You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Marc Portier <mp...@outerthought.org> on 2007/05/22 17:30:37 UTC

2.2 deploying as webapp

Hi there,

I'm getting further into trying the 2.2 stuff out, and with two testing 
blocks somewhat functional I was trying out deployment to webapp as 
described in:

http://cocoon.zones.apache.org/daisy/cdocs-site-main/g2/1362.html

the weird thing I'm seeing is that the dispatcher-servlet apparently 
gets totally confused


Here is my setup

+ block1
    + pom.xml
    + src/main/resources/COB-INF/*
    + src/main/resources/META-INF/cocoon/spring/servlet-service.xml
            * that binds the block to url 'block1'

+ block2
    + pom.xml
            * declaring a dependency on the block1
    + src/main/resources/COB-INF/*
    + src/main/resources/META-INF/cocoon/spring/servlet-service.xml
            * that binds the block to url 'block2'
            * and connects to the previous block over 'b1'

using the rcl plugin on this last one I get everything to work as expected

http://localhost:8888/block1/, http://localhost:8888/block12/
serviced by the correct sitemap.xmaps etc etc


however, now that I bundle all this up in

+ webapp
    + pom.xml
            * only declaring the dependency to block2
              (assuming transitivity will work to block1)
    + all the rest out of the box



and doing
mvn package jetty:run

I get http://localhost:8888/block1/ and http://localhost:8888/block2/ 
both triggering the block1 sitemap!


anybody a clue where I should be looking?

regards
-marc=
PS: while searching I happened across: 
http://cocoon.zones.apache.org/daisy/cdocs/g1/g1/g5/1263.html
this looks like it's not completely up to date, or is it?

Re: 2.2 deploying as webapp

Posted by Reinhard Poetz <re...@apache.org>.
Marc Portier wrote:
> Reinhard Poetz wrote:
>> Marc Portier wrote:
>>
>>> I get http://localhost:8888/block1/ and http://localhost:8888/block2/ 
>>> both triggering the block1 sitemap!
>>>
>>>
>>> anybody a clue where I should be looking?
>>
>> If it's not a bug the only reason could be that you copied your 
>> servlet-service configuration from block1 to block2 and forgot to 
>> correct the blockcontext path.
>>
> 
> aargh, exactly that!
> 
> hm, this almost sounds like you had that happen as well once in a while :-)

for that reason I always use the archetype

> hm, this kinda puts on the table why the blocks themselves are stating 
> this (and the mount-path)
> 
> what is this block-context-path anyway? sounds like a directory where 
> the COB-INF is unpacked

yep

>, couldn't that be implied from the block's 
> jar-name?

We already put the block name as property into the MANIFEST.MF of a block (see 
the jar plugin which is configured in the block's pom). The problem is that we 
have to find a way to tell the servlet service bean, where all the resources 
that belong to the servlet service, can be found.

> anyway, at least some advice or naming conventions should be made 
> probably? (same for the bean/@ids in fact)

the configuration of a servlet service consists of at least three properties:

  - bean name
  - mount path
  - block context path

For now I don't have an idea how we could introduce a naming convention here, 
which doesn't confuse more than it helps.

-- 
Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------

Re: 2.2 deploying as webapp

Posted by Marc Portier <mp...@outerthought.org>.

Reinhard Poetz wrote:
> Marc Portier wrote:
> 
>> I get http://localhost:8888/block1/ and http://localhost:8888/block2/ 
>> both triggering the block1 sitemap!
>>
>>
>> anybody a clue where I should be looking?
> 
> If it's not a bug the only reason could be that you copied your 
> servlet-service configuration from block1 to block2 and forgot to 
> correct the blockcontext path.
> 

aargh, exactly that!

hm, this almost sounds like you had that happen as well once in a while :-)

hm, this kinda puts on the table why the blocks themselves are stating 
this (and the mount-path)

what is this block-context-path anyway? sounds like a directory where 
the COB-INF is unpacked, couldn't that be implied from the block's jar-name?

anyway, at least some advice or naming conventions should be made 
probably? (same for the bean/@ids in fact)


anyway thx for helping...
-marc=


>> regards
>> -marc=
>> PS: while searching I happened across: 
>> http://cocoon.zones.apache.org/daisy/cdocs/g1/g1/g5/1263.html
>> this looks like it's not completely up to date, or is it?
> 
> right, fixed now.
>

Re: 2.2 deploying as webapp

Posted by Reinhard Poetz <re...@apache.org>.
Marc Portier wrote:

> I get http://localhost:8888/block1/ and http://localhost:8888/block2/ 
> both triggering the block1 sitemap!
> 
> 
> anybody a clue where I should be looking?

If it's not a bug the only reason could be that you copied your servlet-service 
configuration from block1 to block2 and forgot to correct the blockcontext path.

> regards
> -marc=
> PS: while searching I happened across: 
> http://cocoon.zones.apache.org/daisy/cdocs/g1/g1/g5/1263.html
> this looks like it's not completely up to date, or is it?

right, fixed now.

-- 
Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------