DO NOT REPLY [Bug 22842] New: - flow: importPackage/importClass problems creating InitialContext()

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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: CommandManager issues [was Re: Releasing 2.1.1?]

[Bruno Dumon]

On Sat, 2003-08-30 at 15:20, Giacomo Pati wrote:
> On Fri, 29 Aug 2003, Bruno Dumon wrote:
> 
> > On Fri, 2003-08-29 at 19:55, Giacomo Pati wrote:
> >
> > if you add the following code before the closing bracket of the
> > PooledExecutor.workerDone(...) method, then it --seems to-- work:
> >
> > if (!shutdown_) {
> >   if (poolSize_ < maximumPoolSize_) {
> > Runnable r= null;
> > try {
> >   r = getTask();
> > } catch (InterruptedException e) {
> >   e.printStackTrace();
> > }
> > if (r != null)
> >   addThread(r);
> >   }
> > }
> >
> > Could someone else also try this out? For your convenience, here's a
> > compiled jar with this change:
> 
> I've patched the 1.3.2 Doug Lea utils myself with your suggestion above
> and can affirm it works now.

ok, thanks (Jeff/Antonio too).

> 
> Cocoon compiled and tested with sun jdk 1.4.2 as well as sun jdk 1.3.1
> on Linux. To stop the Jetty running under 1.3.1 I needed two [Ctrl][C]
> hits whereas the first hit reports "Shutdown hook executing" and after
> the second one Jetty finally shuts down. If've made the tests with
> Tomcat 4.1.27 as well where it behaves correctly as expected.
> 
> Now, there is still the double Ctrl-C on jdk 1.3. Can you confirm this,
> Bruno (or someone else with a Win$ machine)?

On Linux/JDK1.3.1 I have this problem too. It has nothing to do with the
CommandManager though (I'm really sure since I disabled the code). Maybe
a Java or Jetty problem.

> 
> Is someone on the Doug Lea list (if there is any) to report this?

I've just sent him a message, I'll keep the list up-to-date on any news
from him of course.

> 
> 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:
> 
>   
> 
>   class="my.comp.MyTarget"
>logger="mytarget">
> 
>-1 
>SUN 
>* 
>9-17/2 
>*/5 
> 
>   ...
> 
>   
> 
> 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.

-- 
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]

SendPage returns plain text

[Upayavira]

I've started attempting to convert the Authorisation-fw to use flow. But 
I'm finding, as was mentioned on the user list recently, that when a 
page is generated using sendPage(), the page returns as test/plain, not 
text/html.

This is happening with both my own flow pages and also for the flow 
samples (e.g. calculator).

Does anyone have any idea what is going on?

Regards, Upayavira

CommandManager issues [was Re: Releasing 2.1.1?]

[Giacomo Pati]

On Fri, 29 Aug 2003, Bruno Dumon wrote:

> On Fri, 2003-08-29 at 19:55, Giacomo Pati wrote:
>
> if you add the following code before the closing bracket of the
> PooledExecutor.workerDone(...) method, then it --seems to-- work:
>
> if (!shutdown_) {
>   if (poolSize_ < maximumPoolSize_) {
> Runnable r= null;
> try {
>   r = getTask();
> } catch (InterruptedException e) {
>   e.printStackTrace();
> }
> if (r != null)
>   addThread(r);
>   }
> }
>
> Could someone else also try this out? For your convenience, here's a
> compiled jar with this change:

I've patched the 1.3.2 Doug Lea utils myself with your suggestion above
and can affirm it works now.

Cocoon compiled and tested with sun jdk 1.4.2 as well as sun jdk 1.3.1
on Linux. To stop the Jetty running under 1.3.1 I needed two [Ctrl][C]
hits whereas the first hit reports "Shutdown hook executing" and after
the second one Jetty finally shuts down. If've made the tests with
Tomcat 4.1.27 as well where it behaves correctly as expected.

Now, there is still the double Ctrl-C on jdk 1.3. Can you confirm this,
Bruno (or someone else with a Win$ machine)?

Is someone on the Doug Lea list (if there is any) to report this?

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:

  

  

   -1 
   SUN 
   * 
   9-17/2 
   */5 

  ...

  

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.

--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com

Re: [VOTE] Migrate from the aging ECM

[Geoff Howard]

