howto make use of default database add, delete, update action for mutilple table at a time

[marco]

I have a user input form and which is used to add/update/delete records in
serveral tables. I found a sample that came with cocoon, but it is simple
example that only one table is handled at a time.

How can I make use the default DatabaseAddAction, DatabaseUpdateAction,
DatabaseDeleteAction to manipulate the data of mutiple tables at a time.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: AW: some XSLT benchmarks

[MORAVEK Peter]

> Results:
> Xalan 2.3 XSLTC
> XT
> MSXML 3.0

And what about SAXON and MSXML 4.0 ? How are the results of the benchmarks
with these two transformers ?

Thanks

Peter


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: AW: some XSLT benchmarks

[Berin Loritsch]

Jacek Ambroziak wrote:
> --- Berin Loritsch <[EMAIL PROTECTED]> wrote:
> 
>>Stefano Mazzocchi wrote:
>>
>>>"Jacek R. Ambroziak" wrote:
>>>
>>>
> 
>>>Anyway, seriously, XSLTC *is* a solution to the
>>>
>>XSLT bottleneck problem.
>>
> 
>>My question is this:  how does it _scale_.
>>
>>
> 
>>I would like to see the *same* tests with 100
>>threads each performing
>>500 translations (yes they can have their own
>>instance of the translet
>>in each thread as is necessary).  I would like to
>>see that in comparison
>>to Xalan and Saxon.
>>
>>
> 
> Have you tested Xalan/Saxon/XSLTC in your
> multithreaded environment?
> 
> I don't see a priori reasons why translets should
> scale worse...


I have run Xalan and Saxon (As have just about every other
Cocooner).  For the low volume highly personalized webapps
I generally create, it is ok.  However, I have seen much
room for improvement--server side caching helps.





Sign Up for NetZero Platinum Today
Only $9.95 per month!
http://my.netzero.net/s/signup?r=platinum&refcd=PT97

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: AW: some XSLT benchmarks

[Jacek Ambroziak]

--- Berin Loritsch <[EMAIL PROTECTED]> wrote:
> Stefano Mazzocchi wrote:
> > "Jacek R. Ambroziak" wrote:
> > 

> > Anyway, seriously, XSLTC *is* a solution to the
> XSLT bottleneck problem.
> > 

> My question is this:  how does it _scale_.
> 

> I would like to see the *same* tests with 100
> threads each performing
> 500 translations (yes they can have their own
> instance of the translet
> in each thread as is necessary).  I would like to
> see that in comparison
> to Xalan and Saxon.
> 

Have you tested Xalan/Saxon/XSLTC in your
multithreaded environment?

I don't see a priori reasons why translets should
scale worse...

--Jacek

__
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: AW: some XSLT benchmarks

[Jacek Ambroziak]

Stefano,

that is cool!  Except for the mysterious 'dbonerow'. I
will attempt to fix it
an in general I am going continue to follow my
original vision
to make XSLTC a good technology for people to actually
use.

You are right, there are multiple 'goto's' in the
generated bytecodes
(although the bytecodes are not hand-optimized, right?
:-)
but automatically generated), so that translets do not
correspond
to any valid Java program.  Decompiling to FORTRAN
would be a different
thing :-)  This is one of the reasons why I chose to
generate bytecodes
directly instead of Java code (which would make
compilation longer, too).

As to you other suggestions... I think a lot of time
is spent *around*
transformation, ie. first building the (special) DOM,
and then
serializing (or otherwise using) transformation
output.
In other words, even if transformation would take
exactly 0 ms,
we'd see a lot of time going to broadly conceived of
input/output.
That's why translets shine when the same DOM objects
can be reused,
perhaps to generate different 'views' of a document,
eg. personalize)
-- at least building-the-DOM part is factored out.

Next I'd like to address 'dbonerow'; the benchmark
kills XSLTC  :-(
so that it ends the race last w/ 10 iterations of the
test.

--Jacek


--- Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:
> "Jacek R. Ambroziak" wrote:
> > 
> > Stefano,
> > 
> > A new xmdrivers.jar is attached with an updated
> drived for XSLTC.
> > You can now run your tests again.
> 
> Ok, ran the tests on my laptop, same
> hardware/software/condition as
> before.
> 
> Results:
> 
> Xalan 2.3 XSLTC
> ---
> 
> Sun 1.3.1 [1]118,09
> Sun 1.3.1 [2]257,73
> Sun 1.3.1 [3]390,13
> Sun 1.4.0 [3]353,04
> IBM 1.3.0 [3]345,93
> 
> XT
> --
> 
> Sun 1.3.1 [1]241,52
> Sun 1.3.1 [2]205,10
> Sun 1.3.1 [3]202,33
> Sun 1.4.0 [3]193,85
> IBM 1.3.0 [3]202,48
> 
> MSXML 3.0
> -
> 
> Sun 1.3.1 [1]317,67
> Sun 1.3.1 [2]241,40
> Sun 1.3.1 [3]222,21
> IBM 1.3.0 [3]221,57
> Sun 1.4.0 [3]221,67
> 
> NOTES:
> 
> [1] all tests are run
> [2] all tests but dbonerow (XSLTC is *very* slow on
> this, about 10 times
> slower than XT)
> [3] all tests but dbonerow, decoy, number, patterns
> 
> The third test is somewhat 'XSLTC-oriented' since I
> removed the tests
> where it appears to be unreasonably slower
> (dbonerow, decoy and
> patterns) and the one that triggers an exception
> (number) [please, guys,
> fix this! I can provide stacktraces if you want]
> 
> COMMENTS:
> -
> 
> XSLTC is *fast*!!! It's even faster than native
> code!
> 
> I also tried to see if the test (running in java)
> was impacting the
> native performance but the three tests on the
> different JVMs show that
> the native code has always the same performance.
> 
> MSXML gains a lot in dbonerow (10 secs vs. 200 secs,
> a really huge
> difference! but I think this is a synchronization
> issue since the CPU is
> not going at full speed, or could be a Java I/O
> problem since it's
> working on the biggest file)
> 
> Final result:
> -
> 
> All these processors aren't exactly top class as far
> as compliance goes.
> If you want a compliant processor use Xalan or
> Saxon, no way out.
> 
> But if you want to run *fast* and you don't need to
> stress every
> function of XSLT, but perform normal stylesheets
> (like normally done in
> cocoon, since some of the XSLT functionality if
> factored out in other
> places), XSLTC is *without*any*doubt* the way to go.
> 
> Interesting enough: Java 1.3 is faster than Java 1.4
> (all tests were
> done with client JVM, since the tests aren't long
> enough to benefit from
> the hotspot server VM) and faster than IBM (which is
> normally 10% faster
> than SUN 1.3 in almost anything).
> 
> I think this could be due to the hand-written java
> assembly code that
> XSLTC generates. In fact, no decompiler is able to
> decompile a translet
> since no javac pattern is recognized... I assume
> they make extensive use
> of direct jumping (which is prohibited in java since
> 'goto' is reserved
> but not used, while is allowed at the bytecode
> level. Too bad I don't
> have time to jump into their code, but should be fun
> for an old assembly
> freak like me :) finally able to tune the JVM
> bytecode by hand :)
> 
> Seriously: hand-optimized java bytecode it's a
> dangerous approach since
> every JVM implementation is different.
> 
> Ideal should for the XSLTC engine to recognize the
> JVM it runs in (via
> system properties) and tune the generated bytecode
> on the running JVM. I
> assume this could give some 20/30% more speed
> improvement, but it's a
> potentially harmful thing to do since it might
> duplicate code and
> requires *lots* of guesses on how the JVM works
> internally.
> 
> Anyway, seriously, XSLTC *is* a solution to the XSLT
> bottlene

Re: AW: some XSLT benchmarks

[Berin Loritsch]

Stefano Mazzocchi wrote:
> "Jacek R. Ambroziak" wrote:
> 
> Ideal should for the XSLTC engine to recognize the JVM it runs in (via
> system properties) and tune the generated bytecode on the running JVM. I
> assume this could give some 20/30% more speed improvement, but it's a
> potentially harmful thing to do since it might duplicate code and
> requires *lots* of guesses on how the JVM works internally.
> 
> Anyway, seriously, XSLTC *is* a solution to the XSLT bottleneck problem.
> 
> Now: only one thing to add: let's make it work on Cocoon.
> 
> Xalan-guys, please, can you give us a hand there?


My question is this:  how does it _scale_.

For instance, The ECM is quite resonable with only a few threads, but in
a server environment where there can be as many as 150 or more
concurrent threads it slows down so badly it is unusable.  A fresh
approach reaping the benefits of the lessons of the ECM and Phoenix
proved that the new approach can handle the load *much* more gracefully.

I would like to see the *same* tests with 100 threads each performing
500 translations (yes they can have their own instance of the translet
in each thread as is necessary).  I would like to see that in comparison
to Xalan and Saxon.

That is the most important lesson we can learn.




Sign Up for NetZero Platinum Today
Only $9.95 per month!
http://my.netzero.net/s/signup?r=platinum&refcd=PT97

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [RT] Cocoon subcomponent object model (was: Re: is cocoon symmetry a holy grail?)

[Stefano Mazzocchi]

Sorry, took me a while to respond.

