Block resources and proxying
Hi all, we have developed a block to add a new section to our page. http://juntadeandalucia.es/28f2009/index.html This section is independent from the rest of the portal. Since we are using Apache httpd to serve all images, css and js we had to implement a rewrite rule to the work dir of tomcat. Something like: RewriteRule ^/themes/images/28f2009/(.*)\.(gif|jpg|jpeg|ico)$ $PORTAL/work/blocks/conectorEspeciales/themer/themes/common/images/$1.$2 [L] We cannot do this anymore out of constraints from our production department and are looking into ways to link to the resources in the block lib not pointing into the work dir of tomcat. How do other solve this issue? Is there a a way to tell the block to deploy to another path then the work dir of tomcat? I see different solutions: 1) Link into the jar via httpd directly (not sure whether httpd can do that and whether that brings any drawbacks). 2) Use block deployer from cocoon (if exists) that extract the jar to certain configurable path. 3) Tell production that they need to unzip the block.jar into a certain path themselves. Any ideas and thoughts welcome. TIA salu2 -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions Sociedad Andaluza para el Desarrollo de la Sociedad de la Información, S.A.U. (SADESI)
[jira] Commented: (COCOON-2253) StringXMLizable in combination with IncludeXMLConsumer does not handle xml-comments
[
https://issues.apache.org/jira/browse/COCOON-2253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12677930#action_12677930
]
Thorsten Scherler commented on COCOON-2253:
---
On Fri, 2009-02-27 at 14:26 +0100, Andreas Hartmann wrote:
StringXMLizable.toSAX() sets only the content handler of the SAX parser.
Maybe it makes sense to set the lexical handler, if possible?
public void toSAX(ContentHandler contentHandler) throws SAXException {
final SAXParser parser = getContext().parser;
parser.getXMLReader().setContentHandler(contentHandler);
+ if (contentHandler instanceof LexicalHandler) {
+ parser.getXMLReader().setProperty(
+ http://xml.org/sax/properties/lexical-handler;,
+ (LexicalHandler) contentHandler);
+ }
InputSource is = new InputSource(new StringReader(data));
try {
parser.getXMLReader().parse(is);
} catch (IOException e) {
throw new SAXException(e);
}
}
StringXMLizable in combination with IncludeXMLConsumer does not handle
xml-comments
---
Key: COCOON-2253
URL: https://issues.apache.org/jira/browse/COCOON-2253
Project: Cocoon
Issue Type: Bug
Components: * Cocoon Core
Affects Versions: 2.1.12-dev (Current SVN), 2.2
Reporter: Thorsten Scherler
Assignee: Cocoon Developers Team
Attachments: TestComment.java
http://markmail.org/thread/h5jfhzmv7su2osob
I encountered a very weird problem that happened suddenly.
I am using the dispatcherTransformer [1] and in the method
structurerProcessingEnd() I am doing: ... StringXMLizable xml = new
StringXMLizable(out.toString()); xml.toSAX(new
IncludeXMLConsumer(super.xmlConsumer)); ...
I as well tried XMLUtils.valueOf(new IncludeXMLConsumer(super.xmlConsumer),
xml);
but after this stage the comments disappear.
You can test it by doing StringXMLizable xml = new
StringXMLizable(body!--test--/body); xml.toSAX(new
IncludeXMLConsumer(super.xmlConsumer)); in a clean transformer and you get
body /body.
First I though it is the RedundantNamespacesFilter which I used as consumer
but changing this did not work.
I see (while debugging) in the IncludeXMLConsumer that comment(...) is not
being called but does it e.g. for startElements.
Anybody has a clue what is going on?
salu2
[1]
http://svn.apache.org/viewvc/forrest/branches/dispatcher_rewrite/plugins/org.apache.forrest.plugin.internal.dispatcher/src/java/org/apache/forrest/dispatcher/transformation/DispatcherTransformer.java?diff_format=hview=markup
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2253) StringXMLizable.toSAX() sets only the content handler of the SAX parser leading to not generating SAX events for e.g. comments
[ https://issues.apache.org/jira/browse/COCOON-2253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thorsten Scherler updated COCOON-2253: -- Summary: StringXMLizable.toSAX() sets only the content handler of the SAX parser leading to not generating SAX events for e.g. comments (was: StringXMLizable in combination with IncludeXMLConsumer does not handle xml-comments) StringXMLizable.toSAX() sets only the content handler of the SAX parser leading to not generating SAX events for e.g. comments -- Key: COCOON-2253 URL: https://issues.apache.org/jira/browse/COCOON-2253 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.12-dev (Current SVN), 2.2 Reporter: Thorsten Scherler Assignee: Cocoon Developers Team Attachments: TestComment.java http://markmail.org/thread/h5jfhzmv7su2osob I encountered a very weird problem that happened suddenly. I am using the dispatcherTransformer [1] and in the method structurerProcessingEnd() I am doing: ... StringXMLizable xml = new StringXMLizable(out.toString()); xml.toSAX(new IncludeXMLConsumer(super.xmlConsumer)); ... I as well tried XMLUtils.valueOf(new IncludeXMLConsumer(super.xmlConsumer), xml); but after this stage the comments disappear. You can test it by doing StringXMLizable xml = new StringXMLizable(body!--test--/body); xml.toSAX(new IncludeXMLConsumer(super.xmlConsumer)); in a clean transformer and you get body /body. First I though it is the RedundantNamespacesFilter which I used as consumer but changing this did not work. I see (while debugging) in the IncludeXMLConsumer that comment(...) is not being called but does it e.g. for startElements. Anybody has a clue what is going on? salu2 [1] http://svn.apache.org/viewvc/forrest/branches/dispatcher_rewrite/plugins/org.apache.forrest.plugin.internal.dispatcher/src/java/org/apache/forrest/dispatcher/transformation/DispatcherTransformer.java?diff_format=hview=markup -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: IncludeXMLConsumer with RedundantNamespacesFilter does not output comments
On Fri, 2009-02-27 at 14:26 +0100, Andreas Hartmann wrote:
StringXMLizable.toSAX() sets only the content handler of the SAX
parser.
Maybe it makes sense to set the lexical handler, if possible?
public void toSAX(ContentHandler contentHandler) throws
SAXException {
final SAXParser parser = getContext().parser;
parser.getXMLReader().setContentHandler(contentHandler);
+ if (contentHandler instanceof LexicalHandler) {
+ parser.getXMLReader().setProperty(
+ http://xml.org/sax/properties/lexical-handler;,
+ (LexicalHandler) contentHandler);
+ }
InputSource is = new InputSource(new StringReader(data));
try {
parser.getXMLReader().parse(is);
} catch (IOException e) {
throw new SAXException(e);
}
}
I agree that this change is the elegant solution for the problem. Can
you apply it, if nobody objects.
salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
Sociedad Andaluza para el Desarrollo de la Sociedad
de la Información, S.A.U. (SADESI)
Re: Block resources and proxying
Thorsten Scherler wrote:
Hi all,
we have developed a block to add a new section to our page.
http://juntadeandalucia.es/28f2009/index.html
This section is independent from the rest of the portal. Since we are
using Apache httpd to serve all images, css and js we had to implement a
rewrite rule to the work dir of tomcat.
Something like:
RewriteRule ^/themes/images/28f2009/(.*)\.(gif|jpg|jpeg|ico)$
$PORTAL/work/blocks/conectorEspeciales/themer/themes/common/images/$1.$2 [L]
We cannot do this anymore out of constraints from our production
department and are looking into ways to link to the resources in the
block lib not pointing into the work dir of tomcat.
How do other solve this issue?
Is there a a way to tell the block to deploy to another path then the
work dir of tomcat?
I see different solutions:
1) Link into the jar via httpd directly (not sure whether httpd can do
that and whether that brings any drawbacks).
2) Use block deployer from cocoon (if exists) that extract the jar to
certain configurable path.
Have a look at the cocoon-block-deployment subproject. It contains a
servlet listener (BlockDeploymentServletContextListener) that extracts
all blocks into the work directory.
You could write an additional listener for you purpose which should be
fairly easy because DeploymentUtil.deployBlockArtifacts(File f) does
everything that you need.
The only problem that we would have to solve is how we make this
configurable. We can't use the Spring configurator for that purpose
because it is not initialized when the listener is called.
After writing this I think that you could also write an initializable
Spring bean that calls DeploymentUtil.deployBlockArtifacts(File f) which
would solve the configuration problem.
3) Tell production that they need to unzip the block.jar into a certain
path themselves.
Of course possible but clumsy IMO.
Any ideas and thoughts welcome.
Another idea is to use mod_cache of httpd.
HTH
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinh...@apache.org
Re: Block resources and proxying
Reinhard Pötz pisze: Any ideas and thoughts welcome. Another idea is to use mod_cache of httpd. +1 for this one. Cocoon by default sets all caching-related HTTP headers for static resources. Thus httpd should just act as a simple proxy in front of Cocoon instance. -- Best regards, Grzegorz Kossakowski
Re: Block resources and proxying
Grzegorz Kossakowski wrote:
Reinhard Pötz pisze:
Any ideas and thoughts welcome.
Another idea is to use mod_cache of httpd.
+1 for this one.
Cocoon by default sets all caching-related HTTP headers for static
resources. Thus httpd should just act as a simple proxy in front of
Cocoon instance.
We usually use httpd mod_cache for static resources in our projects but
some sysadmins don't like it (don't ask me why).
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinh...@apache.org
Re: Block resources and proxying
Reinhard Pötz pisze: We usually use httpd mod_cache for static resources in our projects but some sysadmins don't like it (don't ask me why). Too bad, I would be very curious to hear why it's a bad idea. I can say why configuring httpd to access some resources directly is a bad idea. It's simply mixing of layers that sooner or later will introduce some headaches (think of SSF for e.g.) or will limit application developer in artificial way. -- Best regards, Grzegorz Kossakowski
Re: Block resources and proxying
Grzegorz Kossakowski schrieb: Reinhard Pötz pisze: We usually use httpd mod_cache for static resources in our projects but some sysadmins don't like it (don't ask me why). Too bad, I would be very curious to hear why it's a bad idea. I can say why configuring httpd to access some resources directly is a bad idea. It's simply mixing of layers that sooner or later will introduce some headaches (think of SSF for e.g.) or will limit application developer in artificial way. I totally agree. Using mod_cache instead of directly exposing files to HTTPD already saved me a lot of deployment hassle. -- Andreas -- Andreas Hartmann, CTO BeCompany GmbH http://www.becompany.ch Tel.: +41 (0) 43 818 57 01
Re: FW: Cocoon versions for Java 6
Hi Laurent, we are using Cocoon 2.1.x still with Java 5. But with that comment in the bug report you should just give it a spin. If you want to be cautious, define the magic property. If you feel more adventerous, try it without and fix the source where it bombs. Cheers, Alfred. Submitted On 25-JUL-2007 Neale I tripped over this, and thought: JDK6 has broken something. Now that there is a documented workaround, I think that it could be considered fixed, as we now have two options: 1) Add -Dsun.lang.ClassLoader.allowArraySyntax=true if you want to use a library for which you don't have the source with JDK6 2) Change loader.loadClass( name ) to Class.forName( name, false, loader ) if you own the code. If Sun are not intending to fix this to be compatible without the flag, then I think it would be great if we could have a clear statement here to close off this bug On Thu, 2009-02-26 at 14:25 +0100, Laurent Medioni wrote: Hi, Trying my luck on the dev list ? Thanks, Laurent -Original Message- From: Laurent Medioni [mailto:lmedi...@odyssey-group.com] Sent: mardi, 24. février 2009 10:37 To: us...@cocoon.apache.org Subject: Cocoon versions for Java 6 Hi, Anyone knows if a Cocoon version is validated/intended for Java 6 ? Sorry Googled a lot but to no avail... We plan to move our 2.1.11 application to Java 6 and already had a nasty Reflection issue for arrays with 1.6 described in http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6434149 And I noticed that there are a lot of occurrences of these calls in 2.1.11... Thanks.
