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 use
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 need
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 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.
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 for
classes from some JAR file then you should unpack the JAR and configure RCL so it knows where the
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 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.
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?
[1]
http://cocoon.apache.org/subprojects/configuration/1.0/spring-configurator/1.0/1312_1_1.html
[2] http://cocoon.apache.org/2.2/core-modules/core/2.2/1263_1_1.html
--
Grzegorz Kossakowski
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
