Skip to main content

[jsr342-experts] Re: [javaee-spec users] Re: Re: Modularization Framework/SPI

  • From: Werner Keil <werner.keil@...>
  • To: jsr342-experts@...
  • Cc: Jevgeni Kabanov <jevgeni@...>, Craig Ringer <ringerc@...>
  • Subject: [jsr342-experts] Re: [javaee-spec users] Re: Re: Modularization Framework/SPI
  • Date: Thu, 26 Jul 2012 17:03:34 +0200

Somehow this only went to Reza as he sent it CC to the EG

On Thu, Jul 26, 2012 at 4:19 PM, Reza Rahman <reza_rahman@...> wrote:
+1. This basically restates what I was trying to suggest. That being said as Craig alluded to, this is a "nice to have" that is not worth sacrificing basic API innovation (e.g. component model alignment), technology adoption (e.g. HTML5, NoSQL, social media, etc) and basic stability (application servers that are lightweight, affordable and bug free).

On 7/26/2012 8:54 AM, michael keith wrote:
A quick comment on this.

Modularity is something that we need to have in EE, and in fact we already have some of the packaging and isolation (EJB jars, wars and the like have been "modules" since the beginning), but we are missing the parts that allow us to better state dependencies, allow multiple versions of the same thing, and arguably be able to dynamically add (aka hot deploy) them.

We don't strictly need to have a module system surface at the application developer level to achieve this. In fact, the vendors that have used module systems like OSGi in their implementations do not need to expose them to the users (and in many cases they don't). They use modularity internally to accomplish some of the goals listed above. In EE we need to focus on the problems that we are having and come up with solutions so developers can do what they want to do in a standard way. The solutions may or may not be implemented by the vendors using a module system (though I believe the smart choice is to use one). The EE spec should not tread into the domain of defining or coupling to a module system.


At least it would be good, if vendor-specific class-loader control in Enterprise Applications like "weblogic-application.xml" or similar descriptors in other containers could be more coordinated. I know from experience with large systems, there are ways to overload the dependencies or provided libraries of the underlying container there. Unfortunately not all versions of all containers do this in a consistent way right now, so it is almost impossible to deploy a large enterprise application without class loading issues into more than one container right now.

Also for the advocates of "Minimal Profiles" and all other settings that are smaller than the full EE scope, it is good to understand, e.g. even in a simple WAR based web-application in recent versions of WLS you must wrap that into an EAR to accomplish e.g. isolation of certain dependencies against other Web applications or the underlying container and its own dependencies.

Take different versions of JPA only as one example, it equally applies to other dependency issues.

On Thu, Jul 26, 2012 at 4:58 PM, Jason T. Greene <jason.greene@...> wrote:
On 7/26/12 6:57 AM, Jevgeni Kabanov wrote:

Wouldn't it make more sense to accommodate OSGi as an optional extension
of the spec and just define better interoperation? I'm afraid that
baking modularity into the Java EE spec will introduce more complexity
than it's worth for most of the Java EE ecosystem.

The problem with that approach is that OSGi and EE are essentially competing models. OSGi isn't just modular classloading, it's a a service and component environment with very extensive restrictions on interaction and definition. You can't model legacy EE behavior and packaging on it (e.g. EARs). So you end up with essentially two forms of every deployment. WAB vs WAR, some kind of EJB bundle, and two types of classloading models. The reverse is also difficult. The service registry is not mappable to JNDI, or EE resource injection. In a nutshell, if you include OSGi "support", unless you redesign EE around OSGi, it's going to be an island.

IMO a better approach is defining something thinner that is purely around classloading, and bridges well to the legacy EE approach. We should make it easy as possible for users to transition to the modular world.


> This all is very anecdotal. In our survey most folks did not indicate > that they use OSGi or anything like it

I have similar anecdotal experiences. There is lots of interest around OSGi (although it seems less than a year ago), but 9/10 times the developers I hear from are interested just because they want more isolation and better packaging. They aren't really after everything else it brings in. I also found a lot of misconceptions. Like that having OSGi means you can do side-by-side/versioned/rolling deployment in Java EE. The 1/10 is usually someone that is self-building a container anyway. Although I fully admit that as an EE vender, I tend to interact more with those that have at least used or built something on Java EE. This perception doesn't cover the complete Java market.



+1
See my reply to Mike's input above, it is mostly about dependency isolation, and as some of that is already possible today, shifting some of the best examples of how it's done in vendor specific descriptors and configuration files into a more general EE descriptor shouldn't be impossible and maybe all we need for now
 
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat



--

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"

* JavaOne: September 30-October 4 2012, San Francisco, USA. Werner Keil,  JCP Executive Committee will represent "Eclipse UOMo, STEM, and JSRs involved in, e.g. 331 or JCP.next"



[jsr342-experts] Re: [javaee-spec users] Re: Re: Re: Re: Re: Modularization Framework/SPI

(continued)

[jsr342-experts] Re: [javaee-spec users] Re: Re: Re: Re: Re: Modularization Framework/SPI

Werner Keil 07/26/2012

[jsr342-experts] Re: [javaee-spec users] Re: Re: Re: Re: Re: Re: Modularization Framework/SPI

Reza Rahman 07/26/2012

[jsr342-experts] Re: [javaee-spec users] Re: Re: Re: Re: Re: Re: Modularization Framework/SPI

Werner Keil 07/26/2012

[jsr342-experts] Re: [javaee-spec users] Re: Re: Re: Re: Re: Re: Modularization Framework/SPI

Reza Rahman 07/26/2012

[jsr342-experts] Re: [javaee-spec users] Re: Re: Re: Re: Re: Re: Modularization Framework/SPI

Werner Keil 07/26/2012

[jsr342-experts] Re: [javaee-spec users] Re: Re: Re: Re: Re: Re: Modularization Framework/SPI

Werner Keil 07/26/2012

[jsr342-experts] Re: [javaee-spec users] Re: Re: Re: Re: Re: Re: Modularization Framework/SPI

Werner Keil 07/26/2012

[jsr342-experts] Re: [javaee-spec users] Re: Re: Re: Modularization Framework/SPI

Werner Keil 07/26/2012

[jsr342-experts] Re: [javaee-spec users] Re: Re: Re: Modularization Framework/SPI

Reza Rahman 07/26/2012

[jsr342-experts] Re: [javaee-spec users] Re: Re: Modularization Framework/SPI

Jason T. Greene 07/26/2012

[jsr342-experts] Re: [javaee-spec users] Re: Re: Modularization Framework/SPI

Werner Keil 07/26/2012

[jsr342-experts] Re: [javaee-spec users] Re: Re: Modularization Framework/SPI

Jevgeni Kabanov 07/26/2012

[jsr342-experts] Re: [javaee-spec users] Re: Re: Modularization Framework/SPI

Werner Keil 07/26/2012

[jsr342-experts] Re: [javaee-spec users] Re: Re: Modularization Framework/SPI

Markus Eisele 07/26/2012
 
 
Close
loading
Please Confirm
Close