[SOLVED] Re: Trunk Broken
Carsten Ziegeler schrieb: > Sorry, that's my fault - I thought the wsrp block was excluded... > I'll fix this asap. > > That was it, works again. Thanks Carsten
Re: Trunk Broken
Sorry, that's my fault - I thought the wsrp block was excluded... I'll fix this asap. Carsten Daniel Fagerstrom wrote: > Felix Knecht skrev: > Can't build the trunk with allblocks. > Did I missed something? > >> I had the same problem yesterday. It remained after having cleaned the >> local maven repository for Cocoon artifacts. When loading it into >> Eclipse it seemed like there where a lot of missing dependencies. > >> /Daniel > INFO] Compiling 29 source files to > /home/felix/svn/apache/cocoon/trunk/blocks/cocoon-portal/cocoon-portal-wsrp-impl/target/classes > > [INFO] > - > > [ERROR] BUILD FAILURE > [INFO] > - > > [INFO] Compilation failure > > /home/felix/svn/apache/cocoon/trunk/blocks/cocoon-portal/cocoon-portal-wsrp-impl/src/main/java/org/apache/cocoon/portal/wsrp/adapter/WSRPAdapter.java:[45,47] > > cannot find symbol > symbol : class EncodingSerializer > location: package org.apache.cocoon.components.serializers > > /home/felix/svn/apache/cocoon/trunk/blocks/cocoon-portal/cocoon-portal-wsrp-impl/src/main/java/org/apache/cocoon/portal/wsrp/adapter/WSRPAdapter.java:[370,16] > > cannot find symbol > symbol : variable EncodingSerializer > location: class org.apache.cocoon.portal.wsrp.adapter.WSRPAdapter > > > Regards > Felix >> -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Trunk Broken
Felix Knecht skrev: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Can't build the trunk with allblocks. Did I missed something? I had the same problem yesterday. It remained after having cleaned the local maven repository for Cocoon artifacts. When loading it into Eclipse it seemed like there where a lot of missing dependencies. /Daniel INFO] Compiling 29 source files to /home/felix/svn/apache/cocoon/trunk/blocks/cocoon-portal/cocoon-portal-wsrp-impl/target/classes [INFO] - [ERROR] BUILD FAILURE [INFO] - [INFO] Compilation failure /home/felix/svn/apache/cocoon/trunk/blocks/cocoon-portal/cocoon-portal-wsrp-impl/src/main/java/org/apache/cocoon/portal/wsrp/adapter/WSRPAdapter.java:[45,47] cannot find symbol symbol : class EncodingSerializer location: package org.apache.cocoon.components.serializers /home/felix/svn/apache/cocoon/trunk/blocks/cocoon-portal/cocoon-portal-wsrp-impl/src/main/java/org/apache/cocoon/portal/wsrp/adapter/WSRPAdapter.java:[370,16] cannot find symbol symbol : variable EncodingSerializer location: class org.apache.cocoon.portal.wsrp.adapter.WSRPAdapter Regards Felix -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGwAgt2lZVCB08qHERAsnJAJ9vN0MlfZor0AEhzZ15EhD6e+1DdACg0v0Z 4pSEgfk9UTFt1QrYWejH+vk= =CY1V -END PGP SIGNATURE-
Trunk Broken
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Can't build the trunk with allblocks. Did I missed something? INFO] Compiling 29 source files to /home/felix/svn/apache/cocoon/trunk/blocks/cocoon-portal/cocoon-portal-wsrp-impl/target/classes [INFO] - [ERROR] BUILD FAILURE [INFO] - [INFO] Compilation failure /home/felix/svn/apache/cocoon/trunk/blocks/cocoon-portal/cocoon-portal-wsrp-impl/src/main/java/org/apache/cocoon/portal/wsrp/adapter/WSRPAdapter.java:[45,47] cannot find symbol symbol : class EncodingSerializer location: package org.apache.cocoon.components.serializers /home/felix/svn/apache/cocoon/trunk/blocks/cocoon-portal/cocoon-portal-wsrp-impl/src/main/java/org/apache/cocoon/portal/wsrp/adapter/WSRPAdapter.java:[370,16] cannot find symbol symbol : variable EncodingSerializer location: class org.apache.cocoon.portal.wsrp.adapter.WSRPAdapter Regards Felix -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGwAgt2lZVCB08qHERAsnJAJ9vN0MlfZor0AEhzZ15EhD6e+1DdACg0v0Z 4pSEgfk9UTFt1QrYWejH+vk= =CY1V -END PGP SIGNATURE-
Re: Trunk Broken, Re: [jira] Commented: (COCOON-2079) Parser error when launching webapp with jetty
Grzegorz Kossakowski wrote: Vadim Gritsenko pisze: Grzegorz Kossakowski (JIRA) wrote: Grzegorz Kossakowski commented on COCOON-2079: -- The most simple solution was to exclude pull-parser from scratchpad's dependencies and it was exactly what I have done in r563174. Could someone check if trunk works now? Vadim? Sorry... Does not work: [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /Users/vgritsenko/Projects/Apache/cocoon/core/cocoon-expression-language/cocoon-expression-language-impl/src/main/java/org/apache/cocoon/components/expression/jxpath/JXPathExpression.java:[27,37] package org.apache.cocoon.util.jxpath does not exist It was missing dependency on cocoon-sitemap-impl, sorry for inconvenience. Fixed in r563852. Still does not build, but I don't get why - there is a dependency on cocoon-expression-language-api, that should be enough, isn't it? [INFO] Compiling 79 source files to /Users/vgritsenko/Projects/Apache/cocoon/blocks/cocoon-template/cocoon-template-impl/target/classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /Users/vgritsenko/Projects/Apache/cocoon/blocks/cocoon-template/cocoon-template-impl/src/main/java/org/apache/cocoon/template/expression/JXTExpression.java:[22,54] package org.apache.cocoon.components.expression.jxpath does not exist /Users/vgritsenko/Projects/Apache/cocoon/blocks/cocoon-template/cocoon-template-impl/src/main/java/org/apache/cocoon/template/instruction/Import.java:[24,37] cannot find symbol symbol : class ObjectModelImpl location: package org.apache.cocoon.objectmodel /Users/vgritsenko/Projects/Apache/cocoon/blocks/cocoon-template/cocoon-template-impl/src/main/java/org/apache/cocoon/template/JXTemplateGenerator.java:[33,46] cannot find symbol symbol : class FlowObjectModelHelper location: package org.apache.cocoon.template.environment /Users/vgritsenko/Projects/Apache/cocoon/blocks/cocoon-template/cocoon-template-impl/src/main/java/org/apache/cocoon/template/expression/JXTExpression.java:[145,62] cannot find symbol symbol : variable JXPathExpression location: class org.apache.cocoon.template.expression.JXTExpression /Users/vgritsenko/Projects/Apache/cocoon/blocks/cocoon-template/cocoon-template-impl/src/main/java/org/apache/cocoon/template/JXTemplateGenerator.java:[146,8] cannot find symbol symbol : variable FlowObjectModelHelper location: class org.apache.cocoon.template.JXTemplateGenerator Vadim
Trunk Status, Re: Trunk Broken, Re: [jira] Commented: (COCOON-2079) Parser error when launching webapp with jetty
Ok with lots of help from Grzegorz, trunk now can be built *if you skip tests*. There is still issue of three copies of XML APIs in WEB-INF/lib: xml-apis-1.3.02.jar xmlParserAPIs-2.0.2.jar xmlParserAPIs-2.6.2.jar And exceptions from deli: java.lang.NullPointerException at com.hp.hpl.deli.Workspace.getResource(Workspace.java:436) at org.apache.cocoon.components.deli.DeliImpl.initialize(DeliImpl.java:117) But it starts and sorta works. Vadim
Re: Trunk Broken, Re: [jira] Commented: (COCOON-2079) Parser error when launching webapp with jetty
Vadim Gritsenko wrote: Grzegorz Kossakowski wrote: Vadim Gritsenko pisze: Grzegorz Kossakowski wrote: Vadim Gritsenko pisze: It was missing dependency on cocoon-sitemap-impl, sorry for inconvenience. Fixed in r563852. Still does not build, but I don't get why - there is a dependency on cocoon-expression-language-api, that should be enough, isn't it? Unfortunately not. Template generator uses helper class from cocoon-expression-language-impl. I fixed this problem and threw out my crappy, customized build of Maven that did not inform me about this problems and compiled everything without moaning. Now I tested it with standard Maven 2.0.6 and it works well. I got further this time: [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. [INFO] How were you able to build it? :) Skipping tests did not help... Today's probably not the best day to attempt building Cocoon... [INFO] Compiling 3 source files to /Users/vgritsenko/Projects/Apache/cocoon/blocks/cocoon-serializers/cocoon-serializers-impl/target/classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /Users/vgritsenko/Projects/Apache/cocoon/blocks/cocoon-serializers/cocoon-serializers-impl/src/main/java/org/apache/cocoon/components/serializers/XHTMLSerializer.java:[23,26] package javax.servlet.http does not exist /Users/vgritsenko/Projects/Apache/cocoon/blocks/cocoon-serializers/cocoon-serializers-impl/src/main/java/org/apache/cocoon/components/serializers/HTMLSerializer.java:[23,26] package javax.servlet.http does not exist /Users/vgritsenko/Projects/Apache/cocoon/blocks/cocoon-serializers/cocoon-serializers-impl/src/main/java/org/apache/cocoon/components/serializers/XHTMLSerializer.java:[80,20] cannot find symbol symbol : class HttpServletRequest location: class org.apache.cocoon.components.serializers.XHTMLSerializer /Users/vgritsenko/Projects/Apache/cocoon/blocks/cocoon-serializers/cocoon-serializers-impl/src/main/java/org/apache/cocoon/components/serializers/HTMLSerializer.java:[75,20] cannot find symbol symbol : class HttpServletRequest location: class org.apache.cocoon.components.serializers.HTMLSerializer /Users/vgritsenko/Projects/Apache/cocoon/blocks/cocoon-serializers/cocoon-serializers-impl/src/main/java/org/apache/cocoon/components/serializers/XMLSerializer.java:[58,20] cannot find symbol symbol : class HttpServletRequest location: class org.apache.cocoon.components.serializers.XMLSerializer Vadim
Re: Trunk Broken, Re: [jira] Commented: (COCOON-2079) Parser error when launching webapp with jetty
Grzegorz Kossakowski wrote: Vadim Gritsenko pisze: Grzegorz Kossakowski wrote: Vadim Gritsenko pisze: It was missing dependency on cocoon-sitemap-impl, sorry for inconvenience. Fixed in r563852. Still does not build, but I don't get why - there is a dependency on cocoon-expression-language-api, that should be enough, isn't it? Unfortunately not. Template generator uses helper class from cocoon-expression-language-impl. I fixed this problem and threw out my crappy, customized build of Maven that did not inform me about this problems and compiled everything without moaning. Now I tested it with standard Maven 2.0.6 and it works well. I got further this time: [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. [INFO] How were you able to build it? :) Vadim
Re: Trunk Broken, Re: [jira] Commented: (COCOON-2079) Parser error when launching webapp with jetty
Vadim Gritsenko pisze: Grzegorz Kossakowski wrote: Vadim Gritsenko pisze: It was missing dependency on cocoon-sitemap-impl, sorry for inconvenience. Fixed in r563852. Still does not build, but I don't get why - there is a dependency on cocoon-expression-language-api, that should be enough, isn't it? Unfortunately not. Template generator uses helper class from cocoon-expression-language-impl. I fixed this problem and threw out my crappy, customized build of Maven that did not inform me about this problems and compiled everything without moaning. Now I tested it with standard Maven 2.0.6 and it works well. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: Trunk Broken, Re: [jira] Commented: (COCOON-2079) Parser error when launching webapp with jetty
Grzegorz Kossakowski wrote: Vadim Gritsenko pisze: Grzegorz Kossakowski (JIRA) wrote: Grzegorz Kossakowski commented on COCOON-2079: -- The most simple solution was to exclude pull-parser from scratchpad's dependencies and it was exactly what I have done in r563174. Could someone check if trunk works now? Vadim? Sorry... Does not work: [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /Users/vgritsenko/Projects/Apache/cocoon/core/cocoon-expression-language/cocoon-expression-language-impl/src/main/java/org/apache/cocoon/components/expression/jxpath/JXPathExpression.java:[27,37] package org.apache.cocoon.util.jxpath does not exist It was missing dependency on cocoon-sitemap-impl, sorry for inconvenience. Fixed in r563852. Still does not build, but I don't get why - there is a dependency on cocoon-expression-language-api, that should be enough, isn't it? [INFO] Compiling 79 source files to /Users/vgritsenko/Projects/Apache/cocoon/blocks/cocoon-template/cocoon-template-impl/target/classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /Users/vgritsenko/Projects/Apache/cocoon/blocks/cocoon-template/cocoon-template-impl/src/main/java/org/apache/cocoon/template/expression/JXTExpression.java:[22,54] package org.apache.cocoon.components.expression.jxpath does not exist /Users/vgritsenko/Projects/Apache/cocoon/blocks/cocoon-template/cocoon-template-impl/src/main/java/org/apache/cocoon/template/instruction/Import.java:[24,37] cannot find symbol symbol : class ObjectModelImpl location: package org.apache.cocoon.objectmodel /Users/vgritsenko/Projects/Apache/cocoon/blocks/cocoon-template/cocoon-template-impl/src/main/java/org/apache/cocoon/template/JXTemplateGenerator.java:[33,46] cannot find symbol symbol : class FlowObjectModelHelper location: package org.apache.cocoon.template.environment /Users/vgritsenko/Projects/Apache/cocoon/blocks/cocoon-template/cocoon-template-impl/src/main/java/org/apache/cocoon/template/expression/JXTExpression.java:[145,62] cannot find symbol symbol : variable JXPathExpression location: class org.apache.cocoon.template.expression.JXTExpression /Users/vgritsenko/Projects/Apache/cocoon/blocks/cocoon-template/cocoon-template-impl/src/main/java/org/apache/cocoon/template/JXTemplateGenerator.java:[146,8] cannot find symbol symbol : variable FlowObjectModelHelper location: class org.apache.cocoon.template.JXTemplateGenerator Vadim
Re: Trunk Broken, Re: [jira] Commented: (COCOON-2079) Parser error when launching webapp with jetty
Vadim Gritsenko pisze: Grzegorz Kossakowski (JIRA) wrote: Grzegorz Kossakowski commented on COCOON-2079: -- The most simple solution was to exclude pull-parser from scratchpad's dependencies and it was exactly what I have done in r563174. Could someone check if trunk works now? Vadim? Sorry... Does not work: [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /Users/vgritsenko/Projects/Apache/cocoon/core/cocoon-expression-language/cocoon-expression-language-impl/src/main/java/org/apache/cocoon/components/expression/jxpath/JXPathExpression.java:[27,37] package org.apache.cocoon.util.jxpath does not exist It was missing dependency on cocoon-sitemap-impl, sorry for inconvenience. Fixed in r563852. The question remains: Why Continuum does not inform us about such situations? Why e-mail are not sent? -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Trunk Broken, Re: [jira] Commented: (COCOON-2079) Parser error when launching webapp with jetty
Grzegorz Kossakowski (JIRA) wrote: Grzegorz Kossakowski commented on COCOON-2079: -- The most simple solution was to exclude pull-parser from scratchpad's dependencies and it was exactly what I have done in r563174. Could someone check if trunk works now? Vadim? Sorry... Does not work: [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /Users/vgritsenko/Projects/Apache/cocoon/core/cocoon-expression-language/cocoon-expression-language-impl/src/main/java/org/apache/cocoon/components/expression/jxpath/JXPathExpression.java:[27,37] package org.apache.cocoon.util.jxpath does not exist /Users/vgritsenko/Projects/Apache/cocoon/core/cocoon-expression-language/cocoon-expression-language-impl/src/main/java/org/apache/cocoon/objectmodel/provider/CocoonEntryObjectModelProvider.java:[26,36] package org.apache.cocoon.processing does not exist /Users/vgritsenko/Projects/Apache/cocoon/core/cocoon-expression-language/cocoon-expression-language-impl/src/main/java/org/apache/cocoon/objectmodel/provider/CocoonEntryObjectModelProvider.java:[37,12] cannot find symbol symbol : class ProcessInfoProvider location: class org.apache.cocoon.objectmodel.provider.CocoonEntryObjectModelProvider /Users/vgritsenko/Projects/Apache/cocoon/core/cocoon-expression-language/cocoon-expression-language-impl/src/main/java/org/apache/cocoon/objectmodel/provider/CocoonEntryObjectModelProvider.java:[47,11] cannot find symbol symbol : class ProcessInfoProvider location: class org.apache.cocoon.objectmodel.provider.CocoonEntryObjectModelProvider /Users/vgritsenko/Projects/Apache/cocoon/core/cocoon-expression-language/cocoon-expression-language-impl/src/main/java/org/apache/cocoon/objectmodel/provider/CocoonEntryObjectModelProvider.java:[51,39] cannot find symbol symbol : class ProcessInfoProvider location: class org.apache.cocoon.objectmodel.provider.CocoonEntryObjectModelProvider /Users/vgritsenko/Projects/Apache/cocoon/core/cocoon-expression-language/cocoon-expression-language-impl/src/main/java/org/apache/cocoon/components/expression/jxpath/JXPathExpression.java:[140,53] cannot find symbol symbol : class NamespacesTablePointer location: class org.apache.cocoon.components.expression.jxpath.JXPathExpression Vadim
Re: svn commit: r552371 - trunk broken, help needed
Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
Grzegorz Kossakowski wrote:
Reinhard, could you give it another try? I'll try to reproduce it on
Windows.
Now I can reproduce the problem. Sorry.
I think that my last commit (r552518) fixes the problem. It was a silly
mistake: JS and JEXL beans where mixed up so initialization was not done
properly.
Test and report if it works for you, please. Thanks!
works again. Thanks!
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: svn commit: r552371 - trunk broken, help needed
Reinhard Poetz pisze: Grzegorz Kossakowski wrote: Reinhard, could you give it another try? I'll try to reproduce it on Windows. Now I can reproduce the problem. Sorry. I think that my last commit (r552518) fixes the problem. It was a silly mistake: JS and JEXL beans where mixed up so initialization was not done properly. Test and report if it works for you, please. Thanks! -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: svn commit: r552371 - trunk broken, help needed
Grzegorz Kossakowski wrote:
[EMAIL PROTECTED] pisze:
Author: gkossakowski
Date: Sun Jul 1 16:13:44 2007
New Revision: 552371
URL: http://svn.apache.org/viewvc?view=rev&rev=552371
Log:
COCOON-2082: Getting rid of Avalon dependencies, it includes:
* conversion JS, JXPath and JEXL compilers to Spring beans
* conversion DefaultExpressionFactory to Spring bean, it collects
language compilers by using bean-map from Spring configurator
As you see, I'm in between of Avalon->Spring conversion process for
expression languages. I have not moved and adjusted tests (thus build
will fail) because I came across very obscure problem.
First of all I would like you to ask to do svn up and mvn clean install
-Dmaven.test.skip=true for trunk, run cocoon-webapp, access
http://localhost:/blocks/cocoon-template-sample/view/caching2
and check if you get following error:
TypeError: Cannot read property "parameters" from undefined (#1)
AFAICS the problem is that we want to support the syntax
cocoon.request.parameters.foo
to access request parameters. For some reason this isn't supported anymore after
your refactorings though I can't see from your commits where this could be
caused. (Well actually I don't have an idea where this feature is implemented at
all.)
I would be grateful for any reports to be sure if it's not a JDK issue
or so. Also, any help with sorting this out is really appreciated
because I'm really out of ideas how to track such a weird problem.
Details below.
After conversion (changes in r552371) ExpressionContext creation is
slightly broken. Take a look at
TemplateObjectModelHelper#getTemplateObjectModel method, the most
interesting fragment is line:
cocoon.put("settings",
(Settings)WebAppContextUtils.getCurrentWebApplicationContext().getBean(Settings.ROLE));
Cocoon object is normal Java's HashMap, so it seems that there should
happen nothing fancy. As you guess, something weird happens, though ;)
More specifically, this put breaks completely cocoon object. Inspection
in debugger of this object shows that before put operation mentioned
above everything looks ok and just after keys of HashMap are getting out
of sync of values (table). In a fact, the table of values contains 3
items (and is lacking request object, that explains an exception) and
keySet contains 4 items (including request). Moreover, if I change key
from "settings" to something else like "test", cocoon object is less
broken (table includes request) but if you iterate the cocoon object you
will never reach the request object.
From using the debugger I came to the conclustion that the cocoon object is
setup correctly (at least for me). I don't see this weird behaviour.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: svn commit: r552371 - trunk broken, help needed
Grzegorz Kossakowski wrote:
Reinhard, could you give it another try? I'll try to reproduce it on
Windows.
Now I can reproduce the problem. Sorry.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: svn commit: r552371 - trunk broken, help needed
Grzegorz Kossakowski pisze: Reinhard Poetz pisze: I'm not sure if it is really a JDK issue. I guess that your setup got messed up by your refactorings. After fixing the compilation error (see my commit) I was able to run the cocoon-template-sample using the webapp produced by the rcl goal (I checked in the configuration) of the Cocoon Maven plugin with Java 5 (1.5.0_11) without a problem. Sorry for compilation problem, I use Java 6 (1.6.0). Make sure that there are no old Java classes that haven't been deleted by SVN (run 'svn stat' on your working copy) and then run 'mvn clean'. As a next step I suggest that you remove all org.apache.cocoon artifacts from your local repository and finally run 'mvn install -Dmaven.test.skip=true'. This should make sure that your classpath doesn't contain any unwanted classes. HTH I tried it few times, even checking classpath and I still get the same error :( I'll try to downgrade my Java version or try it on another machine... I have tried it on my second machine (openSUSE 10.2, Java 1.5.0_8) with clean installation (no Maven repo, fresh cocoon checkout) and got exactly the same error. Reinhard, could you give it another try? I'll try to reproduce it on Windows. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: svn commit: r552371 - trunk broken, help needed
Reinhard Poetz pisze: I'm not sure if it is really a JDK issue. I guess that your setup got messed up by your refactorings. After fixing the compilation error (see my commit) I was able to run the cocoon-template-sample using the webapp produced by the rcl goal (I checked in the configuration) of the Cocoon Maven plugin with Java 5 (1.5.0_11) without a problem. Sorry for compilation problem, I use Java 6 (1.6.0). Make sure that there are no old Java classes that haven't been deleted by SVN (run 'svn stat' on your working copy) and then run 'mvn clean'. As a next step I suggest that you remove all org.apache.cocoon artifacts from your local repository and finally run 'mvn install -Dmaven.test.skip=true'. This should make sure that your classpath doesn't contain any unwanted classes. HTH I tried it few times, even checking classpath and I still get the same error :( I'll try to downgrade my Java version or try it on another machine... -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: trunk broken?
Olivier Billard pisze: Antonio, (all,) FYI, we won the fight, we'll be using 6.0. Yes-s-s :). I still presume that I was not the only one, however there is one less now ! Thanks for saying that. This really convinces me to opt for Java 1.5 as minimal requirement for Cocoon in near future. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: trunk broken?
Antonio, (all,) FYI, we won the fight, we'll be using 6.0. Yes-s-s :). I still presume that I was not the only one, however there is one less now ! -- Oliv_i_er Antonio Gallardo wrote: Oliver, I think we will stay at 1.4 Thank your for your feedback. :) Best Regards, Antonio Gallardo. Olivier Billard escribió: Hello there, This is my humble case :), but we are planning to use Cocoon 2.2, and cannot decide (customer does) on Java version, that is strongly likely to be Java 1.4... Because our Cocoon application will be embedded into a bigger existing software architecture based/tested/deployed on Java 1.4. They are some cases where you cannot do it in another way, unfortunately, Antonio :)... I personally think (in a Cocoon user POV) that this should be planned, announced far before doing this, so users like me can plan for it and decide knowing the consequences.
Re: svn commit: r552371 - trunk broken, help needed
Grzegorz Kossakowski wrote:
[EMAIL PROTECTED] pisze:
Author: gkossakowski
Date: Sun Jul 1 16:13:44 2007
New Revision: 552371
URL: http://svn.apache.org/viewvc?view=rev&rev=552371
Log:
COCOON-2082: Getting rid of Avalon dependencies, it includes:
* conversion JS, JXPath and JEXL compilers to Spring beans
* conversion DefaultExpressionFactory to Spring bean, it collects
language compilers by using bean-map from Spring configurator
As you see, I'm in between of Avalon->Spring conversion process for
expression languages. I have not moved and adjusted tests (thus build
will fail) because I came across very obscure problem.
First of all I would like you to ask to do svn up and mvn clean install
-Dmaven.test.skip=true for trunk, run cocoon-webapp, access
http://localhost:/blocks/cocoon-template-sample/view/caching2
and check if you get following error:
TypeError: Cannot read property "parameters" from undefined (#1)
I would be grateful for any reports to be sure if it's not a JDK issue
or so. Also, any help with sorting this out is really appreciated
because I'm really out of ideas how to track such a weird problem.
Details below.
I'm not sure if it is really a JDK issue. I guess that your setup got messed up
by your refactorings. After fixing the compilation error (see my commit) I was
able to run the cocoon-template-sample using the webapp produced by the rcl goal
(I checked in the configuration) of the Cocoon Maven plugin with Java 5
(1.5.0_11) without a problem.
Make sure that there are no old Java classes that haven't been deleted by SVN
(run 'svn stat' on your working copy) and then run 'mvn clean'. As a next step I
suggest that you remove all org.apache.cocoon artifacts from your local
repository and finally run 'mvn install -Dmaven.test.skip=true'. This should
make sure that your classpath doesn't contain any unwanted classes. HTH
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: svn commit: r552371 - trunk broken, help needed
[EMAIL PROTECTED] pisze:
Author: gkossakowski
Date: Sun Jul 1 16:13:44 2007
New Revision: 552371
URL: http://svn.apache.org/viewvc?view=rev&rev=552371
Log:
COCOON-2082: Getting rid of Avalon dependencies, it includes:
* conversion JS, JXPath and JEXL compilers to Spring beans
* conversion DefaultExpressionFactory to Spring bean, it collects language
compilers by using bean-map from Spring configurator
As you see, I'm in between of Avalon->Spring conversion process for expression languages. I have not moved and adjusted tests (thus build
will fail) because I came across very obscure problem.
First of all I would like you to ask to do svn up and mvn clean install -Dmaven.test.skip=true for trunk, run cocoon-webapp, access
http://localhost:/blocks/cocoon-template-sample/view/caching2
and check if you get following error:
TypeError: Cannot read property "parameters" from undefined (#1)
I would be grateful for any reports to be sure if it's not a JDK issue or so. Also, any help with sorting this out is really appreciated
because I'm really out of ideas how to track such a weird problem. Details below.
After conversion (changes in r552371) ExpressionContext creation is slightly broken. Take a look at
TemplateObjectModelHelper#getTemplateObjectModel method, the most interesting fragment is line:
cocoon.put("settings",
(Settings)WebAppContextUtils.getCurrentWebApplicationContext().getBean(Settings.ROLE));
Cocoon object is normal Java's HashMap, so it seems that there should happen
nothing fancy. As you guess, something weird happens, though ;)
More specifically, this put breaks completely cocoon object. Inspection in debugger of this object shows that before put operation mentioned
above everything looks ok and just after keys of HashMap are getting out of sync of values (table). In a fact, the table of values contains
3 items (and is lacking request object, that explains an exception) and keySet contains 4 items (including request). Moreover, if I change
key from "settings" to something else like "test", cocoon object is less broken (table includes request) but if you iterate the cocoon
object you will never reach the request object.
All of that is really weird for me and I guess I lack enough Java skills to sort that out so I appreciate any help. If this problem is not
fixed soon I'm going to revert my changes to not keep trunk in broken state.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: trunk broken?
On 6/26/07, Joerg Heinicke <[EMAIL PROTECTED]> wrote: On 26.06.2007 17:01, Peter Hunsberger wrote: >> > And what some other people here seem to ignore is the increasing cost >> > for our community to stay behind the rest of the world. >> > >> > And, BTW, what is your take on our Continuum problems? >> >> Daniel, I don't think it makes any sense to discuss this anymore. We >> rate the costs of losing actual users and "stay behind the rest of the >> world" differently. Let's get 2.2 out of the door ... > > Joerg, I think it's a legitimate question. Which serious one that has not been discussed extensively? Cocoon is not the only community/project still supporting Java 1.4. This actually answers both arguments. In more detail: 1. I'd be glad if we were ahead of Spring - which drops 1.3 support only in the upcoming 2.1 release. And the OSGi projects ... Equinox 1.3 (Oct 2006), Knopflerfish 1.2.2, Felix 1.4 ... I get the feeling the success of a community/project is not determined by its minimum JDK requirement. 2. Yes, how do all the other projects do this? How for example does the Maven community/project ensure that they are compatible with JDK 1.4? Joerg, what other projects do is mostly (if not completely) irrelevant to what we do. The questions for our community are twofold: 1) does retaining Java 1.4 compatibility cost us anything? 2) does making Java 1.5 the minimum supported JDK cost us anything? We know there are things we can't do because if 1.4 is the required base. We have absolutely no _real evidence_ that anyone actually requires Java 1.4 compatibility for the 2.2 code base, just a couple people saying "yeah we can't move to Java 1.5" but those same people have never stated they have a solid requirement to move to Cocoon 2.2 that can't be met by staying on Cocoon 2.1. -- Peter Hunsberger
Re: trunk broken?
Joerg Heinicke skrev: On 15.06.2007 09:32, Daniel Fagerstrom wrote: And what some other people here seem to ignore is the increasing cost for our community to stay behind the rest of the world. And, BTW, what is your take on our Continuum problems? Daniel, I don't think it makes any sense to discuss this anymore. Joerg, it will make sense to discuss this issue each time your veto creates an obstacle. And as Java 1.4 grows more and more irrelevant, these discussions will be more and more frequent. We rate the costs of losing actual users and "stay behind the rest of the world" differently. To be more specific: you rate the cost differently from the rest of those who voted. Citing from http://www.apache.org/foundation/voting.html: "To prevent vetos from being used capriciously, they must be accompanied by a technical justification showing why the change is bad (opens a security exposure, negatively affects performance, etc.). A veto without a justification is invalid and has no weight." As your motivation is of non-technical nature, it is clearly a border case. As it is a question about rating different kinds of community costs, each committers unique view add relevant information to the decision. I find it rather arrogant to act if as your particular view is more worth than all the rest of the committers views together. Let's get 2.2 out of the door ... Sure, and one of the obstacles right now is that we don't have any continuous integration testing that makes sure that 2.2 works with Java 1.4. So I repeat my question: what is your take on our Continuum problems? === But the most important reason for me to return to your veto is about community health. This is the first time in the history of the Cocoon-community that I'm aware of, that we have a unresolved veto, where consensus gathering have failed. One of the more important learnings from open source is that the community is far smarter than the individual. While our community have proved to be incredibly robust historically, that could change if we leave core values of our community culture, and start to consider vetos without consensus gathering as something that is OK. /Daniel
Re: trunk broken?
On 26.06.2007 17:01, Peter Hunsberger wrote: > And what some other people here seem to ignore is the increasing cost > for our community to stay behind the rest of the world. > > And, BTW, what is your take on our Continuum problems? Daniel, I don't think it makes any sense to discuss this anymore. We rate the costs of losing actual users and "stay behind the rest of the world" differently. Let's get 2.2 out of the door ... Joerg, I think it's a legitimate question. Which serious one that has not been discussed extensively? Cocoon is not the only community/project still supporting Java 1.4. This actually answers both arguments. In more detail: 1. I'd be glad if we were ahead of Spring - which drops 1.3 support only in the upcoming 2.1 release. And the OSGi projects ... Equinox 1.3 (Oct 2006), Knopflerfish 1.2.2, Felix 1.4 ... I get the feeling the success of a community/project is not determined by its minimum JDK requirement. 2. Yes, how do all the other projects do this? How for example does the Maven community/project ensure that they are compatible with JDK 1.4? Joerg
Re: trunk broken?
On 6/25/07, Joerg Heinicke <[EMAIL PROTECTED]> wrote: On 15.06.2007 09:32, Daniel Fagerstrom wrote: > And what some other people here seem to ignore is the increasing cost > for our community to stay behind the rest of the world. > > And, BTW, what is your take on our Continuum problems? Daniel, I don't think it makes any sense to discuss this anymore. We rate the costs of losing actual users and "stay behind the rest of the world" differently. Let's get 2.2 out of the door ... Joerg, I think it's a legitimate question. We can't hide behind a claim that "some users somewhere need 1.4 compatability" at the expense of ignoring problems other places. In particular, when it's never been shown that anyone who requires Java 1.4 compatability will actually be running Cocoon 2.2 any time in the next 3 years. -- Peter Hunsberger
Re: trunk broken?
On 26.06.2007 01:45, Grzegorz Kossakowski wrote: Joerg, let it be a consensus. However, don't be angry that I'll bring this issue back again shortly after 2.2 is released. :-) I'm not angry about the topic itself or won't be when it is put back onto the table for the next major or minor release beyond 2.2. It's only the way it is discussed ... Joerg
Re: trunk broken?
Joerg Heinicke pisze: On 15.06.2007 09:32, Daniel Fagerstrom wrote: And what some other people here seem to ignore is the increasing cost for our community to stay behind the rest of the world. And, BTW, what is your take on our Continuum problems? Daniel, I don't think it makes any sense to discuss this anymore. We rate the costs of losing actual users and "stay behind the rest of the world" differently. Let's get 2.2 out of the door ... Joerg, let it be a consensus. However, don't be angry that I'll bring this issue back again shortly after 2.2 is released. :-) -- Grzegorz Kossakowki
Re: trunk broken?
On 15.06.2007 09:32, Daniel Fagerstrom wrote: And what some other people here seem to ignore is the increasing cost for our community to stay behind the rest of the world. And, BTW, what is your take on our Continuum problems? Daniel, I don't think it makes any sense to discuss this anymore. We rate the costs of losing actual users and "stay behind the rest of the world" differently. Let's get 2.2 out of the door ... Joerg
Re: trunk broken?
Joerg Heinicke skrev: Well, for what it's worth (which isn't much) I for one am glad Cocoon 2.2 still supports JDK 1.4. It's finally looking like our US datacentre is getting their act together so my team can plan to migrate our sites off Websphere 5.0 (JDK 1.3, and end-of-life'd about 9 months ago!) onto a more recent version. However, the new version that they are willing to support is 6.0, which uses... JDK 1.4 In 2007 the company decided to upgrade to websphere 6.0. It is a product from 2004. Hence I don't believe such cutting-edge technology as cocoon 2.2 is going to be picked up there until it is not 3 years old or so, hence we are talking about year 2010 when the company will plan to move to java 5 and cocoon 2.2. Is this correct? If yes, there is another reason to move to java 5 for cocoon 2.2 now! :) What some people here seem to ignore is the difference between the environment you deploy your application in and the application itself. While you might not influence the environment like in Andrew's case with the data center or a hosting provider you might deploy there everything you like - unless you require more than it is provided. As discussed before, Retroweaver is available for those who are dependent on obsolete infrastructure. And what some other people here seem to ignore is the increasing cost for our community to stay behind the rest of the world. And, BTW, what is your take on our Continuum problems? /Daniel
Re: trunk broken?
Oliver, I think we will stay at 1.4 Thank your for your feedback. :) Best Regards, Antonio Gallardo. Olivier Billard escribió: Hello there, This is my humble case :), but we are planning to use Cocoon 2.2, and cannot decide (customer does) on Java version, that is strongly likely to be Java 1.4... Because our Cocoon application will be embedded into a bigger existing software architecture based/tested/deployed on Java 1.4. They are some cases where you cannot do it in another way, unfortunately, Antonio :)... I personally think (in a Cocoon user POV) that this should be planned, announced far before doing this, so users like me can plan for it and decide knowing the consequences.
Re: trunk broken?
Hello there, This is my humble case :), but we are planning to use Cocoon 2.2, and cannot decide (customer does) on Java version, that is strongly likely to be Java 1.4... Because our Cocoon application will be embedded into a bigger existing software architecture based/tested/deployed on Java 1.4. They are some cases where you cannot do it in another way, unfortunately, Antonio :)... I personally think (in a Cocoon user POV) that this should be planned, announced far before doing this, so users like me can plan for it and decide knowing the consequences. -- Olivier Billard Andrew Stevens wrote: From: [EMAIL PROTECTED] Date: Fri, 8 Jun 2007 17:16:27 +0100 Hi, (thanks for the reminder, Daniel - yes, I'd forgotten about the vote) On 8 Jun 2007, at 00:57, Andrew Stevens wrote: Well, for what it's worth (which isn't much) I for one am glad Cocoon 2.2 still supports JDK 1.4. It's finally looking like our US datacentre is getting their act together so my team can plan to migrate our sites off Websphere 5.0 (JDK 1.3, and end-of-life'd about 9 months ago!) onto a more recent version. However, the new version that they are willing to support is 6.0, which uses... JDK 1.4 Useful feedback indeed Andrew, it's always helpful for us to know what the issues are out there in the real world. Are you using c2.1 or c2.2 at the moment? Currently 2.1, and a couple of versions behind at that. We'll probably be moving to a more recent version in the near future, but whether that's the latest 2.1.x or 2.2 will depend on how stable 2.2 is by that point, and how much effort it is to update our application and existing customised components (including the fins charting components, which I modified a while back to work in Cocoon 2.1.7 & JDK 1.3). Andrew.
Re: trunk broken?
Well, for what it's worth (which isn't much) I for one am glad Cocoon 2.2 still supports JDK 1.4. It's finally looking like our US datacentre is getting their act together so my team can plan to migrate our sites off Websphere 5.0 (JDK 1.3, and end-of-life'd about 9 months ago!) onto a more recent version. However, the new version that they are willing to support is 6.0, which uses... JDK 1.4 In 2007 the company decided to upgrade to websphere 6.0. It is a product from 2004. Hence I don't believe such cutting-edge technology as cocoon 2.2 is going to be picked up there until it is not 3 years old or so, hence we are talking about year 2010 when the company will plan to move to java 5 and cocoon 2.2. Is this correct? If yes, there is another reason to move to java 5 for cocoon 2.2 now! :) What some people here seem to ignore is the difference between the environment you deploy your application in and the application itself. While you might not influence the environment like in Andrew's case with the data center or a hosting provider you might deploy there everything you like - unless you require more than it is provided. Joerg
RE: trunk broken?
> From: [EMAIL PROTECTED] > Date: Fri, 8 Jun 2007 17:16:27 +0100 > > Hi, > > (thanks for the reminder, Daniel - yes, I'd forgotten about the vote) > > On 8 Jun 2007, at 00:57, Andrew Stevens wrote: > > > Well, for what it's worth (which isn't much) I for one am glad > > Cocoon 2.2 still supports JDK 1.4. It's finally looking like our > > US datacentre is getting their act together so my team can plan to > > migrate our sites off Websphere 5.0 (JDK 1.3, and end-of-life'd > > about 9 months ago!) onto a more recent version. However, the new > > version that they are willing to support is 6.0, which uses... JDK 1.4 > > Useful feedback indeed Andrew, it's always helpful for us to know > what the issues are out there in the real world. Are you using c2.1 > or c2.2 at the moment? Currently 2.1, and a couple of versions behind at that. We'll probably be moving to a more recent version in the near future, but whether that's the latest 2.1.x or 2.2 will depend on how stable 2.2 is by that point, and how much effort it is to update our application and existing customised components (including the fins charting components, which I modified a while back to work in Cocoon 2.1.7 & JDK 1.3). Andrew. -- http://pseudoq.sourceforge.net/ Open source java Sudoku _ Feel like a local wherever you go with BackOfMyHand.com http://www.backofmyhand.com
Re: trunk broken?
Hi, (thanks for the reminder, Daniel - yes, I'd forgotten about the vote) On 8 Jun 2007, at 00:57, Andrew Stevens wrote: Well, for what it's worth (which isn't much) I for one am glad Cocoon 2.2 still supports JDK 1.4. It's finally looking like our US datacentre is getting their act together so my team can plan to migrate our sites off Websphere 5.0 (JDK 1.3, and end-of-life'd about 9 months ago!) onto a more recent version. However, the new version that they are willing to support is 6.0, which uses... JDK 1.4 Useful feedback indeed Andrew, it's always helpful for us to know what the issues are out there in the real world. Are you using c2.1 or c2.2 at the moment? Thanks, Andrew. -- Andrew Savory, Managing Director, Sourcesense UK Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.sourcesense.com/
Re: trunk broken?
Andrew Stevens escribió: Date: Thu, 7 Jun 2007 22:37:02 +0200 From: [EMAIL PROTECTED] Antonio Gallardo skrev: Grzegorz Kossakowski escribió: Antonio Gallardo pisze: Grzegorz Kossakowski escribió: Am I missing something, but IIRC cocoon 2.2. should compile and run with java 1.4. Is this correct? Yes, even though it seems that only few souls living in solitude use Java 1.4 these days... Not my case, I am already on 1.6. ;) I asked due the contract with our user base. Perhaps it is time to reconsider this issue before the 2.2 release. For those not remembering, we are waiting for Joerg to retract his veto against switching to Java 1.5. In the meantime the benefit of supporting Java 1.4 decreases each day while the cost of doing so increases ... /Daniel Well, for what it's worth (which isn't much) I for one am glad Cocoon 2.2 still supports JDK 1.4. It's finally looking like our US datacentre is getting their act together so my team can plan to migrate our sites off Websphere 5.0 (JDK 1.3, and end-of-life'd about 9 months ago!) onto a more recent version. However, the new version that they are willing to support is 6.0, which uses... JDK 1.4 In 2007 the company decided to upgrade to websphere 6.0. It is a product from 2004. Hence I don't believe such cutting-edge technology as cocoon 2.2 is going to be picked up there until it is not 3 years old or so, hence we are talking about year 2010 when the company will plan to move to java 5 and cocoon 2.2. Is this correct? If yes, there is another reason to move to java 5 for cocoon 2.2 now! :) We're already being pressured to ditch Cocoon in favour of a proprietary in-house framework (which would be a shame IMO as Cocoon is a much better fit with our XML-based content management system). Without 1.4 support, Cocoon becomes a dead end for us with no upgrade path, which would make it harder to justify continuing with it. Minimal cocoon 2.1 requires java 1.3, but in fact you get more of it with java 1.4, some newer blocks requieres it as the minimal entry java version. Best Regards, Antonio Gallardo. I guess that makes us the few souls living in solitude :-) Andrew.
Re: trunk broken?
Andrew Stevens wrote: For those not remembering, we are waiting for Joerg to retract his veto against switching to Java 1.5. In the meantime the benefit of supporting Java 1.4 decreases each day while the cost of doing so increases ... /Daniel Well, for what it's worth (which isn't much) I for one am glad Cocoon 2.2 still supports JDK 1.4. It's finally looking like our US datacentre is getting their act together so my team can plan to migrate our sites off Websphere 5.0 (JDK 1.3, and end-of-life'd about 9 months ago!) onto a more recent version. However, the new version that they are willing to support is 6.0, which uses... JDK 1.4 Big mistake. The performance improvements between 1.4 and java 5 are pretty significant. java 6 is even better. Our Cocoon has been running in production on 1.4 for quite some time and we are planning to upgrade just for that reason. We're already being pressured to ditch Cocoon in favour of a proprietary in-house framework (which would be a shame IMO as Cocoon is a much better fit with our XML-based content management system). Without 1.4 support, Cocoon becomes a dead end for us with no upgrade path, which would make it harder to justify continuing with it. Hmm. My guess is that in your environment you won't be upgrading to 2.2 anytime soon anyway? The biggest negative I continue to face isn't Cocoon itself, but the lack of any professional support here in the U.S. I guess that makes us the few souls living in solitude :-) Andrew.
RE: trunk broken?
> Date: Thu, 7 Jun 2007 13:22:54 +0200 > From: [EMAIL PROTECTED] > > Andrew Savory pisze: > > Hi, > > > > On 6 Jun 2007, at 23:23, Grzegorz Kossakowski wrote: > > > >> It's notable that Continuum has not informed us about incompatibility > >> because it also runs newer Java version (1.5 AFAIR). > > > > Hmm, perhaps continuum should use the minimum version of java that we > > support? > > We use shared Continuum instance so I fear it will not be that easy. I guess > that INFRA folks will not be happy with the idea downgrading > Java version. > > -- > Grzegorz Kossakowski > http://reflectingonthevicissitudes.wordpress.com/ Maybe you guys should switch to Ant for your builds instead of Maven, then. I have no trouble with our CruiseControl at work running under 1.6 but building the projects with whichever JDK (1.3, 1.4, Sun's or IBM's) they're targetted to run on - it just uses the Ant script generated by Netbeans' project and that forks javac from the chosen active platform :-) *Ducks, runs & hides* Andrew. _ Feel like a local wherever you go with BackOfMyHand.com http://www.backofmyhand.com
RE: trunk broken?
> Date: Thu, 7 Jun 2007 22:37:02 +0200 > From: [EMAIL PROTECTED] > > Antonio Gallardo skrev: > > Grzegorz Kossakowski escribió: > >> Antonio Gallardo pisze: > >>> Grzegorz Kossakowski escribió: > >>> > >>> Am I missing something, but IIRC cocoon 2.2. should compile and run > >>> with java 1.4. Is this correct? > >> > >> Yes, even though it seems that only few souls living in solitude use > >> Java 1.4 these days... > > Not my case, I am already on 1.6. ;) > > > > I asked due the contract with our user base. Perhaps it is time to > > reconsider this issue before the 2.2 release. > > For those not remembering, we are waiting for Joerg to retract his veto > against switching to Java 1.5. > > In the meantime the benefit of supporting Java 1.4 decreases each day > while the cost of doing so increases ... > > /Daniel Well, for what it's worth (which isn't much) I for one am glad Cocoon 2.2 still supports JDK 1.4. It's finally looking like our US datacentre is getting their act together so my team can plan to migrate our sites off Websphere 5.0 (JDK 1.3, and end-of-life'd about 9 months ago!) onto a more recent version. However, the new version that they are willing to support is 6.0, which uses... JDK 1.4 We're already being pressured to ditch Cocoon in favour of a proprietary in-house framework (which would be a shame IMO as Cocoon is a much better fit with our XML-based content management system). Without 1.4 support, Cocoon becomes a dead end for us with no upgrade path, which would make it harder to justify continuing with it. I guess that makes us the few souls living in solitude :-) Andrew. -- http://pseudoq.sourceforge.net/ Open source java Sudoku _ The next generation of MSN Hotmail has arrived - Windows Live Hotmail http://www.newhotmail.co.uk
Re: trunk broken?
Antonio Gallardo skrev: Grzegorz Kossakowski escribió: Antonio Gallardo pisze: Grzegorz Kossakowski escribió: Am I missing something, but IIRC cocoon 2.2. should compile and run with java 1.4. Is this correct? Yes, even though it seems that only few souls living in solitude use Java 1.4 these days... Not my case, I am already on 1.6. ;) I asked due the contract with our user base. Perhaps it is time to reconsider this issue before the 2.2 release. For those not remembering, we are waiting for Joerg to retract his veto against switching to Java 1.5. In the meantime the benefit of supporting Java 1.4 decreases each day while the cost of doing so increases ... /Daniel
Re: trunk broken?
Vadim Gritsenko pisze: I have this great idea for a build system using Ant I'm intrigued... Tell me more?! :-P Don't even try to approach to Pandora's box! :-P -- Grzegorz Kossakowski
Re: trunk broken?
Andrew Savory wrote: Hi, On 7 Jun 2007, at 12:52, Grzegorz Kossakowski wrote: Andrew Savory pisze: Hi, On 7 Jun 2007, at 12:21, Grzegorz Kossakowski wrote: This time it's problem at your side, you use a broken mirror. mirrors.dotsrc.org seems to be not synchronized correctly with repo1.maven.org where xreporter artifacts can be found. Urrgh :-( (insert rant about stupid maven and lack of decent hierarchical mirror system) What do others recommend for a suitable mirror to use? I don't use Maven mirrors, just rely on repo1.maven.org as it seems the only really safe option. In which case, we really need to update the README.txt that recommends using a maven mirror, especially as it explicitly recommends the use of the dotsrc mirror! I have this great idea for a build system using Ant I'm intrigued... Tell me more?! :-P Vadim
Re: trunk broken?
Hi, On 7 Jun 2007, at 12:52, Grzegorz Kossakowski wrote: Andrew Savory pisze: Hi, On 7 Jun 2007, at 12:21, Grzegorz Kossakowski wrote: This time it's problem at your side, you use a broken mirror. mirrors.dotsrc.org seems to be not synchronized correctly with repo1.maven.org where xreporter artifacts can be found. Urrgh :-( (insert rant about stupid maven and lack of decent hierarchical mirror system) What do others recommend for a suitable mirror to use? I don't use Maven mirrors, just rely on repo1.maven.org as it seems the only really safe option. In which case, we really need to update the README.txt that recommends using a maven mirror, especially as it explicitly recommends the use of the dotsrc mirror! I have this great idea for a build system using Ant Meanwhile, I can confirm that trunk now builds again. Thanks, Andrew. -- Andrew Savory, Managing Director, Sourcesense UK Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.sourcesense.com/
Re: trunk broken?
Andrew Savory pisze: Hi, On 7 Jun 2007, at 12:21, Grzegorz Kossakowski wrote: This time it's problem at your side, you use a broken mirror. mirrors.dotsrc.org seems to be not synchronized correctly with repo1.maven.org where xreporter artifacts can be found. Urrgh :-( (insert rant about stupid maven and lack of decent hierarchical mirror system) What do others recommend for a suitable mirror to use? I don't use Maven mirrors, just rely on repo1.maven.org as it seems the only really safe option. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: trunk broken?
Hi, On 7 Jun 2007, at 12:21, Grzegorz Kossakowski wrote: This time it's problem at your side, you use a broken mirror. mirrors.dotsrc.org seems to be not synchronized correctly with repo1.maven.org where xreporter artifacts can be found. Urrgh :-( (insert rant about stupid maven and lack of decent hierarchical mirror system) What do others recommend for a suitable mirror to use? Thanks, Andrew. -- Andrew Savory, Managing Director, Sourcesense UK Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.sourcesense.com/
Re: trunk broken?
Andrew Savory pisze: Hi, On 6 Jun 2007, at 23:23, Grzegorz Kossakowski wrote: It's notable that Continuum has not informed us about incompatibility because it also runs newer Java version (1.5 AFAIR). Hmm, perhaps continuum should use the minimum version of java that we support? We use shared Continuum instance so I fear it will not be that easy. I guess that INFRA folks will not be happy with the idea downgrading Java version. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: trunk broken?
Andrew Savory pisze:
Hi,
On 6 Jun 2007, at 23:52, Grzegorz Kossakowski wrote:
Should be working again. Test, please.
Yes, that particular problem is fixed.
Meanwhile (sorry, don't have time right now to find a fix for the below):
INFO]
[INFO] Building Cocoon Forms Block Implementation
[INFO]task-segment: [install]
[INFO]
[INFO] [enforcer:enforce-once {execution: enforce-maven}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
Downloading:
http://mirrors.dotsrc.org/maven2/org/outerj/xreporter/xreporter-expression/1.2.1.1/xreporter-expression-1.2.1.1.pom
Downloading:
http://mirrors.dotsrc.org/maven2/org/outerj/xreporter/xreporter-grouping/1.2.1.1/xreporter-grouping-1.2.1.1.pom
Downloading:
http://mirrors.dotsrc.org/maven2/org/outerj/xreporter/xreporter-expression/1.2.1.1/xreporter-expression-1.2.1.1.jar
This time it's problem at your side, you use a broken mirror. mirrors.dotsrc.org seems to be not synchronized correctly with repo1.maven.org
where xreporter artifacts can be found.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: trunk broken?
Hi,
On 6 Jun 2007, at 23:52, Grzegorz Kossakowski wrote:
Should be working again. Test, please.
Yes, that particular problem is fixed.
Meanwhile (sorry, don't have time right now to find a fix for the
below):
INFO]
[INFO] Building Cocoon Forms Block Implementation
[INFO]task-segment: [install]
[INFO]
[INFO] [enforcer:enforce-once {execution: enforce-maven}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
Downloading: http://mirrors.dotsrc.org/maven2/org/outerj/xreporter/
xreporter-expression/1.2.1.1/xreporter-expression-1.2.1.1.pom
Downloading: http://mirrors.dotsrc.org/maven2/org/outerj/xreporter/
xreporter-grouping/1.2.1.1/xreporter-grouping-1.2.1.1.pom
Downloading: http://mirrors.dotsrc.org/maven2/org/outerj/xreporter/
xreporter-expression/1.2.1.1/xreporter-expression-1.2.1.1.jar
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
1) org.outerj.xreporter:xreporter-expression:jar:1.2.1.1
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.outerj.xreporter -
DartifactId=xreporter-expression \
-Dversion=1.2.1.1 -Dpackaging=jar -Dfile=/path/to/file
Path to dependency:
1) org.apache.cocoon:cocoon-forms-impl:jar:1.0.0-RC1-SNAPSHOT
2) org.outerj.xreporter:xreporter-expression:jar:1.2.1.1
--
1 required artifact is missing.
for artifact:
org.apache.cocoon:cocoon-forms-impl:jar:1.0.0-RC1-SNAPSHOT
from the specified remote repositories:
central (http://repo1.maven.org/maven2),
apache.snapshots (http://people.apache.org/repo/m2-snapshot-
repository)
How do I get a username/password for continuum? I'd like to find out
why I'm the fortunate one picking up on all these failures rather
than our automated build environment!
Thanks,
Andrew.
--
Andrew Savory, Managing Director, Sourcesense UK
Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135
Web: http://www.sourcesense.com/
Re: trunk broken?
Hi, On 6 Jun 2007, at 23:23, Grzegorz Kossakowski wrote: It's notable that Continuum has not informed us about incompatibility because it also runs newer Java version (1.5 AFAIR). Hmm, perhaps continuum should use the minimum version of java that we support? (Accidents like this aside, I have no problem with using 1.5, but we should make an explicit decision if we're going that way.) Thanks, Andrew. -- Andrew Savory, Managing Director, Sourcesense UK Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.sourcesense.com/
Re: trunk broken?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andrew Savory wrote:
> Hi,
>
> Trying to build Cocoon 2.2 trunk:
>
> rm -rf ~/.m2/repository/org/apache
> mvn clean
> mvn install -Dmaven.test.skip=true -P allblocks
>
> [ snip ]
>
> [INFO]
>
>
> [INFO] Building Cocoon Servlet Service Implementation
> [INFO]task-segment: [install]
> [INFO]
>
>
> [INFO] [enforcer:enforce-once {execution: enforce-maven}]
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:compile]
> [INFO] Compiling 1 source file to
> /Users/savs/Development/svn-apache/cocoon-trunk/core/cocoon-servlet-service/cocoon-servlet-service-impl/target/classes
>
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] Compilation failure
> /Users/savs/Development/svn-apache/cocoon-trunk/core/cocoon-servlet-service/cocoon-servlet-service-impl/src/main/java/org/apache/cocoon/servletservice/DispatcherServlet.java:[100,18]
> cannot resolve symbol
> symbol : method remove ()
> location: class java.lang.ThreadLocal
Oops, my fault. I haven't realized, that the remove method of ThreadLocal was
added since Java 1.5.
I'll fix it right away. Sorry for the inconvenience and thanks for spotting it.
Ciao
>
>
> /Users/savs/Development/svn-apache/cocoon-trunk/core/cocoon-servlet-service/cocoon-servlet-service-impl/src/main/java/org/apache/cocoon/servletservice/DispatcherServlet.java:[100,18]
> cannot resolve symbol
> symbol : method remove ()
> location: class java.lang.ThreadLocal
>
>
>
>
> Thanks,
>
> Andrew.
> --
> Andrew Savory, Managing Director, Sourcesense UK
> Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135
> Web: http://www.sourcesense.com/
>
>
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.4 (GNU/Linux)
iD8DBQFGZ6bNLNdJvZjjVZARAoVZAKDU/WsTB2j404QK2ChxAIGgE2M2PACfbHP9
26bwNZC4NuuZP0jb73dYYyQ=
=EO+L
-END PGP SIGNATURE-
Re: trunk broken?
Andrew Savory pisze: Hi, Trying to build Cocoon 2.2 trunk: rm -rf ~/.m2/repository/org/apache mvn clean mvn install -Dmaven.test.skip=true -P allblocks [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure Should be working again. Test, please. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: trunk broken?
Grzegorz Kossakowski pisze: I'm all for setting Java 1.5 as minimal but it's not my priority to argue on this forever. There are more interesting things to do like fixing COCOON-2066. :-) It's notable that Continuum has not informed us about incompatibility because it also runs newer Java version (1.5 AFAIR). -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: trunk broken?
Antonio Gallardo pisze: Grzegorz Kossakowski escribió: Antonio Gallardo pisze: Grzegorz Kossakowski escribió: Am I missing something, but IIRC cocoon 2.2. should compile and run with java 1.4. Is this correct? Yes, even though it seems that only few souls living in solitude use Java 1.4 these days... Not my case, I am already on 1.6. ;) Me too. It makes these souls even more lonely. ;) I asked due the contract with our user base. Perhaps it is time to reconsider this issue before the 2.2 release. I'm all for setting Java 1.5 as minimal but it's not my priority to argue on this forever. There are more interesting things to do like fixing COCOON-2066. :-) -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: trunk broken?
Grzegorz Kossakowski escribió: Antonio Gallardo pisze: Grzegorz Kossakowski escribió: Am I missing something, but IIRC cocoon 2.2. should compile and run with java 1.4. Is this correct? Yes, even though it seems that only few souls living in solitude use Java 1.4 these days... Not my case, I am already on 1.6. ;) I asked due the contract with our user base. Perhaps it is time to reconsider this issue before the 2.2 release. Best Regards, Antonio Gallardo.
Re: trunk broken?
Antonio Gallardo pisze: Grzegorz Kossakowski escribió: Am I missing something, but IIRC cocoon 2.2. should compile and run with java 1.4. Is this correct? Yes, even though it seems that only few souls living in solitude use Java 1.4 these days... I'm already working on the solution that Daniel described in the COCOON-2066 issue so I hope will not have to bother with Giacomo's code for too long. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: trunk broken?
Grzegorz Kossakowski escribió: Let me guess, you use Java 1.4? In Java 1.4 ThreadLocal does not have remove() method and that's why the build fails. I have no idea how to fix it, though. Am I missing something, but IIRC cocoon 2.2. should compile and run with java 1.4. Is this correct? Best Regards, Antonio Gallardo.
Re: trunk broken?
On 06.06.2007 22:39, Grzegorz Kossakowski wrote: Let me guess, you use Java 1.4? In Java 1.4 ThreadLocal does not have remove() method and that's why the build fails. I have no idea how to fix it, though. set(null)? As long as we have no initialValue() it is easy. Joerg
Re: trunk broken?
Andrew Savory pisze: Hi, Trying to build Cocoon 2.2 trunk: rm -rf ~/.m2/repository/org/apache mvn clean mvn install -Dmaven.test.skip=true -P allblocks [...] /Users/savs/Development/svn-apache/cocoon-trunk/core/cocoon-servlet-service/cocoon-servlet-service-impl/src/main/java/org/apache/cocoon/servletservice/DispatcherServlet.java:[100,18] cannot resolve symbol symbol : method remove () location: class java.lang.ThreadLocal /Users/savs/Development/svn-apache/cocoon-trunk/core/cocoon-servlet-service/cocoon-servlet-service-impl/src/main/java/org/apache/cocoon/servletservice/DispatcherServlet.java:[100,18] cannot resolve symbol symbol : method remove () location: class java.lang.ThreadLocal Let me guess, you use Java 1.4? In Java 1.4 ThreadLocal does not have remove() method and that's why the build fails. I have no idea how to fix it, though. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
trunk broken?
Hi,
Trying to build Cocoon 2.2 trunk:
rm -rf ~/.m2/repository/org/apache
mvn clean
mvn install -Dmaven.test.skip=true -P allblocks
[ snip ]
[INFO]
[INFO] Building Cocoon Servlet Service Implementation
[INFO]task-segment: [install]
[INFO]
[INFO] [enforcer:enforce-once {execution: enforce-maven}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 1 source file to /Users/savs/Development/svn-apache/
cocoon-trunk/core/cocoon-servlet-service/cocoon-servlet-service-impl/
target/classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
/Users/savs/Development/svn-apache/cocoon-trunk/core/cocoon-servlet-
service/cocoon-servlet-service-impl/src/main/java/org/apache/cocoon/
servletservice/DispatcherServlet.java:[100,18] cannot resolve symbol
symbol : method remove ()
location: class java.lang.ThreadLocal
/Users/savs/Development/svn-apache/cocoon-trunk/core/cocoon-servlet-
service/cocoon-servlet-service-impl/src/main/java/org/apache/cocoon/
servletservice/DispatcherServlet.java:[100,18] cannot resolve symbol
symbol : method remove ()
location: class java.lang.ThreadLocal
Thanks,
Andrew.
--
Andrew Savory, Managing Director, Sourcesense UK
Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135
Web: http://www.sourcesense.com/
Re: 2.1 trunk broken? problem with jxtemplate component...
Joern Nettingsmeier wrote: vadim, Vadim Gritsenko wrote: Yes it's a known problem. Please bear with me (us? :), I'll try to fix it as soon as I can... thanks for your quick reply. i rest assured that the problem is in capable hands :) in case it turns out to be a hard problem or you are short on time, Try current branch... Vadim
Re: 2.1 trunk broken? problem with jxtemplate component...
On 05.04.2007 18:09, Joern Nettingsmeier wrote: in case it turns out to be a hard problem or you are short on time, could you tell me at which revision the issue was introduced, so that i can roll back? Information can be found at http://marc.info/?t=11753452452&r=1&w=4. Regards Jörg
Re: 2.1 trunk broken? problem with jxtemplate component...
vadim, Vadim Gritsenko wrote: Yes it's a known problem. Please bear with me (us? :), I'll try to fix it as soon as I can... thanks for your quick reply. i rest assured that the problem is in capable hands :) in case it turns out to be a hard problem or you are short on time, could you tell me at which revision the issue was introduced, so that i can roll back? thanks, jörn
Re: 2.1 trunk broken? problem with jxtemplate component...
Jörn Nettingsmeier wrote: hi everyone! i've just updated my lenya tree, and the servlet engine bails out on startup with this error message: org.apache.avalon.framework.service.ServiceException: Could not find component (key [org.apache.cocoon.template.expression.StringTemplateParser/jxtg]) (Key='org.apache.cocoon.template.expression.StringTemplateParser/jxtg') a quick check shows that this component is declared in lenya's cocoon 2.1.11-dev external, which is why i'm posting here. can anyone reproduce the problem? Yes it's a known problem. Please bear with me (us? :), I'll try to fix it as soon as I can... Vadim
2.1 trunk broken? problem with jxtemplate component...
hi everyone! i've just updated my lenya tree, and the servlet engine bails out on startup with this error message: org.apache.avalon.framework.service.ServiceException: Could not find component (key [org.apache.cocoon.template.expression.StringTemplateParser/jxtg]) (Key='org.apache.cocoon.template.expression.StringTemplateParser/jxtg') a quick check shows that this component is declared in lenya's cocoon 2.1.11-dev external, which is why i'm posting here. can anyone reproduce the problem? the relevant portion of my servlet engine log is attached below. if you want to see the problem for yourself, check out http://lenya.zones.apache.org:. any enlightenment is appreciated :) best, jörn main DEBUG core.manager - ComponentFactory creating new instance of org.apache.cocoon.template.expression.JXTGStringTemplateParser. main DEBUG core.manager - no logger attribute available, using standard logger main DEBUG core.manager - ComponentHandler initialized for: org.apache.cocoon.template.expression.JXTGStringTemplateParser main DEBUG core.manager - Adding org.apache.cocoon.template.expression.JXTGStringTemplateParser for hint [jxtg] main DEBUG core.manager - ComponentFactory creating new instance of org.apache.cocoon.template.expression.DefaultStringTemplateParser. main DEBUG core.manager - no logger attribute available, using standard logger main DEBUG core.manager - ComponentHandler initialized for: org.apache.cocoon.template.expression.DefaultStringTemplateParser main DEBUG core.manager - Adding org.apache.cocoon.template.expression.DefaultStringTemplateParser for hint [default] main DEBUG core.manager - ComponentHandler initialized for: org.apache.cocoon.components.ExtendedComponentSelector main DEBUG core.manager - ComponentFactory creating new instance of org.apache.cocoon.template.script.DefaultScriptManager. main DEBUG core.manager - no logger attribute available, using standard logger main DEBUG core.manager - ComponentFactory creating new instance of org.apache.cocoon.template.script.DefaultInstructionFactory. main DEBUG core.manager - no logger attribute available, using standard logger main DEBUG core.manager - Resolving 'resource://org/apache/cocoon/template/template-instructions.xml' with base 'null' in context 'file:/b uild/lenya-trunk-rework-pubconf/build/lenya/webapp/' main DEBUG core.manager - Resolved to systemID : resource://org/apache/cocoon/template/template-instructions.xml main DEBUG core.manager - Creating source object for resource://org/apache/cocoon/template/template-instructions.xml main DEBUG core.manager - Releasing source object for resource://org/apache/cocoon/template/template-instructions.xml main DEBUG core.manager - ComponentHandler initialized for: org.apache.cocoon.template.script.DefaultInstructionFactory main DEBUG core.manager - Could not find component for role: org.apache.cocoon.template.expression.StringTemplateParser/jxtg main ERROR core.manager - Caught an exception trying to initialize the component handler. org.apache.avalon.framework.service.ServiceException: Could not find component (key [org.apache.cocoon.template.expression.StringTemplateP arser/jxtg]) (Key='org.apache.cocoon.template.expression.StringTemplateParser/jxtg') at org.apache.avalon.framework.service.WrapperServiceManager.lookup(WrapperServiceManager.java:80) at org.apache.cocoon.template.script.DefaultScriptManager.service(DefaultScriptManager.java:68) at org.apache.avalon.framework.container.ContainerUtil.service(ContainerUtil.java:143) at org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(DefaultComponentFactory.java:271) at org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.initialize(ThreadSafeComponentHandler.java:108) at org.apache.avalon.excalibur.component.ExcaliburComponentManager.initialize(ExcaliburComponentManager.java:524) at org.apache.cocoon.components.CocoonComponentManager.initialize(CocoonComponentManager.java:583) at org.apache.avalon.framework.container.ContainerUtil.initialize(ContainerUtil.java:244) at org.apache.cocoon.Cocoon.initialize(Cocoon.java:345) at org.apache.avalon.framework.container.ContainerUtil.initialize(ContainerUtil.java:244) at org.apache.cocoon.servlet.CocoonServlet.createCocoon(CocoonServlet.java:1429) at org.apache.cocoon.servlet.CocoonServlet.init(CocoonServlet.java:499) at org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:383) at org.mortbay.jetty.servlet.ServletHolder.start(ServletHolder.java:243) at org.mortbay.jetty.servlet.ServletHandler.initializeServlets(ServletHandler.java:445) at org.mortbay.jetty.servlet.WebApplicationHandler.initializeServlets(WebApplicationHandler.java:323) at org.mortbay.jetty.servlet.WebApplicationContext.doStart(WebApplicationContext.java:511) at org.mortbay.
Re: Trunk broken?
Well, I created the eclipse project using "mvn eclipse:eclipse". Then I imported it into my workspace (btw, I ony use the webapp now with the SitemapServlet) and configured the Jetty Launcher to use my Jetty 5.1.12 installation (that defaults to Servlet 2.4, too) and set the webapp root to "src/main/webapp". My webapp contains a web.xml file that is set to use 2.4 Servlets. Then I start to debug, jetty starts and I get the error message when accessing "/". On Thursday 28 December 2006 18:25, Reinhard Poetz wrote: > Philipp Zerelles wrote: > > I just created a new webapp and block using the archetypes from trunk and > > I get the same error when using the Jetty-Eclipse-Plugin to run the > > webapp: > > > > java.lang.IllegalStateException: No thread-bound request found: Are you > > referring to request attributes outside of an actual web request? If you > > are actually operating within a web request and still receive this > > message,your code is probably running outside of > > DispatcherServlet/DispatcherPortlet: In this case, use > > RequestContextListener or RequestContextFilter to expose the current > > request. > > > > When I run it using maven, it works without problem. Any idea why it does > > not work with eclipse? > > Are you sure that the web.xml, that is used, contains the listener (or > filter) and is set to version 2.4 as suggested by Jörg and Carsten?
Re: Trunk broken?
Philipp Zerelles wrote:
I just created a new webapp and block using the archetypes from trunk and I
get the same error when using the Jetty-Eclipse-Plugin to run the webapp:
java.lang.IllegalStateException: No thread-bound request found: Are you
referring to request attributes outside of an actual web request? If you are
actually operating within a web request and still receive this message,your
code is probably running outside of DispatcherServlet/DispatcherPortlet: In
this case, use RequestContextListener or RequestContextFilter to expose the
current request.
When I run it using maven, it works without problem. Any idea why it does not
work with eclipse?
Are you sure that the web.xml, that is used, contains the listener (or filter)
and is set to version 2.4 as suggested by Jörg and Carsten?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Trunk broken?
I just created a new webapp and block using the archetypes from trunk and I get the same error when using the Jetty-Eclipse-Plugin to run the webapp: java.lang.IllegalStateException: No thread-bound request found: Are you referring to request attributes outside of an actual web request? If you are actually operating within a web request and still receive this message,your code is probably running outside of DispatcherServlet/DispatcherPortlet: In this case, use RequestContextListener or RequestContextFilter to expose the current request. When I run it using maven, it works without problem. Any idea why it does not work with eclipse? On Thursday 28 December 2006 08:59, Reinhard Poetz wrote: > Carsten Ziegeler wrote: > > Reinhard Poetz wrote: > >> Thanks Carsten and Jörg! After adding the > >> org.springframework.web.filter.RequestContextFilter, the reloading > >> classloader (works like the shielded cl) works for me again. > >> > >> For some reasons the use of the > >> org.springframework.web.context.request.RequestContextListener caused > >> this exception: > >> > >> java.lang.IllegalStateException: No thread-bound request found: Are you > >> referring to request attributes outside of an actual web request? If you > >> are actually operating within a web request and still receive this > >> message,your code is probably running outside of > >> DispatcherServlet/DispatcherPortlet: In this case, use > >> RequestContextListener or RequestContextFilter to expose the current > >> request. > >> > >> Don't know what's wrong here, but I won't investigate further because > >> together with the manipulation of the classloading mechanism like the > >> reloading classloader does, things are often difficult to debug at that > >> level. > > > > I guess you're still using 2.3 of the servlet spec; you have to adjust > > your web.xml in order to use 2.4. Have a look at the sample web.xml in > > the core-webapp module. > > thanks. I forgot that the change of the servlet spec also manifests in the > web.xml and updating the jar is not enough.
Re: Trunk broken?
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Thanks Carsten and Jörg! After adding the
org.springframework.web.filter.RequestContextFilter, the reloading classloader
(works like the shielded cl) works for me again.
For some reasons the use of the
org.springframework.web.context.request.RequestContextListener caused this
exception:
java.lang.IllegalStateException: No thread-bound request found: Are you
referring to request attributes outside of an actual web request? If you are
actually operating within a web request and still receive this message,your code
is probably running outside of DispatcherServlet/DispatcherPortlet: In this
case, use RequestContextListener or RequestContextFilter to expose the current
request.
Don't know what's wrong here, but I won't investigate further because together
with the manipulation of the classloading mechanism like the reloading
classloader does, things are often difficult to debug at that level.
I guess you're still using 2.3 of the servlet spec; you have to adjust
your web.xml in order to use 2.4. Have a look at the sample web.xml in
the core-webapp module.
thanks. I forgot that the change of the servlet spec also manifests in the
web.xml and updating the jar is not enough.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Trunk broken?
Reinhard Poetz wrote: > > Thanks Carsten and Jörg! After adding the > org.springframework.web.filter.RequestContextFilter, the reloading > classloader > (works like the shielded cl) works for me again. > > For some reasons the use of the > org.springframework.web.context.request.RequestContextListener caused this > exception: > > java.lang.IllegalStateException: No thread-bound request found: Are you > referring to request attributes outside of an actual web request? If you are > actually operating within a web request and still receive this message,your > code > is probably running outside of DispatcherServlet/DispatcherPortlet: In this > case, use RequestContextListener or RequestContextFilter to expose the > current > request. > > Don't know what's wrong here, but I won't investigate further because > together > with the manipulation of the classloading mechanism like the reloading > classloader does, things are often difficult to debug at that level. > I guess you're still using 2.3 of the servlet spec; you have to adjust your web.xml in order to use 2.4. Have a look at the sample web.xml in the core-webapp module. HTH Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Trunk broken?
On 27.12.2006 19:05, Reinhard Poetz wrote: I removed our own implementation in favour of Spring's RequestContextHolder. The attributes are used to keep track of poolable components and to release them when the request is finished. Therefore you should add the Spring's request context listener to your web.xml (I added it to web.xml in svn); this listener requires servlet spec 2.4. For some reasons the use of the org.springframework.web.context.request.RequestContextListener caused this exception: java.lang.IllegalStateException: No thread-bound request found: Are you referring to request attributes outside of an actual web request? If you are actually operating within a web request and still receive this message,your code is probably running outside of DispatcherServlet/DispatcherPortlet: In this case, use RequestContextListener or RequestContextFilter to expose the current request. That's the descriptive exception I talked about when RequestContextHolder does actually not hold a RequestAttributes instance. It's caused by the mentioned null check instead of the NPE you got. If you use web.xml as is (the one you committed, [1]) the Listener does not work because of servlet 2.3 while you need 2.4. IIRC we decided to switch to 2.4, so it would be better to change the DTD/schema declaration to 2.4 in that web.xml. Regards Jörg [1] http://svn.apache.org/viewvc/cocoon/trunk/tools/cocoon-rcl/cocoon-rcl-plugin/src/main/resources/org/apache/cocoon/maven/rcl/WEB-INF/web.xml?revision=490547&view=markup&pathrev=490547
Re: Trunk broken?
Carsten Ziegeler wrote:
Joerg Heinicke wrote:
On 27.12.2006 13:48, Reinhard Poetz wrote:
Does anybody else see this error message when he tries to use the latest
snapshot from trunk?
java.lang.NullPointerException
at
org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:50)
Line 50 of the PoolableProxyHandler is
RequestContextHolder.getRequestAttributes().removeAttribute(this.attributeName,
RequestAttributes.SCOPE_REQUEST);
Don't know about Cocoon trunk yet, but if RequestContextHolder is the
one delivered with Spring you need a component setting the
RequestAttributes on the RequestContextHolder. Therefore you can use
RequestContextListener or RequestContextFilter and declare it in web.xml.
Exactly :)
I removed our own implementation in favour of Spring's
RequestContextHolder. The attributes are used to keep track of poolable
components and to release them when the request is finished.
Therefore you should add the Spring's request context listener to your
web.xml (I added it to web.xml in svn); this listener requires servlet
spec 2.4.
Thanks Carsten and Jörg! After adding the
org.springframework.web.filter.RequestContextFilter, the reloading classloader
(works like the shielded cl) works for me again.
For some reasons the use of the
org.springframework.web.context.request.RequestContextListener caused this
exception:
java.lang.IllegalStateException: No thread-bound request found: Are you
referring to request attributes outside of an actual web request? If you are
actually operating within a web request and still receive this message,your code
is probably running outside of DispatcherServlet/DispatcherPortlet: In this
case, use RequestContextListener or RequestContextFilter to expose the current
request.
Don't know what's wrong here, but I won't investigate further because together
with the manipulation of the classloading mechanism like the reloading
classloader does, things are often difficult to debug at that level.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Re: Trunk broken?
Joerg Heinicke schrieb: > On 27.12.2006 14:03, Carsten Ziegeler wrote: > Line 50 of the PoolableProxyHandler is RequestContextHolder.getRequestAttributes().removeAttribute(this.attributeName, RequestAttributes.SCOPE_REQUEST); > >> I removed our own implementation in favour of Spring's >> RequestContextHolder. The attributes are used to keep track of poolable >> components and to release them when the request is finished. >> Therefore you should add the Spring's request context listener to your >> web.xml (I added it to web.xml in svn); this listener requires servlet >> spec 2.4. > > Wouldn't it be better to use > RequestContextHolder.currentRequestAttributes() (instead of > getRequestAttributes()) then? It has an additional null check and fails > early with an IllegalStateException with a quite clear error message. > This prevents NPEs like the one above. > Yes, you're right. I used this approach in the rest of our code (at least I *think* I used it...) :) Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Trunk broken?
On 27.12.2006 14:03, Carsten Ziegeler wrote: Line 50 of the PoolableProxyHandler is RequestContextHolder.getRequestAttributes().removeAttribute(this.attributeName, RequestAttributes.SCOPE_REQUEST); I removed our own implementation in favour of Spring's RequestContextHolder. The attributes are used to keep track of poolable components and to release them when the request is finished. Therefore you should add the Spring's request context listener to your web.xml (I added it to web.xml in svn); this listener requires servlet spec 2.4. Wouldn't it be better to use RequestContextHolder.currentRequestAttributes() (instead of getRequestAttributes()) then? It has an additional null check and fails early with an IllegalStateException with a quite clear error message. This prevents NPEs like the one above. Jörg
Re: Trunk broken?
Joerg Heinicke wrote: > On 27.12.2006 13:48, Reinhard Poetz wrote: > >> Does anybody else see this error message when he tries to use the latest >> snapshot from trunk? >> >> java.lang.NullPointerException >> at >> org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:50) >> >> >> >> Line 50 of the PoolableProxyHandler is >> >> RequestContextHolder.getRequestAttributes().removeAttribute(this.attributeName, >> >> RequestAttributes.SCOPE_REQUEST); > > Don't know about Cocoon trunk yet, but if RequestContextHolder is the > one delivered with Spring you need a component setting the > RequestAttributes on the RequestContextHolder. Therefore you can use > RequestContextListener or RequestContextFilter and declare it in web.xml. > Exactly :) I removed our own implementation in favour of Spring's RequestContextHolder. The attributes are used to keep track of poolable components and to release them when the request is finished. Therefore you should add the Spring's request context listener to your web.xml (I added it to web.xml in svn); this listener requires servlet spec 2.4. Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Trunk broken?
On 27.12.2006 13:48, Reinhard Poetz wrote: Does anybody else see this error message when he tries to use the latest snapshot from trunk? java.lang.NullPointerException at org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:50) Line 50 of the PoolableProxyHandler is RequestContextHolder.getRequestAttributes().removeAttribute(this.attributeName, RequestAttributes.SCOPE_REQUEST); Don't know about Cocoon trunk yet, but if RequestContextHolder is the one delivered with Spring you need a component setting the RequestAttributes on the RequestContextHolder. Therefore you can use RequestContextListener or RequestContextFilter and declare it in web.xml. Jörg
Trunk broken?
Does anybody else see this error message when he tries to use the latest
snapshot from trunk?
java.lang.NullPointerException
at
org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:50)
at $Proxy1.putBackIntoAvalonPool(Unknown Source)
at
org.apache.cocoon.core.container.spring.avalon.AvalonServiceManager.release(AvalonServiceManager.java:73)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.buildConcreteProcessor(TreeProcessor.java:410)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.setupConcreteProcessor(TreeProcessor.java:324)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:232)
at
org.apache.cocoon.servlet.RequestProcessor.process(RequestProcessor.java:328)
at
org.apache.cocoon.servlet.RequestProcessor.service(RequestProcessor.java:155)
at
org.apache.cocoon.sitemap.SitemapServlet.service(SitemapServlet.java:61)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.cocoon.blocks.BlockContext$PathDispatcher.forward(BlockContext.java:461)
at
org.apache.cocoon.blocks.BlockContext$PathDispatcher.forward(BlockContext.java:443)
at org.apache.cocoon.blocks.BlockServlet.service(BlockServlet.java:123)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.cocoon.blocks.DispatcherServlet.service(DispatcherServlet.java:126)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.cocoon.servlet.ReloadingServlet.service(ReloadingServlet.java:93)
Line 50 of the PoolableProxyHandler is
RequestContextHolder.getRequestAttributes().removeAttribute(this.attributeName,
RequestAttributes.SCOPE_REQUEST);
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: svn trunk broken
Vadim Gritsenko wrote: > Hi All, > > Noticed that SVN trunk is broken: > > $ svn proplist . > Properties on '.': > subversion/libsvn_subr/subst.c:643: (apr_err=135000) > svn: Inconsistent line ending style It was like that for me recently too. After doing svn up today, i needed to manually delete some leftover bits from the src/documentation removal, perhaps the svn:externals stuff that was in there. Anyway, trunk is fine for me now. > All commands - proplist, propset, propget - fail with same message. > Examining contents of .svn/dir-props shows mixed line endings. > > I'll try fixing what/if I can - but please make sure your svn client does > not wreak havoc in the repository... I ran the program http://svn.apache.org/repos/private/committers/tools/report_svn_text.pl which shows about 330 problem files. I will gradually tidy up. Yes, please committers see: http://www.apache.org/dev/version-control.html#https-svn Vadim, i recall that you made a Cocoon doc to explain some of this, but i cannot find it now. -David
svn trunk broken
Hi All, Noticed that SVN trunk is broken: $ svn proplist . Properties on '.': subversion/libsvn_subr/subst.c:643: (apr_err=135000) svn: Inconsistent line ending style All commands - proplist, propset, propget - fail with same message. Examining contents of .svn/dir-props shows mixed line endings. I'll try fixing what/if I can - but please make sure your svn client does not wreak havoc in the repository... Vadim
Re: trunk broken ()
Sorry, commited to much. It is gone now. /Daniel Antonio Gallardo wrote: Hi Daniel: In gump.xml there is: What this means? Can you review the changes Daniel? The trunk is broken. Best Regards, Antonio Gallardo
trunk broken ()
Hi Daniel: In gump.xml there is: What this means? Can you review the changes Daniel? The trunk is broken. Best Regards, Antonio Gallardo
