|
|
|
|
|
The first Technology Preview for GlassFish v3 was just a proof of concept but we are now working out the detailed plans for the second TP through the final release. |
John has posted a list of the main GF v3 Themes and started a Mail Thread. So far the feedback covers both developer and deployment topics; combined with the Modular Architecture, GFv3 will cover a lot of space. Please check out the wiki page and the mail thread and consider contributing.
What about OSGi integration for server side.
Posted by pavelt on November 02, 2007 at 07:40 AM PDT #
please, give priority to the faster deployments for development for Java, less memory footprint. 9 in 10 glassfish users will not give a damn about JRuby...
Posted by afsina on November 02, 2007 at 05:16 PM PDT #
Keith and Pavel - so we understand your suggestion better... what do you want to get from OSGi integration? - eduard/o
Posted by Eduardo Pelegri-Llopart on November 03, 2007 at 10:23 PM PDT #
There are a few things I think that osgi integration would help:
1) I'd like to see the emergence of a standard module framework. The closest we have is osgi. hk2 and openide seem to be reinventions -- they may be decent, but they are non-interoperable with any other development community.
2) If glassfish v3 was built out of osgi modules, one could mix and match the capabilites of the server and perhaps provide alternatives, create more lightweight distributions, or embed a capability in your own code. One could do all of this with Spring osgi etc.
3) Alternate implementation interoperability would be possible with EJB3. For example, rather than use dependency injection, you could uses a service locator to find the appropriate dependency (if there is more than one, it becomes necessary)
My main point is #1. It seems we have too many non-interoperable module standards snd glassfish doesn't seem to have the userbase to be the "one ring to rule them all." It would have been great to use eclipse plugins in netbeans, etc (within SWT limits) but it wasn't possible because they had different module standards -- it would be nice to avoid that on the server side.
Do you have a good link that explains why osgi wasn't used and why hk2 is worth the non-interoperability? I've ben searching around, but all I can see are flamewars that seem more emotional than substantive.
Posted by Keith Weinberg on November 04, 2007 at 06:17 AM PST #
THanks, Keith.
Note that HK2 does several things and it would exist even if we used OSGi. One of its roles is to encapsulate the dependency on the modular system so GFv3 could be easily switched from one system (JSR277) to another (OSGi), and we would very much welcome contributions to add an OSGi imlementation. We see some technical benefits on 277 but mostly we are trying to stay one level up from that discussion which is really centered at the Java SE layer.
Regarding 2) and 3), it seems to me that GF-specific modules will require to implement additional interfaces anyhow. There is a benefit of familiarity (and tools) from adopting OSGi but so there would be if 277 were to be in Java SE 7. Thus our dilemma...
Anyhow, thanks very much for the list. We will consider it carefuly for GFv3.
Posted by Eduardo Pelegri-Llopart on November 04, 2007 at 07:44 AM PST #
Thank you for your thoughtful reply.
It seems to me that a logical end to all of this is probably to extend the service-locator idea out of the modular system all the way to a network-service-locator.
For example, one should probably be able to define a local module service interface and publish it over the network via a proxy. Think: "An alternative to local and remote ejb3 session beans that gives you versioning and conditional loading for free".
I'm excited about the prospect of these local modules eventually becoming network accessible. Sorta like ejb3 session beans but even more powerful. Along with some notion of redundancy (for clustering) and distribution (for gridding), the possibilities are tremendous.
If the glassfish team could deliver something on the road to that, it would change distributed computing for a long time.
Posted by Keith Weinberg on November 04, 2007 at 09:48 AM PST #