cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kamal Bhatt <>
Subject Re: C2.2 Migration plan from 2.1
Date Mon, 14 Apr 2008 00:05:44 GMT
Thanks Vadim and Grzegorz. I hope my questions haven't been too annoying.
> If you run C2.2 in one JVM instance and C2.1 in another there is no 
> trouble here. However, if you want to communicate between 2.1 and 2.2 
> you will need to serialize and parse everything and use standard HTTP 
> for communication.
> It depends on your app if performance overhead will increase seriously.
Thanks. That makes me happier.

> Yes, this should be easily migrated to Flowscript/JXTemplates combo. 
> As for any template frameworks: I don't think so we are going to 
> support anything else than JXTemplate anytime soon. We would need to 
> have a strong need for that.
That's cool. I was just curious. I think the only need would be that 
people are used to Velocity or JSP and would prefer not having to learn 
another view technology. Not me, though. I am probably one of the few 
people on this mailing list who has had little to no experience with 
Velocity or JSP.
> It depends on what these SQL queries are used for. If it's simple 
> pulling from database then SQLTransformer is fine.
> Migrating SQL to Java code is a good idea as well but you are right 
> that you will probably need to restart your web server if you need to 
> update them. The question is whether it's a good idea to "hot-fix" SQL 
> queries when production server is running. Not sure about the answer.
> For development, you would use RCL for class realoding so there is no 
> issue here.
I take it, using class loading in production is not allowed/recommended? 
I would prefer not having to redeploy all of Cocoon for just one client. 
Also, we have a situation where one client may have version X and 
another client has version Y, and X and Y are incompatible. If class 
reloading is available in a production environment (ie in a bundled 
war), without too much of an overhead, that would be good.

>> This worked why I ran jetty:run on the block, but once I bundled the 
>> block into a Cocoon webapp and I ran that packaged War (in Jetty), 
>> the override was lost :(.
> How exactly you have configured the override? Where you put the 
> properties file? It should be put in 
> myBlock/src/main/resources/META-INF/cocoon/spring. Then you should 
> execute:
>   mvn clean install (in myBlock)
> and generate your WAR. It should work just fine then.
I will give this a go.
>> I thought we could achieve the same sort of thing with sitemap 
>> redirects, but I never got an answer if that was a good idea or not.
> Not sure what you mean here. Could you elaborate?

It seems to me there are a number of approaches for placing your sitemap 
in an arbitary location on the file system:

1. You could use a mount in the block, such as this:
   <map:match pattern="*/**">
      <map:mount check-reload="true" reload-method="synchron" 
src="file:///test/{1}/sitemap.xmap" uri-prefix="" />
This what I meant about sitemap redirections.
2. You could use the RCL method and specify the property (though I 
haven't got this to work in the packaged war, I will have a look at it 
3. You could use Cocoon in classic mode and use the xconf
4. You could use the block servlet bean definition method:

  <bean name="org.apache.cocoon-welcome.block" 
      <entry key="sitemap-path" value="file:///path/to/sitemap.xmap"/>
    <servlet:context mount-path="/" 
        <entry key="style" 

So which would be the best way?
> The problem is that there is no predefined list of properties that you 
> can use. I mean here that becaue of how bean property overriding works 
> (see [1]) you have almost infinite number of properties for your own 
> use if you want to tweak any of bean configuration.
> However, if you need a list of somehow "standard" properties then I 
> think the only solution is to scan Cocoon jars for properties files 
> (there are not so many) and see what properties are defined there.
That's what I was afraid of.
>> Just to confirm OSGi integration would allow me to hotfix JARs and 
>> java classes right. I don't mind staying as close as possible to the 
>> Cocoon standard, but I see nothing in regards to documentation as to 
>> what that standard is.
Maybe my OSGi question didn't make any sense. I was trying to work out 
if OSGi allows us to "patch" live cocoon instances. That is, if I have 
functionality in arbitary jar files on the file system, instead of 
redeploying the whole Cocoon war, would it be possible to redeploy the 
singular jar files that may (for example) have a custom generator.
>> For example, are you suggesting that I should have a COB-INF 
>> directory on my filesystem? What are the internal/external resources 
>> and why do I have to put my JX files into them for CForms, but not 
>> for everything else.
> Yes I was thinking about COB-INF directory and basic block layout 
> documented here[2]. I'm not sure what you meant in the last sentence. 
> Could you explain it little bit more?

The CForms tutorial says to put the files in the external directory [1]. 
I don't know if this is a standard or a suggestion.

Just wondering when we are likely to see the XSP block made available 
outside of the trunk. I don't mind missing out SOAP capability (not 
using it), is there a maven dependency I can use to get XSPs now?


Kamal Bhatt

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message