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.
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). 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.
I was going to announce it officially once C2.2 final release
announce is being prepared but I can give you a quick overview of
the steps of proposed service:
1. The person willing to migrate her app from C2.1 to C2.2 does some
basic research on how C2.2 works and how /new/ applications should
be created. We have some tutorials explaining this.
Where are these tutorials? Are you talking about the setting up of
blocks?
Yep. That's not much but give you some starting point and should
clearly suggest that C2.2 is all about blocks. Your application should
basically consists of a few blocks of the structure the same as
standard Cocoon blocks has.
The most urgent issue is documentation of SSF that plays very
important role in C2.2. We have some bits already but documentation
process stopped because all of us are busy with COCOON-2176 issues
which is our major problem at the moment. Once we are done with it I'm
going to continue my work on SSF docs.
au.com.tt.ccm.cocoon-ccm.service%classes-dir=./target/classes
There is no ./target/classes directory.
There is. You will find it in myBlock directory once you execute:
mvn jetty:run (or at least mvn cocoon:prepare)
It points to the directory where mvn compiles classes.
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?
Also, I found out that if I add this property:
au.com.tt.ccm.cocoon-ccm.service/contextPath
you can put your sitemap file outside of a jar (at least when using
Jetty). But I don't know the implications of this, or even what code
to look at to find out.
It uses Spring property overriding[2] functionality of Spring
Configurator. Basically it overrides default value of contextPath
property of bean named au.com.tt.ccm.cocoon-ccm.service. You can find
configuration of this bean in
myBlock/src/main/resources/META-INF/cocoon/spring/block-servlet-service.xml
It's totally safe to use your own value pointing to some directory in
file system here. Basically, contextPath points to the base directory
for your block and it can be anywhere you want.
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 :(.
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.
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?
I see your arguments here. Your requirements could be perfectly met by
OSGi integration we planned for Cocoon for years now. Then you could
install your blocks without restarting the server and only one
application would get affected by redeployment. However, OSGi
integration is not an easy topic and we decided to leave it for
upcomming releases.
As you already figure it out you could point SitemapServlets to
external locations for block content overrding contextPath. I think
it's quite sane options and you should get what you are looking for.
There would be one issue remaining: each time you add a new sitemap,
you need a new SitemapServlet configuration that will handle this new
sitemap. That means you would still need restart your servlet
container if any new sitemap is being created. I think it's not that a
big problem, right?
Even everything should work fine with such setup I would suggest to
you to stay as close as possible to standards that Cocoon is now
trying to establish. I'm talking here about directory layout and
blocks. If you want block contents to be outside the JAR it's fine but
keep directory structure standard so once we get OSGi running in
Cocoon your migration process will be much, much smoother.
I hope I helped you a little.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
