RE: New Rhino.jar
Can we keep the source separate from the jar? I don't want to
have the rhino (etc) sources in every deployed Cocoon application :)
Carsten
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Sent: Monday, June 28, 2004 7:59 AM
To: [EMAIL PROTECTED]
Subject: Re: New Rhino.jar
Antonio Gallardo wrote:
Hi:
The new submitted rhino lib is 2 times bigger than the older one. I
noted it has included the source files.
When we discussed the inclusion of sources of Cocoon-produced
jars, several people expressed the desire to have sources
included in third-party jars produced from CVS snapshots.
That's what I did for
rhino+cont.
Is this the new approach? Will we end with a 160 MB Cocoon?
This size is unlikely to be reached if we apply this policy
only to third-party library *snapshots*. Now if even this is
considered to big, I can rebuild rhino without sources.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: New Rhino.jar
Sylvain Wallez dijo: Antonio Gallardo wrote: Hi: The new submitted rhino lib is 2 times bigger than the older one. I noted it has included the source files. When we discussed the inclusion of sources of Cocoon-produced jars, several people expressed the desire to have sources included in third-party jars produced from CVS snapshots. That's what I did for rhino+cont. First, sorry for the comment about a 160MB Cocoon distro. AFAIK we don't reached a consense in this issue. Can we start a vote? Best Regards, Antonio Gallardo
Re: Cocoon application inside coplet
Hi, Thank you for answer. No i have not tried to run CocoonPortlet in Pluto. The guidance in web are not sufficiently. But perhaps you can me help. What i have to do, in order to let run pluto? Seb :) On Thu, 24 Jun 2004 13:23:12 -0400, Menke, John [EMAIL PROTECTED] wrote: Sebastian, Although i can't answer your question it seems we are trying to accomplish the same thing. I also want to run Cocoon applications as portlets. I am taking the path of using the JSR168Portlet or CocoonPortlet class and trying to figure out the instructions on the CocoonWiki site for how to do this with Pluto. Have you tried to run CocoonPorlet in Pluto? -jm -Original Message- From: Sebastian Gnoyke [mailto:[EMAIL PROTECTED] Sent: Thursday, June 24, 2004 10:13 AM To: [EMAIL PROTECTED] Subject: Cocoon application inside coplet Hi, it is possible to run complete cocoon applications inside a portal coplet? I mean, if i write an sepearate cocoon application, is a coplet able to show this cocoon application and handles all links, etc which contains these cocoon application? Thanks, Sebastian -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Re: New Rhino.jar
Antonio Gallardo wrote:
Sylvain Wallez dijo:
Antonio Gallardo wrote:
Hi:
The new submitted rhino lib is 2 times bigger than the older one. I noted
it has included the source files.
When we discussed the inclusion of sources of Cocoon-produced jars,
several people expressed the desire to have sources included in
third-party jars produced from CVS snapshots. That's what I did for
rhino+cont.
First, sorry for the comment about a 160MB Cocoon distro.
Please, please, don't be sorry Antonio. I often have the feeling that
you think you offended people. This is *not* the case. We're discussing
openly, and diverging opinions don't mean people get offended. People
throw in their opinions and arguments, and that's what makes a consensus
accepted by everybody. Feeling sorry because you think to have offended
someone just makes you frustrated, which isn't good neither for you,
neither (indirectly) for the group.
AFAIK we don't reached a consense in this issue. Can we start a vote?
Ok. I'll write down the various options and start the vote ASAP.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
[VOTE] preservation policy for third-party snapshot sources
Hi all,
Some time ago, we discussed the need to keep sources somewhere in Cocoon
for third-party jars produced from CVS snapshots. The purpose is to be
able to easily find the source files for these jars, in order to be able
to know what we use and eventually track bugs.
It must be clear that this vote is about *snapshots only*, i.e.
non-released version. For released versions, the sources are available
by downloading the corresponding distro. Also, our policy is to use
released third-party libraries when building Cocoon releases. So this
vote is mainly about development snapshot of 3rd-party libraries used to
build development snapshots of Cocoon.
There are 3 possible policies:
1/ do not keep sources. The build date that's present in the jar name
gives us enough precision to get the corresponding sources, even if some
files may have changed within a 24 hour period.
2/ keep sources as a separate zip file. This allows to distribute
binary-only jars, and we can dig the Cocoon CVS to get the corresponding
sources when needed.
3/ include the sources inside the jar. This makes the jar size bigger
but ensures immediate availability of source files.
Please cast your votes:
[ ] do not keep sources
[ ] keep sources as separate zip files
[ ] keep sources in jar files
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [VOTE] preservation policy for third-party snapshot sources
2/ keep sources as a separate zip file. This allows to distribute binary-only jars, and we can dig the Cocoon CVS to get the corresponding sources when needed. This option is the least intrusive to users who are not interested in sources. Developers will have CVS checkouts anyway instead of the binary distribution so it seems like the logical thing to do. It will however require some discipline to keep things synchronized (especially when running custom patched versions of 3rd party libs) but i'm sure that @dev is fully aware of this :) [ ] do not keep sources [x] keep sources as separate zip files [ ] keep sources in jar files Jorg
Re: [VOTE] preservation policy for third-party snapshot sources
Sylvain Wallez dijo: Please cast your votes: [+1] do not keep sources [+1] keep sources as separate zip files [-0] keep sources in jar files Best Regards, Antonio Gallardo
Re: [VOTE] preservation policy for third-party snapshot sources
Please cast your votes: [ ] do not keep sources [X] keep sources as separate zip files but only in this special case, otherwise don't keep the sources. [ ] keep sources in jar files Stephan.
Re: [VOTE] preservation policy for third-party snapshot sources
Sylvain Wallez wrote:
snip/
There are 3 possible policies:
1/ do not keep sources. The build date that's present in the jar name
gives us enough precision to get the corresponding sources, even if
some files may have changed within a 24 hour period.
2/ keep sources as a separate zip file. This allows to distribute
binary-only jars, and we can dig the Cocoon CVS to get the
corresponding sources when needed.
3/ include the sources inside the jar. This makes the jar size bigger
but ensures immediate availability of source files.
Please cast your votes:
[ ] do not keep sources
[ ] keep sources as separate zip files
[X] keep sources in jar files
This solution ensures permanent and unambiguous availability of snapshot
sources, especially in critical situations such as commando-debugging at
a customer site months after the deployment (yes, we sometimes deploy
unreleased Cocoon versions).
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: WebDAVSource.getParent() and makeCollection()
Michal Stochmialek wrote:
Hello,
Something's wrong with implementation of getParent and makeCollection methods.
(in cocoon 2.1.5)
makeCollection() - creates collection only if parent exists. Can't create
directory hierarchy. When I try, i've got this exception:
org.apache.excalibur.source.SourceException: Unable to create collection
webdav://localhost/svn/einformatyka/articles/review/1088372068812.
Server responded 404 (Not Found (404))
Directory einformatyka/articles exists, review - don't.
Is this correct implementation of ModifiableTraversableSource?
Nope, you found a bug :-)
Well, i tried to make a work around, and created method like this:
private void createDirectories(ModifiableTraversableSource source) throws
SourceException
{
System.out.println(Creating dir [+source.getURI()+] + EXISTS:
+source.exists());
if (source.exists()) return;
if (!source.getParent().exists())
createDirectories((ModifiableTraversableSource)source.getParent());
source.makeCollection();
}
And this doesn't work too. It goes into infintive loop of recursive
calls. On standard output I get:
Creating dir [webdav://localhost/svn/einformatyka/articles/review/1088373196783]
EXISTS: false
Creating dir [webdav://localhost/svn/einformatyka/articles/review/] EXISTS: false
Creating dir [webdav://localhost/svn/einformatyka/articles/review/] EXISTS: false
Creating dir [webdav://localhost/svn/einformatyka/articles/review/] EXISTS: false
Creating dir [webdav://localhost/svn/einformatyka/articles/review/] EXISTS: false
[ and so on...]
NOTE slash at the end of URI (review/)
This example demonstrates that sometimes: source ==
source.getParent()...
Is this a bug in cocoon or in webdav-lib? Or is this a feature? ;)
Yes, is also a bug. It seems that in some cases getParent() would return
itself as its parent collection. I've just committed a fix for both
problems. I think its fixed now but haven't the opportunity to test.
Could you check if it works for you now?
--
Unico
Re: [VOTE] preservation policy for third-party snapshot sources
Sylvain Wallez wrote: Please cast your votes: [+1] do not keep sources and use a full timestamp (as UTC time) in the jar filename so that people can get the sources from the relevant external CVS, e.g. foobar-20040628T0824.jar -- David Crossley
Re: [VOTE] preservation policy for third-party snapshot sources
Sylvain Wallez wrote: ... keep sources in jar files +1 -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [VOTE] preservation policy for third-party snapshot sources
On 28.06.2004 10:32, Sylvain Wallez wrote: Please cast your votes: [ ] do not keep sources [ ] keep sources as separate zip files [X] keep sources in jar files Joerg
DO NOT REPLY [Bug 24433] - JXTemplate generator does not handle format-number(number, '$#,##0.00')
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=24433. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=24433 JXTemplate generator does not handle format-number(number, '$#,##0.00') --- Additional Comments From [EMAIL PROTECTED] 2004-06-28 11:17 --- I will re-test it, if I have a working PC again. See the patch I have done to work around this problem at that time: http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/petstore/samples/view/jxpath/Cart.xml?r1=1.2r2=1.3diff_format=h I moved the formatting from the template (where it does not belong) to the stylesheet. Maybe you can reproduce it yourself with the old version of the code. Joerg
component lifecycles
Hi All I am making a (non-SiteMap) Avalon Component that allows you to manage LDAP Entries from FlowScript. (LDAPEntryManager). I am loading the Component in FlowScript using it's Interface: var users = cocoon.getComponent (EntryManager.ROLE); and disposing it using: cocoon.releaseComponent (users); The Component implements the following lifecycle Interfaces: Configurable, Serviceable, Initializable, Disposable, ThreadSafe Configurable works as expected, the configuration in cocoon.xconf is correctly read when Cocoon starts up. I am not sure I need Serviceable as I do not need to lookup other components. Initializable, Disposable are not triggering when expected. My assumption was that 'initialize' would be called at the time of cocoon.getComponent and 'dispose' would be called at the time of cocoon.releaseComponent, but this is not happening. 'initialize' is being called at Cocoon startup, and 'dispose' is being called at Cocoon shutdown. The Component is managing a Naming Context on behalf of the FlowScript. The Naming Context cannot be shared by multiple Threads AFAIU. I am sorry, I am sure these basic lifecycle questions bore the bejesus out of you, but, what Interfaces should I implement to have my methods called by cocoon.getComponent and cocoon.releaseComponent ? So, experimenting . I removed ThreadSafe and Serviceable. What happens now is that the Component is Configured, Initialised and Disposed for every use, which is safer, but I do not need it Configured for every usage, this only needs to be done once. How can I get it Configured only once, but Initialised and Disposed for every cocoon.getComponent/cocoon.releaseComponent pair? Thanks for any suggestions. regards Jeremy If email from this address is not signed IT IS NOT FROM ME Always check the label, folks ! smime.p7s Description: S/MIME cryptographic signature
Re: component lifecycles
Jeremy Quinn wrote: Hi All I am making a (non-SiteMap) Avalon Component that allows you to manage LDAP Entries from FlowScript. (LDAPEntryManager). I am loading the Component in FlowScript using it's Interface: var users = cocoon.getComponent (EntryManager.ROLE); and disposing it using: cocoon.releaseComponent (users); The Component implements the following lifecycle Interfaces: Configurable, Serviceable, Initializable, Disposable, ThreadSafe Configurable works as expected, the configuration in cocoon.xconf is correctly read when Cocoon starts up. I am not sure I need Serviceable as I do not need to lookup other components. Initializable, Disposable are not triggering when expected. My assumption was that 'initialize' would be called at the time of cocoon.getComponent and 'dispose' would be called at the time of cocoon.releaseComponent, but this is not happening. 'initialize' is being called at Cocoon startup, and 'dispose' is being called at Cocoon shutdown. The Component is managing a Naming Context on behalf of the FlowScript. The Naming Context cannot be shared by multiple Threads AFAIU. I am sorry, I am sure these basic lifecycle questions bore the bejesus out of you, but, what Interfaces should I implement to have my methods called by cocoon.getComponent and cocoon.releaseComponent ? So, experimenting . I removed ThreadSafe and Serviceable. What happens now is that the Component is Configured, Initialised and Disposed for every use, which is safer, but I do not need it Configured for every usage, this only needs to be done once. How can I get it Configured only once, but Initialised and Disposed for every cocoon.getComponent/cocoon.releaseComponent pair? Instead of Disposable implement org.apache.avalon.excalibur.pool.Recyclable. ECM will call the recycle method when it releases the instance back to the pool. As for activating your component upon acquirement there is currently no real support for that in Cocoon AFAIK. You could lazy-activate your component when its service methods are called. -- Unico
Re: component lifecycles
Unico Hommes wrote: Jeremy Quinn wrote: Hi All I am making a (non-SiteMap) Avalon Component that allows you to manage LDAP Entries from FlowScript. (LDAPEntryManager). I am loading the Component in FlowScript using it's Interface: var users = cocoon.getComponent (EntryManager.ROLE); and disposing it using: cocoon.releaseComponent (users); The Component implements the following lifecycle Interfaces: Configurable, Serviceable, Initializable, Disposable, ThreadSafe Configurable works as expected, the configuration in cocoon.xconf is correctly read when Cocoon starts up. I am not sure I need Serviceable as I do not need to lookup other components. Initializable, Disposable are not triggering when expected. My assumption was that 'initialize' would be called at the time of cocoon.getComponent and 'dispose' would be called at the time of cocoon.releaseComponent, but this is not happening. 'initialize' is being called at Cocoon startup, and 'dispose' is being called at Cocoon shutdown. The Component is managing a Naming Context on behalf of the FlowScript. The Naming Context cannot be shared by multiple Threads AFAIU. I am sorry, I am sure these basic lifecycle questions bore the bejesus out of you, but, what Interfaces should I implement to have my methods called by cocoon.getComponent and cocoon.releaseComponent ? So, experimenting . I removed ThreadSafe and Serviceable. What happens now is that the Component is Configured, Initialised and Disposed for every use, which is safer, but I do not need it Configured for every usage, this only needs to be done once. How can I get it Configured only once, but Initialised and Disposed for every cocoon.getComponent/cocoon.releaseComponent pair? Instead of Disposable implement org.apache.avalon.excalibur.pool.Recyclable. ECM will call the recycle method when it releases the instance back to the pool. As for activating your component upon acquirement there is currently no real support for that in Cocoon AFAIK. You could lazy-activate your component when its service methods are called. Forgot to mention: when implementing Poolable (Recyclable extends Poolable) don't implement ThreadSafe. These interfaces are contrary. In avalon speak they define the 'lifestyle' of a component, where ThreadSafe means singleton (one instance per container) and Poolable means single threaded (stateful) and pooled (duh :-). Poolable components also have some extra configuration semantics. Attributes pool-min, pool-max, pool-grow control ECMs pool behavior. -- Unico
RE: JXTemplate introspection problem - PLEASE HELP
Hi,
yes, that turned out to be the problem. My class was package-private, after
making it public it went fine. I'll test with the new rhino.jar asap.
Thanks.
Bye, Helma
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Sent: Sunday, 27 June 2004 15:47
To: [EMAIL PROTECTED]
Subject: Re: JXTemplate introspection problem - PLEASE HELP
[EMAIL PROTECTED] wrote:
Guys,
I hope some of you can help, because I'm stuck and cannot figure out
what to do to get this solved. I've posted this on the
userlist as well
but got no response, so I figured that it is probably too
much related
to the Cocoon internals for a regular user to answer. I'm
trying my
luck here.
Helma, I just fixed a weird bug in Rhino+cont related to Java objects
introspection. That problem occured on objects instance of a
private of
package-private class, which were turned into JS objects having no
properties at all.
Don't know if your classes are private or package-private,
but you may
want to try the latest rhino jar, committed a few minutes ago.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [VOTE] preservation policy for third-party snapshot sources
[ ] do not keep sources [X] keep sources as separate zip files [ ] keep sources in jar files -- Ugo Cei - http://beblogging.com/ smime.p7s Description: S/MIME cryptographic signature
RE: [VOTE] preservation policy for third-party snapshot sources
Please cast your votes: [X] do not keep sources I'm -1 on: keep sources in jar files as I don't want to have the sources deployed in every Cocoon app. Carsten
JavaFlow working with Jetty but not with Tomcat
Hi, I want to use JavaFlow for writing my application flow. But I've got a problem; it isn't working with Tomcat, I'm getting a black page (view source also shows that there is really nothing). However, it is working with Jetty (both using the same webapp of couse). How is this possible, what is wrong? It seems to go wrong at org.apache.cocoon.components.flow.java.ContinuationClassLoader.java (line 100): Repository.setRepository(new ClassLoaderRepository(parent)); I'm using: Cocoon 2.1.5 Tomcat 5.0.19 I've used the Jetty included with Cocoon. Bart.
RE: JavaFlow working with Jetty but not with Tomcat
I solved it myself. I re-installed Tomcat, which seems to do the trick. The only thing that I changed in the previous Tomcat installation was that I added Apache Cactus to it (for testing). I know that JUnit (and Cactus) also uses class loading, is it possible that this conflicts with JavaFlow class loading? Bart. -Original Message- From: Bart Molenkamp Sent: Monday, June 28, 2004 2:24 PM To: [EMAIL PROTECTED] Subject: JavaFlow working with Jetty but not with Tomcat Hi, I want to use JavaFlow for writing my application flow. But I've got a problem; it isn't working with Tomcat, I'm getting a black page (view source also shows that there is really nothing). However, it is working with Jetty (both using the same webapp of couse). How is this possible, what is wrong? It seems to go wrong at org.apache.cocoon.components.flow.java.ContinuationClassLoader.java (line 100): Repository.setRepository(new ClassLoaderRepository(parent)); I'm using: Cocoon 2.1.5 Tomcat 5.0.19 I've used the Jetty included with Cocoon. Bart.
Re: JavaFlow working with Jetty but not with Tomcat
Am Mo, den 28.06.2004 schrieb Bart Molenkamp um 14:23: Hi, I want to use JavaFlow for writing my application flow. But I've got a problem; it isn't working with Tomcat, I'm getting a black page (view source also shows that there is really nothing). However, it is working with Jetty (both using the same webapp of couse). How is this possible, what is wrong? It seems to go wrong at org.apache.cocoon.components.flow.java.ContinuationClassLoader.java (line 100): Repository.setRepository(new ClassLoaderRepository(parent)); It might be that you have an old bcel library in your classpath. I know also that the xsltc is sometimes delivered with an including bcel library. Stephan.
Re: [VOTE] preservation policy for third-party snapshot sources
Sylvain Wallez wrote: [+1] do not keep sources [ 0] keep sources as separate zip files [-1] keep sources in jar files Vadim
RE: JavaFlow working with Jetty but not with Tomcat
I see only one bcel library: jakarta-bcel-20040329.jar. And it works fine with another Tomcat installation, as I posted earlier. So I don't think that this is the source of the problem. Thanks anyway, Bart. -Original Message- From: Stephan Michels [mailto:[EMAIL PROTECTED] Sent: Monday, June 28, 2004 2:57 PM To: Cocoon Developers Subject: Re: JavaFlow working with Jetty but not with Tomcat Am Mo, den 28.06.2004 schrieb Bart Molenkamp um 14:23: Hi, I want to use JavaFlow for writing my application flow. But I've got a problem; it isn't working with Tomcat, I'm getting a black page (view source also shows that there is really nothing). However, it is working with Jetty (both using the same webapp of couse). How is this possible, what is wrong? It seems to go wrong at org.apache.cocoon.components.flow.java.ContinuationClassLoader.java (line 100): Repository.setRepository(new ClassLoaderRepository(parent)); It might be that you have an old bcel library in your classpath. I know also that the xsltc is sometimes delivered with an including bcel library. Stephan.
Re: [VOTE] preservation policy for third-party snapshot sources
On Mon, Jun 28, 2004 at 11:13:22AM +0200, Sylvain Wallez wrote: Sylvain Wallez wrote: Please cast your votes: [ ] do not keep sources [ ] keep sources as separate zip files [X] keep sources in jar files This solution ensures permanent and unambiguous availability of snapshot sources, especially in critical situations such as commando-debugging at a customer site months after the deployment (yes, we sometimes deploy unreleased Cocoon versions). +1 To me this is a strong argument, because this seems to be when you really want the source, and need to be sure it is the exactly right version. Perhaps we could supply a source-stripping target or build property that would trim the source out for those who still do not want it? I.e. by default you are safe (source is included for the limited case of unreleased third-parties), but you could still go without if you prefer. --Tim Larson
portal-html-eventlink transformer and req-params ?
Hi, On last cvs 2.1, with cachingURI coplet adapter and portal-html-eventlink transformer, links like a href=page2?a=1page2/a are transformed in action=xevent=y I discovered the original request-params like a are put before the question mark in the query string : a=1?copletid=app-test-1cocoon-portal-action=1cocoon-portal-event=21 I get the request param a that is before ? from sitemap or XSP Ok, but i don't know which method i should use to get it directly from the servlet, i can only get what is behind the ?. Any idea? Regards, Phil
Re: component lifecycles
On 28 Jun 2004, at 12:43, Unico Hommes wrote: Unico Hommes wrote: Jeremy Quinn wrote: Hi All I am making a (non-SiteMap) Avalon Component that allows you to manage LDAP Entries from FlowScript. (LDAPEntryManager). I am loading the Component in FlowScript using it's Interface: var users = cocoon.getComponent (EntryManager.ROLE); and disposing it using: cocoon.releaseComponent (users); The Component implements the following lifecycle Interfaces: Configurable, Serviceable, Initializable, Disposable, ThreadSafe Configurable works as expected, the configuration in cocoon.xconf is correctly read when Cocoon starts up. I am not sure I need Serviceable as I do not need to lookup other components. Initializable, Disposable are not triggering when expected. My assumption was that 'initialize' would be called at the time of cocoon.getComponent and 'dispose' would be called at the time of cocoon.releaseComponent, but this is not happening. 'initialize' is being called at Cocoon startup, and 'dispose' is being called at Cocoon shutdown. The Component is managing a Naming Context on behalf of the FlowScript. The Naming Context cannot be shared by multiple Threads AFAIU. I am sorry, I am sure these basic lifecycle questions bore the bejesus out of you, but, what Interfaces should I implement to have my methods called by cocoon.getComponent and cocoon.releaseComponent ? So, experimenting . I removed ThreadSafe and Serviceable. What happens now is that the Component is Configured, Initialised and Disposed for every use, which is safer, but I do not need it Configured for every usage, this only needs to be done once. How can I get it Configured only once, but Initialised and Disposed for every cocoon.getComponent/cocoon.releaseComponent pair? Instead of Disposable implement org.apache.avalon.excalibur.pool.Recyclable. ECM will call the recycle method when it releases the instance back to the pool. As for activating your component upon acquirement there is currently no real support for that in Cocoon AFAIK. You could lazy-activate your component when its service methods are called. Forgot to mention: when implementing Poolable (Recyclable extends Poolable) don't implement ThreadSafe. These interfaces are contrary. In avalon speak they define the 'lifestyle' of a component, where ThreadSafe means singleton (one instance per container) and Poolable means single threaded (stateful) and pooled (duh :-). Poolable components also have some extra configuration semantics. Attributes pool-min, pool-max, pool-grow control ECMs pool behavior. Hi Unico, Many thanks for your suggestions. I now have it working more as expected . I implement Parameterizable, Disposable, Recyclable. I made my initialize() method private. I call the initialize method (to lazily initialize) from each (non-lifecycle) method that can get called from the FlowScript. On the first call, I see the code being Parameterized, my method is called, it is initialized, used then Recycled. When Cocoon is shutdown it is Disposed. Each time I run the same pipeline again, I only see it being initialized and Recycled. If I hit the same Pipeline twice simultaneously, I see another instance of the Component being Parameterized etc. Just what the Dr. ordered, thanks. BTW. I have not setup any of the Poolable parameters that you mentioned, but it seems to behave without them. How important is this ? My next question . I have my Component setup like this in cocoon.xconf : component class=org.our.component.LDAPEntryManager logger=flow.ldap role=org.our.component.EntryManager parameter name=ldap-host value=ldap://our.org:389/ parameter name=ldap-base value=ou=users,o=project,dc=our,dc=org/ parameter name=ldap-user value=cn=admin,dc=our,dc=org/ parameter name=ldap-pass value=**/ /component And as mentioned above, I load the component in FlowScript like this: cocoon.getComponent (EntryManager.ROLE); How would I organise this differently, in the situation where I had several of these Components, each differently configured, that I wanted to be able to load in FlowScript in a similar way. Maybe we want one setup for read-only privs and another setup for read-write privs etc. regards Jeremy If email from this address is not signed IT IS NOT FROM ME Always check the label, folks ! smime.p7s Description: S/MIME cryptographic signature
portal-html-eventlink transformer and req-params ?
Hi, On last cvs 2.1, with cachingURI coplet adapter and portal-html-eventlink transformer, links like a href=page2?a=1page2/a are transformed in action=xevent=y I discovered the original request-params like a are put before the question mark in the query string : a=1?copletid=app-test-1cocoon-portal-action=1cocoon-portal-event=21 I get the request param a that is before ? from sitemap or XSP Ok, but i don't know which method i should use to get it directly from the servlet, i can only get what is behind the ?. Any idea? Regards, Phil
RE: portal-html-eventlink transformer and req-params ?
If I understand you correctly, the problem is in the pipeline calling
your coplet pipeline (calling page2?a=1).
The statement is in the sitemap in coplets/html/sitemap.xmap:
map:generate
src={coplet:temporaryAttributes/application-uri}?copletid={coplet:#}/
{coplet:temporaryAttributes/application-uri} should be replaced with the
original URI: page2?a=1, so the src for the generator will be
BASEURL/page2?a=1?copletid=something
which is obviously not a valid URL. If you don't need the coplet id in your
pipeline, you could remove the ?copletid={coplet:#} from the statement.
If this is your problem, we could solve it by either using a different
approach
to build the uri or by always including the copletid in the uri. This could
be done by the html-eventlink transformer.
HTH
Carsten
-Original Message-
From: Philippe Guillard [mailto:[EMAIL PROTECTED]
Sent: Monday, June 28, 2004 6:42 AM
To: [EMAIL PROTECTED]
Subject: portal-html-eventlink transformer and req-params ?
Hi,
On last cvs 2.1, with cachingURI coplet adapter and
portal-html-eventlink transformer, links like a
href=page2?a=1page2/a are transformed in action=xevent=y
I discovered the original request-params like a are put
before the question mark in the query string :
a=1?copletid=app-test-1cocoon-portal-action=1cocoon-portal-event=21
I get the request param a that is before ? from sitemap
or XSP Ok, but i don't know which method i should use to get
it directly from the servlet, i can only get what is behind
the ?. Any idea?
Regards,
Phil
Re: component lifecycles
Jeremy Quinn wrote: On 28 Jun 2004, at 12:43, Unico Hommes wrote: Unico Hommes wrote: Jeremy Quinn wrote: Hi All I am making a (non-SiteMap) Avalon Component that allows you to manage LDAP Entries from FlowScript. (LDAPEntryManager). I am loading the Component in FlowScript using it's Interface: var users = cocoon.getComponent (EntryManager.ROLE); and disposing it using: cocoon.releaseComponent (users); The Component implements the following lifecycle Interfaces: Configurable, Serviceable, Initializable, Disposable, ThreadSafe Configurable works as expected, the configuration in cocoon.xconf is correctly read when Cocoon starts up. I am not sure I need Serviceable as I do not need to lookup other components. Initializable, Disposable are not triggering when expected. My assumption was that 'initialize' would be called at the time of cocoon.getComponent and 'dispose' would be called at the time of cocoon.releaseComponent, but this is not happening. 'initialize' is being called at Cocoon startup, and 'dispose' is being called at Cocoon shutdown. The Component is managing a Naming Context on behalf of the FlowScript. The Naming Context cannot be shared by multiple Threads AFAIU. I am sorry, I am sure these basic lifecycle questions bore the bejesus out of you, but, what Interfaces should I implement to have my methods called by cocoon.getComponent and cocoon.releaseComponent ? So, experimenting . I removed ThreadSafe and Serviceable. What happens now is that the Component is Configured, Initialised and Disposed for every use, which is safer, but I do not need it Configured for every usage, this only needs to be done once. How can I get it Configured only once, but Initialised and Disposed for every cocoon.getComponent/cocoon.releaseComponent pair? Instead of Disposable implement org.apache.avalon.excalibur.pool.Recyclable. ECM will call the recycle method when it releases the instance back to the pool. As for activating your component upon acquirement there is currently no real support for that in Cocoon AFAIK. You could lazy-activate your component when its service methods are called. Forgot to mention: when implementing Poolable (Recyclable extends Poolable) don't implement ThreadSafe. These interfaces are contrary. In avalon speak they define the 'lifestyle' of a component, where ThreadSafe means singleton (one instance per container) and Poolable means single threaded (stateful) and pooled (duh :-). Poolable components also have some extra configuration semantics. Attributes pool-min, pool-max, pool-grow control ECMs pool behavior. Hi Unico, Many thanks for your suggestions. I now have it working more as expected . I implement Parameterizable, Disposable, Recyclable. I made my initialize() method private. I call the initialize method (to lazily initialize) from each (non-lifecycle) method that can get called from the FlowScript. On the first call, I see the code being Parameterized, my method is called, it is initialized, used then Recycled. When Cocoon is shutdown it is Disposed. Each time I run the same pipeline again, I only see it being initialized and Recycled. If I hit the same Pipeline twice simultaneously, I see another instance of the Component being Parameterized etc. Just what the Dr. ordered, thanks. BTW. I have not setup any of the Poolable parameters that you mentioned, but it seems to behave without them. How important is this ? Looking around for an answer to your question I came across this: http://avalon.apache.org/excalibur/api/org/apache/avalon/excalibur/component/PoolableComponentHandler.html which suggests my answer was a bit outdated. Personally I never have experimented with pool settings a lot myself. Default settings have been sufficient for me. My next question . I have my Component setup like this in cocoon.xconf : component class=org.our.component.LDAPEntryManager logger=flow.ldap role=org.our.component.EntryManager parameter name=ldap-host value=ldap://our.org:389/ parameter name=ldap-base value=ou=users,o=project,dc=our,dc=org/ parameter name=ldap-user value=cn=admin,dc=our,dc=org/ parameter name=ldap-pass value=**/ /component And as mentioned above, I load the component in FlowScript like this: cocoon.getComponent (EntryManager.ROLE); How would I organise this differently, in the situation where I had several of these Components, each differently configured, that I wanted to be able to load in FlowScript in a similar way. Maybe we want one setup for read-only privs and another setup for read-write privs etc. Use separate role names for different component deployments. For instance: component role=org.our.component.EntryManager/ReadOnly class=.. !-- read-only configuration -- /component component role=org.our.component.EntryManager/ReadWrite class=.. !-- read-only configuration -- /component Then in your flowscript var readOnlyEntryManager =
Re: component lifecycles
Jeremy Quinn wrote: How would I organise this differently, in the situation where I had several of these Components, each differently configured, that I wanted to be able to load in FlowScript in a similar way. Maybe we want one setup for read-only privs and another setup for read-write privs etc. Use the ServiceSelector like for DataSources. I dont't know where documentation about this can be found, but the sources of Cocoon should contain many lines of that kind and a search on ServiceSelector should help. Using a ServiceSelector, a entry in cocoon.xconf looks like: your-selector component-instance class=bar.Foo name=foo1 parameter ./ /component-instance component-instance class=bar.Foo name=foo2 parameter .../ /component-instance /your-selector In a java class the code to retrieve the component foo1 should be something like: ServiceSelector selector = (ServiceSelector)this.serviceManager.lookup(Foo.ROLE); ... Foo foo1 = (Foo)selector.select(foo1); ... Hope this few lines helps. Regards
Re: [VOTE] preservation policy for third-party snapshot sources
Carsten Ziegeler wrote:
Please cast your votes:
[X] do not keep sources
I'm -1 on: keep sources in jar files as I don't want to have the sources deployed in every Cocoon app.
Can you elaborate? Is there a technical reason except size?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [VOTE] preservation policy for third-party snapshot sources
On Mon, Jun 28, 2004 at 03:40:56PM +0200, Sylvain Wallez wrote: Carsten Ziegeler wrote: Please cast your votes: [X] do not keep sources I'm -1 on: keep sources in jar files as I don't want to have the sources deployed in every Cocoon app. Can you elaborate? Is there a technical reason except size? And would having a source-stripping target or build property satisfy your concerns? --Tim Larson
RE: [VOTE] preservation policy for third-party snapshot sources
Sylvain Wallez wrote: Carsten Ziegeler wrote: Please cast your votes: [X] do not keep sources I'm -1 on: keep sources in jar files as I don't want to have the sources deployed in every Cocoon app. Can you elaborate? Is there a technical reason except size? My main concern is size. I don't see any reason for deploying source code in production environments. Carsten
Re: [VOTE] preservation policy for third-party snapshot sources
Tim Larson wrote: On Mon, Jun 28, 2004 at 11:13:22AM +0200, Sylvain Wallez wrote: Sylvain Wallez wrote: Please cast your votes: [ ] do not keep sources [ ] keep sources as separate zip files [X] keep sources in jar files This solution ensures permanent and unambiguous availability of snapshot sources, especially in critical situations such as commando-debugging at a customer site months after the deployment (yes, we sometimes deploy unreleased Cocoon versions). +1 To me this is a strong argument, because this seems to be when you really want the source, and need to be sure it is the exactly right version. Perhaps we could supply a source-stripping target or build property that would trim the source out for those who still do not want it? I.e. by default you are safe (source is included for the limited case of unreleased third-parties), but you could still go without if you prefer. Am i getting this completely wrong? I thought we would be providing these sourcejars in CVS, but never as part of the binary distribution. How about releasing an official sourcepack that matches each release? That should take care of most debugging needs IMO. Jorg
Problems with JavaFlow and lookup of components
Hello,
I want to lookup a component in a JavaFlow class, but I get a BCEL
error. I get the following error:
org.apache.bcel.verifier.exc.StructuralCodeConstraintException:
Instruction GETSTATIC constraint violated: Class
'com.bizzdesign.cms.model.StorageUnitManager' is referenced, but cannot
be loaded and resolved: 'VERIFIED_REJECTED Number of LocalVariableTable
attributes of Code attribute 'CODE' (method 'static void clinit()')
exceeds number of local variable slots '0' ('There may be no more than
one LocalVariableTable attribute per local variable in the Code
attribute.'). '. InstructionHandle: 1: getstatic[178](3) 24 Execution
Frame: Local Variables: 0:
org.apache.cocoon.samples.flow.java.CalculatorFlow 1: unknown object
2: unknown object 3: unknown object 4: unknown object
OperandStack: Slots used: 1 MaxStack: 6.
org.apache.cocoon.samples.flow.java.CalculatorFlow (Size: 1) Execution
flow: 0: aload_0 [InstructionContext] 1: getstatic 24
[InstructionContext]
I've tested on the CalculatorFlow.java sample class. I've added the line
StorageUnitManager manager = (StorageUnitManager)
getComponent(StorageUnitManager.ROLE);
The line above causes the error. What am I doing wrong?
Bart.
Re: component lifecycles
On 28 Jun 2004, at 14:50, Unico Hommes wrote: Jeremy Quinn wrote: On 28 Jun 2004, at 12:43, Unico Hommes wrote: Unico Hommes wrote: Jeremy Quinn wrote: Hi All I am making a (non-SiteMap) Avalon Component that allows you to manage LDAP Entries from FlowScript. (LDAPEntryManager). I am loading the Component in FlowScript using it's Interface: var users = cocoon.getComponent (EntryManager.ROLE); and disposing it using: cocoon.releaseComponent (users); The Component implements the following lifecycle Interfaces: Configurable, Serviceable, Initializable, Disposable, ThreadSafe Configurable works as expected, the configuration in cocoon.xconf is correctly read when Cocoon starts up. I am not sure I need Serviceable as I do not need to lookup other components. Initializable, Disposable are not triggering when expected. My assumption was that 'initialize' would be called at the time of cocoon.getComponent and 'dispose' would be called at the time of cocoon.releaseComponent, but this is not happening. 'initialize' is being called at Cocoon startup, and 'dispose' is being called at Cocoon shutdown. The Component is managing a Naming Context on behalf of the FlowScript. The Naming Context cannot be shared by multiple Threads AFAIU. I am sorry, I am sure these basic lifecycle questions bore the bejesus out of you, but, what Interfaces should I implement to have my methods called by cocoon.getComponent and cocoon.releaseComponent ? So, experimenting . I removed ThreadSafe and Serviceable. What happens now is that the Component is Configured, Initialised and Disposed for every use, which is safer, but I do not need it Configured for every usage, this only needs to be done once. How can I get it Configured only once, but Initialised and Disposed for every cocoon.getComponent/cocoon.releaseComponent pair? Instead of Disposable implement org.apache.avalon.excalibur.pool.Recyclable. ECM will call the recycle method when it releases the instance back to the pool. As for activating your component upon acquirement there is currently no real support for that in Cocoon AFAIK. You could lazy-activate your component when its service methods are called. Forgot to mention: when implementing Poolable (Recyclable extends Poolable) don't implement ThreadSafe. These interfaces are contrary. In avalon speak they define the 'lifestyle' of a component, where ThreadSafe means singleton (one instance per container) and Poolable means single threaded (stateful) and pooled (duh :-). Poolable components also have some extra configuration semantics. Attributes pool-min, pool-max, pool-grow control ECMs pool behavior. Hi Unico, Many thanks for your suggestions. I now have it working more as expected . I implement Parameterizable, Disposable, Recyclable. I made my initialize() method private. I call the initialize method (to lazily initialize) from each (non-lifecycle) method that can get called from the FlowScript. On the first call, I see the code being Parameterized, my method is called, it is initialized, used then Recycled. When Cocoon is shutdown it is Disposed. Each time I run the same pipeline again, I only see it being initialized and Recycled. If I hit the same Pipeline twice simultaneously, I see another instance of the Component being Parameterized etc. Just what the Dr. ordered, thanks. BTW. I have not setup any of the Poolable parameters that you mentioned, but it seems to behave without them. How important is this ? Looking around for an answer to your question I came across this: http://avalon.apache.org/excalibur/api/org/apache/avalon/excalibur/ component/PoolableComponentHandler.html which suggests my answer was a bit outdated. Personally I never have experimented with pool settings a lot myself. Default settings have been sufficient for me. Thanks, I will have a closer look at that. My next question . I have my Component setup like this in cocoon.xconf : component class=org.our.component.LDAPEntryManager logger=flow.ldap role=org.our.component.EntryManager parameter name=ldap-host value=ldap://our.org:389/ parameter name=ldap-base value=ou=users,o=project,dc=our,dc=org/ parameter name=ldap-user value=cn=admin,dc=our,dc=org/ parameter name=ldap-pass value=**/ /component And as mentioned above, I load the component in FlowScript like this: cocoon.getComponent (EntryManager.ROLE); How would I organise this differently, in the situation where I had several of these Components, each differently configured, that I wanted to be able to load in FlowScript in a similar way. Maybe we want one setup for read-only privs and another setup for read-write privs etc. Use separate role names for different component deployments. For instance: component role=org.our.component.EntryManager/ReadOnly class=.. !-- read-only configuration -- /component component
Re: component lifecycles
On 28 Jun 2004, at 14:52, Stephan Coboos wrote: Jeremy Quinn wrote: How would I organise this differently, in the situation where I had several of these Components, each differently configured, that I wanted to be able to load in FlowScript in a similar way. Maybe we want one setup for read-only privs and another setup for read-write privs etc. Use the ServiceSelector like for DataSources. I dont't know where documentation about this can be found, but the sources of Cocoon should contain many lines of that kind and a search on ServiceSelector should help. Using a ServiceSelector, a entry in cocoon.xconf looks like: your-selector component-instance class=bar.Foo name=foo1 parameter ./ /component-instance component-instance class=bar.Foo name=foo2 parameter .../ /component-instance /your-selector In a java class the code to retrieve the component foo1 should be something like: ServiceSelector selector = (ServiceSelector)this.serviceManager.lookup(Foo.ROLE); ... Foo foo1 = (Foo)selector.select(foo1); ... Hope this few lines helps. Thanks for this. I had seen ServiceSelector, but was not sure how it could be used from FlowScript, regards Jeremy If email from this address is not signed IT IS NOT FROM ME Always check the label, folks ! smime.p7s Description: S/MIME cryptographic signature
Re: Problems with JavaFlow and lookup of components
Am Mo, den 28.06.2004 schrieb Bart Molenkamp um 16:25:
Hello,
I want to lookup a component in a JavaFlow class, but I get a BCEL
error. I get the following error:
org.apache.bcel.verifier.exc.StructuralCodeConstraintException:
Instruction GETSTATIC constraint violated: Class
'com.bizzdesign.cms.model.StorageUnitManager' is referenced, but cannot
be loaded and resolved: 'VERIFIED_REJECTED Number of LocalVariableTable
attributes of Code attribute 'CODE' (method 'static void clinit()')
exceeds number of local variable slots '0' ('There may be no more than
one LocalVariableTable attribute per local variable in the Code
attribute.'). '. InstructionHandle: 1: getstatic[178](3) 24 Execution
Frame: Local Variables: 0:
org.apache.cocoon.samples.flow.java.CalculatorFlow 1: unknown object
2: unknown object 3: unknown object 4: unknown object
OperandStack: Slots used: 1 MaxStack: 6.
org.apache.cocoon.samples.flow.java.CalculatorFlow (Size: 1) Execution
flow: 0: aload_0 [InstructionContext] 1: getstatic 24
[InstructionContext]
I've tested on the CalculatorFlow.java sample class. I've added the line
StorageUnitManager manager = (StorageUnitManager)
getComponent(StorageUnitManager.ROLE);
The verifier code, which comes from bcel was a bit buggy, so I removed
it in the current CVS. So, I would rather use the CVS than 2.1.5
Stephan.
Re: Contents of our NOTICE.txt
Sylvain Wallez wrote: Hi all, Re-reading the ASL 2.0 and looking at our NOTICE.txt, I don't think its content is appropriate, considering that this file is the attribution notice that must be included in every derivative work. With ASL 1.1 the only attribution needed was This product includes software developed by The Apache Software Foundation (http://www.apache.org/). We now have two additional paragraphs that were previously in the license header but weren't part of the attribution notice. Do we want to keep these two additional paragraphs? Stefano, do you want to have your name in each and every derivative work? I checked randomly some other ASF project's NOTICE.txt files, and all of them contain the simple ASF attribution [1], eventually accompanied with attribution notices of included third-party libraries (e.g [2]). WDYT? I agree that just my name there is a little bit odd. I don't have a problem if you remove it. Of course, that will make me fall into oblivion, but hey, what the hell. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
RE: [VOTE] preservation policy for third-party snapshot sources
Carsten Ziegeler dijo: Tim Larson wrote: On Mon, Jun 28, 2004 at 03:40:56PM +0200, Sylvain Wallez wrote: Carsten Ziegeler wrote: Please cast your votes: [X] do not keep sources I'm -1 on: keep sources in jar files as I don't want to have the sources deployed in every Cocoon app. Can you elaborate? Is there a technical reason except size? And would having a source-stripping target or build property satisfy your concerns? No :) We are doing *today* way too much in our build system and such features would just complicate things. Let's keep it simple: separate sources from classes - SoC :) And let's just vote about adding sources to our repository for such third party snapshots. Adding sources to our own CVS is not a good solution. Keeping the exact time (at minute precision) is enough. Why replicate other CVS inside our own CVS? See this: http://blogs.cocoondev.org/mpo/archives/001979.html Best Regards, Antonio Gallardo
Re: Contents of our NOTICE.txt
with a Google Number of 18,900i don't think so :) :) (http://www.google.com/search?q=stefano+mazzocchi). Then there's always the http://www.waybackmachine.org/ to look us all up when we kick the bucket and fall off google's radar :) -- dims On Mon, 28 Jun 2004 13:50:41 -0400, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Sylvain Wallez wrote: Hi all, Re-reading the ASL 2.0 and looking at our NOTICE.txt, I don't think its content is appropriate, considering that this file is the attribution notice that must be included in every derivative work. With ASL 1.1 the only attribution needed was This product includes software developed by The Apache Software Foundation (http://www.apache.org/). We now have two additional paragraphs that were previously in the license header but weren't part of the attribution notice. Do we want to keep these two additional paragraphs? Stefano, do you want to have your name in each and every derivative work? I checked randomly some other ASF project's NOTICE.txt files, and all of them contain the simple ASF attribution [1], eventually accompanied with attribution notices of included third-party libraries (e.g [2]). WDYT? I agree that just my name there is a little bit odd. I don't have a problem if you remove it. Of course, that will make me fall into oblivion, but hey, what the hell. -- Stefano. smime.p7s - 3K -- Davanum Srinivas - http://webservices.apache.org/~dims/
[OT] Re: Contents of our NOTICE.txt
Even better than that: just look at http://www.google.com/search?q=stefano Darn, the first link on that page is hosted on my server :-P Although, when it comes to Geek-Fame, the award goes to Carsten http://www.google.com/search?q=carsten+ziegler 22.000 links! :-) I'm waaay back with only 10.400 :-( :-( Pier (need to improve my google rating) On 28 Jun 2004, at 19:31, Davanum Srinivas wrote: with a Google Number of 18,900i don't think so :) :) (http://www.google.com/search?q=stefano+mazzocchi). Then there's always the http://www.waybackmachine.org/ to look us all up when we kick the bucket and fall off google's radar :) -- dims On Mon, 28 Jun 2004 13:50:41 -0400, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Sylvain Wallez wrote: Hi all, Re-reading the ASL 2.0 and looking at our NOTICE.txt, I don't think its content is appropriate, considering that this file is the attribution notice that must be included in every derivative work. With ASL 1.1 the only attribution needed was This product includes software developed by The Apache Software Foundation (http://www.apache.org/). We now have two additional paragraphs that were previously in the license header but weren't part of the attribution notice. Do we want to keep these two additional paragraphs? Stefano, do you want to have your name in each and every derivative work? I checked randomly some other ASF project's NOTICE.txt files, and all of them contain the simple ASF attribution [1], eventually accompanied with attribution notices of included third-party libraries (e.g [2]). WDYT? I agree that just my name there is a little bit odd. I don't have a problem if you remove it. Of course, that will make me fall into oblivion, but hey, what the hell. -- Stefano. smime.p7s - 3K -- Davanum Srinivas - http://webservices.apache.org/~dims/ smime.p7s Description: S/MIME cryptographic signature
DO NOT REPLY [Bug 29562] - [PATCH] BerkeleyDBStore
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29562. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29562 [PATCH] BerkeleyDBStore --- Additional Comments From [EMAIL PROTECTED] 2004-06-28 19:26 --- Created an attachment (id=11986) new version
DO NOT REPLY [Bug 29562] - [PATCH] BerkeleyDBStore
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29562. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29562 [PATCH] BerkeleyDBStore --- Additional Comments From [EMAIL PROTECTED] 2004-06-28 19:28 --- Preloading the memory cache is a cpu hog on startup, the new version has that step removed. So far, I have not encountered any problems with this store implementation. I am still not brave enough to use it on our production site though.
Re: [VOTE] preservation policy for third-party snapshot sources
Please cast your votes: [ -1] do not keep sources [ +.5] keep sources as separate zip files [ +1] keep sources in jar files
RE: [VOTE] preservation policy for third-party snapshot sources
Interesting argument. However, if I was deploying something with a snapshot into production I sure as heck would want to make sure I had the source code for the snapshot to debug any problems that might arise. I've complained about this before. Sylvain made it pretty clear that snapshots wouldn't be used in formal Cocoon releases, so this procedure would never apply to those. In the past this hasn't been followed. If that happens in the future I would want the snapshot source with the release. For stuff still in dev I'm not sure it matters whether the source goes out or not since it is pretty risky to deploy such a thing in production. My 2 cents anyway. Ralph At 6/28/2004 07:11 AM, you wrote: Can you elaborate? Is there a technical reason except size? My main concern is size. I don't see any reason for deploying source code in production environments. Carsten
Re: component lifecycles
Not to throw a wrench in the works, but if I was to implement something like this (I have, in fact), I would make it ThreadSafe and create a new naming context every time it is accessed. Then set the system property that allows the JVM to pool JNDI LDAP contexts and forget about it. Ralph At 6/28/2004 04:17 AM, you wrote: Hi All The Component is managing a Naming Context on behalf of the FlowScript. The Naming Context cannot be shared by multiple Threads AFAIU.
JCS Exceptions with 2.1.5?
Anyone have any tips/ideas/suggestions as to what might be causing a JCS exception of the following form: ERROR (2004-06-22) 18:41:29.156 org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCache : Failure updating element, cacheName: main, key: PK_R-resource- file:/H:/Tomcat/webapps/cct/user/pdf/pdfSeparatorPage.pdf java.io.IOException: Bad file descriptor at java.io.RandomAccessFile.length(Native Method) at org.apache.jcs.auxiliary.disk.indexed.IndexedDisk.length(IndexedDisk.java:236) at org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCache.doUpdate(IndexedDiskCac he.java:249) at org.apache.jcs.auxiliary.disk.AbstractDiskCache$MyCacheListener.handlePut(Abst ractDiskCache.java:417) at org.apache.jcs.engine.CacheEventQueue$PutEvent.doRun(CacheEventQueue.java:440) at org.apache.jcs.engine.CacheEventQueue$AbstractCacheEvent.run(CacheEventQueue.j ava:358) at org.apache.jcs.engine.CacheEventQueue$QProcessor.run(CacheEventQueue.java:327) It doesn't seem to be consistent. Running 2.1.5 released version. Thanks! Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com
Re: Contents of our NOTICE.txt
Davanum Srinivas wrote: with a Google Number of 18,900i don't think so :) :) (http://www.google.com/search?q=stefano+mazzocchi). Then there's always the http://www.waybackmachine.org/ to look us all up when we kick the bucket and fall off google's radar :) [for the record, I was kidding ;-)] -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: Contents of our NOTICE.txt
i know :) On Mon, 28 Jun 2004 22:37:51 -0400, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Davanum Srinivas wrote: with a Google Number of 18,900i don't think so :) :) (http://www.google.com/search?q=stefano+mazzocchi). Then there's always the http://www.waybackmachine.org/ to look us all up when we kick the bucket and fall off google's radar :) [for the record, I was kidding ;-)] -- Stefano. smime.p7s - 3K -- Davanum Srinivas - http://webservices.apache.org/~dims/
Re: [VOTE] preservation policy for third-party snapshot sources
Ralph Goers dijo: Please cast your votes: [ -1] do not keep sources Can you explain your veto (-1)? Best Regards, Antonio Gallardo
DO NOT REPLY [Bug 29854] New: - FormsTransformer causes NullPointerException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29854. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29854 FormsTransformer causes NullPointerException Summary: FormsTransformer causes NullPointerException Product: Cocoon 2 Version: 2.1.5 Platform: PC OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: CocoonForms AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Trying to transform a form cause a message org.apache.cocoon.ProcessingException: Failed to execute pipeline.: java.lang.NullPointerException The message occurs when attempting to porcess the SAX stream coming out of the FormsTransformer - for instance, with the serializer. Inserting a LogTransformer between the FormsTransformer and the serializer (XHTML 1.1) reveals that the last SAX event was: [startPrefixMapping] prefix=null,uri=null
DO NOT REPLY [Bug 29854] - FormsTransformer causes NullPointerException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29854. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29854 FormsTransformer causes NullPointerException --- Additional Comments From [EMAIL PROTECTED] 2004-06-29 05:43 --- Created an attachment (id=11988) Form definition file
DO NOT REPLY [Bug 29854] - FormsTransformer causes NullPointerException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29854. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29854 FormsTransformer causes NullPointerException --- Additional Comments From [EMAIL PROTECTED] 2004-06-29 05:44 --- Created an attachment (id=11989) Form binding definition
DO NOT REPLY [Bug 29854] - FormsTransformer causes NullPointerException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29854. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29854 FormsTransformer causes NullPointerException --- Additional Comments From [EMAIL PROTECTED] 2004-06-29 05:45 --- Created an attachment (id=11990) Form template to be transformed
