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