Re: Possible threading issues with xsltc + BCEL ???

2003-02-06 Thread Andy Lewis

I've hit this - it only happens when compiling the stylesheet though. Concurrent 
requests right at
startup do not do wel...I had no workaround...but that would be a GOOD THING to have 
fixed...
 Hi Cocooners,

 Are their any other Cocoon users having Threading Issues with xsltc?

 Its seems that if you have a translat being compiled at the same time by two  or 
more threads
 (instances of TraxTransformer) you will get issues because  BCEL is not (by design) 
threadsafe
 as it users static methods and  variables which seem to be overwriting each other???

 Once the Translets get compiled however, such threading issues disappear.

 Does anyone have expirence with this?

 Regards,
 Michael Melhem

 Ps After locally patching org.apache.xalan.xsltc.trax.TemplatesHandlerImpl.java with 
some synch
 code around the compile block, all seems OK.




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


-- 
The heights of genius are only measurable by the depths of stupidity.



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

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




Re: Photo Album sample?

2002-12-09 Thread Andy Lewis

snip/
 I have got a personal photo album that I have prepared using Cocoon. It uses the  
ImageReader
snip/

I would also be interested in the if you have no objections...thanks!

-- 
The heights of genius are only measurable by the depths of stupidity.



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

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




Re: R: Strings to SAX events

2002-11-14 Thread Andy Lewis

This should really be a code snippet...


 Hi Damian,

 Perhaps it helps : If you are in XSP, the following tags resolve it without java 
code :

 ?xml version=1.0 encoding=ISO-8859-1?
 xsp:page language=java xmlns:xsp=http://apache.org/xsp;
 xmlns:util=http://apache.org/xsp/util/2.0;
 ...
 util:include-expr
 util:exprxsp:expr
 yourXMLString
 /xsp:expr/util:expr
 /util:include-expr
 ...

 Regards,

 Ludovic

 - Original Message -
 From: Damian Chojna [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Thursday, November 14, 2002 6:02 PM
 Subject: Re: R: Strings to SAX events


 Hi Reinhard,

 thanks for the last post. I also need to add a string as XML elements into an XSP 
generator
 and I used your suggestion (below). It seems to work well, but I have two questions:

 1) I've noticed that the API states that the Parser is deprecated. I'm currently 
using 2.0.3,
 if I choose to use this method will it effect me being able to move to a newer 
version of
 cocoon at some time in the
 future?

 2) When I generate my XML elements it seems that the parser is including the ?xml
 version=1.0 encoding=UTF-8? header. Is there a way to get the parser not to 
