Markus/all,
Thanks for trying to follow up on that.
One thing with EE in mind I gently proposed to the EC when Mark mentioned
this "Profile" idea was something like a "Headless" mode for servers and EE.
Unfortunately, while Swing or JavaFX could hopefully be avoided on the
server side, there are several references to AWT at least in an earlier
(JavaEE 5 level) version of RichFaces just as an example:
java.lang.NoClassDefFoundError: Could not initialize class
sun.awt.X11GraphicsEnvironment
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:169)
at
java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:68)
at
java.awt.image.BufferedImage.createGraphics(BufferedImage.java:1135)
at
org.ajax4jsf.resource.Java2Dresource.getImage(Java2Dresource.java:115)
at org.ajax4jsf.resource.Java2Dresource.send(Java2Dresource.java:89)
at
org.ajax4jsf.resource.ResourceLifecycle.sendResource(ResourceLifecycle.java:221)
at
org.ajax4jsf.resource.ResourceLifecycle.send(ResourceLifecycle.java:157)
at
org.ajax4jsf.resource.InternetResourceService.load(InternetResourceService.java:335)
at org.ajax4jsf.cache.LRUMapCache.load(LRUMapCache.java:116)
at org.ajax4jsf.cache.LRUMapCache.get(LRUMapCache.java:87)
at
org.ajax4jsf.resource.InternetResourceService.serviceResource(InternetResourceService.java:195)
at
org.ajax4jsf.resource.InternetResourceService.serviceResource(InternetResourceService.java:141)
at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:510)
at
org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
at
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
at
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
at
org.jboss.on.embedded.LazyStartupFilter.doFilter(LazyStartupFilter.java:87)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
at
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
at
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
at
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
While there could be other ways to use images and graphics, it shows, how
many dependencies even to a "desktop" style GUI package we have in EE.
Cheers,
On Mon, Jul 23, 2012 at 6:17 AM, Markus Eisele <myfear_at_web.de> wrote:
> 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
> >>
> >
> >
> >
> >
> >
>
--
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"