DO NOT REPLY [Bug 22842] New: - flow: importPackage/importClass problems creating InitialContext()
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22842. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22842 flow: importPackage/importClass problems creating InitialContext() Summary: flow: importPackage/importClass problems creating InitialContext() Product: Cocoon 2 Version: 2.1 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: sitemap components AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] From flow, the following works: var initCtx = new Packages.javax.naming.InitialContext(); However, the following does not: importPackage(Packages.javax.naming); ... var initCtx = new InitialContext(); returns the error: org.mozilla.javascript.EvaluatorException: file:/home/steve/mdc/cocoon-2.1/build/webapp/clavin/flow/global.js, line 16: Java constructor for javax.naming.InitialContext with arguments not found. and importClass(Packages.javax.naming.InitialContext); ... var initCtx = new InitialContext(); returns java.lang.NullPointerException
Re: [VOTE] Migrate from the aging ECM
On Sat, Aug 30, 2003 at 08:59:42AM -0400, Geoff Howard wrote: Berin Loritsch wrote: The new Cocoon should be able to use the new Fortress container. This should have little to no impact on component writers. It boasts faster startup, and it provides easier component definition. I will be happy to do the work. ... Wouldn't it be better not to do this change on the 2.1.x line? I am assuming that this change would break back-compatibility in some points at least of custom components, etc. and that should be avoided on a released version. +1 for doing it in 2.2. --Jeff Could someone (Berin?) give an estimate of what the damage would be even if we agree it's a good move? Geoff
Re: accessing sitemap parameters in a flow script
Vadim Gritsenko wrote:
Marc Portier wrote:
snip/
There's already a parameters property in the cocoon object.
We can have :
function whatever() {
doSomething(cocoon.parameters.x, cocoon.parameters.y);
}
And nobody still answered the question: why passing of parameters into
the function
function whatever(x, y, z)
is required and can not be removed? Let's remove this and move along.
cocoon.parameters is much better and has no place for confusion.
+1. But this creates a back incompatibility with the released 2.1 version...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Writing for users (was: Re: [RT] Improving Sitemap and Flowscript)
Sylvain Wallez wrote: You might need to have access to the response too. In WebDAV world, as an example, you need to set a whole bunch of headers (Allow:, DAV:, MS-Author-Via - yuck - and more), and a DASL component needs to specify the search vocabularies supported. True, you can do it by hand, but it would be much better if such manipulation could be done by a request-factory. Damn, great point. So, back one step: could adapt-environment help? or is environment not good enough for people to understand? What do others think? Mmmh... Up to now, the environment is mostly non visible to regular components (i.e. out of the sitemap/pipeline machinery). Exposing it may lead to many abuses and misuses. I would go back only a half-step : adapt-object-model sounds better as it provides all that it needed for Gianugo's use cases, and avoids messing up the environment. I'm fine with the concept, but this brings another question: who is the average sitemap writer/manager? I would say that in the Cocoon management SoC paradigm who manages the sitemap is not necessariyl an OO programmer (or, for that matter, a programmer altogether). She is (probably) knows about XML, HTML and HTTP, but it's far less than granted that he knows what an object model is. I think, then, that sitemap semantics should not assume previous OOP knowledge, and I would refrain from using programmer-domain specific terms to describe the sitemap behaviour. This is why I'm more inclined towards environment: it's probably easier to explain to a programmer that sitemap's environment is actually the object model than having a manager understand what the heck an object model is. Thoughts? -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: cvs commit: cocoon-2.1/src/blocks/woody/samples/xsl/html woody-default.xsl
Sylvain Wallez wrote: Example : wt:widget id=foo wi:styling type=textarea rows=10/ /wt:widget The type attribute defines the style type and all other attributes are dependent on this type (and here, copied as is). What do you think ? Including the style element directly rather than referring to it with a type attribute leaves for more future expansion room and won't mess up namespaces if you include direct output elements in the wi:styling/ element, IMHO. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
cvs commit: cocoon-2.1/lib/core util.concurrent-1.3.2-patched.jar
bruno 2003/08/31 02:31:55
Added: lib/core util.concurrent-1.3.2-patched.jar
Log:
Same as 1.3.2 version, but with the following method patched in the PooledExecutor
class:
protected synchronized void workerDone(Worker w) {
threads_.remove(w);
if (--poolSize_ == 0 shutdown_) {
maximumPoolSize_ = minimumPoolSize_ = 0; // disable new threads
notifyAll(); // notify awaitTerminationAfterShutdown
}
if (!shutdown_) { // create a replacement now if needed
if (poolSize_ minimumPoolSize_) {
try {
Runnable r = (Runnable)(handOff_.poll(0));
if (r != null)
addThread(r);
} catch(InterruptedException ie) {
return;
}
}
}
}
(will be part of next maintenance release of this package)
Revision ChangesPath
1.1 cocoon-2.1/lib/core/util.concurrent-1.3.2-patched.jar
Binary file
cvs commit: cocoon-2.1/lib jars.xml
bruno 2003/08/31 02:32:35 Modified:.status.xml lib jars.xml Removed: lib/core util.concurrent-1.3.1.jar Log: Upgraded util.concurrent.jar Revision ChangesPath 1.131 +5 -1 cocoon-2.1/status.xml Index: status.xml === RCS file: /home/cvs/cocoon-2.1/status.xml,v retrieving revision 1.130 retrieving revision 1.131 diff -u -r1.130 -r1.131 --- status.xml28 Aug 2003 19:08:23 - 1.130 +++ status.xml31 Aug 2003 09:32:35 - 1.131 @@ -189,6 +189,10 @@ changes release version=@version@ date=@date@ + action dev=BRD type=fix fixes-bug=18131 + Patched util-concurrent.jar so that Tomcat shutdown and continuations + cleanup now works properly. + /action action dev=CZ type=add Add a session-context input module to the session framework to retrieve information from a session context in the sitemap. 1.82 +2 -2 cocoon-2.1/lib/jars.xml Index: jars.xml === RCS file: /home/cvs/cocoon-2.1/lib/jars.xml,v retrieving revision 1.81 retrieving revision 1.82 diff -u -r1.81 -r1.82 --- jars.xml 26 Aug 2003 06:39:56 - 1.81 +++ jars.xml 31 Aug 2003 09:32:35 - 1.82 @@ -16,7 +16,7 @@ foundation of JDK 1.5 concurrency management. /description used-byCocoon/used-by -libcore/util.concurrent-1.3.1.jar/lib +libcore/util.concurrent-1.3.2-patched.jar/lib homepagehttp://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html/homepage /file
Re: Inclusion of the Calendar Popup in Apache Cocoon
Sylvain Wallez dijo: [For cocoon-dev] I asked Matt Kruse about the inclusion of his nice JavaScript calendar popup (http://www.mattkruse.com/javascript/calendarpopup/) into Cocoon. He answered very positively, so be prepared to see this in Woody in the coming days (I have it working on my HD, but it needs some polishing). Nice calendar, it has many features. I hope it can be include :) I am using also another interesting project (overLib) to show a simple online help: http://www.bosrup.com/web/overlib/ I prefer to use this enhanced version: http://www.macridesweb.com/oltest/ I think we can use ask the author if we can include it in Cocoon to show the woody help. Best Regards, Antonio Gallardo
Re: CommandManager issues [was Re: Releasing 2.1.1?]
On Sat, 2003-08-30 at 15:20, Giacomo Pati wrote:
Is someone on the Doug Lea list (if there is any) to report this?
I got an answer from him, he provided me with a slightly edited change:
protected synchronized void workerDone(Worker w) {
threads_.remove(w);
if (--poolSize_ == 0 shutdown_) {
maximumPoolSize_ = minimumPoolSize_ = 0; // disable new threads
notifyAll(); // notify awaitTerminationAfterShutdown
}
if (!shutdown_) { // create a replacement now if needed
if (poolSize_ minimumPoolSize_) {
try {
Runnable r = (Runnable)(handOff_.poll(0));
if (r != null)
addThread(r);
} catch(InterruptedException ie) {
return;
}
}
}
}
I've patched the concurrent 1.3.2 package with this change and put it in
CVS. This change will be part of the next maintenance release of
concurrent (he had this problem fixed already in the JSR-166 version of
that class).
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
[EMAIL PROTECTED] [EMAIL PROTECTED]
DO NOT REPLY [Bug 18131] - The Cocoon Servlet does not shutdown properly under Tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18131. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18131 The Cocoon Servlet does not shutdown properly under Tomcat [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-08-31 09:36 --- Should be fixed by util.concurrent-1.3.2-patched.jar
FW: HTML code shown in browser, not parsed
It seems this is the same problem as the sendPage() problem described recently on both lists because AFAIK sendPage(..) calls are internal redirects. Is anybody aware of any changes (environment, ...?) that could have caused this problem? Cheers, Reinhard -Original Message- From: Sonny Sukumar [mailto:[EMAIL PROTECTED] Sent: Sunday, August 31, 2003 12:43 AM To: [EMAIL PROTECTED] Subject: HTML code shown in browser, not parsed Hi guys, I just noticed this strange behavior today.. When I do an internal redirect to a trivially simple pipeline that just does a map:read to read an HTML document, then the actual HTML code for that doc is shown in my browser. Here's an example sitemap snippet: map:match pattern=doSomething !-- Do some things -- map:redirect-to uri=cocoon:/readStaticHtmlDoc/ map:match map:match pattern=readStaticHtmlDoc map:read src=myapp/html_files/someFile.htm/ /map:match Note that invoking readStaticHtmlDoc works just fine. Can anybody explain this? I upgraded to Cocoon 2.1.1-dev yesterday, and I'm on Tomcat 4.1.17 with JDK 1.4.2_01. I think it has to be a Cocoon-related thing though, whether my fault or a bug. It's probably my fault somehow, but it's never happened before. Thanks, Sonny _ MSN 8: Get 6 months for $9.95/month http://join.msn.com/?page=dept/dialup - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Implementing Cocoon Blocks
Stefano Mazzocchi wrote: On Wednesday, Aug 27, 2003, at 11:35 Europe/Rome, Christian Haul wrote: Which is the whole point of my mail. Don't use dependency ranges, use metadata specifying capabilities and requirements for this. I think you greatly underestimate the complexity of the approach you are proposing. Last thing I want is to enter the ontology problem space. There is absolutely no need to go the full way and I don't suggest to do it. A simple list of features that are matched 1:1 would be orders of magnitude more powerful than version numbers. But in case I'm missing your point, please provide an explicit example. Actually, I have already provided one: provides-features feature name=html-skin/ feature name=wml-skin/ /provides-features dependencies block name=core uri=core feature name=html-serializer/ /block /dependencies This would be a very simple block that has little requirements and provides few features. Let's look e.g. at the databases block. For ease of use, let's assume that any tag appearing beneath provides-features is a name of a feature and let's assume that features may have sub-features: provides-features esql stored-procedures/ grouping/ get-xml/ get-clob/ get-blob/ /esql sql-transformer stored-procedures/ get-xml/ get-clob/ get-blob/ /sql-transformer db-actions add/ update/ delete/ /db-actions mod-actions add autoincrement oracle/ informix/ mysql/ postgres/ hsqldb/ /autoincrement /add update/ delete/ query/ /mod-actions /provides-features Now, another block might require the following: dependencies block name=databases uri=db !-- *this* block will refer to the block satisfying the requirements as cob:db -- esql grouping/ /esql sql-transformer/ /block /dependencies Which is apparently compatible. Even without knowing the semantics of a feature esql hence without ontologies. OK, this is more expensive than comparing to integers. OTOH this will occurr only once when a new block is registered. Chris. -- C h r i s t i a n H a u l [EMAIL PROTECTED] fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
Re: cvs commit: cocoon-2.1/src/blocks/woody/samples/xsl/html woody-default.xsl
Steven Noels wrote:
Sylvain Wallez wrote:
Example :
wt:widget id=foo
wi:styling type=textarea rows=10/
/wt:widget
The type attribute defines the style type and all other
attributes are dependent on this type (and here, copied as is).
What do you think ?
Including the style element directly rather than referring to it with
a type attribute leaves for more future expansion room and won't mess
up namespaces if you include direct output elements in the
wi:styling/ element, IMHO.
I think I wasn't clear : this applies well to _flat_ styling
configurations (i.e. a simple list of name/value pairs) as it doesn't
require an additional nested element (reduced verbosity). But this does
not prevent the use of nested elements in wi:styling when needed
(although I haven't encountered this need up to now).
Furthermore, use of attributes ensures uniqueness of styling type, which
is not guaranteed with nested elements.
E.g. what happens if we write :
wt:widget id=foo
wi:styling
textarea rows=10/
password size=20/
/wi:styling
/wt:widget
Will this widget be rendered as a textarea or as a password ? With
textarea or password being defined by the unique type attribute,
this problem cannot happen.
Or do we want wi:styling to be able to hold different styling
directives and let the layout stylesheet decide which one is best ?
Mmmh... too much magic...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [VOTE] Migrate from the aging ECM
Berin Loritsch wrote: The new Cocoon should be able to use the new Fortress container. This should have little to no impact on component writers. It boasts faster startup, and it provides easier component definition. I will be happy to do the work. +1 from me. +1 for this change in either 2.1.2 (together with change of logging) or in 2.2 Chris. -- C h r i s t i a n H a u l [EMAIL PROTECTED] fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
Re: CommandManager issues [was Re: Releasing 2.1.1?]
On Sat, 2003-08-30 at 17:24, Bruno Dumon wrote: On Sat, 2003-08-30 at 15:20, Giacomo Pati wrote: snip/ I like the way how the Cornerstone Scheduler recently integrated by Carsten more than the CommandManager way because of its componentisation. Still, I like to see a Scheduler as a single component definition in the xconf file. Today we need at least three component definitions (Scheduler, ThreadManager, TimeScheduler) as well as one for each Target. I think this can be made much easier, like: scheduler logger=scheduler triggers trigger name=mytarget class=my.comp.MyTarget logger=mytarget timed type=crontab month -1 /month weekday SUN /weekday day * /day hour 9-17/2 /hour minute */5 /minute /timed ... /triggers /scheduler In the above, triggers are handled as Avalon components and the scheduler takes care of instatiation and the lifecycle stuff. Unfortunately, the Cornerstone Scheduler toolkit doensn't offer a full crontab like specification of defining trigger point in time like I've used above (and I'd be happy to have). My suggestion (which I can implement if accepted) is to have a Scheduler that is able to do the above by use of the CommandManager given someone can fix Doug Leas concurrent utilities with the patch from Bruno. great. Or maybe not so great. I'm not sure the CommandManager is well suited for a general purpose scheduler. What follows now should be read with a 'AFAIU' disclaimer: All commands added to the CommandManager are executed sequentially and on one thread. So if there is one command that takes somewhat longer to execute, it will block the execution of other commands. This may be fine for management-tasks which should be executed repeatedly (but not at fixed times), but for a scheduler I would expect a command to be executed at the configured time. This could be solved by creating a different CommandManager for each scheduled task, since multiple CommandManagers can be executed in parallel. But then you'd still want to use a different ThreadManager than the TPCThreadManager, since that will block when all threads are in use. The result will however be rather overkill IMHO: even commands that need to be executed only weekly, will be checked every 100 ms (= sleeptime parameter) to see if they need to be executed. Conclusion: while this event-based infrastructure is quite cool, I'm not convinced yet it is good for scheduling-purposes. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: FW: HTML code shown in browser, not parsed
Reinhard Poetz wrote:
It seems this is the same problem as the sendPage() problem described
recently on both lists because AFAIK sendPage(..) calls are internal
redirects.
Is anybody aware of any changes (environment, ...?) that could have
caused this problem?
I recently fixed bugs in internal redirects more about two weeks ago,
but I don't see how this can affect the mime type. Also,
sendPageAndWait() also uses an internal redirect.
I will investigate further on this...
Sylvain
-Original Message-
From: Sonny Sukumar [mailto:[EMAIL PROTECTED]
Sent: Sunday, August 31, 2003 12:43 AM
To: [EMAIL PROTECTED]
Subject: HTML code shown in browser, not parsed
Hi guys,
I just noticed this strange behavior today..
When I do an internal redirect to a trivially simple pipeline
that just does
a map:read to read an HTML document, then the actual HTML
code for that doc
is shown in my browser. Here's an example sitemap snippet:
map:match pattern=doSomething
!-- Do some things --
map:redirect-to uri=cocoon:/readStaticHtmlDoc/ map:match
map:match pattern=readStaticHtmlDoc
map:read src=myapp/html_files/someFile.htm/
/map:match
Note that invoking readStaticHtmlDoc works just fine. Can
anybody explain
this?
I upgraded to Cocoon 2.1.1-dev yesterday, and I'm on Tomcat
4.1.17 with JDK
1.4.2_01. I think it has to be a Cocoon-related thing
though, whether my
fault or a bug. It's probably my fault somehow, but it's
never happened
before.
Thanks,
Sonny
_
MSN 8: Get 6 months for $9.95/month
http://join.msn.com/?page=dept/dialup
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: poolable avalon in cocoon
Nicolas Maisonneuve wrote:
hy ,
i hava some trouble with poolabe interface in cocon..
i made a XMLDB avalon component .
but
if i call the lookup 6 times, 6 instances are created ..
i would use the instances already created .. so in using the avalon
Poolable interface and adding the attributs pool-grow pool-max
pool-min , it would be ok .. but .. no
if i call the lookup 6 times, 6 instances are created ..
if someone can me help to understand ..
Quick question : do you release() the instances after lookup() ? Because
this is what puts instances back into the pool.
Ah, and could you please send plain text mails, and not HTML ? Thanks.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: Writing for users
Gianugo Rabellino wrote:
Sylvain Wallez wrote:
You might need to have access to the response too. In WebDAV world,
as an example, you need to set a whole bunch of headers (Allow:,
DAV:, MS-Author-Via - yuck - and more), and a DASL component needs
to specify the search vocabularies supported. True, you can do it
by hand, but it would be much better if such manipulation could be
done by a request-factory.
Damn, great point.
So, back one step: could adapt-environment help? or is
environment not good enough for people to understand?
What do others think?
Mmmh... Up to now, the environment is mostly non visible to regular
components (i.e. out of the sitemap/pipeline machinery). Exposing it
may lead to many abuses and misuses.
I would go back only a half-step : adapt-object-model sounds better
as it provides all that it needed for Gianugo's use cases, and avoids
messing up the environment.
I'm fine with the concept, but this brings another question: who is
the average sitemap writer/manager? I would say that in the Cocoon
management SoC paradigm who manages the sitemap is not necessariyl an
OO programmer (or, for that matter, a programmer altogether). She is
(probably) knows about XML, HTML and HTTP, but it's far less than
granted that he knows what an object model is.
I think, then, that sitemap semantics should not assume previous OOP
knowledge, and I would refrain from using programmer-domain specific
terms to describe the sitemap behaviour. This is why I'm more inclined
towards environment: it's probably easier to explain to a programmer
that sitemap's environment is actually the object model than having a
manager understand what the heck an object model is.
Thoughts?
I share your concerns, and my proposal was actually more about the
abilities of this kind of component than its naming. So we can consider
using the adapt-environment sitemap statement using components
adapting a _subset_ of the environment, which is the object model.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [Vote] Move from LogKitManager to LoggerManager
Carsten Ziegeler wrote:
Triggered by the recent discussions about using log4j,
I propose that we move from the deprecated LogKitManager
to the new LoggerManager. This will make using log4j much
easier (and I would implement that then next).
There is a patch for the move already in bugzilla:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21730
But: this is an incompatible change (however the impace should be
very small).
So, please vote on the change.
and please vote if this is a change for 2.1.1 or 2.2.
+1 in 2.1.2 !
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: cvs commit: cocoon-2.1/src/blocks/woody/samples/xsl/html woody-default.xsl
Bruno Dumon wrote:
On Sun, 2003-08-17 at 23:03, [EMAIL PROTECTED] wrote:
sylvain 2003/08/17 14:03:42
Modified:src/blocks/woody/java/org/apache/cocoon/woody/transformation
WidgetReplacingPipe.java
src/blocks/woody/samples/xsl/html woody-default.xsl
Log:
Prevent the production of wi:styling if it's already present in a wt:widget.
This allows to pass styling information as attributes of wi:style
Wouldn't it be better to remove the old behaviour completely and require the styling information to be put inside wi:styling? Might become confusing otherwise...
+1. But I did not want to break anything ;-)
Talking about this, I find it much more readable to use attributes on
wi:styling rather than nested elements for flat styling
configuration, which is the most frequent.
Example :
wt:widget id=foo
wi:styling type=textarea rows=10/
/wt:widget
The type attribute defines the style type and all other attributes
are dependent on this type (and here, copied as is).
What do you think ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
DO NOT REPLY [Bug 18131] - The Cocoon Servlet does not shutdown properly under Tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18131. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18131 The Cocoon Servlet does not shutdown properly under Tomcat [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED
Re: CommandManager issues [was Re: Releasing 2.1.1?]
On Sun, 31 Aug 2003, Bruno Dumon wrote: On Sat, 2003-08-30 at 17:24, Bruno Dumon wrote: On Sat, 2003-08-30 at 15:20, Giacomo Pati wrote: snip/ I like the way how the Cornerstone Scheduler recently integrated by Carsten more than the CommandManager way because of its componentisation. Still, I like to see a Scheduler as a single component definition in the xconf file. Today we need at least three component definitions (Scheduler, ThreadManager, TimeScheduler) as well as one for each Target. I think this can be made much easier, like: scheduler logger=scheduler triggers trigger name=mytarget class=my.comp.MyTarget logger=mytarget timed type=crontab month -1 /month weekday SUN /weekday day * /day hour 9-17/2 /hour minute */5 /minute /timed ... /triggers /scheduler In the above, triggers are handled as Avalon components and the scheduler takes care of instatiation and the lifecycle stuff. Unfortunately, the Cornerstone Scheduler toolkit doensn't offer a full crontab like specification of defining trigger point in time like I've used above (and I'd be happy to have). My suggestion (which I can implement if accepted) is to have a Scheduler that is able to do the above by use of the CommandManager given someone can fix Doug Leas concurrent utilities with the patch from Bruno. great. Or maybe not so great. I'm not sure the CommandManager is well suited for a general purpose scheduler. What follows now should be read with a 'AFAIU' disclaimer: All commands added to the CommandManager are executed sequentially and on one thread. So if there is one command that takes somewhat longer to execute, it will block the execution of other commands. This may be fine for management-tasks which should be executed repeatedly (but not at fixed times), but for a scheduler I would expect a command to be executed at the configured time. This is a matter of configuring a ThreadManager (which admittedly today the one created in the Cocoon class isn't configurable at all). This could be solved by creating a different CommandManager for each scheduled task, since multiple CommandManagers can be executed in If you have a ThreadManager with as many threads as needed you're set. You only need ONE CommandManager, AFAIU. Looking at the ThreadManager code I quite don't understand what it is doing as it could use the Executor from Doug Leas package more efficently. parallel. But then you'd still want to use a different ThreadManager than the TPCThreadManager, since that will block when all threads are in use. Or at least a configurable one. The result will however be rather overkill IMHO: even commands that need to be executed only weekly, will be checked every 100 ms (= sleeptime parameter) to see if they need to be executed. Well, IMHO 100ms is far too fast even for the ContinuationManager. For the Scheduler a granularity of one minute is enough. Conclusion: while this event-based infrastructure is quite cool, I'm not convinced yet it is good for scheduling-purposes. First, if you look at the Cornerstone Scheduler you'll see that the ability to define repeated tasks are somehow limited. Business apps can easily request administration tasks to be run twice a day on work days. To define this with the Cornerstone Scheduler you'll need to add 10 'cron' entries to it. This is why I'd like to extend it using the unix cron direction to define ranges and list of timing aspects. But then you're faced with the problem of defining sleep time for efficient use (which you need to be able to cooperate in the Cornerstone Scheduler machinery). The unix cron daemon runs every minute to check if there are any jobs to run. It checks initially creating bitsets for the minute, hour, day, month, and weekday definition for each task. This makes it easy to check whether a task has to be launched. I still haven't found an algorithm (and I think there isn't an easy one available) to determine the sleep time until the next task is due. Thus, a check every minute isn't much but still 1440 times a day. The other thing to respect if you'd like to go as efficent as possible is the determination of Threads you'll need to run each cron task at the time specified. But this needs knowledge about how much elapsed time a task need to run to decide if you need one or two thread to complete to task defined neat in time to each other. If you have an algorithm for this you'll be able to define the maximum numbers of Thread you'll need. Otherwise you allocate a separate Thread per defined task. The consequences are that probably the easiest solution to a (more or less) complete Cron like Scheduler is an own heart beat of one minute to check for task to launch and a pool of Threads as big as you have task to process. As it
Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/flowContinuationsDisposer.java
[EMAIL PROTECTED] wrote:
mpo 2003/08/26 02:04:39
Added: src/java/org/apache/cocoon/components/flow
ContinuationsDisposer.java
Log:
Adding the new ContinuationsDisposer interface declaring the callback for
implementation specific Clean-up of continuations.
See initial proposal of http://marc.theaimsgroup.com/?l=xml-cocoon-devm=105948225805344w=2
Sorry for being late on this, but is this new ContinuationsDisposer
interface really needed ? The use case explains that the interpreter
will implement ContinuationsDisposer. Since it's the interpreter that
creates WebContinuation instances, why can't it create a specialized
subclass that does the call back on invalidate() ?
And if finally this proves to be really needed, the name doesn't seem
adequate, as this interface is notified of the disposal and doesn't do
the disposal job. So this could be a ContinuationsManagerListener (which
can also be notified on creation).
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
User managed distributed transactions, thread pooling, and flow
Hey all -- I am working on using user managed distrubuted transactions from flow. I have Cocoon 2.1, Tomcat 4.1.27, JOTM 1.4.3, and the JSQLConnect JDBC driver. I believe I have it working and would like to share some things and ask a question. The biggest problem I had was the scenario when I started a transaction from flow and there was an unhandled exception, and the transaction was not cleaned up. When this happened, the next request would return a Nested transactions not supported exception. I suspect that this is because Tomcat (or Cocoon) has a thread pool servicing the requests, and since I did not clean up the transaction when the exception was thrown, the transaction remained active and bound to one of the threads in the pool. Therefore, the next request that reuses this thread and tries to start its own transaction will get the Nested transactions not supported exception. To help solve this problem, I created a small TransactionHelper JavaScript class that keeps track of the current connection(s) and transacion and has a cleanup() method that I call from a finally block. This method will attempt to rollback the active transaction and close any open connections. This seems to work, however, I wonder if there is a better place for this code? Who should be responsible for making sure there are no active transactions on threads in the thread pool? When I start a transaction, I could store a reference to the transaction using ThreadLocal, and somewhere right before the thread is returned to the pool, this could be checked and cleaned up (and an exception thrown) before the thread is returnd to the pool. Where would be an appropriate place in Cocoon to add this code? cheers, -steve
Re: CommandManager issues [was Re: Releasing 2.1.1?]
On Sun, 2003-08-31 at 20:38, Giacomo Pati wrote: On Sun, 31 Aug 2003, Bruno Dumon wrote: On Sat, 2003-08-30 at 17:24, Bruno Dumon wrote: On Sat, 2003-08-30 at 15:20, Giacomo Pati wrote: snip/ I like the way how the Cornerstone Scheduler recently integrated by Carsten more than the CommandManager way because of its componentisation. Still, I like to see a Scheduler as a single component definition in the xconf file. Today we need at least three component definitions (Scheduler, ThreadManager, TimeScheduler) as well as one for each Target. I think this can be made much easier, like: scheduler logger=scheduler triggers trigger name=mytarget class=my.comp.MyTarget logger=mytarget timed type=crontab month -1 /month weekday SUN /weekday day * /day hour 9-17/2 /hour minute */5 /minute /timed ... /triggers /scheduler In the above, triggers are handled as Avalon components and the scheduler takes care of instatiation and the lifecycle stuff. Unfortunately, the Cornerstone Scheduler toolkit doensn't offer a full crontab like specification of defining trigger point in time like I've used above (and I'd be happy to have). My suggestion (which I can implement if accepted) is to have a Scheduler that is able to do the above by use of the CommandManager given someone can fix Doug Leas concurrent utilities with the patch from Bruno. great. Or maybe not so great. I'm not sure the CommandManager is well suited for a general purpose scheduler. What follows now should be read with a 'AFAIU' disclaimer: All commands added to the CommandManager are executed sequentially and on one thread. So if there is one command that takes somewhat longer to execute, it will block the execution of other commands. This may be fine for management-tasks which should be executed repeatedly (but not at fixed times), but for a scheduler I would expect a command to be executed at the configured time. This is a matter of configuring a ThreadManager (which admittedly today the one created in the Cocoon class isn't configurable at all). This could be solved by creating a different CommandManager for each scheduled task, since multiple CommandManagers can be executed in If you have a ThreadManager with as many threads as needed you're set. You only need ONE CommandManager, AFAIU. Looking at the code again, I still think that all events from one CommandManager are handled by one thread. If you look at the code of the AbstractThreadManager: In the method register( EventPipeline pipeline ) one PipelineRunner is created to handle events from the given EventPipeline (e.g. the one of the CommandManager). Then in the run() method the PipelineRunners are executed in parallel by using the PooledExecutor: m_executor.execute( nextRunner ); But in the PipelineRunner.run() method, and the CommandManager.handleEvents() which is called by it, no new threads are started. Looking at the ThreadManager code I quite don't understand what it is doing as it could use the Executor from Doug Leas package more efficently. parallel. But then you'd still want to use a different ThreadManager than the TPCThreadManager, since that will block when all threads are in use. Or at least a configurable one. The result will however be rather overkill IMHO: even commands that need to be executed only weekly, will be checked every 100 ms (= sleeptime parameter) to see if they need to be executed. Well, IMHO 100ms is far too fast even for the ContinuationManager. For the Scheduler a granularity of one minute is enough. Conclusion: while this event-based infrastructure is quite cool, I'm not convinced yet it is good for scheduling-purposes. First, if you look at the Cornerstone Scheduler you'll see that the ability to define repeated tasks are somehow limited. Business apps can easily request administration tasks to be run twice a day on work days. To define this with the Cornerstone Scheduler you'll need to add 10 'cron' entries to it. This is why I'd like to extend it using the unix cron direction to define ranges and list of timing aspects. But then you're faced with the problem of defining sleep time for efficient use (which you need to be able to cooperate in the Cornerstone Scheduler machinery). The unix cron daemon runs every minute to check if there are any jobs to run. It checks initially creating bitsets for the minute, hour, day, month, and weekday definition for each task. This makes it easy to check whether a task has to be launched. I still haven't found an algorithm (and I think there isn't an easy one available) to determine the sleep time until the next task is due. Ah, didn't think that far. Thus, a check
Re: Woody flow example do not work
On Thu, 2003-08-21 at 14:59, Sylvain Wallez wrote: (on the topic of the validator function in woody flowscript integration) Thinking further, I really think we must separate event handler and application-related-validator. These are really two different concerns. yep, they should be split. Furthermore, the event handler decides if the _form_ validation should occur, meaning that if a single function is to implement both concerns, the event-handling part has to manually validate the form and check the validation result before going to its application-related-validation part. This is not clean, and opens the door both to unreadabable code and to complicated bugs (what if I do business validation on a form which is not valid?). Sylvain -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: cvs commit: cocoon-2.1/src/blocks/woody/samples/xsl/html woody-default.xsl
Sylvain Wallez wrote: Furthermore, use of attributes ensures uniqueness of styling type, which is not guaranteed with nested elements. E.g. what happens if we write : wt:widget id=foo wi:styling textarea rows=10/ password size=20/ /wi:styling /wt:widget Will this widget be rendered as a textarea or as a password ? With textarea or password being defined by the unique type attribute, this problem cannot happen. Well, it will be up to the stylesheet to define what will happen. And since we can't control how people will make use of that stylesheet (edit it, or better: import it), I was thinking to just give them an isolated zone where they can add any styling info they want, which most likely will be copied verbatim to the output form. Your suggestion hints at having some definitive list of style widgets, something which I doubt will happen. Or we are in a mutual misunderstanding, of course. ;-) Or do we want wi:styling to be able to hold different styling directives and let the layout stylesheet decide which one is best ? Mmmh... too much magic... Definitely. People should be prepared to do some XSL hacking, but we shouldn't provide them with anything but a very basic stylesheet. Cheers, /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: CommandManager issues [was Re: Releasing 2.1.1?]
On Sun, 31 Aug 2003, Bruno Dumon wrote: On Sun, 2003-08-31 at 20:38, Giacomo Pati wrote: First, if you look at the Cornerstone Scheduler you'll see that the ability to define repeated tasks are somehow limited. Business apps can easily request administration tasks to be run twice a day on work days. To define this with the Cornerstone Scheduler you'll need to add 10 'cron' entries to it. This is why I'd like to extend it using the unix cron direction to define ranges and list of timing aspects. But then you're faced with the problem of defining sleep time for efficient use (which you need to be able to cooperate in the Cornerstone Scheduler machinery). The unix cron daemon runs every minute to check if there are any jobs to run. It checks initially creating bitsets for the minute, hour, day, month, and weekday definition for each task. This makes it easy to check whether a task has to be launched. I still haven't found an algorithm (and I think there isn't an easy one available) to determine the sleep time until the next task is due. Ah, didn't think that far. Thus, a check every minute isn't much but still 1440 times a day. But a lot less then the 864000 times a day in case of a check every 100 ms :-) Sure. The other thing to respect if you'd like to go as efficent as possible is the determination of Threads you'll need to run each cron task at the time specified. But this needs knowledge about how much elapsed time a task need to run to decide if you need one or two thread to complete to task defined neat in time to each other. If you have an algorithm for this you'll be able to define the maximum numbers of Thread you'll need. Otherwise you allocate a separate Thread per defined task. The consequences are that probably the easiest solution to a (more or less) complete Cron like Scheduler is an own heart beat of one minute to check for task to launch and a pool of Threads as big as you have task to process. As it seems Doug Leas concurrency tools could be configured to be as resource sparing as possible (have a look at http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/PooledExecutor.html) Yep, I think that will be fine too. Ok, so I'll gona build up a Scheduler based on its own heart beat (own Thread) with Crond expressions for timing specifications that uses a PooledExecutor for the Triggers in the size of the numbers of Task defined in the configuration but with lazy construction of Thread objects. This will not need any additional jars and the ones introduced by the Cornerstone Sccheduler can be eliminated again. Is everybody happy with that? -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com
Re: CommandManager issues [was Re: Releasing 2.1.1?]
Giacomo Pati wrote: First, if you look at the Cornerstone Scheduler you'll see that the ability to define repeated tasks are somehow limited. Business apps can easily request administration tasks to be run twice a day on work days. To define this with the Cornerstone Scheduler you'll need to add 10 'cron' entries to it. This is why I'd like to extend it using the unix cron direction to define ranges and list of timing aspects. But then you're faced with the problem of defining sleep time for efficient use (which you need to be able to cooperate in the Cornerstone Scheduler machinery). I'll repeat this issue. I'd like to see the cron type entries take * like normal crontabs do. We've used this with my GenericTaskManager and doing repeated entires is a pain. David
Re: HTML code shown in browser, not parsed
Sylvain Wallez wrote:
Reinhard Poetz wrote:
It seems this is the same problem as the sendPage() problem described
recently on both lists because AFAIK sendPage(..) calls are internal
redirects.
Is anybody aware of any changes (environment, ...?) that could have
caused this problem?
I fixed bugs in internal redirects about two weeks ago, but I don't
see how this can affect the mime type. Also, sendPageAndWait() also
uses an internal redirect.
I will investigate further on this...
Found and fixed (in the CVS).
The content type was not set in the case of internal redirects, leaving
it to browser decision, mainly based upon file extension. In my case, I
always use .html which displays well, whereas other unknown extensions
appear to be rendered as text.
All should be ok now.
Sylvain
-Original Message-
From: Sonny Sukumar [mailto:[EMAIL PROTECTED] Sent: Sunday,
August 31, 2003 12:43 AM
To: [EMAIL PROTECTED]
Subject: HTML code shown in browser, not parsed
Hi guys,
I just noticed this strange behavior today..
When I do an internal redirect to a trivially simple pipeline that
just does a map:read to read an HTML document, then the actual HTML
code for that doc is shown in my browser. Here's an example sitemap
snippet:
map:match pattern=doSomething
!-- Do some things --
map:redirect-to uri=cocoon:/readStaticHtmlDoc/ map:match
map:match pattern=readStaticHtmlDoc
map:read src=myapp/html_files/someFile.htm/
/map:match
Note that invoking readStaticHtmlDoc works just fine. Can anybody
explain this?
I upgraded to Cocoon 2.1.1-dev yesterday, and I'm on Tomcat 4.1.17
with JDK 1.4.2_01. I think it has to be a Cocoon-related thing
though, whether my fault or a bug. It's probably my fault somehow,
but it's never happened before.
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: HTML code shown in browser, not parsed
Hey thanks for identifying the problem and fixing it. If I don't specify a
mime-type for map:read does it always default to text/html?
From: Sylvain Wallez [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Subject: Re: HTML code shown in browser, not parsed
Date: Sun, 31 Aug 2003 22:39:52 +0200
Sylvain Wallez wrote:
Reinhard Poetz wrote:
It seems this is the same problem as the sendPage() problem described
recently on both lists because AFAIK sendPage(..) calls are internal
redirects.
Is anybody aware of any changes (environment, ...?) that could have
caused this problem?
I fixed bugs in internal redirects about two weeks ago, but I don't see
how this can affect the mime type. Also, sendPageAndWait() also uses an
internal redirect.
I will investigate further on this...
Found and fixed (in the CVS).
The content type was not set in the case of internal redirects, leaving it
to browser decision, mainly based upon file extension. In my case, I always
use .html which displays well, whereas other unknown extensions appear to
be rendered as text.
All should be ok now.
Sylvain
-Original Message-
From: Sonny Sukumar [mailto:[EMAIL PROTECTED] Sent: Sunday, August
31, 2003 12:43 AM
To: [EMAIL PROTECTED]
Subject: HTML code shown in browser, not parsed
Hi guys,
I just noticed this strange behavior today..
When I do an internal redirect to a trivially simple pipeline that just
does a map:read to read an HTML document, then the actual HTML code for
that doc is shown in my browser. Here's an example sitemap snippet:
map:match pattern=doSomething
!-- Do some things --
map:redirect-to uri=cocoon:/readStaticHtmlDoc/ map:match
map:match pattern=readStaticHtmlDoc
map:read src=myapp/html_files/someFile.htm/
/map:match
Note that invoking readStaticHtmlDoc works just fine. Can anybody
explain this?
I upgraded to Cocoon 2.1.1-dev yesterday, and I'm on Tomcat 4.1.17 with
JDK 1.4.2_01. I think it has to be a Cocoon-related thing though,
whether my fault or a bug. It's probably my fault somehow, but it's
never happened before.
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_
Get MSN 8 and enjoy automatic e-mail virus protection.
http://join.msn.com/?page=features/virus
