Grzegorz Kossakowski wrote:
I see your arguments. In a fact, the ability of sitemap (and other
resources) reloading mechanism is not bound to map:mount functionality
so I don't see much a problem here.
Also, we have constructed much of a our build processes around this
idea that every client will have a common set of files (sitemaps,
flowscripts, XSPs, etc) and aside from some automated tweaking we do
to the sitemap (for things like file locations and database pools)
these files remain the same across clients.
Just out of curiosity: have you developed your own build process becuase:
a) Cocoon failed to provide flexible enough default development
skeleton that you could use
or rather
b) your requirements were so specific that you would have to develop
it anyway?
I ask because one of the identified weaknesses of C2.1 was poor
support for real development process. There was nothing standard and
flexible enough that anyone could take and only customize to her needs
but still retaining base in common. One of the goals of C2.2 is to
change that hence switch to Maven 2, archetypes and real blocks
implementation.
Bit of both. As I may have said previously, we have a set of files
(XSPs, XSLTs, sitemaps, etc) that are common to all our clients, we then
overlay client specific files. The client specific files may override
the base set of files (and do). I don't see the process you are talking
about as facilitating this functionality. Regardless, we barely have
enough time to migrate to 2.2, so I cannot imagine changing the build
process as well.
The map:mount has given us a way to nicely modularise and customise
our application.
I think that blocks+SSF give you even more flexibility in this
regards. Actually, there are both invented exactly for achieving nice
modularization of Cocoon-based applications.
In actual fact, I was leaning towards this option as it gave me
something I didn't have in the past - zero Cocoon redeployments for
setting up new clients.
If you tell SitemapServlet (by chaning context-path property) to look
for the resources _outside_ the block JAR you are achieving fairly the
same.
Previously, we would have to change mount tables and datasources to
add a new clients, but thanks to Hibernate's configuration options
(yes, I have finally decided to bit the bullet and use Hibernate :) )
and some mount table trickery I should be able to deploy a new client
with very little overhead.
We imagined (and it's already working) that you just create new
application as a new block, compile and package it into JAR. Then you
just drop the JAR containing block into WEB-INF/lib, restart and you
are done. Your application will get mounted/discovered without any
extra steps. Since block's are meant to be mostly self-contained you
can configure DataSources (as Spring beans) inside block and Cocoon
(along with Spring) will pick up your configuration and will setup
everything as needed.
As you see, deployment of a new application involves only dropping the
JAR and restarting Servlet container. I think there is a little that
could be easier, don't you think?
Actually, what you describe isn't easy in our case. I would prefer
Cocoon in its own environment, but it isn't. It is with a bunch of
significant applications. Deploying Cocoon with all its dependencies is
going to bring down most application servers eventually. This is
something I wish to mitigate.
If SSF allows me to do this (or you can suggest to me a way of
fulfilling my requirements with SSF), I will happily use it,
otherwise, I would actually prefer using potentially deprecated
functionality.
SSF is only about mounting (if we limit ourselves to your situation of
course); resource reloading is out of scope of this framework but
you've been already explained how to achieve the same.
If I open browser tabs (even sometimes two windows) and I run our
CForms application from both, then all sorts of weirdness ensues when
I save. Changes from one window will automagically migrate to the
other window, and it is just a bit of a disaster. The pervading
theory right now, is this is because of Cookie based session
management. Therefore, the solution is to use URL rewriting (right?).
But Form's state is bound to Flowscript continuation that is
identified by has in URL already. AFAIK, continuation's ID are not put
into cookies so nothing could be messed up. I fail to see any reason
for the odd behavior you describe here.
I thought so too, but somehow it caused this sort of behaviour.
Can't you write your own validator?
<sigh> I guess I will have to.
Kamal, but it's damn easy to write a such! :-)
It probably is now that everything is using maven :)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
