avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [heads-up] The version of ECM in CVS has a change in JDK reqs
Date Mon, 30 Sep 2002 13:39:23 GMT
Leo Sutic wrote:
> 
>>From: Berin Loritsch [mailto:bloritsch@apache.org] 
>>
>>Leo Sutic wrote:
>>
>>>In theory, if a container is 100% A4 compliant, it should 
>>
>>remain so for 
>>
>>>all future
>>>versions of A4, in the same way that a component, once 
>>
>>having achieved 
>>
>>>100% A4 status,
>>>will remain so until A5.
>>
>>
>>ECM has been made A4.1 compliant.  A4.1 is *released*.
> 
> 
> I'm fully aware of that. But my point is that instead of having
> just Avalon 4, we have Avalon 4.0, Avalon 4.1, and we'll have Avalon
> 4.2,
> and the frameworks will be sufficiently different that a container
> written
> for Avalon 4.0 will not be completely Avalon 4.1 compliant.
>  
> That's fine, if you can committ resources to playing catch-up with an
> evolving standard, but the whole point of a framework is that you should
> not *have* to play catch-up.

If the container is upgraded to be 4.1 compliant, you can still use
your legacy code.  Is that a problem?  That way the user does not have
to play catch-up.  They can do it a little bit at a time.


> Now I'm all for evolving specifications, but it is a fact that the
> framework that claims to be most fundamental for everything (i.e. you
> would
> use Avalon to build an EJB server), is also the framework that has
> changed
> the most, and that has consumed most of my catch-up resources.

Really.  You think Avalon Framework has changed *that* much?  If I am
not mistaken, EJB specs have changed a bit too--probably more so than
Avalon 4.x.

> That is my problem and not yours - but to dismiss the problem with a
> "A4.1 is *released*" is just not right. It assumes that once the gods at
> avalon-dev releases a new version, the rest of the world had better
> keep up or they will, can and should be left behind.

No my point is that because Avalon 4.1 is released we need to support
it.


>>>The Seviceable interface messes all that up.
>>>
>>>It is possible for a container to be Avalon 4.0 compliant, but not 
>>>Avalon 4.1
>>>compliant.
>>>
>>>I consider this a problem.
>>>
>>>What to do:
>>>
>>> + ECM remains JDK1.2 compatible. Look, the damn thing is 
>>
>>legacy legacy 
>>
>>>legacy.
>>>   It works fine, but I'd rather have it remain A4.0 
>>
>>instead of trying 
>>
>>>to mutate
>>>   it to A4.1, unless that mutation can be done without JDK1.3. 
>>>Branching is
>>>   another possiblity. Under JDK1.2, the lookup of a non-Component 
>>>implementing
>>>   component would throw a ComponentException, under 1.3 it 
>>
>>would be solved
>>
>>>   via the proxy generator.
>>
>>
>>Why JDK 1.2?  When there wasn't a 1.3+ for certain platforms it made
>>sense.
> 
> 
> As long as Cocoon promises to run on JDK1.2, we have to support it.

Oh, I see.  However, you're the only one from Cocoon complaining.  In
fact, quite a few of the Cocooner's are in favor of upgrading their
minimum JDK standard--and they need a good reason to do it.  We solved
their problem for them.

Also note that it is the ECM in CVS, which means that they would have
to make that change for a *future* version of Cocoon.  A JDK change for
Cocoon isn't as harsh as just ripping out the old 4.0 deprecated code.

>>>I think this solves Cocoon's problems.
>>
>>
>>Not everyones.
> 
> 
> I don't get your point.


There are many Cocooner's who *want* to upgrade the minumum JVM because
they are feeling the restrictions of JDK 1.2--and how 1.3 makes their
lives easier.


>>>Random thought: With the Proxy generator Berin put in the 
>>
>>ECM, doesn't 
>>
>>>the whole
>>>need for Serviceable disappear?
>>
>>
>>Random thought: If we are trying to divorce ourselves from the need of
>>the Component interface (i.e. migrate to Serviceable) doesn't the need
>>for the ProxyGenerator dissapear?  The trend should be simplification,
>>not making things more complex.  Any complexity should have a reason.
> 
> 
> That depends on how you define compatibility between Avalon versions,
> what you prioritize, etc.
> 
> *Can* we remove loads and loads of cruft from Avalon? Sure.
> 
> *Should* we remove loads and loads of cruft from Avalon? Not so sure,
> since
> we have to consider compatibility.


We are trying to *ease* the transition.  In order to do it effectively,
we need to use JDK 1.3--unless you want to write a dynamic proxy
generator using BCEL.  That would make ECM able to stay with 1.2--but at
what cost?


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message