You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Mark Lundquist <ml...@comcast.net> on 2007/01/05 01:51:16 UTC
Input modules samples broken in trunk
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.
3) Do we use JIRA to report stuff like this, or just keep it on the dev
list?
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?
cheers,
—ml—
RAD (was Re: Input modules samples broken in trunk)
Posted by Mark Lundquist <ml...@wrinkledog.com>.
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
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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://<path to block>) 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: Input modules samples broken in trunk
Posted by Reinhard Poetz <re...@apache.org>.
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
Posted by Mark Lundquist <ml...@wrinkledog.com>.
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: Input modules samples broken in trunk
Posted by Reinhard Poetz <re...@apache.org>.
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)
Posted by Mark Lundquist <ml...@wrinkledog.com>.
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)
Posted by Reinhard Poetz <re...@apache.org>.
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)
Posted by Mark Lundquist <ml...@wrinkledog.com>.
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: RCL difficulties (was Re: Input modules samples broken in trunk)
Posted by Reinhard Poetz <re...@apache.org>.
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: RCL difficulties (was Re: Input modules samples broken in trunk)
Posted by Mark Lundquist <ml...@wrinkledog.com>.
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=116834275600005&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: Importing Cocoon projects into Eclipse
Posted by Mark Lundquist <ml...@wrinkledog.com>.
On Jan 11, 2007, at 12:56 AM, Daniel Fagerstrom wrote:
> File -> Import ... -> General -> Existing projects into workspace ->
> Point on a directory that contains the project, it will be scanned for
> Eclipse project descriptors. It takes some time for Eclipse to scan
> all of cocoon-trunk. Choose the projects you want.
D'oh, I've always just used this to import a single project, never
noticed the "scanning" business :-o
> Take a look at properties -> Java build path for the project, to see
> what other projects it depends on and make sure that you import all
> dependencies.
Well, I'm really a little too lazy for that, but if that's what I have
to do... :-/.
Has anyone tried the Eclipse Maven plugin [1] ?
—ml—
[1] http://m2eclipse.codehaus.org/
Re: Importing Cocoon projects into Eclipse
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Mark Lundquist wrote:
>
> On Jan 11, 2007, at 12:35 PM, Grzegorz Kossakowski wrote:
>
>> You have to set up variable 'M2_REPO' in Eclipse (in build classpath
>> settings somewhere) to point on the directory where your Maven's repo
>> sit.
>>
>
> yes... thanks :-)
> —ml—
>
you can also use
mvn eclipse:add-maven-repo -Dworkspace=workspaceLocation
the plugin will take care of M2_REPO variable.
http://maven.apache.org/plugins/maven-eclipse-plugin/add-maven-repo-mojo.html
--
Leszek Gawron CTO at MobileBox Ltd.
Re: Importing Cocoon projects into Eclipse
Posted by Mark Lundquist <ml...@wrinkledog.com>.
On Jan 11, 2007, at 12:35 PM, Grzegorz Kossakowski wrote:
> You have to set up variable 'M2_REPO' in Eclipse (in build classpath
> settings somewhere) to point on the directory where your Maven's repo
> sit.
>
yes... thanks :-)
—ml—
Re: Importing Cocoon projects into Eclipse
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Mark Lundquist napisał(a):
>
> On Jan 11, 2007, at 12:56 AM, Daniel Fagerstrom wrote:
>
> I just imported all the projects in trunk. I get all kinds of errors
> of this sort:
>
> Unbound classpath variable:
> 'M2_REPO/aopalliance/aopalliance/1.0/aopalliance-1.0.jar' in project
> cocoon-core
You have to set up variable 'M2_REPO' in Eclipse (in build classpath
settings somewhere) to point on the directory where your Maven's repo sit.
--
Grzegorz Kossakowski
Re: Importing Cocoon projects into Eclipse
Posted by Mark Lundquist <ml...@wrinkledog.com>.
On Jan 11, 2007, at 12:56 AM, Daniel Fagerstrom wrote:
> File -> Import ... -> General -> Existing projects into workspace ->
> Point on a directory that contains the project, it will be scanned for
> Eclipse project descriptors. It takes some time for Eclipse to scan
> all of cocoon-trunk. Choose the projects you want.
>
> Take a look at properties -> Java build path for the project, to see
> what other projects it depends on and make sure that you import all
> dependencies.
I just imported all the projects in trunk. I get all kinds of errors
of this sort:
Unbound classpath variable:
'M2_REPO/aopalliance/aopalliance/1.0/aopalliance-1.0.jar' in project
cocoon-core
—ml—
Re: Importing Cocoon projects into Eclipse
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Mark Lundquist skrev:
> OK...
>
> On Jan 10, 2007, at 2:50 PM, Daniel Fagerstrom wrote:
>
>> 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),
>
> I ran "mvn eclipse:eclipse"; now which projects do I need to import,
> and what's the easiest way to do it? :-)
>
> (again, my goal here is to run the cocoon-webapp w/ samples using the
> Eclipse Jetty plugin...)
File -> Import ... -> General -> Existing projects into workspace ->
Point on a directory that contains the project, it will be scanned for
Eclipse project descriptors. It takes some time for Eclipse to scan all
of cocoon-trunk. Choose the projects you want.
Take a look at properties -> Java build path for the project, to see
what other projects it depends on and make sure that you import all
dependencies.
/Daniel
Re: Importing Cocoon projects into Eclipse
Posted by Joerg Heinicke <jo...@gmx.de>.
On 11.01.2007 02:28, Mark Lundquist wrote:
> I ran "mvn eclipse:eclipse"; now which projects do I need to import, and
> what's the easiest way to do it? :-)
At least the Eclipse setup works as expected if following the
description in README.txt in Cocoon trunk's root dir.
Jörg
Importing Cocoon projects into Eclipse
Posted by Mark Lundquist <ml...@wrinkledog.com>.
OK...
On Jan 10, 2007, at 2:50 PM, Daniel Fagerstrom wrote:
> 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),
I ran "mvn eclipse:eclipse"; now which projects do I need to import,
and what's the easiest way to do it? :-)
(again, my goal here is to run the cocoon-webapp w/ samples using the
Eclipse Jetty plugin...)
thx,
—ml—
Re: RCL difficulties (was Re: Input modules samples broken in trunk)
Posted by Carsten Ziegeler <cz...@apache.org>.
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)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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)
Posted by Mark Lundquist <ml...@wrinkledog.com>.
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
Posted by Mark Lundquist <ml...@wrinkledog.com>.
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—
Re: Input modules samples broken in trunk
Posted by Mark Lundquist <lu...@gmail.com>.
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:
<jx:forEach var="name" items="${cocoon.parameters.names}">
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
<jx:forEach var="name" items="${cocoon.parameters.getNames()}">
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—
Re: Input modules samples broken in trunk
Posted by Mark Lundquist <lu...@gmail.com>.
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:
<map:parameter name="attributeNames"
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—