Re: XML input module (was: RE: Nice changes!)

[Christian Haul]

On 01.Oct.2002 -- 04:09 PM, Hunsberger, Peter wrote:
> > Think of the various matchers and selectors in cocoon. What if you
> > could just plug-in the data source? There wouldn't be sources * match
> > type matchers.
> 
> This gets me to a pet issue of mine:  If I ever get the time I'd really like
> to build a version of the site map pipeline handler based XSLT that has all
> context information available to it as XML; the request variables, session
> data, etc.   The XSLT could either act as a filter to some SAX event handler
> or you could use XSLT extensions to invoke the Cocoon components directly or
> you could use some form of import mechanism to invoke the Cocoon components.
> The first is perhaps more pure to XSLT, but it could have strange
> transformation/filtering requirements and be a little opaque to those not
> comfortable with XSLT ;-) More on imports in a moment...

Well, go ahead: use the request generator - I think there is no
session generator &c., otherwise you could aggregate the other context
information together - and you are almost done. Add some methods to
access sitemap components (actions only, I guess - you could copy them
from the sitemap implementation or JSCocoon.java). This is probably
limited to produce XML (i.e. well-formed content, no binaries), but
hey!

[...]
> that invokes other transforms.  As such, XSLT import semantics might be a
> reasonable way to go, but I doubt you could use them in native form since
> some Cocoon components seem orthogonal to the transform process?  However,
> for the normal case you might have to instantiate parsing and transformation
> many fewer times.  

I can't judge this one. I feel that it should not be a real problem,
especially since those components might be of little use in your
scenario anyway.

> But none of this has any advantage over examining the same data in an XML
> tree via XSLT?

No, it's just that it is usable in places where there's no XSLT
available, the data is no XML or the data is very small.

[...]

> Yes, that certainly makes sense, you're extending the sitemap capabilities
> to build in some of the capabilities of XSLT: but just the XPath portion.  I
> guess what I'd rather see (now that I understand what you're trying to do),
> is a sitemap pipeline parser that was XSLT transform driven (user definable
> of course).  It likely wouldn't replace all of the sitemap, but rather would
> be aimed at replacing just the pipeline handling.  Ultimately my reason for
> doing this is that the sitemap pipeline (as it exists today) ends up
> encoding a lot of business and presentation rules.  I want to have these
> rules be configurable from a database (of some form).  As such, I want to be
> able to generate XML (from my database) that invokes rules, which are
> written in XSLT.  You're getting a long way there, but XPath by itself isn't
> sufficient for all types of rule handling.

So, maybe you like the flow idea better? In 2.1-dev you can code your
business logic in javascript. But even there it is handy to have this :-)

> > XSP is completely absent from this picture. Actually, there's no
> > support to use it from XSP as of today.
> 
> If I understand you're essentially creating many components reusable from
> the pipeline and trying to have a single set of semantics to extract data
> from these components into the pipeline?  I'd guess the XSP folks would want
> similar capabilities, but I can see why that's not your concern!

Yes, but not just the pipeline but anywhere. Actions use it, so do
Matchers and Selectors. It would not be much of a problem to make it
accessible from XSP as well. It's just not done, yet.

Chris.
-- 
C h r i s t i a n   H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

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

DO NOT REPLY [Bug 13163] - [PATCH] TextSerializer should use text/plain MIME type instead of text/text

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

[PATCH] TextSerializer should use text/plain MIME type instead of text/text

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|TextSerializer should use   |[PATCH] TextSerializer
   |text/plain MIME type instead|should use text/plain MIME
   |of text/text|type instead of text/text

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

DO NOT REPLY [Bug 13186] New: - after java exception in XSP, Cocoon continues with pipeline

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

after java exception in XSP, Cocoon continues with pipeline

   Summary: after java exception in XSP, Cocoon continues with
pipeline
   Product: Cocoon 2
   Version: 2.0.3
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Major
  Priority: Other
 Component: sitemap components
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When I have a java exception in XSP code, in a pipeline with transform stages, 
everything should get short circuited as soon as the exception occurs, that is, 
no output from the pipeline should occur.  Instead, Cocoon should switch to an 
error handler pipeline (if there is one) or to some default error message.  
This was the behavior in C2.0.2.  In C2.0.3, what happens is that the pipeline 
continues through the stages and produces output.  If an error handler is set 
up, that *also* gets run and produces output.  The result is output something 
like  ... error handler output here ...  ... original page 
stuff here 

I've checked this both in our web app and in the (otherwise unmodified) 
distribution web app (cocoon.war).

This is easily reproduced.  Here's a sitemap entry:

  
  
  


Here's bleah.xml:

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

  int fudge = Integer.parseInt("Hello");

  


and here's bleah.xsl:

http://www.w3.org/1999/XSL/Transform"; version="1.0">

  

  Hello!
  Hey!

   



If done in cocoon.war, you should see both the system error handler, then the 
headers "Hello" and "Hey" at the bottom.

-Christopher

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

[Summary] RE: [control flow] Reloading Scripts

[Reinhard Poetz]

Hi Ovidiu,

Thank you! Your patch solved the problem with the reload.

Regards,
Reinhard

> -Original Message-
> From: Ovidiu Predescu [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, October 01, 2002 9:42 AM
> To: Reinhard Poetz
> Cc: [EMAIL PROTECTED]
> Subject: Re: [control flow] Reloading Scripts
> 
> 
> Hi Reinhard,
> 
> Please test the latest changes in the CVS, the code should work now.
> 
> I still have to implement an automatic test of this feature, so that we 
> can prevent this bug from happening in the future. Until then, please 
> let me know if you still see problems.
> 
> Regards,
> Ovidiu
> 
> On Sunday, September 29, 2002, at 09:43  AM, Reinhard Poetz wrote:
> 
> > Ovidiu,
> >
> > Yestery I did some tests with the control flow - everything worked 
> > fine but
> > the scripts have not been reloaded. In the cocoon.xconf I set the 
> > check-time
> > for the flow-interpreters to 1 and then to 0 but both values didn't 
> > help.
> > Only a restart led to a "reload" of the scripts. I know there were 
> > ?similar?
> > (at least the symptom is the same) problems 5 weeks ago:
> > [http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102956711018659&w=2].
> >
> > Regards
> > Reinhard
> >
> >
> -- 
> Ovidiu Predescu <[EMAIL PROTECTED]>
> http://webweavertech.com/ovidiu/weblog/ (Weblog)
> http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, 
> Emacs ...)
> 

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

RE: XML input module (was: RE: Nice changes!)

[Hunsberger, Peter]

> Say, you want to insert data to a database. Some data stems from request
> parameters, some from the session and some from request attributes set
> by another action.  In order to make this possible, the database action
> needs to be flexible enough to do this. It used to read from request
> parameters only.

In our case, the XSLT has access to all the data in the request and the
session.  If it's going to be round tripped, then we do so, but the action
doesn't need to determine where a particular value came from.  The original
XSLT took care of determining that.  If you're handling a lot of data in
this manner then doing round trips obviously doesn't make sense, but we'll
get to that in a bit...

