Workaround for Safari 3.x problem with redirect after multipart upload
Howdy folks,
I discovered a problem in using a redirect after a multipart upload,
affecting the combination of Cocoon 2.1.10 and Safari 3.x on Mac.
The symptom is a stacktrace from the CocoonServlet saying
MultipartException: Malformed Stream
It is really Safari that is misbehaving. The problem is similar to what is
described here:
http://jira.codehaus.org/browse/GRAILS-1938
Multipart upload from Safari into Cocoon works just fine in the cases we
have tested.
The browser uses POST to submit the multipart data. But after the upload
completes, if
we redirect the browser to GET another URL (e.g. a Thank you for your
upload page),
Safari does something bad. It sends the GET request as instructed, but it
also includes
a header like:
Content type: multipart/form-data; boundary=WebKitFormBoundaryCSofPC
...which Cocoon interprets as indicating a multipart request, regardless of
the
fact that a multipart GET is rather unlikely. Cocoon then expects to see
multipart
data in the request, and it does not, and so Cocoon throws a
MalformedStreamException.
My guess is that this behavior by Safari is a violation of the MIME and/or
HTTP
specs. Safari isn't really sending any multipart data on the redirected
GET, so
it shouldn't send this Content type header. It seems like a bit of
residual state
that is left in Safari after the redirect is causing it to re-send this
Content Type.
Note that I did not observe this same behavior in Safari on WindowsXP - only
in Safari on Mac.
Because one of our Cocoon applications has a significant number of Mac
Safari users, and it occurs to
me that some other browsers may exhibit similar behavior (though I hope
not).
I created a workaround that allows Cocoon to ignore the multipart Content
type
header in situations where it is unlikely that the inbound data is really
multipart.
The cocoon code which controls this behavior (in version 2.1.10) is:
org.apache.cocoon.servlet.multipart.RequestFactory
...specifically, the getServletRequest() method, which decides to process a
request as multipart if the
following condition holds:
if ((contentType != null)
(contentType.toLowerCase().indexOf(multipart/form-data) -1))
I have extended this condition so that it looks like the following, which is
hereby contributed
to the community. If someone wants to use this patch as inspiration for
a real patch in the
cocoon source, that's fine and dandy.
---
if ((contentType != null)
(contentType.toLowerCase().indexOf(multipart/form-data) -1)) {
// It sorta looks like a multipart request, based on the content-type.
// BUT, if it's a GET request, and content-length = 0, then it's
// probably not a valid multipart request. Most multipart requests
// are POSTS (I guess some are PUTS...).More likely, it's a
// redirected GET from Safari.(We could check User-Agent,
too...)
String method = request.getMethod();
int contentLength = request.getContentLength();
String userAgent = request.getHeader(User-Agent);
if ((contentLength = 0) method.equals(GET)) {
String warningMsg = Ignoring Content-Type +
contentType + because
Method= + method + and Content-Length= + contentLength + .
User-Agent= + userAgent;
// This should be a logger warning, but not
sure how to
get a logger here.
System.out.println(warningMsg);
// After printing the warning, we take no
further special action on the
request.
// It is treated like a regular GET
} else {
// Treat the request as a bona-fide multi-part
request...
---
Additional Notes: The usefulness of the Content-Length clue is debatable.
I guess if someone
is using GET to send multipart data, they might very well stream a large
block
of data with initially unknown length, leading to a Content-Length value of
-1. So, the
most useful thing in this workaround (for me, at least), is the added check
on the HTTP method,
which is essentially denying the ability of the browser to send multipart
data using a GET request.
It would possibly be worthwhile to check
the User-Agent as well, if one thought that multipart-GET is reasonable, but
still
wanted to workaround the Safari bug. Yet another option would be to try to
make the multipart parser robust to empty content, but that might lead to
more
subtle problems if we weren't careful.
peace,
Stu Baurmann
--
View this message in context:
http://www.nabble.com/Workaround-for-Safari-3.x-problem-with-redirect-after-multipart-upload-tp16656737p16656737.html
Sent from the Cocoon - Users mailing list archive at
Workaround for Safari 3.x problem with redirect after multipart upload
Howdy folks,[Apologies if this gets posted twice - my first submit
attempt through Nabble appeared to fail]
I discovered a problem in using a redirect after a multipart upload,
affecting the combination of Cocoon 2.1.10 and Safari 3.x on Mac.
The symptom is a stacktrace from the CocoonServlet saying
MultipartException: Malformed Stream
It is really Safari that is misbehaving. The problem is similar to what is
described here:
http://jira.codehaus.org/browse/GRAILS-1938
Multipart upload from Safari into Cocoon works just fine in the cases we
have tested.
The browser uses POST to submit the multipart data. But after the upload
completes, if
we redirect the browser to GET another URL (e.g. a Thank you for your
upload page),
Safari does something bad. It sends the GET request as instructed, but it
also includes
a header like:
Content type: multipart/form-data; boundary=WebKitFormBoundaryCSofPC
...which Cocoon interprets as indicating a multipart request, regardless of
the
fact that a multipart GET is rather unlikely. Cocoon then expects to see
multipart
data in the request, and it does not, and so Cocoon throws a
MalformedStreamException.
My guess is that this behavior by Safari is a violation of the MIME and/or
HTTP
specs. Safari isn't really sending any multipart data on the redirected
GET, so
it shouldn't send this Content type header. It seems like a bit of
residual state
that is left in Safari after the redirect is causing it to re-send this
Content Type.
Note that I did not observe this same behavior in Safari on WindowsXP - only
in Safari on Mac.
Because one of our Cocoon applications has a significant number of Mac
Safari users, and it occurs to
me that some other browsers may exhibit similar behavior (though I hope
not).
I created a workaround that allows Cocoon to ignore the multipart Content
type
header in situations where it is unlikely that the inbound data is really
multipart.
The cocoon code which controls this behavior (in version 2.1.10) is:
org.apache.cocoon.servlet.multipart.RequestFactory
...specifically, the getServletRequest() method, which decides to process a
request as multipart if the
following condition holds:
if ((contentType != null)
(contentType.toLowerCase().indexOf(multipart/form-data) -1))
I have extended this condition so that it looks like the following, which is
hereby contributed
to the community. If someone wants to use this patch as inspiration for
a real patch in the
cocoon source, that's fine and dandy.
---
if ((contentType != null)
(contentType.toLowerCase().indexOf(multipart/form-data) -1)) {
// It sorta looks like a multipart request, based on the content-type.
// BUT, if it's a GET request, and content-length = 0, then it's
// probably not a valid multipart request. Most multipart requests
// are POSTS (I guess some are PUTS...).More likely, it's a
// redirected GET from Safari.(We could check User-Agent,
too...)
String method = request.getMethod();
int contentLength = request.getContentLength();
String userAgent = request.getHeader(User-Agent);
if ((contentLength = 0) method.equals(GET)) {
String warningMsg = Ignoring Content-Type +
contentType + because
Method= + method + and Content-Length= + contentLength + .
User-Agent= + userAgent;
// This should be a logger warning, but not
sure how to
get a logger here.
System.out.println(warningMsg);
// After printing the warning, we take no
further special action on the
request.
// It is treated like a regular GET
} else {
// Treat the request as a bona-fide multi-part
request...
---
Additional Notes: The usefulness of the Content-Length clue is debatable.
I guess if someone
is using GET to send multipart data, they might very well stream a large
block
of data with initially unknown length, leading to a Content-Length value of
-1. So, the
most useful thing in this workaround (for me, at least), is the added check
on the HTTP method,
which is essentially denying the ability of the browser to send multipart
data using a GET request.
It would possibly be worthwhile to check
the User-Agent as well, if one thought that multipart-GET is reasonable, but
still
wanted to workaround the Safari bug. Yet another option would be to try to
make the multipart parser robust to empty content, but that might lead to
more
subtle problems if we weren't careful.
peace,
Stu Baurmann
--
View this message in context:
http://cocoon.zones.apache.org/demos/trunk/ down since Friday
Hi guys, I started trying to get on to http://cocoon.zones.apache.org/demos/trunk/ on Friday so I could see how the site worked before doing my latest update on 2.2, but it has been down since Friday, presenting a 502. I wanted to see how the forms samples looked now that 2.2 release is just around the corner. Regards, Ross -- View this message in context: http://www.nabble.com/http%3A--cocoon.zones.apache.org-demos-trunk--down-since-Friday-tp16656999p16656999.html Sent from the Cocoon - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: pom.xml / Tomcat
Hi Grzegorz! Patrick Heiden pisze: snip/ I also used the simple webApp-Block out of the tut. Inside that blocks pom.xml there are dependencies to myBlock 12 and also the dependency to my domainModel. With that dependency given, there is no chance to get the app running inside tomcat (first there is a warning about servlet-api-2.3.jar and then the FATAL :error listenerLoad). As soon as I remove the domainModel-dependency out of the webApp-Block, everything is fine. Why??? AFAIK, C2.2 require servlet-api-2.4 for running. Could it be that your domainModel depends on 2.3 version? You can check it running: mvn dependency:list in your myDomainModel-Block. Alright, fixed this. THANKS! But... I don't think it's problem with RCL. I still have to remove myDomainModel-dependency from cocoons web-app block to get the app running inside tomcat. Clearly this can not be an RCL issue, due to the fact that RCL never 'touches' my tomcat, but this is a little misterious, still. WDYT?? Besides: I recieve the same error, when I put myDomainBlock-dependency inside another block (e.g. myBlock2). Should there be only ONE dependency to myDomainModel? This would be confusing, since some blocks should use this dep? Best greetings, Patrick -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: date bug related to leap year?
Joerg, This is indeed interesting. I will try it out and post my results. Thank you very much--you got me out of a bind once before also, back in 2004! rgds Paul - Original Message - From: Joerg Heinicke [EMAIL PROTECTED] To: users@cocoon.apache.org Sent: Saturday, April 12, 2008 11:06 PM Subject: Re: date bug related to leap year? On 12.04.2008 07:40, Paul Joseph wrote: Do you know what I need to do to switch it to the JDK lib.? Any thing to grep for that I then need to replace with its equivalent JDK call? I can't answer your questions directly right now, but I searched for ICU4J on our changes page [1] and found following entries: - Version 2.1.7 (March 23 2005) CForms: separate FormattingDateConvertor that uses java.text.SimpleDateFormat and Icu4jDateFormatter that uses ICU4J. There was previously an automatic switch to ICU4J if the library was present in the classpath, which sometimes caused some strange results as it behaves a bit differently. Committed by SW. - Version 2.1.6 (November 19 2004) The daylight time cause error when timezone is CST. Updated icu4j to 3.0. Committed by AG. Thanks to Johnson Hsu. See Issue 30372. See second one might be exactly what you are looking for. It seems we fixed it only by upgrading ICU4J. Hope this helps, Joerg [1] http://cocoon.apache.org/2.1/changes.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: http://cocoon.zones.apache.org/demos/trunk/ down since Friday
rossputin pisze: Hi guys, Hi Ross, I started trying to get on to http://cocoon.zones.apache.org/demos/trunk/ on Friday so I could see how the site worked before doing my latest update on 2.2, but it has been down since Friday, presenting a 502. I wanted to see how the forms samples looked now that 2.2 release is just around the corner. Fixed. It was stupid svn that got confused and wasn't able to update the trunk. I've fixed that, now demos work fine. Thanks for reporting. -- Grzegorz Kossakowski - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: date bug related to leap year?
Joerg, It worked! I updated the ICU4J lib. with the latest available and the problem has gone! Thanks again. If ever you are in the Boston area, please do let me know, I owe you a great dinner! brgds Paul - Original Message - From: Joerg Heinicke [EMAIL PROTECTED] To: users@cocoon.apache.org Sent: Saturday, April 12, 2008 11:06 PM Subject: Re: date bug related to leap year? On 12.04.2008 07:40, Paul Joseph wrote: Do you know what I need to do to switch it to the JDK lib.? Any thing to grep for that I then need to replace with its equivalent JDK call? I can't answer your questions directly right now, but I searched for ICU4J on our changes page [1] and found following entries: - Version 2.1.7 (March 23 2005) CForms: separate FormattingDateConvertor that uses java.text.SimpleDateFormat and Icu4jDateFormatter that uses ICU4J. There was previously an automatic switch to ICU4J if the library was present in the classpath, which sometimes caused some strange results as it behaves a bit differently. Committed by SW. - Version 2.1.6 (November 19 2004) The daylight time cause error when timezone is CST. Updated icu4j to 3.0. Committed by AG. Thanks to Johnson Hsu. See Issue 30372. See second one might be exactly what you are looking for. It seems we fixed it only by upgrading ICU4J. Hope this helps, Joerg [1] http://cocoon.apache.org/2.1/changes.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: pom.xml / Tomcat
Patrick Heiden pisze: I don't think it's problem with RCL. I still have to remove myDomainModel-dependency from cocoons web-app block to get the app running inside tomcat. Clearly this can not be an RCL issue, due to the fact that RCL never 'touches' my tomcat, but this is a little misterious, still. WDYT?? Besides: I recieve the same error, when I put myDomainBlock-dependency inside another block (e.g. myBlock2). Should there be only ONE dependency to myDomainModel? This would be confusing, since some blocks should use this dep? To be honest, I'm lost with your problem now. If servlet API 2.3 is not included (there is no dependency on it) what is the problem? You can depend on your myDomainModel from whatever block you want. It will be included only once. It's a job of Maven to guarantee that. -- Grzegorz Kossakowski - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: C2.2 Migration plan from 2.1
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]
Re: pom.xml / Tomcat
Hello Grzegorz! I still have to remove myDomainModel-dependency from cocoons web-app block to get the app running inside tomcat. Clearly this can not be an RCL issue, due to the fact that RCL never 'touches' my tomcat, but this is a little misterious, still. WDYT?? Besides: I recieve the same error, when I put myDomainBlock-dependency inside another block (e.g. myBlock2). Should there be only ONE dependency to myDomainModel? This would be confusing, since some blocks should use this dep? To be honest, I'm lost with your problem now. If servlet API 2.3 is not included (there is no dependency on it) what is the problem? Well, i solved the 2.3 problem. I had some outdated deps inside my domainModel-pom due to the usage of hibernate. This is no problem anymore ;) You can depend on your myDomainModel from whatever block you want. It will be included only once. It's a job of Maven to guarantee that. Here exactly is my problem: As soon as I add a dependency to myDomainBlock to more then one cocoon-Block (no matter if it is the web-app block or some usual cocoon-22-archetype-block) there is no chance to get the application run inside my tomcat. Is there any information I could state so that you are in better position to help me with that? Best regards, Patrick -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: pom.xml / Tomcat
Patrick Heiden pisze: You can depend on your myDomainModel from whatever block you want. It will be included only once. It's a job of Maven to guarantee that. Here exactly is my problem: As soon as I add a dependency to myDomainBlock to more then one cocoon-Block (no matter if it is the web-app block or some usual cocoon-22-archetype-block) there is no chance to get the application run inside my tomcat. Is there any information I could state so that you are in better position to help me with that? Ok, I agree that's something very weird. I'll probably need dependency listing of myBlock, myBlock2, and myCocoonWebapp in case you have dependency to domain added to myBlock and myBlock2. Apart from that I'll need exact error message that Tomcat returns. I'm really curious what you will bring here. :-) -- Grzegorz Kossakowski - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: pom.xml / Tomcat
Actually all Blocks (three :) depend on myDomainBlock: dependencies of my domain (plain maven block): [INFO] The following files have been resolved: [INFO]antlr:antlr:jar:2.7.6:compile [INFO]asm:asm:jar:1.5.3:compile [INFO]asm:asm-attrs:jar:1.5.3:compile [INFO]cglib:cglib:jar:2.1_3:compile [INFO]commons-collections:commons-collections:jar:2.1.1:compile [INFO]commons-dbcp:commons-dbcp:jar:1.2.2:compile [INFO]commons-logging:commons-logging:jar:1.0.4:compile [INFO]commons-pool:commons-pool:jar:1.3:compile [INFO]dom4j:dom4j:jar:1.6.1:compile [INFO]javax.transaction:jta:jar:1.0.1B:compile [INFO]junit:junit:jar:3.8.1:test [INFO]log4j:log4j:jar:1.2.14:compile [INFO]mysql:mysql-connector-java:jar:5.1.6:compile [INFO]net.sf.ehcache:ehcache:jar:1.2.3:compile [INFO]org.hibernate:hibernate:jar:3.2.2.ga:compile [INFO]org.springframework:spring:jar:2.0.6:compile [INFO]org.springframework:spring-mock:jar:2.0.6:test dependencies of cocoon block1 (called isac) [INFO] The following files have been resolved: [INFO]antlr:antlr:jar:2.7.6:compile [INFO]aopalliance:aopalliance:jar:1.0:compile [INFO]asm:asm:jar:1.5.3:compile [INFO]asm:asm-attrs:jar:1.5.3:compile [INFO]cglib:cglib:jar:2.1_3:compile [INFO]commons-collections:commons-collections:jar:3.2:compile [INFO]commons-dbcp:commons-dbcp:jar:1.2.2:compile [INFO]commons-io:commons-io:jar:1.3.1:compile [INFO]commons-jexl:commons-jexl:jar:1.0:compile [INFO]commons-jxpath:commons-jxpath:jar:1.2:compile [INFO]commons-lang:commons-lang:jar:2.3:compile [INFO]commons-logging:commons-logging:jar:1.1:compile [INFO]commons-pool:commons-pool:jar:1.3:compile [INFO]concurrent:concurrent:jar:1.3.4:compile [INFO]de.ifado:isac2:jar:1.0-SNAPSHOT:compile [INFO]de.ifado:isacDomain:jar:1.0-SNAPSHOT:compile [INFO]dom4j:dom4j:jar:1.6.1:compile [INFO]jakarta-regexp:jakarta-regexp:jar:1.4:compile [INFO]javax.transaction:jta:jar:1.0.1B:compile [INFO]junit:junit:jar:3.8:compile [INFO]log4j:log4j:jar:1.2.14:compile [INFO]mysql:mysql-connector-java:jar:5.1.6:compile [INFO]net.sf.ehcache:ehcache:jar:1.2.3:compile [INFO]org.apache.avalon.framework:avalon-framework-api:jar:4.3.1:compile [INFO]org.apache.avalon.framework:avalon-framework-impl:jar:4.3.1:compile [INFO]org.apache.cocoon:cocoon-configuration-api:jar:1.0.1:compile [INFO]org.apache.cocoon:cocoon-core:jar:2.2.0-RC2:compile [INFO]org.apache.cocoon:cocoon-expression-language-api:jar:1.0.0-RC2:compile [INFO] org.apache.cocoon:cocoon-expression-language-impl:jar:1.0.0-RC2:compile [INFO]org.apache.cocoon:cocoon-flowscript-impl:jar:1.0.0-RC2:compile [INFO]org.apache.cocoon:cocoon-linkrewriter-impl:jar:1.0.0-RC2:compile [INFO]org.apache.cocoon:cocoon-pipeline-api:jar:1.0.0-RC2:compile [INFO]org.apache.cocoon:cocoon-pipeline-components:jar:1.0.0-RC2:compile [INFO]org.apache.cocoon:cocoon-pipeline-impl:jar:1.0.0-RC2:compile [INFO] org.apache.cocoon:cocoon-servlet-service-components:jar:1.0.0-RC1:compile [INFO]org.apache.cocoon:cocoon-servlet-service-impl:jar:1.0.0-RC1:compile [INFO]org.apache.cocoon:cocoon-sitemap-api:jar:1.0.0-RC2:compile [INFO]org.apache.cocoon:cocoon-sitemap-components:jar:1.0.0-RC2:compile [INFO]org.apache.cocoon:cocoon-sitemap-impl:jar:1.0.0-RC2:compile [INFO]org.apache.cocoon:cocoon-spring-configurator:jar:1.0.1:compile [INFO]org.apache.cocoon:cocoon-store-impl:jar:1.0.0-RC2:runtime [INFO]org.apache.cocoon:cocoon-template-impl:jar:1.0.0-RC2:compile [INFO]org.apache.cocoon:cocoon-thread-api:jar:1.0.0-RC2:compile [INFO]org.apache.cocoon:cocoon-thread-impl:jar:1.0.0-RC2:runtime [INFO]org.apache.cocoon:cocoon-util:jar:1.0.0-RC2:compile [INFO]org.apache.cocoon:cocoon-xml-api:jar:1.0.0-RC2:compile [INFO]org.apache.cocoon:cocoon-xml-impl:jar:1.0.0-RC2:compile [INFO]org.apache.cocoon:cocoon-xml-resolver:jar:1.0.0-RC2:compile [INFO]org.apache.cocoon:cocoon-xml-util:jar:1.0.0-RC2:compile [INFO]org.apache.excalibur.components:excalibur-pool-api:jar:2.2.1:compile [INFO] org.apache.excalibur.components:excalibur-sourceresolve:jar:2.2.3:compile [INFO]org.apache.excalibur.components:excalibur-store:jar:2.2.1:compile [INFO]org.apache.excalibur.components:excalibur-xmlutil:jar:2.2.1:compile [INFO] org.apache.excalibur.containerkit:excalibur-instrument-api:jar:2.2.1:compile [INFO]org.apache.excalibur.containerkit:excalibur-logger:jar:2.2.1:compile [INFO]org.hibernate:hibernate:jar:3.2.2.ga:compile [INFO]org.springframework:spring:jar:2.0.6:compile [INFO]org.springframework:spring-aop:jar:2.0.6:compile [INFO]org.springframework:spring-beans:jar:2.0.6:compile [INFO]org.springframework:spring-context:jar:2.0.6:compile [INFO]org.springframework:spring-core:jar:2.0.6:compile [INFO]org.springframework:spring-web:jar:2.0.6:compile [INFO]
Re: pom.xml / Tomcat
Patrick Heiden pisze: Actually all Blocks (three :) depend on myDomainBlock: dependencies of my domain (plain maven block): snip/ Here everything looks ok so it rather not Maven's mistake. And finally, the tomcat output: snip/ FATAL: Error listenerStart 13.04.2008 20:25:41 org.apache.catalina.core.StandardContext start FATAL: Context [/isacWebApp-1.0-SNAPSHOT] startup failed due to previous errors Ouch, that's certainly not enough to get idea what's happening. Are you sure this is everything that Tomcat provides? This log does not explain which listener and why it failed. I have not used Tomcat for some time but I remember it was logging much, much more than what you pasted here. Have you checked $CATALINA_HOME/logs ? -- Grzegorz Kossakowski - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More Cocoon 2.2 question
On Apr 9, 2008, at 11:36 PM, Kamal Bhatt wrote: As such, how do I point Cocoon to use a sitemap outside the main Cocoon project? Depends what you mean... If using 2.2 blocks, add a parameter to the block servlet bean definition. Like this: 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 If using classic mode, it is same as usual, sitemap/ element in main xconf file. Vadim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon 2.2 - Cocoon Forms 1.0 block: Replacing Avalon's ServiceManager interface with Spring 2
On Apr 10, 2008, at 3:58 PM, Magnus Haraldsen Amundsen wrote: I'm looking into the Cocoon Forms 1.0 block (with Cocoon 2.2) and it seems very nice. But I see that the Java API example at http://cocoon.apache.org/2.2/blocks/forms/1.0/498_1_1.html use Avalon's ServiceManager interface. However, at the New in 2.2 page it says that Cocoon 2.2 doesn't use an Avalon-based component manager any more but uses Spring 2 instead.. Cocoon 2.2 internally uses Spring, but it still provides backward compatibility (as far as it's possible) with Cocoon 2.1, so it implements Avalon functionality and provides an implementation of Avalon's ServiceManager. Because of this CForms 1.0 can continue to use ServiceManager. I should also mention that there is CForms version 1.1 which does not use ServiceManager anymore and is migrated to Spring. Links to CForms 1.0 and 1.1: http://svn.apache.org/repos/asf/cocoon/branches/cocoon-forms-1.0.0/ http://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-forms/ Vadim How do I replace the Avalon ServiceManager interface in the Cocoon Forms 1.0 block Java API sample with Spring 2? A small code example on this would be great, since I don't know Avalon or Spring 2. Best regards, Magnus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: C2.2 Migration plan from 2.1
On Apr 12, 2008, at 7:30 AM, Grzegorz Kossakowski wrote: Kamal pisze: Hi, I am trying to work out the best way of migrating off 2.1 into 2.2. Firstly, we have far too much functionality to migrate everything in one hit. So, I was wondering if it were possible to communicate XML between two instances of Cocoon easily (without hitting an URL). That is, from 2.2 to 2.1. Would the Cocoon Servlet Service help here? Hmmm. I haven't tried such approach. This should be possible, the only problem I can see here is that running two Cocoon versions in the same JVM may result in library clashes. It's still a subject for research. Running any number of different Cocoon versions within same container instance (Tomcat/Jetty) is not a problem at all, since container will isolate web applications. But running different Cocoon versions within same webapp would be non trivial. I guess question should be reformulated as, can SSF be used to communicate between two webapps in the same container... Grzegorz? :) Vadim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: C2.2 Migration plan from 2.1
On Apr 12, 2008, at 2:31 PM, Grzegorz Kossakowski wrote: Kamal pisze: I didn't see anything in Vadim's slides that indicated how to get around the lack of XSP support (admittadly, I was looking at the slides through Google as my powerpoint viewer seems busted). Oh XSP may be a big problem. I mean, we have XSP block in C2.2 but it was never officially released and I doubt it will ever get released. It looks like nobody is interested in maintaining XSP these days when we have different approaches. Alfred is one of XSP users and Cocoon committer, so saying that it is completely unmaintained is a bit hasty. Also, most of the XSP samples in trunk are working (with the exception of SOAP samples) [1], so all it might need for release is some samples fixes and clean up. Vadim [1] http://cocoon.zones.apache.org/demos/trunk/cocoon-xsp-sample/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: C2.2 Migration plan from 2.1
Vadim Gritsenko pisze: Running any number of different Cocoon versions within same container instance (Tomcat/Jetty) is not a problem at all, since container will isolate web applications. But running different Cocoon versions within same webapp would be non trivial. Ah, you are right Vadim. I guess question should be reformulated as, can SSF be used to communicate between two webapps in the same container... Grzegorz? :) Generally speaking, yes. The only problem is that SSF allows to communicate servlets that are Spring beans. If one would like to talk to servlet managed by Servlet container then a simple proxy servlet should be created (and registered to SSF). This proxy servlet would forward every request coming to the target servlet managed by Servlet Container. Writing such proxy servlet seems to be trivial tasks as all handy API is already in place. -- Grzegorz Kossakowski - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon 2.2 - Cocoon Forms 1.0 block: Replacing Avalon's ServiceManager interface with Spring 2
Vadim Gritsenko pisze: On Apr 10, 2008, at 3:58 PM, Magnus Haraldsen Amundsen wrote: I'm looking into the Cocoon Forms 1.0 block (with Cocoon 2.2) and it seems very nice. But I see that the Java API example at http://cocoon.apache.org/2.2/blocks/forms/1.0/498_1_1.html use Avalon's ServiceManager interface. However, at the New in 2.2 page it says that Cocoon 2.2 doesn't use an Avalon-based component manager any more but uses Spring 2 instead.. Cocoon 2.2 internally uses Spring, but it still provides backward compatibility (as far as it's possible) with Cocoon 2.1, so it implements Avalon functionality and provides an implementation of Avalon's ServiceManager. Because of this CForms 1.0 can continue to use ServiceManager. I should also mention that there is CForms version 1.1 which does not use ServiceManager anymore and is migrated to Spring. Links to CForms 1.0 and 1.1: http://svn.apache.org/repos/asf/cocoon/branches/cocoon-forms-1.0.0/ http://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-forms/ I would add that we have already Spring implementation for Apples, see[1]. This way, Controllers can be just Spring beans so Dependency Injection can be used instead of ServletManager from Avalon. Magnus, since you said you don't know Spring or Avalon I think you will have hard times using Java code in Cocoon. I would say that you don't need to be a master of Spring to use Cocoon but some basics are highly recommended. In this particular case I would advise you to take a look at apples block samples[2][3] and figure out how to migrate them to Spring with help of people from this list. This way you would learn basics and could contribute migrated samples to community so others could benefit. [1] http://svn.apache.org/viewvc/cocoon/trunk/blocks/cocoon-apples/cocoon-apples-impl/src/main/java/org/apache/cocoon/components/flow/apples/SpringApplesProcessor.java?view=markup [2] http://cocoon.zones.apache.org/demos/trunk/cocoon-apples-sample/ [3] http://svn.apache.org/viewvc/cocoon/trunk/blocks/cocoon-apples/cocoon-apples-sample/ -- Grzegorz Kossakowski - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: pom.xml / Tomcat
Sorry, I've forgotten to activate logging, here an extendet version of tomcats output, maybe now you are able to see what is happening: Using CATALINA_BASE: /home/pepemuck/_opt/tomcat55 Using CATALINA_HOME: /home/pepemuck/_opt/tomcat55 Using CATALINA_TMPDIR: /home/pepemuck/_opt/tomcat55/temp Using JRE_HOME: /opt/jdk1.5.0_15 13.04.2008 21:56:28 org.apache.catalina.core.AprLifecycleListener lifecycleEvent INFO: The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /opt/jdk1.5.0_15/jre/lib/i386/client:/opt/jdk1.5.0_15/jre/lib/i386:/opt/jdk1.5.0_15/jre/../lib/i386 13.04.2008 21:56:28 org.apache.coyote.http11.Http11BaseProtocol init INFO: Initializing Coyote HTTP/1.1 on http-8080 13.04.2008 21:56:28 org.apache.catalina.startup.Catalina load INFO: Initialization processed in 1021 ms 13.04.2008 21:56:28 org.apache.catalina.core.StandardService start INFO: Starting service Catalina 13.04.2008 21:56:28 org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/5.5.26 13.04.2008 21:56:28 org.apache.catalina.core.StandardHost start INFO: XML validation disabled [ERROR,ContextLoader,main] Context initialization failed org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.cocoon.el.objectmodel.ObjectModel': Initialization of bean failed; nested exception is org.springframework.beans.factory.CannotLoadBeanClassException: Error loading class [org.apache.cocoon.el.impl.objectmodel.ObjectModelImpl] for bean with name 'scopedTarget.org.apache.cocoon.el.objectmodel.ObjectModel' defined in URL [jar:file:/home/pepemuck/_opt/tomcat55/webapps/isacWebApp/WEB-INF/lib/cocoon-pipeline-impl-1.0.0-RC2.jar!/META-INF/cocoon/spring/ObjectModel.xml]: problem with class file or dependent class; nested exception is java.lang.NoClassDefFoundError: org/apache/commons/collections/map/AbstractMapDecorator Caused by: org.springframework.beans.factory.CannotLoadBeanClassException: Error loading class [org.apache.cocoon.el.impl.objectmodel.ObjectModelImpl] for bean with name 'scopedTarget.org.apache.cocoon.el.objectmodel.ObjectModel' defined in URL [jar:file:/home/pepemuck/_opt/tomcat55/webapps/isacWebApp/WEB-INF/lib/cocoon-pipeline-impl-1.0.0-RC2.jar!/META-INF/cocoon/spring/ObjectModel.xml]: problem with class file or dependent class; nested exception is java.lang.NoClassDefFoundError: org/apache/commons/collections/map/AbstractMapDecorator Caused by: java.lang.NoClassDefFoundError: org/apache/commons/collections/map/AbstractMapDecorator at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:1853) at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:875) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1330) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1209) at org.springframework.util.ClassUtils.forName(ClassUtils.java:201) at org.springframework.beans.factory.support.AbstractBeanDefinition.resolveBeanClass(AbstractBeanDefinition.java:327) at org.springframework.beans.factory.support.AbstractBeanFactory.resolveBeanClass(AbstractBeanFactory.java:1075) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.predictBeanType(AbstractAutowireCapableBeanFactory.java:465) at org.springframework.beans.factory.support.AbstractBeanFactory.getType(AbstractBeanFactory.java:478) at org.springframework.aop.scope.ScopedProxyFactoryBean.setBeanFactory(ScopedProxyFactoryBean.java:92) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1162) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:425) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:251) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:156) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:248) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:160) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:284) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:352) at
Re: pom.xml / Tomcat
Sorry, I've forgotten to activate logging, here an extendet version of tomcats output, maybe now you are able to see what is happening: snip actual-archetypes=somewhat-mixed-up-within-my-configuration / I would guess, that I've done something wrong with my archetypes. What versions for cocoon-22-archetype-block-plain, cocoon-22-archetype-block and cocoon-22-archetype-webapp are adviced to get used? repo1.maven.org states, that 1.0.0 is 'recommended', right? There are 1.1.0-SNAPSHOTS inside my local repo, should I use them? It is a bit confusing (although logical), that mixing archetypes could result in such stuff (my fault!) if my guess is right. If it is, what should one do with blocks created by older archetypes? At this point (myself comming from Ant before) mavens pom could easily get into the way when one is trying to synchronize different frameworks dependencies. (I would say, that I have to repeat some maven-readings ;) Best regards, Patrick -- Psst! Geheimtipp: Online Games kostenlos spielen bei den GMX Free Games! http://games.entertainment.gmx.net/de/entertainment/games/free - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: pom.xml / Tomcat
Patrick Heiden pisze: Sorry, I've forgotten to activate logging, here an extendet version of tomcats output, maybe now you are able to see what is happening: snip/ [org.apache.cocoon.el.impl.objectmodel.ObjectModelImpl] for bean with name 'scopedTarget.org.apache.cocoon.el.objectmodel.ObjectModel' defined in URL [jar:file:/home/pepemuck/_opt/tomcat55/webapps/isacWebApp/WEB-INF/lib/cocoon-pipeline-impl-1.0.0-RC2.jar!/META-INF/cocoon/spring/ObjectModel.xml]: problem with class file or dependent class; nested exception is java.lang.NoClassDefFoundError: org/apache/commons/collections/map/AbstractMapDecorator Caused by: java.lang.NoClassDefFoundError: org/apache/commons/collections/map/AbstractMapDecorator Ok. Now everything is clear. Class org.apache.cocoon.el.impl.objectmodel.ObjectModelImpl comes from cocoon-expression-language module, its dependencies can be found here: http://cocoon.apache.org/2.2/core-modules/expression-language-impl/1.0/dependencies.html As you can see, EL module depends on commons-collections:3.2, now let's take a look at your dependencies listings: myDomainBlock: [INFO]commons-collections:commons-collections:jar:2.1.1:compile isac: [INFO]commons-collections:commons-collections:jar:3.2:compile isacWebApp: [INFO]commons-collections:commons-collections:jar:2.1.1:compile As you see, wrong version (coming from myDomain) lands in your webapp and that's why it breaks. I think that Patrick it's crucial now for you to understand how transitive dependencies work in Maven in order to effectively resolve such problems. You sould study [1][2] and then decide to use exclusion mechanism or direct dependency specification (so right version is being pulled). [1] http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html [2] http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution -- Best regards, Grzegorz Kossakowski - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: C2.2 Migration plan from 2.1
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
