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_at_lycos.com> 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_at_redhat.com>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"
