+1.
On 7/26/2012 7: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
>