Berin Loritsch wrote:
Vadim Gritsenko 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.

+1 from me.
+1, but I (still) would like to hear quick comment on Fortress vs 
Merlin. I heard on avalon-dev that merlin is gonna be that new craze.
Consider Fortress a stepping stone from ECM to Merlin.  Once Cocoon has 
done
all the work to move to Fortress, it becomes trivial to host in Merlin.
The main things here are:

1) Merlin does not support ServiceSelector.
2) Fortress provides mechanisms to make the ServiceSelector unecessary, but
   seamlessly supports components that still hold on to it.
3) Merlin does not support the ThreadSafe, SingleThreaded, Poolable 
interfaces.
4) Fortress still supports them for legacy components--but it encourages 
the
   new meta-data enabled way.

These are the key areas where Cocoon *needs* Fortress for the immediate 
shift.
I would much rather work toward the immediate need, because we can still 
work
with Cocoon while we are doing the other migrations.

It is important to note that Merlin has a number of features that Fortress
does not have--but Fortress provides a number of features that ECM doesn't
have.  When Merlin is officially released, it will be 100% Fortress 
compatible.
Ok, then I'll be +1.  But this raises a point which is for some reason 
contentious on the list the last few days:

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.

Could someone (Berin?) give an estimate of what the "damage" would be 
even if we agree it's a good move?

Geoff

Re: [RT] Implementing Cocoon Blocks

[Geoff Howard]

Ryan Hoegg wrote:
This seems to be blurring the lines between the responsibilities of 
Cocoon and the container.  We might be able to reuse some ideas or even 
code that has been done in Merlin, Fortress, Loom, or Plexus for 
deployment time configuration and dependencies.
Anyone familiar with Fortress (which it seems we're going to as an 
intermediate until Merlin's full release) know if there's something 
which can help?  Berin?

Geoff

Geoff Howard wrote:

Also, how to recreate the deploy step efficiently?  For example:

You deploy a block with some dependencies and configuration.  The 
block deploy process walks you through setting configs and resolving 
dependencies.  You then have no record of these deployment choices 
except in wiring.xml which is not meant for human consumption.  
Perhaps it would be good to record these human-step deployment time 
configurations in a conf file which could be easily reprocessed to 
easily re-deploy all blocks to their last configuration.

Alternate versions of this file may be needed as blocks move from dev 
to staging to live, etc.

RE: [VOTE] Migrate from the aging ECM

[Reinhard Poetz]

From: Berin Loritsch

> 
> 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 from me

cvs commit: cocoon-2.1/src/java/org/apache/cocoon/sitemap LinkGatherer.java

[upayavira]

upayavira2003/08/30 02:51:59

  Modified:src/java/org/apache/cocoon/sitemap LinkGatherer.java
  Log:
  Making LinkGatherer non-caching, so that it will continue to work
  
  Revision  ChangesPath
  1.4   +4 -2  cocoon-2.1/src/java/org/apache/cocoon/sitemap/LinkGatherer.java
  
  Index: LinkGatherer.java
  ===
  RCS file: /home/cvs/cocoon-2.1/src/java/org/apache/cocoon/sitemap/LinkGatherer.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- LinkGatherer.java 17 Aug 2003 13:43:00 -  1.3
  +++ LinkGatherer.java 30 Aug 2003 09:51:59 -  1.4
  @@ -102,7 +102,9 @@
* component is currently not cacheable.
*/
   public SourceValidity getValidity() {
  -return NOPValidity.SHARED_INSTANCE;
  +//  Whilst the cache does not store gathered links, this component must be 
non-cacheable
  +//  return NOPValidity.SHARED_INSTANCE;
  +return null;
   }
   
   public void simpleLink(String href, String role, String arcrole, String title, 
String show, String actuate, String uri,
  
  
  

Re: [VOTE] Migrate from the aging ECM

[Bertrand Delacretaz]

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.
+1

I will be happy to do the work.
+1 - great!

-Bertrand

Re: Shutdown bug (was: Re: Releasing 2.1.1?)

[Antonio Gallardo]

Jeff Turner dijo:
> On Fri, Aug 29, 2003 at 10:18:40PM +0200, Bruno Dumon wrote:
> ...
> [on bug http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18131]
> ...
>> ok, 10 minutes later now, got an idea:
>>
>> if you add the following code before the closing bracket of the
>> PooledExecutor.workerDone(...) method, then it --seems to-- work:
>>
>> if (!shutdown_) {
>>   if (poolSize_ < maximumPoolSize_) {
>> Runnable r= null;
>> try {
>>   r = getTask();
>> } catch (InterruptedException e) {
>>   e.printStackTrace();
>> }
>> if (r != null)
>>   addThread(r);
>>   }
>> }
>>
>> Could someone else also try this out? For your convenience, here's a
>> compiled jar with this change:
>> http://outerthought.net/~bruno/concurrent.jar
>>
>> just copy it over the util.concurrent-1.3.1.jar
>
> Great :)  Tomcat shutdown works fine on my system with this jar.  Thanks
> muchly.

Brilliant Bruno! Where you will commit this long awaited feature and close
the bug. ;)

