cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: C2.2 Migration plan from 2.1
Date Sun, 13 Apr 2008 16:08:48 GMT
Kamal pisze:
>>> We currently have two version of Cocoon running on the same 
>>> application server (2.1.7 and 2.1.9). It is far from perfect, but it 
>>> works. Not too sure about the ramifications of the 2.2 and 2.1.x.
>> I fear that differences in libraries used by C2.1 and C2.2 can be 
>> quite serious but as I said someone need to check it.
> Unfortunately, we would need C2.1 and C2.2 on a server (we are 
> maintaining legacy functionality - lenya - that was in 2.1.7). If we 
> ignore my intial comment about having the two applications servers 
> communicate, would there be any conflict? We are using JBoss as the 
> application server.

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
standard HTTP for communication.

It depends on your app if performance overhead will increase seriously.

>> Standard question: What features of XSP do you need the most? Yep, I'm 
>> thinking about suggesting you some smooth migration from XSP to 
>> something that will satisfy your needs.
> There are two main usages, generation of CInclude tags and SQL queries. 
> I guess the first one could be easily done with Flowscript/JXtemplates 
> (though it would be a bit of work), with the flowscript generating a 
> list of files to include and the JXtemplate generating this list. BTW, I 
> like JXTemplates, but are there any plans to support other view 
> frameworks (JSP, Velocity, etc). 

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
to have a strong need for that.

> I am thinking the SQL queries could be 
> maintained by the SQL transformer (I never really looked at it). Some of 
> the SQL in question is rather curly, and we would like to shift some of 
> it into the Java code itself (I have a feeling that it would help with 
> preview functionality that we need in our application), but I think in 
> doing so, I would loose the ability to hot fix those queries.

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
"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.

> Would this work with JAR files as well? That is, if I had a JAR file, 
> would I be able to put it in the class directory and it would just pick 
> up the new file?

No, RCL is intended to be used with unpacked classes. If you want to have class reloading
classes from some JAR file then you should unpack the JAR and configure RCL so it knows where
classes are stored.

You can configure RCL to monitor many different locations for class reloading.

> 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 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?

> Also, I cannot fine a listing of what properties are available to me and 
> what they do anywhere on the website. Does such a page exist?

The problem is that there is no predefined list of properties that you can use. I mean here
becaue of how bean property overriding works (see [1]) you have almost infinite number of
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.

> 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.
> 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?


Grzegorz Kossakowski

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

View raw message