Thorsten Scherler | 2 Mar 2009 09:22
Picon

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
(Continue reading)

Thorsten Scherler (JIRA | 2 Mar 2009 10:02
Picon
Favicon

[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-tabpanel&focusedCommentId=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);
>          }
>      }
(Continue reading)

Thorsten Scherler (JIRA | 2 Mar 2009 10:04
Picon
Favicon

[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
(Continue reading)

Thorsten Scherler | 2 Mar 2009 10:09
Picon

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
--

-- 
(Continue reading)

Reinhard Pötz | 2 Mar 2009 12:37
Picon
Favicon

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. 
(Continue reading)

Grzegorz Kossakowski | 2 Mar 2009 14:21
Favicon
Gravatar

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

Reinhard Pötz | 2 Mar 2009 14:27
Picon
Favicon

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                  reinhard <at> apache.org
________________________________________________________________________

Grzegorz Kossakowski | 2 Mar 2009 14:33
Favicon
Gravatar

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

Andreas Hartmann | 2 Mar 2009 14:41
Picon
Favicon

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

Alfred Nathaniel | 3 Mar 2009 00:26
Picon
Favicon

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
> 
(Continue reading)


Gmane