Re: Input modules samples broken in trunk

2007-01-18 Thread Mark Lundquist


On Jan 4, 2007, at 4:51 PM, Mark Lundquist wrote:


1) For the jxpath modules, an exception is thrown:

	org.apache.commons.jxpath.JXPathException: Cannot access  
property: 
rg.apache.cocoon.environment.wrapper.RequestWrapper.attributeNames; No  
read method


I thought I saw an error (obviously slightly different) on at least one  
other jxpath input module, but now I can't reproduce it... maybe I was  
goofed before.  But anyway, the RequestModule does get the above  
exception for the 'attributeNames' path, but other properties can be  
accessed with no problem.  If I comment this out of the sitemap:


	  value="{request:attributeNames}"/>


...then the sample works.

I'm not sure what causes the problem here; RequestWrapper implements  
Request, which contains the getAttributeNames() signature.  Any ideas?


cheers,
—ml—



Re: Input modules samples broken in trunk

2007-01-18 Thread Mark Lundquist


On Jan 4, 2007, at 4:51 PM, Mark Lundquist wrote:


The modules samples are broken...

1) For the jxpath modules, an exception is thrown:

	org.apache.commons.jxpath.JXPathException: Cannot access  
property: 
rg.apache.cocoon.environment.wrapper.RequestWrapper.attributeNames; No  
read method


2) For the rest, the "Accessor/Value" table displays as empty.


Well, I finally got the chance to come back to this...

Problem #2 involves this line in  
cocoon-core-additional-sample/.../modules/properties.xml:


  

cocoon.parameters is of class  
o.a.c.environment.TemplateObjectModelHelper.ParametersMap.  The class  
itself is protected, but the getNames() method is public.  It turns out  
that if I change the JXT to


  

then the page works correctly.

Is this a JExL bug/features, and/or a known incompatibility in the new  
JXTG, or is it something that can be fixed?


—ml—



RAD (was Re: Input modules samples broken in trunk)

2007-01-11 Thread Mark Lundquist


On Jan 11, 2007, at 8:35 AM, Daniel Fagerstrom wrote:

I described how to use Eclipse as that is what I have experience with. 
But if you can ensure that the Maven Jetty plugin gets the blocks as 
directories rather than jars at its classpath, that should work as 
well.


That was going to be my next question... :-)

One of my clients has other people who work on Cocoon web sites that I 
create.  They do content updates, and one of them can do some CSS and a 
few elementary things  in XSLT to tweak the site layout/styling.  But 
these are pretty much non-technical peeps; for them Eclipse is a 
chewing gum [1].  And they don't know how to build these webapps on 
their own computers and run them locally, that's just beyond them.  
They work by remotely editing files in place in a development instance 
of the application running up on a server.  Then, one of them I've 
taught how to do svn commits from dev and then update into the 
production instance (sometimes it gets botched and I have to go clean 
up a subversion mess by hand, but 95% of the time this works OK).


So to move these apps forward to 2.2, I will need a no-brainer way for 
them to make live changes on the development instance in a server 
environment.  But I think now that I understand all about what we're 
discussing here [2], I will probably end up keeping root-level 
application resources directly in the webapp module instead of 
servletizing them in a separate block.  I think that will take care of 
most of our issues.


[1] - http://www.wrigley.com/wrigley/products/products_eclipse.asp
[2] - sorry, no reference for discussion thread "every new webapp a 
block?" — I can't find it on marc.theaimsgroup.com for some reason?


thx,
—ml—



Re: Input modules samples broken in trunk

2007-01-11 Thread Daniel Fagerstrom

Reinhard Poetz skrev:

Mark Lundquist wrote:


On Jan 10, 2007, at 10:15 PM, Reinhard Poetz wrote:


try http://cocoon.zones.apache.org/daisy/cdocs-rcl-plugin/g1/1297.html


OK, so let me make sure I understand...

I want to make changes to sitemap, XLST, XML sources etc. within a 
block and have those changes take effect immediately in the running 
Cocoon.  IIUC, there are two ways to do this:


1) By using the reloading classloader;

