from:"Thorsten Scherler"

On 02/26/2013 04:36 PM, Francesco Chicchiriccò wrote:
>
>>> as you have already found, the problem is the "cocoon" entry in the
>>> sitemap's ObjectModel, always passed among parameters.
>>>
>>> I have been able to actually print the content of the "cocoon" entry
>>> via common-collection's MapUtils:
>>>
>>>  if (entry.getValue() instanceof Map) {
>>>  MapUtils.verbosePrint(System.out, null,
>>> parameters);
>>>  } else {
>>>  System.out.println(entry.getValue());
>>>  }
>>>
>>> I am about to commit a fix for the issue in STRenderer you've reported
>>> above based on the usage of MapUtils#verbosePrint()
>> Nice you are a "monstruo".
>
> Hem, guess you mean "mostro" (a.k.a. monster) - I'll take as a
> compliment ;-)

Definitely here in the south of spain we use it as compliment for a
person/friend which is usually accomplishing BIG things.

>
> Anyway as per r1450217 the StackOverflowError is removed from STRenderer.
>

Thank you very much, so awesome.

I had some problems to find the "important" change though between the
checkstyle/formating changes. It would be great if you could separate
those in the future. Anyway as I understand the most important change is:

Modified: 
cocoon/cocoon3/trunk/cocoon-stringtemplate/src/main/java/org/apache/cocoon/stringtemplate/STRenderer.java
URL: 
http://svn.apache.org/viewvc/cocoon/cocoon3/trunk/cocoon-stringtemplate/src/main/java/org/apache/cocoon/stringtemplate/STRenderer.java?rev=1450217&r1=1450216&r2=1450217&view=diff
==
--- 
cocoon/cocoon3/trunk/cocoon-stringtemplate/src/main/java/org/apache/cocoon/stringtemplate/STRenderer.java
 (original)
+++ 
cocoon/cocoon3/trunk/cocoon-stringtemplate/src/main/java/org/apache/cocoon/stringtemplate/STRenderer.java
 Tue Feb 26 15:31:18 2013
@@ -17,7 +17,10 @@
 package org.apache.cocoon.stringtemplate;
 
 import java.io.IOException;
+import java.io.PrintStream;
 import java.util.Map;
+import org.apache.commons.collections.MapUtils;
+import org.apache.commons.io.output.ByteArrayOutputStream;
 import org.apache.commons.lang3.StringEscapeUtils;
 import org.slf4j.Logger;
 import org.slf4j.LoggerFactory;
@@ -58,8 +61,18 @@ public final class STRenderer {
 ? 
StringEscapeUtils.escapeXml(entry.getValue().toString())
 : entry.getValue());
 
-LOG.debug("Passing pipeline parameter as attribute: key={}, 
value={}",
-entry.getKey(), entry.getValue());
+if (LOG.isDebugEnabled()) {
+final String value;
+if (entry.getValue() instanceof Map) {
+final ByteArrayOutputStream baos = new 
ByteArrayOutputStream();
+MapUtils.verbosePrint(new PrintStream(baos), null, 
parameters);
+baos.flush();
+value = baos.toString();
+} else {
+value = entry.getValue().toString();
+}
+LOG.debug("Passing parameter as ST attribute: key={}, 
value={}", entry.getKey(), value);
+}
 }
 }
 



>> Let us see whether that gets rid of the redundant data as well.
>
> I've been exploring a bit the various call and I think that this
> duplication might be generated when intra-pipeline calls (e.g.
> "servlet:/") are issued.
>

Yeah that definitely makes sense since some props where the same but
other not e.g.
source=file:/home/thorsten/src/codebusters/CLIENT/c3-extractor/src/main/resources/COB-INF/resources/views/admin.xhtml,
only appears once (which is the view called by the controller via
servlet:/ ...)

Thanks again Francesco and as well for your latest bugfixing run. :)

salu2

-- 
Thorsten Scherler 
codeBusters S.L. - web based systems


http://www.codebusters.es/

Re: REST view and weird error

On 02/26/2013 03:21 PM, Francesco Chicchiriccò wrote:
> On 26/02/2013 13:43, Thorsten Scherler wrote:
>> On 02/25/2013 02:10 PM, Thorsten Scherler wrote:
>>> ...
>>> Passing pipeline parameter as attribute: key=cocoon, value=[FAILED
>>> toString()]
>>>
>>> in MessageFormatter.arrayFormat.
>>>
>>> still investigating
>>>
>>> salu2
>>>
>> Actually you can see it if you start the cocoon-sample block and request
>> http://localhost:/controller/abc/foo?reqparam=1
>>
>>
>> SLF4J: Failed toString() invocation on an object of type
>> [java.util.HashMap]
>> java.lang.StackOverflowError
>>  at
>> java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:631)
>>  at java.lang.StringBuilder.append(StringBuilder.java:224)
>>  at
>> org.apache.cocoon.configuration.MutableSettings.toString(MutableSettings.java:312)
>>
>>  at java.lang.String.valueOf(String.java:2902)
>>
>> It actually happens in STRenderer
>> [...]
>
> Hi Thorsten,
> as you have already found, the problem is the "cocoon" entry in the
> sitemap's ObjectModel, always passed among parameters.
>
> I have been able to actually print the content of the "cocoon" entry
> via common-collection's MapUtils:
>
> if (entry.getValue() instanceof Map) {
> MapUtils.verbosePrint(System.out, null, parameters);
> } else {
> System.out.println(entry.getValue());
>     }
>
> I am about to commit a fix for the issue in STRenderer you've reported
> above based on the usage of MapUtils#verbosePrint()
>

Nice you are a "monstruo".

Let us see whether that gets rid of the redundant data as well.

salu2

-- 
Thorsten Scherler 
codeBusters S.L. - web based systems


http://www.codebusters.es/

Re: REST view and weird error

