标签: apache-karaf

Apache Karaf是Apache Felix的子项目.它被定义为"轻量级OSGi容器".

我不明白我何时应该使用重量级以及何时使用轻量级.他们的网站没有解释太多.

我对Apache Karaf究竟是什么感到有些困惑.

你能否说Apache Karaf包含以下内容:

• Apache Felix(这是OSGi 4.2框架的一个实现)
• Apache Aries(蓝图标准的实现)

我无法在Karaf(版本3.0.1)中启动捆绑包.

捆绑包是使用maven构建的,它导入gson.

我根据需要在maven中包含了gson:

<dependency>
     <groupId>com.google.code.gson</groupId>
     <artifactId>gson</artifactId>
     <version>2.3.1</version>
</dependency>

构建顺利.但是,在部署捆绑包时,我收到了来自Karaf的警告:

2015-05-27 12:45:07,371 | WARN  | 49-19-bin/deploy | fileinstall                      | 11 - org.apache.felix.fileinstall - 3.2.8 | Error while starting bundle: file:/Users/user/Documents/tools/MyBundle-1.0.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Unresolved constraint in bundle MyBundle [121]: Unable to resolve 121.13: missing requirement [121.13] osgi.wiring.package; (&(osgi.wiring.package=com.google.gson)(version>=2.3.0)(!(version>=3.0.0)))
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3974)[org.apache.felix.framework-4.2.1.jar:]
at org.apache.felix.framework.Felix.startBundle(Felix.java:2037)[org.apache.felix.framework-4.2.1.jar:]
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:955)[org.apache.felix.framework-4.2.1.jar:]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1263)[11:org.apache.felix.fileinstall:3.2.8]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1235)[11:org.apache.felix.fileinstall:3.2.8]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1224)[11:org.apache.felix.fileinstall:3.2.8]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:519)[11:org.apache.felix.fileinstall:3.2.8]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:308)[11:org.apache.felix.fileinstall:3.2.8]

捆绑包未安装.

在Import-Package中MANIFEST.MF开头:

Import-Package: com.google.gson;version="[2.3,3)"

我试着改变它:

Import-Package: com.google.code.gson;version="[2.3,3)"

但它给了我一个类似的错误:

missing requirement [121.13] osgi.wiring.package; (&(osgi.wiring.package=com.google.code.gson) …

是否有人使用Karaf而不是Servicemix？如果是这样,你是怎么做出这个决定的？我知道Servicemix在Karaf附近添加了一层功能,只是好奇Karaf是否自己使用以及为什么......

我有一个OSGi包,它使用JAX-RS来处理一些REST服务.该捆绑包使用Apache CXF在Karaf中运行.我需要将基本的http身份验证应用于某些路径/方法组合.我一直在修改Spring Security,看起来新的3.1版本可以让你做到这一点,但是我在使用OSGi时遇到了很多麻烦.

就像测试一样,我创建了一个非常简单的beans.xml文件:

<beans>
    <import resource="classpath:META-INF/cxf/cxf.xml"/>
    <import resource="classpath:META-INF/cxf/cxf-extension-jaxrs-binding.xml"/>
    <import resource="classpath:META-INF/cxf/cxf-extension-http.xml"/>
    <import resource="classpath:META-INF/cxf/osgi/cxf-extension-osgi.xml"/>

    <jaxrs:server id="serverTest" address="/test">
        <jaxrs:serviceBeans>
            <ref bean="tstSvr"/>
        </jaxrs:serviceBeans>
    </jaxrs:server>

    <bean id="tstSvr" class="com.demo.Test"/>

    <security:http auto-config="true">
        <security:intercept-url pattern="/admin/**" access="ROLE_ADMIN" method="PUT" />
        <security:intercept-url pattern="/**" access="ROLE_USER" />
    </security:http>

    <security:authentication-manager>
        <security:authentication-provider>
            <security:user-service>
                <security:user name="user" password="pass" authorities="ROLE_USER"/>
                <security:user name="admin" password="pass" authorities="ROLE_ADMIN"/>
            </security:user-service>
        </security:authentication-provider>
    </security:authentication-manager>
</beans>

现在,这里有趣的部分...从我一直在做的所有阅读中,我需要一个web.xml来实现这一点.比如我尝试使用的这个示例:

<web-app>
    <filter>
        <filter-name>springSecurityFilterChain</filter-name>
        <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
    </filter>
    <filter-mapping>
        <filter-name>springSecurityFilterChain</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>
</web-app>

使用这两个文件的组合不起作用.并且"没有用",我的意思是什么也没发生.没有错误消息,没有异常,捆绑功能就像我尝试添加spring security之前一样.我假设问题是bundle需要是一个WAR或WAB来加载web.xml.它是否正确？

更重要的是,有没有一种方法可以让没有web.xml的春天工作？

我正在假设我需要将捆绑包作为一个捆绑包供CXF加载它,所以我无法将其转换为WAR或WAB,但我并不完全确定是这种情况.

感谢您的任何帮助,您可以提供!

更新: 在做了一堆额外的谷歌搜索后,我发现了一个论坛帖子,提到添加Web-FilterMappings: springSecurityFilterChain;url-patterns:="/*"到您的清单而不是使用web.xml.但是,您仍然需要使用WAB而不是普通的捆绑包.我已将该行添加到我的清单中以防万一,但它没有任何效果.我的问题似乎转变为:如何在CXF中使用WAB？

更新2: 因为这个问题不够长......我决定尝试使用Spring …

我决定在OSGI和Karaf之上构建一个应用程序 - 我真的很喜欢这个东西.但是,我在本地开发机器上进行日常部署时遇到了一些困难.我的意思是..我做了一个改变,然后我想在我当地的Karaf实例上进行测试.它可能发生在每小时几次.

我现在这样做的方式是创建一个JAR包的maven构建,然后将其复制到Karaf的deploy目录中.我认为它根本不优雅.

我试图寻找一种方法(谷歌).我读到了Karaf的功能,但似乎尽管它是一个很好的机制来部署整个应用程序,但它并没有解决我的问题.据我所知,它不会检查我的SNAPSHOT jar的新版本是否出现在我当地的maven回购中,对吗？

我是apache karaf的新手.
当我通过在我的Windows机器上执行bat文件启动apache karaf时.它一直给我低于错误

C:\karaf\apache-karaf-4.0.5\bin>karaf.bat
There is a Root instance already running with name root and pid 1320

我检查了这个pid,但没有使用该pid的进程.

我还检查了任务管理器中的进程,但没有运行名为kafar/root的进程.

我开发的产品由许多捆绑包组成,这些捆绑包作为karaf顶部的功能运行.通常,我们的开发人员一次只能处理一个捆绑包.我们的正常开发类似于:代码,编译,复制捆绑到部署文件夹,测试.我们还发现hotdeploy只是拒绝覆盖作为功能安装的某些bundle而不重启服务器或卸载/重新安装功能,因此有时循环时间更长.

我的问题是:社区中的任何人都有更好的方法吗？我们做事的方式很有效,但我觉得它很慢而且效率低下,而且我认为有人会想出更好的东西!

编辑:我意识到在我的问题中我很不清楚...我们在Karaf下使用Equinox.我们也使用Eclipse和Maven,虽然我不知道使用Maven是相关的.

我正在研究部署和更新OSGI(特别是Karaf)应用程序的方法.似乎有几种选择.一种是使用OSGi Bundle Repository(OBR),另一种是使用Karaf中的Features,第三种是使用Karaf Cave.

我不确定这些选项是如何真正不同的.他们似乎都在做同样的事情.它们只是相同功能的不同实现吗？有人可以解释差异或提供一些建议吗？

OSGI企业版第5版规范第126章提到了兼容性:

"支持Java SE和Java EE客户端使用的传统JNDI编程模型."

和使用OSGI不知道的代码:

"不知道OSGi的客户端和JNDI上下文提供程序使用静态方法连接到JRE JNDI实现.InitialContext类提供从提供程序访问上下文,提供程序使用静态NamingManager方法进行对象转换并查找URL上下文.传统模型不了解OSGi,因此只有在管理这种缺乏OSGi意识的后果时才能可靠地使用它."

但是我不清楚这个文本是仅适用于在OSGI包内执行的"遗留"代码,还是OSGI容器外部的代码,在OSGI容器嵌入应用程序的情况下.

在嵌入方案中,OSGI容器外部和内部可能存在执行JNDI调用的应用程序代码,并且当它们在同一JVM中执行时,它们将共享JNDI实现.

问题:在嵌入式OSGI容器中运行的OSGI JNDI实现是否允许容器外部的OSGI无意识代码像往常一样执行其JNDI调用,或者是否需要移植到"OSGI-awareness"？

使用Apache Karaf 2.3.0(使用Apache Aries JNDI 1.0.0)自己尝试这个似乎不起作用,因为Apache Aries需要JNDI客户端调用来自OSGI包.
部分堆栈跟踪:

javax.naming.NoInitialContextException: The calling code's BundleContext could not be determined.
    at org.apache.aries.jndi.OSGiInitialContextFactoryBuilder.getInitialContext(OSGiInitialContextFactoryBuilder.java:46)
    at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
    at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307)
    at javax.naming.InitialContext.init(InitialContext.java:242)
    at javax.naming.InitialContext.<init>(InitialContext.java:192)

问题:这是正确的行为,还是我可以参考的规范中有一部分违反了此限制？