> Say, you want to chose your pipeline in sitemap depending on some
> request parameter value, or a request header, or the current time
> of the day. You need to code an action to export this value to as
> sitemap parameter.  With InputModules you can just say  src="context://docs/{request:/parameters/foo}.xml"/> or  src="context://docs/list-{date:now}.xml"/>
> 
> Think of the various matchers and selectors in cocoon. What if you
> could just plug-in the data source? There wouldn't be sources * match
> type matchers.

This gets me to a pet issue of mine:  If I ever get the time I'd really like
to build a version of the site map pipeline handler based XSLT that has all
context information available to it as XML; the request variables, session
data, etc.   The XSLT could either act as a filter to some SAX event handler
or you could use XSLT extensions to invoke the Cocoon components directly or
you could use some form of import mechanism to invoke the Cocoon components.
The first is perhaps more pure to XSLT, but it could have strange
transformation/filtering requirements and be a little opaque to those not
comfortable with XSLT ;-) More on imports in a moment...

Using XSLT in such a way seems cleaner than constantly inventing new site
map semantics and parameters.  Of course the performance of such a beast
might be sub-optimal.  Then again, there's likely a lot of Cocoon overhead
that would be eliminated; you essentially end up with a master transform
that invokes other transforms.  As such, XSLT import semantics might be a
reasonable way to go, but I doubt you could use them in native form since
some Cocoon components seem orthogonal to the transform process?  However,
for the normal case you might have to instantiate parsing and transformation
many fewer times.  

> Say, you want to use the skin specified in a session attribute, if not
> present a system default or if present a request parameter. That's what
> the DefaultsMetaModule does (well, only default and one source as of now).
> Plug-in the source and you're happy.
> 
> Another advantage: If you have used your personal instances of these
> modules (highly advisable!), you could change the storage easily. So,
> you don't like to read the data from request parameters, a session is
> more secure? Well just switch to another InputModule.

But none of this has any advantage over examining the same data in an XML
tree via XSLT?

> JXPath comes into this, as for the request you may want to access
> parameters, attributes, headers, &c. In addition, I needed to access
> values from a java.util.Map. So, why have a request-attributes module
> and a request-parameters module if JXPath would provide this almost for
> free with a consistent interface that everyone is familiar with?

Yes, that certainly makes sense, you're extending the sitemap capabilities
to build in some of the capabilities of XSLT: but just the XPath portion.  I
guess what I'd rather see (now that I understand what you're trying to do),
is a sitemap pipeline parser that was XSLT transform driven (user definable
of course).  It likely wouldn't replace all of the sitemap, but rather would
be aimed at replacing just the pipeline handling.  Ultimately my reason for
doing this is that the sitemap pipeline (as it exists today) ends up
encoding a lot of business and presentation rules.  I want to have these
rules be configurable from a database (of some form).  As such, I want to be
able to generate XML (from my database) that invokes rules, which are
written in XSLT.  You're getting a long way there, but XPath by itself isn't
sufficient for all types of rule handling.

> XSP is completely absent from this picture. Actually, there's no
> support to use it from XSP as of today.

If I understand you're essentially creating many components reusable from
the pipeline and trying to have a single set of semantics to extract data
from these components into the pipeline?  I'd guess the XSP folks would want
similar capabilities, but I can see why that's not your concern!


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

DO NOT REPLY [Bug 11401] - [PATCH] upload bug

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

[PATCH] upload bug

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|upload bug  |[PATCH] upload bug



--- Additional Comments From [EMAIL PROTECTED]  2002-10-01 20:43 ---
marked as [PATCH]

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

DO NOT REPLY [Bug 11401] - upload bug

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

upload bug





--- Additional Comments From [EMAIL PROTECTED]  2002-10-01 20:41 ---
Created an attachment (id=3303)
patch for FilePartFile.toString()

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

DO NOT REPLY [Bug 11401] - upload bug

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

upload bug

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |



--- Additional Comments From [EMAIL PROTECTED]  2002-10-01 20:38 ---
the current toString() method of FilePartFile only returns the file name.
MaybeUpload used to return the whole path (via File.toString()). So a more
compatible way is using File.toString() in FilePartFile.toString() (patch follows).

additional comment:

I find the method getFilePath() in FilePart quite irritating cause it doesn't
return the file path of the uploaded file. Instead it returns the filename which
was transmitted by the user agent (which may be the original path if uploaded
with IE or only the original filename if uploaded with Moz).
A more intuitive name for this method would be: getOriginalFileName()

-peter

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

Re: XML input module (was: RE: Nice changes!)

[Christian Haul]

