RE: Cocoon 2.1.11- XSP compiled in Java 1.3 when running Cocoon with a 1.6 JVM and using the Eclipse compiler
Should we also replace, in Cocoon 2.1.x, JDT 3.1 with 3.5 ? As 3.1 does not know about 1.6 and 3.5 still support Java 1.1 ;) We use 3.5 since a few weeks and have not detected any issue... Laurent -Original Message- From: Antonio Gallardo [mailto:agalla...@agssa.net] Sent: lundi, 31. août 2009 22:45 To: us...@cocoon.apache.org Subject: Re: Cocoon 2.1.11- XSP compiled in Java 1.3 when running Cocoon with a 1.6 JVM and using the Eclipse compiler El 31/08/09 04:54, Laurent Medioni escribió: Anyway I think that EclipseJavaCompiler should be modified to properly handle 1.6 without reverting to 1.3 by default (even if the 2 additional jdt properties look more cosmetic than critical for the generated code). +1 Would you provide a patch. I think it should not be too dificult. BTW, The java 1.3 was set to default value, due historical reasons. Perhaps it is time to switch that too. :) Best Regards, Antonio Gallardo. - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org � This email and any files transmitted with it are CONFIDENTIAL and intended solely for the use of the individual or entity to which they are addressed. � Any unauthorized copying, disclosure, or distribution of the material within this email is strictly forbidden. � Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of Odyssey Financial Technologies SA unless otherwise specifically stated. � An electronic message is not binding on its sender. Any message referring to a binding engagement must be confirmed in writing and duly signed. � If you have received this email in error, please notify the sender immediately and delete the original.
Re: rapid application development with rcl
On Thu, 2009-09-03 at 15:29 +0200, Andreas Hartmann wrote: Thorsten Scherler schrieb: On Thu, 2009-09-03 at 13:23 +0200, Reinhard Pötz wrote: Thorsten Scherler wrote: Hi all, our site is based on different blocks and one main webapp (cocoon-22-archetype-webapp). The problem we are facing is that developing within blocks is really rapid thanks to the rcl but all the code we have in the webapp needs to have a constant rebuild, which is a real pain. http://cocoon.apache.org/2.2/maven-plugins/maven-plugin/1.0/1358_1_1.html Is talking about the goals that are doing the rcl stuff, how can we port this to the webapp? Any hints and tips are welcome. Why do you have to put Java code into the webapp at all? Not talking about the java code that is the bad thing. I am talking about normal xsl/sitemap changes. :( I use the webapp only as a container for the blocks, it doesn't contain any code at all. There is a welcome block which is mounted at / as an entry point. Definitely a clean workaround. ;) How do you deal with the fact that the mount does not provide a pass-trough attribute anymore? I mean in 2.1 I can mount different maps which are looked into and if no match can be found there they are coming back to the parent sitemap and look for the next mount/match. That is a problem that we face in forrest with the switch to 2.2. That works quite well, but the class loader incompatibilities (e.g. for session attributes) are still a real PITA (cannot cast class Foo to Foo) :( How did you worked around that? 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: rapid application development with rcl
On Fri, 2009-09-04 at 12:06 +0200, Reinhard Pötz wrote: Thorsten Scherler wrote: On Thu, 2009-09-03 at 15:29 +0200, Andreas Hartmann wrote: Thorsten Scherler schrieb: On Thu, 2009-09-03 at 13:23 +0200, Reinhard Pötz wrote: Thorsten Scherler wrote: Hi all, our site is based on different blocks and one main webapp (cocoon-22-archetype-webapp). The problem we are facing is that developing within blocks is really rapid thanks to the rcl but all the code we have in the webapp needs to have a constant rebuild, which is a real pain. http://cocoon.apache.org/2.2/maven-plugins/maven-plugin/1.0/1358_1_1.html Is talking about the goals that are doing the rcl stuff, how can we port this to the webapp? Any hints and tips are welcome. Why do you have to put Java code into the webapp at all? Not talking about the java code that is the bad thing. I am talking about normal xsl/sitemap changes. :( I use the webapp only as a container for the blocks, it doesn't contain any code at all. There is a welcome block which is mounted at / as an entry point. Definitely a clean workaround. ;) How do you deal with the fact that the mount does not provide a pass-trough attribute anymore? I mean in 2.1 I can mount different maps which are looked into and if no match can be found there they are coming back to the parent sitemap and look for the next mount/match. That is a problem that we face in forrest with the switch to 2.2. That's an unsolved problem with the servlet-service framework. It wouldn't be too difficult to add pass-through support per se but the problem is the order of sitemap servlets that are mounted to the _same_ path. I see two options: One is introducing an order attribute (similar to the order attribute of Spring AOP), the other option is making the behavior deterministic by sorting the servlets, that point to the same mount path, alphabetically by their bean names. Thanks Reinhard for the pin-down. The second option would need no maintaining of the order attribute since we sort automatic the bean names, however using the same approach as the Spring AOP brings some standard approach that is easy to explain. Not really sure what to vote for. The ordering of servlets would have the same behavior like the properties files meaning something known for a 2.2 user. That works quite well, but the class loader incompatibilities (e.g. for session attributes) are still a real PITA (cannot cast class Foo to Foo) :( How did you worked around that? You can put all your problematic classes (classes that are kept in the session, proxied interfaces/classes) into a separate module which is not loaded by the RCL. Jeje, maybe directly in the webapp (to come back to the topic). ;) Thanks for your feedback Reinhard. 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: rapid application development with rcl
Thorsten Scherler wrote:
On Thu, 2009-09-03 at 15:29 +0200, Andreas Hartmann wrote:
Thorsten Scherler schrieb:
On Thu, 2009-09-03 at 13:23 +0200, Reinhard Pötz wrote:
Thorsten Scherler wrote:
Hi all,
our site is based on different blocks and one main webapp
(cocoon-22-archetype-webapp).
The problem we are facing is that developing within blocks is really
rapid thanks to the rcl but all the code we have in the webapp needs to
have a constant rebuild, which is a real pain.
http://cocoon.apache.org/2.2/maven-plugins/maven-plugin/1.0/1358_1_1.html
Is talking about the goals that are doing the rcl stuff, how can we
port this to the webapp?
Any hints and tips are welcome.
Why do you have to put Java code into the webapp at all?
Not talking about the java code that is the bad thing. I am talking
about normal xsl/sitemap changes. :(
I use the webapp only as a container for the blocks, it doesn't contain
any code at all. There is a welcome block which is mounted at / as an
entry point.
Definitely a clean workaround. ;) How do you deal with the fact that the
mount does not provide a pass-trough attribute anymore? I mean in 2.1 I
can mount different maps which are looked into and if no match can be
found there they are coming back to the parent sitemap and look for the
next mount/match. That is a problem that we face in forrest with the
switch to 2.2.
That's an unsolved problem with the servlet-service framework. It
wouldn't be too difficult to add pass-through support per se but the
problem is the order of sitemap servlets that are mounted to the _same_
path. I see two options: One is introducing an order attribute (similar
to the order attribute of Spring AOP), the other option is making the
behavior deterministic by sorting the servlets, that point to the same
mount path, alphabetically by their bean names.
That works quite well, but the class loader incompatibilities (e.g. for
session attributes) are still a real PITA (cannot cast class Foo to Foo) :(
How did you worked around that?
You can put all your problematic classes (classes that are kept in the
session, proxied interfaces/classes) into a separate module which is not
loaded by the RCL.
--
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: rapid application development with rcl
Thorsten Scherler wrote:
On Fri, 2009-09-04 at 12:06 +0200, Reinhard Pötz wrote:
Thorsten Scherler wrote:
On Thu, 2009-09-03 at 15:29 +0200, Andreas Hartmann wrote:
Thorsten Scherler schrieb:
On Thu, 2009-09-03 at 13:23 +0200, Reinhard Pötz wrote:
Thorsten Scherler wrote:
Hi all,
our site is based on different blocks and one main webapp
(cocoon-22-archetype-webapp).
The problem we are facing is that developing within blocks is really
rapid thanks to the rcl but all the code we have in the webapp needs to
have a constant rebuild, which is a real pain.
http://cocoon.apache.org/2.2/maven-plugins/maven-plugin/1.0/1358_1_1.html
Is talking about the goals that are doing the rcl stuff, how can we
port this to the webapp?
Any hints and tips are welcome.
Why do you have to put Java code into the webapp at all?
Not talking about the java code that is the bad thing. I am talking
about normal xsl/sitemap changes. :(
I use the webapp only as a container for the blocks, it doesn't contain
any code at all. There is a welcome block which is mounted at / as an
entry point.
Definitely a clean workaround. ;) How do you deal with the fact that the
mount does not provide a pass-trough attribute anymore? I mean in 2.1 I
can mount different maps which are looked into and if no match can be
found there they are coming back to the parent sitemap and look for the
next mount/match. That is a problem that we face in forrest with the
switch to 2.2.
That's an unsolved problem with the servlet-service framework. It
wouldn't be too difficult to add pass-through support per se but the
problem is the order of sitemap servlets that are mounted to the _same_
path. I see two options: One is introducing an order attribute (similar
to the order attribute of Spring AOP), the other option is making the
behavior deterministic by sorting the servlets, that point to the same
mount path, alphabetically by their bean names.
Thanks Reinhard for the pin-down. The second option would need no
maintaining of the order attribute since we sort automatic the bean
names, however using the same approach as the Spring AOP brings some
standard approach that is easy to explain.
Not really sure what to vote for. The ordering of servlets would have
the same behavior like the properties files meaning something known for
a 2.2 user.
This could be the default behavior, using the order attribute could be
optional.
That works quite well, but the class loader incompatibilities (e.g. for
session attributes) are still a real PITA (cannot cast class Foo to Foo) :(
How did you worked around that?
You can put all your problematic classes (classes that are kept in the
session, proxied interfaces/classes) into a separate module which is not
loaded by the RCL.
Jeje, maybe directly in the webapp (to come back to the topic). ;)
Thanks for your feedback Reinhard.
Probably not because this would introduce a cyclic reference if a block
module depends on the webapp module.
--
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
[jira] Closed: (COCOON3-39) Cocoon-monitoring cache overview
[ https://issues.apache.org/jira/browse/COCOON3-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Reinhard Poetz closed COCOON3-39. - Resolution: Fixed Patch applied Cocoon-monitoring cache overview Key: COCOON3-39 URL: https://issues.apache.org/jira/browse/COCOON3-39 Project: Cocoon 3 Issue Type: New Feature Components: cocoon-monitoring Reporter: Dariusz Łuksza Assignee: Reinhard Poetz Fix For: 3.0.0-alpha-2 Attachments: cache-overview-all.patch, cache-overview-all2.patch, cache-overview-doc.patch, cache-overview-part1.patch, cache-overview-part2-burst-actions.patch, cache-overview-part3-cache-entrys.patch This milestone of my GSoC project I'll divide in to thee smaller tasks: 1. General overview of configured caches with base functions like: - clearing whole cache - getting list of cached keys - removing single key from cache - getting size of cache 2. Getting list of all CacheKey's and expose them in some kind of logical order on JXM tree 3. Add additional operation and information to every CacheKey like: - clearing cache value - editing cache value - reloading cache value - getting time of creation - getting expires time, if any -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