Nicola Ken Barozzi wrote:
> 
> From: "Vadim Gritsenko" <[EMAIL PROTECTED]>
> 
> > I have another one, it provides different functionality but it features
> > similar approach. As I don't have a name for this (multiplexer?), here
> > is the diagram:
> >
> >   - pipeline1 -
> >  /  \
> > request -> A -> X - pipeline2 - X -> C -> response
> >  \  /
> >   - pipelineN -
> >
> > Explanation:
> > 1. Request goes in
> > 2. Pipeline is being constructed from A, X, C
> > 3. SAX events passed from the A to X, where they are dispatched (same as
> > separator) to several other pipelines
> > 4. SAX events passed from these events reassembled into the one SAX
> > stream by the same instance of X component
> > 5. Result passed down the original pipeline to the C
> > 6. C spits out the response
> 
> Oh my, I've seen this in ApacheCon two more that a year ago, we knew it was
> going to come out again! ;-)
> 
> The first comment that come to me is that IMHO, to have better performance
> you need to have good control over what is happening, and that leads to
> KISS. The whole concept of making pipelines split, recombine and branch
> could make it difficult to maintain control.

I agree here.
 
> But the concept is intriguing. IMHO it could be transformed in another
> concept, a sub-component object model.
> 
> We have been seeing the picture from a sitemap POV, but never talked about
> helping the developer in writing the components themselves.
> 
> So, since it's 3:26 and I can't get sleep, here's my first RT.

:)
 
> ===
> Cocoon Sub-Component Object Model
> ===
> 
> Abstract
> -
> 
> This RT describes a finer grained object model for Cocoon that is meant
> to attain a better separation of concerns and usability.
> 
> Description
> -
> 
> Cocoon has a macro object model based on the pipeline metaphore.
> 
> Each Cocoon "object" is a pipeline component and can be of three major
> kinds:
> 1.Generator: initiates the XML pipeline by converting generic data into XML.
> 2.Transformer: filters the XML events.
> 3. Serializer converts the resulting XML into something useful for the
> client.
> 
> The pipelines are defined in a sitemap that specifies order, parameters and
> condition of pipeline components.
> 
> This componentization is useful because it enforces separation of concerns
> between content providers, graphic-layout designers, developers and site
> administrators.
> 
> Cocoon1 made life easy for the first two and quite hard for the last, who
> had the data he is responsible for scattered in all three kinds of
> components. The sitemap of Cocoon2 changed this and put things where they
> belong.
> 
> My opinion is that developers are not yet taken correctly into account.
> While the other three have a componentization which is sufficient for their
> part of work, developers suffer for the lack of it. Usually a developer has
> to write a component, and doesn't have a (sub) component model to deal with.

??? I disagree, you can write avalon-aware sitemap components by hand
(and many people do just as easy as they write servlets... or even
better).
 
> Ok, it's not really true, there are XSPs.
> But in many respects there are not sufficient:
> XSPs are hard to write
> XSPs mix (declarative) XML and (procedural) Java in an unmaintainable and
> undebuggable tangle
> XSPs cannot aid writing transformers
> XSPs must have their main tag
> XSPs do not automagically scale well (no automantic pooling or brokering)
> XSPs have slooow startup and are not good for dynamic pages that change
> often
> XSPs are a nightmare to debug (just try ;-) )
> XSPs have the 64k limit
> XSP taglibs are hard to understand, write and maintain

I agree on all these limitations, but if you don't varying XML content
in your pages (say it pretty much all comes from data stores), I'd
suggest you to write your generators directly, where you have the nice
component model that avalon gives you.
 
> Also, Cocoon components do not have scope and filter all events coming
> in (security: I don't want sensitive tags passing in a transformer that is
> useful but not completely known).

please, let's get real here: I *strongly* doubt you'll ever use a filter
in your pipeline that you don't trust. Security is ok, but at this
granularity becomes a nightmare (and a serious performance limitation)
 
> Cocoon doesn't have context scoping for session or global values.
> 
> As you can see these remarks are not in a small number, but come all from
> simple shortcomings of Cocoon IMHO:
> - The coexistence between Java and XML is a key problem.
> - The current component model is too coarse grained to help pipeline
> component writers.
> 
> A finer grained object model could also have the notion of context
> variables.
> 
> These have nothing to do with and do not endange

Re: [FYI] Cocoon 0.9

[Stefano Mazzocchi]

Steven Noels wrote:
> 
> Stefano wrote:
> 
> >
> > At that time there were four independent projects doing server side XSLT
> > (that I know of, at least)
> >
> > 1) docproc
> > 2) javalobby's project (don't remember the name, but was used to
> > generate the javalobby home page)
> > 3) IBM alphaworks XSLT servlet (later discontinued)
> > 4) Cocoon
> >
> > So Cocoon has never been the first to do this, but the first to
> > introduce the notion of XML pipelines on the server side :)
> >
> 
> Yes indeed. And given the attention Cocoon has been receiving during the past few 
>weeks, it seems it was the right
> choice to keep tracking Cocoon instead of the others :-))

Shameless plug, but seriously expect *much* more attention in the future
:)

-- 
Stefano Mazzocchi  One must still have chaos in oneself to be
  able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: AW: some XSLT benchmarks

[Stefano Mazzocchi]

"Jacek R. Ambroziak" wrote:
> 
> Stefano,
> 
> A new xmdrivers.jar is attached with an updated drived for XSLTC.
> You can now run your tests again.

Ok, ran the tests on my laptop, same hardware/software/condition as
before.

Results:

Xalan 2.3 XSLTC
---

Sun 1.3.1 [1]118,09
Sun 1.3.1 [2]257,73
Sun 1.3.1 [3]390,13
Sun 1.4.0 [3]353,04
IBM 1.3.0 [3]345,93

XT
--

Sun 1.3.1 [1]241,52
Sun 1.3.1 [2]205,10
Sun 1.3.1 [3]202,33
Sun 1.4.0 [3]193,85
IBM 1.3.0 [3]202,48

MSXML 3.0
-

Sun 1.3.1 [1]317,67
Sun 1.3.1 [2]241,40
Sun 1.3.1 [3]222,21
IBM 1.3.0 [3]221,57
Sun 1.4.0 [3]221,67

NOTES:

[1] all tests are run
[2] all tests but dbonerow (XSLTC is *very* slow on this, about 10 times
slower than XT)
[3] all tests but dbonerow, decoy, number, patterns

The third test is somewhat 'XSLTC-oriented' since I removed the tests
where it appears to be unreasonably slower (dbonerow, decoy and
patterns) and the one that triggers an exception (number) [please, guys,
fix this! I can provide stacktraces if you want]

COMMENTS:
-

XSLTC is *fast*!!! It's even faster than native code!

I also tried to see if the test (running in java) was impacting the
native performance but the three tests on the different JVMs show that
the native code has always the same performance.

MSXML gains a lot in dbonerow (10 secs vs. 200 secs, a really huge
difference! but I think this is a synchronization issue since the CPU is
not going at full speed, or could be a Java I/O problem since it's
working on the biggest file)

Final result:
-

All these processors aren't exactly top class as far as compliance goes.
If you want a compliant processor use Xalan or Saxon, no way out.

But if you want to run *fast* and you don't need to stress every
function of XSLT, but perform normal stylesheets (like normally done in
cocoon, since some of the XSLT functionality if factored out in other
places), XSLTC is *without*any*doubt* the way to go.

Interesting enough: Java 1.3 is faster than Java 1.4 (all tests were
done with client JVM, since the tests aren't long enough to benefit from
the hotspot server VM) and faster than IBM (which is normally 10% faster
than SUN 1.3 in almost anything).

I think this could be due to the hand-written java assembly code that
XSLTC generates. In fact, no decompiler is able to decompile a translet
since no javac pattern is recognized... I assume they make extensive use
of direct jumping (which is prohibited in java since 'goto' is reserved
but not used, while is allowed at the bytecode level. Too bad I don't
have time to jump into their code, but should be fun for an old assembly
freak like me :) finally able to tune the JVM bytecode by hand :)

Seriously: hand-optimized java bytecode it's a dangerous approach since
every JVM implementation is different.

Ideal should for the XSLTC engine to recognize the JVM it runs in (via
system properties) and tune the generated bytecode on the running JVM. I
assume this could give some 20/30% more speed improvement, but it's a
potentially harmful thing to do since it might duplicate code and
requires *lots* of guesses on how the JVM works internally.

Anyway, seriously, XSLTC *is* a solution to the XSLT bottleneck problem.

Now: only one thing to add: let's make it work on Cocoon.

Xalan-guys, please, can you give us a hand there?

-- 
Stefano Mazzocchi  One must still have chaos in oneself to be
  able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Finally live worldwide

[David Crossley]

OK Michael, it has been added to livesites.xml
--David

Stefano Mazzocchi wrote:
> Michael Homeijer wrote:
> > 
> > Hi,
> > 
> > Finally after some time performance tuning, checking the performance of
> > Cocoon 2, a site we build for a customer was tuned on Cocoon 1. We now have
> > acceptable and stable performance. The site is highly dynamic because
> > virtually everything is personalized, the data (prices, etc) that is
> > displayed and the layout of some tables are based on extensive customer
> > profiles. (This will only be visible to large accounts and people having a
> > valid Sun agreement).
> > 
> > Our customer went worldwide (except for unicode languages) with the
> > following site with Cocoon 1 underneath:
> > 
> > www.sun-catalogue.com
> > 
> > We are planning a new (dynamic) site with Cocoon 2 for another customer that
> > will hopefully give us enough confidence in performance and scalability to
> > propose a migration traject for this site.
> > 
> > Can somebody add this site to the list of live sites for Cocoon 1?
> 
> awesome!
> 
> this gives us better resonance even if I believe that Cocoon2 will soon
> ready to be fast/scalable enough to fit your needs.
> 
> I think that interpreted sitemap + Berin's patches + the use of XSLTC
> will do the trick.
> 
> -- 
> Stefano Mazzocchi  One must still have chaos in oneself to be
>   able to give birth to a dancing star.
> <[EMAIL PROTECTED]> Friedrich Nietzsche
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: [FYI] Cocoon 0.9