Best Regards,

Antonio Gallardo
>
>
> --Jeff

Re: [VOTE] Migrate from the aging ECM

[Nicola Ken Barozzi]

Berin Loritsch wrote, On 29/08/2003 17.25:
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  :-D

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-

DO NOT REPLY [Bug 20381] - XSLTC: top-level xsl:variable with document() breaks

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=20381

XSLTC: top-level xsl:variable with document() breaks





--- Additional Comments From [EMAIL PROTECTED]  2003-08-30 05:17 ---
Tried with both Xalan and Cocoon built from CVS 30/8/2003, same problem.

Shutdown bug (was: Re: Releasing 2.1.1?)

[Jeff Turner]

On Fri, Aug 29, 2003 at 10:18:40PM +0200, Bruno Dumon wrote:
...
[on bug http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18131]
...
> ok, 10 minutes later now, got an idea:
> 
> if you add the following code before the closing bracket of the
> PooledExecutor.workerDone(...) method, then it --seems to-- work:
> 
> if (!shutdown_) {
>   if (poolSize_ < maximumPoolSize_) {
> Runnable r= null;
> try {
>   r = getTask();
> } catch (InterruptedException e) {
>   e.printStackTrace();
> }
> if (r != null)
>   addThread(r);
>   }
> }
> 
> Could someone else also try this out? For your convenience, here's a
> compiled jar with this change:
> http://outerthought.net/~bruno/concurrent.jar
> 
> just copy it over the util.concurrent-1.3.1.jar

Great :)  Tomcat shutdown works fine on my system with this jar.  Thanks
muchly.  


--Jeff

Re: [RT] Implementing Cocoon Blocks

[Ryan Hoegg]

This seems to be blurring the lines between the responsibilities of 
Cocoon and the container.  We might be able to reuse some ideas or even 
code that has been done in Merlin, Fortress, Loom, or Plexus for 
deployment time configuration and dependencies.

--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
Geoff Howard wrote:

Also, how to recreate the deploy step efficiently?  For example:

You deploy a block with some dependencies and configuration.  The 
block deploy process walks you through setting configs and resolving 
dependencies.  You then have no record of these deployment choices 
except in wiring.xml which is not meant for human consumption.  
Perhaps it would be good to record these human-step deployment time 
configurations in a conf file which could be easily reprocessed to 
easily re-deploy all blocks to their last configuration.

Alternate versions of this file may be needed as blocks move from dev 
to staging to live, etc.

Re: [RT] Implementing Cocoon Blocks

[Geoff Howard]

Vadim Gritsenko wrote:
Geoff Howard wrote:

Vadim Gritsenko wrote:

Stefano Mazzocchi wrote:
...
Ok, great. Does anybody have a problem with the proposed file 
system  layout?
AFAIU, blocks are expanded into WEB-INF/blocks/\d+/ directories:
By default - but as I understood Stefano's last email, it should be 
possible to override?

the file system layout (relative to the cocoon webapp context) is

   [-] WEB-INF
L___ [-] blocks
  L___ [-] 384938958499
  | L___ [-] BLOCK-INF
  | | L___ block.xml
  | L_ (the contents of cob:mycompany.com/webmail/1.3.43)
Why temp directory is not used here? And, where unpacked blocks are 
stored?
earlier in the RT he said that the location is resolved relative to the 
webapp dir if relative location is given (WEB-INF/blocks/384938958499 ) 
but could also be absolute ($TOMCAT_HOME/work/blocks)