2) By using the Eclipse Jetty Launcher.

Is that right?


Definitly with 1). Haven't tried 2) myself but it works for Daniel. So 
yes, you're right.


To make resources available directly to a webapp you just need to make 
sure that the block directory with the resources in is available at the 
class path as a directory (file://) rather than the block 
jar. Then the DeployUtil in the cocoon-spring-configurator takes care of 
the rest. See 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=116326232408386&w=2 for 
how it works.


I described how to use Eclipse as that is what I have experience with. 
But if you can ensure that the Maven Jetty plugin gets the blocks as 
directories rather than jars at its classpath, that should work as well.


/Daniel



Re: RCL difficulties (was Re: Input modules samples broken in trunk)

2007-01-11 Thread Mark Lundquist


On Jan 11, 2007, at 7:56 AM, Reinhard Poetz wrote:


The RCL only works for blocks ATM.


Ah!  OK.

So I'll just servletize the samples app and then I should be able to 
see the RCL in action.


thx a lot,
—ml—



Re: RCL difficulties (was Re: Input modules samples broken in trunk)

2007-01-11 Thread Reinhard Poetz

Mark Lundquist wrote:

[...]
I know how to do it the block way, that's not the issue... I'm just 
trying to quick-'n'-dirty configure my own local build of cocoon-webapp 
to use the RCL, and it doesn't appear to be working right — which is 
probably All My Fault somewhere, and I'm trying to figure out where I 
went wrong :-).


target/rcl/webapp/ should (I presume) end up containing everything that 
target/webapp does, right? My target/rcl/webapp contains only the 
WEB-INF, but nothing else.


Any ideas?


The RCL only works for blocks ATM.

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


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

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



Re: RCL difficulties (was Re: Input modules samples broken in trunk)

2007-01-11 Thread Mark Lundquist


On Jan 10, 2007, at 10:20 PM, Reinhard Poetz wrote:

I just tried setting up the RCL per 
http://cocoon.zones.apache.org/daisy/cdocs/g1/g4/g1/1297.html; is 
that the solution I'm after?
I added the rcl.properties to cocoon-core-addition-sample/pom.xml and 
tweaked the cocoon-webapp/pom.xml, ran "mvn rcl:webapp" there...  but 
when I request the webapp site root in my browser, I get:
Looking at target/rcl/webapp, I see that there's a WEB-INF/ there, 
but that's all the sitemap.xmap etc., are all missing.



After running rcl:webapp, have you tried to start the created webapp?


Yes, I'm sorry, I see where in my original email I left a place to 
paste in the reply from Cocoon, but then I forget to do it.  Here's 
what I see in the browser:



HTTP ERROR: 503

SERVICE_UNAVAILABLE
RequestURI=/

Powered by jetty://


There is no need for a global sitemap.xmap anymore. You mount one of 
your blocks to the root of your webapp ("/").


No, no... this is core/cocoon-webapp where I have done this.  I did it 
there, in situ, just temporarily while I (hopefully) test some changes 
in trunk. cocoon-webapp does have "global" (self-contained root-level) 
resources (sitemap.xmap, welcome.xml, stylesheets/ etc.).


I know how to do it the block way, that's not the issue... I'm just 
trying to quick-'n'-dirty configure my own local build of cocoon-webapp 
to use the RCL, and it doesn't appear to be working right — which is 
probably All My Fault somewhere, and I'm trying to figure out where I 
went wrong :-).


target/rcl/webapp/ should (I presume) end up containing everything that 
target/webapp does, right?  My target/rcl/webapp contains only the 
WEB-INF, but nothing else.


Any ideas?

—ml—



Re: Input modules samples broken in trunk

2007-01-11 Thread Reinhard Poetz

Mark Lundquist wrote:


On Jan 10, 2007, at 10:15 PM, Reinhard Poetz wrote:


try http://cocoon.zones.apache.org/daisy/cdocs-rcl-plugin/g1/1297.html


OK, so let me make sure I understand...

I want to make changes to sitemap, XLST, XML sources etc. within a block 
and have those changes take effect immediately in the running Cocoon.  
IIUC, there are two ways to do this:


