+1. The way it appears to me (and to Caucho/the Resin team) the "larger"
Java EE vendors seem to be touting general modularity mostly for their
own reasons more than anything else...
On 7/26/2012 8:41 AM, Jevgeni Kabanov wrote:
>>> 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.
>> I will disagree here once again. OSGi/modularity is certainly not
>> low. There is a reason many major JavaEE app vendors are
>> implementing some for of modularity of their own... and THAT is the
>> point. We represent JavaEE EG and since we are all rolling our own
>> modular implementations, its clear that its something the community
>> wants and its something we need to address, period.
> You can disagree all you want, without data it's just an opinion.
> We're not arguing on technical merits here, we're discussing if the
> market needs/is ready for the solution discussed in the thread. My
> hypotheses supported both anecdotally and by data is that it's a minor
> part of the market with largest complexity of deployment.
>
> JavaEE app vendors implement OSGi because a) it helps them to manage
> their own dependencies and b) their largest customers want it. This
> does not counter with anything I said.
>>
>> Again, I want to make extremely clear Im not saying we commit to
>> *one* solution, and I am saying quite the contrary. I am saying get
>> something that allows us to bridge to whatever until we can commit to
>> something that is built in (Jigsaw).
> I'm not even sure what we're arguing about. My point is just that in
> the complexity trade-off let's not impose more complexity on the
> larger ecosystem just because a minority wants it.
>>
>> Jeff
>>
>>
>>> 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
>