You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@cocoon.apache.org by sy...@apache.org on 2002/02/06 22:09:22 UTC
cvs commit: xml-cocoon2/src/java/org/apache/cocoon/sitemap DefaultSitemapComponentSelector.java
sylvain 02/02/06 13:09:22
Added: src/java/org/apache/cocoon/sitemap
DefaultSitemapComponentSelector.java
Log:
Oops, forgot to add the new file :/
Revision Changes Path
1.1 xml-cocoon2/src/java/org/apache/cocoon/sitemap/DefaultSitemapComponentSelector.java
Index: DefaultSitemapComponentSelector.java
===================================================================
/*
* The Apache Software License, Version 1.1
*
*
* Copyright (c) 2001 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in
* the documentation and/or other materials provided with the
* distribution.
*
* 3. The end-user documentation included with the redistribution,
* if any, must include the following acknowledgment:
* "This product includes software developed by the
* Apache Software Foundation (http://www.apache.org/)."
* Alternately, this acknowledgment may appear in the software itself,
* if and wherever such third-party acknowledgments normally appear.
*
* 4. The names "Apache Cocoon" and "Apache Software Foundation" must
* not be used to endorse or promote products derived from this
* software without prior written permission. For written
* permission, please contact apache@apache.org.
*
* 5. Products derived from this software may not be called "Apache",
* nor may "Apache" appear in their name, without prior written
* permission of the Apache Software Foundation.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
* ====================================================================
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* <http://www.apache.org/>.
*/
package org.apache.cocoon.sitemap;
import org.apache.avalon.excalibur.component.ExcaliburComponentSelector;
import org.apache.avalon.framework.component.Component;
import org.apache.avalon.framework.component.ComponentException;
import org.apache.avalon.framework.configuration.Configuration;
import org.apache.avalon.framework.configuration.ConfigurationException;
import java.util.Collections;
import java.util.HashMap;
import java.util.Map;
import java.util.ArrayList;
import java.util.StringTokenizer;
/**
* Default component manager for Cocoon's sitemap components.
*
* @author <a href="mailto:bloritsch@apache.org">Berin Loritsch</a>
* @author <a href="mailto:giacomo@apache.org">Giacomo Pati</a>
* @version CVS $Id: DefaultSitemapComponentSelector.java,v 1.1 2002/02/06 21:09:22 sylvain Exp $
*/
public class DefaultSitemapComponentSelector extends ExcaliburComponentSelector
implements SitemapComponentSelector {
private Map hintLabels;
private Map mime_types;
private SitemapComponentSelector parentSelector;
/** Dynamic component handlers mapping. */
private Map componentMapping;
/** The conctructors (same as the Avalon ComponentManager)
*/
public DefaultSitemapComponentSelector() {
super();
this.hintLabels = new HashMap();
this.mime_types = new HashMap();
componentMapping = Collections.synchronizedMap(new HashMap());
}
public void setParentSelector(SitemapComponentSelector newSelector) {
if (this.parentSelector == null) {
this.parentSelector = newSelector;
}
}
public Component select(Object hint) throws ComponentException {
Component component = null;
try {
component = super.select(hint);
} catch (ComponentException ce) {
if (this.parentSelector != null) {
component = this.parentSelector.select(hint);
componentMapping.put(component, this.parentSelector);
} else {
throw ce;
}
}
return component;
}
public void release(Component component) {
SitemapComponentSelector selector = (SitemapComponentSelector)componentMapping.get(component);
if(selector != null) {
componentMapping.remove(component);
selector.release(component);
} else {
super.release(component);
}
}
public void initialize() {
super.initialize();
this.mime_types = Collections.unmodifiableMap(this.mime_types);
}
public String getMimeTypeForHint(Object hint) {
String mimeType = (String)this.mime_types.get(hint);
if (mimeType != null) {
return mimeType;
}
if (this.parentSelector != null) {
return this.parentSelector.getMimeTypeForHint(hint);
}
return null;
}
public boolean hasLabel(Object hint, String label) {
String[] labels = (String[])this.hintLabels.get(hint);
if (labels != null) {
for (int i = 0; i < labels.length; i++) {
if (labels[i].equals(label))
return true;
}
} else if (parentSelector != null) {
return parentSelector.hasLabel(hint, label);
}
return false;
}
public String[] getLabels(Object hint) {
String[] labels = (String[])this.hintLabels.get(hint);
// Labels can be inherited or completely overrided
if (labels == null && parentSelector != null) {
return parentSelector.getLabels(hint);
}
return labels;
}
public void addComponent(Object hint, Class component, Configuration conf)
throws ComponentException {
String mimeType = conf.getAttribute("mime-type", null);
if (mimeType != null)
this.mime_types.put(hint, mimeType);
String label = conf.getAttribute("label", null);
if (label != null) {
// Empty '' attribute will result in empty array,
// overriding all labels on the component declared in the parent.
StringTokenizer st = new StringTokenizer(label, " ,", false);
String[] labels = new String[st.countTokens()];
for (int i = 0; i < labels.length; i++) {
labels[i] = st.nextToken();
}
this.hintLabels.put(hint, labels);
}
super.addComponent(hint, component, conf);
}
public void addSitemapComponent(Object hint, Class component,
Configuration conf, String mimeType)
throws ComponentException, ConfigurationException {
this.addComponent(hint, component, conf);
this.mime_types.put(hint, mimeType);
}
}
----------------------------------------------------------------------
In case of troubles, e-mail: webmaster@xml.apache.org
To unsubscribe, e-mail: cocoon-cvs-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-cvs-help@xml.apache.org
Re: WebLogic,
Was: cvs commit: xml-cocoon2/src/java/org/apache/cocoon/sitemap
DefaultSitemapComponentSelector.java
Posted by Bernhard Huber <be...@a1.net>.
hi,
i have not tested it, but your idea might be right, as i experienced
problems launching the i18n demo webapp
under wls6.1.
the setup was only replacing the xslt processor of wls6.1 but keeping
the wls6.1 xml parser.
you remember this was neccessary to keep cocoon running under wls6.1 at all.
now it seems replacing wls6.1 xml parser is neccessary, too.
sorry but it might take some time before i can come up with more
specific results.
bye bernhard
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
WebLogic, Was: cvs commit: xml-cocoon2/src/java/org/apache/cocoon/sitemap DefaultSitemapComponentSelector.java
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Bernhard Huber [mailto:berni_huber@a1.net]
>
> hi,
>
> i made following experience:
>
> Launching via tomcat Cocoon2 works fine, and the sitemap is correctly
> regenerated.
>
> Launching Cocoon2 via WLS6.1 does not generate the
org/apache/cocoon/www
> directory hierarchy at all.
> I observed that 100% cpu usage under W2K, probably some
endless-looping.
Copy that. Probably this loop is somewhere in Weblogic's Xalan/Xerces,
or there is something else weird.
Did anybody found a way around this issue?
> I copied org/apache/cocoon/www directory + files from the tomcat
> deployment to
> the WLS6.1 deployment and now I was able to see the Cocoon2 demo
webapp.
That's not fun. :-/
Vadim
>
> bye bernhard
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: cvs commit: xml-cocoon2/src/java/org/apache/cocoon/sitemap
DefaultSitemapComponentSelector.java
Posted by Bernhard Huber <be...@a1.net>.
hi,
i made following experience:
Launching via tomcat Cocoon2 works fine, and the sitemap is correctly
regenerated.
Launching Cocoon2 via WLS6.1 does not generate the org/apache/cocoon/www
directory hierarchy at all.
I observed that 100% cpu usage under W2K, probably some endless-looping.
I copied org/apache/cocoon/www directory + files from the tomcat
deployment to
the WLS6.1 deployment and now I was able to see the Cocoon2 demo webapp.
bye bernhard
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: RequestLifecycle [was: Re: cvs commit: xml-cocoon2/src/java/org/apache/cocoon/sitemap DefaultSitemapComponentSelector.java]
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
>
> Carsten Ziegeler wrote:
>
> >Sylvain Wallez wrote:
> >
> >><snipped>
> >>
> >>
> >>But I have also have a question : should enter/leaveEnvironment be
> >>called only once per request (i.e. on the root sitemap), or also on
> >>every nested subsitemap ?
> >>
> >>In sitemap.handler, it seems to be called for each subsitemap, which
> >>means for example that a RequestLifecycle component looked up in the
> >>main sitemap is hidden when we enter in a subsitemap. Is this the
> >>intended behaviour ?
> >>
> >Argh, no of course not - the intended behaviour is that a
> RequestLifecycle
> >component is valid for a request regardless in what sitemap it
> is looked up.
> >But, if an internal request is process (using the cocoon: protocol),
> >the RequestLifecycle component of the calling process are not
> valid inside
> >the internal request. That is the intention of the lines in the
> >sitemap.handler.
> >
> >Well, lets see if I can fix it somehow. Thanks for reporting it!
> >
> >Carsten
> >
> One more detail : should a "cocoon:" URL considered as a new request, or
> should it inherit RequestLifecycle components of the calling request ?
>
> I would say it should be considered as a new request, in order to behave
> independently of the calling environment, but what do you think ?
>
Yupp, it's a new request. That was actually what I meant by my previous mail
and this should be fixed with my patch from yesterday (which is a little bit
hacky, but it should work).
Thanks,
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RequestLifecycle [was: Re: cvs commit: xml-cocoon2/src/java/org/apache/cocoon/sitemap DefaultSitemapComponentSelector.java]
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
>Sylvain Wallez wrote:
>
>><snipped>
>>
>>
>>But I have also have a question : should enter/leaveEnvironment be
>>called only once per request (i.e. on the root sitemap), or also on
>>every nested subsitemap ?
>>
>>In sitemap.handler, it seems to be called for each subsitemap, which
>>means for example that a RequestLifecycle component looked up in the
>>main sitemap is hidden when we enter in a subsitemap. Is this the
>>intended behaviour ?
>>
>Argh, no of course not - the intended behaviour is that a RequestLifecycle
>component is valid for a request regardless in what sitemap it is looked up.
>But, if an internal request is process (using the cocoon: protocol),
>the RequestLifecycle component of the calling process are not valid inside
>the internal request. That is the intention of the lines in the
>sitemap.handler.
>
>Well, lets see if I can fix it somehow. Thanks for reporting it!
>
>Carsten
>
One more detail : should a "cocoon:" URL considered as a new request, or
should it inherit RequestLifecycle components of the calling request ?
I would say it should be considered as a new request, in order to behave
independently of the calling environment, but what do you think ?
Sylvain
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: cvs commit: xml-cocoon2/src/java/org/apache/cocoon/sitemap DefaultSitemapComponentSelector.java
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
> <snipped>
>
>
> But I have also have a question : should enter/leaveEnvironment be
> called only once per request (i.e. on the root sitemap), or also on
> every nested subsitemap ?
>
> In sitemap.handler, it seems to be called for each subsitemap, which
> means for example that a RequestLifecycle component looked up in the
> main sitemap is hidden when we enter in a subsitemap. Is this the
> intended behaviour ?
>
Argh, no of course not - the intended behaviour is that a RequestLifecycle
component is valid for a request regardless in what sitemap it is looked up.
But, if an internal request is process (using the cocoon: protocol),
the RequestLifecycle component of the calling process are not valid inside
the internal request. That is the intention of the lines in the
sitemap.handler.
Well, lets see if I can fix it somehow. Thanks for reporting it!
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: cvs commit: xml-cocoon2/src/java/org/apache/cocoon/sitemap DefaultSitemapComponentSelector.java
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
>Sylvain Wallez wrote:
>
>>Vadim Gritsenko wrote:
>>
>>>Sylvain,
>>>
>>>How it is different from SitemapComponentSelector?
>>>
>>>Just curios...
>>>
>>>Vadim
>>>
>>It's identical :) But as the TreeProcessor has it's own
>>ComponentSelector to directly handle the syntax of <map:components> as
>>its configuration, I had to move the sitemap specific methods (getLabels
>>and hadLabel) to a common interface. This interface is
>>SitemapComponentSelector, and the previous SitemapComponentSelector has
>>been moved to DefaultSitemapComponentSelector.
>>
>>This means label and mime-type handling is duplicated between sitemap
>>and treeprocessor selectors, which is obviously bad. A solution would be
>>for the compiled sitemap to use the selector in the treeprocessor (it's
>>compatible as it doesn't use the special handling of configuration), but
>>this is not possible now because treeprocessor is in the scratchpad.
>>
>>If treeprocessor moves to the main src trunk, some refactoring will be
>>possible for common parts between the two implementations.
>>
>
>Is anything against adding it to the main trunk? I'm +1 on moving it.
>
There are still some bugs, which I should have the time to fix in the
coming days. But since main trunk doesn't mean bug-free, +1 from me also :)
>But I have one question:
>
>The compiled sitemap uses the AbstractSitemap class which creates a
>CocoonComponentManager
>instances looking up the sitemap components. This is in order to get the
>RequestLifecycle
>support.
>
Ah, I missed that.
>I haven't looked too much into the TreeProcessor code, but I assume that it
>doesn't use the AbstractSitemap class, right? Can you point me to the place
>where I have to add the required changes?
>
The component manager is created in
treeprocessor.sitemap.SitemapLanguage.createComponentManager(), and the
main entry point of a sitemap is in
treeprocessor.sitemap.PipelinesNode.invoke().
But I have also have a question : should enter/leaveEnvironment be
called only once per request (i.e. on the root sitemap), or also on
every nested subsitemap ?
In sitemap.handler, it seems to be called for each subsitemap, which
means for example that a RequestLifecycle component looked up in the
main sitemap is hidden when we enter in a subsitemap. Is this the
intended behaviour ?
Sylvain
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: cvs commit: xml-cocoon2/src/java/org/apache/cocoon/sitemap DefaultSitemapComponentSelector.java
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
>
> Vadim Gritsenko wrote:
>
> >Sylvain,
> >
> >How it is different from SitemapComponentSelector?
> >
> >Just curios...
> >
> >Vadim
> >
> It's identical :) But as the TreeProcessor has it's own
> ComponentSelector to directly handle the syntax of <map:components> as
> its configuration, I had to move the sitemap specific methods (getLabels
> and hadLabel) to a common interface. This interface is
> SitemapComponentSelector, and the previous SitemapComponentSelector has
> been moved to DefaultSitemapComponentSelector.
>
> This means label and mime-type handling is duplicated between sitemap
> and treeprocessor selectors, which is obviously bad. A solution would be
> for the compiled sitemap to use the selector in the treeprocessor (it's
> compatible as it doesn't use the special handling of configuration), but
> this is not possible now because treeprocessor is in the scratchpad.
>
> If treeprocessor moves to the main src trunk, some refactoring will be
> possible for common parts between the two implementations.
>
Is anything against adding it to the main trunk? I'm +1 on moving it.
But I have one question:
The compiled sitemap uses the AbstractSitemap class which creates a
CocoonComponentManager
instances looking up the sitemap components. This is in order to get the
RequestLifecycle
support.
I haven't looked too much into the TreeProcessor code, but I assume that it
doesn't use the AbstractSitemap class, right? Can you point me to the place
where I have to add the required changes?
Thanks,
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: cvs commit: xml-cocoon2/src/java/org/apache/cocoon/sitemap DefaultSitemapComponentSelector.java
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Vadim Gritsenko wrote:
>Sylvain,
>
>How it is different from SitemapComponentSelector?
>
>Just curios...
>
>Vadim
>
It's identical :) But as the TreeProcessor has it's own
ComponentSelector to directly handle the syntax of <map:components> as
its configuration, I had to move the sitemap specific methods (getLabels
and hadLabel) to a common interface. This interface is
SitemapComponentSelector, and the previous SitemapComponentSelector has
been moved to DefaultSitemapComponentSelector.
This means label and mime-type handling is duplicated between sitemap
and treeprocessor selectors, which is obviously bad. A solution would be
for the compiled sitemap to use the selector in the treeprocessor (it's
compatible as it doesn't use the special handling of configuration), but
this is not possible now because treeprocessor is in the scratchpad.
If treeprocessor moves to the main src trunk, some refactoring will be
possible for common parts between the two implementations.
>>-----Original Message-----
>>From: sylvain@apache.org [mailto:sylvain@apache.org]
>>Sent: Wednesday, February 06, 2002 4:09 PM
>>To: xml-cocoon2-cvs@apache.org
>>Subject: cvs commit: xml-cocoon2/src/java/org/apache/cocoon/sitemap
>>DefaultSitemapComponentSelector.java
>>
>>sylvain 02/02/06 13:09:22
>>
>> Added: src/java/org/apache/cocoon/sitemap
>> DefaultSitemapComponentSelector.java
>> Log:
>> Oops, forgot to add the new file :/
>>
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: cvs commit: xml-cocoon2/src/java/org/apache/cocoon/sitemap DefaultSitemapComponentSelector.java
Posted by Vadim Gritsenko <va...@verizon.net>.
Sylvain,
How it is different from SitemapComponentSelector?
Just curios...
Vadim
> -----Original Message-----
> From: sylvain@apache.org [mailto:sylvain@apache.org]
> Sent: Wednesday, February 06, 2002 4:09 PM
> To: xml-cocoon2-cvs@apache.org
> Subject: cvs commit: xml-cocoon2/src/java/org/apache/cocoon/sitemap
> DefaultSitemapComponentSelector.java
>
> sylvain 02/02/06 13:09:22
>
> Added: src/java/org/apache/cocoon/sitemap
> DefaultSitemapComponentSelector.java
> Log:
> Oops, forgot to add the new file :/
>
> Revision Changes Path
> 1.1 xml-
>
cocoon2/src/java/org/apache/cocoon/sitemap/DefaultSitemapComponentSelect
or.jav
> a
>
> Index: DefaultSitemapComponentSelector.java
> ===================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org