From: Werner Keil <werner.keil_at_gmail.com>
Date: Tue, 24 Jul 2012 17:11:08 +0200

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