You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@s-und-n.de> on 2003/03/13 09:27:19 UTC
Minimal JDK Version for 2.1
We discussed this topic several times, so I think we can
come to a conclusion now.
Currently, we have JDK 1.2 as a minimal requirement for 2.1,
but afaik the avalon framework requires JDK 1.3 anyway and
the poll started recently showed, that most are using
1.3 or 1.4.
And 2.1 is a new minor version.
So, is anyone against changing from 1.2 to 1.3? If not,
I will change the docs etc. tomorrow.
Carsten
Carsten Ziegeler
Open Source Group, S&N AG
Re: Minimal JDK Version for 2.1
Posted by Stefano Mazzocchi <st...@apache.org>.
Torsten Curdt wrote:
> Carsten Ziegeler wrote:
>
>> We discussed this topic several times, so I think we can
>> come to a conclusion now.
>> Currently, we have JDK 1.2 as a minimal requirement for 2.1,
>> but afaik the avalon framework requires JDK 1.3 anyway and
>> the poll started recently showed, that most are using
>> 1.3 or 1.4.
>> And 2.1 is a new minor version.
>>
>> So, is anyone against changing from 1.2 to 1.3? If not,
>> I will change the docs etc. tomorrow.
>
>
> I'd say go ahead +1
Since it seems that even FreeBSD has a working 1.3 implementation of the
JVM, I'd go +1 on this. This will sure allow us to use Proxies, which
are a good thing.
Stefano.
Re: Minimal JDK Version for 2.1
Posted by Torsten Curdt <tc...@dff.st>.
Carsten Ziegeler wrote:
> We discussed this topic several times, so I think we can
> come to a conclusion now.
> Currently, we have JDK 1.2 as a minimal requirement for 2.1,
> but afaik the avalon framework requires JDK 1.3 anyway and
> the poll started recently showed, that most are using
> 1.3 or 1.4.
> And 2.1 is a new minor version.
>
> So, is anyone against changing from 1.2 to 1.3? If not,
> I will change the docs etc. tomorrow.
I'd say go ahead +1
--
Torsten
RE: Minimal JDK Version for 2.1
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Marcus Crafter wrote:
> > >
> > Personally, I don't see a real problem with this. If we use a
> new container,
> > we change the inheritance from ECM to whatever container we use.
>
> Well, I know we don't change container implementations all that
> often :) so perhaps this is a bit academic - but this was
> what I was
> hoping to avoid. It could also be that the inheritance method
> currently used now is not possible with a future container.
>
Yes, that's possible.
>
> > We could also implement a delegation to the real container, but I don't
> > see a real need for this as changing the container implementation
> > is due to different feature sets not possible.
>
> Delegation would be good - then we'd be operating through the
> ComponentManager (or ServiceManager or similar) interface right ?
>
Hmm, yes ServiceManager I guess.
> Not sure if I fully understand your last sentence though mate - do
> mean it's not possible to change containers in Cocoon at all due
> to some other reasons ?
>
Yes, that's my perception of the different container implementations. I'm
not sure if I'm mistaken, but I think, after long discussions in Avalon,
there was the agreement that it doesn't make sense to have different
container implementations with the same feature set. So if you have
different containers, you have different features. (One container
implementation is a superset of another one).
So, Cocoon will rely on a distinct set of features. Then you can't
use an implementation with less features of course. And as we here in
Cocoon tend to use everything available, we will choose the container
will the most features anyway :)
This is only my understanding of the different container implementations,
perhaps I'm wrong.
Cheers
Carsten
Re: Minimal JDK Version for 2.1
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
Hi Carsten!
On Thu, Mar 13, 2003 at 02:33:41PM +0100, Carsten Ziegeler wrote:
> Marcus Crafter wrote:
> >
> > BTW - I was just about to email you a question regarding
> > CocoonComponentManager.
> >
> > The current version extends from ECM, which hardcodes us to
> > that container implementation - do you think it's possible to find
> > another way so we can alleviate this restriction (making it
> > easier to
> > move between containers when the time comes) ?
> >
> Personally, I don't see a real problem with this. If we use a new container,
> we change the inheritance from ECM to whatever container we use.
Well, I know we don't change container implementations all that
often :) so perhaps this is a bit academic - but this was what I was
hoping to avoid. It could also be that the inheritance method
currently used now is not possible with a future container.
> We could also implement a delegation to the real container, but I don't
> see a real need for this as changing the container implementation
> is due to different feature sets not possible.
Delegation would be good - then we'd be operating through the
ComponentManager (or ServiceManager or similar) interface right ?
Not sure if I fully understand your last sentence though mate - do
mean it's not possible to change containers in Cocoon at all due
to some other reasons ?
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
Re: Minimal JDK Version for 2.1
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
On Thu, Mar 13, 2003 at 01:35:41PM +0100, Nicola Ken Barozzi wrote:
>
> Marcus Crafter wrote, On 13/03/2003 12.12:
> ...
> > BTW - I was just about to email you a question regarding
> > CocoonComponentManager.
> >
> > The current version extends from ECM, which hardcodes us to
> > that container implementation - do you think it's possible to find
> > another way so we can alleviate this restriction (making it easier to
> > move between containers when the time comes) ?
> >
> > Any thoughts ?
>
> I thought the same thing recently. You see, I would like to see Fortress
> used now. CocoonComponentManager should use other containers instead of
> extending them, no? It would be quite easy to do it seems.
Yes, I'd like to do some container experimentation too - hence the
thought of reducing some of these dependancies.
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
Re: Minimal JDK Version for 2.1
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Marcus Crafter wrote, On 13/03/2003 12.12:
...
> BTW - I was just about to email you a question regarding
> CocoonComponentManager.
>
> The current version extends from ECM, which hardcodes us to
> that container implementation - do you think it's possible to find
> another way so we can alleviate this restriction (making it easier to
> move between containers when the time comes) ?
>
> Any thoughts ?
I thought the same thing recently. You see, I would like to see Fortress
used now. CocoonComponentManager should use other containers instead of
extending them, no? It would be quite easy to do it seems.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
RE: Minimal JDK Version for 2.1
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Marcus Crafter wrote:
>
> BTW - I was just about to email you a question regarding
> CocoonComponentManager.
>
> The current version extends from ECM, which hardcodes us to
> that container implementation - do you think it's possible to find
> another way so we can alleviate this restriction (making it
> easier to
> move between containers when the time comes) ?
>
Personally, I don't see a real problem with this. If we use a new container,
we change the inheritance from ECM to whatever container we use.
We could also implement a delegation to the real container, but I don't
see a real need for this as changing the container implementation
is due to different feature sets not possible.
Carsten
Re: Minimal JDK Version for 2.1
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
On Thu, Mar 13, 2003 at 12:02:55PM +0100, Carsten Ziegeler wrote:
> > I think it's the Excalibur component subproject that requires 1.3
> > now due to the use of Proxy classes inside of ECM.
> >
> Ah, yes, sorry - you're right. It's excalibur not the framework.
No problem mate - wasn't 100% sure myself :)
BTW - I was just about to email you a question regarding
CocoonComponentManager.
The current version extends from ECM, which hardcodes us to
that container implementation - do you think it's possible to find
another way so we can alleviate this restriction (making it easier to
move between containers when the time comes) ?
Any thoughts ?
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
RE: Minimal JDK Version for 2.1
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Marcus Crafter wrote:
>
> Hi Carsten!
>
> On Thu, Mar 13, 2003 at 09:27:19AM +0100, Carsten Ziegeler wrote:
> > We discussed this topic several times, so I think we can
> > come to a conclusion now.
> > Currently, we have JDK 1.2 as a minimal requirement for 2.1,
> > but afaik the avalon framework requires JDK 1.3 anyway and
> > the poll started recently showed, that most are using
> > 1.3 or 1.4.
> > And 2.1 is a new minor version.
>
> I think it's the Excalibur component subproject that requires 1.3
> now due to the use of Proxy classes inside of ECM.
>
Ah, yes, sorry - you're right. It's excalibur not the framework.
Thanks
Carsten
Re: Minimal JDK Version for 2.1
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
Hi Carsten!
On Thu, Mar 13, 2003 at 09:27:19AM +0100, Carsten Ziegeler wrote:
> We discussed this topic several times, so I think we can
> come to a conclusion now.
> Currently, we have JDK 1.2 as a minimal requirement for 2.1,
> but afaik the avalon framework requires JDK 1.3 anyway and
> the poll started recently showed, that most are using
> 1.3 or 1.4.
> And 2.1 is a new minor version.
I think it's the Excalibur component subproject that requires 1.3
now due to the use of Proxy classes inside of ECM.
> So, is anyone against changing from 1.2 to 1.3? If not,
> I will change the docs etc. tomorrow.
+1 for 1.3.
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&: