From: Reza Rahman <reza_rahman_at_lycos.com>
Date: Tue, 24 Jul 2012 13:14:19 -0400

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