1) By using the reloading classloader;

2) By using the Eclipse Jetty Launcher.

Is that right?


Definitly with 1). Haven't tried 2) myself but it works for Daniel. So yes, 
you're right.


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


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

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



Re: Input modules samples broken in trunk

2007-01-11 Thread Mark Lundquist


On Jan 10, 2007, at 10:15 PM, Reinhard Poetz wrote:


try http://cocoon.zones.apache.org/daisy/cdocs-rcl-plugin/g1/1297.html


OK, so let me make sure I understand...

I want to make changes to sitemap, XLST, XML sources etc. within a 
block and have those changes take effect immediately in the running 
Cocoon.  IIUC, there are two ways to do this:


1) By using the reloading classloader;

2) By using the Eclipse Jetty Launcher.

Is that right?

—ml—



Re: RCL difficulties (was Re: Input modules samples broken in trunk)

2007-01-11 Thread Carsten Ziegeler
Daniel Fagerstrom wrote:

> It is also important to have -Dorg.apache.cocoon.mode=develop as 
> argument to the Jetty launcher, otherwise the tree processor will not 
> reload the resources when they change.
> 
The correct name for the mode is "dev", so you have to specify
"-Dorg.apache.cocoon.mode=dev"

Carsten

-- 
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/


Re: RCL difficulties (was Re: Input modules samples broken in trunk)

2007-01-10 Thread Reinhard Poetz

Mark Lundquist wrote:


On Jan 10, 2007, at 2:04 PM, Mark Lundquist wrote:



On Jan 4, 2007, at 4:51 PM, Mark Lundquist wrote:


[..snip]

4) If I want to debug this, I'm going to fiddle around with resources 
in the cocoon-core-additional-sample block (like the sitemap, JXTs 
etc.).  How do I set things up so that those changes will take effect 
on the fly, without having to do some mvn install thing and restart 
Jetty?


Any clues?
—ml—


I just tried setting up the RCL per 
http://cocoon.zones.apache.org/daisy/cdocs/g1/g4/g1/1297.html; is that 
the solution I'm after?


I added the rcl.properties to cocoon-core-addition-sample/pom.xml and 
tweaked the cocoon-webapp/pom.xml, ran "mvn rcl:webapp" there...  but 
when I request the webapp site root in my browser, I get:



Looking at target/rcl/webapp, I see that there's a WEB-INF/ there, but 
that's all the sitemap.xmap etc., are all missing.


There is no need for a global sitemap.xmap anymore. You mount one of your blocks 
to the root of your webapp ("/").


After running rcl:webapp, have you tried to start the created webapp?

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


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

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



Re: Input modules samples broken in trunk

2007-01-10 Thread Reinhard Poetz

Mark Lundquist wrote:


On Jan 4, 2007, at 4:51 PM, Mark Lundquist wrote:


[..snip]

4) If I want to debug this, I'm going to fiddle around with resources 
in the cocoon-core-additional-sample block (like the sitemap, JXTs 
etc.).  How do I set things up so that those changes will take effect 
on the fly, without having to do some mvn install thing and restart 
Jetty?


Any clues?


try http://cocoon.zones.apache.org/daisy/cdocs-rcl-plugin/g1/1297.html

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


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

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



Re: RCL difficulties (was Re: Input modules samples broken in trunk)

2007-01-10 Thread Mark Lundquist


On Jan 10, 2007, at 2:50 PM, Daniel Fagerstrom wrote:

Don't know how rcl work, it is mainly for recompiling Java classes on 
the fly IIUC.


Yes... what got me thinking RCL was this thread: 
http://marc.theaimsgroup.com/?t=11683427565&r=1&w=2


For resources it works as you want OOTB, if you run from Eclipse. What 
is important is that you run "mvn eclipse:eclipse" from top level. If 
you do that (and import the needed projectts into Eclipse), you can 
just run the Eclipse Jetty plugin and change the resources in the 
blocks and get result immediately. If you instead run eclipse:eclipse 
from within a project, you will instead get the installed jars in your 
Maven repository as dependencies and the you have to rebuild and 
restart.