[Steven Noels]

Stefano wrote:

>
> At that time there were four independent projects doing server side XSLT
> (that I know of, at least)
>
> 1) docproc
> 2) javalobby's project (don't remember the name, but was used to
> generate the javalobby home page)
> 3) IBM alphaworks XSLT servlet (later discontinued)
> 4) Cocoon
>
> So Cocoon has never been the first to do this, but the first to
> introduce the notion of XML pipelines on the server side :)
>

Yes indeed. And given the attention Cocoon has been receiving during the past few 
weeks, it seems it was the right
choice to keep tracking Cocoon instead of the others :-))




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

cvs commit: xml-cocoon2/src/documentation/xdocs livesites.xml

[crossley]

crossley02/02/19 15:19:13

  Modified:src/documentation/xdocs livesites.xml
  Log:
  Added entry for www.sun-catalogue.com C1
  
  Revision  ChangesPath
  1.10  +1 -0  xml-cocoon2/src/documentation/xdocs/livesites.xml
  
  Index: livesites.xml
  ===
  RCS file: /home/cvs/xml-cocoon2/src/documentation/xdocs/livesites.xml,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- livesites.xml 10 Feb 2002 06:08:58 -  1.9
  +++ livesites.xml 19 Feb 2002 23:19:12 -  1.10
  @@ -76,6 +76,7 @@
   http://www.linxs.pt/";>Linxs
   http://store.learningnetwork.com/main/index.xml";>Learning 
Network
   http://www.stu.lipetsk.ru/";>Lipetsk State Technical 
University
  +http://www.sun-catalogue.com/";>Sun Catalogue
   
  
 
  
  
  

--
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail:  [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

CastorTranformer

[Thorsten Mauch]

Hi 
I wrote a Castor Transfomer it Marshals a java bean from the 
Session or the Sitemap  into a series of SAX events.
So it can replace a element with marshalled object.
I wan't to ask if you want this Transformer as a 
conribution ?


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Finally live worldwide

[Stefano Mazzocchi]

Michael Homeijer wrote:
> 
> Hi,
> 
> Finally after some time performance tuning, checking the performance of
> Cocoon 2, a site we build for a customer was tuned on Cocoon 1. We now have
> acceptable and stable performance. The site is highly dynamic because
> virtually everything is personalized, the data (prices, etc) that is
> displayed and the layout of some tables are based on extensive customer
> profiles. (This will only be visible to large accounts and people having a
> valid Sun agreement).
> 
> Our customer went worldwide (except for unicode languages) with the
> following site with Cocoon 1 underneath:
> 
> www.sun-catalogue.com
> 
> We are planning a new (dynamic) site with Cocoon 2 for another customer that
> will hopefully give us enough confidence in performance and scalability to
> propose a migration traject for this site.
> 
> Can somebody add this site to the list of live sites for Cocoon 1?

awesome!

this gives us better resonance even if I believe that Cocoon2 will soon
ready to be fast/scalable enough to fit your needs.

I think that interpreted sitemap + Berin's patches + the use of XSLTC
will do the trick.

-- 
Stefano Mazzocchi  One must still have chaos in oneself to be
  able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [FYI] Cocoon 0.9

[Stefano Mazzocchi]

Steven Noels wrote:
> 
> > -Original Message-
> > From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]]
> > Sent: maandag 18 februari 2002 14:23
> > To: Apache Cocoon
> > Subject: [FYI] Cocoon 0.9
> >
> >
> > I was looking for some old pictures in my archive CDs and
> > found the very
> > first release of Apache Cocoon, so old that it never left my computer,
> > until now where you can find it here:
> >
> >  http://www.apache.org/~stefano/archeology/Cocoon0.9.zip
> >
> > It's 50Kb big and the creation date says 8 February 1999.
> 
> Does anyone remember the very similar docproc?
> 
> http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Nov-1997/0216.html
> 
> and thanks to google's cache
> 
> http://www.google.com/search?q=cache:javalab.uoregon.edu/ser/software/do
> cproc/index.xml
> http://www.google.com/search?q=cache:javalab.uoregon.edu/ser/software/do
> cproc/news.xml
> 
> It was this project that inspired me to track serverside XSLT
> frameworks, and after a while Cocoon came into existence :-)

Yes, I do.

At that time there were four independent projects doing server side XSLT
(that I know of, at least)

1) docproc
2) javalobby's project (don't remember the name, but was used to
generate the javalobby home page)
3) IBM alphaworks XSLT servlet (later discontinued)
4) Cocoon

So Cocoon has never been the first to do this, but the first to
introduce the notion of XML pipelines on the server side :)

-- 
Stefano Mazzocchi  One must still have chaos in oneself to be
  able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

esql thread unsafe - bug

[Szymon Stasik]

Hi,

I've discovered serious bug in esql logicsheet while using it with
cocoon-1.8.3. However the same bug seems to exists in cocoon2. The
problem is that while node stack logic variables (xspParentNode,
xspCurrentNode, xspNodeStack) are defined inside populateDocument
method, similar objects used by esql (_esql_connections etc...) exist as
object attributes.

Since there is only one instance of particular xsp page (eg.
_index.class) per application, under havy load it is possible (and easy
to observe using eg jmeter) that concurent calls to the same
_index.populateDocument method will lead esql structures and connection
pools to be corrupted.

you can find attached the patch that should fix thing up (it works at
least with cocoon-1.8.x)

regards,

Szymon




--- 
xml-cocoon2-orig/src/java/org/apache/cocoon/components/language/markup/xsp/java/esql.xsl
Tue Feb 19 14:13:21 2002
+++ 
+xml-cocoon2-patched/src/java/org/apache/cocoon/components/language/markup/xsp/java/esql.xsl
+ Tue Feb 19 21:02:01 2002
@@ -249,13 +249,6 @@
   
 
 
-  private Stack _esql_connections = new Stack();
-  private EsqlConnection _esql_connection = 
null;
-  private Stack _esql_queries = new Stack();
-  private EsqlQuery _esql_query = null;
-  private SQLException _esql_exception = null;
-  private StringWriter _esql_exception_writer = null;
-
   
 
   
@@ -322,6 +315,13 @@
   
 
 
+  private Stack _esql_connections = new Stack();
+  private EsqlConnection _esql_connection = 
+null;
+  private Stack _esql_queries = new Stack();
+  private EsqlQuery _esql_query = null;
+  private SQLException _esql_exception = null;
+  private StringWriter _esql_exception_writer = null;
+  
 
 
   




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 6549] - [PATCH] new "powered by Cocoon" bitmap

[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=6549

[PATCH] new "powered by Cocoon" bitmap





--- Additional Comments From [EMAIL PROTECTED]  2002-02-19 18:39 ---
BTW, I have seen these types of logos as large as 150x43, although I
would be most comfortable if we do not exceed 100 pixels wide.  (we
are currently safe at only 88)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 6549] - [PATCH] new "powered by Cocoon" bitmap

[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=6549

[PATCH] new "powered by Cocoon" bitmap





--- Additional Comments From [EMAIL PROTECTED]  2002-02-19 18:38 ---
All of those are great!

Looking at the three, I have to say 

http://nagoya.apache.org/bugzilla/showattachment.cgi?attach_id=1212

is the best.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 6549] - [PATCH] new "powered by Cocoon" bitmap

[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=6549

[PATCH] new "powered by Cocoon" bitmap





--- Additional Comments From [EMAIL PROTECTED]  2002-02-19 18:28 ---
Created an attachment (id=1212)
Third variation

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 6549] - [PATCH] new "powered by Cocoon" bitmap

[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=6549

[PATCH] new "powered by Cocoon" bitmap





--- Additional Comments From [EMAIL PROTECTED]  2002-02-19 18:28 ---
Created an attachment (id=1211)
Second variation

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 6549] - [PATCH] new "powered by Cocoon" bitmap

[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=6549

[PATCH] new "powered by Cocoon" bitmap





--- Additional Comments From [EMAIL PROTECTED]  2002-02-19 18:28 ---
Created an attachment (id=1210)
First variation

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 6549] - [PATCH] new "powered by Cocoon" bitmap

[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=6549

[PATCH] new "powered by Cocoon" bitmap





--- Additional Comments From [EMAIL PROTECTED]  2002-02-19 18:27 ---
Good points :-)

I came up with three possible designs to overcome these issues.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: EmailTransformer and Mock Classes Update

[Stuart Roebuck]

Yes it is a contribution, but being rushed off my feet at the moment I 
didn't want to spend ages re-packaging it only to find that it wasn't 
suitable or of interest.

If it is suitable and of interest, then can you confirm that the following 
would be a suitable approach re: re-packaging?

1. Put the new transform under 
"/src/scratchpad/src/org/apache/cocoon/transformation"
2. Put the utility classes under 
"/src/scratchpad/src/org/apache/cocoon/util"
3. Rename the namespace to "http://apache.org/cocoon/sendmail/1.0";
4. Put the test code in "/src/test/org/apache/cocoon/..."
5. Put the mock classes under their existing package names within 
"src/test"

