cocoon3 block deployment

[Jos Snellings]

Hi,

When trying to deploy a cocoon-3 block to Tomcat, it does not seem to
find it:
java.lang.RuntimeException: There is no block 'YourBlockName' deployed.
The available blocks are {}.

I must say that the documentation on this issue is a little bit terse...
(http://cocoon.apache.org/subprojects/block-deployment/1.1/1471_1_1.html)

>From what I understand:
- pack block in a .jar file
- add a line to the manifest file META-INF/MANIFEST.MF :
  Cocoon-Block-Name: YourBlockName
  (yes it ends with a newline)
- place .jar in lib directory of webapp

Can anybody shed some light on this issue, please?

Thanks,
Jos



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Reinhard Pötz-2]

Jos Snellings wrote:

> Hi,
>
> When trying to deploy a cocoon-3 block to Tomcat, it does not seem to
> find it:
> java.lang.RuntimeException: There is no block 'YourBlockName' deployed.
> The available blocks are {}.
>
> I must say that the documentation on this issue is a little bit terse...
> (http://cocoon.apache.org/subprojects/block-deployment/1.1/1471_1_1.html)
>
>>From what I understand:
> - pack block in a .jar file
> - add a line to the manifest file META-INF/MANIFEST.MF :
>   Cocoon-Block-Name: YourBlockName
>   (yes it ends with a newline)
> - place .jar in lib directory of webapp
>
> Can anybody shed some light on this issue, please?

In order to use a Cocoon *block*, you also have to install the
BlockDeploymentServletContextListener in your web.xml:

<listener>
<listener-class>org.apache.cocoon.blockdeployment.BlockDeploymentServletContextListener</listener-class>
</listener>



If the block provides servlet-services, you have to use the
DispatcherServlet of the servlet-service-framework which collects and
mounts all servlets that are registered as Spring beans.

<servlet>
  <description>Cocoon blocks dispatcher</description>
  <display-name>DispatcherServlet</display-name>
  <servlet-name>DispatcherServlet</servlet-name>

<servlet-class>org.apache.cocoon.servletservice.DispatcherServlet</servlet-class>
  <load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
  <servlet-name>DispatcherServlet</servlet-name>
  <url-pattern>/*</url-pattern>
</servlet-mapping>



And of course you have to properly setup Spring:

<!--
Declare Spring context listener which sets up the Spring Application
Context containing all Cocoon components (and user defined beans as
well).
-->
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

<!--
Declare Spring request listener which sets up the required
RequestAttributes to support Springs and Cocoon custom bean scopes
like the request scope or the session scope.
-->
<listener>
<listener-class>org.springframework.web.context.request.RequestContextListener</listener-class>
</listener>


Does this answer your question?

--
Reinhard Pötz                           Managing Director, {Indoqa} GmbH
                         http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member                  reinhard@...
________________________________________________________________________

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Jos Snellings]

Thank you for the answer, Rheinhard,

I am afraid it does not. The web.xml I am using is from the cocoon
sample, and it contains all the necessary listeners. In the log file I
find startup information, but then it does not find the block.
By the way, if one expands the block's jar file under WEB-INF/classes,
so that we have:
   WEB-INF/classes/COB-INF
   WEB-INF/classes/META-INF
it should be found, no?

Jos

On Tue, 2009-11-10 at 14:48 +0100, Reinhard Pötz wrote:

> Jos Snellings wrote:
> > Hi,
> >
> > When trying to deploy a cocoon-3 block to Tomcat, it does not seem to
> > find it:
> > java.lang.RuntimeException: There is no block 'YourBlockName' deployed.
> > The available blocks are {}.
> >
> > I must say that the documentation on this issue is a little bit terse...
> > (http://cocoon.apache.org/subprojects/block-deployment/1.1/1471_1_1.html)
> >
> >>From what I understand:
> > - pack block in a .jar file
> > - add a line to the manifest file META-INF/MANIFEST.MF :
> >   Cocoon-Block-Name: YourBlockName
> >   (yes it ends with a newline)
> > - place .jar in lib directory of webapp
> >
> > Can anybody shed some light on this issue, please?
>
> In order to use a Cocoon *block*, you also have to install the
> BlockDeploymentServletContextListener in your web.xml:
>
> <listener>
> <listener-class>org.apache.cocoon.blockdeployment.BlockDeploymentServletContextListener</listener-class>
> </listener>
>
>
>
> If the block provides servlet-services, you have to use the
> DispatcherServlet of the servlet-service-framework which collects and
> mounts all servlets that are registered as Spring beans.
>
> <servlet>
>   <description>Cocoon blocks dispatcher</description>
>   <display-name>DispatcherServlet</display-name>
>   <servlet-name>DispatcherServlet</servlet-name>
>
> <servlet-class>org.apache.cocoon.servletservice.DispatcherServlet</servlet-class>
>   <load-on-startup>1</load-on-startup>
> </servlet>
> <servlet-mapping>
>   <servlet-name>DispatcherServlet</servlet-name>
>   <url-pattern>/*</url-pattern>
> </servlet-mapping>
>
>
>
> And of course you have to properly setup Spring:
>
> <!--
> Declare Spring context listener which sets up the Spring Application
> Context containing all Cocoon components (and user defined beans as
> well).
> -->
> <listener>
> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
> </listener>
>
> <!--
> Declare Spring request listener which sets up the required
> RequestAttributes to support Springs and Cocoon custom bean scopes
> like the request scope or the session scope.
> -->
> <listener>
> <listener-class>org.springframework.web.context.request.RequestContextListener</listener-class>
> </listener>
>
>
> Does this answer your question?
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Jos Snellings]

Yet something is missing, logging at debuglevel:
At startup, none of the methods in DeploymentUtil is ever called :-(

When a block's url is called it is not found:
2009-11-10 15:37:10,139 DEBUG main org.apache.jasper.servlet.JspServlet
- Scratch dir for the JSP engine
is: /usr/local/apache-tomcat-5.5.27/work/Catalina/localhost/testcocoon
2009-11-10 15:37:10,140 DEBUG main org.apache.jasper.servlet.JspServlet
- IMPORTANT: Do not modify the generated servlets
2009-11-10 15:37:46,378 DEBUG http-8080-Processor25
org.springframework.web.context.request.RequestContextListener - Bound
request context to thread:
org.apache.catalina.connector.RequestFacade@1480773
2009-11-10 15:37:46,402 DEBUG http-8080-Processor25
org.springframework.beans.factory.support.DefaultListableBeanFactory -
Returning cached instance of singleton bean
'org.apache.cocoon.servletservice.spring.BlockServletMap'
2009-11-10 15:37:46,421 DEBUG http-8080-Processor25
org.springframework.beans.factory.support.DefaultListableBeanFactory -
Returning cached instance of singleton bean
'org.springframework.aop.aspectj.AspectJPointcutAdvisor#0'
2009-11-10 15:37:46,429 INFO  http-8080-Processor25
org.apache.cocoon.servletservice.DispatcherServlet - No block for /
2009-11-10 15:37:46,429 DEBUG http-8080-Processor25
org.springframework.web.context.request.RequestContextListener - Cleared
thread-bound request context:
org.apache.catalina.connector.RequestFacade@1480773
2009-11-10 15:38:10,296 DEBUG
ContainerBackgroundProcessor[StandardEngine[Catalina]]
org.apache.catalina.session.ManagerBase - Start expire sessions
StandardManager at 1257863890296 sessioncount 0
2009-11-10 15:38:10,297 DEBUG
ContainerBackgroundProcessor[StandardEngine[Catalina]]
org.apache.catalina.session.ManagerBase - End expire sessions
StandardManager processingTime 1 expired sessions: 0

And sorry for misspelling your name, Reinhard.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Reinhard Pötz-2]

Jos Snellings wrote:

> Thank you for the answer, Rheinhard,
>
> I am afraid it does not. The web.xml I am using is from the cocoon
> sample, and it contains all the necessary listeners. In the log file I
> find startup information, but then it does not find the block.
> By the way, if one expands the block's jar file under WEB-INF/classes,
> so that we have:
>    WEB-INF/classes/COB-INF
>    WEB-INF/classes/META-INF
> it should be found, no?

No, I don't think that this works.

What libraries do you have in your /WEB-INF/lib directory?

--
Reinhard Pötz                           Managing Director, {Indoqa} GmbH
                         http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member                  reinhard@...
________________________________________________________________________

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Jos Snellings]

antlr-2.7.7.jar    
cocoon-configuration-api-1.0.2.jar
cocoon-servlet-3.0.0-alpha-1.jar  
commons-collections-3.2.jar spring-aop-2.5.5.jar stringtemplate-3.0.jar
aopalliance-1.0.jar    
cocoon-controller-3.0.0-alpha-1.jar
cocoon-servlet-service-impl-1.1.0.jar    
commons-io-1.4.jar
spring-beans-2.5.5.jar
aspectjrt-1.5.4.jar    
cocoon-jnet-1.0.0.jar  cocoon-sitemap-3.0.0-alpha-1.jar  
commons-jexl-1.1.jar
log4j-1.2.14.jar      
spring-context-2.5.5.jar
aspectjweaver-1.5.4.jar      
cocoon-pipeline-3.0.0-alpha-1.jar
cocoon-spring-configurator-2.0.0.jar  
commons-lang-2.3.jar
servlet-api-2.3.jar  
spring-core-2.5.5.jar
cocoon-block-deployment.jar  
cocoon-rest-3.0.0-alpha-1.jar  cocoon-stringtemplate-3.0.0-alpha-1.jar
commons-logging-1.1.jar sigblok.jar -----------------------------> this
is the block      
spring-web-2.5.5.jar

Are these not the dependencies mentioned in the pom file?


On Wed, 2009-11-11 at 08:47 +0100, Reinhard Pötz wrote:

> Jos Snellings wrote:
> > Thank you for the answer, Rheinhard,
> >
> > I am afraid it does not. The web.xml I am using is from the cocoon
> > sample, and it contains all the necessary listeners. In the log file I
> > find startup information, but then it does not find the block.
> > By the way, if one expands the block's jar file under WEB-INF/classes,
> > so that we have:
> >    WEB-INF/classes/COB-INF
> >    WEB-INF/classes/META-INF
> > it should be found, no?
>
> No, I don't think that this works.
>
> What libraries do you have in your /WEB-INF/lib directory?
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Reinhard Pötz-2]

Have you also tried to use Cocoon 3 trunk to build and run your application?

Jos Snellings wrote:

> antlr-2.7.7.jar    
> cocoon-configuration-api-1.0.2.jar
> cocoon-servlet-3.0.0-alpha-1.jar  
> commons-collections-3.2.jar spring-aop-2.5.5.jar stringtemplate-3.0.jar
> aopalliance-1.0.jar    
> cocoon-controller-3.0.0-alpha-1.jar
> cocoon-servlet-service-impl-1.1.0.jar    
> commons-io-1.4.jar
> spring-beans-2.5.5.jar
> aspectjrt-1.5.4.jar    
> cocoon-jnet-1.0.0.jar  cocoon-sitemap-3.0.0-alpha-1.jar  
> commons-jexl-1.1.jar
> log4j-1.2.14.jar      
> spring-context-2.5.5.jar
> aspectjweaver-1.5.4.jar      
> cocoon-pipeline-3.0.0-alpha-1.jar
> cocoon-spring-configurator-2.0.0.jar  
> commons-lang-2.3.jar
> servlet-api-2.3.jar  
> spring-core-2.5.5.jar
> cocoon-block-deployment.jar  
> cocoon-rest-3.0.0-alpha-1.jar  cocoon-stringtemplate-3.0.0-alpha-1.jar
> commons-logging-1.1.jar sigblok.jar -----------------------------> this
> is the block      
> spring-web-2.5.5.jar
>
> Are these not the dependencies mentioned in the pom file?
>
>
> On Wed, 2009-11-11 at 08:47 +0100, Reinhard Pötz wrote:
>> Jos Snellings wrote:
>>> Thank you for the answer, Rheinhard,
>>>
>>> I am afraid it does not. The web.xml I am using is from the cocoon
>>> sample, and it contains all the necessary listeners. In the log file I
>>> find startup information, but then it does not find the block.
>>> By the way, if one expands the block's jar file under WEB-INF/classes,
>>> so that we have:
>>>    WEB-INF/classes/COB-INF
>>>    WEB-INF/classes/META-INF
>>> it should be found, no?
>> No, I don't think that this works.
>>
>> What libraries do you have in your /WEB-INF/lib directory?
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

--
Reinhard Pötz                           Managing Director, {Indoqa} GmbH
                         http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member                  reinhard@...
________________________________________________________________________

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Jos Snellings]

You mean this would yield the better versions?
Yes I have the cocoon trunk from alpha-2 level, and they were converted
to eclipse projects.
You mean if I build this together the result might be far better?
OK, I will do that.

By the way, when is the beta coming about? Now I need it.

Thanks,
Jos


On Wed, 2009-11-11 at 09:42 +0100, Reinhard Pötz wrote:

> Have you also tried to use Cocoon 3 trunk to build and run your application?
>
> Jos Snellings wrote:
> > antlr-2.7.7.jar    
> > cocoon-configuration-api-1.0.2.jar
> > cocoon-servlet-3.0.0-alpha-1.jar  
> > commons-collections-3.2.jar spring-aop-2.5.5.jar stringtemplate-3.0.jar
> > aopalliance-1.0.jar    
> > cocoon-controller-3.0.0-alpha-1.jar
> > cocoon-servlet-service-impl-1.1.0.jar    
> > commons-io-1.4.jar
> > spring-beans-2.5.5.jar
> > aspectjrt-1.5.4.jar    
> > cocoon-jnet-1.0.0.jar  cocoon-sitemap-3.0.0-alpha-1.jar  
> > commons-jexl-1.1.jar
> > log4j-1.2.14.jar      
> > spring-context-2.5.5.jar
> > aspectjweaver-1.5.4.jar      
> > cocoon-pipeline-3.0.0-alpha-1.jar
> > cocoon-spring-configurator-2.0.0.jar  
> > commons-lang-2.3.jar
> > servlet-api-2.3.jar  
> > spring-core-2.5.5.jar
> > cocoon-block-deployment.jar  
> > cocoon-rest-3.0.0-alpha-1.jar  cocoon-stringtemplate-3.0.0-alpha-1.jar
> > commons-logging-1.1.jar sigblok.jar -----------------------------> this
> > is the block      
> > spring-web-2.5.5.jar
> >
> > Are these not the dependencies mentioned in the pom file?
> >
> >
> > On Wed, 2009-11-11 at 08:47 +0100, Reinhard Pötz wrote:
> >> Jos Snellings wrote:
> >>> Thank you for the answer, Rheinhard,
> >>>
> >>> I am afraid it does not. The web.xml I am using is from the cocoon
> >>> sample, and it contains all the necessary listeners. In the log file I
> >>> find startup information, but then it does not find the block.
> >>> By the way, if one expands the block's jar file under WEB-INF/classes,
> >>> so that we have:
> >>>    WEB-INF/classes/COB-INF
> >>>    WEB-INF/classes/META-INF
> >>> it should be found, no?
> >> No, I don't think that this works.
> >>
> >> What libraries do you have in your /WEB-INF/lib directory?
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
> >
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Jos Snellings]

Are
jnet and
block-deployment
servlet-service
likely to change for 3.0? I think not.
Is cocoon-configuration needed?
 
Thanks,
Jos


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Reinhard Pötz-2]

Jos Snellings wrote:
> You mean this would yield the better versions?
> Yes I have the cocoon trunk from alpha-2 level, and they were converted
> to eclipse projects.
> You mean if I build this together the result might be far better?

It might be that you run into a problem that was solved with one of the
current versions
cocoon-jnet/cocoon-servlet-service-impl/cocoon-spring-configurator .

> OK, I will do that.
>
> By the way, when is the beta coming about? Now I need it.

I'm almost there to create the release artifacts for alpha-2 - there is
only one issue left.

Reinhard

--
Reinhard Pötz                           Managing Director, {Indoqa} GmbH
                         http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member                  reinhard@...
________________________________________________________________________

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Jos Snellings]

Please find below the follow up on the tomcat deployment problem. I am sure it is of interest
to a lot of users:
With the latest sources checked out from svn, built in eclipse the problem is solved.

Deployment under tomcat:
1. add xercesImpl.jar
2. in the local build I have no pom.properties file included in the jar
   (in fact, in my builds there is no META-INF/maven), so XMLSitemapServlet.initVersionNumber() will fail,
   I stubbed that method for the time being.
3. An entry Cocoon-Block-Name in the manifest file is not necessary, this invalidates:
   http://cocoon.apache.org/subprojects/block-deployment/1.1/1471_1_1.html

Blocks are neatly deployed under the mount point specified in the servlet-service bean declaration.

I had to adapt the samples to the alpha-2 level. Some classes were refactored to cocoon-sax, others are obsolete.
Is the new version available? Care for the adapted code?

Cheers,
Jos



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Reinhard Pötz-2]

Jos Snellings wrote:
> Please find below the follow up on the tomcat deployment problem. I am sure it is of interest
> to a lot of users:
> With the latest sources checked out from svn, built in eclipse the problem is solved.
>
> Deployment under tomcat:
> 1. add xercesImpl.jar
> 2. in the local build I have no pom.properties file included in the jar
>    (in fact, in my builds there is no META-INF/maven), so XMLSitemapServlet.initVersionNumber() will fail,
>    I stubbed that method for the time being.

So you don't use Maven to build Cocoon 3 trunk?

> 3. An entry Cocoon-Block-Name in the manifest file is not necessary, this invalidates:
>    http://cocoon.apache.org/subprojects/block-deployment/1.1/1471_1_1.html

The blockcontext:/ protocol usually used in the Servlet-Service
definition relies on this entry. Without it, the servlet context can't
be resolved correctly.

> Blocks are neatly deployed under the mount point specified in the servlet-service bean declaration.

It's good to hear but I wonder how this can work for you at all ;-)

> I had to adapt the samples to the alpha-2 level. Some classes were refactored to cocoon-sax, others are obsolete.
> Is the new version available? Care for the adapted code?

What do you mean by "new version"?

--
Reinhard Pötz                           Managing Director, {Indoqa} GmbH
                         http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member                  reinhard@...
________________________________________________________________________

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Robin Rigby]

Suffering great frustration deploying Cocoon 2.2 to Tomcat.   Reverted to
the tutorial to check the basics.  Hope following notes will help someone
else avoid pain.

Robin

- SUMMARY -------------------

A. Tutorial page 1.  Welcome page has a link to spring bean
which fails if called from

  http://localhost:8888/myBlock1

but succeeds when called from  
 
  http://localhost:8888/myBlock1/
 
Link is not properly fixed up.  See #2 below.
 
B. Tutorial page 4. Parent POM fails to compile myCocoonWebapp.
Cannot find correct version of maven-war-plugin.  Solutions found
on mailing list do not work.  See #5 below.

C. <servlet:context/@mount-path="" ...> is not sufficient to mount
the web app as ROOT in Tomcat.  The war file must be ROOT.war
(or the app must be deployed with a context fragment from
elsewhere in the file system).  See #7 below.

D. <finalName>ROOT</finalName> is not sufficient to mount
the web app as ROOT in Jetty.  Change <webAppSourceDirectory/>.  
See #9 below.

E. Tomcat does not unpack ROOT.war if there is a context
fragment ROOT.xml.  Check and remove the conflicting file.
See #10 below.

F. <finalName>ROOT</finalName> is not sufficient to deploy
the web app as ROOT in Tomcat with tomcat-maven-plugin.  
Add context path. See #12 below.  

- START ----------------------

1.  Create new tutorial blocks

  {...}/myBlock1
  {...}/myBlock2

from

  http://cocoon.apache.org/2.2/1159_1_1.html
  http://cocoon.apache.org/2.2/1290_1_1.html
  http://cocoon.apache.org/2.2/1291_1_1.html

2.  Run under Jetty + rcl

  cd {...}/myBlock1
  mvn compile jetty:run

browse to

  http://localhost:8888/myBlock1/

works fine                      <--- OK

But note that

  http://localhost:8888/myBlock1

works OK (without trailing slash) but then the
link to the Spring bean fails

  http://localhost:8888/spring-bean   <--- FAIL

instead of

  http://localhost:8888/myBlock1/spring-bean

This is not good on page one of the tutorial.

3.  Add webapp block and parent POM

  {...}/myCocoonWebApp
  {...}/pom.xml

from

  http://cocoon.apache.org/2.2/1362_1_1.html

4.  Run under Jetty + war file

  cd {...}/myBlock1
  mvn install
  cd {...}/myBlock2
  mvn install
  cd {...}/myCocoonWebApp
  mvn package jetty:run

browse to

  http://localhost:8888/

works fine                      <--- OK

5.  Reactor build from parent POM

  cd {...}
  mvn install

Build fails with           <-- FAIL

  Internal error in the plugin manager
    executing goal 'org.apache.maven.plugins:maven-war-plugin:2.0.2:war':
    Unable to find the mojo
'org.apache.maven.plugins:maven-war-plugin:2.0.2:war'
    in the plugin 'org.apache.maven.plugins:maven-war-plugin'
  Component descriptor cannot be found in the component repository:
 
org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-war-plugin:2.0.2:
war.

This has been an unsolved problem since I first tested Cocoon 2.2.  There
are two
issues here:  

  i.  The tutorial fails [on my machine] despite the standardisation offered
by Maven.
  ii. The requested plugin is not found in the (any?) repository.

6.  There two solutions at

  http://issues.apache.org/jira/browse/COCOON-2240

Neither one works.  The second solution changes the version number in the
above
message from 2.0.2 to 2.1-beta-1.

7.  Work around.  Go back to 4 above and copy

  myCocoonWebApp-1.0.0.war

to {tomcat 5.5.20}/webapps. Browse to

  http://localhost:8080/           <-- FAIL

Get error 404 from Tomcat.  But browse to

  http://localhost:8080/myCocoonWebApp-1.0.0/

and it finds the page.  Tomcat ignores the servlet:context/@mount-path=""
attribute in block-servlet-service.xml

8.  Rename the WAR file ROOT.xml by setting

  <finalName>ROOT</finalName>

in the POM for myCocoonWebApp.  See

  http://mojo.codehaus.org/tomcat-maven-plugin/usage.html

9.  Test with

  cd {...}/myCocoonWebApp
  mvn clean install jetty:run

This fails with          <-- FAIL

  Webapp source directory
    {...}\myCocoonWebApp\target\myCocoonWebApp-1.0.0
    does not exist

Maven has built a ROOT directory and ROOT.war but installed
myCocoonWebApp-1.0.0.war
in the repository (which could be OK).  Jetty has not recognized the
<finalName/>.
Fix this by changing maven-jetty-plugin in

  {...}/myCocoonWebApp/pom.xml

under

  <build>
    <plugins>
      <plugin>
        <groupId>org.mortbay.jetty</groupId>
        <artifactId>maven-jetty-plugin</artifactId>
        <version>6.1.7</version>
        <configuration>

change

 
<webAppSourceDirectory>${project.build.directory}/${pom.artifactId}-${pom.ve
rsion}</webAppSourceDirectory>

to

 
<webAppSourceDirectory>${project.build.directory}/ROOT</webAppSourceDirector
y>

Browse to

  http://localhost:8080/           <-- OK

10. Test by copying

  ROOT.war

to {tomcat 5.5.20}/webapps. Browse to

  http://localhost:8080/           <-- FAIL

and Tomcat has not unpacked ROOT.war, though it unpacked the other
(see #7, above).

Restart Tomcat.  No mention of ROOT.war in {tomcat 5.5.20}/logs.

Check {tomcat 5.5.20}/conf/{engineName}/{hostName} for ROOT.xml.  Remove it.
Tomcat unpacks ROOT.war. Browse to

  http://localhost:8080/           <-- SUCCESS

11. OK, now remove ROOT.war and ROOT subdirectory from {tomcat
5.5.20}/webapps.
Log in to the Tomcat manager

  http://localhost:8080/manager/html

Deploy

  {...}\myCocoonWebApp\target\ROOT.war

Browse to

  http://localhost:8080/           <-- OK

12. Again, remove ROOT.war and ROOT subdirectory from {tomcat
5.5.20}/webapps.
Add in

  {...}/myCocoonWebApp/pom.xml

under

  <build>
    <plugins>

a new plugin

      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>tomcat-maven-plugin</artifactId>
        <version>1.0-beta-1</version>
        <configuration>
          <url>http://localhost:8080/manager</url>
          <server>tomcat-local</server>
        </configuration>
      </plugin>

Set up the server tomcat-local in your Maven settings file

  {userHome}/.m2/settings.xml

under

  <settings>
    <servers>
 
a new server

      <server>
        <id>tomcat-local</id>
        <username>uname</username>
        <password>pwd</password>
      </server>

All as given at

  http://mojo.codehaus.org/tomcat-maven-plugin/usage.html

Deploy with

  cd {...}/myCocoonWebApp
  mvn tomcat:deploy

Browse to

  http://localhost:8080/           <-- FAIL

The plugin has ignored <finalName/>.  Maven has again built a
ROOT directory and ROOT.war but installed myCocoonWebApp.war
which works fine but is not required.

Browse to

  http://localhost:8080/myCocoonWebApp/       <-- OK but not useful

Add the context path

      <server>
        <id>tomcat-local</id>
        <username>uname</username>
        <password>pwd</password>
        <path>/ROOT</path>
      </server>

Redeploy with

  mvn tomcat:redeploy

Browse to

  http://localhost:8080/           <-- QED

- END -----------
   





---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Jos Snellings]

>It's good to hear but I wonder how this can work for you at all ;-)

Well, this is admittedly a bit exceptional. In this forum, mostly people
invest efforts to figure out why something does not work, we are about
to try to find out why something works ;-)
Anyway, where is the code where this happens. blockcontexts are
registered via jnet, no? Blockcontexts are mounted in
cocoon-block-deployment.

On not using maven:
Every single project comes with an eclipse goal, so mvn eclipse:eclipse
builds a nice importable project. After import the 'autobuild' is on,
so, I just grab COB-INF and META-INF together with 'jar cvf
somesample.jar, and the cocoon block is ready.

I mainly suppressed maven to replace all internal cocoon dependencies by
dependencies on the mutual projects, rather than making them rely on the
maven repository. This enables me to 'tweak' the code if necessary. In
any case, it allows me to better understand what's happening. One day I
must write a 'cocoon for blondes' page.

New version:
I depart from 'getting started', get the maven archetypes and artefacts:
mvn org.apache.maven.plugins:maven-archetype-plugin:1.0-alpha-7:create
-DarchetypeGroupId=org.apache.cocoon.archetype-sample
-DarchetypeArtifactId=cocoon-archetype-sample
-DarchetypeVersion=3.0.0-alpha-1 -DgroupId=org.tanteterra
-DartifactId=newsample

What are the magic words for the alpha2 archetype?
I come back with a list of compilation errors.

Cheers,
Jos

On Tue, 2009-11-17 at 15:38 +0100, Reinhard Pötz wrote:

> Jos Snellings wrote:
> > Please find below the follow up on the tomcat deployment problem. I am sure it is of interest
> > to a lot of users:
> > With the latest sources checked out from svn, built in eclipse the problem is solved.
> >
> > Deployment under tomcat:
> > 1. add xercesImpl.jar
> > 2. in the local build I have no pom.properties file included in the jar
> >    (in fact, in my builds there is no META-INF/maven), so XMLSitemapServlet.initVersionNumber() will fail,
> >    I stubbed that method for the time being.
>
> So you don't use Maven to build Cocoon 3 trunk?
>
> > 3. An entry Cocoon-Block-Name in the manifest file is not necessary, this invalidates:
> >    http://cocoon.apache.org/subprojects/block-deployment/1.1/1471_1_1.html
>
> The blockcontext:/ protocol usually used in the Servlet-Service
> definition relies on this entry. Without it, the servlet context can't
> be resolved correctly.
>
> > Blocks are neatly deployed under the mount point specified in the servlet-service bean declaration.
>
> It's good to hear but I wonder how this can work for you at all ;-)
>
> > I had to adapt the samples to the alpha-2 level. Some classes were refactored to cocoon-sax, others are obsolete.
> > Is the new version available? Care for the adapted code?
>
> What do you mean by "new version"?
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...