include it,
 as it is causing me problems?

 Thanks in advance!
 Damian.




 [EMAIL PROTECTED] wrote:

  Luca,
 
  In a generator I use flowing code within the generate()-Method. Maybe
 this
  helps:
 
  parser = (Parser)this.manager.lookup(Parser.ROLE);
  parser.setConsumer(super.xmlConsumer);
  parser.parse(new InputSource(new StringReader(sb.toString(;
 
  Regards,
  Reinhard




 - Please check 
that your
 question  has not already been answered in the FAQ before posting.
 http://xml.apache.org/cocoon/faq/index.html

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





 - Please check 
that your
 question  has not already been answered in the FAQ before posting.
 http://xml.apache.org/cocoon/faq/index.html

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


-- 
The heights of genius are only measurable by the depths of stupidity.



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

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




Re: Cocoon Portal - User Roles

2002-11-13 Thread Andy Lewis

We are doing this with XSPs to provide the XML, rather the the SQL transformer. But we 
are
actually part way through replacing all of the file-based pipelines for these 
componenets with XSP
driven database equivalents. so far, only a few problems have cropped up
 Hi Matthew,

 If I understand it right, I have to change the sunrise-newrole.xml into something 
that the sql
 transformer would understand and remove the cinclude and writesource transformer on 
the
 pipeline?

 In this case...

 Whats the advantage of using transformer than an action?

 In the end of this map:match pattern it is returning an xml like this...

 ?xml version=1.0 encoding=UTF-8 ?
- !--  $Id: sunrise-newrole.xml,v 1.1 2002/06/03 11:45:54 cziegeler Exp $  
Description: Add
a new role --  - addrole xmlns:source=http://apache.org/cocoon/source/1.0;
xmlns:session=http://cocoon.apache.org/session/1.0; - sourceResult
  executionsuccess/execution
  messagecontent inserted at: roles/message
  behaviourinsert/behaviour
  actionoverwritten/action
  
sourcefile:/C:/ApacheGroup/Tomcat4.1/webapps/cocoon/myportal/resources/sunrise-roles.xml/source
   serializerxml/serializer
  /sourceResult
  /addrole
 If I'd use an action, do I have to serialized these kinds of xml?

 And can you tell me where the sunrise-newrole resource is being called and returned 
to?

 Thanks again.
 Richard

  - Original Message -
  From: Matthew Langham
  To: [EMAIL PROTECTED]
  Sent: Tuesday, November 12, 2002 8:16 PM
  Subject: RE: Cocoon Portal - User Roles


  
  Since the the new role function in the portal sample is mapped to new-role
  uri=cocoon:raw:/sunrise-newrole/ uri, it is using this sitemap snippet right?

  map:match pattern=sunrise*
  map:generate src=resources/sunrise{1}.xml/
  map:transform type=session/
  map:transform type=cinclude/
  map:transform type=write-source/
  map:transform src=styles/portal.xsl/
  map:serialize type=xml/
  /map:match

  and the documentations says that

  The new-role resource creates a new role in the system. It gets the parameters 
type with the
  value role and role with the new rolename.

  Where is the type and role parameter?
  and why does it have to serialized in an xml type in the end?
  

  You need to take a look at the file sunrise-newrole.xml. That file contains most of 
the dirty
  work. The transformers session, cinclude and writesource act on the information 
contained in
  there. Because sunrise-newrole.xml also flows through the pipeline it is then 
formatted by the
  stylesheet and returned to the browser. It is serialized to xml because it is being 
used
  inside the portal (in this case).

  If you wanted to write this to a database you would need to change the 
sunrise-newrole.xml and
  use the sqltransformer instead of cinclude and write-source. In all this should 
take you
  around 5 minutes or less to adapt. :-)

  So it really is quite simple really.

  Matthew
  --
  Open Source Group   Cocoon { Consulting, Training, Projects }
    Matthew Langham, 
SN AG,
  Klingenderstrasse 5, D-33100 Paderborn Tel:+49-5251-1581-30  [EMAIL PROTECTED] -
  http://www.s-und-n.de 
- Cocoon
  book:
http://www.amazon.com/exec/obidos/ASIN/0735712352/needacake-20
  Weblog:
http://radio.weblogs.com/0103021/
  
-Original Message-
From: Richard Reyes [mailto:seyer_drahcir;hotmail.com]
Sent: Tuesday, November 12, 2002 12:53 PM
To: cocoon-users
Subject: RE: Cocoon Portal - User Roles




Hi Matthew / Guys,

Just want to confirm some things

Since the the new role function in the portal sample is mapped to new-role
uri=cocoon:raw:/sunrise-newrole/ uri, it is using this sitemap snippet right?

map:match pattern=sunrise*
map:generate src=resources/sunrise{1}.xml/
map:transform type=session/
map:transform type=cinclude/
map:transform type=write-source/
map:transform src=styles/portal.xsl/
map:serialize type=xml/
/map:match

and the documentations says that

The new-role resource creates a new role in the system. It gets the parameters 
type with
the value role and role with the new rolename.

Where is the type and role parameter?
and why does it have to serialized in an xml type in the end?

Also, for the sunrise-newrole resource, the only thing this pipeline does is save 
a new role
in the xml file ( sunrise-roles.xml )? whose responsible for displaying the next 
page after
saving the new role?

And since this sitemap snippet is called inside a map:pipeline internal only 
clause I 

Re: Separation of concerns?

2002-11-12 Thread Andy Lewis

I have found it a great advantage to have someone who is a developer, not a designer, 
work with
the designer to create the XSLT to produce a particular design. Most designers 
struggle with
dynamic components and web-related efficiency concerns. The developer and designer 
working
together usually produces a good rendition of the design, but adapted in a way that 
makes sense.
Never let a pure designer produce your templates.
 I have a (multi-part) question about the suggested separation of concerns  that it 
is
 proposed that Cocoon achieves.

 I would like to ask how Cocoon is being used in a production environment,  
specifically how
 does separation of roles work out. Does it actually work  in practice? How easy is 
it in
 production settings to find graphics  designers who are also fluent in XSLT?

 Aren't such bi-skilled people essential to achieve the implementation of  the 
style concern?
 Or, in practice, are real designers and real XSLT  coders working together on 
the XSLT
 stylesheets?

 I guess that the suspicion that is lurking at the back of my mind is that  the 
confusion of
 concerns (to coin a phrase) is, to some extent, being  shuffled off into the 
style box. Of
 course, that may be a signficant  improvement over other workflows.

 I can see pretty clearly the cleanness of the current approach for  
programmers/administrators
 ... designers don't touch the content nor the  sitemaps ... but I do have slight 
doubts about
 the cleanness of the style  concern. Or maybe my doubt is about the realisticness of 
finding
 graphics  designers comfortable to code in XSLT.

 I notice, too, that style is little mentioned in the online documentation  and 
doesn't appear
 as a term in the index of the Langham/Ziegeler book.  That makes me wonder if others 
either
 have doubts too about the style  concern or, perhaps, haven't looked (yet?) in a 
detailed way
 at how this  will work.

 I wonder if what has mostly been happening up to now is XSLT-coders  dabbling with 
design? :)

 I would be interested in any stories about the reactions of pure graphics  
designers in a
 production setting when first faced with the Cocoon approach  and how they and, I 
suspect,
 XSLT-programmer colleagues actually worked out  a practical workflow.

 Andrew Watt


 - Please check 
that your
 question  has not already been answered in the FAQ before posting.
 http://xml.apache.org/cocoon/faq/index.html

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


-- 
The heights of genius are only measurable by the depths of stupidity.



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

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




XSP Logicsheet Questions...

2002-11-08 Thread Andy Lewis

I am just starting to really get into XSP, having worked with various other parts of 
Cocoon
since 1.3  and I  have three questions regarding XPS Logicsheets:

First, it appears that a logicsheet must declared to be used and that the only place 
to declare a
logic sheet is in the xconf file. Is this correct?
Second, is the xconf file only reload at Cocoon restart time, or are there other 
events that
trigger a reload as well?
Third, are changes to a logicsheet picked up and used in a running Cocoon environment, 
or are they
only caught when the configuration is read? If changes are picked up, are they a 
dependancy of the
pipeline, or are they only picked up when the XSP itself is recompiled due to another 
trigger,
such as being updated.
Thanks!

-- 
The heights of genius are only measurable by the depths of stupidity.



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

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