Hi,
I might not follow this down to the technical challenges of the
app-server developer I just did not want to be misinterpreted with my
view.
In my view the plugability aspect should be taken into account for the
higher level components only from a specification point of view.
Honestly I have never seen somebody replacing JTA or more low-level
components. And I believe that these are rare product requirements.
The higher level components on the other hand give the impression of
being interchangeable. At least to me.
Especially with JPA and JSF where we actually have at least two or
more very active and competing alternatives. Further on I do want to
be able
to upgrade at least patch versions on my own (e.g. bcause of bugfixes
... weld, jsf .. GlassFish starts to become usable with 3.1.2.2 ...
component updates
still only with server releases ....)
It seems as if there are basically two approaches to this:
1) Define a general modularization and plugability concept for EE as a whole
2) define a decent set of SPIs or a framework for the RI's to
implement and follow that.
The first sounds very complete and expensive in any way. And Craig
might be right regarding the implications.
The second sounds more doable to me but would additionally force the
relevant RIs to not only follow the SPI but also find a good
and save way of providing extensions.
I haven't had the requirement of zero-downtime or rolling updates to
those modules. The simple possibility to exchange single
implementations at a given point in time would be far than enough. So
this might be about defining the components which need to be
interchangeable and find a solution for them.
I also agree that a "certain baseline of infrastructure [has to be]
locked in place".
-M
On 26 July 2012 13:41, Jeff Genender <jgenender_at_savoirtech.com> 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
>