[jira] Closed: (COCOON-2077) XModuleSource getInputStream() throws NPE
[
https://issues.apache.org/jira/browse/COCOON-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jörg Heinicke closed COCOON-2077.
-
Resolution: Fixed
Fix Version/s: 2.2-dev (Current SVN)
2.1.11-dev (Current SVN)
Components must obviously be set up the component framework's way. Otherwise
changes to a component might break the users of the component - as it happened
here for QDoxSource and XModuleSource.
Thanks, Ellis, for reporting the issue and the good analysis which made it
quite easy to fix it. I fixed both QDoxSource and XModuleSource in both 2.1
branch and trunk. Would be fine if you can check the one or the other.
Joerg
> XModuleSource getInputStream() throws NPE
> -
>
> Key: COCOON-2077
> URL: https://issues.apache.org/jira/browse/COCOON-2077
> Project: Cocoon
> Issue Type: Bug
> Components: * Cocoon Core
>Affects Versions: 2.1.9, 2.1.10, 2.1.11-dev (Current SVN), 2.2-dev
> (Current SVN)
>Reporter: Ellis Pritchard
>Assignee: Jörg Heinicke
>Priority: Minor
> Fix For: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN)
>
>
> I'm getting:
> java.lang.NullPointerException
> at
> org.apache.cocoon.serialization.AbstractTextSerializer.getTransformerHandler(AbstractTextSerializer.java:138)
> at
> org.apache.cocoon.serialization.XMLSerializer.setOutputStream(XMLSerializer.java:53)
> at
> org.apache.cocoon.components.source.impl.XModuleSource.getInputStream(XModuleSource.java:196)
> at
> com.researchresearch.cocoon.generation.RESTfulServiceGenerator.doPOSTBody(RESTfulServiceGenerator.java:323)
> at
> com.researchresearch.cocoon.generation.RESTfulServiceGenerator.generate(RESTfulServiceGenerator.java:276)
> at
> org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLPipeline(AbstractProcessingPipeline.java:579)
> at
> org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:780)
> at
> org.apache.cocoon.components.source.impl.SitemapSource.toSAX(SitemapSource.java:414)
> at
> org.apache.cocoon.components.source.SourceUtil.toSAX(SourceUtil.java:101)
> at
> org.apache.cocoon.components.source.SourceUtil.parse(SourceUtil.java:321)
> at
> org.apache.cocoon.sitemap.ContentAggregator.generate(ContentAggregator.java:125)
> ...
> When trying to use an xmodule: as the source for a custom generator.
> [Cocoon BRANCH_2_1_X.]
> Now admittedly, I'm not using it in a pure sitemap way, which would end up
> using the XMLizable interface method, but I'm calling the (equally valid)
> Source method getInputStream() instead.
> The offending code in org.apache.cocoon.components.source.impl.XModuleSource
> seems to be:
> /**
> * Return an InputStream object to read from the source.
> *
> * @throws IOException if I/O error occured.
> */
> // Stolen from QDoxSource
> public InputStream getInputStream() throws IOException, SourceException {
> if ( this.logger.isDebugEnabled() ) {
> this.logger.debug( "Getting InputStream for " + getURI() );
> }
> // Serialize the SAX events to the XMLSerializer:
> XMLSerializer serializer = new XMLSerializer();
> ByteArrayInputStream inputStream = null;
> try {
> ByteArrayOutputStream outputStream = new ByteArrayOutputStream(
> 2048 );
> serializer.setOutputStream( outputStream );
> toSAX( serializer );
> inputStream = new ByteArrayInputStream(
> outputStream.toByteArray() );
> } catch ( SAXException se ) {
> logger.error( "SAX exception!", se );
> throw new SourceException( "Serializing SAX to a ByteArray
> failed!", se );
> }
> return inputStream;
> }
> The serializer is created, but not configure()d, and it is only the
> configuration that sets the TransformerFactory in
> AbstractTextSerializer.java, hence the NPE.
> The causal change seems to have been made to AbstractTextSerializer yonks ago:
> 23784 3/19/03 5:37PM sylvain Allow the TransformerFactory class to
> be specified in the configuration
> Before that revision the TransformerFactory was set in the constructor of
> AbstractTextSerializer, thus it worked with the xmodule getInputStream()
> method before that change.
> No compensating change is in XModuleSource (433543), so this has been broken
> since 2003.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2077) XModuleSource getInputStream() throws NPE
[
https://issues.apache.org/jira/browse/COCOON-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jörg Heinicke reassigned COCOON-2077:
-
Assignee: Jörg Heinicke
> XModuleSource getInputStream() throws NPE
> -
>
> Key: COCOON-2077
> URL: https://issues.apache.org/jira/browse/COCOON-2077
> Project: Cocoon
> Issue Type: Bug
> Components: * Cocoon Core
>Affects Versions: 2.1.9, 2.1.10, 2.1.11-dev (Current SVN), 2.2-dev
> (Current SVN)
>Reporter: Ellis Pritchard
>Assignee: Jörg Heinicke
>Priority: Minor
>
> I'm getting:
> java.lang.NullPointerException
> at
> org.apache.cocoon.serialization.AbstractTextSerializer.getTransformerHandler(AbstractTextSerializer.java:138)
> at
> org.apache.cocoon.serialization.XMLSerializer.setOutputStream(XMLSerializer.java:53)
> at
> org.apache.cocoon.components.source.impl.XModuleSource.getInputStream(XModuleSource.java:196)
> at
> com.researchresearch.cocoon.generation.RESTfulServiceGenerator.doPOSTBody(RESTfulServiceGenerator.java:323)
> at
> com.researchresearch.cocoon.generation.RESTfulServiceGenerator.generate(RESTfulServiceGenerator.java:276)
> at
> org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLPipeline(AbstractProcessingPipeline.java:579)
> at
> org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:780)
> at
> org.apache.cocoon.components.source.impl.SitemapSource.toSAX(SitemapSource.java:414)
> at
> org.apache.cocoon.components.source.SourceUtil.toSAX(SourceUtil.java:101)
> at
> org.apache.cocoon.components.source.SourceUtil.parse(SourceUtil.java:321)
> at
> org.apache.cocoon.sitemap.ContentAggregator.generate(ContentAggregator.java:125)
> ...
> When trying to use an xmodule: as the source for a custom generator.
> [Cocoon BRANCH_2_1_X.]
> Now admittedly, I'm not using it in a pure sitemap way, which would end up
> using the XMLizable interface method, but I'm calling the (equally valid)
> Source method getInputStream() instead.
> The offending code in org.apache.cocoon.components.source.impl.XModuleSource
> seems to be:
> /**
> * Return an InputStream object to read from the source.
> *
> * @throws IOException if I/O error occured.
> */
> // Stolen from QDoxSource
> public InputStream getInputStream() throws IOException, SourceException {
> if ( this.logger.isDebugEnabled() ) {
> this.logger.debug( "Getting InputStream for " + getURI() );
> }
> // Serialize the SAX events to the XMLSerializer:
> XMLSerializer serializer = new XMLSerializer();
> ByteArrayInputStream inputStream = null;
> try {
> ByteArrayOutputStream outputStream = new ByteArrayOutputStream(
> 2048 );
> serializer.setOutputStream( outputStream );
> toSAX( serializer );
> inputStream = new ByteArrayInputStream(
> outputStream.toByteArray() );
> } catch ( SAXException se ) {
> logger.error( "SAX exception!", se );
> throw new SourceException( "Serializing SAX to a ByteArray
> failed!", se );
> }
> return inputStream;
> }
> The serializer is created, but not configure()d, and it is only the
> configuration that sets the TransformerFactory in
> AbstractTextSerializer.java, hence the NPE.
> The causal change seems to have been made to AbstractTextSerializer yonks ago:
> 23784 3/19/03 5:37PM sylvain Allow the TransformerFactory class to
> be specified in the configuration
> Before that revision the TransformerFactory was set in the constructor of
> AbstractTextSerializer, thus it worked with the xmodule getInputStream()
> method before that change.
> No compensating change is in XModuleSource (433543), so this has been broken
> since 2003.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Closed: (COCOON-2079) Parser error when launching webapp with jetty
On 23.06.2007 20:06, Grzegorz Kossakowski wrote: I hope it's not serious enough to stop our release? What do you mean? I hope the fix makes it into the release? Not into RC1 because it's already prepared for release and waits for votes: http://article.gmane.org/gmane.text.xml.cocoon.devel/73707 Reformulating the question: is the fix important enough to stop RC1? No, it should not block RC, but a possible final release. Since it's fixed this does not apply anymore. Joerg
Re: [test] Cocoon 2.2-RC1 & others (take 2)
Hi Grzegorz,
> Component (Spring beans) configurations files can be found at
> src/main/resources/META-INF/cocoon/spring. Before we change id of spring
> bean
> to make it unique we have to rename java class as well. Here are
> instructions (everything should be done in myBlock2 from the tutorial):
> 1. Rename Java class demo.myBean to demo.myBean2. The class can be found
> at src/main/java
> 2. Open
> src/main/resources/META-INF/cocoon/spring/demo-application-context.xml for
> edition and change following part:
>
>
>
> 3. We need to update flowscript code to make it picking up new component.
> Open src/main/resources/COB-INF/flow/spring-bean.js and change
> this line:
> var demoBean = cocoon.getComponent("demo");
> so it looks:
> var demoBean = cocoon.getComponent("demo2");
>
> Run jetty:run from myBlock1 and everything (I hope) should be working.
>
RCL [create]:
/home/xweber/tmp/cocoon/test/myBlock1/./target/classes/demo/MyBean.class
2007-06-23 23:11:02.460:/:INFO: Initializing Spring root
WebApplicationContext
2007-06-23 23:11:03.961::WARN: Failed startup of context
[EMAIL PROTECTED]
...
Caused by: org.springframework.beans.factory.BeanDefinitionStoreException:
Unable to read spring configurations from classpath*:META-INF/cocoon/spring;
nested exception is
org.springframework.beans.factory.parsing.BeanDefinitionParsingException:
Configuration problem: Cannot locate BeanDefinitionDecorator for element
[connections]
...
Caused by:
org.springframework.beans.factory.parsing.BeanDefinitionParsingException:
Configuration problem: Cannot locate BeanDefinitionDecorator for element
[connections]
on the jetty:run step. So browser says:
HTTP ERROR: 503
SERVICE_UNAVAILABLE
RequestURI=/myBlock1/
Powered by jetty://
I even tried it with a clean second dir + attempt to build the steps.
Alex
--
View this message in context:
http://www.nabble.com/-test--Cocoon-2.2-RC1---others-%28take-2%29-tf3965214.html#a11270315
Sent from the Cocoon - Dev mailing list archive at Nabble.com.
RES: RES: [jira] Closed: (COCOON-2079) Parser error when launching webapp with jetty
> > Gustavo N. Fernandes pisze: > > It may not have occurred the past two years, but in this month it has > > occurred 3 times: > > > > > http://www.nabble.com/forum/Search.jtp?query=%22DOCTYPE+declarations+NOT+s > up > > ported%22&local=y&forum=113&daterange=0&startdate=&enddate= > > > > Perhaps the runtime validation was off and is now active? > > Yes, that must be the reason but AFAIR nothing has been changed in Cocoon > related to validation. I suspect it's a change in JDK, what > version do you use? > The error occurred both on 1.5 (linux) and 1.6 (windows). One important change in jdk 1.6 was a shipment of its own pull parser. Perhaps a new version of the pull parser used came thru maven and that version is a bit stricter. Just a though. []s Gustavo No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.472 / Virus Database: 269.9.6/863 - Release Date: 23/6/2007 11:08
Re: RES: [jira] Closed: (COCOON-2079) Parser error when launching webapp with jetty
Gustavo N. Fernandes pisze: It may not have occurred the past two years, but in this month it has occurred 3 times: http://www.nabble.com/forum/Search.jtp?query=%22DOCTYPE+declarations+NOT+sup ported%22&local=y&forum=113&daterange=0&startdate=&enddate= Perhaps the runtime validation was off and is now active? Yes, that must be the reason but AFAIR nothing has been changed in Cocoon related to validation. I suspect it's a change in JDK, what version do you use? -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: [test] Cocoon 2.2-RC1 & others (take 2)
xweber pisze:
Hi Grzegorz,
Grzegorz Kossakowski wrote:
I think you found little trap in our current setup. When two blocks
containing demo classes are connected they define exactly the same
Spring component (same package and same component id) twice. In my setup
this does not lead to exception, just first Java class and last
declaration of component is used. Try to change a class name/package and
Spring Id of the component (don't forget to change in flowscript
too) and everything should be working fine.
Please report if it's the case.
Sure, i would like to test it but unfortunately i have no clue what
files/lines to change. The doc part for this
(http://cocoon.zones.apache.org/daisy/cdocs/g1/g1/g4/1268.html) is near
empty. So I cannot figure what part means "component id". I beg your pardon
for this - i am just starting with cocoon.
Yes, docs needs polishing, I hope we will get more attention on this as soon as
RC1 is released and we are sure that most of the code is stable.
Component (Spring beans) configurations files can be found at src/main/resources/META-INF/cocoon/spring. Before we change id of spring bean
to make it unique we have to rename java class as well. Here are instructions (everything should be done in myBlock2 from the tutorial):
1. Rename Java class demo.myBean to demo.myBean2. The class can be found at
src/main/java
2. Open src/main/resources/META-INF/cocoon/spring/demo-application-context.xml
for edition and change following part:
3. We need to update flowscript code to make it picking up new component. Open src/main/resources/COB-INF/flow/spring-bean.js and change
this line:
var demoBean = cocoon.getComponent("demo");
so it looks:
var demoBean = cocoon.getComponent("demo2");
Run jetty:run from myBlock1 and everything (I hope) should be working.
Grzegorz Kossakowski wrote:
I don't think it's show-stopper for release, we just should put an
information about work-around in docs and fix it in RC2 that would follow
RC1 quickly (I hope you all remember independent release cycles).
Yesterday I have run the examples from a svn build. There have been some
error messages and "dead" pages while clicking through all the links.
Don't hesitate report them. Some of them may be broken because we move samples
to new architecture (servlet-service-fw, docs comming soon).
Haven't tried if a example webapp build is possible with the "to rc1"
released files (i am just a beginner with cocoon - so i would need a little
howto).
e.g. in cocoon-validation-sample's sitemap.xmap is a
type="servletService" "> - count the "
Maybe it's a wanted syntax error for validation to check something.
No, it's typo, it would be commented that it's broken intentionally. I fixed
that, thanks.
If you want i can run through all examples in rc1 and give a more complete
list of problems.
AFAIK you can run in rcl only blocks that are already converted to use servlet-service-fw. If you want to check if it's the case just find
out if file at src/main/resources/META-INF/cocoon/spring/*blockServlet.xml exists. Some blocks are not converted yet, see:
http://thread.gmane.org/gmane.text.xml.cocoon.devel/73643/focus=73661
Any help will be appreciated, of course.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
RES: [jira] Closed: (COCOON-2079) Parser error when launching webapp with jetty
> > Reformulating the question: is the fix important enough to stop RC1? As > people have used trunk for two years not suffering from this problem > I don't think it's show-stopper but I would like to make sure. > > -- It may not have occurred the past two years, but in this month it has occurred 3 times: http://www.nabble.com/forum/Search.jtp?query=%22DOCTYPE+declarations+NOT+sup ported%22&local=y&forum=113&daterange=0&startdate=&enddate= Perhaps the runtime validation was off and is now active? []s Gustavo No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.472 / Virus Database: 269.9.6/863 - Release Date: 23/6/2007 11:08
Re: [test] Cocoon 2.2-RC1 & others (take 2)
Hi Grzegorz, Grzegorz Kossakowski wrote: > > I think you found little trap in our current setup. When two blocks > containing demo classes are connected they define exactly the same > Spring component (same package and same component id) twice. In my setup > this does not lead to exception, just first Java class and last > declaration of component is used. Try to change a class name/package and > Spring Id of the component (don't forget to change in flowscript > too) and everything should be working fine. > Please report if it's the case. > Sure, i would like to test it but unfortunately i have no clue what files/lines to change. The doc part for this (http://cocoon.zones.apache.org/daisy/cdocs/g1/g1/g4/1268.html) is near empty. So I cannot figure what part means "component id". I beg your pardon for this - i am just starting with cocoon. Grzegorz Kossakowski wrote: > > I don't think it's show-stopper for release, we just should put an > information about work-around in docs and fix it in RC2 that would follow > RC1 quickly (I hope you all remember independent release cycles). > Yesterday I have run the examples from a svn build. There have been some error messages and "dead" pages while clicking through all the links. Haven't tried if a example webapp build is possible with the "to rc1" released files (i am just a beginner with cocoon - so i would need a little howto). e.g. in cocoon-validation-sample's sitemap.xmap is a - count the " Maybe it's a wanted syntax error for validation to check something. If you want i can run through all examples in rc1 and give a more complete list of problems. Alex -- View this message in context: http://www.nabble.com/-test--Cocoon-2.2-RC1---others-%28take-2%29-tf3965214.html#a11268794 Sent from the Cocoon - Dev mailing list archive at Nabble.com.
Re: [jira] Closed: (COCOON-2079) Parser error when launching webapp with jetty
Joerg Heinicke pisze: On 23.06.2007 19:40, Grzegorz Kossakowski wrote: I tried my best to reproduce the problem and failed. If it was broken since more than two years why no one noticed it before? My validating XML editor (jEdit + XML plugins) complained exactly about those problems Gustavo's patch fixed. There are some roles declarations in it without @shorthand and @model was added to some of them. No idea why it was never noticed. Is nobody using a validating editor? That one gets the error and another one not at runtime is just some (default) configuration option I guess. I use editor with validation enabled but have never opened this particular file. I was wondering why most of us did not experienced the problem during runtime. If it is up to us I would like to have validation enabled everywhere configuration files are read. To simply avoid such problems. I hope it's not serious enough to stop our release? What do you mean? I hope the fix makes it into the release? Not into RC1 because it's already prepared for release and waits for votes: http://article.gmane.org/gmane.text.xml.cocoon.devel/73707 Reformulating the question: is the fix important enough to stop RC1? As people have used trunk for two years not suffering from this problem I don't think it's show-stopper but I would like to make sure. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: [jira] Closed: (COCOON-2079) Parser error when launching webapp with jetty
On 23.06.2007 19:40, Grzegorz Kossakowski wrote: Jörg Heinicke closed COCOON-2079. - Resolution: Fixed Fix Version/s: 2.2-dev (Current SVN) Funny: This file has been invalid since more than two years ... :) I tried my best to reproduce the problem and failed. If it was broken since more than two years why no one noticed it before? My validating XML editor (jEdit + XML plugins) complained exactly about those problems Gustavo's patch fixed. There are some roles declarations in it without @shorthand and @model was added to some of them. No idea why it was never noticed. Is nobody using a validating editor? That one gets the error and another one not at runtime is just some (default) configuration option I guess. I hope it's not serious enough to stop our release? What do you mean? I hope the fix makes it into the release? Joerg
Re: [jira] Closed: (COCOON-2079) Parser error when launching webapp with jetty
Jörg Heinicke (JIRA) pisze: [ https://issues.apache.org/jira/browse/COCOON-2079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörg Heinicke closed COCOON-2079. - Resolution: Fixed Fix Version/s: 2.2-dev (Current SVN) Funny: This file has been invalid since more than two years ... :) I tried my best to reproduce the problem and failed. If it was broken since more than two years why no one noticed it before? Anyway, it's nice to be fixed. I hope it's not serious enough to stop our release? -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: [test] Cocoon 2.2-RC1 & others (take 2)
xweber pisze: Hi, I tried to follow the tutorials with latest rc1 files. (http://cocoon.zones.apache.org/daisy/cdocs/g2/g2/g1/1291.html) On the connecting example (Connect two blocks) I receive an error like java.lang.RuntimeException: Cannot invoke listener [EMAIL PROTECTED] .. Unable to read spring configurations from classpath .. on mvn jetty:run startup Maybe it is related to the rc1 build. I think you found little trap in our current setup. When two blocks containing demo classes are connected they define exactly the same Spring component (same package and same component id) twice. In my setup this does not lead to exception, just first Java class and last declaration of component is used. Try to change a class name/package and Spring Id of the component (don't forget to change in flowscript too) and everything should be working fine. Please report if it's the case. I don't think it's show-stopper for release, we just should put an information about work-around in docs and fix it in RC2 that would follow RC1 quickly (I hope you all remember independent release cycles). As regards the fix, do you have a good idea how to make demo beans unique? Do you think that appending block's name (artifact Id) is a good idea? Is artifact Id strict enough to not brake name of class? -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: How to import cocoon-forms-sample in a new created block architecture
Jean-Christophe Kermagoret pisze: But block portal works well. The only problem comes from the fact you can't access it directly. I don't see for which reason this may be related to the way forms are managed. Any ideas or pointers ? It's not related to the way forms itself are managed but how forms' block is managed. You can't access portal samples by using /blocks/cocoon-portal-sample because all block/* URLs are handled by DispatcherServlet from servlet-service-fw, see [1]: DispatcherServlet /blocks/* It means that only blocks that are configured (converted) to use servlet-serfice-fw functionality will be available at block/* address. Of course you can still use map:mount construct to mount a cocoon-portal-sample at any location you like as you already tried. It's our goal to have all blocks converted and retain for back-compatibility. I'm going to prepare some docs for servlet-service-fw and will discuss there. I read the thread above and I will update portal block if necessary. I would appreciate your help with conversion process. The other problem is related to dojo-resources param that seems to be absent from the forms-field-styling.xsl. Maybe it is provided through a use-request-parameters alike ? Anyway, by just adding the , it works again. Where do you have to put it? At the top of forms-field-styling.xsl. I will provide a patch. Create an issue on JIRA, thanks. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: [test] Cocoon 2.2-RC1 & others (take 2)
Hi, I tried to follow the tutorials with latest rc1 files. (http://cocoon.zones.apache.org/daisy/cdocs/g2/g2/g1/1291.html) On the connecting example (Connect two blocks) I receive an error like java.lang.RuntimeException: Cannot invoke listener [EMAIL PROTECTED] .. Unable to read spring configurations from classpath .. on mvn jetty:run startup Maybe it is related to the rc1 build. Alex -- View this message in context: http://www.nabble.com/-test--Cocoon-2.2-RC1---others-%28take-2%29-tf3965214.html#a11267783 Sent from the Cocoon - Dev mailing list archive at Nabble.com.
Re: [test] Cocoon 2.2-RC1 & others (take 2)
Reinhard Poetz pisze: The proposed release artifacts are available at http://people.apache.org/builds/cocoon/. Except for the archetypes the easiest way to test the artifacts is by adding a "cocoon-staging" profile to your ~/.m2/settings.xml: Then change the version number of the artifacts that you use in your POMs to the number of the proposed artifact and append "-P cocoon-staging" to all your Maven commands, e.g. mvn install -P cocoon-staging - o - I also want to draw your attention to http://cocoon.zones.apache.org/daisy/cdocs/g2/g1/g2/1370.html which contains references to 4 tutorials that help you to get started with Cocoon 2.2 and also help to test the release artifacts. Again, make sure that you use the cocoon-staging profile for all your commands as explained above. Otherwise the referenced artifacts can't be found. Thanks Reinhard for brining this release. I tested it briefly and everything seems to work well. Tested functionality: 1. block archetype 2. cocoon:rcl goal, reloading works very well. I could even create new Spring beans and use them in modified flowscript code. Great work, really :-) 3. webapp archetype 4. Forms and Templates (using some basic application) I would like to test database block as well but I don't find any documentation about it. Does any one know how to configure database block to have HSQL db running, how to create tables and add sample data (so basically, how to run SQL statements from file) and how to integrate it with JDBI? Any tips will be appreciated. I also wonder what is status of documentation? What work is left to be done before we can publish new documentation? -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: hot redeployment mostly failed
Rice Yeh pisze: Hi, My environment is the jetty from cocoon trunk. That is, I run jetty through mvn jetty:run. This problem does not happen every time doing redeployment. I was thinking about Java version, OS etc. I really think it's low-level bug in JDK and not in Cocoon itself. Do you use cocoon:rcl before running jetty:run or use webapp archetype? To track down the problem we really need more details. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: hot redeployment mostly failed
I experienced the same problem when running jetty:run of my webapplication and then rebuilding a jar used in the webbapp with mvn install. But I always thought that is not supported anyway... Alex Rice Yeh schrieb: Hi, My environment is the jetty from cocoon trunk. That is, I run jetty through mvn jetty:run. This problem does not happen every time doing redeployment. Rice On 6/23/07, Grzegorz Kossakowski <[EMAIL PROTECTED]> wrote: Rice Yeh pisze: > Hi, > I often met the following error during hot redeployment. This makes me > have to restart server and this makes redeployment nonsense. Any clue? > Here is the error: > After searching the Web for a while I suspect that your problem is not Cocoon-specific and you hit a bug in Tomcat/Java in jar files cache. Providing some details about your environment would help to eliminate Cocoon as possible cause of your problem. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/ -- Alexander Klimetschek http://www.mindquarry.com
Re: hot redeployment mostly failed
Hi, My environment is the jetty from cocoon trunk. That is, I run jetty through mvn jetty:run. This problem does not happen every time doing redeployment. Rice On 6/23/07, Grzegorz Kossakowski <[EMAIL PROTECTED]> wrote: Rice Yeh pisze: > Hi, > I often met the following error during hot redeployment. This makes me > have to restart server and this makes redeployment nonsense. Any clue? > Here is the error: > After searching the Web for a while I suspect that your problem is not Cocoon-specific and you hit a bug in Tomcat/Java in jar files cache. Providing some details about your environment would help to eliminate Cocoon as possible cause of your problem. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