On 01.Oct.2002 -- 01:20 PM, Hunsberger, Peter wrote:
> >> I've been following this discussion for the last week or so and suddenly
> >> this morning I had to start questioning exactly what the true purpose of
> all
> >> this is?  The idea of being able to dig out a value based on a precedence
> >> hierarchy makes sense, but XML and XSLT already have very good mechanisms
> >> for doing this (and Cocoon provides perfectly adequate ways of building
> XML
> >> and running XSLT!).  Consider, for instance:
> >
> > You are absolutely right. It's just that these InputModules serve the
> purpose
> > of returning small values, and that often multiple times from the same
> source.
> > The DatabaseActions make use of this heavily. I wouldn't want to use
> pipelines
> > for obtaining 30 values through the use of the request generator and some
> xslt
> > resulting in 30 executions of this pipeline.
> 
> I guess, that's part of the problem I have with this: I'm much more
> comfortable with producing XML directly as database output and using it
> directly in XSLT than I am in using the half procedural half functional XSP
> model (though perhaps you're using this some other way?).  If you have an
> XML dataset and XSLT processing you usually don't need to reference a value
> multiple times (you use XSL keys, parameters or variables if you do).  If
> you aggregate all your XML sources you don't need multiple processing steps
> (except as desired to separate business logic from presentation logic).  So,
> once more I'm still wondering about exactly what the conceptual problem is
> that all of this is really supposed to solve?

Say, you want to insert data to a database. Some data stems from request
parameters, some from the session and some from request attributes set
by another action.  In order to make this possible, the database action
needs to be flexible enough to do this. It used to read from request
parameters only.

Say, you want to chose your pipeline in sitemap depending on some
request parameter value, or a request header, or the current time
of the day. You need to code an action to export this value to as
sitemap parameter.  With InputModules you can just say  or 

Think of the various matchers and selectors in cocoon. What if you
could just plug-in the data source? There wouldn't be sources * match
type matchers.

Say, you want to use the skin specified in a session attribute, if not
present a system default or if present a request parameter. That's what
the DefaultsMetaModule does (well, only default and one source as of now).
Plug-in the source and you're happy.

Another advantage: If you have used your personal instances of these
modules (highly advisable!), you could change the storage easily. So,
you don't like to read the data from request parameters, a session is
more secure? Well just switch to another InputModule.

JXPath comes into this, as for the request you may want to access
parameters, attributes, headers, &c. In addition, I needed to access
values from a java.util.Map. So, why have a request-attributes module
and a request-parameters module if JXPath would provide this almost for
free with a consistent interface that everyone is familiar with?

XSP is completely absent from this picture. Actually, there's no
support to use it from XSP as of today.

Chris.
-- 
C h r i s t i a n   H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

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

RE: XML input module (was: RE: Nice changes!)

[Hunsberger, Peter]

>> I've been following this discussion for the last week or so and suddenly
>> this morning I had to start questioning exactly what the true purpose of
all
>> this is?  The idea of being able to dig out a value based on a precedence
>> hierarchy makes sense, but XML and XSLT already have very good mechanisms
>> for doing this (and Cocoon provides perfectly adequate ways of building
XML
>> and running XSLT!).  Consider, for instance:
>
> You are absolutely right. It's just that these InputModules serve the
purpose
> of returning small values, and that often multiple times from the same
source.
> The DatabaseActions make use of this heavily. I wouldn't want to use
pipelines
> for obtaining 30 values through the use of the request generator and some
xslt
> resulting in 30 executions of this pipeline.

I guess, that's part of the problem I have with this: I'm much more
comfortable with producing XML directly as database output and using it
directly in XSLT than I am in using the half procedural half functional XSP
model (though perhaps you're using this some other way?).  If you have an
XML dataset and XSLT processing you usually don't need to reference a value
multiple times (you use XSL keys, parameters or variables if you do).  If
you aggregate all your XML sources you don't need multiple processing steps
(except as desired to separate business logic from presentation logic).  So,
once more I'm still wondering about exactly what the conceptual problem is
that all of this is really supposed to solve?

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

Re: XML input module (was: RE: Nice changes!)

[Christian Haul]

On 02.Oct.2002 -- 01:32 AM, Jeff Turner wrote:
> On Tue, Oct 01, 2002 at 10:17:40AM +0200, Christian Haul wrote:

> > The degree, to what they digest the data is not set to
> > stone. SessionModule could, for instance, just return the session
> > object.
> 
> Yes, it would have to, to accommodate the most general 'upstream' module,
> JXPath. but then you've got such a loose contract between modules as to
> be almost useless:
> 
> public interface InputModule {
> Object getData();
> }
> 
> At least with the current module (attributes and values), we can have
> modules like DefaultsMetaModule which can default *any* 'upstream'
> module's values.
> 
> > If we believe that jxpath is the one and only interface that the
> > InputModules should expose, I'm fine with that. Then it would make
> > perfectly sense to make all of them inherit from
> > AbstractJXPathModule. Obviously, all complex ones do currently.
> > 
> > But what about the others. How will they fit in e.g. DateMetaInput
> > (parses a string and returns a java.util.Date)?
> 
> However it currently works. Putting the question the other way, what sort
> of inter-module data model is sufficiently general to allow JXPath on one
> hand, and DateMetaModule on the other?

OK, I'm almost convined. 
 
> > Granted, the simple
> > ones like NullInput (always returns "null") won't need it.
> > 
> > Another point may be that when switching to jxpath, would that impact
> > the interface? Does getAttributeNames() still return a reasonable
> > enumeration?
> 
> Hmm, probably not. It wouldn't make much sense to iterate through all
> possible XPaths.

OTOH this method is AFAIR only used to create a compabitility feature for
migration between the two DatabaseActions. With the original ones you 
could say values from "name*" and collapse values of parameters 
"name1", "name2", and "namesomething" to an array.

Since InputModules were available only in scratchpad sofar, shall we
remove this method and agree that all InputModules need to provide an
XPath interface? I.e. getAttribute() and getAttributeValues() accept an
XPath expression for the parameter name?

We would need to do that before 2.0.4 since I've moved them out of
scratchpad recently.

Chris.
-- 
C h r i s t i a n   H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

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

Re: XML input module (was: RE: Nice changes!)

[Christian Haul]

On 01.Oct.2002 -- 09:46 AM, Hunsberger, Peter wrote:
> I've been following this discussion for the last week or so and suddenly
> this morning I had to start questioning exactly what the true purpose of all
> this is?  The idea of being able to dig out a value based on a precedence
> hierarchy makes sense, but XML and XSLT already have very good mechanisms
> for doing this (and Cocoon provides perfectly adequate ways of building XML
> and running XSLT!).  Consider, for instance:

You are absolutely right. It's just that these InputModules serve the purpose
of returning small values, and that often multiple times from the same source.
The DatabaseActions make use of this heavily. I wouldn't want to use pipelines
for obtaining 30 values through the use of the request generator and some xslt
resulting in 30 executions of this pipeline.

We all are familiar with xpath, so why not use this to specify what values
should be taken. 

Chris.
-- 
C h r i s t i a n   H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

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

Re: Where did the authentication framework go?

[Ugo Cei]

I just updated the sources form CVS and it seems that the authentication 
framework is working again now.

Thanks to whomever fixed it :-).

Ugo

-- 
Ugo Cei - http://www.beblogging.com/blog/


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

Re: EsqlQuery changes

[Christian Haul]

On 01.Oct.2002 -- 05:45 PM, [EMAIL PROTECTED] wrote:
> Christian, you added in EsqlQuery in prepareCall:
> 
>   preparedStatement.setMaxRows( ...
> 
> This breaks the rowCount() function which is vital for our application to
> get the absolute count of pages. Is it really necessary?
> Do you mind if I remove it? 

Not at all, this is was a patch from neil which apeared to be sane, see

http://mailman.real-time.com/pipermail/cocoon-users/2002-August/020812.html

(Couldn't find the first post)

Chris.
-- 
C h r i s t i a n   H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

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

cvs commit: xml-cocoon2/src/test/anteater sitemapReload.xml

[ovidiu]

ovidiu  2002/10/01 09:06:35

  Modified:src/test/anteater sitemapReload.xml
  Log:
  Use a regexp pattern to check the value. Correctly identify the
  paragraph element containing the value.
  
  Revision  ChangesPath
  1.3   +2 -2  xml-cocoon2/src/test/anteater/sitemapReload.xml
  
  Index: sitemapReload.xml
  ===
  RCS file: /home/cvs/xml-cocoon2/src/test/anteater/sitemapReload.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- sitemapReload.xml 1 Oct 2002 09:30:11 -   1.2
  +++ sitemapReload.xml 1 Oct 2002 16:06:35 -   1.3
  @@ -25,7 +25,7 @@
   
 
  -
  +
 
   
   
  @@ -43,7 +43,7 @@
   
 
  -
  +
 
   
   
  
  
  

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

EsqlQuery changes

[tcurdt]

Christian, you added in EsqlQuery in prepareCall:

  preparedStatement.setMaxRows( ...

This breaks the rowCount() function which is vital for our application to
get the absolute count of pages. Is it really necessary?
Do you mind if I remove it? 
--
Torsten

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

Re: XML input module (was: RE: Nice changes!)

[Jeff Turner]

On Tue, Oct 01, 2002 at 10:17:40AM +0200, Christian Haul wrote:
> On 01.Oct.2002 -- 01:31 AM, Jeff Turner wrote:
...
> > It is universally pluggable, only the plugin mechanism is inheritance,
> > not composition. The current model is:
> > 
> > AbstractJXPathModule .
> >  | RequestModule
> >  | SessionModule
> >  | XMLModule
> >  + 
> > 
> > Where each subclass just chooses what Object to let JXPath use.
> > 
> > If I've understood you, you're proposing to change from inheritance to
> > composition. Create a JXPathModule that takes as 'input', *any* other
> > module:
> > 
> > 
> >   
> > 
> 
> Right.
> 
> > 
> > The JXPath module then provides XPath access to the input-module's
> > what? This is my question above. A Module's public interface doesn't
> > allow access to the raw object model that JXPath needs. It's always
> > pre-digested, accessible through tokens that the Module defines. For
> > instance, how would the above XML snippet translate to code? How could
> > XMLModule functionality be achieved?
> 
> The degree, to what they digest the data is not set to
> stone. SessionModule could, for instance, just return the session
> object.

Yes, it would have to, to accommodate the most general 'upstream' module,
JXPath. but then you've got such a loose contract between modules as to
be almost useless:

public interface InputModule {
Object getData();
}

At least with the current module (attributes and values), we can have
modules like DefaultsMetaModule which can default *any* 'upstream'
module's values.

> If we believe that jxpath is the one and only interface that the
> InputModules should expose, I'm fine with that. Then it would make
> perfectly sense to make all of them inherit from
> AbstractJXPathModule. Obviously, all complex ones do currently.
> 
> But what about the others. How will they fit in e.g. DateMetaInput
> (parses a string and returns a java.util.Date)?

However it currently works. Putting the question the other way, what sort
of inter-module data model is sufficiently general to allow JXPath on one
hand, and DateMetaModule on the other?

> Granted, the simple
> ones like NullInput (always returns "null") won't need it.
> 
> Another point may be that when switching to jxpath, would that impact
> the interface? Does getAttributeNames() still return a reasonable
> enumeration?

Hmm, probably not. It wouldn't make much sense to iterate through all
possible XPaths.


--Jeff

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

RE: XML input module (was: RE: Nice changes!)

[Hunsberger, Peter]

I've been following this discussion for the last week or so and suddenly
this morning I had to start questioning exactly what the true purpose of all
this is?  The idea of being able to dig out a value based on a precedence
hierarchy makes sense, but XML and XSLT already have very good mechanisms
for doing this (and Cocoon provides perfectly adequate ways of building XML
and running XSLT!).  Consider, for instance:














It's pretty much trivial to write a generator that would create such a
structure directly and pretty much trivial to use existing generators
(except perhaps for session data) to generate such a structure using
aggregation from the sitemap (name spaces and element names aside).  It's
also easy to write XSLT that will parse such a structure and pick up a value
based on any precedence hierarchy that one might want.

I'm not really trying to discourage the creation of a similar mechanism that
is more friendly to the Java half of Cocoon, in particular since there are
performance implications to doing this via XSLT.  However, it's likely
you're going to need a transform in any case and adding one more template to
traverse an XPath to a value isn't going to add that much more overhead.
Moreover, any truly powerful module configuration mechanism should likely be
XML based and that will add it's own parsing and interpretation overhead
(and perhaps be as complicated as writing an XSLT template) and of course
documentation.

I guess the I'm wondering if I wouldn't rather see development efforts go
into creating generalized generators and optimizing the existing code. It
seems to me that many times people forget about exploiting the capabilities
of XSLT and end up writing lots of unneeded Java code.   Of course, this
being open source, you're completely free to ignore this suggestion, but if
you have specific reasons why doing this via XML/XSLT is problematic I'd be
interested in hearing them.

-Original Message-
From: Christian Haul [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 01, 2002 3:18 AM
To: [EMAIL PROTECTED]
Subject: Re: XML input module (was: RE: Nice changes!)


On 01.Oct.2002 -- 01:31 AM, Jeff Turner wrote:
> On Mon, Sep 30, 2002 at 04:56:36PM +0200, Christian Haul wrote:
> > On 30.Sep.2002 -- 09:59 PM, Jeff Turner wrote:
> > > On Mon, Sep 30, 2002 at 01:19:04PM +0200, Christian Haul wrote:
> > > > I would prefer that module to be a "meta" module that can be
> > > > configured to take input from any source (i.e. another InputModule)
> > > > rather than do the reading itself.
> > > 
> > > >From what I gather, Meta modules take in as input, a) another module,
b)
> > > a configuration. In this scenario, what object would we feed JXPath?
> > > Where does the DOM come from?
> > 
> > As already pointed out in others' replies, jxpath can operate on more
> > than DOM, i.e. uses reflexion to obtain the get and set methods.
> 
> > > This might already be possible, since I think JXPath can traverse from
> > > the Session object to a DOM.
> > 
> > Yes. The current request InputModule uses jxpath and allows this
> > functionality. However, I believe this is a feature that deserves to
> > be universally plugable.
> 
> It is universally pluggable, only the plugin mechanism is inheritance,
> not composition. The current model is:
> 
> AbstractJXPathModule .
>  | RequestModule
>  | SessionModule
>  | XMLModule
>  + 
> 
> Where each subclass just chooses what Object to let JXPath use.
> 
> If I've understood you, you're proposing to change from inheritance to
> composition. Create a JXPathModule that takes as 'input', *any* other
> module:
> 
> 
>   
> 

Right.

> 
> The JXPath module then provides XPath access to the input-module's
> what? This is my question above. A Module's public interface doesn't
> allow access to the raw object model that JXPath needs. It's always
> pre-digested, accessible through tokens that the Module defines. For
> instance, how would the above XML snippet translate to code? How could
> XMLModule functionality be achieved?

The degree, to what they digest the data is not set to
stone. SessionModule could, for instance, just return the session
object.

If we believe that jxpath is the one and only interface that the
InputModules should expose, I'm fine with that. Then it would make
perfectly sense to make all of them inherit from
AbstractJXPathModule. Obviously, all complex ones do currently.

But what about the others. How will they fit in e.g. DateMetaInput
(parses a string and returns a java.util.Date)? Granted, the simple
ones like NullInput (always returns "null") won't need it.

Another point may be that when switching to jxpath, would that imp

RE: Strange behavior in SQLTransforme Cocoon 2.0.3

[Luca Morandini]

Luca,

since I know you're such a good guy, I fixed your problem...

...seriously now:

The Cocoon 2.0.3 version of SQLTransformer lacks the characters method, which in 
Cocoon 2.0.2 took care of the proper concatenation
of queries (something super.characters(), apparently cannot do).

Here's my patch (just a slightly modified version of the Cocoon 2.0.2 method):

public void characters( char ary[], int start,
int length ) throws SAXException {
if ( current_state != SQLTransformer.STATE_INSIDE_VALUE_ELEMENT &&
 current_state != SQLTransformer.STATE_INSIDE_QUERY_ELEMENT &&
 current_state != SQLTransformer.STATE_INSIDE_ESCAPE_STRING ) {
super.characters( ary, start, length );
}
getLogger().debug( "RECEIVED CHARACTERS: " +
   new String( ary, start, length ) );
this.getCurrentQuery().addQueryPart( new String( ary, start, length ) 
);
}

Could someone test it properly and put it in the next Cocoon release ?

Best regards,

-
   Luca Morandini
   GIS Consultant
  [EMAIL PROTECTED]
http://utenti.tripod.it/lmorandini/index.html
-


> -Original Message-
> From: Luca Morandini [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 30, 2002 11:47 PM
> To: Cocoon-users
> Subject: Strange behavior in SQLTransforme Cocoon 2.0.3
>
>
> Folks,
>
> when I call an Oracle Stored Procedure with SQLTransformer the DBMS refuses to 
>execute it (lamenting a parsing error) if
> I don't put
> the call on one line.
>
> Needless to say, it worked fine up to 2.0.2.
>
> My configuration:
> - Windows 2000 Pro SP3
> - JDK 1.3.1
> - Tomcat 4.0.1
> - Cocoon 2.0.3
> - Oracle 8.1.7
>
> To sum it up:
>
> begin UMan.Logon('ammini', 'ammini', ?, ?, ?, ?, ?); end;
>
> works
>
> begin UMan.Logon('ammini',
> 'ammini', ?, ?, ?, ?, ?); end;
>
> doesn't... it gives:
> ERROR   (2002-09-30) 23:37.34:339   [sql.transformer.sql] 
>(/cerbero-dev/login-execute.html)
> Ajp13Processor[8009][4]/SQLTransformer$Query: Caught a SQLException
> java.sql.SQLException: ORA-06550: riga 1, colonna 27:
> PLS-00103: ...
>
> Best regards,
>
> -
>Luca Morandini
>GIS Consultant
>   [EMAIL PROTECTED]
> http://utenti.tripod.it/lmorandini/index.html
> -
>
>
>
> -
> Please check that your question  has not already been answered in the
> FAQ before posting. 
>
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail:   <[EMAIL PROTECTED]>
>


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

Re: Where did the authentication framework go?

[Bertrand Delacretaz]

On Tuesday 01 October 2002 16:01, Antonio Gallardo Rivera wrote:
>. . .
> My plataform was the same before and after the changes in the CVS.
>. . .

Don't forget that CVS allows you can easily rebuild the state of the codebase 
for any day, version or tag (-d and -r options IIRC). 

Maybe this would help you finding out what happened?

-Bertrand

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

Re: Where did the authentication framework go?

[Antonio Gallardo Rivera]

Yes,

If it can help:
I am using Java 1.4.1, Red Hat Linux 7.3 and Tomcat 4.1.12
I must said that everything was working well after the creation of the blocks. 
My plataform was the same before and after the changes in the CVS.

In the WEB-INF i have:

cocoon-2.1-dev.jar
cocoon-authentication-fw-block.jar
cocoon-batik-block.jar
cocoon-chaperon-block.jar
cocoon-fop-block.jar
cocoon-jfor-block.jar
cocoon-portal-fw-block.jar
cocoon-samples.jar
cocoon-session-fw-block.jar
cocoon-swf-block.jar

I buided using:

./build.sh clean
./build.sh installwar

Antonio Gallard


Antonio Gallardo.

El Martes, 01 de Octubre de 2002 07:49, [EMAIL PROTECTED] escribió:
> Quoting Antonio Gallardo Rivera <[EMAIL PROTECTED]>:
> > I saw that authentication, session and portal was moved to a block, but I
> > dont
> > know why it does not work. :(
>
> do you have the blocks in the WEB-INF/lib dir?

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

Re: Where did the authentication framework go?

[tcurdt]

Quoting Antonio Gallardo Rivera <[EMAIL PROTECTED]>:

> I saw that authentication, session and portal was moved to a block, but I
> dont 
> know why it does not work. :(

do you have the blocks in the WEB-INF/lib dir?
--
Torsten

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

Re: Where did the authentication framework go?

[Antonio Gallardo Rivera]

I saw that authentication, session and portal was moved to a block, but I dont 
know why it does not work. :(

I think people that commit the authentication framwork and XSP are very busy 
now. There is really a problem about the ComponentManager that uses examples 
and others XSP stuff.

I dont know why this happens always in weekend. But I learned to make a backup 
of all the plataform before making a download of CVS. If this does not work. 
I can go back to the old copy and wait. I recommend you to do the same thing 
next time. Its hard to wait until the problem is resolved.

If someone can helps us. We will be very glad. :)

Regards,

Antonio Gallardo.


El Martes, 01 de Octubre de 2002 06:28, Ugo Cei escribió:
> [I posted this yesterday on cocoon-users but got no reply. The same
> issue was reported also by Antonio Gallardo Rivera. Are we the only two
> users having this problem?]
>
> I just updated C2.1-dev from CVS, installed with build
> installscratchpadwar and I cannot find the authenitication framework
> anymore :(.
>
> http://localhost:8080/cocoon/samples/authentication/login
>
> The org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode
> notifies that org.apache.avalon.framework.component.ComponentException
> says:
>
> Could not find component
>
> More precisely:
>
> org.apache.avalon.framework.component.ComponentException: Could not find
> component
> org.apache.avalon.framework.component.ComponentException: Could not find
> component
> at
> org.apache.avalon.excalibur.component.ExcaliburComponentManager.lookup(Exca
>liburComponentManager.java:255) at
> org.apache.cocoon.components.CocoonComponentManager.lookup(CocoonComponentM
>anager.java:236) at
> org.apache.avalon.excalibur.component.DefaultComponentFactory$ComponentMana
>gerProxy.lookup(DefaultComponentFactory.java:393) at
> org.apache.avalon.excalibur.component.DefaultComponentFactory$ComponentMana
>gerProxy.lookup(DefaultComponentFactory.java:393) at
> org.apache.cocoon.webapps.authentication.acting.LoggedInAction.act(Unknown
> Source)
> ...
>
> Just as I was starting again to work on CocoBlog :(.
>
>  Ugo

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

Where did the authentication framework go?

[Ugo Cei]

[I posted this yesterday on cocoon-users but got no reply. The same 
issue was reported also by Antonio Gallardo Rivera. Are we the only two 
users having this problem?]

I just updated C2.1-dev from CVS, installed with build 
installscratchpadwar and I cannot find the authenitication framework 
anymore :(.

http://localhost:8080/cocoon/samples/authentication/login

The org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode 
notifies that org.apache.avalon.framework.component.ComponentException says:

Could not find component

More precisely:

org.apache.avalon.framework.component.ComponentException: Could not find 
component
org.apache.avalon.framework.component.ComponentException: Could not find 
component
at 
org.apache.avalon.excalibur.component.ExcaliburComponentManager.lookup(ExcaliburComponentManager.java:255)
at 
org.apache.cocoon.components.CocoonComponentManager.lookup(CocoonComponentManager.java:236)
at 
org.apache.avalon.excalibur.component.DefaultComponentFactory$ComponentManagerProxy.lookup(DefaultComponentFactory.java:393)
at 
org.apache.avalon.excalibur.component.DefaultComponentFactory$ComponentManagerProxy.lookup(DefaultComponentFactory.java:393)
at 
org.apache.cocoon.webapps.authentication.acting.LoggedInAction.act(Unknown 
Source)
...

Just as I was starting again to work on CocoBlog :(.

 Ugo

-- 
Ugo Cei - http://www.beblogging.com/blog/



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

cvs commit: xml-cocoon2/src/test/anteater all-tests.xml

[ovidiu]

ovidiu  2002/10/01 02:33:49

  Modified:src/test/anteater all-tests.xml
  Log:
  Added deploy and init targets (deploy doesn't work for the moment).
  
  You can now run a single Anteater test case by running in the
  src/test/anteater directory the command:
  
  anteater -f all-tests.xml -Dport=8090 -Dhost=localhost -Dbase=cocoon runtest 
-Dname=sitemapReload
  
  Revision  ChangesPath
  1.5   +1 -1  xml-cocoon2/src/test/anteater/all-tests.xml
  
  Index: all-tests.xml
  ===
  RCS file: /home/cvs/xml-cocoon2/src/test/anteater/all-tests.xml,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- all-tests.xml 1 Oct 2002 09:00:43 -   1.4
  +++ all-tests.xml 1 Oct 2002 09:33:49 -   1.5
  @@ -50,7 +50,7 @@
   
 
   
  -  
  +  
  
  
  
  
  
  

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

cvs commit: xml-cocoon2/src/webapp/samples/flow/examples/test sitemap.xmap

[ovidiu]

ovidiu  2002/10/01 02:30:39

  Modified:src/webapp/samples/flow/examples/test sitemap.xmap
  Log:
  Use @PARAMETER@ as the value to be replaced.
  
  Revision  ChangesPath
  1.2   +1 -1  xml-cocoon2/src/webapp/samples/flow/examples/test/sitemap.xmap
  
  Index: sitemap.xmap
  ===
  RCS file: /home/cvs/xml-cocoon2/src/webapp/samples/flow/examples/test/sitemap.xmap,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- sitemap.xmap  1 Oct 2002 08:59:57 -   1.1
  +++ sitemap.xmap  1 Oct 2002 09:30:39 -   1.2
  @@ -23,7 +23,7 @@
   
 
   
  -   
  +   

 
   
  
  
  

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

cvs commit: xml-cocoon2/src/test/anteater sitemapReload.xml

[ovidiu]

ovidiu  2002/10/01 02:30:11

  Modified:src/test/anteater sitemapReload.xml
  Log:
  Use overwrite mode when copying files.
  
  Revision  ChangesPath
  1.2   +9 -7  xml-cocoon2/src/test/anteater/sitemapReload.xml
  
  Index: sitemapReload.xml
  ===
  RCS file: /home/cvs/xml-cocoon2/src/test/anteater/sitemapReload.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- sitemapReload.xml 1 Oct 2002 09:01:14 -   1.1
  +++ sitemapReload.xml 1 Oct 2002 09:30:11 -   1.2
  @@ -14,10 +14,11 @@
   
   
  -
  +
 
  - 
  + 
 
   
   
  @@ -31,14 +32,15 @@
   
   
  -
  +
 
  - 
  + 
 
   
   
  -
 
   
  
  
  

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

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/treeprocessor/sitemap CallFunctionNode.java

[ovidiu]

ovidiu  2002/10/01 02:08:04

  Modified:src/java/org/apache/cocoon/components/treeprocessor/sitemap
CallFunctionNode.java
  Log:
  Removed extra imports.
  
  Revision  ChangesPath
  1.6   +0 -9  
xml-cocoon2/src/java/org/apache/cocoon/components/treeprocessor/sitemap/CallFunctionNode.java
  
  Index: CallFunctionNode.java
  ===
  RCS file: 
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/components/treeprocessor/sitemap/CallFunctionNode.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- CallFunctionNode.java 24 Sep 2002 08:23:00 -  1.5
  +++ CallFunctionNode.java 1 Oct 2002 09:08:04 -   1.6
  @@ -49,27 +49,18 @@
   import java.util.Collections;
   import java.util.List;
   import java.util.Map;
  -import org.apache.avalon.framework.activity.Initializable;
  -import org.apache.avalon.framework.component.Component;
   import org.apache.avalon.framework.component.ComponentManager;
   import org.apache.avalon.framework.component.Composable;
   import org.apache.avalon.framework.configuration.Configurable;
   import org.apache.avalon.framework.configuration.Configuration;
   import org.apache.avalon.framework.configuration.ConfigurationException;
   import org.apache.cocoon.components.flow.Interpreter;
  -import org.apache.cocoon.components.flow.InterpreterSelector;
   import org.apache.cocoon.components.treeprocessor.AbstractProcessingNode;
  -import org.apache.cocoon.components.treeprocessor.CategoryNode;
   import org.apache.cocoon.components.treeprocessor.InvokeContext;
  -import org.apache.cocoon.components.treeprocessor.ParameterizableProcessingNode;
  -import org.apache.cocoon.components.treeprocessor.ProcessingNode;
  -import org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode;
   import org.apache.cocoon.components.treeprocessor.variables.VariableResolver;
   import org.apache.cocoon.components.treeprocessor.variables.VariableResolverFactory;
   import org.apache.cocoon.environment.Environment;
  -import org.apache.cocoon.environment.Redirector;
   import org.apache.cocoon.sitemap.PatternException;
  -import org.apache.cocoon.components.flow.Interpreter;
   
   /**
* Node handler for calling functions and resuming continuations in
  
  
  

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

cvs commit: xml-cocoon2/src/test/anteater sitemapReload.xml

[ovidiu]

ovidiu  2002/10/01 02:01:14

  Added:   src/test/anteater sitemapReload.xml
  Log:
  Added. Tests the reloading of a modified sitemap.
  
  Revision  ChangesPath
  1.1  xml-cocoon2/src/test/anteater/sitemapReload.xml
  
  Index: sitemapReload.xml
  ===
  
  
  
  

  

  


  
  
  
  
  
  



  
  
  

  

  
  
  
  
  



  
  
  

  

  
  

  
  
  
  
  

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

cvs commit: xml-cocoon2/src/test/anteater all-tests.xml

[ovidiu]

ovidiu  2002/10/01 02:00:43

  Modified:src/test/anteater all-tests.xml
  Log:
  Added the deploy target (not enabled right now because of some problems in Anteater.
  
  Revision  ChangesPath
  1.4   +13 -2 xml-cocoon2/src/test/anteater/all-tests.xml
  
  Index: all-tests.xml
  ===
  RCS file: /home/cvs/xml-cocoon2/src/test/anteater/all-tests.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- all-tests.xml 6 Sep 2002 00:25:16 -   1.3
  +++ all-tests.xml 1 Oct 2002 09:00:43 -   1.4
  @@ -28,9 +28,20 @@
 
 
   
  -  http://${host}:${port}/${base}"/>
  +  
  +
  +http://${host}:${port}/${base}"/>
  +
  +
  +  
   
  -  
  +  
  +
  +
  +
  +  
  +
  +  
   
 
   
  
  
  

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

cvs commit: xml-cocoon2/src/webapp/samples/flow/examples/test/pages showString.xsp

[ovidiu]

ovidiu  2002/10/01 01:59:57

  Added:   src/webapp/samples/flow/examples/test README.txt sendpage.js
sitemap.xmap
   src/webapp/samples/flow/examples/test/pages showString.xsp
  Log:
  Added. Used for Anteater tests.
  
  Revision  ChangesPath
  1.1  xml-cocoon2/src/webapp/samples/flow/examples/test/README.txt
  
  Index: README.txt
  ===
  This directory is intended to be used by the Anteater test
  suite. Please don't modify things in this directory without modifying
  the appropriate Anteater scripts in src/test/anteater/.
  
  
  
  
  1.1  xml-cocoon2/src/webapp/samples/flow/examples/test/sendpage.js
  
  Index: sendpage.js
  ===
  function showString(parameter)
  {
print ("parameter = " + parameter);

sendPageAndContinue("showString.html",
{ "parameter" : parameter, "replaceme" : "@replaceme@" });
  }
  
  
  
  1.1  xml-cocoon2/src/webapp/samples/flow/examples/test/sitemap.xmap
  
  Index: sitemap.xmap
  ===
  
  
  http://apache.org/cocoon/sitemap/1.0";>
  

  
  
  
  
  

  

  

  

  
  

  

  

  
  


  
  
  

  
  
  
  
  
  1.1  
xml-cocoon2/src/webapp/samples/flow/examples/test/pages/showString.xsp
  
  Index: showString.xsp
  ===
  
  
  
  
  http://apache.org/xsp";
xmlns:jpath="http://apache.org/xsp/jpath/1.0";
>


  
  
Show number

  

  
  
  



 
  
  

  
  
  
  
  

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

cvs commit: xml-cocoon2/src/webapp/samples/flow/examples/test/pages - New directory

[ovidiu]

ovidiu  2002/10/01 01:59:23

  xml-cocoon2/src/webapp/samples/flow/examples/test/pages - New directory

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

cvs commit: xml-cocoon2/src/webapp/samples/flow/examples/test - New directory

[ovidiu]

ovidiu  2002/10/01 01:59:08

  xml-cocoon2/src/webapp/samples/flow/examples/test - New directory

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

Re: XML input module (was: RE: Nice changes!)

[Christian Haul]

On 01.Oct.2002 -- 01:31 AM, Jeff Turner wrote:
> On Mon, Sep 30, 2002 at 04:56:36PM +0200, Christian Haul wrote:
> > On 30.Sep.2002 -- 09:59 PM, Jeff Turner wrote:
> > > On Mon, Sep 30, 2002 at 01:19:04PM +0200, Christian Haul wrote:
> > > > I would prefer that module to be a "meta" module that can be
> > > > configured to take input from any source (i.e. another InputModule)
> > > > rather than do the reading itself.
> > > 
> > > >From what I gather, Meta modules take in as input, a) another module, b)
> > > a configuration. In this scenario, what object would we feed JXPath?
> > > Where does the DOM come from?
> > 
> > As already pointed out in others' replies, jxpath can operate on more
> > than DOM, i.e. uses reflexion to obtain the get and set methods.
> 
> > > This might already be possible, since I think JXPath can traverse from
> > > the Session object to a DOM.
> > 
> > Yes. The current request InputModule uses jxpath and allows this
> > functionality. However, I believe this is a feature that deserves to
> > be universally plugable.
> 
> It is universally pluggable, only the plugin mechanism is inheritance,
> not composition. The current model is:
> 
> AbstractJXPathModule .
>  | RequestModule
>  | SessionModule
>  | XMLModule
>  + 
> 
> Where each subclass just chooses what Object to let JXPath use.
> 
> If I've understood you, you're proposing to change from inheritance to
> composition. Create a JXPathModule that takes as 'input', *any* other
> module:
> 
> 
>   
> 

Right.

> 
> The JXPath module then provides XPath access to the input-module's
> what? This is my question above. A Module's public interface doesn't
> allow access to the raw object model that JXPath needs. It's always
> pre-digested, accessible through tokens that the Module defines. For
> instance, how would the above XML snippet translate to code? How could
> XMLModule functionality be achieved?

The degree, to what they digest the data is not set to
stone. SessionModule could, for instance, just return the session
object.

If we believe that jxpath is the one and only interface that the
InputModules should expose, I'm fine with that. Then it would make
perfectly sense to make all of them inherit from
AbstractJXPathModule. Obviously, all complex ones do currently.

But what about the others. How will they fit in e.g. DateMetaInput
(parses a string and returns a java.util.Date)? Granted, the simple
ones like NullInput (always returns "null") won't need it.

Another point may be that when switching to jxpath, would that impact
the interface? Does getAttributeNames() still return a reasonable
enumeration? 

> IMHO, inheritance is the way to go, with more advanced "chaining"
> functionality layered underneath, so that any subclass can automatically
> be chained.

Any automatic lookup or chaining should at least be configurable. Like
extending the DefaultsMetaModule.c

Chris.
-- 
C h r i s t i a n   H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

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

Re: [control flow] Reloading Scripts

[Ovidiu Predescu]

Hi Reinhard,

Please test the latest changes in the CVS, the code should work now.

I still have to implement an automatic test of this feature, so that we 
can prevent this bug from happening in the future. Until then, please 
let me know if you still see problems.

Regards,
Ovidiu

On Sunday, September 29, 2002, at 09:43  AM, Reinhard Poetz wrote:

> Ovidiu,
>
> Yestery I did some tests with the control flow - everything worked 
> fine but
> the scripts have not been reloaded. In the cocoon.xconf I set the 
> check-time
> for the flow-interpreters to 1 and then to 0 but both values didn't 
> help.
> Only a restart led to a "reload" of the scripts. I know there were 
> ?similar?
> (at least the symptom is the same) problems 5 weeks ago:
> [http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102956711018659&w=2].
>
> Regards
> Reinhard
>
>
-- 
Ovidiu Predescu <[EMAIL PROTECTED]>
http://webweavertech.com/ovidiu/weblog/ (Weblog)
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, 
Emacs ...)


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

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/flow InterpreterSelector.java

[ovidiu]

ovidiu  2002/10/01 00:34:16

  Modified:src/java/org/apache/cocoon/components/flow
InterpreterSelector.java
  Log:
  Don't read the reload-scripts and check-time parameters here, let the
  actual interpreter instances read them.
  
  Revision  ChangesPath
  1.4   +0 -7  
xml-cocoon2/src/java/org/apache/cocoon/components/flow/InterpreterSelector.java
  
  Index: InterpreterSelector.java
  ===
  RCS file: 
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/components/flow/InterpreterSelector.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- InterpreterSelector.java  17 Aug 2002 01:15:48 -  1.3
  +++ InterpreterSelector.java  1 Oct 2002 07:34:16 -   1.4
  @@ -63,8 +63,6 @@
   super.configure(config);
   
   defaultLanguage = config.getAttribute("default", null);
  -boolean reloadScripts = config.getAttributeAsBoolean("reload-scripts", false);
  -long checkTime = config.getAttributeAsLong("check-time", 1000L);
   
   // Finish the initialization of the already created components
   Configuration[] configurations = config.getChildren("component-instance");
  @@ -82,11 +80,6 @@
 catch (ComponentException ex) {
   throw new ConfigurationException("Could not find component for hint "
+ hint + ": " + ex.toString());
  -  }
  -
  -  if (interp instanceof AbstractInterpreter) {
  -((AbstractInterpreter)interp).setReloadScripts(reloadScripts);
  -((AbstractInterpreter)interp).setCheckTime(checkTime);
 }
   
 if (i == 0 && defaultLanguage == null)
  
  
  

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

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/flow flow.xconf

[ovidiu]

ovidiu  2002/10/01 00:33:07

  Modified:src/java/org/apache/cocoon/components/flow flow.xconf
  Log:
  Pass the reload-scripts and check-time arguments on a per-interpreter
  basis, rather than at the interpreter selector level.
  
  Revision  ChangesPath
  1.2   +2 -2  
xml-cocoon2/src/java/org/apache/cocoon/components/flow/flow.xconf
  
  Index: flow.xconf
  ===
  RCS file: 
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/components/flow/flow.xconf,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- flow.xconf19 May 2002 19:19:38 -  1.1
  +++ flow.xconf1 Oct 2002 07:33:07 -   1.2
  @@ -41,13 +41,13 @@
 -->
   
 
   
   
 
resource://org/apache/cocoon/components/flow/javascript/system.js
  +  true
  +  4000
   
   
   

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/flow AbstractInterpreter.java

[ovidiu]

ovidiu  2002/10/01 00:32:14

  Modified:src/java/org/apache/cocoon/components/flow
AbstractInterpreter.java
  Log:
  Implement Configurable. Read the reload-scripts and check-time
  configuration parameters locally, instead of being set from
  InterpreterSelector.
  
  Revision  ChangesPath
  1.9   +11 -11
xml-cocoon2/src/java/org/apache/cocoon/components/flow/AbstractInterpreter.java
  
  Index: AbstractInterpreter.java
  ===
  RCS file: 
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/components/flow/AbstractInterpreter.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- AbstractInterpreter.java  24 Sep 2002 08:08:32 -  1.8
  +++ AbstractInterpreter.java  1 Oct 2002 07:32:14 -   1.9
  @@ -62,6 +62,9 @@
   import org.apache.avalon.framework.thread.SingleThreaded;
   import org.apache.avalon.framework.logger.AbstractLogEnabled;
   import org.apache.avalon.framework.context.Contextualizable;
  +import org.apache.avalon.framework.configuration.Configurable;
  +import org.apache.avalon.framework.configuration.Configuration;
  +import org.apache.avalon.framework.configuration.ConfigurationException;
   import org.apache.avalon.framework.context.ContextException;
   import org.apache.avalon.framework.component.Composable;
   import org.apache.avalon.framework.component.ComponentManager;
  @@ -80,7 +83,7 @@
*/
   public abstract class AbstractInterpreter extends AbstractLogEnabled
 implements Component, Composable, Contextualizable, Interpreter,
  -  SingleThreaded
  + SingleThreaded, Configurable
   {
 /**
  * List of source locations that need to be resolved.
  @@ -103,6 +106,13 @@
  */
 protected long checkTime;
   
  +  public void configure(Configuration config)
  +throws ConfigurationException
  +  {
  +reloadScripts = config.getChild("reload-scripts").getValueAsBoolean(false);
  +checkTime = config.getChild("check-time").getValueAsLong(1000L);
  +  }
  +
 public void compose(ComponentManager manager)
   throws ComponentException
 {
  @@ -118,16 +128,6 @@
   throws ContextException
 {
   this.context = (Context)context.get(Constants.CONTEXT_ENVIRONMENT_CONTEXT);
  -  }
  -
  -  public void setReloadScripts(boolean yn)
  -  {
  -reloadScripts = yn;
  -  }
  -
  -  public void setCheckTime(long time)
  -  {
  -checkTime = time;
 }
   
 /**
  
  
  

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

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/flow/javascript JavaScriptInterpreter.java

[ovidiu]

ovidiu  2002/10/01 00:30:43

  Modified:src/java/org/apache/cocoon/components/flow/javascript
JavaScriptInterpreter.java
  Log:
  configure: call super.configure().
  
  Revision  ChangesPath
  1.10  +3 -5  
xml-cocoon2/src/java/org/apache/cocoon/components/flow/javascript/JavaScriptInterpreter.java
  
  Index: JavaScriptInterpreter.java
  ===
  RCS file: 
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/components/flow/javascript/JavaScriptInterpreter.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- JavaScriptInterpreter.java24 Sep 2002 08:18:41 -  1.9
  +++ JavaScriptInterpreter.java1 Oct 2002 07:30:43 -   1.10
  @@ -46,16 +46,12 @@
   package org.apache.cocoon.components.flow.javascript;
   
   import java.io.BufferedReader;
  -import java.io.InputStream;
   import java.io.InputStreamReader;
   import java.io.Reader;
  -import java.io.SequenceInputStream;
   import java.util.ArrayList;
  -import java.util.Enumeration;
   import java.util.HashMap;
   import java.util.List;
   import java.util.Map;
  -import org.apache.avalon.excalibur.collections.ArrayEnumeration;
   import org.apache.avalon.framework.activity.Initializable;
   import org.apache.avalon.framework.configuration.Configurable;
   import org.apache.avalon.framework.configuration.Configuration;
  @@ -70,7 +66,6 @@
   import org.apache.cocoon.environment.Session;
   import org.apache.cocoon.environment.Source;
   import org.mozilla.javascript.Context;
  -import org.mozilla.javascript.ErrorReporter;
   import org.mozilla.javascript.Function;
   import org.mozilla.javascript.NativeArray;
   import org.mozilla.javascript.PropertyException;
  @@ -110,7 +105,10 @@
 JSErrorReporter errorReporter;
   
 public void configure(Configuration config)
  +throws ConfigurationException
 {
  +super.configure(config);
  +
   String loadOnStartup
 = config.getChild("load-on-startup", true).getValue(null);
   if (loadOnStartup != null)
  
  
  

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