OK, thanks... I'll try it.

It is also important to have -Dorg.apache.cocoon.mode=develop as 
argument to the Jetty launcher, otherwise the tree processor will not 
reload the resources when they change.


JOOC, where's that implmented?

Anyway... for whoever's interested, it seems like setting up 
cocoon-webapp for the RCL did not work as advertised for me, maybe I 
was doing something wrong?  In any case I'll be moving on to try my 
luck with the Eclipse Jetty plugin.


Thx a lot,
—ml—



Re: RCL difficulties (was Re: Input modules samples broken in trunk)

2007-01-10 Thread Daniel Fagerstrom

Mark Lundquist skrev:


On Jan 10, 2007, at 2:04 PM, Mark Lundquist wrote:



On Jan 4, 2007, at 4:51 PM, Mark Lundquist wrote:


[..snip]

4) If I want to debug this, I'm going to fiddle around with resources 
in the cocoon-core-additional-sample block (like the sitemap, JXTs 
etc.).  How do I set things up so that those changes will take effect 
on the fly, without having to do some mvn install thing and restart 
Jetty?


Any clues?
—ml—


I just tried setting up the RCL per 
http://cocoon.zones.apache.org/daisy/cdocs/g1/g4/g1/1297.html; is that 
the solution I'm after?


I added the rcl.properties to cocoon-core-addition-sample/pom.xml and 
tweaked the cocoon-webapp/pom.xml, ran "mvn rcl:webapp" there...  but 
when I request the webapp site root in my browser, I get:



Looking at target/rcl/webapp, I see that there's a WEB-INF/ there, but 
that's all the sitemap.xmap etc., are all missing.


Any ideas?


Don't know how rcl work, it is mainly for recompiling Java classes on 
the fly IIUC. For resources it works as you want OOTB, if you run from 
Eclipse. What is important is that you run "mvn eclipse:eclipse" from 
top level. If you do that (and import the needed projectts into 
Eclipse), you can just run the Eclipse Jetty plugin and change the 
resources in the blocks and get result immediately. If you instead run 
eclipse:eclipse from within a project, you will instead get the 
installed jars in your Maven repository as dependencies and the you have 
to rebuild and restart.


It is also important to have -Dorg.apache.cocoon.mode=develop as 
argument to the Jetty launcher, otherwise the tree processor will not 
reload the resources when they change.


/Daniel


RCL difficulties (was Re: Input modules samples broken in trunk)

2007-01-10 Thread Mark Lundquist


On Jan 10, 2007, at 2:04 PM, Mark Lundquist wrote:



On Jan 4, 2007, at 4:51 PM, Mark Lundquist wrote:


[..snip]

4) If I want to debug this, I'm going to fiddle around with resources 
in the cocoon-core-additional-sample block (like the sitemap, JXTs 
etc.).  How do I set things up so that those changes will take effect 
on the fly, without having to do some mvn install thing and restart 
Jetty?


Any clues?
—ml—


I just tried setting up the RCL per 
http://cocoon.zones.apache.org/daisy/cdocs/g1/g4/g1/1297.html; is that 
the solution I'm after?


I added the rcl.properties to cocoon-core-addition-sample/pom.xml and 
tweaked the cocoon-webapp/pom.xml, ran "mvn rcl:webapp" there...  but 
when I request the webapp site root in my browser, I get:



Looking at target/rcl/webapp, I see that there's a WEB-INF/ there, but 
that's all the sitemap.xmap etc., are all missing.


Any ideas?
—ml—



Re: Input modules samples broken in trunk

2007-01-10 Thread Mark Lundquist


On Jan 4, 2007, at 4:51 PM, Mark Lundquist wrote:


[..snip]

4) If I want to debug this, I'm going to fiddle around with resources 
in the cocoon-core-additional-sample block (like the sitemap, JXTs 
etc.).  How do I set things up so that those changes will take effect 
on the fly, without having to do some mvn install thing and restart 
Jetty?


Any clues?
—ml—