Unfortunately Jigsaw's current direction will make this difficult. They
are taking a "everything must be specified in the language/bytecode"
route, and leaving adequate extensibility contracts behind. Aside from
the plugability challenge it's going to make legacy interoperability
between old EE deployments and the future jigsaw EE deployments difficult.
So to be honest, I think this delay is a good thing because really this
level of change should have been debated in a JSR. A JSR that has
representation from this EG. Otherwise I fear it will just be a disaster.
In the past I was against defining someone on our own, because I didn't
like the idea of further fragmentation, but at this point it seems
inevitable.
On 7/24/12 12:41 PM, Jeff Genender wrote:
> These are great examples, Werner, and is a great reason for a SPI
> framework. It would be awesome to pick your module framework du jour.
>
> Jeff
>
> On Jul 24, 2012, at 12:27 PM, Werner Keil wrote:
>
>> If that worked, why not.
>> Let's hear from more App Server Vendors.
>> Beside OSGi or Jigsaw, there are a couple of similar approaches,
>> Eclipse ObjectTeams or JBoss Modules which could help as inspirations.
>> Those like OSGi offer modularity already.
>>
>> Am 24.07.2012 19:14 schrieb "Reza Rahman" <reza_rahman_at_lycos.com
>> <mailto:reza_rahman_at_lycos.com>>:
>>
>> Right. Admittedly, the ultimate answer to the multiple API version
>> issue is of course Jigsaw/OGSi style general modularity. However,
>> a more “low-tech” option could simply be being able to specify
>> desired API version numbers in the existing deployment meta-data
>> and having the runtime’s class-loader understand what you mean and
>> load the right Java EE API packages.____
>>
>> __ __
>>
>> *From:*Werner Keil [mailto:werner.keil_at_gmail.com
>> <mailto:werner.keil_at_gmail.com>]
>> *Sent:* Tuesday, July 24, 2012 11:11 AM
>> *To:* jsr342-experts_at_javaee-spec.java.net
>> <mailto:jsr342-experts_at_javaee-spec.java.net>
>> *Subject:* [jsr342-experts] Re: Modularization Framework/SPI____
>>
>> __ __
>>
>> That's a bit down to what apps and the frameworks used do, too.
>> E.g. we could very easily deploy Drools to a variety of containers
>> including WebLogic (which was the production environment there)
>> other than JBoss AS, while JRules just gives us pain by demanding
>> a very specific version of JSF and ripping the guts out of
>> underlying app servers like WLS or JBoss<image001.gif>____
>>
>> __ __
>>
>> I saw similar issues between let's say Hibernate and various
>> servers, too. Might be fixed by now. And as you mention JPA,
>> please don't try that in older WebLogic versions that have an
>> older JPA version built in, it's a pain probably worse than what
>> we're facing with JRules here at another client...____
>>
>> On Tue, Jul 24, 2012 at 3:27 PM, Reza Rahman
>> <reza_rahman_at_lycos.com <mailto:reza_rahman_at_lycos.com>> 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.____
>>
>> ____
>>
>> *From:*Werner Keil [mailto:werner.keil_at_gmail.com
>> <mailto:werner.keil_at_gmail.com>]
>> *Sent:* Tuesday, July 24, 2012 5:04 AM
>> *To:* jsr342-experts_at_javaee-spec.java.net
>> <mailto:jsr342-experts_at_javaee-spec.java.net>
>> *Subject:* [jsr342-experts] Re: Modularization Framework/SPI____
>>
>> ____
>>
>> Now the JAX-WS and almost everything related to XML I roughly
>> agree, but why would you think CDI can't be extended, upgraded or
>> things easily plugged into.____
>>
>> ____
>>
>> There are dozens of Seam Modules and there will be even more of
>> that once DeltaSpike gets to speed.____
>>
>> Unlike most of the Servlet related parts, CDI also works to a
>> large extent in a pure SE or Android environment, so I think it
>> can be safely considered one of the more modern parts of the Java
>> ecosystems. Allowing better pluggability of other JSRs and
>> frameworks properly building on top of that.____
>>
>> ____
>>
>> Werner____
>>
>> On Tue, Jul 24, 2012 at 2:44 AM, Reza Rahman
>> <reza_rahman_at_lycos.com <mailto:reza_rahman_at_lycos.com>> wrote:____
>>
>> To be honest, I think Java EE API pluggability/upgradability is a
>> bigger issue than general modularity per se. And I don't think the
>> issue is as intractable as it may first appear. JPA, JSF, Bean
>> Validation, JAX-RS, JavaMail, JMS, etc are pluggable to some
>> degree but could use further improvements (particularly with
>> regards to upgradability). I don’t think most people expect
>> Servlet, EJB, EL, JSP, JTA, etc to be that pluggable anyway. The
>> big ones as far as I have seen personally that could use greater
>> pluggability/upgradability would be CDI and JAX-WS (roughly in
>> that order). If we can't achieve the somewhat lofty (but doubtless
>> important) goal of general modularity, I think it would be great
>> if we could make some headway in making these few APIs more
>> pluggable?____
>>
>>
>> > -----Original Message-----
>> > From: eisele.markus_at_gmail.com <mailto:eisele.markus_at_gmail.com>
>> [mailto:eisele.markus_at_gmail.com <mailto:eisele.markus_at_gmail.com>]
>> On Behalf
>> > Of Markus Eisele
>> > Sent: Monday, July 23, 2012 12:17 AM
>> > To: jsr342-experts_at_javaee-spec.java.net
>> <mailto:jsr342-experts_at_javaee-spec.java.net>
>> > Subject: [jsr342-experts] Modularization Framework/SPI
>> >
>> > Hi Jeff/all,
>> >
>> > I would highly appreciate to adopt a modularization
>> framework/SPI! I feel that
>> > the the missing modularity is hitting EE harder with every
>> release. No matter
>> > which way we go here, let's not forget that there are things we
>> will not solve
>> > without sufficient support from the SE platform (Classloading
>> :|). What I do
>> > believe is, that profiles in the sense Mark proposed them as a
>> intermediate
>> > solution for SE will not work for us.
>> >
>> > I'm still missing more general feedback from Linda/Bill here. As
>> to my
>> > understanding the Jigsaw delay also made some of their visions
>> obsolete (I
>> > might have interpreted that from a tweet by Arun Gupta) ...
>> >
>> > Thanks,
>> > - M
>> >
>> > On 20 July 2012 15:26, Jeff Genender <jgenender_at_savoirtech.com
>> <mailto:jgenender_at_savoirtech.com>> wrote:
>> > > But why wait on our side at this stage? Why can't we create an
>> > > SPI/Adapter framework for EE and plug in whatever modularity
>> in the
>> > > background? That way we can start with OSGi and then additionally
>> > > hook up Jigsaw when/if that ever comes to fruition...
>> > >
>> > > Thoughts?
>> > >
>> > > Jeff
>> > >
>> > > On Jul 20, 2012, at 7:54 AM, Werner Keil wrote:
>> > >
>> > > Jim/all,
>> > >
>> > > Interesting thoughts. Although Mark tried to mitigate damage
>> done by
>> > > the Jigsaw delay a bit, a lot of the finer grained Modularity
>> in EE is
>> > > likely to be delayed until EE can actually use Java 9+ Modularity.
>> > >
>> > > Whether that'll be EE8 or 9, let's see, usual naming scheme leans
>> > > towards the latter.
>> > >
>> > > For those profiles that already exist or may be created
>> without JMS,
>> > > why not consider making MDBs optional, but for any scenario where
>> > > Messaging like MQ Server or other JMS solutions need to be
>> consumed, I
>> > > strongly suggest keeping MDBs in there.
>> > > I saw them work perfectly fine in some of the biggest Java EE
>> farms
>> > > probably out there with large telcos. About a year ago another big
>> > > telco in a much smaller system insisted on using their wrong
>> > > experience and understanding of Spring and Spring JMS Template
>> for a
>> > > similar requirement. Spring mimicking proper Java EE and protocols
>> > > like JTA (sorry having to say that, but the whole "Spring vs.
>> Standard
>> > > EE" has its point, I am not trying to fuel it) by adding its "AOP
>> > > Voodoo" caused that part of the project to end up in a horrible
>> > > failure. And us coaches recommended different approaches which
>> they
>> > > unfortunately didn't listen to<326.gif>
>> > >
>> > > Removing MDBs by default from ANY EE Profile would send the wrong
>> > > signal and raise temptation for similar experiments with other
>> > > technologies. While considering them optional in certain profiles
>> > > where JMS is not required at all, that I could imagine.
>> > >
>> > > Regards,
>> > > --
>> > >
>> > > Werner Keil | JCP Executive Committee Member | Eclipse UOMo Lead
>> > >
>> > > Twitter @wernerkeil | #Java_Social | #EclipseUOMo | #OpenDDR Skype
>> > > werner.keil | Google+ gplus.to/wernerkeil
>> <http://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"
>> > >
>> > >
>> > > On Fri, Jul 20, 2012 at 12:00 AM, Jim Knutson
>> <knutson_at_us.ibm.com <mailto:knutson_at_us.ibm.com>> wrote:
>> > >>
>> > >> Linda DeMichiel <linda.demichiel_at_oracle.com
>> <mailto:linda.demichiel_at_oracle.com>> wrote on 05/10/2012
>> > >> 02:50:43
>> > >> PM:
>> > >> > The Java EE Platform and EJB specifications currently
>> require the
>> > >> > capability of using RMI-IIOP to export EJB components and
>> to access
>> > >> > EJB components over a network. This requirement enables
>> > >> > interoperability between Java EE products.
>> > >> >
>> > >> > It has been suggested that we consider removing the
>> requirement for
>> > >> > such interoperability support from the Java EE Platform and EJB
>> > >> > specifications.
>> > >>
>> > >> Apologies for the late reply. In general, I'm in favor of making
>> > >> optional some of the less used parts of the platform, so
>> consider this a +1.
>> > >>
>> > >> However, we all need to agree on what this means as there are
>> > >> intended compliance implications. I agree with Jason that
>> interop is
>> > >> important and that there are certain QoS characteristics that go
>> > >> along with RMI-IIOP.
>> > >>
>> > >> > There are several reasons behind this proposed change:
>> > >> >
>> > >> > * RMI/IIOP has been largely superseded by modern web
>> technologies
>> > >> > that provide interoperability support, such as SOAP and
>> REST.
>> > >> > Hence, few developers are currently relying on RMI/IIOP
>> for this
>> > >> > purpose.
>> > >> > * Implementing the required support is seen as an unnecessary
>> > >> > burden on Java EE implementors.
>> > >> > * There is a perception that this requirement makes Java EE
>> seem
>> > >> > heavyweight at a time when we're trying to appeal to
>> developers
>> > >> > who want a lightweight solution.
>> > >>
>> > >> The first bullet above implies more than just making RMI-IIOP
>> > >> optional to me. It says that the RMI programming model
>> itself with
>> > >> its corresponding QoS has been replaced by web services /
>> REST when
>> > >> interop is required.
>> > >>
>> > >> The second bullet is not quite true. It's an implementation
>> burden
>> > >> for any _new_ Java EE implementor, but any existing vendor who
>> > >> already supports RMI-IIOP is not likely to remove support
>> from their
>> > >> existing customers just because it's optional now. As usage
>> drops to
>> > >> zero, then existing vendors can stop supporting it, but it's
>> still a
>> > >> non-zero effort in the meantime.
>> > >>
>> > >> There's more than a perception that RMI-IIOP is heavyweight.
>> There's
>> > >> a very noticeable memory footprint that goes with an ORB,
>> OTS, INS,
>> > >> and CSIv2 and not everyone will require this. So making this
>> > >> optional is a definite improvement for a large customer segment.
>> > >>
>> > >> > Removing this requirement would mean that an implementation
>> of the
>> > >> > Platform would still be required to support remote access
>> to EJBs,
>> > >> > but would not be required to use IIOP to do so. That is,
>> we would
>> > >> > be removing requirements that provide interoperability across
>> > >> > products, but would not be removing requirements that require
>> > >> > support for remote access within a single product, since
>> other protocols
>> > could be used.
>> > >>
>> > >> This is where we start to get into ironing out a common
>> understanding
>> > >> of what is truly being proposed. The first bullet implies
>> that all
>> > >> of the RMI programming model is optional and you just
>> annotate your
>> > >> web profile EJBs with @WebService if you want to expose
>> remote access
>> > >> (or use REST). I like the idea of provisioning in web services
>> > >> remoting function without also being required to provide RMI
>> remoting
>> > function.
>> > >> The way the spec is today, vendors are technically in
>> violation of
>> > >> the spec if they provide one without the other. However, the
>> > >> previous paragraph implies that RMI stays and it's only the CORBA
>> > >> interop (ORB, OTS, INS, CSIv2) requirements that disappear.
>> > >>
>> > >> Let's assume for the moment that just the CORBA interop
>> requirements
>> > >> go away and we keep the RMI programming model. Will
>> transaction and
>> > >> security context flows still be required? What about remote JNDI
>> > >> lookup? If we have no portability requirements, are we confident
>> > >> that CTS can validate compliant behavior when the client and the
>> > >> server are vendor specific?
>> > >>
>> > >> From my perspective, RMI, RMI-IIOP, and all the OTS, CSIv2, INS
>> > >> related aspects and qualities of service should be tied together.
>> > >> I don't mind them being made optional and vendors can
>> implement RMI
>> > >> or not as they choose, but if they choose to implement RMI, a
>> > >> compliant and interoperable set of QoS should be part of the
>> package.
>> > >>
>> > >> If push came to shove, I could accept non-interoperable RMI iff:
>> > >> 1. RMI is separately optional (e.g. you can deliver web profile +
>> > >> JAX-WS + EJBs as JAX-WS components without requiring RMI,
>> > >> MDBs, etc.)
>> > >> 2. a non-interoperable RMI is required to support the same QoS
>> > >> as RMI-IIOP based RMI.
>> > >>
>> > >> While you're at it, how about making MDBs optional so I can
>> deliver
>> > >> web profile + MDBs, but without web services and RMI if I want?
>> > >>
>> > >> Thanks,
>> > >> Jim Knutson
>> > >> WebSphere Java EE Architect
>> > >>
>> > >
>> > >
>> > >
>> > >
>> > >____
>>
>> ____
>>
>>
>>
>> ____
>>
>> __ __
>>
>
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat