Date: Wed, 25 Jul 2012 16:27:52 +0200
Well, this could work a bit like with JSR 107 (which since its formation in
2001!!! hasn't even published an EDR yet btw.[?]) and 347 (which also missed
its goal for a Public Draft this May, probably makes it less likely to go
into EE7 unless they get their act together quickly)
While the two are distantly related, 347 has some goals which may even be
fulfilled independently of 107, especially should 107 fail all together (or
be deferred to Java SE 10[?])
I guess what's been called SPI here could be instrumentalized on top of
existing well-established technologies like OSGi, JBoss Modules or whatever
else you prefer to use. And in the event, Jigsaw or a follow-up JSR exists
and becomes accepted, future versions of Java EE and this mechanism could
and should be flexible enough to make use of that, too.
To a certain extent this may also benefit from JSR 350 (State Management)
where a wide range of providers and SPI extensions for different areas of
Java and EE are also explored. As of now, 350 seems more likely towards an
EE 8 "Release Train" according to official voices. As may be other JSRs,
especially if they haven't yet produced a convincing EDR yet. Thus the
plans discussed here are also more likely for EE8, unless EE7 was to change
timing in favour of at least appropriate "Java EE Modularity" first?[?]
Kind Regards,
-- Werner Keil | JCP Executive Committee Member | Eclipse UOMo Lead Twitter @wernerkeil | #Java_Social | #EclipseUOMo | #OpenDDR Skype werner.keil | Google+ gplus.to/wernerkeil * Chip-to-Cloud Security Forum: September 19 2012, Nice, French Riviera. Werner Keil, JCP Executive Committee, JSR-321 EG Member will present "Trusted Computing API for Java™" * Eclipse Day Delft: September 27 2012, Delft, Netherlands. Werner Keil, Eclipse Committer, UOMo Lead, Mærsk Build Manager will present "Triple-E class Continuous Delivery with Hudson, Maven and Mylyn" * JavaOne: September 30-October 4 2012, San Francisco, USA. Werner Keil, JCP Executive Committee will represent "Eclipse UOMo, STEM, and JSRs involved in, e.g. 331 or JCP.next" On Wed, Jul 25, 2012 at 3:53 PM, Jeff Genender <jgenender_at_savoirtech.com>wrote: > I have to completely disagree with Craig. JavaEE vendors are implementing > pluggable modular capabilities because its direly needed. > > We don't have to design a thorough modular spec now, but something that > gives a bridge to pluggable modularity would be a great direction. A > simple SPI that contains a degree of life cycle would be a good start. > > If we keep putting this off, it going to be too late and the landscape for > modularity will be terribly fragmented. > > In my world, I am seeing users pushing modularity in front of JavaEE and > we are really missing this boat. A large section of my clients are moving > to OSGi stacks picking and choosing what they want in their stacks, with > some building their own JavaEE light containers (JTA, JPA). > > Excuse my abrasiveness, but this is key and we just keep making excuses > for putting it off. > > Craig, this was certainly not directed at you... Just the nay-sayers as a > whole. > > Jeff > Sent from my iPhone > > On Jul 25, 2012, at 8:32 AM, Reza Rahman <reza_rahman_at_lycos.com> wrote: > > I must say these are indeed good points… > > > > *From:* Craig Ringer [mailto:ringerc_at_ringerc.id.au] > *Sent:* Tuesday, July 24, 2012 8:07 PM > *To:* Reza Rahman > *Cc:* users_at_javaee-spec.java.net > *Subject:* Re: [javaee-spec users] [jsr342-experts] Re: Modularization > Framework/SPI > > > > On 07/24/2012 09:27 PM, Reza Rahman wrote: > > You are absolutely correct in that CDI is quite progressive with regards > to extensibility and pluggability into non-Java EE runtimes. I am actually > concerned about pluggability/upgradability within Java EE runtimes. This > could be as simple as a bootstrap API/configuration mechanism to choose > between multiple available implementations in the current class-loader, > much like JPA and Bean Validation (and to some degree JSF/JAX-RS) allows. > > Please, no. > > Allow CDI to be a locked and bolted in fixed part of the server. > > EE app server vendors are already wasting lots of time on implementation > pluggability that they could be spending on more meaningful platform > improvement. Despite this, pluggability still often doesn't work right > because few of the SPIs are complete enough. Breakage is common. > > Unless a full module system and insanely detailed SPIs for component > interaction is specified, pluggability will always be incomplete and > unreliable. Sometimes it's important anyway (eg: JPA) but do we *really* > need pluggable CDI implementations? What does that gain the end > user/developer in real-world terms? > > Adding more pluggability is not the answer. In my view, clearly specifying > what is and isn't pluggable is. JPA impl, JSF impl? must be > interchangeable. CDI, EJB3, JTA, JCA? Bolted in. You don't like 'em, roll > your own assembly of parts from a servlet container or use another EE app > server. > > Right now we have this horrible in-between mush where everything is > expected to be pluggable in theory but little is in practice. Where > components are replaced it often only works with reduced functionality and > extra bugs. It's not clear to users and developers which components can be > replaced and how. EE app server vendors don't care much because it's WAY > too hard to test and verify; they want to get their main product working > well instead. Witness JBoss AS 7, which is great using Hibernate 4 and > RESTEasy, but good luck using it with EclipseLink and Jersey - it's > possible, but not just a matter of bundling some jars. > > Please leave pluggability until there's a solid module system. Either > adopt Jboss Modules from AS7 for EE7 (please!) or recognise that without a > strong module system - and lots and lots of work on improving SPIs - > pluggability of core components will not work well. > > Witness for example the "fun" involved in plugging EclipseLink into JBoss > AS 7 with full dynamic weaving, JTA, etc: > > https://community.jboss.org/wiki/HowToUseEclipseLinkWithAS7 > > Do you really want to make developing an app server into a huge > combinatorial problem - with a severe lack of spec-wide integration tests > to use for verification? Is replacing CDI solving a real developer problem > and furthering the platform, or is it just pluggability-as-a-philosophy? > Are there better places (like legacy cleanup and polishing oversights out > of EE6) that time can be spent? > > -- > Craig Ringer > >
