Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cocoon.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <48015BEF.5030307@tt.com.au>
Date: Sun, 13 Apr 2008 11:03:43 +1000
From: Kamal <kbhatt@tt.com.au>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: users@cocoon.apache.org
Subject: Re: C2.2 Migration plan from 2.1
References: <4800151A.7000202@tt.com.au> <48009D52.7030007@tuffmail.com>
 <4800BC04.5040806@tt.com.au> <4800FFED.8020006@tuffmail.com>
In-Reply-To: <4800FFED.8020006@tuffmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


>> 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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org