jsr342-experts@javaee-spec.java.net

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

From: Jason T. Greene <jason.greene_at_redhat.com>
Date: Thu, 26 Jul 2012 10:30:25 -0500

Really? You have never seen users complain about EE classloader
isolation problems? It's pretty common these days for EE deployments to
suck in 10+ libraries that conflict with another deployments 10+ libraries.

On 7/26/12 10:27 AM, Reza Rahman wrote:
> Thanks for the clarification, but I don't think that I've misinterpreted
> much. The overwhelming indication the way I've seen it first hand is
> that people don't really need general modularity that much and have much
> more bread-and-butter concerns.
>
> On 7/26/2012 11:15 AM, Jason T. Greene wrote:
>> I think Jeff is frustrated because we are missing his underlying
>> point. What I think hes saying (and I am sure he will correct me), is
>> that we need standardized modularity badly. Some are sick of the
>> packaging and portability challenges in Java EE, and are considering
>> other options.
>>
>> To his point we should be careful not to equate perceptions of low
>> OSGi use with users not wanting modularity.
>>
>> On 7/26/12 9:28 AM, Reza Rahman wrote:
>>> I can understand that this is something you feel strongly about, but
>>> kindly get a hold of yourself (and I know you can do better :-)). I do
>>> talk with everyone that I can about these issues as frequently as I can
>>> simply because I care (and have absolutely no personal stake in any of
>>> this). The reality that I see consistently matches up very closely with
>>> what Jevgeni is saying rather than what you are saying, sorry.
>>>
>>> On 7/26/2012 10:19 AM, Jeff Genender wrote:
>>>> Guys,
>>>>
>>>> I don't get the support for the marketing drivel. We all come from
>>>> different backgrounds. Be it Jboss modules, OSGI, roll your own, or
>>>> whatever. If you want data, go look at the Jboss modules, Geronimo
>>>> (Websphere CE), Glassfish, Equinox, Karaf, Felix user mailing lists
>>>> and the number of blogs on the subject. Go do your own count of
>>>> users... That's *not* marketing... Thats *not* anecdotal... That's our
>>>> users. That is who we represent. That's *real* data. guess what...
>>>> They *use* our designs. Let's please stop the BS at this point. This
>>>> is a dead horse. If you have something useful to contribute, please
>>>> do it...but let's stop the +1s on the loaded marketing material.
>>>>
>>>> Jeff
>>>> Sent from my iPhone
>>>>
>>>> On Jul 26, 2012, at 9:04 AM, Reza Rahman <reza_rahman_at_lycos.com
>>>> <mailto:reza_rahman_at_lycos.com>> wrote:
>>>>
>>>>> +1 (and I can guarantee that I'm a dispassionate observer on this one
>>>>> :-)).
>>>>>
>>>>> On 7/26/2012 8:23 AM, Jevgeni Kabanov wrote:
>>>>>> I'm glad we agree on the sentiment.
>>>>>>
>>>>>> The paper is NOT based on customer data. This was a community-wide
>>>>>> poll with 1450+ answers. It agrees with other larger polls, e.g. one
>>>>>> conducted by Eclipse. It certainly is not my side of the fence, it's
>>>>>> what the world looks like, at least in the outline.
>>>>>>
>>>>>> My point was that OSGi adoption is fairly low, and it's the
>>>>>> poster-boy of Java modularity story. Is there an actual need outside
>>>>>> the largest shops? Can we accommodate the largest shops in the spec
>>>>>> without impacting the majority of the community? These are important
>>>>>> questions that need answering before we commit to any one solution.
>>>>>>
>>>>>> JK
>>>>>>
>>>>>> --
>>>>>> Founder & CEO of ZeroTurnaround
>>>>>> @ekabanov | Skype: ekabanov | http://www.linkedin.com/in/ekabanov
>>>>>>
>>>>>> On Thursday, 26 July 2012 at 15:17, Jeff Genender wrote:
>>>>>>
>>>>>>> Jevgeni,
>>>>>>>
>>>>>>> I have to disagree vehemently with your fist comment. Your
>>>>>>> presentation of your paper is strawman. Your paper/analysis is from
>>>>>>> your customers which is your side of the fence. You have a small
>>>>>>> slice of a different sort of customer and your survey is directed
>>>>>>> at people who use JRebel and its likes which is anti OSGi in
>>>>>>> nature. Different strokes for different folks but I am certainly
>>>>>>> not calling yours anecdotal... just strawman. ;-)
>>>>>>>
>>>>>>> I wasn't stating OSGi is the end-all. But it does fit a need for
>>>>>>> what people want form what *I* see. People want the same thing
>>>>>>> with LiveRebel. The areas I listed is what LiveRebel helps to
>>>>>>> define as well.
>>>>>>>
>>>>>>> Hence, what you produce is exactly what I want and what your last
>>>>>>> statement pretty much summed up. We need something that allows
>>>>>>> someone to plug in whatever modular system for now, be it OSGi,
>>>>>>> JBoss Modules, or even LiveRebel. You stated exactly what I want
>>>>>>> to see.
>>>>>>>
>>>>>>> Jeff
>>>>>>>
>>>>>>>
>>>>>>> On Jul 26, 2012, at 6:57 AM, Jevgeni Kabanov wrote:
>>>>>>>
>>>>>>>> This all is very anecdotal. In our survey most folks did not
>>>>>>>> indicate that they use OSGi or anything like it:
>>>>>>>> http://files.zeroturnaround.com/developer-productivity-report/zeroturnaround-developer-productivity-report-2012.pdf
>>>>>>>>
>>>>>>>> (only a third are our customers, the rest just the folks across
>>>>>>>> the community that responded)
>>>>>>>>
>>>>>>>> There were also a bunch of open questions and although the no
>>>>>>>> downtime provisioning of application is a great concern, there
>>>>>>>> were fairly little issues with multiple library version. And
>>>>>>>> modularity without a good isolation model is not a way to solve
>>>>>>>> hot update or the class loading issues you mentioned.
>>>>>>>>
>>>>>>>> I'm afraid we're trying to solve the issues of the largest shops,
>>>>>>>> which are always more complex than the rest and probably do need a
>>>>>>>> custom solution built on OSGi or whatnot. And they already have
>>>>>>>> access to OSGi on the Glassfish, Websphere and so on.
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> JK
>>>>>>>>
>>>>>>>> --
>>>>>>>> Founder & CEO of ZeroTurnaround
>>>>>>>> @ekabanov | Skype: ekabanov | http://www.linkedin.com/in/ekabanov
>>>>>>>>
>>>>>>>> On Thursday, 26 July 2012 at 14:41, Jeff Genender wrote:
>>>>>>>>
>>>>>>>>> Hi Craig... thanks for the response and I darned well agree with
>>>>>>>>> a lot in this email ;-)
>>>>>>>>>
>>>>>>>>> answers in line...
>>>>>>>>>
>>>>>>>>> On Jul 25, 2012, at 7:30 PM, Craig Ringer wrote:
>>>>>>>>>
>>>>>>>>>> On 07/25/2012 09:53 PM, Jeff Genender wrote:
>>>>>>>>>>> In my world, I am seeing users pushing modularity in front of
>>>>>>>>>>> JavaEE and we are really missing this boat. A large section of
>>>>>>>>>>> my clients are moving to OSGi stacks picking and choosing what
>>>>>>>>>>> they want in their stacks, with some building their own JavaEE
>>>>>>>>>>> light containers (JTA, JPA).
>>>>>>>>>>
>>>>>>>>>> Can you explain in a bit more detail what problems they're
>>>>>>>>>> encountering that leave them forced to take this option?
>>>>>>>>>> Application and business problems, not just the common "we need
>>>>>>>>>> X because we've always used it" issues I see come up sometimes.
>>>>>>>>>
>>>>>>>>> Here are what I usually hear:
>>>>>>>>>
>>>>>>>>> 1) The comments made come along the line of the thick stack and
>>>>>>>>> having resources used by major components that aren't used.
>>>>>>>>> Complaint is EE-bloat.
>>>>>>>>> 2) Ability to hot deploy/undeploy without corrupting the
>>>>>>>>> classloaders. Example... try to deploy/deploy a war many times in
>>>>>>>>> a standard JavaEE container until an OutOf Memory exception
>>>>>>>>> occurs.
>>>>>>>>> 3) Ability to provision applications and services on the fly
>>>>>>>>> without having to reboot - think cloud-like Applications As A
>>>>>>>>> Service (AaaS).
>>>>>>>>> 4) Ability to prevent class clashing with multiple versions.
>>>>>>>>> Wanting to run multiple applications in the same container
>>>>>>>>> without worry for parent classloading corruption - the class tree
>>>>>>>>> classloading issues.
>>>>>>>>> 5) Dependent execution. The ability to run transitive
>>>>>>>>> dependencies on other applications/jars, much like a Unix inti.d
>>>>>>>>> or Windows services model. i.e. an application can;t run until
>>>>>>>>> its other dependent applications are running.
>>>>>>>>>
>>>>>>>>> OSGi seems to wor in this model, albeit with a great amount of
>>>>>>>>> pain.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Do you have people who really must swap out the JTA
>>>>>>>>>> implementation in a an app server with a different one in order
>>>>>>>>>> to meet business or application requirements? JPA I fully
>>>>>>>>>> understand, but JTA? I'm surprised and interested by that.
>>>>>>>>>
>>>>>>>>> Yes, many of my clients are interested in the Blueprint JTA
>>>>>>>>> implementation or use a local resource like Spring. Hence those
>>>>>>>>> who want to use Spring local transactions can rip out the JTA, or
>>>>>>>>> if they need XA, they wire up Aries/Blueprint and enable
>>>>>>>>> aries-transaction. I see this choice a lot.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I'm having very frustrating problems with the lack of
>>>>>>>>>> plugability of some of the upper layer stuff myself. Hibernate
>>>>>>>>>> is a very poor fit for the needs of an app I'm working on, but
>>>>>>>>>> getting EclipseLink to integrate well into AS7 is a major pain.
>>>>>>>>>> I appreciate the need for pluggability at least at the higher
>>>>>>>>>> levels of the stack, and it's been a major source of pain for me
>>>>>>>>>> since I started working with Java EE.
>>>>>>>>>>
>>>>>>>>>> My comments were specific to CDI and some low level, tightly
>>>>>>>>>> integrated components in the server like the EJB3
>>>>>>>>>> implementation, JTA, JCA, etc. These are tightly integrated and
>>>>>>>>>> - from what I've seen in AS7's sources and on the bug tracker -
>>>>>>>>>> the existing SPIs appear inadeaute to allow them to simply be
>>>>>>>>>> swapped out and replaced. I'd *love* to be wrong about this, but
>>>>>>>>>> my experience even trying to swap out theoretically pluggable
>>>>>>>>>> things like JPA implementations argues against it.
>>>>>>>>>>
>>>>>>>>>> I would like to see a certain baseline of infrastructure locked
>>>>>>>>>> in place as something thatthe app server does not have to
>>>>>>>>>> support replacing (it still may if it chooses). In exchange,
>>>>>>>>>> certain higher level components like JSF2, JPA2, maybe JAX-RS,
>>>>>>>>>> etc would *have* to support being swapped out with either
>>>>>>>>>> app-bundled implementations or modules installed in the app
>>>>>>>>>> server. This would give vendors realistic test targets and
>>>>>>>>>> narrow the number of configurations to something (almost)
>>>>>>>>>> testable. It would also make it clearer which specs need really
>>>>>>>>>> complete SPIs as a priority.
>>>>>>>>>>
>>>>>>>>>> As for needing a module system: I could not possibly agree more,
>>>>>>>>>> and think that things like CDI *should* be modules within the
>>>>>>>>>> app server - for app server maintainability and good design.
>>>>>>>>>> Sure enough you'll see that all the low level components in AS7
>>>>>>>>>> are modules. I just don't think the spec should require the
>>>>>>>>>> server vendor to support applications swapping out arbitrary
>>>>>>>>>> modules; that needs to be confined to modules implementing specs
>>>>>>>>>> where there's a good enough SPI.
>>>>>>>>>>
>>>>>>>>>> The trouble with the module system issue is that JBoss modules
>>>>>>>>>> is probably a bit too basic, and OSGi is (IMO) convoluted and
>>>>>>>>>> horrible to work with. There isn't a really good candidate.
>>>>>>>>>
>>>>>>>>> I completely agree with you... but I am just concerned we are
>>>>>>>>> going to miss the boat if we keep putting this off. ;-)
>>>>>>>>>
>>>>>>>>> Jeff
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Craig Ringer
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> No virus found in this message.
>>>>>> Checked by AVG - www.avg.com <http://www.avg.com>
>>>>>> Version: 2012.0.2171 / Virus Database: 2437/5147 - Release Date:
>>>>>> 07/22/12
>>>>>>
>>>>>
>>>>>
>>>> No virus found in this message.
>>>> Checked by AVG - www.avg.com <http://www.avg.com>
>>>> Version: 2012.0.2171 / Virus Database: 2437/5156 - Release Date:
>>>> 07/26/12
>>>>
>>>
>>>
>>
>>
>
>


-- 
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat