from:"Thorsten Scherler"

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 MapString, Object 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.EntryString, Object 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 scherler.at.gmail.com
codeBusters S.L. - web based systems
consulting, training and solutions

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 scherler.at.gmail.com
codeBusters S.L. - web based systems
consulting, training and solutions

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 scherler.at.gmail.com
codeBusters S.L. - web based systems
consulting, training and solutions

http://www.codebusters.es/

Re: REST view and weird error

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=1450217r1=1450216r2=1450217view=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 scherler.at.gmail.com
codeBusters S.L. - web based systems
consulting, training and solutions

http://www.codebusters.es/

Re: REST view and weird error

Hi all,

actually I tried with

HashMapString, Object data = new HashMapString, Object();
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:

div id=properties class=tab_content
dl
  $properties.keys:{k|
  dt$k$/dt
  dd
  ![CDATA[$properties.(k)$]]
  /dd
  }$
/dl
  /div

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'
 HashMapString, Object data = new HashMapString, Object();

 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 {
 HashMapString, Object data = new HashMapString, Object();
 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

 root
 level value=WARN/
 appender-ref ref=CORE/
 /root

 Any ideas?

 salu2

 --
 Thorsten Scherler scherler.at.gmail.com codeBusters S.L. - web based 
 systems consulting, training and solutions

 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 scherler.at.gmail.com
codeBusters S.L. - web based systems
consulting, training and solutions

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

 HashMapString, Object data = new HashMapString, Object();
 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:

 div id=properties class=tab_content
 dl
   $properties.keys:{k|
   dt$k$/dt
   dd
   ![CDATA[$properties.(k)$]]
   /dd
   }$
 /dl
   /div

 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.

logger name=org.apache.cocoon additivity=false
level value=WARN/
appender-ref ref=CORE/
/logger

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 scherler.at.gmail.com
codeBusters S.L. - web based systems
consulting, training and solutions

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

 servlet:context mount-path=/mysite
 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:

build
resources
  resource
directorysrc/main/resources/directory
filteringfalse/filtering
excludes
  excludeMETA-INF/cocoon/spring/**/exclude
/excludes
  /resource
  resource
directorysrc/main/resources/META-INF/cocoon/spring/directory
filteringtrue/filtering
targetPath${project.build.outputDirectory}/META-INF/cocoon/spring
/targetPath
  /resource
/resources
  /build

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.

build
filters
  filter../src/main/filter/general.properties/filter
  filter../src/main/filter/${env}.properties/filter
/filters
resources
  resource
directorysrc/main/resources/directory
filteringfalse/filtering
excludes
  excludeMETA-INF/cocoon/spring/**/exclude
  excludeMETA-INF/cocoon/properties/**/exclude
/excludes
  /resource
  resource
directorysrc/main/resources/META-INF/cocoon/spring/directory
filteringtrue/filtering
   
targetPath${project.build.outputDirectory}/META-INF/cocoon/spring/targetPath
  /resource
  resource
directorysrc/main/resources/META-INF/cocoon/properties/directory
filteringtrue/filtering
   
targetPath${project.build.outputDirectory}/META-INF/cocoon/properties/targetPath
  /resource
/resources

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 scherler.at.gmail.com
codeBusters S.L. - web based systems
consulting, training and solutions

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

 HashMapString, Object data = new HashMapString, Object();
 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:

 div id=properties class=tab_content
 dl
   $properties.keys:{k|
   dt$k$/dt
   dd
   ![CDATA[$properties.(k)$]]
   /dd
   }$
 /dl
   /div

 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.
 logger name=org.apache.cocoon additivity=false
 level value=WARN/
 appender-ref ref=CORE/
 /logger

 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 scherler.at.gmail.com
codeBusters S.L. - web based systems
consulting, training and solutions

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 {
HashMapString, Object data = new HashMapString, Object();
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

root
level value=WARN/
appender-ref ref=CORE/
/root

Any ideas?

salu2

-- 
Thorsten Scherler scherler.at.gmail.com
codeBusters S.L. - web based systems
consulting, training and solutions

http://www.codebusters.es/

[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 

   appender name=FAILS class=ch.qos.logback.core.FileAppender
file${crawler.log.error}/file
appendfalse/append
encoder class=ch.qos.logback.core.encoder.LayoutWrappingEncoder
  layout class=ch.qos.logback.classic.log4j.XMLLayout
locationInfotrue/locationInfo
  /layout
/encoder
/appender

The implemented solution has the following configuration in spring:

  bean name=generator:log4j 
class=org.apache.cocoon.optional.pipeline.components.sax.generator.AddRootElementGenerator
 scope=prototype
property name=encoding value=UTF-8/
property name=localName value=events/
property name=prefix value=log4j/
property name=namespace value=http://jakarta.apache.org/log4j//
  /bean

and later parse the file that the appender gives like:
map:pipeline
  map:match pattern=errorLogs
map:generate src=${crawler.log.error} type=log4j/
map:serialize type=xml /
  /map:match
/map:pipeline

which will result in something like:
?xml version=1.0 encoding=UTF-8?
log4j:events xmlns:log4j=http://jakarta.apache.org/log4j/;
  log4j:event logger=org.apache.droids.exception.ExceptionHandler 
timestamp=1361325224196 level=ERROR thread=main
   log4j:message![CDATA[org.apache.droids.core.DroidsException: 
org.apache.droids.core.DroidsException: org.apache.droids.core.DroidsException: 
org.apache.http.client.HttpResponseException: Internal Server Error 
http://localhost:/xxx/details/xxx]]
  /log4j:message
  log4j:locationInfo class=org.apache.droids.exception.ExceptionHandler 
method=handleException file=ExceptionHandler.java line=23/
 /log4j:event
/log4j:events

--
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-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 
appender name=FAILS class=ch.qos.logback.core.FileAppender
 file${crawler.log.error}/file
 appendfalse/append
 encoder class=ch.qos.logback.core.encoder.LayoutWrappingEncoder
   layout class=ch.qos.logback.classic.log4j.XMLLayout
 locationInfotrue/locationInfo
   /layout
 /encoder
 /appender
 The implemented solution has the following configuration in spring:
   bean name=generator:log4j 
 class=org.apache.cocoon.optional.pipeline.components.sax.generator.AddRootElementGenerator
  scope=prototype
 property name=encoding value=UTF-8/
 property name=localName value=events/
 property name=prefix value=log4j/
 property name=namespace value=http://jakarta.apache.org/log4j//
   /bean
 and later parse the file that the appender gives like:
 map:pipeline
   map:match pattern=errorLogs
 map:generate src=${crawler.log.error} type=log4j/
 map:serialize type=xml /
   /map:match
 /map:pipeline
 which will result in something like:
 ?xml version=1.0 encoding=UTF-8?
 log4j:events xmlns:log4j=http://jakarta.apache.org/log4j/;
   log4j:event logger=org.apache.droids.exception.ExceptionHandler 
 timestamp=1361325224196 level=ERROR thread=main
log4j:message![CDATA[org.apache.droids.core.DroidsException: 
 org.apache.droids.core.DroidsException: 
 org.apache.droids.core.DroidsException: 
 org.apache.http.client.HttpResponseException: Internal Server Error 
 http://localhost:/xxx/details/xxx]]
   /log4j:message
   log4j:locationInfo class=org.apache.droids.exception.ExceptionHandler 
 method=handleException file=ExceptionHandler.java line=23/
  /log4j:event
 /log4j:events

--
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

[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

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 scherler.at.gmail.com
codeBusters S.L. - web based systems
consulting, training and solutions

http://www.codebusters.es/

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 @@
   dependencies
 dependency
   groupIdcom.mycompany/groupId
-  artifactIdmysite2/artifactId
+  artifactIdmysite/artifactId
   version${project.version}/version
 /dependency


alu2

-- 
Thorsten Scherler scherler.at.gmail.com
codeBusters S.L. - web based systems
consulting, training and solutions

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 scherler.at.gmail.com
codeBusters S.L. - web based systems
consulting, training and solutions

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.xmlhttps://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.ziphttps://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/KEYShttp://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 thorsten.at.codebusters.es
codeBusters S.L. - web based systems
consulting, training and solutions

Tel.: +34 954 520 169
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.xmlhttps://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.ziphttps://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/KEYShttp://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 thorsten.at.codebusters.es
codeBusters S.L. - web based systems
consulting, training and solutions

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-tabpanelfocusedCommentId=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(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

[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-tabpanelfocusedCommentId=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 scherler.at.gmail.com
codeBusters S.L. - web based systems
consulting, training and solutions

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

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

[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-tabpanelfocusedCommentId=13482880#comment-13482880
 ] 

Thorsten Scherler commented on COCOON3-107:
---

add bean name=expression-language:blockcontext 
class=org.apache.cocoon.sitemap.expression.BlockcontextInterpreter / 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

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

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 scherler.at.gmail.com
codeBusters S.L. - web based systems
consulting, training and solutions

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 scherler.at.gmail.com
codeBusters S.L. - web based systems
consulting, training and solutions

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 scherler.at.gmail.com
codeBusters S.L. - web based systems
consulting, training and solutions

http://www.codebusters.es/

[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
   Alternatively, if you host your own repository you can deploy the file 
 there:
   mvn deploy:deploy-file -DgroupId=daisy 
 -DartifactId=daisy-repository-common-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

[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 repository you can deploy the file 
 there:
   mvn deploy:deploy-file -DgroupId=daisy 
 -DartifactId=daisy-repository-common-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-common-impl:jar:1.5-dev
 6

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:
map:generate src=cocoon://{relative-url}/
* within an xslt calling
xsl:variable name=var select='cocoon://{relative-url}' /
* 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?

map:generate src={someBlock}://{relative-url}/

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 scher...@gmail.com
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

servlet:context mount-path=/${blockId}
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:

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 scher...@gmail.com 
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:
  map:generate src=cocoon://{relative-url}/
* within an xslt calling
xsl:variable name=var select='cocoon://{relative-url}' /
* 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?

map:generate src={someBlock}://{relative-url}/


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
scher...@gmail.com 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ò

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

servlet:context mount-path=/${blockId}
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 scherler.at.gmail.com
codeBusters S.L. - web based systems
consulting, training and solutions

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-25 Thread Thorsten Scherler (JIRA)


[ 
https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 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

[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 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

[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-tabpanelfocusedCommentId=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. 
 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

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 scherler.at.gmail.com
codeBusters S.L. - web based systems
consulting, training and solutions

http://www.codebusters.es/

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)
j...@apache.org mailto:j...@apache.org wrote:

[

https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 codeURLStreamHandler/code 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 codehttp/code, codeftp/code, or
* codegopher/code.
* p
* In most cases, an instance of a codeURLStreamHandler/code
* subclass is not created directly by an application. Rather, the
* first time a protocol name is encountered when constructing a
* codeURL/code, 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

[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 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

[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-tabpanelfocusedCommentId=13456938#comment-13456938
 ] 

Thorsten Scherler commented on COCOON3-105:
---

We need to find a way to get the 
this.blockContexts = (MapString, String) 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/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

[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-tabpanelfocusedCommentId=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 codeURLStreamHandler/code 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 codehttp/code, codeftp/code, or
 * codegopher/code.
 * p
 * In most cases, an instance of a codeURLStreamHandler/code
 * subclass is not created directly by an application. Rather, the
 * first time a protocol name is encountered when constructing a
 * codeURL/code, 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]
   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

[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

[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-tabpanelfocusedCommentId=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] [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-tabpanelfocusedCommentId=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] [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] [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 
listener-classorg.apache.cocoon.blockdeployment.BlockDeploymentServletContextListener/listener-class

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

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):


plugin
groupIdorg.apache.cocoon/groupId
artifactIdcocoon-maven-plugin/artifactId
version1.0.2/version
executions
  execution
idprepare/id
phasecompile/phase
goals
  goalprepare/goal
/goals
  /execution
/executions
  /plugin

into

plugin
groupIdorg.apache.cocoon/groupId
artifactIdcocoon-maven-plugin/artifactId
version1.0.0/version
dependencies
!-- RCL --
dependency
  groupIdorg.apache.cocoon/groupId
artifactIdcocoon-rcl-spring-reloader/artifactId
  version1.0.0/version
/dependency
dependency
  groupIdorg.apache.cocoon/groupId
artifactIdcocoon-rcl-webapp-wrapper/artifactId
  version1.0.0/version
/dependency
/dependencies
executions
  execution
idprepare/id
phasecompile/phase
goals
  goalprepare/goal
/goals
  /execution
/executions
  /plugin

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 scherler.at.gmail.com
codeBusters S.L. - web based systems
consulting, training and solutions

http://www.codebusters.es/

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)


bean id=es.sadesi.boja class=org.apache.cocoon.sitemap.SitemapServlet
servlet:context mount-path= context-path=/
  servlet:connections
entry key=clientBlock value-ref=es.clientBlock.service/
  /servlet:connections
/servlet:context
  /bean

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 scherler.at.gmail.com
codeBusters S.L. - web based systems
consulting, training and solutions

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=1381952view=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=1381952r1=1381951r2=1381952view=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 @@
  dependency
groupIdorg.apache.cocoon/groupId
artifactIdcocoon-core/artifactId
-  version2.2.0/version
+  version2.2.1-SNAPSHOT/version
  /dependency
  dependency
groupIdorg.apache.cocoon/groupId
artifactIdcocoon-servlet-service-components/artifactId
-  version1.0.0/version
+  version1.1.0-SNAPSHOT/version
  /dependency
  dependency
groupIdorg.apache.cocoon/groupId
artifactIdcocoon-template-impl/artifactId
-  version1.1.0/version
+  version1.2.0-SNAPSHOT/version
  /dependency
  dependency
groupIdorg.apache.cocoon/groupId
artifactIdcocoon-flowscript-impl/artifactId
-  version1.0.0/version
+  version1.1.0-SNAPSHOT/version
  /dependency
  dependency
groupIdjavax.servlet/groupId
@@ -62,7 +62,7 @@
plugin
  groupIdorg.apache.cocoon/groupId
  artifactIdcocoon-maven-plugin/artifactId
-version1.0.0-M2/version
+version1.0.2/version
  executions
execution
  idprepare/id
@@ -76,7 +76,7 @@
plugin
  groupIdorg.mortbay.jetty/groupId
  artifactIdmaven-jetty-plugin/artifactId
-version6.1.7/version
+version6.1.25/version
  configuration
connectors
  connector 
implementation=org.mortbay.jetty.nio.SelectChannelConnector
@@ -96,7 +96,7 @@
/plugin
plugin
  artifactIdmaven-jar-plugin/artifactId
-version2.1/version
+version2.4/version
  configuration
archive
  manifestEntries
@@ -107,7 +107,7 @@
/plugin
plugin
  artifactIdmaven-eclipse-plugin/artifactId
-version2.5/version
+version2.9/version
/plugin
  /plugins
/build


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

[jira] [Assigned] (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 reassigned COCOON-2233:
-

Assignee: Thorsten Scherler

 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
Assignee: Thorsten Scherler
 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] [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-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-2222) Add SaxParser configuration properties