What do you mean by a stand-alone illustration of the Transformer, and 
where should I put it? (perhaps you could point me at the equivalent for 
one of the existing transformers that I can use as a template)

In submitting diffs against the CVS at Bugzilla, how do I do this - do I 
enter it as a new bug and post the diffs as plain text in the description?

Finally, if the code is in scratchpad and the tests are outside of 
scratchpad I imagine we'll have build problems, do we need a scratchpad 
test area, or should I just put the tests side-by-side with the code in 
scratchpad for separation if/when it moves to the main code?

Thanks,

Stuart.


On Tuesday, February 19, 2002, at 01:27 pm, Davanum Srinivas wrote:

> Stuart,
>
> Is this a contribution? If yes, Thanks for your contribution. Can i ask 
> you for a few more
> changes?
>
> 1. Test cases should be under xml-cocoon2\src\test
> 2. Change com.adolos.cocoon to something more that appropriate.
> 3. A stand-alone sample that can be used for illustration of how to use 
> the Transformer as well as
> for testing...
> 4. Please submit diffs against the latest CVS at Bugzilla (http://nagoya.
> apache.org). So that
> things don't get lost in the email deluge.
>
> Thanks,
> dims
>

Public Key - 1024D/88DD65AF 2001-11-23 Stuart Roebuck (Adolos)
  Key fingerprint = 89D9 E405 F8B1 9B22 0FA2  F2C1 9E57 5AB1 88DD 65AF
-
Stuart Roebuck  [EMAIL PROTECTED]
Systems Architect Java, XML, MacOS X, XP, etc.
ADOLOS   


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 6555] New: - Can't start first time (tomcat 4.0.2)

[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=6555

Can't start first time (tomcat 4.0.2)

   Summary: Can't start first time (tomcat 4.0.2)
   Product: Cocoon 2
   Version: 2.0.1
  Platform: Sun
OS/Version: Solaris
Status: NEW
  Severity: Normal
  Priority: Other
 Component: core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I downloaded http://xml.apache.org/cocoon/dist/cocoon-2.0.1-bin.zip and put
cocoon.war file into tomcat/webapps. When I try to access it throws an exception
with "root cause" :

java.lang.NoClassDefFoundError: javax/xml/transform/URIResolver
at java.lang.ClassLoader.findLoadedClass(Native Method)
at java.lang.ClassLoader.findLoadedClass(Compiled Code)
at org.apache.catalina.loader.WebappClassLoader.loadClass(Compiled Code)
at java.lang.ClassLoader.loadClass(Compiled Code)
at java.lang.ClassLoader.loadClass(Compiled Code)
at 
org.apache.avalon.excalibur.component.ExcaliburComponentManager.configure
(Compiled Code)
at org.apache.cocoon.Cocoon.configure(Cocoon.java:406)
at org.apache.cocoon.Cocoon.initialize(Cocoon.java:267)
at org.apache.cocoon.servlet.CocoonServlet.createCocoon
(CocoonServlet.java:991)
at org.apache.cocoon.servlet.CocoonServlet.init(CocoonServlet.java:308)
at org.apache.catalina.core.StandardWrapper.loadServlet(Compiled Code)
at org.apache.catalina.core.StandardWrapper.allocate(Compiled Code)
at org.apache.catalina.core.StandardWrapperValve.invoke(Compiled Code)
at org.apache.catalina.core.StandardPipeline.invokeNext(Compiled Code)
at org.apache.catalina.core.StandardPipeline.invoke(Compiled Code)
at org.apache.catalina.core.ContainerBase.invoke(Compiled Code)
at org.apache.catalina.core.StandardContextValve.invoke(Compiled Code)
at org.apache.catalina.core.StandardPipeline.invokeNext(Compiled Code)
at org.apache.catalina.core.StandardPipeline.invoke(Compiled Code)
at org.apache.catalina.core.ContainerBase.invoke(Compiled Code)
at org.apache.catalina.core.StandardContext.invoke(Compiled Code)
at org.apache.catalina.core.StandardHostValve.invoke(Compiled Code)
at org.apache.catalina.core.StandardPipeline.invokeNext(Compiled Code)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke(Compiled Code)
at org.apache.catalina.core.StandardPipeline.invokeNext(Compiled Code)
at org.apache.catalina.valves.ErrorReportValve.invoke(Compiled Code)
at org.apache.catalina.core.StandardPipeline.invokeNext(Compiled Code)
at org.apache.catalina.valves.AccessLogValve.invoke(Compiled Code)
at org.apache.catalina.core.StandardPipeline.invokeNext(Compiled Code)
at org.apache.catalina.core.StandardPipeline.invoke(Compiled Code)
at org.apache.catalina.core.ContainerBase.invoke(Compiled Code)
at org.apache.catalina.core.StandardEngineValve.invoke(Compiled Code)
at org.apache.catalina.core.StandardPipeline.invokeNext(Compiled Code)
at org.apache.catalina.core.StandardPipeline.invoke(Compiled Code)
at org.apache.catalina.core.ContainerBase.invoke(Compiled Code)
at org.apache.catalina.connector.http.HttpProcessor.process(Compiled 
Code)
at org.apache.catalina.connector.http.HttpProcessor.run(Compiled Code)
at java.lang.Thread.run(Compiled Code)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: EmailTransformer and Mock Classes Update

[Stuart Roebuck]

Yes it is a contribution, but being rushed off my feet at the moment I 
didn't want to spend ages re-packaging it only to find that it wasn't 
suitable or of interest.

If it is suitable and of interest, then can you confirm that the following 
would be a suitable approach re: re-packaging?

1. Put the new transform under 
"/src/scratchpad/src/org/apache/cocoon/transformation"
2. Put the utility classes under 
"/src/scratchpad/src/org/apache/cocoon/util"
3. Rename the namespace to "http://apache.org/cocoon/sendmail/1.0";
4. Put the test code in "/src/test/org/apache/cocoon/..."
5. Put the mock classes under their existing package names within 
"src/test"

What do you mean by a stand-alone illustration of the Transformer, and 
where should I put it? (perhaps you could point me at the equivalent for 
one of the existing transformers that I can use as a template)

In submitting diffs against the CVS at Bugzilla, how do I do this - do I 
enter it as a new bug and post the diffs as plain text in the description?

Finally, if the code is in scratchpad and the tests are outside of 
scratchpad I imagine we'll have build problems, do we need a scratchpad 
test area, or should I just put the tests side-by-side with the code in 
scratchpad for separation if/when it moves to the main code?

Thanks,

Stuart.


On Tuesday, February 19, 2002, at 01:27 pm, Davanum Srinivas wrote:
>
> Stuart,
>
> Is this a contribution? If yes, Thanks for your contribution. Can i ask 
> you for a few more
> changes?
>
> 1. Test cases should be under xml-cocoon2\src\test
> 2. Change com.adolos.cocoon to something more that appropriate.
> 3. A stand-alone sample that can be used for illustration of how to use 
> the Transformer as well as
> for testing...
> 4. Please submit diffs against the latest CVS at Bugzilla (http://nagoya.
> apache.org). So that
> things don't get lost in the email deluge.
>
> Thanks,
> dims


Public Key - 1024D/88DD65AF 2001-11-23 Stuart Roebuck (Adolos)
  Key fingerprint = 89D9 E405 F8B1 9B22 0FA2  F2C1 9E57 5AB1 88DD 65AF
-
Stuart Roebuck  [EMAIL PROTECTED]
Systems Architect Java, XML, MacOS X, XP, etc.
ADOLOS   


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 6554] - [PATCH] new interactive target in build to help in installing the scratchpad war

[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=6554

[PATCH] new interactive target in build to help in installing the scratchpad war 





--- Additional Comments From [EMAIL PROTECTED]  2002-02-19 17:10 ---
Created an attachment (id=1209)
installscratchpadwar new target

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 6554] New: - [PATCH] new interactive target in build to help in installing the scratchpad war

[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=6554

[PATCH] new interactive target in build to help in installing the scratchpad war 

   Summary: [PATCH] new interactive target in build to help in
installing the scratchpad war
   Product: Cocoon 2
   Version: Current CVS
  Platform: All
OS/Version: All
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


New interactive target in build to help in installing the scratchpad war.
The target is installscratchpadwar.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 6549] - [PATCH] new "powered by Cocoon" bitmap

[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=6549

[PATCH] new "powered by Cocoon" bitmap





--- Additional Comments From [EMAIL PROTECTED]  2002-02-19 16:50 ---
It does look pretty, but here are two comments:

The text in the font is small, and hard to read.
The text "made with" should be something like
"built with".

There are two solutions:

remove "made with" altogether, or increase the
size of the graphic a little (using "built with").

The word "built" sounds more industrial strength,
and works whether the site is actively powered by
Cocoon or merely pregenerated with it.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 6549] - [PATCH] new "powered by Cocoon" bitmap

[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=6549

[PATCH] new "powered by Cocoon" bitmap





--- Additional Comments From [EMAIL PROTECTED]  2002-02-19 16:45 ---
Created an attachment (id=1207)
Made with Cocoon bitmap

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 6549] New: - [PATCH] new "powered by Cocoon" bitmap

