收录了 osgi 频道下的 50 篇内容
欢迎进入GlassFish OSGi-JavaEE专题!自从GlassFish v3开始,一个新的特性被加入到GlassFish中,那就是GlassFish OSGi-JavaEE。本专题将分为九个部分向大家介绍GlassFish OSGi-Java EE相关的知识,本文对GlassFish OSGi-JavaEE做简单的介绍并简要叙述企业级的OSGi开发的现状。
在Part1中,我们提到了企业级OSGi制定了一系列的规范来与JavaEE集成,其中,最具代表性的规范是OSGi WEB应用程序规范,这部分将带领大家深入理解OSGi WEB应用程序规范和GlassFish OSGi/WEB容器。
Peter Kriens是OSGi的推动者之一,日前宣布重返OSGi联盟,到2012年初为止他一直在这里担任总监长达11年。InfoQ联系到了Peter,与他讨论了重返OSGi及其jpm4j项目的最新情况。
Java 9中标志性的特性是Java平台模块化系统(JPMS)。OSGi已经很成熟,为什么另一个Java模块化系统很快要出现?这里-有技术、政治和商业三方面的原因。本篇文章中,我们从技术角度对比两个方面,看看JPMS和OSGi如何协同工作。
普通的web应用要转换为OSGi应用,经常会遇到应用中依赖的Jar是非标准的情况,这些Jar可能只遵守了部分OSGi规范,甚至Manifest信息是空的。这种情况在OSGi 应用中根本无法使用这个非标准的Jar做为Bundle,故必须要将这个非标准的Jar转换成遵守OSGi规范的Bundle。另外用Maven管理的仓库,由于不同开发者对规范的理解不同,在仓库中也存在了各种规范或者不规范的Jar,如果我们能很好的将Maven仓库中的Jar转换成标准的Bundle,Maven仓库也就转换成对应的OSGi Bundle仓库,对于非OSGi的应用而言也就可以很方便的利用Maven仓库,普通web应用也可以平滑的切换到OSGi环境。
把大型系统移植到OSGi架构上常常意味着解决复杂的类加载问题。这篇文章专门研究了面向这个领域最难问题的几个框架:有关动态代码生成的框架。这些框架也都是些超酷的框架:AOP包装器,ORM映射器以及服务代理生成器,这些仅仅是一些例子。
The flagship feature of Java 9 will be the new Java Platform Module System (JPMS). Given the maturity of OSGi there were technical, political and commercial reasons why another Java module system will soon exist. In this article we compare the two from a technical perspective and see how JPMS and OSGi can work together.
上周OSGi社区大会在伦敦召开,它是和JAX伦敦大会一起举办的。 会上演讲的内容涉及到的范围非常广泛,从Java EE的迁移和云计算,到嵌入式设备和Android都有涉及。
Spring Dynamic Modules for OSGi(也就是从前的Spring-OSGi)今天发布了1.0版本。InfoQ就这个版本的发布以及它能为Spring社区提供什么采访了 SpringSource的CTO——Adrian Colyer和Spring Dynamic Modules项目的领导人——Costin Leau。
随着最近GlassFish3.0版“Prelude”,即Sun公司基于OSGi的Java EE 6服务器的发布,OSGi在企业中的应用已经覆盖了几乎所有后端服务器。
近日OSGi联盟的技术指导Peter Kriens在UK OSGi Users Group上就即将到来的OSGi 4.2发表了一个主题演讲。该活动已经被全程录制下来,同时还有演讲视频。OSGi 4.2将于今年8月底发布,包含了大量的新特性。
Nagarro的Bill Kayser最近详细描述了他将应用程序从一个自定义基础架构和构造过程转移到OSGi上的经历。
OSGi正在被越来越多的项目所采用。OSGi规范为以模块化形式编写和部署应用到本地或远程计算机提供了一个公共模型。与创建一个单一的不可分应用(monolithic app)不同,该规范允许众多小组件相互协作。这篇新闻为你展现了为什么有像OSGi这样一个规范是至关重要的,它真正包含了哪些内容,以及未来发展方向。
在今年5月份的网侠大会上,InfoQ中文站有幸与国内OSGi的先锋林昊(BlueDavy)在一起探讨了OSGi的相关话题,包括它的优势、复杂度以及Java下的实现等等。直接点击观看完整视频。
一段时间以来,SpringSource一直为Gradle(基于Groovy语言)构建系统的支持者。在一年半之前,SpringSource便开始将构建系统从Maven转向Gradle。现在,Spring 3.2 的开发已经接近尾声,而在此版本中,OSGi元数据将不会发布到Maven库里。
Eric Newcomer,OSGi企业工作组的联合主席,讲述了OSGi的变革以及它和SOA、ESB之间的关系。他谈到他是怎么认为OSGi在未来几年会成为主流,以及Sun是否会采用OSGi作为一个供选择的容器模型。
OSGi 4.2已经发布一月有余了,在这一个月当中都发生了哪些事情呢?
IONA首席技术官以及OSGi企业工作组联合主席Eric Newcomer在这篇采访中,讨论了IONA为什么对OGGi那么感兴趣,为什么OSGi在未来几年中会继续发展和成为主流。另外Eric还简单说明了OSGi与ESB、SOA的关系,以及Sun是否会对OSGi更加感兴趣。
OSGi的API最初是依据Java 1.1平台设计的,所以能运行在包含VM的设备上,比如J2ME移动电话。然后,随着Java 1.4的弃用,几乎所有的开发系统都会使用到泛型和for-each这样的语言特性。Peter Kriens和BJ Hargrave分享了他们的研究成果,就是OSGi API如何能够支持泛型。
很多人认为迁移到OSGi上的代价非常大,但通常这里面包含了模块化本身的代价。无论使用的是OSGi、Jigsaw还是其他的模块化架构,要想对大型、复杂、纵横交错的库进行模块化都要付出代价,而这种模块化对于维护者来说并没有立竿见影的好处。然而如果不这么做,系统就会随着时间的推移变得更加复杂、更加的纵横交错,维护代价也会增加。