GlassFish Modularisation
Let's keep an eye on Glassfish and see what we can learn as they select a modularisation technology.
Projects
Blog Archive
-
▼
2007
(106)
-
▼
March
(20)
- SIP Communicator and OSGi
- JSR 291 Status
- GlassFish Modularisation
- JSR 291 Proposed Final Draft
- Further interest in OSGi and SCA
- Background to Java modularity
- JSR 291 Final Approval Ballot materials
- Modularity and the Java platform
- JSR 277 and class loaders
- The state of Java modularity: JSRs 277, 291, and 294
- BEA's experience of OSGi in building mSA
- IBM, Cisco, and OSGi
- BEA's use of OSGi
- eWeek article on OSGi
- Oracle TopLink being donated to Eclipse
- OSGi universal middleware
- JSR 291 Proposed Final Draft submitted
- JSR 291 rubber-stamp?
- Visualising dependencies between OSGi bundles
- OSGi gathering at JavaOne
-
▼
March
(20)
10 comments:
There have been a few comments from an earlier EZ post on the subject:
http://www.eclipsezone.com/eclipse/forums/t92461.html
I suspect that they won't end up using much of OSGi, but are merely mentioning it to keep people happy.
Yes, I saw that earlier post, thanks.
Interestingly, ModSys apparently has no contributers and no committers who will own up to being in the team.
re: Glyn's comment on committers/team members -- Good point, thanks. Jerome and Kohsuke are the main contributors so far; IIRC. Will fix the site, stay tuned. - eduard/o
re: alblue - "... mentioning (OSGi) to keep people happy." -- Not so. We (GlassFish) are seriously focused on the customers and community needs; it is clear that some level of OSGi support is desireable, but including the whole thing seems an overkill, so we are trying to figure out what is the right balance. - eduard/o
>Will fix the site
That would be helpful - thanks.
>we are trying to figure out what
>is the right balance
The most natural order for adopting OSGi is to work up the layers of the core framework starting with modularity, then lifecycle, then service. You can overlay a set of JARs with OSGi bundles simply by creating suitable metadata (e.g. using the bnd tool) and putting this in the JAR file manifests. Lifecycle usually comes pretty close after in terms of requirements. But you may choose to use your existing techniques for calling between bundles until such times as you need a proper service registry.
That's exactly how we approach OSGi integration.
Metadata handling is separated from it's bundle representation (manifest, annotations, super package in the future, etc...). So meta-data can be obtained from various bundles type (OSGi, maven, 277) and interact happily (277 bundle depending on OSGi bundles for instance).
I think we will probably need some lifecycle support as you mentioned.
As for service registry, this is an interesting topic. So far, I have considered that services identification is usually specific to a bundle type (e.g. META-INF/services, manifest again), however it seems that the ServiceRegistry itself does not need to be tight to a particular type of bundle as it eventually delegates to the module type handler and its class loader how to obtain services instances. Does that make sense ?
>Does that make sense?
Well, I'd have to understand what you are trying to achieve.
Why wouldn't you use an existing open source implementation of the OSGi framework to handle OSGi metadata? The impression I get is that you intend to do your own OSGi implementation, which is feasible, but a bit wasteful.
right it is unclear at this point if we would want to use an OSGi implementation and work above it or just provide OSGi adapters (more than a real OSGi implementation on our own which I agree would be wasteful).
Being 277 and 291 friendly is really what this effort is about and all the answers are not worked out yet of course.
>right it is unclear at this point
>if we would want to use an OSGi
>implementation and work above it
>or just provide OSGi adapters
I see.
A number of app. servers including JOnAS , WebSphere App. Server, and JBoss have adopted the former approach and it seems likely WebLogic will too.
If GlassFish adopts the latter approach, it may turn out to be unique in that respect and then it would be helpful to understand the rationale for designing GlassFish so differently from the other Java EE servers.
>Being 277 and 291 friendly is
>really what this effort is about
So friendliness towards JSR 277 could be a rationale for the GlassFish community, but if JSR 277 interoperates well with JSR 291, then all app. servers that base themselves on OSGi would get JSR 277 friendliness for free.
Post a Comment