[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=6549

[PATCH] new "powered by Cocoon" bitmap

   Summary: [PATCH] new "powered by Cocoon" bitmap
   Product: Cocoon 2
   Version: Current CVS
  Platform: All
OS/Version: All
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


A new version of src/documentation/images/cocoon2-small.jpg that sucks a bit 
less.
Why don't we add it to each site page? xml.apache.org/cocoon/ and Avalon *are* 
powered by Cocoon.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Sun's SDK1.4 license terms

[Berin Loritsch]

Enke Michael wrote:
> Hi,
> as I see some people using SDK version 1.4:
> Did you guys read the license terms?
> Especially VERSION 1.4.X SUPPLEMENTAL LICENSE TERMS?
> 
> 5.  Notice of Automatic Software Updates from Sun.
> 6.  Notice of Automatic Downloads.
> 
> I refuse to use SDK 1.4 with such conditions.
> Has anybody more informations on that?


Considering that JDK 1.4 has the WebStart technology and the
Java PlugIn included, I believe those clauses are in there to
protect SUN from liability should you run an applet that does
bad things--and you give it permission

I am not aware of any automatic download features beyond the
those two technologies.  Sun cannot control what you download,
or the updates that those applications/applets will download.

The JavaPlugIn (if installed directly) will download necessary
parts of the JRE as needed, and update them as Sun provides
updates.  This is much like the WindowsUpdate approach.

Clause 5 is to handle updates to the JRE (i.e. bug fixes, etc.)
without having to download a 40+ MB archive.

Clause 6 is to protect Sun from damages should you run WebStart/
Java PlugIn on third-party software--which may in turn provide
automatic updates of the software on your system.


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
 - Benjamin Franklin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Portal ArrayIndexOutOfBounds error

[Carsten Ziegeler]

Hi Bert,

do you have a stack trace available from the logs?

Carsten

-Original Message-
From: Bert Van Kets [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 19, 2002 3:23 PM
To: [EMAIL PROTECTED]
Subject: Portal ArrayIndexOutOfBounds error


I'm getting ArrayIndexOutOfBounds errors on the portal.  I log in as a guest
or administrator and at different points I'm getting the error.  It happens
on different occasions, but most of the time whenI request the main page
after the login.  Here's the error:
Cocoon 2 - Internal server error

type fatal
message Failed to execute pipeline.
description org.apache.cocoon.ProcessingException: Failed to execute
pipeline.: java.lang.ArrayIndexOutOfBoundsException
sender org.apache.cocoon.servlet.CocoonServlet
source Cocoon servlet
request-uri
/cocoon/sunspotdemo-portlets
path-info
sunspotdemo-portlets

The Cocoon error log reports the same error without any other mentions.  I'm
getting the error on Win2K AND under SuSE Linux 7.3.  I used todays CVS
build (after the modification to the SourceResolver of Carsten Ziegeler) on
both platforms.  Both platforms also use Tomcat 4.0.1 and JDK 1.3.1_02.
Work directories were erased on both platforms as well.
It seems to me that every time the user list is accessed I get this error.
Bert
- To
unsubscribe, e-mail: [EMAIL PROTECTED] For additional
commands, email: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/environment AbstractEnvironment.java

[cziegeler]

cziegeler02/02/19 06:26:52

  Modified:src/java/org/apache/cocoon/environment
AbstractEnvironment.java
  Log:
  This should be now the correct file URI handling...
  
  Revision  ChangesPath
  1.9   +8 -4  
xml-cocoon2/src/java/org/apache/cocoon/environment/AbstractEnvironment.java
  
  Index: AbstractEnvironment.java
  ===
  RCS file: 
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/environment/AbstractEnvironment.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- AbstractEnvironment.java  19 Feb 2002 12:02:01 -  1.8
  +++ AbstractEnvironment.java  19 Feb 2002 14:26:52 -  1.9
  @@ -73,7 +73,7 @@
*
* @author mailto:[EMAIL PROTECTED]";>Giacomo Pati
* @author mailto:[EMAIL PROTECTED]";>Carsten Ziegeler
  - * @version CVS $Id: AbstractEnvironment.java,v 1.8 2002/02/19 12:02:01 cziegeler 
Exp $
  + * @version CVS $Id: AbstractEnvironment.java,v 1.9 2002/02/19 14:26:52 cziegeler 
Exp $
*/
   public abstract class AbstractEnvironment extends AbstractLoggable implements 
Environment {
   
  @@ -339,14 +339,18 @@
   if (systemId.length() == 0) {
   source = this.sourceHandler.getSource(this, 
this.context.toExternalForm());
   } else if (systemId.charAt(0) == '/') {
  -source = this.sourceHandler.getSource(this, this.context.getProtocol() +
  +// windows: absolute paths can start with / followed by a drive letter
  +if (systemId.length() > 2 && systemId.charAt(2) == ':') {
  +source = this.sourceHandler.getSource(this, "file:" + systemId);
  +} else {
  +source = this.sourceHandler.getSource(this, 
this.context.getProtocol() +
 ":" + systemId);
  +}
   } else if (systemId.indexOf(":") > 1) {
   source = this.sourceHandler.getSource(this, systemId);
   // windows: absolute paths can start with drive letter
   } else if (systemId.length() > 1 && systemId.charAt(1) == ':') {
  -source = this.sourceHandler.getSource(this, this.context.getProtocol() +
  -  ":/" + systemId);
  +source = this.sourceHandler.getSource(this, "file:/" + systemId);
   } else {
   source = this.sourceHandler.getSource(this, this.context, systemId);
   }
  
  
  

--
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail:  [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Portal ArrayIndexOutOfBounds error

[Bert Van Kets]

I'm getting ArrayIndexOutOfBounds errors on the portal.  I log in as
a guest or administrator and at different points I'm getting the
error.  It happens on different occasions, but most of the time
whenI request the main page after the login.  Here's the 
error:
Cocoon 2 - Internal server error
type fatal
message Failed to execute pipeline.
description org.apache.cocoon.ProcessingException: Failed
to execute pipeline.: java.lang.ArrayIndexOutOfBoundsException
sender org.apache.cocoon.servlet.CocoonServlet
source Cocoon servlet
request-uri
/cocoon/sunspotdemo-portlets
path-info
sunspotdemo-portlets
The Cocoon error log reports the same error without any other
mentions.  I'm getting the error on Win2K AND under SuSE Linux
7.3.  I used todays CVS build (after the modification to the
SourceResolver of Carsten Ziegeler) on both platforms.  Both
platforms also use Tomcat 4.0.1 and JDK 1.3.1_02.  Work directories
were erased on both platforms as well.
It seems to me that every time the user list is accessed I get this
error.
Bert



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: HTTPHTMLGenerator

[reinhard_poetz]

I think so ... but I havn't had the time of thinking it through. In my
opinion I only have to check whether the src starts with "http" or not. If this is
true I use my way of reading the src otherwise I will use the
SourceResolver.

The second thing is making it Cachable ... Maybe someone could help me!

After solving those two problems I'll post the diff at
http://nagoya.apache.org

Regards,
Reinhard

> Reinhard,
> 
> Can we replace the existing HTMLGenerator with this one? The objective is
> that we should enhance
> the code with what we learn from our experiences :) 
> 
> Can you please check existing samples with this Generator and then post a
> diff to existing
> HTMLGenerator at Bugzilla (http;//nagoya.apache.org). 
> 
> Thanks,
> dims
> 
> --- Reinhard_Pötz <[EMAIL PROTECTED]> wrote:
> > I had the same problem as described in bug #6520
> > (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101402671004632&w=2).
> I
> > solved this problem using the HTTPClient
> (commons-httpclient-20011012.jar).
> > 
> > The use of the HTTPClient makes it possible to use the POST-paramters
> and
> > HEADER-parameters of the client/cocoon-connection.
> > 
> >   Browser   --->Cocoon--->   HTTP-Resource
> >Request   HTTPHTMLGenerator
> >  using HEAD & POST of
> >  the Request
> > 
> > I called this generator (based on the HTML-Generator) HTTPHTMLGenerator.
> > 
> > Using this generator solved my problem posted last december (using
> Cocoon2
> > as Proxy):
> > - http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100758023726189&w=2
> > - http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100763795331083&w=2
> > 
> > The HTTPHTMLConnector makes it very easy to integrate existing web
> > applications into cocoon.
> > 
> > Attached you find the sources (HTTPHTMLGenerator.java) - tested with
> Cocoon
> > 2.0.1/Tomcat4.0.1/Win2K-Prof
> > 
> > Reinhard Pötz
> > 
> 
> > ATTACHMENT part 2 application/octet-stream name=HTTPHTMLGenerator.java
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
> 
> 
> =
> Davanum Srinivas - http://jguru.com/dims/
> 
> __
> Do You Yahoo!?
> Yahoo! Sports - Coverage of the 2002 Olympic Games
> http://sports.yahoo.com
> 

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: EmailTransformer and Mock Classes Update

[Davanum Srinivas]

Stuart,

Is this a contribution? If yes, Thanks for your contribution. Can i ask you for a few 
more
changes?

1. Test cases should be under xml-cocoon2\src\test
2. Change com.adolos.cocoon to something more that appropriate.
3. A stand-alone sample that can be used for illustration of how to use the 
Transformer as well as
for testing...
4. Please submit diffs against the latest CVS at Bugzilla (http://nagoya.apache.org). 
So that
things don't get lost in the email deluge.

Thanks,
dims

--- Stuart Roebuck <[EMAIL PROTECTED]> wrote:
> The first real incarnation of our EmailTransformer has been uploaded with 
> unit tests and associated mock classes to:
> 
>   
> 
> I've taken a look at the David Bigwood's Metatomix SendMailTransformer 
> contribution and decided they are sufficiently different that attempting 
> to merge them wasn't going to be a quick task.
> 
> David's code seems to be a good option for creating emails with HTML 
> content - I've made no explicit provision for these in ours though it may 
> just work with an included 'file' derived from an HTML source in the 
> sitemap.
> 
> The key drive for our code was to be able to send emails with attachments 
> and inline graphic files.   This version now does that by allowing you to 
> reference any source file to be included in the email.  As the file is 
> specified in the useful sitemap file reference syntax it is possible to 
> include graphics or other files that have been generated through the 
> sitemap.  (at least it seems to work :-) )
> 
> Here's an example of the syntax:
> 
> > 
> >   http://adolos.com/cocoon/email/1.0";>
> > [EMAIL PROTECTED]
> > Fred Bloggs <[EMAIL PROTECTED]>
> > [EMAIL PROTECTED]
> > [EMAIL PROTECTED]
> > Test
> > The body text
> >  > disposition="inline" />
> > Some more text
> >  > "attachment" />
> >   
> > 
> 
> For multiple recipients the email addresses can be comma delimited or you 
> can supply multiple entries.
> 
> I've created a NonClosingBufferedInputStream class to enable an 
> InputStreamDataHandler to be used to re-read from the same InputStream, 
> which feels like a bit of a cludge, but it works.  Any suggestions of a 
> more elegant solutions are most welcome!
> 
> I've also updated the Mock Classes a little to allow a Source to be 
> pre-determined in unit tests.
> 
> Stuart.
> 
> 
> 
> Public Key - 1024D/88DD65AF 2001-11-23 Stuart Roebuck (Adolos)
>   Key fingerprint = 89D9 E405 F8B1 9B22 0FA2  F2C1 9E57 5AB1 88DD 65AF
> -
> Stuart Roebuck  [EMAIL PROTECTED]
> Systems Architect Java, XML, MacOS X, XP, etc.
> ADOLOS   
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 


=
Davanum Srinivas - http://jguru.com/dims/

__
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: CookieMatcher

[Davanum Srinivas]

Maciek,

Is it possible to contribute a small sample that we can test with? If you can please 
add the
sample as well as the code below at BugZilla (http://nagoya.apache.org/). The sample 
will help
people understand how to use the CookieMatcher as well as for testing.

Thanks,
dims

--- Maciek Kaminski <[EMAIL PROTECTED]> wrote:
> Please feel free to add attached CookieMatcher into Cocoon codebase, if You 
> find it useful.
> 
> Maciek Kaminski
> [EMAIL PROTECTED]
> 
> 
> > package org.apache.cocoon.matching;
> 
> import org.apache.avalon.framework.parameters.Parameters;
> import org.apache.avalon.framework.logger.AbstractLoggable;
> 
> import org.apache.cocoon.Constants;
> import org.apache.cocoon.environment.ObjectModelHelper;
> import org.apache.cocoon.environment.Cookie;
> import org.apache.cocoon.environment.Request;
> import org.apache.cocoon.environment.Response;
> import org.apache.cocoon.environment.Cookie;
> import org.apache.cocoon.sitemap.PatternException;
> 
> import java.util.Map;
> import java.util.HashMap;
> 
> /**
>  *
>  * Matches cookies agains given name. Returns name, value pairs for all cookies.
>  * @author mailto:[EMAIL PROTECTED]";>Maciek Kaminski
>  */
> public class CookieMatcher extends AbstractLoggable implements Matcher
> {
> public Map match (String pattern, Map objectModel, Parameters parameters) throws
> PatternException {
> 
> if (pattern == null) {
> throw new PatternException("No cookie name given.");
> }
> 
> Request request = (Request) objectModel.get(Constants.REQUEST_OBJECT);
> 
> Cookie[] cookies = request.getCookies();
> HashMap result = null;
> 
> if (cookies != null) {
> for ( int i = 0; i < cookies.length; i++) {
> Cookie cookie = cookies[i];
> if (cookie.getName().equals(pattern)) {
> result = new HashMap();
> for ( int j = 0; j < cookies.length; j++) {
> result.put(cookie.getName(), cookie.getValue());
> }
> }
> }
> }
> 
> if (result == null) {
> getLogger().debug("Cookie'" + pattern + "' not set.");
> }
> 
> return result;
> }
> }
> 
> > -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]


=
Davanum Srinivas - http://jguru.com/dims/

__
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: HTTPHTMLGenerator

[Davanum Srinivas]

Reinhard,

Can we replace the existing HTMLGenerator with this one? The objective is that we 
should enhance
the code with what we learn from our experiences :) 

Can you please check existing samples with this Generator and then post a diff to 
existing
HTMLGenerator at Bugzilla (http;//nagoya.apache.org). 

Thanks,
dims

--- Reinhard_Pötz <[EMAIL PROTECTED]> wrote:
> I had the same problem as described in bug #6520
> (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101402671004632&w=2). I
> solved this problem using the HTTPClient (commons-httpclient-20011012.jar).
> 
> The use of the HTTPClient makes it possible to use the POST-paramters and
> HEADER-parameters of the client/cocoon-connection.
> 
>   Browser   --->Cocoon--->   HTTP-Resource
>Request   HTTPHTMLGenerator
>  using HEAD & POST of
>  the Request
> 
> I called this generator (based on the HTML-Generator) HTTPHTMLGenerator.
> 
> Using this generator solved my problem posted last december (using Cocoon2
> as Proxy):
> - http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100758023726189&w=2
> - http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100763795331083&w=2
> 
> The HTTPHTMLConnector makes it very easy to integrate existing web
> applications into cocoon.
> 
> Attached you find the sources (HTTPHTMLGenerator.java) - tested with Cocoon
> 2.0.1/Tomcat4.0.1/Win2K-Prof
> 
> Reinhard Pötz
> 

> ATTACHMENT part 2 application/octet-stream name=HTTPHTMLGenerator.java
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]


=
Davanum Srinivas - http://jguru.com/dims/

__
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: INTEGRATING STRUTS AND COCOON

[Piroumian, Konstantin]

This question is hardly related to Cocoon, especially to cocoon-dev mail
list.

> HI ,
>
> How to map cocoon to *.xml path .

Change your URL mapping for Cocoon servlet in WEB-INF/web.xml from '/' to
'*.xml' (or anything you like, maybe '*.xsp').

>
> It will be great if you could provide with some sample code for how to
handle
> this complete process . I have done uptil handling the request thru Struts
> but then I do not know how to forward it to cocoon . Let me know if any
Logic
> sheets are also required.

To forward request to Cocoon you should use something like this in your
action:

RequestDispatcher rd =
getServletContext().getRequestDispatcher('path/to/page.xml');
rd.forward(request, response);
return null;

or just use an action forward in struts-config.xml:

 
 


This questions are better be asked in cocoon-users or struts-users lists.

Regards,
Konstantin Piroumian
>
> Thanks,
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Core libraries

[Davanum Srinivas]

Ugo,

1. Remove all libraries from optional directory before you build cocoon.
2. Remove the whole section "" found under xsp-language from
cocoon.xconf. Those entries use bsf jar.

Thanks,
dims


--- Carsten Ziegeler <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> you have to remove the libraries from the lib/opt directory *before*
> building cocoon. The resulting webapp should be runnable without
> any changes.
> 
> Carsten
> 
> > -Original Message-
> > From: Ugo Cei [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, February 19, 2002 9:28 AM
> > To: [EMAIL PROTECTED]
> > Subject: Core libraries
> > 
> > 
> > I've recently decided that the simplest way to start a new Cocoon 
> > project is to prepare a "minimal" configuration as a template and start 
> > adding to it whatever is needed. I've got the latest CVS, compiled it 
> > (WITH scratchpad) and tried to strip sitemap.xmap and cocoon.xconf to 
> > their barebones (you can look at the attached files).
> > 
> > The problem is with the libraries. It looks like there are two 
> > "optional" jars that must be included or you get an error.
> > 
> > The first one is maybeupload_1-0-5pre3.jar. If I don't put it in 
> > WEB-INF/libs I get a stacktrace with this error:
> > 
> > root cause
> > 
> > java.lang.NoClassDefFoundError: 
> > uk/co/weft/maybeupload/MaybeUploadRequestWrapper
> > 
> > The full page is in the attached status.html file.
> > 
> > The second one is bsf-2.2.jar. If I don't include it in WEB-INF/lib I 
> > get a page telling me that the sitemap could not be compiled and the 
> > following message is in the logs:
> > 
> > ERROR   (2002-02-19) 09:22.07:682   [sitemap] (/cocoon/status) 
> > HttpProcessor[8080][4]/Handler: Error compiling sitemap
> > java.lang.NoClassDefFoundError: com/ibm/bsf/BSFException
> > 
> > I can't find where in the sitemap or xconf file these classes are 
> > referred to.
> > 
> > My configuration is the following:
> > 
> > - Linux RedHat 7.1
> > - Sun JDK 1.4.0 (with xalan-2.2.0.jar, xerces-1.4.4.jar, xml-apis.jar
> >in jre/lib/endorsed)
> > - Cocoon 2 from CVS as of February 18.
> > - Tomcat 4.0.1
> > 
> > If we can solve this issue, we might provide this kind of configuration 
> > in the distribution, as it seems it could be useful.
> > 
> > Ugo
> > 
> > -- 
> > Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
> > P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
> > Phone: +39.0382.525100 - E-mail: [EMAIL PROTECTED]
> > 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 


=
Davanum Srinivas - http://jguru.com/dims/

__
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

HTTPHTMLGenerator

[Reinhard Pötz]

I had the same problem as described in bug #6520
(http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101402671004632&w=2). I
solved this problem using the HTTPClient (commons-httpclient-20011012.jar).

The use of the HTTPClient makes it possible to use the POST-paramters and
HEADER-parameters of the client/cocoon-connection.

  Browser   --->Cocoon--->   HTTP-Resource
   Request   HTTPHTMLGenerator
 using HEAD & POST of
 the Request

I called this generator (based on the HTML-Generator) HTTPHTMLGenerator.

Using this generator solved my problem posted last december (using Cocoon2
as Proxy):
- http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100758023726189&w=2
- http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100763795331083&w=2

The HTTPHTMLConnector makes it very easy to integrate existing web
applications into cocoon.

Attached you find the sources (HTTPHTMLGenerator.java) - tested with Cocoon
2.0.1/Tomcat4.0.1/Win2K-Prof

Reinhard Pötz



HTTPHTMLGenerator.java
Description: Binary data

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/environment AbstractEnvironment.java

[cziegeler]

cziegeler02/02/19 04:02:02

  Modified:src/java/org/apache/cocoon/environment
AbstractEnvironment.java
  Log:
  Fix for file uri handling
  
  Revision  ChangesPath
  1.8   +3 -3  
xml-cocoon2/src/java/org/apache/cocoon/environment/AbstractEnvironment.java
  
  Index: AbstractEnvironment.java
  ===
  RCS file: 
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/environment/AbstractEnvironment.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- AbstractEnvironment.java  12 Feb 2002 20:56:56 -  1.7
  +++ AbstractEnvironment.java  19 Feb 2002 12:02:01 -  1.8
  @@ -73,7 +73,7 @@
*
* @author mailto:[EMAIL PROTECTED]";>Giacomo Pati
* @author mailto:[EMAIL PROTECTED]";>Carsten Ziegeler
  - * @version CVS $Id: AbstractEnvironment.java,v 1.7 2002/02/12 20:56:56 vgritsenko 
Exp $
  + * @version CVS $Id: AbstractEnvironment.java,v 1.8 2002/02/19 12:02:01 cziegeler 
Exp $
*/
   public abstract class AbstractEnvironment extends AbstractLoggable implements 
Environment {
   
  @@ -338,11 +338,11 @@
   Source source;
   if (systemId.length() == 0) {
   source = this.sourceHandler.getSource(this, 
this.context.toExternalForm());
  -} else if (systemId.indexOf(":") > 1) {
  -source = this.sourceHandler.getSource(this, systemId);
   } else if (systemId.charAt(0) == '/') {
   source = this.sourceHandler.getSource(this, this.context.getProtocol() +
 ":" + systemId);
  +} else if (systemId.indexOf(":") > 1) {
  +source = this.sourceHandler.getSource(this, systemId);
   // windows: absolute paths can start with drive letter
   } else if (systemId.length() > 1 && systemId.charAt(1) == ':') {
   source = this.sourceHandler.getSource(this, this.context.getProtocol() +
  
  
  

--
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail:  [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: FileWritingTransformer and Windows

[Carsten Ziegeler]

Hi,

I'm not sure, but I think windows needs two slashes after "file:" - the
backslashes are not required.

How do you construct the whole file URI? Do you use the SourceResolver?
If you for example use the relative path "mount/editor/docs/test1.xml" and
put it into the SourceResolver.resolve method, it will give you
automatically
the correct path independent from the OS.

HTH
Carsten

-Original Message-
From: Bert Van Kets [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 19, 2002 12:34 PM
To: [EMAIL PROTECTED]
Subject: FileWritingTransformer and Windows


Has anybody been able to use the FileWriterTransformer under Windows?
I'm getting file access errors from Cocoon (Could not read resource
file:/C:/tomcat/webapps/cocoon/mount/editor/docs/test1.xml), althought the
test1.xml file does exist!  The tests 1 through 4 work perfectly under
Linux.  Does Windows need backslashes and/or a double slash after the file
protocol?
Bert
- To
unsubscribe, e-mail: [EMAIL PROTECTED] For additional
commands, email: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Generating pipeline's content to xml

[Carsten Ziegeler]

> Rogier Peters wrote:
> 
> Hi,
> 
> I'm looking for a way to generate a pipeline's content for a given url,
> instead of the result of its execution. Basically I'd be asking cocoon:
> what pipeline would you use for this url?
> 
> In other words: the url:
> http://localhost:8080/hello.html.sitemap 
> 
> would have to yield the response:
> 
>   
>   
>   
> 
> 
> I realize this example would be easily solved by xls-transformation of
> the sitemap, but afaik this isn't possible for more complex mappings.
> 
Yes, a stylesheet would fail as soon as you use pattern matching or
selectors or actions delivering values.

> I'm guessing the best/quickest/only solution would be to write a custom
> generator for this. Any other suggestions?
> 
Hm, I think this is a use-case for the views concept of Cocoon, so
requesting http://localhost:8080/hello.html?cocoon-view=sitemap should
deliver your above example in XML. If you want to write a custom generator
you might end up with reimplementing all the sitemap logic.

I haven't looked into the new treeprocessor of Cocoon, but I feel that it
might be rather simple to extend it with this special view.

What do you think, Sylvain?

Carsten


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

FileWritingTransformer and Windows

[Bert Van Kets]

Has anybody been able to use the FileWriterTransformer under
Windows?
I'm getting file access errors from Cocoon (Could not read resource
file:/C:/tomcat/webapps/cocoon/mount/editor/docs/test1.xml),
althought the test1.xml file does exist!  The tests 1 through 4 work
perfectly under Linux.  Does Windows need backslashes and/or a
double slash after the file protocol?
Bert



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

CookieMatcher

[Maciek Kaminski]

Please feel free to add attached CookieMatcher into Cocoon codebase, if You 
find it useful.

Maciek Kaminski
[EMAIL PROTECTED]




package org.apache.cocoon.matching;

import org.apache.avalon.framework.parameters.Parameters;
import org.apache.avalon.framework.logger.AbstractLoggable;

import org.apache.cocoon.Constants;
import org.apache.cocoon.environment.ObjectModelHelper;
import org.apache.cocoon.environment.Cookie;
import org.apache.cocoon.environment.Request;
import org.apache.cocoon.environment.Response;
import org.apache.cocoon.environment.Cookie;
import org.apache.cocoon.sitemap.PatternException;

import java.util.Map;
import java.util.HashMap;

/**
 *
 * Matches cookies agains given name. Returns name, value pairs for all cookies.
 * @author mailto:[EMAIL PROTECTED]";>Maciek Kaminski
 */
public class CookieMatcher extends AbstractLoggable implements Matcher
{
public Map match (String pattern, Map objectModel, Parameters parameters) throws 
PatternException {

if (pattern == null) {
throw new PatternException("No cookie name given.");
}

Request request = (Request) objectModel.get(Constants.REQUEST_OBJECT);

Cookie[] cookies = request.getCookies();
HashMap result = null;

if (cookies != null) {
for ( int i = 0; i < cookies.length; i++) {
Cookie cookie = cookies[i];
if (cookie.getName().equals(pattern)) {
result = new HashMap();
for ( int j = 0; j < cookies.length; j++) {
result.put(cookie.getName(), cookie.getValue());
}
}
}
}

if (result == null) {
getLogger().debug("Cookie'" + pattern + "' not set.");
}

return result;
}
}



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: some remnants of old JaxpParser

[Carsten Ziegeler]

> David Crossley wrote:
> 
> 
> OK now that is a non-issue, i can say that the Entity Resolver
> is still happy after the move to Excalibur JaxpParser.

Great to hear this!

Thanks David.

Carsten


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: some remnants of old JaxpParser

[David Crossley]

Carsten Ziegeler wrote:
> > David Crossley wrote:
> > 
> >  
> > Perhaps i did not express myself clearly. I am trying to
> > verify that the Catalog Entity Resolver is still functioning
> > properly after the move to Excalibur JaxpParser.
> > 
> > When i look at the startup logs, then there is one mention
> > of the old role "shorthand resolver" (which then uses the
> > old parser role "shorthand parser"). This entry is then
> > followed by two mentions of the new resolver role
> > "shorthand entity-resolver" (which use the new parser
> > role "shorthand xml-parser").
> > 
> > I cannot find where the first entry (using the old resolver
> > and old parser) are coming from, and so why there is
> > a mixture of old and new.
> 
> The old roles (resolver and parser) are still in the cocoon.roles
> for compatibility , so when this roles file is parsed by the component
> manager, it immediately creates a pool for the old components as
> they are poolable. So, the messages will still appear in the logs - 
> the only solution to avoid them is to remove the Poolable marker
> from the components.
> 
> Carsten

Thanks for explaining that Carsten. You would not believe
how long i have pondered over the meaning of those startup
log messages.

OK now that is a non-issue, i can say that the Entity Resolver
is still happy after the move to Excalibur JaxpParser.
--David


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Finally live worldwide

[Michael Homeijer]

Hi,

Finally after some time performance tuning, checking the performance of
Cocoon 2, a site we build for a customer was tuned on Cocoon 1. We now have
acceptable and stable performance. The site is highly dynamic because
virtually everything is personalized, the data (prices, etc) that is
displayed and the layout of some tables are based on extensive customer
profiles. (This will only be visible to large accounts and people having a
valid Sun agreement).

Our customer went worldwide (except for unicode languages) with the
following site with Cocoon 1 underneath:

www.sun-catalogue.com

We are planning a new (dynamic) site with Cocoon 2 for another customer that
will hopefully give us enough confidence in performance and scalability to
propose a migration traject for this site.

Can somebody add this site to the list of live sites for Cocoon 1?

TIA
Michael

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: [FYI] Cocoon 0.9

[Steven Noels]

> -Original Message-
> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]]
> Sent: maandag 18 februari 2002 14:23
> To: Apache Cocoon
> Subject: [FYI] Cocoon 0.9
>
>
> I was looking for some old pictures in my archive CDs and
> found the very
> first release of Apache Cocoon, so old that it never left my computer,
> until now where you can find it here:
>
>  http://www.apache.org/~stefano/archeology/Cocoon0.9.zip
>
> It's 50Kb big and the creation date says 8 February 1999.

Does anyone remember the very similar docproc?

http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Nov-1997/0216.html

and thanks to google's cache

http://www.google.com/search?q=cache:javalab.uoregon.edu/ser/software/do
cproc/index.xml
http://www.google.com/search?q=cache:javalab.uoregon.edu/ser/software/do
cproc/news.xml

It was this project that inspired me to track serverside XSLT
frameworks, and after a while Cocoon came into existence :-)




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: some XSLT benchmarks

[Torsten Curdt]

On Mon, 18 Feb 2002, Jacek R. Ambroziak wrote:

> Took me a while to recreate XSLTC driver for XSLTMark
> but it appears to be working now. Here are the results:
>
> Dell Inspiron 8000
> Intel Pentium III (Coppermine) 900 MHz
> 256 MB RAM
> Red Hat Linux 7.1, kernel 2.4.16
>
> "magic numbers"  (w/ test 'dbonerow' disabled)
>
> XSLTC493
> XT  377
> Saxon 235
> XalanJ165
>
> ('dbonerow' enabled; 2 iterations)
>
> XT  452
> XSLTC359
> Saxon 253
> XalanJ168
>
> Today's implementation of XSLTC handles the 'dbonerow' really badly.
> What it gains elsewhere it loses on this benchmark.
>
> Otherwise, the results are not bad for XSLTC :-)
> [and remember:  translets run on small devices]
>
> I am curious how Stefano's numbers will look like.

...this looks promising :) That's factor 2-3 faster...
--
Torsten



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Core libraries

[Carsten Ziegeler]

Hi,

you have to remove the libraries from the lib/opt directory *before*
building cocoon. The resulting webapp should be runnable without
any changes.

Carsten

> -Original Message-
> From: Ugo Cei [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 19, 2002 9:28 AM
> To: [EMAIL PROTECTED]
> Subject: Core libraries
> 
> 
> I've recently decided that the simplest way to start a new Cocoon 
> project is to prepare a "minimal" configuration as a template and start 
> adding to it whatever is needed. I've got the latest CVS, compiled it 
> (WITH scratchpad) and tried to strip sitemap.xmap and cocoon.xconf to 
> their barebones (you can look at the attached files).
> 
> The problem is with the libraries. It looks like there are two 
> "optional" jars that must be included or you get an error.
> 
> The first one is maybeupload_1-0-5pre3.jar. If I don't put it in 
> WEB-INF/libs I get a stacktrace with this error:
> 
> root cause
> 
> java.lang.NoClassDefFoundError: 
> uk/co/weft/maybeupload/MaybeUploadRequestWrapper
> 
> The full page is in the attached status.html file.
> 
> The second one is bsf-2.2.jar. If I don't include it in WEB-INF/lib I 
> get a page telling me that the sitemap could not be compiled and the 
> following message is in the logs:
> 
> ERROR   (2002-02-19) 09:22.07:682   [sitemap] (/cocoon/status) 
> HttpProcessor[8080][4]/Handler: Error compiling sitemap
> java.lang.NoClassDefFoundError: com/ibm/bsf/BSFException
> 
> I can't find where in the sitemap or xconf file these classes are 
> referred to.
> 
> My configuration is the following:
> 
> - Linux RedHat 7.1
> - Sun JDK 1.4.0 (with xalan-2.2.0.jar, xerces-1.4.4.jar, xml-apis.jar
>in jre/lib/endorsed)
> - Cocoon 2 from CVS as of February 18.
> - Tomcat 4.0.1
> 
> If we can solve this issue, we might provide this kind of configuration 
> in the distribution, as it seems it could be useful.
> 
>   Ugo
> 
> -- 
> Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
> P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
> Phone: +39.0382.525100 - E-mail: [EMAIL PROTECTED]
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Sun's SDK1.4 license terms

[Enke Michael]

Hi,
as I see some people using SDK version 1.4:
Did you guys read the license terms?
Especially VERSION 1.4.X SUPPLEMENTAL LICENSE TERMS?

5.  Notice of Automatic Software Updates from Sun.
6.  Notice of Automatic Downloads.

I refuse to use SDK 1.4 with such conditions.
Has anybody more informations on that?

Regards,
Michael

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Core libraries

[Ugo Cei]

I've recently decided that the simplest way to start a new Cocoon 
project is to prepare a "minimal" configuration as a template and start 
adding to it whatever is needed. I've got the latest CVS, compiled it 
(WITH scratchpad) and tried to strip sitemap.xmap and cocoon.xconf to 
their barebones (you can look at the attached files).

The problem is with the libraries. It looks like there are two 
"optional" jars that must be included or you get an error.

The first one is maybeupload_1-0-5pre3.jar. If I don't put it in 
WEB-INF/libs I get a stacktrace with this error:

root cause

java.lang.NoClassDefFoundError: 
uk/co/weft/maybeupload/MaybeUploadRequestWrapper

The full page is in the attached status.html file.

The second one is bsf-2.2.jar. If I don't include it in WEB-INF/lib I 
get a page telling me that the sitemap could not be compiled and the 
following message is in the logs:

ERROR   (2002-02-19) 09:22.07:682   [sitemap] (/cocoon/status) 
HttpProcessor[8080][4]/Handler: Error compiling sitemap
java.lang.NoClassDefFoundError: com/ibm/bsf/BSFException

I can't find where in the sitemap or xconf file these classes are 
referred to.

My configuration is the following:

- Linux RedHat 7.1
- Sun JDK 1.4.0 (with xalan-2.2.0.jar, xerces-1.4.4.jar, xml-apis.jar
   in jre/lib/endorsed)
- Cocoon 2 from CVS as of February 18.
- Tomcat 4.0.1

If we can solve this issue, we might provide this kind of configuration 
in the distribution, as it seems it could be useful.

Ugo

-- 
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: [EMAIL PROTECTED]




http://apache.org/cocoon/sitemap/1.0";>



 

  
   

   

   

   

   






  
   

   

   

   
messages
translations
   

   

   

   

   

   
  



  
   
  

  
   
-//WAPFORUM//DTD WML 1.1//EN
http://www.wapforum.org/DTD/wml_1.1.xml
ASCII
yes
   

   
-//W3C//DTD SVG 2303 Stylable//EN
http://www.w3.org/TR/2000/03/WD-SVG-2303/
   
   


  

   

   

   

   
  org.apache.cocoon.SessionState
   

   
  next-state
   

   
  referer
   
  

  
   















   

   

   

   

   

   

   

   

   

   

   
  

  
   

   

   

   

   

   
  
 




 
  
   
  

  


  
  
  
   
  

 



 
 





 
 




 


  
  
   
   



   
  

 
   

   

   



   

   

   

   

   

   

   


   


   

  
 










  
  
  

http://apache.org/cocoon/sitemap/1.0"/>
  








  
  
  
  
  





  
  
  




  
  
  





  
  
  
  
  
  






  
  
  
  
components, views, action-sets, resources, 
pipelines
  

  
  
  
  
pipeline
  
  
  
  
  
  
  
  
  
  
  
  
  

  
sitemap, components, pipelines
  
  
  
sitemap, components, pipeline, 
handle-errors
  

  

  
sitemap, components, pipeline, 
handle-errors
  

  
  
  

  

  

  

  

  

  

  



  
















  
  


  
  
  

  


  





  
  


  


  







  
  





  
  
  
  
  

  

  
  
 
 

 
 
  

  
  
  
 
 
 
 
 
 
 
 
 
  
  

  
  
 
 
  

  
  

  
  





  

  
  



  

  
  


  

  
  


  

  
  

  
  
  
  
  





  

  
  
  
  
  

  
  http://apache.org/xsp"/>

  
  




  
  http://apache.org/xsp/request/2.0"/>
  

   


  
  http://apache.org/xsp/response/2.0"/>
  




  
  http://apache.org/xsp/session/2.0"/>
  




  
  http://apache.org/xsp/cookie/2.0"/>
  




  
  http://apache.org/cocoon/SQL/v2"/>
  



  
  http://apache.org/xsp/log/2.0"/>
  



  
  http://apache.org/xsp/util/2.0"/>
  




  
  http://apache.org/xsp/form-validator/2.0"/>
  




  
  http://apache.org/xsp/sel/1.0