Thanks Vadim and Grzegorz. I hope my questions haven't been too annoying.
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.
Thanks. That makes me happier.
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.
That's cool. I was just curious. I think the only need would be that
people are used to Velocity or JSP and would prefer not having to learn
another view technology. Not me, though. I am probably one of the few
people on this mailing list who has had little to no experience with
Velocity or JSP.
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.
I take it, using class loading in production is not allowed/recommended?
I would prefer not having to redeploy all of Cocoon for just one client.
Also, we have a situation where one client may have version X and
another client has version Y, and X and Y are incompatible. If class
reloading is available in a production environment (ie in a bundled
war), without too much of an overhead, that would be good.
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 will give this a go.
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?
It seems to me there are a number of approaches for placing your sitemap
in an arbitary location on the file system:
1. You could use a mount in the block, such as this:
<map:match pattern="*/**">
<map:mount check-reload="true" reload-method="synchron"
src="file:///test/{1}/sitemap.xmap" uri-prefix="" />
</map:match>
This what I meant about sitemap redirections.
2. You could use the RCL method and specify the property (though I
haven't got this to work in the packaged war, I will have a look at it
later)
3. You could use Cocoon in classic mode and use the xconf
4. You could use the block servlet bean definition method:
<bean name="org.apache.cocoon-welcome.block"
class="org.apache.cocoon.sitemap.SitemapServlet">
<servlet:init-params>
<entry key="sitemap-path" value="file:///path/to/sitemap.xmap"/>
</servlet:init-params>
<servlet:context mount-path="/"
context-path="blockcontext:/cocoon-welcome/">
<servlet:connections>
<entry key="style"
value-ref="org.apache.cocoon.samples.style.default.servlet"/>
</servlet:connections>
</servlet:context>
</bean>
So which would be the best way?
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.
That's what I was afraid of.
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.
Maybe my OSGi question didn't make any sense. I was trying to work out
if OSGi allows us to "patch" live cocoon instances. That is, if I have
functionality in arbitary jar files on the file system, instead of
redeploying the whole Cocoon war, would it be possible to redeploy the
singular jar files that may (for example) have a custom generator.
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?
The CForms tutorial says to put the files in the external directory [1].
I don't know if this is a standard or a suggestion.
Just wondering when we are likely to see the XSP block made available
outside of the trunk. I don't mind missing out SOAP capability (not
using it), is there a maven dependency I can use to get XSPs now?
[1] http://cocoon.apache.org/2.2/blocks/forms/1.0/478_1_1.html
--
Kamal Bhatt
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
