+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
>