On 02/26/2013 03:13 PM, Robby Pelssers wrote:
> To be more precise it happens when processing the map entry "cocoon".  So in 
> this case there must be some circular reference.. finding that needle is a 
> bit more difficult :(
>

Jupp, look at this:

{baseUrl=file:/home/thorsten/src/codebusters/CLIENT/c3-extractor/./src/main/resources/COB-INF/,
javax.servlet.http.HttpServletResponse=org.apache.cocoon.servletservice.HttpServletResponseBufferingWrapper@61771f5,
source=file:/home/thorsten/src/codebusters/CLIENT/c3-extractor/src/main/resources/COB-INF/resources/views/admin.xhtml,
javax.servlet.http.HttpServletRequest=org.apache.cocoon.servletservice.util.ServletServiceRequest@6d3a8ef2,
javax.servlet.ServletContext=org.apache.cocoon.servletservice.ServletServiceContext@63917066,
org.apache.cocoon.configuration.Settings=Settings:
Running mode : dev
org.apache.cocoon.reload-delay : 1000
org.apache.cocoon.reloading : false
org.apache.cocoon.classloader.load.classes : empty
org.apache.cocoon.cache.directory :
/home/thorsten/src/codebusters/CLIENT/c3-extractor/target/work/cache-dir
org.apache.cocoon.work.directory :
/home/thorsten/src/codebusters/CLIENT/c3-extractor/target/work
org.apache.cocoon.formencoding : null
org.apache.cocoon.containerencoding : UTF-8
,
cocoon={response=org.apache.cocoon.servletservice.HttpServletResponseBufferingWrapper@61771f5,
settings=Settings:
Running mode : dev
org.apache.cocoon.reload-delay : 1000
org.apache.cocoon.reloading : false
org.apache.cocoon.classloader.load.classes : empty
org.apache.cocoon.cache.directory :
/home/thorsten/src/codebusters/CLIENT/c3-extractor/target/work/cache-dir
org.apache.cocoon.work.directory :
/home/thorsten/src/codebusters/CLIENT/c3-extractor/target/work
org.apache.cocoon.formencoding : null
org.apache.cocoon.containerencoding : UTF-8
,
request=org.apache.cocoon.servlet.util.ObjectModelProvider$ObjectModelRequest@1f7ee9e4,
context=org.apache.cocoon.servletservice.ServletServiceContext@63917066,
controller={properties={awt.toolkit=sun.awt.X11.XToolkit,
classworlds.conf=/home/thorsten/src/codebusters/workspace/crawl/.metadata/.plugins/org.eclipse.m2e.core/launches/m2conf3387913835580501331.tmp,
common.resources=/home/thorsten/src/codebusters/CLIENT/api/src/main/resources/COB-INF/resources/,more=...,
sun.java.command=org.codehaus.plexus.classworlds.launcher.Launcher -B -s
/home/thorsten/.m2/settings.xml install jetty:run,
sun.java.launcher=SUN_STANDARD, sun.jnu.encoding=UTF-8,
sun.management.compiler=HotSpot 64-Bit Tiered Compilers,
sun.os.patch.level=unknown, user.country=US,
user.dir=/home/thorsten/src/codebusters/CLIENT/c3-extractor,
user.home=/home/thorsten, user.language=en, user.name=thorsten,
user.timezone=Europe/Madrid

The more=..., is much more props I handle but basically
org.apache.cocoon.configuration.Settings are two times and a view more
under a different name. e.g.
javax.servlet.http.HttpServletResponse=org.apache.cocoon.servletservice.HttpServletResponseBufferingWrapper@61771f5,
response=org.apache.cocoon.servletservice.HttpServletResponseBufferingWrapper@61771f5,


I am not sure ATM why this duplication.

salu2

-- 
Thorsten Scherler 
codeBusters S.L. - web based systems


http://www.codebusters.es/

Re: REST view and weird error

On 02/25/2013 02:10 PM, Thorsten Scherler wrote:
> ...
> Passing pipeline parameter as attribute: key=cocoon, value=[FAILED
> toString()]
>
> in MessageFormatter.arrayFormat.
>
> still investigating
>
> salu2
>

Actually you can see it if you start the cocoon-sample block and request
http://localhost:/controller/abc/foo?reqparam=1


SLF4J: Failed toString() invocation on an object of type [java.util.HashMap]
java.lang.StackOverflowError
at
java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:631)
at java.lang.StringBuilder.append(StringBuilder.java:224)
at
org.apache.cocoon.configuration.MutableSettings.toString(MutableSettings.java:312)
at java.lang.String.valueOf(String.java:2902)

It actually happens in STRenderer

public String render(final String template,
final Map parameters)
throws IOException {

final ST stringTemplate = new ST(template, '$', '$');

if (parameters == null || parameters.isEmpty()) {
LOG.warn("There are not any parameters passed to the
template.");
} else {
for (Map.Entry entry : parameters.entrySet()) {
stringTemplate.add(entry.getKey().replace(".", "_"),
(entry.getValue() instanceof String)
? StringEscapeUtils.escapeXml(
entry.getValue().toString())
: entry.getValue());

LOG.debug("Passing pipeline parameter as attribute: key={}"
+ ", value={}", entry.getKey(), entry.getValue());
}
}

return stringTemplate.render();
}

salu2

-- 
Thorsten Scherler 
codeBusters S.L. - web based systems


http://www.codebusters.es/

Re: REST view and weird error

On 02/25/2013 12:36 PM, Thorsten Scherler wrote:
> On 02/25/2013 12:08 PM, Thorsten Scherler wrote:
>> Hi all,
>>
>> actually I tried with
>>
>> HashMap data = new HashMap();
>> data.put("xxx", "xxx");
>> return new URLResponse(VIEW, data);
>>
>> so not really a problem of the hashmap within hasmap. Further I need to
>> inject the hashmap to do in my view:
>>
>> 
>> 
>>   $properties.keys:{k|
>>   $k$
>>   
>>   
>>   
>>   }$
>> 
>>   
>>
>> As soon I add a map to the response I get the stackoverflow.
>>
>> I will now play a bit with the log config.
>>
>> BTW thanks for the feedback.
> 
> 
> 
> 
>
> Gets rid of the error.
>
> The final source of the error is MutableSettings
> (cocoon-configuration-api-1.0.4.jar) where we have
>
> public String toString() {
> return "Settings:\n" +
>   "Running mode : " + this.getRunningMode()+ '\n' +
>   KEY_RELOAD_DELAY + " : " + this.getReloadDelay(null) + '\n' +
>   KEY_RELOADING + " : " + this.isReloadingEnabled(null) + '\n' +
>   KEY_LOAD_CLASSES + " : " +
> this.toString(this.getLoadClasses()) + '\n' +
>   KEY_CACHE_DIRECTORY + " : " + this.getCacheDirectory() + '\n' +
>   KEY_WORK_DIRECTORY + " : " + this.getWorkDirectory() + '\n' +
>   KEY_FORM_ENCODING + " : " + this.getFormEncoding() + '\n' +
>   KEY_CONTAINER_ENCODING + " : " + this.getContainerEncoding() +
> '\n';
> }
>
> protected String toString(List a) {
> final StringBuffer buffer = new StringBuffer();
> final Iterator i = a.iterator();
> boolean first = true;
> while ( i.hasNext() ) {
> if ( first ) {
> first = false;
> } else {
> buffer.append(", ");
> }
> buffer.append(i.next());
> }
> return buffer.toString();   
> }
>
> The whole things points to the latter method which is based on the
> protected final List loadClasses = new ArrayList();
>
> In the following we add values:
>
> /**
>  * Fill from a properties object
>  */
> public void configure(Properties props) {
> ...
> } else if ( key.startsWith(KEY_LOAD_CLASSES) ) {
> this.addToLoadClasses(value);
> }
>
> While debug the loadClasses where empty.
>
> salu2
>

Passing pipeline parameter as attribute: key=cocoon, value=[FAILED
toString()]

in MessageFormatter.arrayFormat.

still investigating

salu2

-- 
Thorsten Scherler 
codeBusters S.L. - web based systems


http://www.codebusters.es/

Properties replacement (was Re: Connecting 2 blocks with C3.0)

Hi Mansour,

we are happy you are so active but please use the dev list for your
questions since c3 is not stable. Meaning by definition we have devs no
user working on c3. Please let us discuss this mail and other on the dev
list. TIA.

On 02/25/2013 05:42 AM, Mansour Al Akeel wrote:
> Francesco,
> I know this is an old thread, but I was trying to update my pom.xml so
> that I get the
>
>  context-path="jar:classpath:lib/${project.build.finalName}.jar!/COB-INF/"/>
>
> replaced by maven at build time.
> Now the whole build is failing.
> Is there another way to get this placeholder replaced without using
> the pom included with your project, especially that it has many
> missing dependencies:
>
> [INFO] 
> 
> [INFO] Building contents SNAPSHOT-1.0
> [INFO] 
> 
> [WARNING] The POM for org.springframework:spring-dao:jar:3.1.2.RELEASE
> is missing, no dependency information available
> [WARNING] The POM for commons-jexl:commons-jexl:jar:2.1.1 is missing,
> no dependency information available
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 1.534s
> [INFO] Finished at: Sun Feb 24 23:35:48 GMT 2013
> [INFO] Final Memory: 7M/88M
> [INFO] 
> 

The only thing from the pom you need is something along the lines of:

src/main/resources
false

  META-INF/cocoon/spring/**

src/main/resources/META-INF/cocoon/spring
true
${project.build.outputDirectory}/META-INF/cocoon/spring

That is doing the filtering and replacing the properties.

However in our latest project we have dropped a bit the configuration of
cocoon in terms of properties from
META-INF/cocoon/properties/xxx.properties and use a central place for
the configuration. This allows to use the project specific properties in
a wide range of modules from a central place.

  ../src/main/filter/general.properties
  ../src/main/filter/${env}.properties

src/main/resources
false

  META-INF/cocoon/spring/**
  META-INF/cocoon/properties/**

src/main/resources/META-INF/cocoon/spring
true

${project.build.outputDirectory}/META-INF/cocoon/spring

src/main/resources/META-INF/cocoon/properties
true

${project.build.outputDirectory}/META-INF/cocoon/properties

Here we assume that you have a couple of general properties that may not
change but as well some environment specific properties. Then in our
properties file in cocoon we just use 
common.resources=${common.resources}
extractor.host=${extractor.host}

and the "real" values come from ../src/main/filter/general.properties
and ../src/main/filter/${env}.properties
common.resources=${project.parent.basedir}/api/src/main/resources/COB-INF/resources/
extractor.host=http://localhost:/

We may want to look into changing our artifacts to
1) parent provides filter
2) modules uses this filter from parent module

The advantages is that the configuration is taken place in a single
place and can be used in a cross module manner. For us we use the same
properties in c3 and in our droids module.

wdyt?

salu2

-- 
Thorsten Scherler 
codeBusters S.L. - web based systems

http://www.codebusters.es/

Re: REST view and weird error

On 02/25/2013 12:08 PM, Thorsten Scherler wrote:
> Hi all,
>
> actually I tried with
>
> HashMap data = new HashMap();
> data.put("xxx", "xxx");
> return new URLResponse(VIEW, data);
>
> so not really a problem of the hashmap within hasmap. Further I need to
> inject the hashmap to do in my view:
>
> 
> 
>   $properties.keys:{k|
>   $k$
>   
>   
>   
>   }$
> 
>   
>
> As soon I add a map to the response I get the stackoverflow.
>
> I will now play a bit with the log config.
>
> BTW thanks for the feedback.






Gets rid of the error.

The final source of the error is MutableSettings
(cocoon-configuration-api-1.0.4.jar) where we have

public String toString() {
return "Settings:\n" +
  "Running mode : " + this.getRunningMode()+ '\n' +
  KEY_RELOAD_DELAY + " : " + this.getReloadDelay(null) + '\n' +
  KEY_RELOADING + " : " + this.isReloadingEnabled(null) + '\n' +
  KEY_LOAD_CLASSES + " : " +
this.toString(this.getLoadClasses()) + '\n' +
  KEY_CACHE_DIRECTORY + " : " + this.getCacheDirectory() + '\n' +
  KEY_WORK_DIRECTORY + " : " + this.getWorkDirectory() + '\n' +
  KEY_FORM_ENCODING + " : " + this.getFormEncoding() + '\n' +
  KEY_CONTAINER_ENCODING + " : " + this.getContainerEncoding() +
'\n';
}

protected String toString(List a) {
final StringBuffer buffer = new StringBuffer();
final Iterator i = a.iterator();
boolean first = true;
while ( i.hasNext() ) {
if ( first ) {
first = false;
} else {
buffer.append(", ");
}
buffer.append(i.next());
}
return buffer.toString();   
}

The whole things points to the latter method which is based on the
protected final List loadClasses = new ArrayList();

In the following we add values:

/**
     * Fill from a properties object
 */
public void configure(Properties props) {
...
} else if ( key.startsWith(KEY_LOAD_CLASSES) ) {
this.addToLoadClasses(value);
}

While debug the loadClasses where empty.

salu2

-- 
Thorsten Scherler 
codeBusters S.L. - web based systems


http://www.codebusters.es/

Re: REST view and weird error

Hi all,

actually I tried with

HashMap data = new HashMap();
data.put("xxx", "xxx");
return new URLResponse(VIEW, data);

so not really a problem of the hashmap within hasmap. Further I need to
inject the hashmap to do in my view:



  $properties.keys:{k|
  $k$
  
  
  
  }$

  

As soon I add a map to the response I get the stackoverflow.

I will now play a bit with the log config.

BTW thanks for the feedback.

salu2
On 02/22/2013 03:10 PM, Robby Pelssers wrote:
> I'd say no...
>
> He does first create a new map called 'data'
> HashMap data = new HashMap();
>
> And next he puts the Props map in data
>
> data.put("properties", getProps());
>
>
> And next he passes the map to the view.
> return new URLResponse(VIEW, data);
>
> But obviously creating that data map is of no use.  And secondly... suppose 
> he wants to keep his hands of the original Props map, he should copy all 
> values over toe the new data map instead of putting the map in the map.
>
> Robby
>
>
> -Original Message-
> From: Nathaniel, Alfred [mailto:alfred.nathan...@six-group.com] 
> Sent: Friday, February 22, 2013 3:07 PM
> To: 'dev@cocoon.apache.org'
> Subject: RE: REST view and weird error
>
> Wild guess:  somewhere you add the map to itself
>
>map.put("map", map);
>
> creating an infinite recursion in map.toString().
>
> HTH, Alfred.
>
> -Original Message-
> From: Robby Pelssers [mailto:robby.pelss...@nxp.com] 
> Sent: Freitag, 22. Februar 2013 11:54
> To: dev@cocoon.apache.org
> Subject: RE: REST view and weird error
>
> Hi Thorsten,
>
> Just one question.
>
> I'm a making a few assumptions here but is Settings not a HashMap already? 
> Can't you just do
>
> @Override
> public RestResponse doGet() throws Exception {
> return new URLResponse(VIEW, getProps());
> }
>
> I don't see the point in putting a hashmap in another hashmap just for the 
> sake of it ;-)
>
> Robby
>
> -Original Message-
> From: Thorsten Scherler [mailto:scher...@gmail.com] 
> Sent: Friday, February 22, 2013 10:13 AM
> To: dev@cocoon.apache.org
> Subject: REST view and weird error
>
> Hi all,
>
> in one view of a REST service of mine I get:
>
> SLF4J: Failed toString() invocation on an object of type [java.util.HashMap] 
> java.lang.StackOverflowError
> at
> java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:639)
> at java.lang.StringBuilder.append(StringBuilder.java:224)
> at
> org.apache.cocoon.configuration.MutableSettings.toString(MutableSettings.java:312)
> at java.lang.String.valueOf(String.java:2902)
> ...
> at java.lang.StringBuilder.append(StringBuilder.java:128)
> at java.util.AbstractMap.toString(AbstractMap.java:523)
> at java.lang.String.valueOf(String.java:2902)
>
> where the last 3 lines will repeat a lot till the end.
>
> I am doing:
>
> @Override
> public RestResponse doGet() throws Exception {
> HashMap data = new HashMap();
> data.put("properties", getProps());
> return new URLResponse(VIEW, data);
> }
>
> where getProps() basically is a helper for getting 
> this.settings.getProperties.
>
> As soon I do return new URLResponse(VIEW) the error is gone.
>
> I have the standard logging activated (via rcl-config), using jetty:run and 
> no override for es.codebusters.droids.rest.DroidsInvoker in my logback.xml
>
> 
>     
> 
> 
>
> Any ideas?
>
> salu2
>
> --
> Thorsten Scherler  codeBusters S.L. - web based 
> systems 
>
> http://www.codebusters.es/
>
>
>
> The content of this e-mail is intended only for the confidential use of the 
> person addressed. 
> If you are not the intended recipient, please notify the sender and delete 
> this email immediately.
> Thank you.
>
>


-- 
Thorsten Scherler 
codeBusters S.L. - web based systems


http://www.codebusters.es/

REST view and weird error

2013-02-22 Thread Thorsten Scherler

Hi all,

in one view of a REST service of mine I get:

SLF4J: Failed toString() invocation on an object of type [java.util.HashMap]
java.lang.StackOverflowError
at
java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:639)
at java.lang.StringBuilder.append(StringBuilder.java:224)
at
org.apache.cocoon.configuration.MutableSettings.toString(MutableSettings.java:312)
at java.lang.String.valueOf(String.java:2902)
...
at java.lang.StringBuilder.append(StringBuilder.java:128)
at java.util.AbstractMap.toString(AbstractMap.java:523)
at java.lang.String.valueOf(String.java:2902)

where the last 3 lines will repeat a lot till the end.

I am doing:

@Override
public RestResponse doGet() throws Exception {
HashMap data = new HashMap();
data.put("properties", getProps());
return new URLResponse(VIEW, data);
}

where getProps() basically is a helper for getting
this.settings.getProperties.

As soon I do return new URLResponse(VIEW) the error is gone.

I have the standard logging activated (via rcl-config), using jetty:run
and no override for es.codebusters.droids.rest.DroidsInvoker in my
logback.xml






Any ideas?

salu2

-- 
Thorsten Scherler 
codeBusters S.L. - web based systems


http://www.codebusters.es/

[jira] [Closed] (COCOON3-121) Create a generic generator that creates a root elemement and wraps the destination stream into it

2013-02-20 Thread Thorsten Scherler (JIRA)


 [ 
https://issues.apache.org/jira/browse/COCOON3-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thorsten Scherler closed COCOON3-121.
-

Resolution: Fixed

Committed revision 1448335.


> Create a generic generator that creates a root elemement and wraps the 
> destination stream into it
> -
>
> Key: COCOON3-121
> URL: https://issues.apache.org/jira/browse/COCOON3-121
> Project: Cocoon 3
>  Issue Type: Bug
>  Components: cocoon-optional
>Affects Versions: 3.0.0-beta-1
>    Reporter: Thorsten Scherler
>    Assignee: Thorsten Scherler
> Fix For: 3.0.0-beta-1
>
>
> If you use something like ch.qos.logback.classic.log4j.XMLLayout you can 
> create xml based log files. However the problem is that it does not add root 
> element making the resulting file not well-formed. 
> You can activate the logging in your logback.xml like 
>
> ${crawler.log.error}
> false
> 
>   
> true
>   
> 
> 
> The implemented solution has the following configuration in spring:
>class="org.apache.cocoon.optional.pipeline.components.sax.generator.AddRootElementGenerator"
>  scope="prototype">
> 
> 
> 
> http://jakarta.apache.org/log4j/"/>
>   
> and later parse the file that the appender gives like:
> 
>   
> 
> 
>   
> 
> which will result in something like:
> 
> http://jakarta.apache.org/log4j/";>
>timestamp="1361325224196" level="ERROR" thread="main">
>
>   
>method="handleException" file="ExceptionHandler.java" line="23"/>
>  
> 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (COCOON3-121) Create a generic generator that creates a root elemement and wraps the destination stream into it

2013-02-20 Thread Thorsten Scherler (JIRA)

Thorsten Scherler created COCOON3-121:
-

 Summary: Create a generic generator that creates a root elemement 
and wraps the destination stream into it
 Key: COCOON3-121
 URL: https://issues.apache.org/jira/browse/COCOON3-121
 Project: Cocoon 3
  Issue Type: Bug
  Components: cocoon-optional
Affects Versions: 3.0.0-beta-1
Reporter: Thorsten Scherler
Assignee: Thorsten Scherler
 Fix For: 3.0.0-beta-1


If you use something like ch.qos.logback.classic.log4j.XMLLayout you can create 
xml based log files. However the problem is that it does not add root element 
making the resulting file not well-formed. 

You can activate the logging in your logback.xml like 

   
${crawler.log.error}
false

  
true
  



The implemented solution has the following configuration in spring:

  



http://jakarta.apache.org/log4j/"/>
  

and later parse the file that the appender gives like:

  


  


which will result in something like:

http://jakarta.apache.org/log4j/";>
  
   
  
  
 


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (COCOON3-120) NekoGenerator is loosing encoding

2013-02-18 Thread Thorsten Scherler (JIRA)


 [ 
https://issues.apache.org/jira/browse/COCOON3-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thorsten Scherler closed COCOON3-120.
-

Resolution: Fixed

> NekoGenerator is loosing encoding 
> --
>
> Key: COCOON3-120
> URL: https://issues.apache.org/jira/browse/COCOON3-120
> Project: Cocoon 3
>  Issue Type: Bug
>  Components: cocoon-optional
>    Reporter: Thorsten Scherler
> Fix For: 3.0.0-beta-1
>
>
> We need to be able to change the default-encoding of the NekoGenerator.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (COCOON3-120) NekoGenerator is loosing encoding

2013-02-18 Thread Thorsten Scherler (JIRA)

Thorsten Scherler created COCOON3-120:
-

 Summary: NekoGenerator is loosing encoding 
 Key: COCOON3-120
 URL: https://issues.apache.org/jira/browse/COCOON3-120
 Project: Cocoon 3
  Issue Type: Bug
  Components: cocoon-optional
Reporter: Thorsten Scherler


We need to be able to change the default-encoding of the NekoGenerator.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [DISCUSS] Fix for COCOON3-105

2013-02-05 Thread Thorsten Scherler

On 02/05/2013 04:10 PM, Thorsten Scherler wrote:
> On 01/19/2013 02:23 PM, Francesco Chicchiriccò wrote:
>> Il 17/01/2013 10:23, Francesco Chicchiriccò ha scritto:
>>> ...
>> Hi Thorsten,
>> I was finally able to make all needed checks and the good news is
>> that everything is working as expected.
>> From the error message you report above I guess that you are not
>> using the very latest C3 SNAPSHOT artifacts.
>>
>> Anyway, I've updated the sample application [1] with some description
>> about how to run and what you get [2].
>>
>> HTH
>
>
> Thank you very much, the problem was indeed in the older snapshot.
>
BTW

diff --git a/mysite2/pom.xml b/mysite2/pom.xml
index c5cb95b..e4c3527 100644
--- a/mysite2/pom.xml
+++ b/mysite2/pom.xml
@@ -17,7 +17,7 @@
   
 
   com.mycompany
-  mysite2
+  mysite
   ${project.version}
 


alu2

-- 
Thorsten Scherler 
codeBusters S.L. - web based systems


http://www.codebusters.es/

Re: [DISCUSS] Fix for COCOON3-105

2013-02-05 Thread Thorsten Scherler

On 01/19/2013 02:23 PM, Francesco Chicchiriccò wrote:
> Il 17/01/2013 10:23, Francesco Chicchiriccò ha scritto:
>> On 14/01/2013 16:20, Thorsten Scherler wrote:
>>> [...]
>>>>> Can you please tell me how can I address block_A's sitemap from
>>>>> from block_B's sitemap?
>>>>> I have used *blockcontext:/* for this before.
>>>>
>>>> This should work In the same way as in *servlet-service.xml, e.g.
>>>> by replacing
>>>>
>>>> blockcontext:/otherblock/BLA
>>>>
>>>> with
>>>>
>>>> jar:classpath:lib/otherblock.jar!/COB-INF/BLA
>>>>
>>>
>>> Hi, I just tried the above in another project but using it in the
>>> sitemap I get
>>> java.net.MalformedURLException: invalid url:
>>> classpath:lib/api-0.1-SNAPSHOT.jar!/COB-INF/resources/xsl/intern-to-solr.xsl
>>> (java.net.MalformedURLException: unknown protocol: classpath)
>>>
>>> I am trying to use a central module to store common xsl that I need
>>> both in cocoon and in my java code.
>>
>> Hi Thorsten,
>> sorry for the delay, I am quite busy in this period on other projects.
>>
>> Anyway, I'll try to check and get back asap to you.
>
> Hi Thorsten,
> I was finally able to make all needed checks and the good news is that
> everything is working as expected.
> From the error message you report above I guess that you are not using
> the very latest C3 SNAPSHOT artifacts.
>
> Anyway, I've updated the sample application [1] with some description
> about how to run and what you get [2].
>
> HTH


Thank you very much, the problem was indeed in the older snapshot.

salu2

-- 
Thorsten Scherler 
codeBusters S.L. - web based systems


http://www.codebusters.es/

Re: [DISCUSS] Fix for COCOON3-105

2013-01-14 Thread Thorsten Scherler

On 12/20/2012 02:05 PM, Francesco Chicchiriccò wrote:
> On 20/12/2012 13:45, Leonardo Miceli wrote:
>> Hello
>>
>> On 12/07/2012 01:33 PM, Francesco Chicchiriccò wrote:
>>> On 07/12/2012 13:09, Jos Snellings wrote:
>>>> In shorthand: What are the implications then?
>>>
>>
>> (...)
>>
>>>> Bottomline:
>>>> - "a block context" is addressable within the sitemap
>>>>   load resource from another block context is possible via
>>>> 'classpath'.
>>>>   The root of every block is available on the classpath?
>>>
>>> Everything should be working in the same way.
>>>
>>
>> Can you please tell me how can I address block_A's sitemap from from
>> block_B's sitemap?
>> I have used *blockcontext:/* for this before.
>
> This should work In the same way as in *servlet-service.xml, e.g. by
> replacing
>
> blockcontext:/otherblock/BLA
>
> with
>
> jar:classpath:lib/otherblock.jar!/COB-INF/BLA
>

Hi, I just tried the above in another project but using it in the
sitemap I get
java.net.MalformedURLException: invalid url:
classpath:lib/api-0.1-SNAPSHOT.jar!/COB-INF/resources/xsl/intern-to-solr.xsl
(java.net.MalformedURLException: unknown protocol: classpath)

I am trying to use a central module to store common xsl that I need both
in cocoon and in my java code.

salu2

-- 
Thorsten Scherler 
codeBusters S.L. - web based systems


http://www.codebusters.es/

Re: [VOTE] Apache Cocoon Servlet Service Implementation 1.3.2

2012-12-16 Thread Thorsten Scherler

+1

You may consider to extend the voting period, to allow that other can vote
on monday


On Thu, Dec 13, 2012 at 10:54 AM, Francesco Chicchiriccò <
ilgro...@apache.org> wrote:

> I've created a Cocoon Servlet Service Implementation 1.3.2 release, with
> the following artifacts up for a vote:
>
> SVN source tag (r1421170):
> https://svn.apache.org/repos/**asf/cocoon/subprojects/cocoon-**
> servlet-service-impl/tags/**cocoon-servlet-service-impl-1.**3.2/<https://svn.apache.org/repos/asf/cocoon/subprojects/cocoon-servlet-service-impl/tags/cocoon-servlet-service-impl-1.3.2/>
>
> List of changes:
> https://svn.apache.org/repos/**asf/cocoon/subprojects/cocoon-**
> servlet-service-impl/tags/**cocoon-servlet-service-impl-1.**
> 3.2/src/changes/changes.xml<https://svn.apache.org/repos/asf/cocoon/subprojects/cocoon-servlet-service-impl/tags/cocoon-servlet-service-impl-1.3.2/src/changes/changes.xml>
>
> Maven staging repo:
> https://repository.apache.org/**content/repositories/**
> orgapachecocoon-008/<https://repository.apache.org/content/repositories/orgapachecocoon-008/>
>
> Source release (checksums and signatures are available at the same
> location):
> https://repository.apache.org/**content/repositories/**
> orgapachecocoon-008/org/**apache/cocoon/cocoon-servlet-**
> service-impl/1.3.2/cocoon-**servlet-service-impl-1.3.2-**
> source-release.zip<https://repository.apache.org/content/repositories/orgapachecocoon-008/org/apache/cocoon/cocoon-servlet-service-impl/1.3.2/cocoon-servlet-service-impl-1.3.2-source-release.zip>
>
> PGP release keys (signed using 273DF287):
> http://www.apache.org/dist/**cocoon/KEYS<http://www.apache.org/dist/cocoon/KEYS>
>
> Vote will be open for 72 hours.
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> --
> Francesco Chicchiriccò
>
> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
> http://people.apache.org/~**ilgrosso/<http://people.apache.org/~ilgrosso/>
>



-- 
Thorsten Scherler 
codeBusters S.L. - web based systems


Tel.: +34 954 520 169
http://www.codebusters.es/

Re: [VOTE] Apache Cocoon Integration Test Framework 1.0.1

2012-12-16 Thread Thorsten Scherler

+1


On Thu, Dec 13, 2012 at 10:16 AM, Francesco Chicchiriccò <
ilgro...@apache.org> wrote:

> I've created a Cocoon Integration Test Framework 1.0.1 release, with the
> following artifacts up for a vote:
>
> SVN source tag (r1421155):
> https://svn.apache.org/repos/**asf/cocoon/subprojects/cocoon-**
> it-fw/tags/cocoon-it-fw-1.0.1/<https://svn.apache.org/repos/asf/cocoon/subprojects/cocoon-it-fw/tags/cocoon-it-fw-1.0.1/>
>
> List of changes:
> https://svn.apache.org/repos/**asf/cocoon/subprojects/cocoon-**
> it-fw/tags/cocoon-it-fw-1.0.1/**src/changes/changes.xml<https://svn.apache.org/repos/asf/cocoon/subprojects/cocoon-it-fw/tags/cocoon-it-fw-1.0.1/src/changes/changes.xml>
>
> Maven staging repo:
> https://repository.apache.org/**content/repositories/**
> orgapachecocoon-007/<https://repository.apache.org/content/repositories/orgapachecocoon-007/>
>
> Source release (checksums and signatures are available at the same
> location):
> https://repository.apache.org/**content/repositories/**
> orgapachecocoon-007/org/**apache/cocoon/cocoon-it-fw/1.**
> 0.1/cocoon-it-fw-1.0.1-source-**release.zip<https://repository.apache.org/content/repositories/orgapachecocoon-007/org/apache/cocoon/cocoon-it-fw/1.0.1/cocoon-it-fw-1.0.1-source-release.zip>
>
> PGP release keys (signed using 273DF287):
> http://www.apache.org/dist/**cocoon/KEYS<http://www.apache.org/dist/cocoon/KEYS>
>
> Vote will be open for 72 hours.
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> --
> Francesco Chicchiriccò
>
> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
> http://people.apache.org/~**ilgrosso/<http://people.apache.org/~ilgrosso/>
>



-- 
Thorsten Scherler 
codeBusters S.L. - web based systems


Tel.: +34 954 520 169
http://www.codebusters.es/

[jira] [Commented] (COCOON3-105) webapp fails if on the same servlet container is a c2.2.1 or other c3 webapp running

2012-12-08 Thread Thorsten Scherler (JIRA)


[ 
https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13527302#comment-13527302
 ] 

Thorsten Scherler commented on COCOON3-105:
---

I tried but I get 
SEVERE: Error configuring application listener of class 
org.apache.cocoon.blockdeployment.BlockDeploymentServletContextListener
java.lang.ClassNotFoundException: 
org.apache.cocoon.blockdeployment.BlockDeploymentServletContextListener
at 
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1714)
at 
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1559)
at 
org.apache.catalina.core.DefaultInstanceManager.loadClass(DefaultInstanceManager.java:532)
at 
org.apache.catalina.core.DefaultInstanceManager.loadClassMaybePrivileged(DefaultInstanceManager.java:514)
at org.apache.catalin

Running the resulting war of my clone in tomcat apache-tomcat-7.0.33

need to check again the patch whether everything was applied - on second 
thought I need to double check the subprojects.

> webapp fails if on the same servlet container is a c2.2.1 or other c3 webapp 
> running 
> -
>
> Key: COCOON3-105
> URL: https://issues.apache.org/jira/browse/COCOON3-105
> Project: Cocoon 3
>  Issue Type: Bug
>  Components: cocoon-webapp
>Affects Versions: 3.0.0-beta-1
>    Reporter: Thorsten Scherler
>Assignee: Francesco Chicchiriccò
>Priority: Blocker
> Fix For: 3.0.0-beta-1
>
> Attachments: COCOON3-105.npe.diff, COCOON3-105.patch, 
> cocoon-block-deployment.patch, cocoon-servlet-service-impl.patch
>
>
> I noticed that you cannot run 2 c3 based war in a tomcat.
> To reproduce:
> - seed parent via archetype
> - seed block in parent via archetype
> - seed block2 in parent via archetype
> - seed webapp in parent via archetype
> - seed webapp2 in parent via archetype
> where webapp depends on block one and webapp2 depends on block2.
> My sample was:
> [INFO] Reactor Summary:
> [INFO] 
> [INFO] myparent .. SUCCESS [1.163s]
> [INFO] myblock ... SUCCESS [3.611s]
> [INFO] mywebapp .. SUCCESS [1.924s]
> [INFO] myblock2 .. SUCCESS [1.498s]
> [INFO] mywebapp2 . SUCCESS [1.230s]
> [INFO] 
> 
> Now take a tomcat (I used 6) and first deploy the mywebapp. You can copy it 
> before you start to webapp or if you have it enable deploy it on a running 
> instance. You should see the welcome page under something like 
> http://localhost:8080/mywebapp-1.0-SNAPSHOT/
> side note: http://localhost:8080/mywebapp-1.0-SNAPSHOT will throw a 
> StringIndexOutOfBoundsException but that is another ticket I guess.
> Now if you deploy the second webapp on a running instance it will deploy 
> without problem but requesting 
> http://localhost:8080/mywebapp2-1.0-SNAPSHOT/
> will return a blank page and in 
> /.../tomcat/work/Catalina/localhost/mywebapp-1.0-SNAPSHOT/cocoon.log
> you find:
> 2012-09-13 22:12:46,056 ERROR http-8080-1 
> org.apache.cocoon.servlet.XMLSitemapServlet - Can't initialize the 
> RequestProcessor correctly.
> org.apache.cocoon.sitemap.SitemapBuilder$SitemapBuilderException: Can't build 
> sitemap from blockcontext:/myblock2/sitemap.xmap
>   at 
> org.apache.cocoon.sitemap.SitemapBuilder.build(SitemapBuilder.java:70) 
> ~[cocoon-sitemap-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT]
>   at 
> org.apache.cocoon.servlet.RequestProcessor.initializeSitemap(RequestProcessor.java:203)
>  ~[cocoon-servlet-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT]
> ...
> Caused by: java.lang.RuntimeException: There is no block 'myblock2' deployed. 
> The available blocks are 
> {myblock=file:/home/thorsten/src/apache/apache-tomcat-6.0.20/work/Catalina/localhost/mywebapp-1.0-SNAPSHOT/blocks/myblock/}.
>   at 
> org.apache.cocoon.blockdeployment.BlockContextURLConnection.getConnection(BlockContextURLConnection.java:76)
>  ~[cocoon-block-deployment-1.2.1.jar:1.2.1]
>   at 
> org.apache.cocoon.blockdeployment.BlockContextURLConnection.getInputStream(BlockContextURLConnection.java:56)
>  ~[cocoon-block-deployment-1.2.1.jar:1.2.1]
>   at java.net.URL.openStream(URL.java:1010) ~[na:1.6.0_30]
>   at 
> org.apache.cocoon.sitemap.SitemapBuilder.build(SitemapBuil

[jira] [Commented] (COCOON3-112) JCommander is updated to 1.30

2012-11-27 Thread Thorsten Scherler (JIRA)


[ 
https://issues.apache.org/jira/browse/COCOON3-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504568#comment-13504568
 ] 

Thorsten Scherler commented on COCOON3-112:
---

can you provide a patch, please?

> JCommander is updated to 1.30
> -
>
> Key: COCOON3-112
> URL: https://issues.apache.org/jira/browse/COCOON3-112
> Project: Cocoon 3
>  Issue Type: Improvement
>  Components: cocoon-cli
>Reporter: ZhiQiang,He
>Priority: Trivial
>
> This is just a tip.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [DISCUSS] Release plan

2012-11-17 Thread Thorsten Scherler

On 11/12/2012 10:25 AM, Francesco Chicchiriccò wrote:
> ...
> =
>
> My questions now are:
>
>  1. Would you agree with the above drafted release plan?

Yes, with a 2.1 release, since I recall there had been a couple of changes.

>
>  2. If so, who is available to help with these tasks? Consider that
> documentation tasks are an easier way to contribute to the project even
> without development skills.

In 2002 I started exactly in this project with documentation. The
initial purpose of cocoon was to generate consistence documentation for
java.apache.org meaning to write some cocoon docs (esp. c3) be sure you
pop onto our watch list.

>
> If you've been using C3 and appreciate this, please don't deny your
> help: we really need it!

c3 is really missing helping hands. I would love to get some cocoon
veterans reactivated again especially for the OSGI re-factoring that we
need to do in the future.  This project is as old as the ASF itself and
we have a long list of prime ASF member contributing to this project.
However I understand that we all only have very limited time.

...but for everyone that is reading this and like the idea of cocoon
please help with

- constructive discussions and giving the helping hand on the ml
- documentation
- testing and bug fixing
- integrating c3 in your project

salu2
PS thanks Francesco for starting this and it had been a pleasure to meet
you in person.

-- 
Thorsten Scherler 
codeBusters S.L. - web based systems

http://www.codebusters.es/

[jira] [Updated] (COCOON3-107) With latest cocoon-block-deployment and cocoon-service-impl SNAPSHOTs, integration tests fail

2012-10-23 Thread Thorsten Scherler (JIRA)


 [ 
https://issues.apache.org/jira/browse/COCOON3-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thorsten Scherler updated COCOON3-107:
--

Attachment: BlockcontextInterpreter.java

Slimed down version - without client deps ;)

> With latest cocoon-block-deployment and cocoon-service-impl SNAPSHOTs, 
> integration tests fail
> -
>
> Key: COCOON3-107
> URL: https://issues.apache.org/jira/browse/COCOON3-107
> Project: Cocoon 3
>  Issue Type: Bug
>  Components: cocoon-sample-webapp, cocoon-servlet, cocoon-sitemap
>Affects Versions: 3.0.0-beta-1
>Reporter: Francesco Chicchiriccò
>Priority: Critical
> Fix For: 3.0.0-beta-1
>
> Attachments: BlockcontextInterpreter.java, 
> BlockcontextInterpreter.java
>
>
> This is happening as a consequence of COCOON3-105, by upgrading 
> cocoon-servlet-service-impl to 1.3.2-SNAPSHOT and cocoon-block-deployment to 
> 1.2.2-SNAPSHOT
> Basically, since there is no more an installed URLStreamHandlerFactory, every 
> "new URL()" should include an instance of BlockContextURLStreamHandler.
> This makes every other URL loading (including XSLT sheets in a separate 
> block, like happening for cocoon-sample-webapp) unaware of "blockcontext://" 
> URLs.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (COCOON3-107) With latest cocoon-block-deployment and cocoon-service-impl SNAPSHOTs, integration tests fail

2012-10-23 Thread Thorsten Scherler (JIRA)


[ 
https://issues.apache.org/jira/browse/COCOON3-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482880#comment-13482880
 ] 

Thorsten Scherler commented on COCOON3-107:
---

add  to your 
app context then use it in your sitemap as {blockcontext:raw-to-internal.xsl} 
where raw-to-internal.xsl would be resolved against the current blockservice 
file uri.

> With latest cocoon-block-deployment and cocoon-service-impl SNAPSHOTs, 
> integration tests fail
> -
>
> Key: COCOON3-107
> URL: https://issues.apache.org/jira/browse/COCOON3-107
> Project: Cocoon 3
>  Issue Type: Bug
>  Components: cocoon-sample-webapp, cocoon-servlet, cocoon-sitemap
>Affects Versions: 3.0.0-beta-1
>Reporter: Francesco Chicchiriccò
>Priority: Critical
> Fix For: 3.0.0-beta-1
>
> Attachments: BlockcontextInterpreter.java
>
>
> This is happening as a consequence of COCOON3-105, by upgrading 
> cocoon-servlet-service-impl to 1.3.2-SNAPSHOT and cocoon-block-deployment to 
> 1.2.2-SNAPSHOT
> Basically, since there is no more an installed URLStreamHandlerFactory, every 
> "new URL()" should include an instance of BlockContextURLStreamHandler.
> This makes every other URL loading (including XSLT sheets in a separate 
> block, like happening for cocoon-sample-webapp) unaware of "blockcontext://" 
> URLs.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (COCOON3-107) With latest cocoon-block-deployment and cocoon-service-impl SNAPSHOTs, integration tests fail

2012-10-23 Thread Thorsten Scherler (JIRA)


 [ 
https://issues.apache.org/jira/browse/COCOON3-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thorsten Scherler updated COCOON3-107:
--

Attachment: BlockcontextInterpreter.java

interpreter to resolve blockcontext against actual file system

> With latest cocoon-block-deployment and cocoon-service-impl SNAPSHOTs, 
> integration tests fail
> -
>
> Key: COCOON3-107
> URL: https://issues.apache.org/jira/browse/COCOON3-107
> Project: Cocoon 3
>  Issue Type: Bug
>  Components: cocoon-sample-webapp, cocoon-servlet, cocoon-sitemap
>Affects Versions: 3.0.0-beta-1
>Reporter: Francesco Chicchiriccò
>Priority: Critical
> Fix For: 3.0.0-beta-1
>
> Attachments: BlockcontextInterpreter.java
>
>
> This is happening as a consequence of COCOON3-105, by upgrading 
> cocoon-servlet-service-impl to 1.3.2-SNAPSHOT and cocoon-block-deployment to 
> 1.2.2-SNAPSHOT
> Basically, since there is no more an installed URLStreamHandlerFactory, every 
> "new URL()" should include an instance of BlockContextURLStreamHandler.
> This makes every other URL loading (including XSLT sheets in a separate 
> block, like happening for cocoon-sample-webapp) unaware of "blockcontext://" 
> URLs.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Cocoon Get Together on ACEU 2012 Sinsheim (was Re: Cocoon presentation link and questions about new contributions)

2012-10-11 Thread Thorsten Scherler


On 10/11/2012 09:22 AM, Francesco Chicchiriccò wrote:

On 11/10/2012 00:38, Javier Puerto wrote:
...

I hope to see you soon in the ApacheCon,

Yep, me too: who's coming??? Chance to have a small Cocoon Get Together
(or just a beer) there?


Hi all,

I was up to write a similar mail asking about a CGT.

We from codebusters.es will come in total 4 pers. Andy tries to come as 
well and Simone and Francesco are there since they are speakers. Meaning 
we have a pretty strong group and should get together to get some work 
on cocoon done and directly commit it. ;)


codebusters.es is right now moving papers to be official sponsor for a 
CocoonGetTogether on ACEU 2012 so that we could get some drink and food 
for the hackathon.


What is the best day for everyone? I guess Monday 05.11 would be the 
best day, or?


BTW 3 of us will fly in already on 1.11 and the 4th will come on the 
4th. We booked a private house in the area and plan to see some sights 
on the weekend. If somebody is interested in a private house I have some 
contacts that still may have some space left, further if somebody is 
interested to get a beer on the weekend before let us talk. ;)


salu2

--
Thorsten Scherler 
codeBusters S.L. - web based systems


http://www.codebusters.es/

Re: Nexus staging repository???

2012-10-10 Thread Thorsten Scherler


On 10/10/2012 04:10 PM, Francesco Chicchiriccò wrote:

On 10/10/2012 16:07, Thorsten Scherler wrote:

On 10/08/2012 11:23 AM, Francesco Chicchiriccò wrote:

Hi,
I've just noticed an open staging repository on Nexus
(org.apache.cocoon-054) opened by Thorsten last Sep 11th.

Could it be removed?

Regards.



Sorry, did not read the mail the first time correctly and Javier just 
pointed it out to me.


...teamwork ;-)

I guess that was an intend to deploy some artifacts. Yes please you 
can remove it again.


Done.

Regards.




thanks

salu2

--
Thorsten Scherler 
codeBusters S.L. - web based systems


http://www.codebusters.es/

Re: Nexus staging repository???

2012-10-10 Thread Thorsten Scherler


On 10/08/2012 11:23 AM, Francesco Chicchiriccò wrote:

Hi,
I've just noticed an open staging repository on Nexus
(org.apache.cocoon-054) opened by Thorsten last Sep 11th.

Could it be removed?

Regards.



Sorry, did not read the mail the first time correctly and Javier just 
pointed it out to me.


I guess that was an intend to deploy some artifacts. Yes please you can 
remove it again.


salu2


--
Thorsten Scherler 
codeBusters S.L. - web based systems


http://www.codebusters.es/

[jira] [Closed] (COCOON-2302) C2.2 : unable to find daisy-..-1.5 jars in rev 959219

2012-10-02 Thread Thorsten Scherler (JIRA)


 [ 
https://issues.apache.org/jira/browse/COCOON-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thorsten Scherler closed COCOON-2302.
-

Resolution: Fixed

Committed revision 1392864.

Fixing groupId and repository location for the daisyplugin. BTW do we really 
use that still?

> C2.2 : unable to find daisy-..-1.5 jars in rev 959219
> -
>
> Key: COCOON-2302
> URL: https://issues.apache.org/jira/browse/COCOON-2302
> Project: Cocoon
>  Issue Type: Bug
>  Components: - Build System: Maven
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Florent ANDRE
>
> Hi,
> On a fresh co of cocoon trunk give me this errors when mvn install.
> Find this repository (http://daisycms.org/maven/maven2/dev/), but there is 
> just 2.5 versions of libs.
> Ugrade dependencies to 2.5 or another 1.5 repository ?
> Thanks.
> INFO] Unable to find resource 'daisy:daisy-util:jar:1.5-dev' in repository 
> gkossakowski-maven2 (http://people.apache.org/~gkossakowski/maven2/repository)
> [INFO] 
> 
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] Failed to resolve artifact.
> Missing:
> --
> 1) daisy:daisy-repository-api:jar:1.5-dev
>   Try downloading the file manually from the project website.
>   Then, install it using the command:
>   mvn install:install-file -DgroupId=daisy 
> -DartifactId=daisy-repository-api -Dversion=1.5-dev -Dpackaging=jar 
> -Dfile=/path/to/file
>   Alternatively, if you host your own repository you can deploy the file 
> there:
>   mvn deploy:deploy-file -DgroupId=daisy 
> -DartifactId=daisy-repository-api -Dversion=1.5-dev -Dpackaging=jar 
> -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
>   Path to dependency:
>   1) 
> org.apache.cocoon:cocoon-sitemaptags2daisy-plugin:maven-plugin:1.0.0-SNAPSHOT
>   2) daisy:daisy-repository-api:jar:1.5-dev
> 2) nekodtd:nekodtd:jar:0.1.11
>   Try downloading the file manually from the project website.
>   Then, install it using the command:
>   mvn install:install-file -DgroupId=nekodtd -DartifactId=nekodtd 
> -Dversion=0.1.11 -Dpackaging=jar -Dfile=/path/to/file
>   Alternatively, if you host your own repository you can deploy the file 
> there:
>   mvn deploy:deploy-file -DgroupId=nekodtd -DartifactId=nekodtd 
> -Dversion=0.1.11 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] 
> -DrepositoryId=[id]
>   Path to dependency:
>   1) 
> org.apache.cocoon:cocoon-sitemaptags2daisy-plugin:maven-plugin:1.0.0-SNAPSHOT
>   2) nekodtd:nekodtd:jar:0.1.11
> 3) daisy:daisy-repository-xmlschema-bindings:jar:1.5-dev
>   Try downloading the file manually from the project website.
>   Then, install it using the command:
>   mvn install:install-file -DgroupId=daisy 
> -DartifactId=daisy-repository-xmlschema-bindings -Dversion=1.5-dev 
> -Dpackaging=jar -Dfile=/path/to/file
>   Alternatively, if you host your own repository you can deploy the file 
> there:
>   mvn deploy:deploy-file -DgroupId=daisy 
> -DartifactId=daisy-repository-xmlschema-bindings -Dversion=1.5-dev 
> -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
>   Path to dependency:
>   1) 
> org.apache.cocoon:cocoon-sitemaptags2daisy-plugin:maven-plugin:1.0.0-SNAPSHOT
>   2) daisy:daisy-repository-xmlschema-bindings:jar:1.5-dev
> 4) daisy:daisy-repository-client-impl:jar:1.5-dev
>   Try downloading the file manually from the project website.
>   Then, install it using the command:
>   mvn install:install-file -DgroupId=daisy 
> -DartifactId=daisy-repository-client-impl -Dversion=1.5-dev -Dpackaging=jar 
> -Dfile=/path/to/file
>   Alternatively, if you host your own repository you can deploy the file 
> there:
>   mvn deploy:deploy-file -DgroupId=daisy 
> -DartifactId=daisy-repository-client-impl -Dversion=1.5-dev -Dpackaging=jar 
> -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
>   Path to dependency:
>   1) 
> org.apache.cocoon:cocoon-sitemaptags2daisy-plugin:maven-plugin:1.0.0-SNAPSHOT
>   2) daisy:daisy-repository-client-impl:jar:1.5-dev
> 5) daisy:daisy-repository-common-impl:jar:1.5-dev
>   Try downloading the file manually from the project website.
>   Then, install it using the command:
>   mvn install:install-file -DgroupId=daisy 
> -DartifactId=daisy-repository-common-impl -Dversion=1.5-dev -Dpackaging=jar 
> -Dfile=/path/to/file
>   Alternatively, if you host your own

[jira] [Reopened] (COCOON-2302) C2.2 : unable to find daisy-..-1.5 jars in rev 959219

2012-10-02 Thread Thorsten Scherler (JIRA)


 [ 
https://issues.apache.org/jira/browse/COCOON-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thorsten Scherler reopened COCOON-2302:
---

  Assignee: (was: Francesco Chicchiriccò)

The bug is not fixed.

I fixed some bad markup in r1392857 but I can see the error afterwards on the 
neko stuff.

> C2.2 : unable to find daisy-..-1.5 jars in rev 959219
> -
>
> Key: COCOON-2302
> URL: https://issues.apache.org/jira/browse/COCOON-2302
> Project: Cocoon
>  Issue Type: Bug
>  Components: - Build System: Maven
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Florent ANDRE
>
> Hi,
> On a fresh co of cocoon trunk give me this errors when mvn install.
> Find this repository (http://daisycms.org/maven/maven2/dev/), but there is 
> just 2.5 versions of libs.
> Ugrade dependencies to 2.5 or another 1.5 repository ?
> Thanks.
> INFO] Unable to find resource 'daisy:daisy-util:jar:1.5-dev' in repository 
> gkossakowski-maven2 (http://people.apache.org/~gkossakowski/maven2/repository)
> [INFO] 
> 
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] Failed to resolve artifact.
> Missing:
> --
> 1) daisy:daisy-repository-api:jar:1.5-dev
>   Try downloading the file manually from the project website.
>   Then, install it using the command:
>   mvn install:install-file -DgroupId=daisy 
> -DartifactId=daisy-repository-api -Dversion=1.5-dev -Dpackaging=jar 
> -Dfile=/path/to/file
>   Alternatively, if you host your own repository you can deploy the file 
> there:
>   mvn deploy:deploy-file -DgroupId=daisy 
> -DartifactId=daisy-repository-api -Dversion=1.5-dev -Dpackaging=jar 
> -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
>   Path to dependency:
>   1) 
> org.apache.cocoon:cocoon-sitemaptags2daisy-plugin:maven-plugin:1.0.0-SNAPSHOT
>   2) daisy:daisy-repository-api:jar:1.5-dev
> 2) nekodtd:nekodtd:jar:0.1.11
>   Try downloading the file manually from the project website.
>   Then, install it using the command:
>   mvn install:install-file -DgroupId=nekodtd -DartifactId=nekodtd 
> -Dversion=0.1.11 -Dpackaging=jar -Dfile=/path/to/file
>   Alternatively, if you host your own repository you can deploy the file 
> there:
>   mvn deploy:deploy-file -DgroupId=nekodtd -DartifactId=nekodtd 
> -Dversion=0.1.11 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] 
> -DrepositoryId=[id]
>   Path to dependency:
>   1) 
> org.apache.cocoon:cocoon-sitemaptags2daisy-plugin:maven-plugin:1.0.0-SNAPSHOT
>   2) nekodtd:nekodtd:jar:0.1.11
> 3) daisy:daisy-repository-xmlschema-bindings:jar:1.5-dev
>   Try downloading the file manually from the project website.
>   Then, install it using the command:
>   mvn install:install-file -DgroupId=daisy 
> -DartifactId=daisy-repository-xmlschema-bindings -Dversion=1.5-dev 
> -Dpackaging=jar -Dfile=/path/to/file
>   Alternatively, if you host your own repository you can deploy the file 
> there:
>   mvn deploy:deploy-file -DgroupId=daisy 
> -DartifactId=daisy-repository-xmlschema-bindings -Dversion=1.5-dev 
> -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
>   Path to dependency:
>   1) 
> org.apache.cocoon:cocoon-sitemaptags2daisy-plugin:maven-plugin:1.0.0-SNAPSHOT
>   2) daisy:daisy-repository-xmlschema-bindings:jar:1.5-dev
> 4) daisy:daisy-repository-client-impl:jar:1.5-dev
>   Try downloading the file manually from the project website.
>   Then, install it using the command:
>   mvn install:install-file -DgroupId=daisy 
> -DartifactId=daisy-repository-client-impl -Dversion=1.5-dev -Dpackaging=jar 
> -Dfile=/path/to/file
>   Alternatively, if you host your own repository you can deploy the file 
> there:
>   mvn deploy:deploy-file -DgroupId=daisy 
> -DartifactId=daisy-repository-client-impl -Dversion=1.5-dev -Dpackaging=jar 
> -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
>   Path to dependency:
>   1) 
> org.apache.cocoon:cocoon-sitemaptags2daisy-plugin:maven-plugin:1.0.0-SNAPSHOT
>   2) daisy:daisy-repository-client-impl:jar:1.5-dev
> 5) daisy:daisy-repository-common-impl:jar:1.5-dev
>   Try downloading the file manually from the project website.
>   Then, install it using the command:
>   mvn install:install-file -DgroupId=daisy 
> -DartifactId=daisy-repository-common-impl -Dversion=1.5-dev -Dpackaging=jar 
> -Dfile=/path/to/file
>   Alterna

Re: blockcontext protocol (part 2) (was Re: [jira] [Created] (COCOON3-107) ...)

2012-09-28 Thread Thorsten Scherler


On 09/28/2012 02:41 PM, Jos Snellings wrote:

Thanks, Thorsten, that makes it a lot clearer.
I will give it a second thought and get back.
Just another question: are there other use cases than:
- within xslt : document() construct
- sitemap
- controller->modelAndView
?


Actually since you brought up cocoon:// protocol I think one possible 
solution is DROP the blockcontext protocol and force to expose all 
static matches via the sitemap. This way the calling instance would need 
to use the servlet protocol and there should no problem any more.


Not sure whether you remember the context:/ in c2.1.x which simply 
pointed to the underlying serlvet context path. The blockcontext is 
based on the same idea. You can reach the path where the actually block 
is deployed (within the calling servlet is to say). However as I see it 
the only real need to know that path is when we deploy the blocks (where 
francesco path works), meaning if we do not use it otherwise the issue 
is fixed.


Now that we reanimated the thread, has anyone else ideas? I feel it is 
an important issue and I would love to see it solved,
as I have myself two cocoon apps that I would like to deploy to one 
server.




Well if they are both c3 based that is ATM broken and I agree that this 
is an important issue since it renders c3 useless if we not fix it.


salu2


Kind regards,
Jos

On Fri, Sep 28, 2012 at 2:29 PM, Thorsten Scherler <mailto:scher...@gmail.com>> wrote:


On 09/28/2012 07:24 AM, Jos Snellings wrote:

Dear all,

Noticing that is very interesting discussion is getting silent,
I'd like to ask a question.
First of all, pardon me my ignorance. (blonde, can't help it).
So from just a high-level understanding, can I rephrase the problem?
What we seek to accomplish is:
* in a sitemap, being able to load resources from another sitemap,
  according to the scheme:
  
* within an xslt calling

* within controller logic:  redirect, or send the reference of a
ModelAndView


Well the cocoon:/ is/was never a java.net <http://java.net>
handler but resolved via avalon/excalibur. Further the c3
correspond  would be more servlet:/




So now, in C3, we want to address resources cross-block to
accomplish modularity, right?




well yes and no. blockcontext:/ refers to static (resources) and
not matches in the blockcontext sitemap. If you would want to call
the block sitemap you would request servlet:${blockId}:/...




This should be restricted to the instance of the cocoon servlet
itself, so it can peacefully coexist with another cocoon servlet
in the same JVM.


The blockcontext protocol once installed only will work for the
first called servlet. With the change of Fran. we do what you
describe but on a specific point in the app. BUT we never install
the protocol which makes it unusable outside the java route where
you can pass a URLHandler to the context.


So you would like to avoid tweaking "URL" for the servlet without
interfering with the rest.

- something less invasive than URL.setURLStreamHandlerFactory ?
- mechanism that keeps track of wich cocoon servlet deployed wich
blocks?

Is that a correct way of stating it? Not even my 10 cents, just a
question.


If we want to keep using blockcontext protocol, the handler needs
a central place where the different paths are resolved. However
due to the nature of the problem we can have the same name for a
block in 2 different servlet but if we resolve the url in the
connection we will have the problem deciding which path to return
to the caller, since it can happen that the underlying request has
no servlet context associated meaning it is impossible to
determine which block to use.

Thanks for keeping the thread alive.

salu2




Cheers,
Jos


On Wed, Sep 26, 2012 at 3:05 PM, Thorsten Scherler
mailto:scher...@gmail.com>> wrote:

On 09/26/2012 10:10 AM, Francesco Chicchiriccò (JIRA) wrote:

Francesco Chicchiriccò created COCOON3-107:
--

  Summary: With latest
cocoon-block-deployment and cocoon-service-impl
SNAPSHOTs, integration tests fail
  Key: COCOON3-107
  URL:
https://issues.apache.org/jira/browse/COCOON3-107
  Project: Cocoon 3
   Issue Type: Bug
   Components: cocoon-sample-webapp,
cocoon-servlet, cocoon-sitemap
 Affects Versions: 3.0.0-beta-1
 Reporter: Francesco Chicchiriccò
 Priority: Critical
  Fix For: 3.0.0-beta-1


This is happening as a consequence of COCOON3-10

Re: blockcontext protocol (part 2) (was Re: [jira] [Created] (COCOON3-107) ...)

2012-09-28 Thread Thorsten Scherler

On 09/28/2012 07:24 AM, Jos Snellings wrote:

Dear all,

Noticing that is very interesting discussion is getting silent, I'd
like to ask a question.

First of all, pardon me my ignorance. (blonde, can't help it).
So from just a high-level understanding, can I rephrase the problem?
What we seek to accomplish is:
* in a sitemap, being able to load resources from another sitemap,
according to the scheme:

* within an xslt calling

* within controller logic: redirect, or send the reference of a
ModelAndView

Well the cocoon:/ is/was never a java.net handler but resolved via
avalon/excalibur. Further the c3 correspond would be more servlet:/

So now, in C3, we want to address resources cross-block to accomplish
modularity, right?

well yes and no. blockcontext:/ refers to static (resources) and not
matches in the blockcontext sitemap. If you would want to call the block
sitemap you would request servlet:${blockId}:/...

This should be restricted to the instance of the cocoon servlet
itself, so it can peacefully coexist with another cocoon servlet in
the same JVM.

The blockcontext protocol once installed only will work for the first
called servlet. With the change of Fran. we do what you describe but on
a specific point in the app. BUT we never install the protocol which
makes it unusable outside the java route where you can pass a URLHandler
to the context.

So you would like to avoid tweaking "URL" for the servlet without
interfering with the rest.

- something less invasive than URL.setURLStreamHandlerFactory ?
- mechanism that keeps track of wich cocoon servlet deployed wich blocks?

Is that a correct way of stating it? Not even my 10 cents, just a
question.

If we want to keep using blockcontext protocol, the handler needs a
central place where the different paths are resolved. However due to the
nature of the problem we can have the same name for a block in 2
different servlet but if we resolve the url in the connection we will
have the problem deciding which path to return to the caller, since it
can happen that the underlying request has no servlet context associated
meaning it is impossible to determine which block to use.

Thanks for keeping the thread alive.

salu2

Cheers,
Jos

On Wed, Sep 26, 2012 at 3:05 PM, Thorsten Scherler <mailto:scher...@gmail.com>> wrote:

On 09/26/2012 10:10 AM, Francesco Chicchiriccò (JIRA) wrote:

Francesco Chicchiriccò created COCOON3-107:
--

Summary: With latest cocoon-block-deployment and
cocoon-service-impl SNAPSHOTs, integration tests fail
Key: COCOON3-107
URL:
https://issues.apache.org/jira/browse/COCOON3-107
Project: Cocoon 3
Issue Type: Bug
Components: cocoon-sample-webapp, cocoon-servlet,
cocoon-sitemap
Affects Versions: 3.0.0-beta-1
Reporter: Francesco Chicchiriccò
Priority: Critical
Fix For: 3.0.0-beta-1

This is happening as a consequence of COCOON3-105.

Basically, since there is no more an installed
URLStreamHandlerFactory, every "new URL()" should include an
instance of BlockContextURLStreamHandler.

This makes every other URL loading (including XSLT sheets in a
separate block, like happening for cocoon-sample-webapp)
unaware of "blockcontext://" URLs.

Meaning we are back to square one.

Andreas Hartman is ATM in our office and we had a small chat about
the underlying problem.
We think that blockcontext cannot work as protocol as it is for now.

The above report shows that we need to use a
URLStreamHandlerFactory to be able to resolve this protocol.

{myblock2=file:/home/thorsten/src/apache/apache-tomcat-6.0.20/work/Catalina/localhost/mywebapp2-1.0-SNAPSHOT/blocks/myblock2/}

Now if we look on the above and how we defined it, we have:

in block-servlet-service.xml

will then produce the following blockcontext object:
${blockId}=${tomcat.work}/${servlet_which uses the
block}/blocks/${blockId}/

Meaning that blockcontext:/ will be resolved to
"${tomcat.work}/${servlet_which uses the block}/blocks/"

There are various problematic parts:

blockcontext protocol (part 2) (was Re: [jira] [Created] (COCOON3-107) ...)

2012-09-26 Thread Thorsten Scherler

On 09/26/2012 10:10 AM, Francesco Chicchiriccò (JIRA) wrote:

Francesco Chicchiriccò created COCOON3-107:
--

Summary: With latest cocoon-block-deployment and
cocoon-service-impl SNAPSHOTs, integration tests fail
Key: COCOON3-107
URL: https://issues.apache.org/jira/browse/COCOON3-107
Project: Cocoon 3
Issue Type: Bug
Components: cocoon-sample-webapp, cocoon-servlet, cocoon-sitemap
Affects Versions: 3.0.0-beta-1
Reporter: Francesco Chicchiriccò
Priority: Critical
Fix For: 3.0.0-beta-1

This is happening as a consequence of COCOON3-105.

Basically, since there is no more an installed URLStreamHandlerFactory, every "new
URL()" should include an instance of BlockContextURLStreamHandler.

This makes every other URL loading (including XSLT sheets in a separate block, like
happening for cocoon-sample-webapp) unaware of "blockcontext://" URLs.

Meaning we are back to square one.

Andreas Hartman is ATM in our office and we had a small chat about the
underlying problem.

We think that blockcontext cannot work as protocol as it is for now.

The above report shows that we need to use a URLStreamHandlerFactory to
be able to resolve this protocol.

{myblock2=file:/home/thorsten/src/apache/apache-tomcat-6.0.20/work/Catalina/localhost/mywebapp2-1.0-SNAPSHOT/blocks/myblock2/}

Now if we look on the above and how we defined it, we have:

in block-servlet-service.xml

context-path="blockcontext:/${blockId}/"/>

will then produce the following blockcontext object:
${blockId}=${tomcat.work}/${servlet_which uses the block}/blocks/${blockId}/

Meaning that blockcontext:/ will be resolved to
"${tomcat.work}/${servlet_which uses the block}/blocks/"

There are various problematic parts:

As of the looks of it a block is treated as "servlet" mounted to a
context. Problematic is that the mount-path in some cases needs to
become ="" to catch all incoming request, which means root context.
Blocks are treated as servlets meaning you can only mount once a block
(in a specific version of that block). If another block use this blockId
it is not possible to use the same mount point. However that has the
ultimate consequence that you need to manage the name of your block
manually or ideally the ${blockId} is unique and contains the version of
the block!
However blocks are more servlets within a servlet, since without a
servlet that has deps on them they would be not reachable.

This leads to to the "real" mount point "${servlet_which uses the
block}/{@mount-path_as defined in the block}" in the servlet context and
the path as above. For example "blockcontext:/test" could refer to
"${tomcat.work}/${servlet1}/blocks/test" or
"${tomcat.work}/${servlet2}/blocks/test", depending from which servlet
the request is issued. Meaning the blockcontext protocol does not
resolve url (Uniform (or universal) resource locator) since the
resources it describes are not universal (due to the fixed connection to
the underlying servlet).

With all the above said the logical consequence is that the pattern of
blockcontext would need the ${servlet_which uses the block} in it
somewhere, but that would render the whole block concept useless if used
within the block. That however would force a url rewritting on the fly
where the ${servlet_which uses the block} prefixed would be injected
prior of resolving.

We tested to push the resolving logic into the handler but that failed
since some calls have no resolvable servlet context while they issue the
call. We succeed to inject the handler in the servlet context but never
declared an UrlFactory so xsl imports e.g. are failing now since they do
not know about our handler.

In the old days (2.1.x) we had our avalon/exaclibur source resolver for
creating custom protocols within a specific context - with them above
would not have been a prob.

Anyway, how can we refactor the blockcontext so we can deploy more then
one c3 webapp? Any ideas?

salu2

--
Thorsten Scherler
codeBusters S.L. - web based systems

http://www.codebusters.es/

[jira] [Closed] (COCOON3-105) webapp fails if on the same servlet container is a c2.2.1 or other c3 webapp running

2012-09-25 Thread Thorsten Scherler (JIRA)


 [ 
https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thorsten Scherler closed COCOON3-105.
-

   Resolution: Fixed
Fix Version/s: 3.0.0-beta-1

last commit around the issue r1389820.

snapshots are deployed as well.

> webapp fails if on the same servlet container is a c2.2.1 or other c3 webapp 
> running 
> -
>
> Key: COCOON3-105
> URL: https://issues.apache.org/jira/browse/COCOON3-105
> Project: Cocoon 3
>  Issue Type: Bug
>  Components: cocoon-webapp
>Affects Versions: 3.0.0-beta-1
>    Reporter: Thorsten Scherler
>Priority: Blocker
> Fix For: 3.0.0-beta-1
>
> Attachments: COCOON3-105.npe.diff, cocoon-block-deployment.patch, 
> cocoon-servlet-service-impl.patch
>
>
> I noticed that you cannot run 2 c3 based war in a tomcat.
> To reproduce:
> - seed parent via archetype
> - seed block in parent via archetype
> - seed block2 in parent via archetype
> - seed webapp in parent via archetype
> - seed webapp2 in parent via archetype
> where webapp depends on block one and webapp2 depends on block2.
> My sample was:
> [INFO] Reactor Summary:
> [INFO] 
> [INFO] myparent .. SUCCESS [1.163s]
> [INFO] myblock ... SUCCESS [3.611s]
> [INFO] mywebapp .. SUCCESS [1.924s]
> [INFO] myblock2 .. SUCCESS [1.498s]
> [INFO] mywebapp2 . SUCCESS [1.230s]
> [INFO] 
> 
> Now take a tomcat (I used 6) and first deploy the mywebapp. You can copy it 
> before you start to webapp or if you have it enable deploy it on a running 
> instance. You should see the welcome page under something like 
> http://localhost:8080/mywebapp-1.0-SNAPSHOT/
> side note: http://localhost:8080/mywebapp-1.0-SNAPSHOT will throw a 
> StringIndexOutOfBoundsException but that is another ticket I guess.
> Now if you deploy the second webapp on a running instance it will deploy 
> without problem but requesting 
> http://localhost:8080/mywebapp2-1.0-SNAPSHOT/
> will return a blank page and in 
> /.../tomcat/work/Catalina/localhost/mywebapp-1.0-SNAPSHOT/cocoon.log
> you find:
> 2012-09-13 22:12:46,056 ERROR http-8080-1 
> org.apache.cocoon.servlet.XMLSitemapServlet - Can't initialize the 
> RequestProcessor correctly.
> org.apache.cocoon.sitemap.SitemapBuilder$SitemapBuilderException: Can't build 
> sitemap from blockcontext:/myblock2/sitemap.xmap
>   at 
> org.apache.cocoon.sitemap.SitemapBuilder.build(SitemapBuilder.java:70) 
> ~[cocoon-sitemap-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT]
>   at 
> org.apache.cocoon.servlet.RequestProcessor.initializeSitemap(RequestProcessor.java:203)
>  ~[cocoon-servlet-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT]
> ...
> Caused by: java.lang.RuntimeException: There is no block 'myblock2' deployed. 
> The available blocks are 
> {myblock=file:/home/thorsten/src/apache/apache-tomcat-6.0.20/work/Catalina/localhost/mywebapp-1.0-SNAPSHOT/blocks/myblock/}.
>   at 
> org.apache.cocoon.blockdeployment.BlockContextURLConnection.getConnection(BlockContextURLConnection.java:76)
>  ~[cocoon-block-deployment-1.2.1.jar:1.2.1]
>   at 
> org.apache.cocoon.blockdeployment.BlockContextURLConnection.getInputStream(BlockContextURLConnection.java:56)
>  ~[cocoon-block-deployment-1.2.1.jar:1.2.1]
>   at java.net.URL.openStream(URL.java:1010) ~[na:1.6.0_30]
>   at 
> org.apache.cocoon.sitemap.SitemapBuilder.build(SitemapBuilder.java:65) 
> ~[cocoon-sitemap-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT]
>   ... 46 common frames omitted
> As you see the blockcontext from the 2nd app is the one from the first EVEN 
> if they are deployed as 2 different webapps!
> Now stop the tomcat and start again. 
> Depending which app you request on a fresh stared tomcat that one will work 
> the other will present a blank page and the log will say something like:
> Caused by: java.lang.RuntimeException: There is no block 'myblock' deployed. 
> The available blocks are 
> {myblock2=file:/home/thorsten/src/apache/apache-tomcat-6.0.20/work/Catalina/localhost/mywebapp2-1.0-SNAPSHOT/blocks/myblock2/}.
> In this case I requested the 2nd first.
> Originally I found out because we have a client that has some c3 and a c2.2.1 
> app (not) running aside. So in case

[jira] [Commented] (COCOON3-105) webapp fails if on the same servlet container is a c2.2.1 or other c3 webapp running

2012-09-25 Thread Thorsten Scherler (JIRA)


[ 
https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13462618#comment-13462618
 ] 

Thorsten Scherler commented on COCOON3-105:
---

Yeah, go ahead. 

If you can manage to seperate the formating changes from the real ones for the 
commit that would awesome. If you want I can do that, just shout.


> webapp fails if on the same servlet container is a c2.2.1 or other c3 webapp 
> running 
> -
>
> Key: COCOON3-105
> URL: https://issues.apache.org/jira/browse/COCOON3-105
> Project: Cocoon 3
>  Issue Type: Bug
>  Components: cocoon-webapp
>Affects Versions: 3.0.0-beta-1
>    Reporter: Thorsten Scherler
>Priority: Blocker
> Attachments: COCOON3-105.npe.diff, cocoon-block-deployment.patch, 
> cocoon-servlet-service-impl.patch
>
>
> I noticed that you cannot run 2 c3 based war in a tomcat.
> To reproduce:
> - seed parent via archetype
> - seed block in parent via archetype
> - seed block2 in parent via archetype
> - seed webapp in parent via archetype
> - seed webapp2 in parent via archetype
> where webapp depends on block one and webapp2 depends on block2.
> My sample was:
> [INFO] Reactor Summary:
> [INFO] 
> [INFO] myparent .. SUCCESS [1.163s]
> [INFO] myblock ... SUCCESS [3.611s]
> [INFO] mywebapp .. SUCCESS [1.924s]
> [INFO] myblock2 .. SUCCESS [1.498s]
> [INFO] mywebapp2 . SUCCESS [1.230s]
> [INFO] 
> 
> Now take a tomcat (I used 6) and first deploy the mywebapp. You can copy it 
> before you start to webapp or if you have it enable deploy it on a running 
> instance. You should see the welcome page under something like 
> http://localhost:8080/mywebapp-1.0-SNAPSHOT/
> side note: http://localhost:8080/mywebapp-1.0-SNAPSHOT will throw a 
> StringIndexOutOfBoundsException but that is another ticket I guess.
> Now if you deploy the second webapp on a running instance it will deploy 
> without problem but requesting 
> http://localhost:8080/mywebapp2-1.0-SNAPSHOT/
> will return a blank page and in 
> /.../tomcat/work/Catalina/localhost/mywebapp-1.0-SNAPSHOT/cocoon.log
> you find:
> 2012-09-13 22:12:46,056 ERROR http-8080-1 
> org.apache.cocoon.servlet.XMLSitemapServlet - Can't initialize the 
> RequestProcessor correctly.
> org.apache.cocoon.sitemap.SitemapBuilder$SitemapBuilderException: Can't build 
> sitemap from blockcontext:/myblock2/sitemap.xmap
>   at 
> org.apache.cocoon.sitemap.SitemapBuilder.build(SitemapBuilder.java:70) 
> ~[cocoon-sitemap-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT]
>   at 
> org.apache.cocoon.servlet.RequestProcessor.initializeSitemap(RequestProcessor.java:203)
>  ~[cocoon-servlet-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT]
> ...
> Caused by: java.lang.RuntimeException: There is no block 'myblock2' deployed. 
> The available blocks are 
> {myblock=file:/home/thorsten/src/apache/apache-tomcat-6.0.20/work/Catalina/localhost/mywebapp-1.0-SNAPSHOT/blocks/myblock/}.
>   at 
> org.apache.cocoon.blockdeployment.BlockContextURLConnection.getConnection(BlockContextURLConnection.java:76)
>  ~[cocoon-block-deployment-1.2.1.jar:1.2.1]
>   at 
> org.apache.cocoon.blockdeployment.BlockContextURLConnection.getInputStream(BlockContextURLConnection.java:56)
>  ~[cocoon-block-deployment-1.2.1.jar:1.2.1]
>   at java.net.URL.openStream(URL.java:1010) ~[na:1.6.0_30]
>   at 
> org.apache.cocoon.sitemap.SitemapBuilder.build(SitemapBuilder.java:65) 
> ~[cocoon-sitemap-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT]
>   ... 46 common frames omitted
> As you see the blockcontext from the 2nd app is the one from the first EVEN 
> if they are deployed as 2 different webapps!
> Now stop the tomcat and start again. 
> Depending which app you request on a fresh stared tomcat that one will work 
> the other will present a blank page and the log will say something like:
> Caused by: java.lang.RuntimeException: There is no block 'myblock' deployed. 
> The available blocks are 
> {myblock2=file:/home/thorsten/src/apache/apache-tomcat-6.0.20/work/Catalina/localhost/mywebapp2-1.0-SNAPSHOT/blocks/myblock2/}.
> In this case I requested the 2nd first.
> Originally I found out because we have a client that has some c3 and a

[jira] [Commented] (COCOON3-105) webapp fails if on the same servlet container is a c2.2.1 or other c3 webapp running

2012-09-24 Thread Thorsten Scherler (JIRA)


[ 
https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461913#comment-13461913
 ] 

Thorsten Scherler commented on COCOON3-105:
---

Hi Francesco, first of all thank you very much for the patch. 

I tried the patches, but with them my webapps actually did not work at all the 
first time. 

After I patched them the correct way everything seems to work as expected. 

Regarding the dep to block from ssc I am not sure, but this way the 
blockcontext is again context aware and unique.

I will do some more testing and finally try to apply the changes in the client 
project.

Thx again

> webapp fails if on the same servlet container is a c2.2.1 or other c3 webapp 
> running 
> -
>
> Key: COCOON3-105
> URL: https://issues.apache.org/jira/browse/COCOON3-105
> Project: Cocoon 3
>  Issue Type: Bug
>  Components: cocoon-webapp
>Affects Versions: 3.0.0-beta-1
>    Reporter: Thorsten Scherler
>Priority: Blocker
> Attachments: COCOON3-105.npe.diff, cocoon-block-deployment.patch, 
> cocoon-servlet-service-impl.patch
>
>
> I noticed that you cannot run 2 c3 based war in a tomcat.
> To reproduce:
> - seed parent via archetype
> - seed block in parent via archetype
> - seed block2 in parent via archetype
> - seed webapp in parent via archetype
> - seed webapp2 in parent via archetype
> where webapp depends on block one and webapp2 depends on block2.
> My sample was:
> [INFO] Reactor Summary:
> [INFO] 
> [INFO] myparent .. SUCCESS [1.163s]
> [INFO] myblock ... SUCCESS [3.611s]
> [INFO] mywebapp .. SUCCESS [1.924s]
> [INFO] myblock2 .. SUCCESS [1.498s]
> [INFO] mywebapp2 . SUCCESS [1.230s]
> [INFO] 
> 
> Now take a tomcat (I used 6) and first deploy the mywebapp. You can copy it 
> before you start to webapp or if you have it enable deploy it on a running 
> instance. You should see the welcome page under something like 
> http://localhost:8080/mywebapp-1.0-SNAPSHOT/
> side note: http://localhost:8080/mywebapp-1.0-SNAPSHOT will throw a 
> StringIndexOutOfBoundsException but that is another ticket I guess.
> Now if you deploy the second webapp on a running instance it will deploy 
> without problem but requesting 
> http://localhost:8080/mywebapp2-1.0-SNAPSHOT/
> will return a blank page and in 
> /.../tomcat/work/Catalina/localhost/mywebapp-1.0-SNAPSHOT/cocoon.log
> you find:
> 2012-09-13 22:12:46,056 ERROR http-8080-1 
> org.apache.cocoon.servlet.XMLSitemapServlet - Can't initialize the 
> RequestProcessor correctly.
> org.apache.cocoon.sitemap.SitemapBuilder$SitemapBuilderException: Can't build 
> sitemap from blockcontext:/myblock2/sitemap.xmap
>   at 
> org.apache.cocoon.sitemap.SitemapBuilder.build(SitemapBuilder.java:70) 
> ~[cocoon-sitemap-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT]
>   at 
> org.apache.cocoon.servlet.RequestProcessor.initializeSitemap(RequestProcessor.java:203)
>  ~[cocoon-servlet-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT]
> ...
> Caused by: java.lang.RuntimeException: There is no block 'myblock2' deployed. 
> The available blocks are 
> {myblock=file:/home/thorsten/src/apache/apache-tomcat-6.0.20/work/Catalina/localhost/mywebapp-1.0-SNAPSHOT/blocks/myblock/}.
>   at 
> org.apache.cocoon.blockdeployment.BlockContextURLConnection.getConnection(BlockContextURLConnection.java:76)
>  ~[cocoon-block-deployment-1.2.1.jar:1.2.1]
>   at 
> org.apache.cocoon.blockdeployment.BlockContextURLConnection.getInputStream(BlockContextURLConnection.java:56)
>  ~[cocoon-block-deployment-1.2.1.jar:1.2.1]
>   at java.net.URL.openStream(URL.java:1010) ~[na:1.6.0_30]
>   at 
> org.apache.cocoon.sitemap.SitemapBuilder.build(SitemapBuilder.java:65) 
> ~[cocoon-sitemap-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT]
>   ... 46 common frames omitted
> As you see the blockcontext from the 2nd app is the one from the first EVEN 
> if they are deployed as 2 different webapps!
> Now stop the tomcat and start again. 
> Depending which app you request on a fresh stared tomcat that one will work 
> the other will present a blank page and the log will say something like:
> Caused by: java.lang.RuntimeException: There is no block 'myblock' deployed.

BlockContextURLConnection is not context safe

2012-09-18 Thread Thorsten Scherler


Hi all,

I am working on COCOON3-105 whenever I find a sec, but I am thinking 
about the underlying problem for a while now.


To resume, the blockcontext:/ is being registered as an extension to 
java.net.URLConnection. In case of a not-known protocol we will create 
the StreamHandler (who is responsible to open the urlConnection) once - 
for the whole container!


This happens in the BlockContextURLStreamHandlerFactory in the method 
createURLStreamHandler(String protocol). Like said: only once (!) we 
call this method even if we have two different servlets using different 
blockcontext. This finally leads to that the BlockContextURLConnection 
only knows the blockcontext of the first requested blockcontext and 
ignores any others.


Some possible solution I see:
- move the resolving of the blockcontext into the 
BlockContextURLConnection. I tried that in the patch I attached to the 
issue but the problem is that the second request has no ServletContext 
associated to it so we cannot get the blocks. -> since we cannot resolve 
here the blockcontext this solution does not work
- use a global blockcontext map. A reference to a global blockcontext 
map will be kept and this map needs to be merged when a new app is 
deployed (if needed). However that leads to many open issue like 
security, version, etc.


Further how do you undeploy the protocol since undeploying the 
underlying servlet would need to undeploy only a part of the 
blockcontext protocol.


I am not sure how to overcome above obstacles and would love any 
thoughts from the community.


salu2

--
Thorsten Scherler 
codeBusters S.L. - web based systems


http://www.codebusters.es/

[jira] [Commented] (COCOON3-105) webapp fails if on the same servlet container is a c2.2.1 or other c3 webapp running

2012-09-17 Thread Thorsten Scherler (JIRA)


[ 
https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13456938#comment-13456938
 ] 

Thorsten Scherler commented on COCOON3-105:
---

We need to find a way to get the 
this.blockContexts = (Map) servletContext

.getAttribute(BlockDeploymentServletContextListener.BLOCK_CONTEXT_MAP);

Somebody knows why servletContext = CallStackHelper.getCurrentServletContext() 
can become null? I need to attend now some urgent matter so I will not be able 
to put more hours into the issue but I will attend it later on and follow the 
comment flow.

> webapp fails if on the same servlet container is a c2.2.1 or other c3 webapp 
> running 
> -
>
> Key: COCOON3-105
> URL: https://issues.apache.org/jira/browse/COCOON3-105
> Project: Cocoon 3
>  Issue Type: Bug
>  Components: cocoon-webapp
>Affects Versions: 3.0.0-beta-1
>    Reporter: Thorsten Scherler
>Priority: Blocker
> Attachments: COCOON3-105.npe.diff
>
>
> I noticed that you cannot run 2 c3 based war in a tomcat.
> To reproduce:
> - seed parent via archetype
> - seed block in parent via archetype
> - seed block2 in parent via archetype
> - seed webapp in parent via archetype
> - seed webapp2 in parent via archetype
> where webapp depends on block one and webapp2 depends on block2.
> My sample was:
> [INFO] Reactor Summary:
> [INFO] 
> [INFO] myparent .. SUCCESS [1.163s]
> [INFO] myblock ... SUCCESS [3.611s]
> [INFO] mywebapp .. SUCCESS [1.924s]
> [INFO] myblock2 .. SUCCESS [1.498s]
> [INFO] mywebapp2 . SUCCESS [1.230s]
> [INFO] 
> 
> Now take a tomcat (I used 6) and first deploy the mywebapp. You can copy it 
> before you start to webapp or if you have it enable deploy it on a running 
> instance. You should see the welcome page under something like 
> http://localhost:8080/mywebapp-1.0-SNAPSHOT/
> side note: http://localhost:8080/mywebapp-1.0-SNAPSHOT will throw a 
> StringIndexOutOfBoundsException but that is another ticket I guess.
> Now if you deploy the second webapp on a running instance it will deploy 
> without problem but requesting 
> http://localhost:8080/mywebapp2-1.0-SNAPSHOT/
> will return a blank page and in 
> /.../tomcat/work/Catalina/localhost/mywebapp-1.0-SNAPSHOT/cocoon.log
> you find:
> 2012-09-13 22:12:46,056 ERROR http-8080-1 
> org.apache.cocoon.servlet.XMLSitemapServlet - Can't initialize the 
> RequestProcessor correctly.
> org.apache.cocoon.sitemap.SitemapBuilder$SitemapBuilderException: Can't build 
> sitemap from blockcontext:/myblock2/sitemap.xmap
>   at 
> org.apache.cocoon.sitemap.SitemapBuilder.build(SitemapBuilder.java:70) 
> ~[cocoon-sitemap-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT]
>   at 
> org.apache.cocoon.servlet.RequestProcessor.initializeSitemap(RequestProcessor.java:203)
>  ~[cocoon-servlet-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT]
> ...
> Caused by: java.lang.RuntimeException: There is no block 'myblock2' deployed. 
> The available blocks are 
> {myblock=file:/home/thorsten/src/apache/apache-tomcat-6.0.20/work/Catalina/localhost/mywebapp-1.0-SNAPSHOT/blocks/myblock/}.
>   at 
> org.apache.cocoon.blockdeployment.BlockContextURLConnection.getConnection(BlockContextURLConnection.java:76)
>  ~[cocoon-block-deployment-1.2.1.jar:1.2.1]
>   at 
> org.apache.cocoon.blockdeployment.BlockContextURLConnection.getInputStream(BlockContextURLConnection.java:56)
>  ~[cocoon-block-deployment-1.2.1.jar:1.2.1]
>   at java.net.URL.openStream(URL.java:1010) ~[na:1.6.0_30]
>   at 
> org.apache.cocoon.sitemap.SitemapBuilder.build(SitemapBuilder.java:65) 
> ~[cocoon-sitemap-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT]
>   ... 46 common frames omitted
> As you see the blockcontext from the 2nd app is the one from the first EVEN 
> if they are deployed as 2 different webapps!
> Now stop the tomcat and start again. 
> Depending which app you request on a fresh stared tomcat that one will work 
> the other will present a blank page and the log will say something like:
> Caused by: java.lang.RuntimeException: There is no block 'myblock' deployed. 
> The available blocks are 
> {myblock2=file:/home/thorsten/src/apache/apache-tomcat-6.0.20/work/C

[jira] [Updated] (COCOON3-105) webapp fails if on the same servlet container is a c2.2.1 or other c3 webapp running

2012-09-17 Thread Thorsten Scherler (JIRA)


 [ 
https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thorsten Scherler updated COCOON3-105:
--

Attachment: COCOON3-105.npe.diff

This is a first step to remove the need of the blocktontext in the constructor. 

However it works fine with the first sevlet however the second will fail with a 
NPE because 
ServletContext servletContext = CallStackHelper.getCurrentServletContext();
is null

> webapp fails if on the same servlet container is a c2.2.1 or other c3 webapp 
> running 
> -
>
> Key: COCOON3-105
> URL: https://issues.apache.org/jira/browse/COCOON3-105
> Project: Cocoon 3
>  Issue Type: Bug
>  Components: cocoon-webapp
>Affects Versions: 3.0.0-beta-1
>    Reporter: Thorsten Scherler
>Priority: Blocker
> Attachments: COCOON3-105.npe.diff
>
>
> I noticed that you cannot run 2 c3 based war in a tomcat.
> To reproduce:
> - seed parent via archetype
> - seed block in parent via archetype
> - seed block2 in parent via archetype
> - seed webapp in parent via archetype
> - seed webapp2 in parent via archetype
> where webapp depends on block one and webapp2 depends on block2.
> My sample was:
> [INFO] Reactor Summary:
> [INFO] 
> [INFO] myparent .. SUCCESS [1.163s]
> [INFO] myblock ... SUCCESS [3.611s]
> [INFO] mywebapp .. SUCCESS [1.924s]
> [INFO] myblock2 .. SUCCESS [1.498s]
> [INFO] mywebapp2 . SUCCESS [1.230s]
> [INFO] 
> 
> Now take a tomcat (I used 6) and first deploy the mywebapp. You can copy it 
> before you start to webapp or if you have it enable deploy it on a running 
> instance. You should see the welcome page under something like 
> http://localhost:8080/mywebapp-1.0-SNAPSHOT/
> side note: http://localhost:8080/mywebapp-1.0-SNAPSHOT will throw a 
> StringIndexOutOfBoundsException but that is another ticket I guess.
> Now if you deploy the second webapp on a running instance it will deploy 
> without problem but requesting 
> http://localhost:8080/mywebapp2-1.0-SNAPSHOT/
> will return a blank page and in 
> /.../tomcat/work/Catalina/localhost/mywebapp-1.0-SNAPSHOT/cocoon.log
> you find:
> 2012-09-13 22:12:46,056 ERROR http-8080-1 
> org.apache.cocoon.servlet.XMLSitemapServlet - Can't initialize the 
> RequestProcessor correctly.
> org.apache.cocoon.sitemap.SitemapBuilder$SitemapBuilderException: Can't build 
> sitemap from blockcontext:/myblock2/sitemap.xmap
>   at 
> org.apache.cocoon.sitemap.SitemapBuilder.build(SitemapBuilder.java:70) 
> ~[cocoon-sitemap-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT]
>   at 
> org.apache.cocoon.servlet.RequestProcessor.initializeSitemap(RequestProcessor.java:203)
>  ~[cocoon-servlet-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT]
> ...
> Caused by: java.lang.RuntimeException: There is no block 'myblock2' deployed. 
> The available blocks are 
> {myblock=file:/home/thorsten/src/apache/apache-tomcat-6.0.20/work/Catalina/localhost/mywebapp-1.0-SNAPSHOT/blocks/myblock/}.
>   at 
> org.apache.cocoon.blockdeployment.BlockContextURLConnection.getConnection(BlockContextURLConnection.java:76)
>  ~[cocoon-block-deployment-1.2.1.jar:1.2.1]
>   at 
> org.apache.cocoon.blockdeployment.BlockContextURLConnection.getInputStream(BlockContextURLConnection.java:56)
>  ~[cocoon-block-deployment-1.2.1.jar:1.2.1]
>   at java.net.URL.openStream(URL.java:1010) ~[na:1.6.0_30]
>   at 
> org.apache.cocoon.sitemap.SitemapBuilder.build(SitemapBuilder.java:65) 
> ~[cocoon-sitemap-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT]
>   ... 46 common frames omitted
> As you see the blockcontext from the 2nd app is the one from the first EVEN 
> if they are deployed as 2 different webapps!
> Now stop the tomcat and start again. 
> Depending which app you request on a fresh stared tomcat that one will work 
> the other will present a blank page and the log will say something like:
> Caused by: java.lang.RuntimeException: There is no block 'myblock' deployed. 
> The available blocks are 
> {myblock2=file:/home/thorsten/src/apache/apache-tomcat-6.0.20/work/Catalina/localhost/mywebapp2-1.0-SNAPSHOT/blocks/myblock2/}.
> In this case I requested the 2nd first.
> Originally I found out because we have a client that has some c3 an

Re: [jira] [Commented] (COCOON3-105) webapp fails if on the same servlet container is a c2.2.1 or other c3 webapp running

2012-09-17 Thread Thorsten Scherler

On 09/17/2012 07:16 AM, Jos Snellings wrote:

Hi Thorsten,

I believe having encountered this problem once.
However, it is not systematic.

Hi Joe,

I think I pinned down the problem.

We use java.net.urlHandler which means we only get init once. I am ATM 
reviewing the servlet handler and here we do the resolving part in the 
Connection part.

I think the blockcontextHandler needs to loose the this.blockcontext 
part, this would need to be resolved in the actual 
BlockContextURLConnection to resolve against only for the current 
servlet specific registered blocks.

salu2

Jos

On Mon, Sep 17, 2012 at 12:06 AM, Thorsten Scherler (JIRA) 
mailto:j...@apache.org>> wrote:

[

https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13456689#comment-13456689
    ]

    Thorsten Scherler commented on COCOON3-105:
---

The problem lies in in

org.apache.cocoon.blockdeployment.BlockContextURLStreamHandlerFactory.createURLStreamHandler
here we create a  BlockContextURLStreamHandler extends
URLStreamHandler

Regarding URLStreamHandler
/**
 * The abstract class URLStreamHandler is the common
 * superclass for all stream protocol handlers. A stream protocol
 * handler knows how to make a connection for a particular protocol
 * type, such as http, ftp, or
 * gopher.
 * 
 * In most cases, an instance of a URLStreamHandler
 * subclass is not created directly by an application. Rather, the
 * first time a protocol name is encountered when constructing a
 * URL, the appropriate stream protocol handler is
 * automatically loaded.*/

Which is exactly the problem in our case. Once the
URLStreamHandler is setup for the first blockcontext as protocol
the second servlet will directly use the java.net.URLStreamHandler
and use that protocol.

Meaning if you start tomcat with both apps deployed the first
request of the first app decides which blockcontext will be
associate with the block context protocol

That happens in BlockContextURLStreamHandlerFactory where
createURLStreamHandler is only called once with the first request
the second then uses the old block context.

> webapp fails if on the same servlet container is a c2.2.1 or
other c3 webapp running
>

-
>
> Key: COCOON3-105
> URL:
https://issues.apache.org/jira/browse/COCOON3-105
> Project: Cocoon 3
>  Issue Type: Bug
>  Components: cocoon-webapp
>Affects Versions: 3.0.0-beta-1
>Reporter: Thorsten Scherler
>Priority: Blocker
>
> I noticed that you cannot run 2 c3 based war in a tomcat.
> To reproduce:
> - seed parent via archetype
> - seed block in parent via archetype
> - seed block2 in parent via archetype
> - seed webapp in parent via archetype
> - seed webapp2 in parent via archetype
> where webapp depends on block one and webapp2 depends on block2.
> My sample was:
> [INFO] Reactor Summary:
> [INFO]
> [INFO] myparent ..
SUCCESS [1.163s]
> [INFO] myblock ...
SUCCESS [3.611s]
> [INFO] mywebapp ..
SUCCESS [1.924s]
> [INFO] myblock2 ..
SUCCESS [1.498s]
> [INFO] mywebapp2 .
SUCCESS [1.230s]
> [INFO]

> Now take a tomcat (I used 6) and first deploy the mywebapp. You
can copy it before you start to webapp or if you have it enable
deploy it on a running instance. You should see the welcome page
under something like http://localhost:8080/mywebapp-1.0-SNAPSHOT/
> side note: http://localhost:8080/mywebapp-1.0-SNAPSHOT will
throw a StringIndexOutOfBoundsException but that is another ticket
I guess.
> Now if you deploy the second webapp on a running instance it
will deploy without problem but requesting
> http://localhost:8080/mywebapp2-1.0-SNAPSHOT/
> will return a blank page and in
> /.../tomcat/work/Catalina/localhost/mywebapp-1.0-SNAPSHOT/cocoon.log
> you find:
> 2012-09-13 22:12:46,056 ERROR http-8080-1
org.apache.cocoon.servlet.XMLSitemapServlet - Can't initialize the
RequestProcessor correctly.
>
org.apache.cocoon.sitemap.SitemapBuilder$SitemapBuilderException:
Can't build sitemap from blockcontext:/myblock2/sitemap.xmap
>

[jira] [Commented] (COCOON3-105) webapp fails if on the same servlet container is a c2.2.1 or other c3 webapp running

2012-09-16 Thread Thorsten Scherler (JIRA)


[ 
https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13456689#comment-13456689
 ] 

Thorsten Scherler commented on COCOON3-105:
---

The problem lies in in 
org.apache.cocoon.blockdeployment.BlockContextURLStreamHandlerFactory.createURLStreamHandler
here we create a  BlockContextURLStreamHandler extends URLStreamHandler

Regarding URLStreamHandler 
/**
 * The abstract class URLStreamHandler is the common
 * superclass for all stream protocol handlers. A stream protocol
 * handler knows how to make a connection for a particular protocol
 * type, such as http, ftp, or
 * gopher.
 * 
 * In most cases, an instance of a URLStreamHandler
 * subclass is not created directly by an application. Rather, the
 * first time a protocol name is encountered when constructing a
 * URL, the appropriate stream protocol handler is
 * automatically loaded.*/

Which is exactly the problem in our case. Once the URLStreamHandler is setup 
for the first blockcontext as protocol the second servlet will directly use the 
java.net.URLStreamHandler and use that protocol.

Meaning if you start tomcat with both apps deployed the first request of the 
first app decides which blockcontext will be associate with the block context 
protocol

That happens in BlockContextURLStreamHandlerFactory where 
createURLStreamHandler is only called once with the first request the second 
then uses the old block context.


> webapp fails if on the same servlet container is a c2.2.1 or other c3 webapp 
> running 
> -
>
> Key: COCOON3-105
> URL: https://issues.apache.org/jira/browse/COCOON3-105
> Project: Cocoon 3
>  Issue Type: Bug
>  Components: cocoon-webapp
>Affects Versions: 3.0.0-beta-1
>    Reporter: Thorsten Scherler
>Priority: Blocker
>
> I noticed that you cannot run 2 c3 based war in a tomcat.
> To reproduce:
> - seed parent via archetype
> - seed block in parent via archetype
> - seed block2 in parent via archetype
> - seed webapp in parent via archetype
> - seed webapp2 in parent via archetype
> where webapp depends on block one and webapp2 depends on block2.
> My sample was:
> [INFO] Reactor Summary:
> [INFO] 
> [INFO] myparent .. SUCCESS [1.163s]
> [INFO] myblock ... SUCCESS [3.611s]
> [INFO] mywebapp .. SUCCESS [1.924s]
> [INFO] myblock2 .. SUCCESS [1.498s]
> [INFO] mywebapp2 . SUCCESS [1.230s]
> [INFO] 
> 
> Now take a tomcat (I used 6) and first deploy the mywebapp. You can copy it 
> before you start to webapp or if you have it enable deploy it on a running 
> instance. You should see the welcome page under something like 
> http://localhost:8080/mywebapp-1.0-SNAPSHOT/
> side note: http://localhost:8080/mywebapp-1.0-SNAPSHOT will throw a 
> StringIndexOutOfBoundsException but that is another ticket I guess.
> Now if you deploy the second webapp on a running instance it will deploy 
> without problem but requesting 
> http://localhost:8080/mywebapp2-1.0-SNAPSHOT/
> will return a blank page and in 
> /.../tomcat/work/Catalina/localhost/mywebapp-1.0-SNAPSHOT/cocoon.log
> you find:
> 2012-09-13 22:12:46,056 ERROR http-8080-1 
> org.apache.cocoon.servlet.XMLSitemapServlet - Can't initialize the 
> RequestProcessor correctly.
> org.apache.cocoon.sitemap.SitemapBuilder$SitemapBuilderException: Can't build 
> sitemap from blockcontext:/myblock2/sitemap.xmap
>   at 
> org.apache.cocoon.sitemap.SitemapBuilder.build(SitemapBuilder.java:70) 
> ~[cocoon-sitemap-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT]
>   at 
> org.apache.cocoon.servlet.RequestProcessor.initializeSitemap(RequestProcessor.java:203)
>  ~[cocoon-servlet-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT]
> ...
> Caused by: java.lang.RuntimeException: There is no block 'myblock2' deployed. 
> The available blocks are 
> {myblock=file:/home/thorsten/src/apache/apache-tomcat-6.0.20/work/Catalina/localhost/mywebapp-1.0-SNAPSHOT/blocks/myblock/}.
>   at 
> org.apache.cocoon.blockdeployment.BlockContextURLConnection.getConnection(BlockContextURLConnection.java:76)
>  ~[cocoon-block-deployment-1.2.1.jar:1.2.1]
>   at 
> org.apache.cocoon.blockdeployment.BlockContextURLConnection.getInputStream(BlockContextURLConnection.java:56)
>  ~[cocoon-block-deployment-1.2.1.jar:1.2.1]
&

[jira] [Created] (COCOON3-105) webapp fails if on the same servlet container is a c2.2.1 or other c3 webapp running

Thorsten Scherler created COCOON3-105:
-

 Summary: webapp fails if on the same servlet container is a c2.2.1 
or other c3 webapp running 
 Key: COCOON3-105
 URL: https://issues.apache.org/jira/browse/COCOON3-105
 Project: Cocoon 3
  Issue Type: Bug
  Components: cocoon-webapp
Affects Versions: 3.0.0-beta-1
Reporter: Thorsten Scherler
Priority: Blocker


I noticed that you cannot run 2 c3 based war in a tomcat.

To reproduce:

- seed parent via archetype
- seed block in parent via archetype
- seed block2 in parent via archetype
- seed webapp in parent via archetype
- seed webapp2 in parent via archetype

where webapp depends on block one and webapp2 depends on block2.

My sample was:
[INFO] Reactor Summary:
[INFO] 
[INFO] myparent .. SUCCESS [1.163s]
[INFO] myblock ... SUCCESS [3.611s]
[INFO] mywebapp .. SUCCESS [1.924s]
[INFO] myblock2 .. SUCCESS [1.498s]
[INFO] mywebapp2 . SUCCESS [1.230s]
[INFO] 

Now take a tomcat (I used 6) and first deploy the mywebapp. You can copy it 
before you start to webapp or if you have it enable deploy it on a running 
instance. You should see the welcome page under something like 
http://localhost:8080/mywebapp-1.0-SNAPSHOT/

side note: http://localhost:8080/mywebapp-1.0-SNAPSHOT will throw a 
StringIndexOutOfBoundsException but that is another ticket I guess.

Now if you deploy the second webapp on a running instance it will deploy 
without problem but requesting 
http://localhost:8080/mywebapp2-1.0-SNAPSHOT/
will return a blank page and in 
/.../tomcat/work/Catalina/localhost/mywebapp-1.0-SNAPSHOT/cocoon.log
you find:

2012-09-13 22:12:46,056 ERROR http-8080-1 
org.apache.cocoon.servlet.XMLSitemapServlet - Can't initialize the 
RequestProcessor correctly.
org.apache.cocoon.sitemap.SitemapBuilder$SitemapBuilderException: Can't build 
sitemap from blockcontext:/myblock2/sitemap.xmap
at 
org.apache.cocoon.sitemap.SitemapBuilder.build(SitemapBuilder.java:70) 
~[cocoon-sitemap-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT]
at 
org.apache.cocoon.servlet.RequestProcessor.initializeSitemap(RequestProcessor.java:203)
 ~[cocoon-servlet-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT]
...
Caused by: java.lang.RuntimeException: There is no block 'myblock2' deployed. 
The available blocks are 
{myblock=file:/home/thorsten/src/apache/apache-tomcat-6.0.20/work/Catalina/localhost/mywebapp-1.0-SNAPSHOT/blocks/myblock/}.
at 
org.apache.cocoon.blockdeployment.BlockContextURLConnection.getConnection(BlockContextURLConnection.java:76)
 ~[cocoon-block-deployment-1.2.1.jar:1.2.1]
at 
org.apache.cocoon.blockdeployment.BlockContextURLConnection.getInputStream(BlockContextURLConnection.java:56)
 ~[cocoon-block-deployment-1.2.1.jar:1.2.1]
at java.net.URL.openStream(URL.java:1010) ~[na:1.6.0_30]
at 
org.apache.cocoon.sitemap.SitemapBuilder.build(SitemapBuilder.java:65) 
~[cocoon-sitemap-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT]
... 46 common frames omitted

As you see the blockcontext from the 2nd app is the one from the first EVEN if 
they are deployed as 2 different webapps!

Now stop the tomcat and start again. 

Depending which app you request on a fresh stared tomcat that one will work the 
other will present a blank page and the log will say something like:

Caused by: java.lang.RuntimeException: There is no block 'myblock' deployed. 
The available blocks are 
{myblock2=file:/home/thorsten/src/apache/apache-tomcat-6.0.20/work/Catalina/localhost/mywebapp2-1.0-SNAPSHOT/blocks/myblock2/}.

In this case I requested the 2nd first.

Originally I found out because we have a client that has some c3 and a c2.2.1 
app (not) running aside. So in case you create a 2.2.1 webapp from the 
archetype as described  http://cocoon.apache.org/2.2/1159_1_1.html and use it 
instead of the c3 2nd webapp you will get similar results.

If you start first with the 1st c3 and then deploy the c2.2 on the run then you 
can actually see both working ONLY if you first request the c3 and then deploy 
and then see the c2. In case you do not request the c3 prior it will not work 
once you requested the c2 (which maybe present interesting for the cause of the 
problem).

Now shutdown and start with both deployed the c2.2 always works and the c3 not. 

I see the problem for our client coming when we introduced 
org.apache.cocoon.blockdeployment.BlockDeploymentServletContextListener

The main observation is that the c2 one seems to much more presistence but that 
can come the way of invocation (on-demand vs. startup). Anyway the

[jira] [Closed] (COCOON3-104) org.apache.cocoon.archetype-webapp creating a new seed fails due to missing logback conf


 [ 
https://issues.apache.org/jira/browse/COCOON3-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thorsten Scherler closed COCOON3-104.
-

   Resolution: Fixed
Fix Version/s: 3.0.0-beta-1

Seems to be an old snapshot that I had on my box.

Doing a clean install of the architype fixed that for me.

Javier tried on his machine and it as well working so closing the issue and 
sorry for the noise.

> org.apache.cocoon.archetype-webapp creating a new seed fails due to missing 
> logback conf
> 
>
> Key: COCOON3-104
> URL: https://issues.apache.org/jira/browse/COCOON3-104
> Project: Cocoon 3
>  Issue Type: Bug
>  Components: cocoon-archetype-X
>Affects Versions: 3.0.0-beta-1
>    Reporter: Thorsten Scherler
> Fix For: 3.0.0-beta-1
>
>
> if you create a webapp project with the artifact like:
> thorsten@bulldozer:~/src/codebusters/c3$ mvn archetype:create \
> > -DarchetypeGroupId=org.apache.cocoon.archetype-webapp \
> > -DarchetypeArtifactId=cocoon-archetype-webapp \
> > -DarchetypeVersion=3.0.0-beta-1-SNAPSHOT \
> > -DgroupId=com.mycompany \
> > -DartifactId=mywebapp 
> Maven is going to complain about:
> [INFO] Using following parameters for creating project from Old (1.x) 
> Archetype: cocoon-archetype-webapp:3.0.0-beta-1-SNAPSHOT
> [INFO] 
> 
> [INFO] Parameter: groupId, Value: com.mycompany
> [INFO] Parameter: packageName, Value: com.mycompany
> [INFO] Parameter: package, Value: com.mycompany
> [INFO] Parameter: artifactId, Value: mywebapp
> [INFO] Parameter: basedir, Value: /home/thorsten/src/codebusters/c3
> [INFO] Parameter: version, Value: 1.0-SNAPSHOT
> [ERROR] ResourceManager : unable to find resource 
> 'archetype-resources/src/main/webapp/WEB-INF/classes/logback.xml' in any 
> resource loader.
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 2.264s
> [INFO] Finished at: Thu Sep 13 19:30:50 CEST 2012
> [INFO] Final Memory: 8M/239M
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-archetype-plugin:2.2:create (default-cli) on 
> project standalone-pom: Error creating from archetype: Error merging velocity 
> templates: Unable to find resource 
> 'archetype-resources/src/main/webapp/WEB-INF/classes/logback.xml' -> [Help 1]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (COCOON3-104) org.apache.cocoon.archetype-webapp creating a new seed fails due to missing logback conf


[ 
https://issues.apache.org/jira/browse/COCOON3-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13455060#comment-13455060
 ] 

Thorsten Scherler edited comment on COCOON3-104 at 9/14/12 4:52 AM:


Just to make sure not to blame the archetype:create for the failure I tried:

mvn archetype:generate \
-DarchetypeGroupId=org.apache.cocoon.archetype-webapp \
-DarchetypeArtifactId=cocoon-archetype-webapp \
-DarchetypeVersion=3.0.0-beta-1-SNAPSHOT \
-DgroupId=com.mycompany \
-DartifactId=mywebapp 

with the same result.

  was (Author: thorsten):
Just to make sure not to blame the archetype:create for the failure I tried:

mvn archetype:generate \
-DarchetypeGroupId=org.apache.cocoon.archetype-webapp \
-DarchetypeArtifactId=cocoon-archetype-webapp \
-DarchetypeVersion=3.0.0-beta-1-SNAPSHOT \
-DgroupId=com.mycompany \
-DartifactId=mywebapp 
  
> org.apache.cocoon.archetype-webapp creating a new seed fails due to missing 
> logback conf
> 
>
> Key: COCOON3-104
> URL: https://issues.apache.org/jira/browse/COCOON3-104
> Project: Cocoon 3
>  Issue Type: Bug
>  Components: cocoon-archetype-X
>Affects Versions: 3.0.0-beta-1
>    Reporter: Thorsten Scherler
>
> if you create a webapp project with the artifact like:
> thorsten@bulldozer:~/src/codebusters/c3$ mvn archetype:create \
> > -DarchetypeGroupId=org.apache.cocoon.archetype-webapp \
> > -DarchetypeArtifactId=cocoon-archetype-webapp \
> > -DarchetypeVersion=3.0.0-beta-1-SNAPSHOT \
> > -DgroupId=com.mycompany \
> > -DartifactId=mywebapp 
> Maven is going to complain about:
> [INFO] Using following parameters for creating project from Old (1.x) 
> Archetype: cocoon-archetype-webapp:3.0.0-beta-1-SNAPSHOT
> [INFO] 
> 
> [INFO] Parameter: groupId, Value: com.mycompany
> [INFO] Parameter: packageName, Value: com.mycompany
> [INFO] Parameter: package, Value: com.mycompany
> [INFO] Parameter: artifactId, Value: mywebapp
> [INFO] Parameter: basedir, Value: /home/thorsten/src/codebusters/c3
> [INFO] Parameter: version, Value: 1.0-SNAPSHOT
> [ERROR] ResourceManager : unable to find resource 
> 'archetype-resources/src/main/webapp/WEB-INF/classes/logback.xml' in any 
> resource loader.
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 2.264s
> [INFO] Finished at: Thu Sep 13 19:30:50 CEST 2012
> [INFO] Final Memory: 8M/239M
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-archetype-plugin:2.2:create (default-cli) on 
> project standalone-pom: Error creating from archetype: Error merging velocity 
> templates: Unable to find resource 
> 'archetype-resources/src/main/webapp/WEB-INF/classes/logback.xml' -> [Help 1]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (COCOON3-104) org.apache.cocoon.archetype-webapp creating a new seed fails due to missing logback conf


[ 
https://issues.apache.org/jira/browse/COCOON3-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13455060#comment-13455060
 ] 

Thorsten Scherler commented on COCOON3-104:
---

Just to make sure not to blame the archetype:create for the failure I tried:

mvn archetype:generate \
-DarchetypeGroupId=org.apache.cocoon.archetype-webapp \
-DarchetypeArtifactId=cocoon-archetype-webapp \
-DarchetypeVersion=3.0.0-beta-1-SNAPSHOT \
-DgroupId=com.mycompany \
-DartifactId=mywebapp 

> org.apache.cocoon.archetype-webapp creating a new seed fails due to missing 
> logback conf
> 
>
> Key: COCOON3-104
> URL: https://issues.apache.org/jira/browse/COCOON3-104
> Project: Cocoon 3
>  Issue Type: Bug
>  Components: cocoon-archetype-X
>Affects Versions: 3.0.0-beta-1
>    Reporter: Thorsten Scherler
>
> if you create a webapp project with the artifact like:
> thorsten@bulldozer:~/src/codebusters/c3$ mvn archetype:create \
> > -DarchetypeGroupId=org.apache.cocoon.archetype-webapp \
> > -DarchetypeArtifactId=cocoon-archetype-webapp \
> > -DarchetypeVersion=3.0.0-beta-1-SNAPSHOT \
> > -DgroupId=com.mycompany \
> > -DartifactId=mywebapp 
> Maven is going to complain about:
> [INFO] Using following parameters for creating project from Old (1.x) 
> Archetype: cocoon-archetype-webapp:3.0.0-beta-1-SNAPSHOT
> [INFO] 
> 
> [INFO] Parameter: groupId, Value: com.mycompany
> [INFO] Parameter: packageName, Value: com.mycompany
> [INFO] Parameter: package, Value: com.mycompany
> [INFO] Parameter: artifactId, Value: mywebapp
> [INFO] Parameter: basedir, Value: /home/thorsten/src/codebusters/c3
> [INFO] Parameter: version, Value: 1.0-SNAPSHOT
> [ERROR] ResourceManager : unable to find resource 
> 'archetype-resources/src/main/webapp/WEB-INF/classes/logback.xml' in any 
> resource loader.
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 2.264s
> [INFO] Finished at: Thu Sep 13 19:30:50 CEST 2012
> [INFO] Final Memory: 8M/239M
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-archetype-plugin:2.2:create (default-cli) on 
> project standalone-pom: Error creating from archetype: Error merging velocity 
> templates: Unable to find resource 
> 'archetype-resources/src/main/webapp/WEB-INF/classes/logback.xml' -> [Help 1]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (COCOON3-104) org.apache.cocoon.archetype-webapp creating a new seed fails due to missing logback conf

Thorsten Scherler created COCOON3-104:
-

 Summary: org.apache.cocoon.archetype-webapp creating a new seed 
fails due to missing logback conf
 Key: COCOON3-104
 URL: https://issues.apache.org/jira/browse/COCOON3-104
 Project: Cocoon 3
  Issue Type: Bug
  Components: cocoon-archetype-X
Affects Versions: 3.0.0-beta-1
Reporter: Thorsten Scherler


if you create a webapp project with the artifact like:

thorsten@bulldozer:~/src/codebusters/c3$ mvn archetype:create \
> -DarchetypeGroupId=org.apache.cocoon.archetype-webapp \
> -DarchetypeArtifactId=cocoon-archetype-webapp \
> -DarchetypeVersion=3.0.0-beta-1-SNAPSHOT \
> -DgroupId=com.mycompany \
> -DartifactId=mywebapp 

Maven is going to complain about:

[INFO] Using following parameters for creating project from Old (1.x) 
Archetype: cocoon-archetype-webapp:3.0.0-beta-1-SNAPSHOT
[INFO] 

[INFO] Parameter: groupId, Value: com.mycompany
[INFO] Parameter: packageName, Value: com.mycompany
[INFO] Parameter: package, Value: com.mycompany
[INFO] Parameter: artifactId, Value: mywebapp
[INFO] Parameter: basedir, Value: /home/thorsten/src/codebusters/c3
[INFO] Parameter: version, Value: 1.0-SNAPSHOT
[ERROR] ResourceManager : unable to find resource 
'archetype-resources/src/main/webapp/WEB-INF/classes/logback.xml' in any 
resource loader.
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 2.264s
[INFO] Finished at: Thu Sep 13 19:30:50 CEST 2012
[INFO] Final Memory: 8M/239M
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-archetype-plugin:2.2:create (default-cli) on 
project standalone-pom: Error creating from archetype: Error merging velocity 
templates: Unable to find resource 
'archetype-resources/src/main/webapp/WEB-INF/classes/logback.xml' -> [Help 1]


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

c2.2.1 webapp blocklistener changes

2012-09-11 Thread Thorsten Scherler


Hi all,

I am ATM trying to upgrade a client project to use 2.2.1 but I am 
running into a problem where I see 2 solutions. I write it here so 
people that are doing an upgrade can benefit from our findings.


One big change in 2.2.1 is that the servlet connections are not forced 
to define any more in the spring config of the war since we are using 
the BlockDeploymentServletContextListener in the web.xml.


Now in the client project we have in 
src/main/webapp/WEB-INF/applicationContext.xml (which worked fine before)




  

  

  

This is due to the fact that the war project has its own sitemap and 
needs to listen to all other mounts. Now the above will fail complaining 
about missing protocol.


So I tried to use context-path="context:/" but then I get complains 
about the context:/ protocol is not defined. So for testing I pointed to 
the target dir of the deploy like 
context-path="file:///home/thorsten/src/clientBlock/target/clientBlock-3.0.7/".


With the last is working but it is not really a valid solution in case 
you deploy to e.g. tomcat, since the context needs to dynamically set.


A possible solution would be that I do a rewrite of the war block and 
move all sitemap stuff to a block on its own and set there the 
mount-path to /. However that solution is not my favourite since it 
means that I need to re-factor quite a lot of code.


So my question is I guess how can I configure the war servlet so its 
mounts on / and use the servlet- context?


Any ideas welcome.

--
Thorsten Scherler 
codeBusters S.L. - web based systems


http://www.codebusters.es/

Re: C2.2.1 block fails to start due to hidden dep to spring 3 (was Re: svn commit: r1381952)

2012-09-11 Thread Thorsten Scherler

On 09/11/2012 11:19 AM, Francesco Chicchiriccò wrote:

On 10/09/2012 20:30, Thorsten Scherler wrote:

[...]
This breaks jetty:run and I am ATM not sure why. It fails like:
...
Any ideas very welcome!

Hi Thorsten,
this is happening because the generated project is using the latest
version of the cocoon-maven-plugin (1.0.2) which in turn is enforcing
the latest versions of cocoon-rcl-webapp-wrapper (1.0.2) and
cocoon-rcl-spring-reloader (1.0.2); these are in turn dependent on
Spring 3.1.

Following the procedure reported above, I've changed (in the generated
pom.xml):

org.apache.cocoon
cocoon-maven-plugin
1.0.2

prepare
compile

prepare

into

org.apache.cocoon
cocoon-maven-plugin
1.0.0

org.apache.cocoon
cocoon-rcl-spring-reloader
1.0.0

org.apache.cocoon
cocoon-rcl-webapp-wrapper
1.0.0

prepare
compile

prepare

and now it works.

I'd suggest to make this changes to archetype resources's pom.xml.

Done and committed. Thanks for the finding.

Moreover, consider that when issuing 'mvn clean deploy' instead of
'mvn clean install', you will also upload the SNAPSHOT artifacts to
ASF maven repository (Nexus): since 2.2.X does not have a configured
Jenkins instance for this (like as C3), you still need to do this
manually when you want to publish updated SNAPSHOT artifacts.

Trying to fix that ATM but since I switch my box a while ago I never
came to setup the deploy to ASF preconditions. I am working on it now. I
get ATM for the "deploy"

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-deploy-plugin:2.6:deploy (default-deploy)
on project cocoon-22-archetype-block: Failed to deploy artifacts: Could
not transfer artifact
org.apache.cocoon:cocoon-22-archetype-block:jar:1.1.0-20120911.095051-2
from/to apache.snapshots.https
(https://repository.apache.org/content/repositories/snapshots): Failed
to transfer file:
https://repository.apache.org/content/repositories/snapshots/org/apache/cocoon/cocoon-22-archetype-block/1.1.0-SNAPSHOT/cocoon-22-archetype-block-1.1.0-20120911.095051-2.jar.
Return code is: 401 -> [Help 1]

Must be something with the credential setup.

salu2

--
Thorsten Scherler
codeBusters S.L. - web based systems

http://www.codebusters.es/

C2.2.1 block fails to start due to hidden dep to spring 3 (was Re: svn commit: r1381952)

2012-09-10 Thread Thorsten Scherler


On 09/07/2012 11:31 AM, thors...@apache.org wrote:

Author: thorsten
Date: Fri Sep  7 09:30:59 2012
New Revision: 1381952

URL: http://svn.apache.org/viewvc?rev=1381952&view=rev
Log:
COCOON-2233
Fixing and upgrading versions of artifact versions
BlockDeploymentServletContextListener to web.xml in the webapp archetype as 
required in trunk.
due to the fact the patch from Mark Lundquist is 4 years old in our issue 
tracker I did not apply it but rather re-did it.

Anyway thanks Mark Lundquist and sorry that we did not apply your patch earlier.

Modified:
...
 
cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml
...

Modified: 
cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml
URL: 
http://svn.apache.org/viewvc/cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml?rev=1381952&r1=1381951&r2=1381952&view=diff
==
--- 
cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml
 (original)
+++ 
cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml
 Fri Sep  7 09:30:59 2012
@@ -32,22 +32,22 @@
  
org.apache.cocoon
cocoon-core
-  2.2.0
+  2.2.1-SNAPSHOT
  
  
org.apache.cocoon
cocoon-servlet-service-components
-  1.0.0
+  1.1.0-SNAPSHOT
  
  
org.apache.cocoon
cocoon-template-impl
-  1.1.0
+  1.2.0-SNAPSHOT
  
  
org.apache.cocoon
cocoon-flowscript-impl
-  1.0.0
+  1.1.0-SNAPSHOT
  
  
javax.servlet
@@ -62,7 +62,7 @@

  org.apache.cocoon
  cocoon-maven-plugin
-1.0.0-M2
+1.0.2
  

  prepare
@@ -76,7 +76,7 @@

  org.mortbay.jetty
  maven-jetty-plugin
-6.1.7
+6.1.25
  

  
@@ -96,7 +96,7 @@


  maven-jar-plugin
-2.1
+2.4
  

  
@@ -107,7 +107,7 @@


  maven-eclipse-plugin
-2.5
+2.9

  



This breaks jetty:run and I am ATM not sure why. It fails like:

20:11:38.723 [main] ERROR o.s.web.context.ContextLoader - Context 
initialization failed

java.lang.NoClassDefFoundError: org/springframework/core/env/Environment
at java.lang.Class.getDeclaredConstructors0(Native Method) 
~[na:1.7.0_02-ea]
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2404) 
~[na:1.7.0_02-ea]

at java.lang.Class.getConstructor0(Class.java:2714) ~[na:1.7.0_02-ea]
at java.lang.Class.getDeclaredConstructor(Class.java:2002) 
~[na:1.7.0_02-ea]
at 
org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:61) 
~[spring-beans-2.5.1.jar:2.5.1]
at 
org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:249) 
~[spring-web-2.5.1.jar:2.5.1]
at 
org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:199) 
~[spring-web-2.5.1.jar:2.5.1]
at 
org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:45) 
[spring-web-2.5.1.jar:2.5.1]
at 
org.apache.cocoon.tools.rcl.wrapper.servlet.ReloadingListener.invoke(ReloadingListener.java:265) 
[cocoon-rcl-webapp-wrapper-1.0.2.jar:1.0.2]
at 
org.apache.cocoon.tools.rcl.wrapper.servlet.ReloadingListener.contextInitialized(ReloadingListener.java:150) 
[cocoon-rcl-webapp-wrapper-1.0.2.jar:1.0.2]
at 
org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548) 
[jetty-6.1.25.jar:6.1.25


You can reproduce it as follows.

cd src/apache/cocoon2.2/
svn up
mvn clean install
mkdir tmp
mvn archetype:generate -DarchetypeGroupId=org.apache.cocoon 
-DarchetypeArtifactId=cocoon-22-archetype-block 
-DarchetypeVersion=1.1.0-SNAPSHOT -DgroupId=my.groupid -DartifactId=2233 
-DarchetypeRepository=local

cd 2233
# make sure that the pom has
 
  org.apache.cocoon
   cocoon-core
   2.2.1-SNAPSHOT

mvn clean install jetty:run

then you will get above error in the console. :(

any idea why there is requested a class which is in spring 3.1 (which is 
not declared as dep) but cannot be found in the 2.5.x what we are using 
in 2.2.


Further I tested before I committed and there it was working (at least I 
think it did).


Anyway I tested now on another box to make sure and it is failing as 
described above.


Any ideas very welcome!

salu2

release 2.2.1

2012-09-07 Thread Thorsten Scherler


Hi all,

we from codebusters.es need a release 2.2.1 for one of our client.

I applied some outstanding issue and for the 4 which are still open I am 
not sure since I do not have any test case to test and some are more 
wishes (like release). ;)


Is there any guideline I should follow to push out the release?

Naturally 2.1.x and 3 should as well be released ASAP, where I see the 
2.1 less complicated since it is a maintenance release. However we lost 
a bit sight of doing an official c3 release and get a stable version out 
there.


salu2

--
Thorsten Scherler 
codeBusters S.L. - web based systems


http://www.codebusters.es/

[jira] [Closed] (COCOON-2222) Add SaxParser configuration properties


 [ 
https://issues.apache.org/jira/browse/COCOON-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thorsten Scherler closed COCOON-.
-

Resolution: Fixed
  Assignee: (was: Thorsten Scherler)

Committed revision 1381963.

> Add SaxParser configuration properties
> --
>
> Key: COCOON-
> URL: https://issues.apache.org/jira/browse/COCOON-
> Project: Cocoon
>  Issue Type: Improvement
>  Components: * Cocoon Core
>Affects Versions: 2.2, 2.2-dev (Current SVN)
>Reporter: Robin Wyles
> Fix For: 2.2, 2.2-dev (Current SVN)
>
> Attachments: sax-parser-config.patch
>
>
> Some Cocoon features do not work unless unless some non-default properties 
> are set on the SaxParser. 
> e.g CForms binding to XML documents containing namespaces requires that the 
> "nsPrefixes" property of the SaxParser be set to true, rather than the 
> default of false.
> Currently there is no way to configure these properties from within a block.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (COCOON-2222) Add SaxParser configuration properties


 [ 
https://issues.apache.org/jira/browse/COCOON-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thorsten Scherler reassigned COCOON-:
-

Assignee: Thorsten Scherler

> Add SaxParser configuration properties
> --
>
> Key: COCOON-
> URL: https://issues.apache.org/jira/browse/COCOON-
> Project: Cocoon
>  Issue Type: Improvement
>  Components: * Cocoon Core
>Affects Versions: 2.2, 2.2-dev (Current SVN)
>Reporter: Robin Wyles
>    Assignee: Thorsten Scherler
> Fix For: 2.2, 2.2-dev (Current SVN)
>
> Attachments: sax-parser-config.patch
>
>
> Some Cocoon features do not work unless unless some non-default properties 
> are set on the SaxParser. 
> e.g CForms binding to XML documents containing namespaces requires that the 
> "nsPrefixes" property of the SaxParser be set to true, rather than the 
> default of false.
> Currently there is no way to configure these properties from within a block.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (COCOON-2233) Update archetypes to current trunk artifact versions


 [ 
https://issues.apache.org/jira/browse/COCOON-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thorsten Scherler closed COCOON-2233.
-

   Resolution: Fixed
Fix Version/s: 2.2-dev (Current SVN)
 Assignee: (was: Thorsten Scherler)

Committed revision 1381952.
Thank you Mark

> Update archetypes to current trunk artifact versions
> 
>
> Key: COCOON-2233
> URL: https://issues.apache.org/jira/browse/COCOON-2233
> Project: Cocoon
>  Issue Type: Task
>  Components: - Build System: Maven
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Mark Lundquist
> Fix For: 2.2-dev (Current SVN)
>
> Attachments: PATCH-2233
>
>
> Patch updates artifact versions in cocoon archetypes to the current trunk 
> versions.
> * Also adds BlockDeploymentServletContextListener to web.xml in the webapp 
> archetype as required in trunk.
> * Some cosmetic cleanup as well

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (COCOON-2233) Update archetypes to current trunk artifact versions