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.
-Mike
On 26/07/2012 8:29 AM, Jeff Genender wrote:
> comments in line...
>
> On Jul 26, 2012, at 7: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.
>
> Well lets agree to disagree... it was pushed from the marketing side
> and it certainly hit a large part of who is in the CRM database... but
> this is moot and we can leave it at that.
>
>>
>> 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.
>
> 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).
>
> 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
>>>>
>>>
>>
>