Hugh Sparks pisze:
Yes. I understand. But I would expect the class SitemapServlet to know
about
the directory where the sitemap is located in the webapp. Or at least
have some
default directory relative to the servlet container.
SitemapServlet in 2.2 is rather simple and has been simplified on the purpose. It's our goal to
simplify things even if these simplifications sometimes can make problems like this.
To say it in short: SitemapServlet in 2.2 is very dumb and does not know about anything else than
what you pass to it using context-path.
To clarify what I'm trying to do: I'm adding a sitemap and content
directly to a
webapp created using the webapp archetype. I then add a SitemapServlet
bean to the spring configuration file in the WEB-INF. It is a strategy
for migrating
a large cocoon 1.x site to cocoon 2.2. This has worked for about one
year, but I
keep testing with recent checkouts from the trunk and it stopped working
in the
last week or two.
Have you really meant here Cocoon 1.x? Or maybe Cocoon 2.1?
This is due to our refactorings of block handling in trunk. Actually what it's called Cocoon Core
2.2.1 will be probably 2.3.0 exactly due to fact that there are some incompatibilities introduces.
At least I would like to call it 2.3.0.
When it comes to your strategy I would suggest you to revisit it. I'm just migrating some rather big
application from 2.1 to 2.2 and decided to create one block that will contain the whole application.
This is at least a starting point to get things running.
Is there anything that stops you from using one block for migration? I guess your life should be
much easier in that case.
Well, it used to be "/", but now using the file protocol as you suggest
make it happier:
On Windows, the file protocol takes you to the top of the C drive:
org.apache.excalibur.source.SourceNotFoundException:
file:///C:/sitemap.xmap doesn't exist.
I also tried "blockcontext://" with no block name:
org.apache.avalon.framework.configuration.ConfigurationException:
Cannot resolve blockcontext:/sitemap.xmap
If you don't have a block then blockcontext is not going to work, that's rather
obvious.
Using the absolute path to the target sitemap directory works:
context-path=
"file:///C:/Documents and Settings/Administrator/My Documents/
Projects/Cocoon/Experiments/Test/target/cocoon22-1.0/"
But that is absurd. The context-path would have to be changed and
the webapp rebuilt whenever it is deployed to a different directory.
Yes, I agree. That's why we have this blockcontext: protocol that holds the logic of resolving the
absolute path at the runtime. Still it needs a block to resolve that path.
Is there some parameteter that could be used that would resolve
to the right place when the servlet starts? For example:
context-path="file:/{$some.spring.thing}/"
In the configuration for the maven-jetty-plugin, there are elements
for webAppSourceDirectory and contextPath. Shouldn't these settings
have some effect on where the context-path for the SitemapServlet looks
when it is a relative path? (Forgive me if this makes no sense. I'm still
trying to figure out how jetty and spring interact.)
To be honest, I have no idea if something like this would be possible. Probably with some effort -
yes but still I fail to see why do you want to fight with all this stuff when using one block seems
to be much easier.
As I mentioned before, this is a very recent change.Using "/" in
cocoon 2.2.0 and all previous snapshots made the context-path
point to the directory that contains the sitemap. This seems like
the right behavior to me.
The logic that previously handled this was quite complicated and maybe some relict from 2.1-times
handled this.
The situation we have now looks to be correct even if it breaks your way of usage. I wasn't even
aware of the fact that "/" could work in 2.2.0. That was something not planned, definitively.
With 2.2.1, it seems there is no way to set the servlet context to the
directory that contains the sitemap unless blocks are used. This seems
to be a needless restriction.
Depends on a view-point. I personally think that block usage in 2.2 is simple just a must and I
don't have enough time (and will) to support any other kind of using Cocoon Core 2.2.
Just look at this from another side: I as a Cocoon developer deal with blocks all the time and for
me it would be very difficult to set up any testing environment for blockless applications. As a
consequence of that fact, you are likely to discover nasty problems when you try to omit blocks.
You may convince us that we need to support blockless style of using 2.2 by pointing out some
serious limitation that block architecture introduces. At this moment, I fail to see any.
Perhaps this change in cocoon 2.2.1 should count as a bug?
I would very much like to convince someone to put this back
the way it was. But I suppose there must have been some motivation
other than making it impossible to use cocoon without adding
content to a new block.
Yep, the motivation was to refactor complicated logic. Now things are much more simple thus easier
to maintain.
If this change was not an accident, Maybe there should be a
new protocol, "servletcontext:/" to allow context-path to be set to a
location relative to the servlet deployment directory?
I could possibly give and advice how to implement such thing but I feel obligated to warn you that
won't be included into C2.2 itself.
I browsed though the cocoon-core svn logs, but I can't find the change
that introduced this behavior. I don't see any changes to SitemapServlet
or files in the surrounding directory that seem recent enough.
As I said, SitemapServlet is unaware of these things and has been for a long time. It's a Servlet
Service Framework that used to handle this stuff.
I am tempted to cross-post this issue to cocoon-dev. Is that appropriate?
I think that before we start discussion about modifying Cocoon itself it's better to stay here. I
guess many Cocoon users are interested in discussion how to migrate existing apps to C2.2.
As a side note: I guess it would be nice if I could post some of my notes and thoughts that I gather
now dealing with migration from 2.1 to 2.2. I'll see what can be done...
--
Best regards,
Grzegorz Kossakowski
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
