From: Werner Keil <werner.keil_at_gmail.com>
Date: Tue, 24 Jul 2012 19:27:31 +0200

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>:

> 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]
> *Sent:* Tuesday, July 24, 2012 11:11 AM
> *To:* 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****
>
> ** **
>
> 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>
> 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]
> *Sent:* Tuesday, July 24, 2012 5:04 AM
> *To:* 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>
> 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] On Behalf
> > Of Markus Eisele
> > Sent: Monday, July 23, 2012 12:17 AM
> > To: 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> 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
> > >
> > > * 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>
> wrote:
> > >>
> > >> Linda DeMichiel <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
> > >>
> > >
> > >
> > >
> > >
> > >****
>
> ****
>
>
>
> ****
>
> ** **
>