You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@anyware-tech.com> on 2005/01/04 11:46:13 UTC
Using the standard Jaxp parser in Cocoon.java
Hi all,
Doing some cleanup on the component management, I went into o.a.c.Cocoon
where a bootstrap service manager is created and setup only to handle
the case where the user would like to use parser different from the
default system-wide one. This alternate parser is specified using the
"org.apache.excalibur.xml.sax.SAXParser" system property.
This looks to me like some old legacy code that was written before JAXP
was finalized and before XML parsers were shipped with the JDK.
I'd like to remove this as it seems IMO useless and complicates the
startup code.
Thoughts? Is anyone having a good use case for this feature?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Using the standard Jaxp parser in Cocoon.java
Posted by Stefano Mazzocchi <st...@apache.org>.
Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
>
>> Hi all,
>>
>> Doing some cleanup on the component management, I went into
>> o.a.c.Cocoon where a bootstrap service manager is created and setup
>> only to handle the case where the user would like to use parser
>> different from the default system-wide one. This alternate parser is
>> specified using the "org.apache.excalibur.xml.sax.SAXParser" system
>> property.
>>
>> This looks to me like some old legacy code that was written before
>> JAXP was finalized and before XML parsers were shipped with the JDK.
>>
>> I'd like to remove this as it seems IMO useless and complicates the
>> startup code.
>>
>> Thoughts? Is anyone having a good use case for this feature?
>>
> Believe it or not, I had exactly the same idea today as I looked at
> the Cocoon class...so +1 for removing.
+1 as well
--
Stefano.
Re: Using the standard Jaxp parser in Cocoon.java
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Upayavira wrote:
> Carsten Ziegeler wrote:
<snip/>
>> Exactly - and we should try to make sense out of our version numbers
>> especially wrt compatibility.
>
>
> I think we should be keeping 2.1.X as stable as possible, and be
> tidying trunk.
Agree
> We therefore need to be thinking about how to get trunk released
> within a reasonable time (6 months?),
Or sooner. What about setting a strict release date within 3 months and
release what we actually have succeeded implementing, rather than wait
untill all our dreams are fullfilled?
> and therefore be prepared to delay some features until 2.3 if their
> development is going to take too long.
Exactly
> After all, 2.1.X is a _maintenance_ branch, but that doesn't seem too
> much like how we're using it - we're adding stuff to it that should go
> in 2.2, only because we don't know when 2.2 will be out, we're not
> happy to just have it there.
We tried this for 2.0 -> 2.1 and I don't think anybody was happy with
the result, i.e. having to either not using the new cool stuff or
running production sites on based on alpha versions for maybe a year.
---o0o---
Is there a list on what incompabillities 2.2 introduces, so that we can
evaluate the consequences of uppgrading?
There is a list on what 2.2 should include
http://wiki.apache.org/cocoon/22Planning. Although it would be nice to
have all that, I think that the Cocoon ECM is reason enough for us to
release a 2.2.
When is Cocoon ECM ready for prime time?
For the Template refactoring, it really is a refactoring, so the idea is
that it should continue to work as before at all times. So we should in
principle be able to switch to it any time. Now having said that I would
like to do some more refactoring steps, write some documentation and
write some more test cases (please help me adding test cases), before I
start a vote about switching. But it should certainly be ready for 2.2.
/Daniel
Re: Pushing 2.2 (was Re: Using the standard Jaxp parser in Cocoon.java)
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
>
>>
>> Good analysis. The problem is that trunk has not (or had not before
>> include) enough distinguishing features to make it really appealing
>> compared to 2.1. And it therefore doesn't urge us to release it,
>> leading new features to be added to 2.1 also as we need them on
>> production systems. Chicken and egg...
>>
>> So raising the demand for 2.2 may simply be a matter for us
>> developpers to add new features only on 2.2 and use it more on
>> realworld projects. That will urge us to officially release it before
>> our projects go into production.
>>
> My personal opinion is that we just need these virtual components
> and then have the final 2.2 (apart from polishing).
+ stable cForms and I'm fine with a 2.2 release too
Everything else
> can go into 2.3.
yep, especially real blocks need some more time :-(
--
Reinhard
Re: Pushing 2.2 (was Re: Using the standard Jaxp parser in Cocoon.java)
Posted by Ralph Goers <Ra...@dslextreme.com>.
Carsten Ziegeler wrote:
> My personal opinion is that we just need these virtual components
> and then have the final 2.2 (apart from polishing). Everything else
> can go into 2.3.
My perception has been that 2.2 was waiting for "real blocks". However,
I believe Sylvain is right. The include feature gets us along that path
far enough for now to make releasing soon desirable.
Ralph
Re: Pushing 2.2 (was Re: Using the standard Jaxp parser in Cocoon.java)
Posted by Stefano Mazzocchi <st...@apache.org>.
Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
>
>>
>> Good analysis. The problem is that trunk has not (or had not before
>> include) enough distinguishing features to make it really appealing
>> compared to 2.1. And it therefore doesn't urge us to release it,
>> leading new features to be added to 2.1 also as we need them on
>> production systems. Chicken and egg...
>>
>> So raising the demand for 2.2 may simply be a matter for us
>> developpers to add new features only on 2.2 and use it more on
>> realworld projects. That will urge us to officially release it before
>> our projects go into production.
>>
> My personal opinion is that we just need these virtual components
> and then have the final 2.2 (apart from polishing). Everything else
> can go into 2.3.
Very much agreed! Release early and often.
--
Stefano.
Re: Pushing 2.2 (was Re: Using the standard Jaxp parser in Cocoon.java)
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
>
> Good analysis. The problem is that trunk has not (or had not before
> include) enough distinguishing features to make it really appealing
> compared to 2.1. And it therefore doesn't urge us to release it, leading
> new features to be added to 2.1 also as we need them on production
> systems. Chicken and egg...
>
> So raising the demand for 2.2 may simply be a matter for us developpers
> to add new features only on 2.2 and use it more on realworld projects.
> That will urge us to officially release it before our projects go into
> production.
>
My personal opinion is that we just need these virtual components
and then have the final 2.2 (apart from polishing). Everything else
can go into 2.3.
Carsten
Pushing 2.2 (was Re: Using the standard Jaxp parser in Cocoon.java)
Posted by Sylvain Wallez <sy...@apache.org>.
Upayavira wrote:
> Carsten Ziegeler wrote:
>
>> Upayavira wrote:
>>
>>> Antonio Gallardo wrote:
>>>
>>
>>>>
>>>> If 2.1 will work without this "feature" => please remove it.
>>>> Cleaning the
>>>> house is good. ;-)
>>>>
>>>>
>>> As is leaving things alone so you don't take the risk of breaking
>>> things :-)
>>>
>> Exactly - and we should try to make sense out of our version numbers
>> especially wrt compatibility.
>
>
> I think we should be keeping 2.1.X as stable as possible, and be
> tidying trunk.
+1
> We therefore need to be thinking about how to get trunk released
> within a reasonable time (6 months?), and therefore be prepared to
> delay some features until 2.3 if their development is going to take
> too long.
+1 also. I think the include feature in xconf will make the pressure to
release 2.2 higher ;-)
> After all, 2.1.X is a _maintenance_ branch, but that doesn't seem too
> much like how we're using it - we're adding stuff to it that should go
> in 2.2, only because we don't know when 2.2 will be out, we're not
> happy to just have it there.
Good analysis. The problem is that trunk has not (or had not before
include) enough distinguishing features to make it really appealing
compared to 2.1. And it therefore doesn't urge us to release it, leading
new features to be added to 2.1 also as we need them on production
systems. Chicken and egg...
So raising the demand for 2.2 may simply be a matter for us developpers
to add new features only on 2.2 and use it more on realworld projects.
That will urge us to officially release it before our projects go into
production.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Using the standard Jaxp parser in Cocoon.java
Posted by Upayavira <uv...@upaya.co.uk>.
Carsten Ziegeler wrote:
> Upayavira wrote:
>
>> Antonio Gallardo wrote:
>>
>
>>>
>>> If 2.1 will work without this "feature" => please remove it.
>>> Cleaning the
>>> house is good. ;-)
>>>
>>>
>> As is leaving things alone so you don't take the risk of breaking
>> things :-)
>>
> Exactly - and we should try to make sense out of our version numbers
> especially wrt compatibility.
I think we should be keeping 2.1.X as stable as possible, and be tidying
trunk.
We therefore need to be thinking about how to get trunk released within
a reasonable time (6 months?), and therefore be prepared to delay some
features until 2.3 if their development is going to take too long.
After all, 2.1.X is a _maintenance_ branch, but that doesn't seem too
much like how we're using it - we're adding stuff to it that should go
in 2.2, only because we don't know when 2.2 will be out, we're not happy
to just have it there.
Regards, Upayavira
Regards, Upayavira
Re: Using the standard Jaxp parser in Cocoon.java
Posted by Carsten Ziegeler <cz...@apache.org>.
Upayavira wrote:
> Antonio Gallardo wrote:
>
>>
>> If 2.1 will work without this "feature" => please remove it. Cleaning the
>> house is good. ;-)
>>
>>
> As is leaving things alone so you don't take the risk of breaking things
> :-)
>
Exactly - and we should try to make sense out of our version numbers
especially wrt compatibility.
Carsten
Re: Using the standard Jaxp parser in Cocoon.java
Posted by Upayavira <uv...@upaya.co.uk>.
Antonio Gallardo wrote:
>On Mar, 4 de Enero de 2005, 9:03, Sylvain Wallez dijo:
>
>
>>Carsten Ziegeler wrote:
>>
>>
>>
>>>Sylvain Wallez wrote:
>>>
>>>
>>>
>>>>I changed it (just to check -- not committed yet) in 2.2, but I see
>>>>no reason why it shouldn't work with 1.3 when a JAXP implementation
>>>>exists in the classpath. And Cocoon does provide one implemenation
>>>>with Xerces.
>>>>
>>>>
>>>Just to be sure, I see no reason why we should change this in 2.1.x.
>>>
>>>
>>I see no reason why it could be more useful in 2.1 than in 2.2, but
>>well, let's keep it in 2.1 ;-)
>>
>>
>
>If 2.1 will work without this "feature" => please remove it. Cleaning the
>house is good. ;-)
>
>
As is leaving things alone so you don't take the risk of breaking things :-)
Upayavira
Re: Using the standard Jaxp parser in Cocoon.java
Posted by Antonio Gallardo <ag...@agssa.net>.
On Mar, 4 de Enero de 2005, 9:03, Sylvain Wallez dijo:
> Carsten Ziegeler wrote:
>
>> Sylvain Wallez wrote:
>>
>>> I changed it (just to check -- not committed yet) in 2.2, but I see
>>> no reason why it shouldn't work with 1.3 when a JAXP implementation
>>> exists in the classpath. And Cocoon does provide one implemenation
>>> with Xerces.
>>
>> Just to be sure, I see no reason why we should change this in 2.1.x.
>
>
> I see no reason why it could be more useful in 2.1 than in 2.2, but
> well, let's keep it in 2.1 ;-)
If 2.1 will work without this "feature" => please remove it. Cleaning the
house is good. ;-)
Best Regards,
Antonio Gallardo
Re: Using the standard Jaxp parser in Cocoon.java
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
>
>> I changed it (just to check -- not committed yet) in 2.2, but I see
>> no reason why it shouldn't work with 1.3 when a JAXP implementation
>> exists in the classpath. And Cocoon does provide one implemenation
>> with Xerces.
>
> Just to be sure, I see no reason why we should change this in 2.1.x.
I see no reason why it could be more useful in 2.1 than in 2.2, but
well, let's keep it in 2.1 ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Using the standard Jaxp parser in Cocoon.java
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
>
> I changed it (just to check -- not committed yet) in 2.2, but I see no
> reason why it shouldn't work with 1.3 when a JAXP implementation
> exists in the classpath. And Cocoon does provide one implemenation
> with Xerces.
>
Just to be sure, I see no reason why we should change this in 2.1.x.
Carsten
Re: Using the standard Jaxp parser in Cocoon.java
Posted by Upayavira <uv...@upaya.co.uk>.
Sylvain Wallez wrote:
> Upayavira wrote:
>
>> Carsten Ziegeler wrote:
>>
>>> Sylvain Wallez wrote:
>>>
>>>> Hi all,
>>>>
>>>> Doing some cleanup on the component management, I went into
>>>> o.a.c.Cocoon where a bootstrap service manager is created and setup
>>>> only to handle the case where the user would like to use parser
>>>> different from the default system-wide one. This alternate parser
>>>> is specified using the "org.apache.excalibur.xml.sax.SAXParser"
>>>> system property.
>>>>
>>>> This looks to me like some old legacy code that was written before
>>>> JAXP was finalized and before XML parsers were shipped with the JDK.
>>>>
>>>> I'd like to remove this as it seems IMO useless and complicates the
>>>> startup code.
>>>>
>>>> Thoughts? Is anyone having a good use case for this feature?
>>>>
>>> Believe it or not, I had exactly the same idea today as I looked at
>>> the Cocoon class...so +1 for removing.
>>
>>
>>
>> Will this work on Java 1.3? Or are you just talking about Cocoon 2.2?
>
>
>
> I changed it (just to check -- not committed yet) in 2.2, but I see no
> reason why it shouldn't work with 1.3 when a JAXP implementation
> exists in the classpath. And Cocoon does provide one implemenation
> with Xerces.
+1 then!
Regards, Upayavira
Re: Using the standard Jaxp parser in Cocoon.java
Posted by Sylvain Wallez <sy...@apache.org>.
Upayavira wrote:
> Carsten Ziegeler wrote:
>
>> Sylvain Wallez wrote:
>>
>>> Hi all,
>>>
>>> Doing some cleanup on the component management, I went into
>>> o.a.c.Cocoon where a bootstrap service manager is created and setup
>>> only to handle the case where the user would like to use parser
>>> different from the default system-wide one. This alternate parser is
>>> specified using the "org.apache.excalibur.xml.sax.SAXParser" system
>>> property.
>>>
>>> This looks to me like some old legacy code that was written before
>>> JAXP was finalized and before XML parsers were shipped with the JDK.
>>>
>>> I'd like to remove this as it seems IMO useless and complicates the
>>> startup code.
>>>
>>> Thoughts? Is anyone having a good use case for this feature?
>>>
>> Believe it or not, I had exactly the same idea today as I looked at
>> the Cocoon class...so +1 for removing.
>
>
> Will this work on Java 1.3? Or are you just talking about Cocoon 2.2?
I changed it (just to check -- not committed yet) in 2.2, but I see no
reason why it shouldn't work with 1.3 when a JAXP implementation exists
in the classpath. And Cocoon does provide one implemenation with Xerces.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Using the standard Jaxp parser in Cocoon.java
Posted by Upayavira <uv...@upaya.co.uk>.
Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
>
>> Hi all,
>>
>> Doing some cleanup on the component management, I went into
>> o.a.c.Cocoon where a bootstrap service manager is created and setup
>> only to handle the case where the user would like to use parser
>> different from the default system-wide one. This alternate parser is
>> specified using the "org.apache.excalibur.xml.sax.SAXParser" system
>> property.
>>
>> This looks to me like some old legacy code that was written before
>> JAXP was finalized and before XML parsers were shipped with the JDK.
>>
>> I'd like to remove this as it seems IMO useless and complicates the
>> startup code.
>>
>> Thoughts? Is anyone having a good use case for this feature?
>>
> Believe it or not, I had exactly the same idea today as I looked at
> the Cocoon class...so +1 for removing.
Will this work on Java 1.3? Or are you just talking about Cocoon 2.2?
Regards, Upayavira
Re: Using the standard Jaxp parser in Cocoon.java
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
> Hi all,
>
> Doing some cleanup on the component management, I went into o.a.c.Cocoon
> where a bootstrap service manager is created and setup only to handle
> the case where the user would like to use parser different from the
> default system-wide one. This alternate parser is specified using the
> "org.apache.excalibur.xml.sax.SAXParser" system property.
>
> This looks to me like some old legacy code that was written before JAXP
> was finalized and before XML parsers were shipped with the JDK.
>
> I'd like to remove this as it seems IMO useless and complicates the
> startup code.
>
> Thoughts? Is anyone having a good use case for this feature?
>
Believe it or not, I had exactly the same idea today as I looked at
the Cocoon class...so +1 for removing.
Carsten