Temp dir:
I've been assuming this file and dir structure is the persistent state 
for the block manager.
The only servlet engine which wipes out deployment (aka temp, aka 
staging) directory on restart is Jetty. None of the others known to me 
do this.
Which is unfortunate since that's the one we ship for the demo.  So 
whatever we come up with has to work well for it too out of the box.

If it has deployed the blocks, it records its state in this 
structure.  At Cocoon restart, this structure (wiring.xml and 
resulting filesystem tree) is used to initialize the 
blocks/components/etc. Otherwise the block deployer has to re-deploy 
everything on restart.  Have I got that right?
Remember, Cocoon is deployed here as a webapp. And webapp can be 
archived into the war file. Now the question: how funny (e.g. 
384938958499) directories get into the war file in the first place?
Ah, I see your point now - unexploded wars is the issue.  Blocks can be 
wired before building a war, and after webapp deploy if the war is 
exploded, but if you prefer (or require) the war unexploded you wouldn't 
be able to deploy new blocks.

So, the WEB-INF/blocks (actually, the location of wiring.xml) must be 
configurable (which is what I think was proposed anyway) at the webapp 
level (web.xml?, cocoon.xconf?)  from there though, I assume its best to 
autogenerate some secret key for the actual location (as the \d+ above) 
to enforce that only the block deploy tool and the block manager know 
where to locate the actual resources on disk.  At least, that's what I 
assume the purpose of this point in the proposal was.  Stefano's off 
list - anyone know his reasoning on this?

But this brings up another point - what to do if the wiring.xml and 
others is deleted?  Presumably, all blocks are "uninstalled" in this 
state, but what does this do to persistence requirements.

Also, how to recreate the deploy step efficiently?  For example:

You deploy a block with some dependencies and configuration.  The block 
deploy process walks you through setting configs and resolving 
dependencies.  You then have no record of these deployment choices 
except in wiring.xml which is not meant for human consumption.  Perhaps 
it would be good to record these human-step deployment time 
configurations in a conf file which could be easily reprocessed to 
easily re-deploy all blocks to their last configuration.

Alternate versions of this file may be needed as blocks move from dev to 
staging to live, etc.

Unpacked blocks:
Good question -- maybe in WEB-INF/blocks ?
I'd suggest to store blocks in WEB-INF/blocks/, and unpack/wire/etc them 
into $temp/blocks, where $temp is temporary directory configured in 
web.xml. WEB-INF/blocks/ can also have blocks.xml to point out to blocks 
which are located outside of the blocks directory, for development needs.
I think the unpacked blocks can be anywhere and don't even need to be 
kept around?  The deploy process (the wiring step) will probably have to 
require specifying the physical location of the cob file.  Or maybe this 
just needs to be a webapp level config (like the unpack/wire destination 
directory) to specify the block library locations.  Am I on the right 
track here?

Geoff

error context when i launch cocoon

[Nicolas Maisonneuve]

hy , i use a avalon component with contextualizable 
and ThreadSafe interface.
In the context method  , i call 
context.get(Constants.DEFAULT_CONTEXT_DIR);
to have the directory of the site 
when i launch cocoon  with tomcat , there is 
this error 
 

 
ERROR   (2003-08-30) 
03:13.15:035   [core.manager] (Unknown-URI) 
Unknown-thread/ExcaliburComponentManager: Caught an exception trying to 
initialize the component 
handler.org.apache.avalon.framework.context.ContextException: Unable to 
resolve context key: ./webapp at 
org.apache.avalon.framework.context.DefaultContext.get(DefaultContext.java:157) at 
org.apache.avalon.framework.context.DefaultContext.get(DefaultContext.java:160) at 
org.apache.cocoon.components.ComponentContext.get(ComponentContext.java:135) at 
org.paris5.component.index.analysis.AnalyzerManagerImpl.contextualize(AnalyzerManagerImpl.java:77) at 
org.apache.avalon.framework.container.ContainerUtil.contextualize(ContainerUtil.java:154)
 
note : 
i use the context tomcat in the system.xml 
 ()
windows XP
cocoon 2.1 CVS
 
 
so the bug is in cocoon (or tomcat) or in my brain 
.. ?