Re: AW: Custom Transformers

[Tony Collen]

Marco Rolappe wrote:
hi tony,
AFAIR all that recording functionality you need exists in
AbstractSAXTransformer. so, slightly modified, that pseudocode should do it.
Marco,
Aha! Thanks for pointing me in the right direction.
Tony

AW: Custom Transformers

[Marco Rolappe]

hi tony,

AFAIR all that recording functionality you need exists in
AbstractSAXTransformer. so, slightly modified, that pseudocode should do it.

> -Ursprungliche Nachricht-
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Auftrag
> von Tony Collen
> Gesendet: Mittwoch, 19. Mai 2004 23:06
> An: [EMAIL PROTECTED]
> Betreff: Custom Transformers
>
>
> Hey everybody,
>
> I'm about to dive in and finally write a custom transformer.
>
> My use case is this:  I am going to look for a certain element in
> the stream with a specific
> namespace, and when I see it, I need to get all the character
> content (i.e. everything that
> characters() would return), manually process it and reformat it,
> and then place it back into the SAX
> stream.
>
> Looking at the ContentHandler API, it says that some
> implementations might chunk the data coming to
> me in characters(), which complicates things, since I might not
> get the entire data, which I need to
> be able to process in one piece.
>
> Poking around, I found the TextRecorder in
> org.apache.cocoon.transformation.helpers, which seems to
> be what I need.
>
> So now I ask if this seems right, in presented in glorious pseudocode:
>
> 
> recording = false
> TextRecorder recorder = new TextRecorder();
>
> void startElement(ns, localname, qname, attrs) {
>
>if (ns.equals(myNs) && localname.equals(myElemName)) {
>  this.recording = true;
>}
>
>super.startElement(ns, localname, qname, attrs);
> }
>
> void endElement(ns, localname, qname, attrs) {
>
>if (ns.equals(myNs) && localname.equals(myElemName)) {
>  // have we seen our element?
>
>  this.recording = false
>  String theText = process(this.recorder.getText());
>  super.characters(theText.toCharArray(), 0, theText.length());
>}
>super.endElement(ns, localname, qname, attrs)
> }
>
> void characters(char buf[], int start, int len) {
>
>if (this.recording) {
>  this.recorder.characters(buf, start, len);
>} else {
>  super.characters(buf, start, len);
>}
> }
>
> String process(String myStr) {
>// process the string arbitrarily
> }
>
> 
> Regards,
>
> Tony
>

RE: [portal] Implementing Login coplet with CForms

[Alex Romayev]

--- Alex Romayev <[EMAIL PROTECTED]> wrote:
> > > > > Is there a way of making request parameters
> > > > available to CForms?
> > > > > 
> > > > Adding the above configuration should actually
> > do the trick. Hmm.
> > > > Just to make sure: Does Cocoon receive the
> form
> > values at 
> > > all (which 
> > > > means is the form running standalone)?
> > > 
> > > The the form outside of portal works fine.
> > > 
> > > Where did you
> > > > add the above
> > > > configuration to?
> > > 
> > > I've added the configuration to copletdata xml:
> > > 
> > > 
> > 
> > Looks good to me. Hmm.
> > 
> > Ok, the only hint I can give you at the moment is
> to
> > try
> > to debug the coplet adapter and see if it really
> > invokes
> > the coplet with the correct parameters or not.
> 
> OK, here is what I found, in the following line:
> 
> Boolean handlePars = (Boolean)this.getConfiguration(
> coplet, "handleParameters");
> 
> handlePars results in null, which is why nothing
> inside:
> 
> if ( handlePars != null && handlePars.booleanValue()
> )
> 
> 
> gets executed.

Sorry, I don't know why it was giving me null, I tried
it again, and it's not.  I did some more testing and
this is what I found:

String sourceUri = uri;

1. The uri here never has any request parameters, i.e.
it's always
"cocoon:raw:/coplets/registration/login-cforms"

if ( handlePars != null && handlePars.booleanValue() )
{


List list = (List)
portalService.getTemporaryAttribute(URICopletAdapter.class.getName());

2. The list here is always null, which gets us into
the else clause

if ( list != null && list.contains( coplet )) {
// add parameters
if ( uri.startsWith("cocoon:raw:") ) {
sourceUri = "cocoon:" + uri.substring(11);
}
} else {

// remove parameters
if (!uri.startsWith("cocoon:raw:") ) {
sourceUri = "cocoon:raw:" + uri.substring(7);
}
}
}

HTH,

-Alex

DO NOT REPLY [Bug 29103] New: - load function in v3/Form.js fails

[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://issues.apache.org/bugzilla/show_bug.cgi?id=29103

load function in v3/Form.js fails

   Summary: load function in v3/Form.js fails
   Product: Cocoon 2
   Version: Current CVS 2.1
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: CocoonForms
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


In v3/Form.js:
Assignment of arg1 to variable "name" in function "load" has == instead of =.
As a result name is undefined and the load function fails throwing message 
'Binding "undefined" not configured for this form.'

DO NOT REPLY [Bug 29103] - load function in v3/Form.js fails

[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://issues.apache.org/bugzilla/show_bug.cgi?id=29103

load function in v3/Form.js fails

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-05-19 20:59 ---
Thanks for reporting and fix.

Joerg

Custom Transformers

[Tony Collen]

Hey everybody,
I'm about to dive in and finally write a custom transformer.
My use case is this:  I am going to look for a certain element in the stream with a specific 
namespace, and when I see it, I need to get all the character content (i.e. everything that 
characters() would return), manually process it and reformat it, and then place it back into the SAX 
stream.

Looking at the ContentHandler API, it says that some implementations might chunk the data coming to 
me in characters(), which complicates things, since I might not get the entire data, which I need to 
be able to process in one piece.

Poking around, I found the TextRecorder in org.apache.cocoon.transformation.helpers, which seems to 
be what I need.

So now I ask if this seems right, in presented in glorious pseudocode:

recording = false
TextRecorder recorder = new TextRecorder();
void startElement(ns, localname, qname, attrs) {
  if (ns.equals(myNs) && localname.equals(myElemName)) {
this.recording = true;
  }
  super.startElement(ns, localname, qname, attrs);
}
void endElement(ns, localname, qname, attrs) {
  if (ns.equals(myNs) && localname.equals(myElemName)) {
// have we seen our element?
this.recording = false
String theText = process(this.recorder.getText());
super.characters(theText.toCharArray(), 0, theText.length());
  }
  super.endElement(ns, localname, qname, attrs)
}
void characters(char buf[], int start, int len) {
  if (this.recording) {
this.recorder.characters(buf, start, len);
  } else {
super.characters(buf, start, len);
  }
}
String process(String myStr) {
  // process the string arbitrarily
}

Regards,
Tony

Re: [VOTE] Release on monday

[Antonio Gallardo]

Carsten Ziegeler dijo:
> I think we fixed the most serious problems for 2.1.5 now.
>
> If noone objects I will release the current state on monday,
> 24th of May. So the code freeze will continue until then.
> This gives us some more days to test and possibly fix bugs.
>
> Or is there anything serious that I did oversee?

+1 To release on Monday. And many thanks to you for doing the work!

I hope we soon will get rid of jisp. What about to deprecate current JISP
support? If someone want to use JISP there is still a posibility using
JCS.

Best Regards,

Antonio Gallardo

Re: [VOTE] Release on monday

[Tim Larson]

On Wed, May 19, 2004 at 08:52:52AM -0400, Vadim Gritsenko wrote:

> For those who have not followed - this was the behavior of the stores in 
> previous releases of Cocoon (before refactoring we had only two stores, 
> IIRC, but same behavior). Given terminology above, we can have a working 
> persistent store (JCS based), and working transient store (from 
> Excalibur). General store is currently broken in two ways:
>  * It does not stores non serializable objects, but should.
>  * It does not persists cache on shutdown.
> 
> I'm +1 on release, if and only if, we note these above bugs in the known 
> issues list.
> 
> Vadim

+1 for release with the same condition as Vadim states above.

--Tim Larson

AW: [VOTE] Release on monday

[Marco Rolappe]

just as a sidenote; I think the naming is somewhat wrong, it muddies the
contracts.

IMO there should be:
 - ObjectCache
- responsibility: (temporarily) cache objects to increase performance
- MIGHT persist these objects (if possible), but this is not guaranteed by
the contract
- so, if objects implement Serializable (or otherwise qualify for being
persisted?) they MIGHT be persisted, but this is an implementation detail

 - ObjectStore
- responsibility: persist/store objects non-temporarily
- objects have to implement Serializable (or otherwise qualify for being
persisted?)

I don't see the need for the Store role. if my component needs objects
persisted I'll use ObjectStore, if I just need a cache for performance I'll
use ObjectCache. anything else should be configuration. e.g. xslt
transformer or the like; it wouldn't require a store. if I wanted it to use
a persisting cache I should be able to configure that.

the bottom line is that there are two contracts: cache and store. the Store
role as it currently exists is IMO unnecessary.


KISS ;-)

> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Auftrag
> von Vadim Gritsenko
> Gesendet: Mittwoch, 19. Mai 2004 14:53
> An: [EMAIL PROTECTED]
> Betreff: Re: [VOTE] Release on monday
>
>
> Sylvain Wallez wrote:
>
> > Joerg Heinicke wrote:
> >
> >> On 19.05.2004 13:02, Carsten Ziegeler wrote:
> >
> ...
>
> >>> - If you put objects into the store, they have to be serializable now.
> >>>   Even if JCS holds the data just in memory, it assumes that the
> >>>   objects are serializable. Perhaps they will change this perhaps
> >>>   not.
> >>
> >>
> >>
> >> What about the non-Serializable objects? Logicsheets and Paginator
> >> stuff were mentioned. Are these objects not put into transient store?
> >
> >
> >
> > Yep. And the transient store does not (and should not) require objects
> > to be serializable (that's its main purpose compared to the regular
> > store that may persist objects).
>
>
> Let's clarify something here about all those stores:
>
> Transient store: MUST hold NON Serializable objects, MUST NOT
> persist objects.
> Persistent store: MUST reject NON Serializable objects, MUST persist
> objects.
> Store: MUST hold NON Serializable objects, CAN persist Serializable
> objects on overflow (or any other reason), MUST persist all Serializable
> objects on shutdown.
>
> For those who have not followed - this was the behavior of the stores in
> previous releases of Cocoon (before refactoring we had only two stores,
> IIRC, but same behavior). Given terminology above, we can have a working
> persistent store (JCS based), and working transient store (from
> Excalibur). General store is currently broken in two ways:
>   * It does not stores non serializable objects, but should.
>   * It does not persists cache on shutdown.
>
> I'm +1 on release, if and only if, we note these above bugs in the known
> issues list.
>
> Vadim
>

Re: [VOTE] Release on monday

[leo leonid]

On 19.05.2004, at 14:52, Vadim Gritsenko wrote:
I'm +1 on release, if and only if, we note these above bugs in the 
known issues list.

Vadim
Please give me that list!!!
I updated a server hosting a bunch of XSPs to current CVS.
Using the default cocoon.xconf settings, first everything is fine,
but after about an hour under medium load it is getting slower and
slower and is starving while heap is growing to ~240M (-Xmx260m).
can anybody confirm that these settings do work?
/leo
  

  
  


  
  
 
 
 
 
 
 
 
  

RE: [VOTE] Release on monday

[Carsten Ziegeler]

Vadim Gritsenko wrote:

> 
> Let's clarify something here about all those stores:
> 
> Transient store: MUST hold NON Serializable objects, MUST 
> NOT persist objects.
> Persistent store: MUST reject NON Serializable objects, 
> MUST persist objects.
> Store: MUST hold NON Serializable objects, CAN persist 
> Serializable objects on overflow (or any other reason), MUST 
> persist all Serializable objects on shutdown.
> 
> For those who have not followed - this was the behavior of 
> the stores in previous releases of Cocoon (before refactoring 
> we had only two stores, IIRC, but same behavior). Given 
> terminology above, we can have a working persistent store 
> (JCS based), and working transient store (from Excalibur). 
> General store is currently broken in two ways:
>   * It does not stores non serializable objects, but should.
>   * It does not persists cache on shutdown.
> 
> I'm +1 on release, if and only if, we note these above bugs 
> in the known issues list.
> 
Fair enough. Just add them.

Thanks
Carsten

Re: cvs commit: cocoon-2.1/src/documentation/xdocs/developing stores.xml book.xml

[Vadim Gritsenko]

[EMAIL PROTECTED] wrote:
 
   The Store (aka "main Store")
   
 The store (role Store.ROLE) is used to store objects that are 
 serializable.

Ummm... Hate repeating [1] myself but this is not correct. See 
DefaultStore (which extends MRUMemoryStore). Would you mind if I fix 
this description?

Vadim
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108497119303581

Re: generator jars in other location than /lib /classes

[Vadim Gritsenko]

Peter Lerche wrote:
Hi,
I'm no expert either, but no there is no constraints.
This is a JBoss setup and I am able to access any jar at any location using 
Jboss's urlclassloader or JBOSS_CLASSPATH. (I assume that this would also be 
the case in a non-jboss installation using CLASSPATH)
Cocoon (Avalon ?) does not recognize any CLASSPATH or classloaders when the 
class is declared in the sitemap.xmap file. It looks like that Cocoon has 
hardcoded the /lib /classes directory in the sourcecode. However there is 
reference to these two directories in a zillion locations.
 

Once again (see prev email), to clear up confusion, default Cocoon 
servlet does not build any classloader of its own, but uses one from the 
container. And any well behaved container classloader will respect 
specification and add /classes and /lib to its classpath.

Vadim

Peter
http://easyspeedy.com
On Wednesday 19 May 2004 15:31, Bertrand Delacretaz wrote:
 

Le 19 mai 04, à 14:43, Peter Lerche a écrit :
   

...After 2 weeks I have still not cracked how to change cocoon 2.1.5
to accept
other locations for its sitemap elements than the /lib and /classes
dir
 

<>hmmm...I'm no expert on servlet containers, but isn't that a limitation
(or rather a security feature) of the servlet container, that will not
let you access jars in other applications?
-Bertrand

Re: generator jars in other location than /lib /classes

[Peter Lerche]

Hi,

I'm no expert either, but no there is no constraints.

This is a JBoss setup and I am able to access any jar at any location using 
Jboss's urlclassloader or JBOSS_CLASSPATH. (I assume that this would also be 
the case in a non-jboss installation using CLASSPATH)
Cocoon (Avalon ?) does not recognize any CLASSPATH or classloaders when the 
class is declared in the sitemap.xmap file. It looks like that Cocoon has 
hardcoded the /lib /classes directory in the sourcecode. However there is 
reference to these two directories in a zillion locations.

Peter
http://easyspeedy.com

 
On Wednesday 19 May 2004 15:31, Bertrand Delacretaz wrote:
> Le 19 mai 04, à 14:43, Peter Lerche a écrit :
> > ...After 2 weeks I have still not cracked how to change cocoon 2.1.5
> > to accept
> > other locations for its sitemap elements than the /lib and /classes
> > dir
>
> hmmm...I'm no expert on servlet containers, but isn't that a limitation
> (or rather a security feature) of the servlet container, that will not
> let you access jars in other applications?
>
> -Bertrand

-- 
Med venlig hilsen / Yours sincerely 
 
Peter Lerche
http://easyspeedy.com 
___ 
European Dedicated Server Hosting 
Extremely low prices, secure, and reliable
Linux and BSD distributions only 
___

Re: generator jars in other location than /lib /classes

[Vadim Gritsenko]

Bertrand Delacretaz wrote:
Le 19 mai 04, à 14:43, Peter Lerche a écrit :
...After 2 weeks I have still not cracked how to change cocoon 2.1.5 
to accept
other locations for its sitemap elements than the /lib and /classes 
dir

See ParanoidCocoonServlet in paranoid block, should be possible to add 
any jars to the classpath.


hmmm...I'm no expert on servlet containers, but isn't that a 
limitation (or rather a security feature) of the servlet container, 
that will not let you access jars in other applications?

No, it is by design: web application classloader loads /lib and 
/classes. Cocoon's paranoid class loader can be used to add to this 
default class path arbitrary jars. AFAIU.

Vadim

Re: generator jars in other location than /lib /classes

[Bertrand Delacretaz]

Le 19 mai 04, à 14:43, Peter Lerche a écrit :
...After 2 weeks I have still not cracked how to change cocoon 2.1.5 
to accept
other locations for its sitemap elements than the /lib and /classes 
dir
hmmm...I'm no expert on servlet containers, but isn't that a limitation 
(or rather a security feature) of the servlet container, that will not 
let you access jars in other applications?

-Bertrand

generator jars in other location than /lib /classes

[Peter Lerche]

Hi,

I am going bonkers.


After 2 weeks I have still not cracked how to change cocoon 2.1.5 to accept 
other locations for its sitemap elements than the /lib and /classes dir.

The file exist-optional.jar contains a 3part sitemap generator. I am forced to 
have this file located in a different location than what is expected by 
cocoon.  (see below).

How do I get cocoon to accept this file location.

I have tried to change sourcecode,classloaders,cocoon.roles,metainf.mf... but 
with no luck.

Please who can tell me how to do this..


dir struct...
./deploy
cocoon.war
WEB-INF
lib
   
exist.sar
lib
   exist-optional.jar
...
WEB-INF
...


Med venlig hilsen / Yours sincerely 
 
Peter Lerche
http://easyspeedy.com 
___ 
European Dedicated Server Hosting 
Extremely low prices, secure, and reliable
Linux and BSD distributions only 
___

Re: [VOTE] Release on monday

[Ugo Cei]

Upayavira wrote:
I need to remove the test-suite and use samples/test, and confirm that 
Ugo's fixes have made the CocoonBeanTestCase work, and then re-enable it.
A word of caution. My fixes add the blocks directory and block-provided 
jars to the classpath for tests and make the "junit-tests" target depend 
upon the "blocks" target.

This is necessary because the CocoonBeanTestCase loads 
"build/webapp/WEB-INF/cocoon.xconf", which contains references to 
components provided by blocks.

This strikes me as a typical anti-pattern. What are we testing here? The 
CocoonBean or the components that it relies upon? If it's the latter, 
fine, but it's not a unit test anymore, it's an integration test and 
does not belong under the "junit-tests" target. If it's the former, it 
should be testable in isolation.

In any case, it would be probably advisable to load the CocoonBean under 
test with a cocoon.xconf derived from a "no-blocks-included" configuration.

WDYT?
Ugo

Re: [VOTE] Release on monday

[Vadim Gritsenko]

Sylvain Wallez wrote:
Joerg Heinicke wrote:
On 19.05.2004 13:02, Carsten Ziegeler wrote:

...
- If you put objects into the store, they have to be serializable now.
  Even if JCS holds the data just in memory, it assumes that the
  objects are serializable. Perhaps they will change this perhaps
  not.

What about the non-Serializable objects? Logicsheets and Paginator 
stuff were mentioned. Are these objects not put into transient store?

Yep. And the transient store does not (and should not) require objects 
to be serializable (that's its main purpose compared to the regular 
store that may persist objects).

Let's clarify something here about all those stores:
   Transient store: MUST hold NON Serializable objects, MUST NOT 
persist objects.
   Persistent store: MUST reject NON Serializable objects, MUST persist 
objects.
   Store: MUST hold NON Serializable objects, CAN persist Serializable 
objects on overflow (or any other reason), MUST persist all Serializable 
objects on shutdown.

For those who have not followed - this was the behavior of the stores in 
previous releases of Cocoon (before refactoring we had only two stores, 
IIRC, but same behavior). Given terminology above, we can have a working 
persistent store (JCS based), and working transient store (from 
Excalibur). General store is currently broken in two ways:
 * It does not stores non serializable objects, but should.
 * It does not persists cache on shutdown.

I'm +1 on release, if and only if, we note these above bugs in the known 
issues list.

Vadim

Re: Status of repository block and webdav question.

[Rolf Kulemann]

On Wed, 2004-05-19 at 13:28, Guido Casper wrote:
> Rolf Kulemann wrote:
> > [...]
> > Sorry, but they are different to me. Repository acts on String like
> > paths and exposes services. The SourceRepository just acts on services
> > exposed by the various *Source interfaces. That looks to me like two
> > different approaches.
> 
> The only indication (within the interface!) of the fact that the 
> implementation acts on Sources is the name and the throwing of 
> SourceExceptions. As a client of this component you are just giving URI 
> Strings to it.

Ah, now I got u, sorry.

> 
> But yes there is a conceptual clash between implementations and if you 
> want a grand unified Repository concept, you have to decide between:
> -having one Repository acting on different Source implementations
> -having (one source acting on) different Repository implementations
> 
> I (obviously) opt for the latter.

ok.

> 
> > 
> > I'm curious about ur concrete merging thoughts.  Would be cool if u share
> > ideas :)
> 
> -First, the SourceRepository currently ignores Properties.
> While preserving Unico's exciting work on SourceInspector (as was 
> Stephan Michel's work before) and SourceDescriptor I would like to move 
> the setting of properties and the like away from the pipelines into the 
> SourceRepository itself (while preserving a working davmap sample). From 
> there on merging the interfaces should be quite straight forward.

Sounds like a plan.

> 
> -The second thing is that the SourceRepository acts on absolute URIs 
> while I prefer paths relativ to some configured repo root.

+1

> 
> -Furthermore the SourceRepository is geared towards *serving* WebDAV 
> (i.e. managing HTTP status codes), a fact that probably shouldn't be 
> within a generalized Repository interface (although serving WebDAV 
> probably is a great use case for a repository).

Of course not.

> 
> 
> Keeping the implementation of SourceRepository (working with the 
> SourceDescriptor) is certainly worth it as it provides a lightweight 
> (and still kind of universal) repository for simple needs (without 
> versioning etc.) in the filesystem (or other simple Sources not 
> available as complete repositories). Once a SourceImpl acting on 
> instances of Repositories is available the current RepositorySource 
> might be deprecated.

Ok. So u will keep URIs as Strings being passed as args to the
repository interface ?


Do u mean a source to act on the reps like this ? :


|RepositorySource  |

|Repository|

|SlideRepository|WebDAVRepository|JCRRepository|


What about all the *Source interfaces like i.e. VersionableSource and
TraversableSource ? Should they be implemented by RepositorySource ?

How would the protocol of RepositorySource work?
I guess u plan that is possible to configure different reps. with
different "symbolic names". So, what url should be used i.e. in sitemaps
to access a rep source?

I.e. imagine three rep. definitions a, b and c where a and b are
pointing to the same backend but using different uri prefixes i.e. x and
y. a id configure with prfix z

Lets see how that could work in a sitemap:

 and
 and


In all cases a RepositorySourceFactory would create a RepositorySource
which looks up the right repository impl. in order to
delegate/fullfill/execute services??

> 
> These are the things (in addition to the JSR170 issue) to address IMO. I 
> planned to bring them up for discussion when I have time to work on them 
> (which is not the case currently :-)

Good to know. Thanks for the info.

-- 

RolfKulemann

"There is inherently no silverbullet" - F.Brooks

Re: [VOTE] Release on monday

[Sylvain Wallez]

Joerg Heinicke wrote:
On 19.05.2004 13:02, Carsten Ziegeler wrote:
Before this week we had a non-working persistent store, now we have 
no longer a persistent store, but a two-stage caching system with 
both JCS and EHCache? What about the Serializable issues?

Ok, let me try it:
- Between 2.1.4 and 2.1.5 we had the refactoring of the stores. The 
basic
  idea is to have only two stores that should be used by clients:
  the store and the transient store. The transient store is - well -
  transient - it does not persist data. The store should also persist
  data. It should implement a two phase store (memory -> disk).
- The old (jisp) based implementation of the store used the persistent
  store to persist the data.
- Due to the refactoring we had severe problems (don't know which)
  that prevented us from releasing - this came up on friday. (it was
  mentioned here and there earlier)

That was Sylvain's refactoring IIRC.

Yep. And this refactoring made JISP bugs apparent since on-disk data was 
never retrieved before (even if written)

- Now: we are using JCS for the store. JCS itself has a two-phase
  caching implemented and therefore we don't need a persistent store
  anymore.

But the second phase is not intended as persistent store, is it?

Since JCS does both memory front-end + disk back-end, it can be _the_ 
store, and we no more need the persistent store.

- We still use the memory store for the transient store.

How do JCS phase I and MRUMemoryStore play together here - or do I mix 
two different things?

They live their lives on their own, orchestrated by the store janitor.
- If you put objects into the store, they have to be serializable now.
  Even if JCS holds the data just in memory, it assumes that the
  objects are serializable. Perhaps they will change this perhaps
  not.

What about the non-Serializable objects? Logicsheets and Paginator 
stuff were mentioned. Are these objects not put into transient store?

Yep. And the transient store does not (and should not) require objects 
to be serializable (that's its main purpose compared to the regular 
store that may persist objects).

  Although this is different from the jisp based version it doesn't
  affect us as we are using serializable objects anyway - which makes
  sense as they whole data should be persistent later on.
- If you put objects into the transient store they don't have to
  be serializable.
- Persisting cache entries inbetween application starts didn't work
  very well with Jisp as we had bugs in Cocoon.
  This works now with JCS.
- There is only one bug: JCS is not always writing the data to disk. It
  seems that there has to be a critical mass of data before it gets
  written. - we reported this issue and I hope they will fix it. But
  this is not a serious issue as the persistence is not that important
  and didn't work before anyway.
So, to sum it up: imho we have no a working system that is based on JCS.

I get the feeling that JCS is not used for transient store (but 
MRUMemoryStore), so no JCS phase I. And JCS phase II (now replacement 
for old Jisp persistent store) has minor bugs as written above.

IIUC the main store based on JCS uses the two phases (memory + disk), 
and it seems we can live for now with the minor shutdown bug.

There are minor problems that we can fix in the next releases.

I don't want to block the release, you get my +1. I'm just curious and 
want to know how the stuff is working now - and if I can use the 
release in a project of course.

+1 from me also.
You guys did an amazing job to solve this issue. I lacked time to 
participate, being very busy on a project. The good news however is that 
this will lead to interesting new CForm features :-)

Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: [VOTE] Release on monday

[Joerg Heinicke]

On 19.05.2004 13:02, Carsten Ziegeler wrote:
Before this week we had a non-working persistent store, now 
we have no longer a persistent store, but a two-stage caching 
system with both JCS and EHCache? What about the Serializable issues?

Ok, let me try it:
- Between 2.1.4 and 2.1.5 we had the refactoring of the stores. The basic
  idea is to have only two stores that should be used by clients:
  the store and the transient store. The transient store is - well -
  transient - it does not persist data. The store should also persist
  data. It should implement a two phase store (memory -> disk).
- The old (jisp) based implementation of the store used the persistent
  store to persist the data.
- Due to the refactoring we had severe problems (don't know which)
  that prevented us from releasing - this came up on friday. (it was
  mentioned here and there earlier)
That was Sylvain's refactoring IIRC.
- Now: we are using JCS for the store. JCS itself has a two-phase
  caching implemented and therefore we don't need a persistent store
  anymore.
But the second phase is not intended as persistent store, is it?
- We still use the memory store for the transient store.
How do JCS phase I and MRUMemoryStore play together here - or do I mix 
two different things?

- If you put objects into the store, they have to be serializable now.
  Even if JCS holds the data just in memory, it assumes that the
  objects are serializable. Perhaps they will change this perhaps
  not.
What about the non-Serializable objects? Logicsheets and Paginator stuff 
were mentioned. Are these objects not put into transient store?

  Although this is different from the jisp based version it doesn't
  affect us as we are using serializable objects anyway - which makes
  sense as they whole data should be persistent later on.
- If you put objects into the transient store they don't have to
  be serializable.
- Persisting cache entries inbetween application starts didn't work
  very well with Jisp as we had bugs in Cocoon.
  This works now with JCS.
- There is only one bug: JCS is not always writing the data to disk. It
  seems that there has to be a critical mass of data before it gets
  written. - we reported this issue and I hope they will fix it. But
  this is not a serious issue as the persistence is not that important
  and didn't work before anyway.
So, to sum it up: imho we have no a working system that is based on JCS.
I get the feeling that JCS is not used for transient store (but 
MRUMemoryStore), so no JCS phase I. And JCS phase II (now replacement 
for old Jisp persistent store) has minor bugs as written above.

There are minor problems that we can fix in the next releases.
I don't want to block the release, you get my +1. I'm just curious and 
want to know how the stuff is working now - and if I can use the release 
in a project of course.

Joerg

RE: [VOTE] Release on monday

[Carsten Ziegeler]

Upayavira wrote:
> >
> I need to remove the test-suite and use samples/test, and 
> confirm that Ugo's fixes have made the CocoonBeanTestCase 
> work, and then re-enable it.
> 
> But, as that test is currently disabled, releasing with it in 
> its current state is not a major problem. I'd just like to 
> get it done before we release.
> 
Sure, makes sense. You have some days time until monday :)

Carsten

RE: Persistent storing should work now

[Carsten Ziegeler]

Upayavira wrote:
> 
> Carsten Ziegeler wrote:
> 
> >Due to our change to JCS I found a serious bug in our own 
> caching keys: 
> >the hash code wasn't always calculated properly :( This resulted in
> >
> >a) an unusable persistent store as after an application restart the 
> >keys didn't match anymore
> >
> >and
> >
> >b) other environments like CLI etc. couldn't use the cache at all.
> >  
> >
> Great work Carsten.
> 
> Can you explain why other environments couldn't use the 
> cache? I'm sure I've seen stuff go in and out of the cache 
> within the CLI (but only within a single session).
> 
The hash-code calculation of our keys was based on the hash code
of some strings used inside the keys. All these hash code were
added to build the hash code for our key. Somehow this seems
to produce an integer overflow/miss-interpretation. So, after
an application start the hash code wasn't the same as when the
objects were stored.
Therefore the hash code didn't match the newly created hash
code of the new keys and nothing could be found in the store
although it wasn't empty.

I haven't tested it with the CLI, but I don't see any reason why
it shouldn't work :)

Carsten

Re: Status of repository block and webdav question.

[Guido Casper]

Rolf Kulemann wrote:
On Wed, 2004-05-19 at 09:10, Guido Casper wrote:
Rolf Kulemann wrote:
What u mean with Repository block? IMHO there are currently two
approaches hosted within the repository bloch, which should be divided
normally.
1.) SourceRepository which acts on various interfaces like
VersionableSource etc. 

2.) Repository interface with a WEbDAV _only_ implementation which is
too flow oriented (no exception handling etc.)
These 2 (interfaces) are not all that different (like different 
approaches) and I plan to merge them.

Sorry, but they are different to me. Repository acts on String like
paths and exposes services. The SourceRepository just acts on services
exposed by the various *Source interfaces. That looks to me like two
different approaches.
The only indication (within the interface!) of the fact that the 
implementation acts on Sources is the name and the throwing of 
SourceExceptions. As a client of this component you are just giving URI 
Strings to it.

But yes there is a conceptual clash between implementations and if you 
want a grand unified Repository concept, you have to decide between:
-having one Repository acting on different Source implementations
-having (one source acting on) different Repository implementations

I (obviously) opt for the latter.
I'm curious about ur concrete merging thoughts.  Would be cool if u share
ideas :)
-First, the SourceRepository currently ignores Properties.
While preserving Unico's exciting work on SourceInspector (as was 
Stephan Michel's work before) and SourceDescriptor I would like to move 
the setting of properties and the like away from the pipelines into the 
SourceRepository itself (while preserving a working davmap sample). From 
there on merging the interfaces should be quite straight forward.

-The second thing is that the SourceRepository acts on absolute URIs 
while I prefer paths relativ to some configured repo root.

-Furthermore the SourceRepository is geared towards *serving* WebDAV 
(i.e. managing HTTP status codes), a fact that probably shouldn't be 
within a generalized Repository interface (although serving WebDAV 
probably is a great use case for a repository).

Keeping the implementation of SourceRepository (working with the 
SourceDescriptor) is certainly worth it as it provides a lightweight 
(and still kind of universal) repository for simple needs (without 
versioning etc.) in the filesystem (or other simple Sources not 
available as complete repositories). Once a SourceImpl acting on 
instances of Repositories is available the current RepositorySource 
might be deprecated.

These are the things (in addition to the JSR170 issue) to address IMO. I 
planned to bring them up for discussion when I have time to work on them 
(which is not the case currently :-).

Guido
--
Guido Casper
-
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5mailto:[EMAIL PROTECTED]
D-33100 Paderborn   http://www.s-und-n.de
-

Re: [IMP] Something is wrong with out stores

[Geoff Howard]

Carsten Ziegeler wrote:
The more I look into this store problem, the more I get confused.
I think I understood from Sylvains explanation that the persistent
store should only be used by our store as a back up.
Looking through our code, I found out, that some components
still use the persistent store:
- StatusGenerator
- ClearPersistentStoreAction
- EventAwareCaching
So, should we simply change them to use the store?
That should be fine for EventAwareCaching.  IIRC the reason I had it use 
persistent store directly is that it is used at shutdown to persist the 
cache/event correlation information between runs and it made more sense to me at 
the time to go directly into permanent storage.  Thanks for working on this.

Geoff

Re: [VOTE] Release on monday

[Upayavira]

Carsten Ziegeler wrote:
I think we fixed the most serious problems for 2.1.5 now.
If noone objects I will release the current state on monday,
24th of May. So the code freeze will continue until then.
This gives us some more days to test and possibly fix bugs.
Or is there anything serious that I did oversee?
 

I need to remove the test-suite and use samples/test, and confirm that 
Ugo's fixes have made the CocoonBeanTestCase work, and then re-enable it.

But, as that test is currently disabled, releasing with it in its 
current state is not a major problem. I'd just like to get it done 
before we release.

Upayavira

Re: Persistent storing should work now

[Upayavira]

Carsten Ziegeler wrote:
Due to our change to JCS I found a serious bug in our
own caching keys: the hash code wasn't always calculated
properly :(
This resulted in 

a) an unusable persistent store as after
an application restart the keys didn't match anymore 

and
b) other environments like CLI etc. couldn't use the cache
at all.
 

Great work Carsten.
Can you explain why other environments couldn't use the cache? I'm sure 
I've seen stuff go in and out of the cache within the CLI (but only 
within a single session).

Upayavira

RE: [VOTE] Release on monday

[Carsten Ziegeler]

Joerg Heinicke wrote: 
> 
> On 19.05.2004 10:49, Carsten Ziegeler wrote:
> > I think we fixed the most serious problems for 2.1.5 now.
> 
> Can you sum up the status of the store issues? 

No, I lost track of it...

> There were 
> hundreds of mail on it especially on Monday.
> 
> Before this week we had a non-working persistent store, now 
> we have no longer a persistent store, but a two-stage caching 
> system with both JCS and EHCache? What about the Serializable issues?
> 
Ok, let me try it:

- Between 2.1.4 and 2.1.5 we had the refactoring of the stores. The basic
  idea is to have only two stores that should be used by clients:
  the store and the transient store. The transient store is - well -
  transient - it does not persist data. The store should also persist
  data. It should implement a two phase store (memory -> disk).
- The old (jisp) based implementation of the store used the persistent
  store to persist the data.
- Due to the refactoring we had severe problems (don't know which)
  that prevented us from releasing - this came up on friday. (it was
  mentioned here and there earlier)

- Now: we are using JCS for the store. JCS itself has a two-phase
  caching implemented and therefore we don't need a persistent store
  anymore.
- We still use the memory store for the transient store.

- If you put objects into the store, they have to be serializable now.
  Even if JCS holds the data just in memory, it assumes that the
  objects are serializable. Perhaps they will change this perhaps
  not.
  Although this is different from the jisp based version it doesn't
  affect us as we are using serializable objects anyway - which makes
  sense as they whole data should be persistent later on.

- If you put objects into the transient store they don't have to
  be serializable.

- Persisting cache entries inbetween application starts didn't work
  very well with Jisp as we had bugs in Cocoon.
  This works now with JCS.
- There is only one bug: JCS is not always writing the data to disk. It
  seems that there has to be a critical mass of data before it gets
  written. - we reported this issue and I hope they will fix it. But
  this is not a serious issue as the persistence is not that important
  and didn't work before anyway.

So, to sum it up: imho we have no a working system that is based on JCS.
There are minor problems that we can fix in the next releases.

I hope I didn't forget anything.

Carsten

RE: CInclude caching in pipelines

[Carsten Ziegeler]

José Ignacio París Prieto wrote:
> 
> Sorry for my misunderstanding :), but ...
No problem!

> does it means that the CInclude transformer isn't aware of 
> changes of the included sources, and, consecuently, it 
> doesn't report those changes to the pipeline component, 
> returning the cached contents despite they are obsolete?
Yes, exactly. It is your (the application developers) responsibility
to take care of this fact. IF you know when your included
sources change, you can configure the caching for the 
pipeline accordingly.

> If it does so, it means that the cinclude cache only 
> refreshes when the expires period is over. is that ok?
Yes.

> In that case, i'd like to implement a cinclude-cache 
> mechanism that is aware of modifications of the included 
> sources. I suspect that IncludeCacheManager and Source have 
> something to do there. Could anybody give me a clue?
Source is an abstraction of the included content, you can get
the contents from a source, some information and important
for caching, a SourceValidity object. This can be used
to test, if a cached response is valid or not.
For example if the source points to a file, the SourceValidity
contains the time stamp of the file to test if it has changed etc.

Now, the "only" thing you have to do is to collect all
SourceValidity objects of the included sources and return
them to the caching system (using the getValidity() method
of the cinclude transformer)
On the next invokation, you again collect these items
of the included sources, return them (by the transformer)
and the caching system tests if each source is still
valid. If one has changed, the pipeline is run again.

HTH
Carsten
> Thanks
> 
> - Original Message -
> From: "Carsten Ziegeler" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, May 19, 2004 10:58 AM
> Subject: RE: CInclude caching in pipelines
> 
> 
> José Ignacio París Prieto wrote:
> >
> > Hello,
> > I,ve 2 questions about CInclude and caching:
> > - it seems to implement the CacheableProcessingComponent
> > interface, in order to support caching in a pipeline, but,
> > looking through the code, the "getKey" method ALWAYS RETURN
> > "1" for all instances of the component. It's supossed that
> > the key returned must be unique for each different result of
> > the cinclude transformation. is that ok?
> > - moreover, this caching support is only activated if the
> > parameter "support-caching" is set to true (look at the setup
> > method), which is not documented.
> > Are those true or am I losing something?
> 
> Yes, they are true :)
> The caching algorithm checks if a cached response is valid
> based on the "input" of a pipeline component. The "input"
> of a component are e.g. parameters, the source that is read
> etc. But the component can rely on the fact that it always
> gets the same XML stream.
> So, in other words, the cinclude transformer has the same
> behaviour if the same XML comes into the transformer. The
> xml contains the same include statements etc. So, that's
> why the key is simply "1".
> For example, the file generator returns the source it reads
> as the key (the uri) because this is the "input" for the generator.
> It doesn't get any XML.
> 
> Now, caching is only enabled if you set the parameter, yes,
> this is because of compatibility and because of ease-of-use.
> The caching has been introduced very lately, so if this
> would be the default behaviour some users would be surprised
> to see now changes even if they change the included sources etc.
> And this is of course also useful for highly dynamic includes,
> development and testing.
> 
> HTH
> Carsten
> 
> Carsten Ziegeler
> Open Source Group, S&N AG
> http://www.osoco.net/weblogs/rael/
> > I'm pretending to
> > support the "If-modified-since" http header for pipelines. It
> > works for those which CInclude caching activated in that way,
> > but I think that something is wrong with the "1" key.
> > wouldn't be better return the src URI in that method?
> >
> > Regards
> > Jose
> >
> 

Re: [VOTE] Release on monday

[Joerg Heinicke]

On 19.05.2004 10:49, Carsten Ziegeler wrote:
I think we fixed the most serious problems for 2.1.5 now.
Can you sum up the status of the store issues? There were hundreds of 
mail on it especially on Monday.

Before this week we had a non-working persistent store, now we have no 
longer a persistent store, but a two-stage caching system with both JCS 
and EHCache? What about the Serializable issues?

Joerg

Re: CInclude caching in pipelines

[José Ignacio París Prieto]

Sorry for my misunderstanding :), but ...
does it means that the CInclude transformer isn't aware of changes of the
included sources, and, consecuently, it doesn't report those changes to the
pipeline component, returning the cached contents despite they are obsolete?
If it does so, it means that the cinclude cache only refreshes when the
expires period is over. is that ok?
In that case, i'd like to implement a cinclude-cache mechanism that is aware
of modifications of the included sources. I suspect that IncludeCacheManager
and Source have something to do there. Could anybody give me a clue?
Thanks

- Original Message - 
From: "Carsten Ziegeler" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 19, 2004 10:58 AM
Subject: RE: CInclude caching in pipelines


José Ignacio París Prieto wrote:
>
> Hello,
> I,ve 2 questions about CInclude and caching:
> - it seems to implement the CacheableProcessingComponent
> interface, in order to support caching in a pipeline, but,
> looking through the code, the "getKey" method ALWAYS RETURN
> "1" for all instances of the component. It's supossed that
> the key returned must be unique for each different result of
> the cinclude transformation. is that ok?
> - moreover, this caching support is only activated if the
> parameter "support-caching" is set to true (look at the setup
> method), which is not documented.
> Are those true or am I losing something?

Yes, they are true :)
The caching algorithm checks if a cached response is valid
based on the "input" of a pipeline component. The "input"
of a component are e.g. parameters, the source that is read
etc. But the component can rely on the fact that it always
gets the same XML stream.
So, in other words, the cinclude transformer has the same
behaviour if the same XML comes into the transformer. The
xml contains the same include statements etc. So, that's
why the key is simply "1".
For example, the file generator returns the source it reads
as the key (the uri) because this is the "input" for the generator.
It doesn't get any XML.

Now, caching is only enabled if you set the parameter, yes,
this is because of compatibility and because of ease-of-use.
The caching has been introduced very lately, so if this
would be the default behaviour some users would be surprised
to see now changes even if they change the included sources etc.
And this is of course also useful for highly dynamic includes,
development and testing.

HTH
Carsten

Carsten Ziegeler
Open Source Group, S&N AG
http://www.osoco.net/weblogs/rael/
> I'm pretending to
> support the "If-modified-since" http header for pipelines. It
> works for those which CInclude caching activated in that way,
> but I think that something is wrong with the "1" key.
> wouldn't be better return the src URI in that method?
>
> Regards
> Jose
>

RE: [IMP] Something is wrong with out stores

[Carsten Ziegeler]

Sylvain Wallez wrote:
> 
> StatusGenerator explicitely display information about the 
> various stores, and as Upayavira said 
> ClearPersistentStoreAction clears, well... 
> the persistent store.
>
:)
 
> So it can be considered legal for them to access the 
> persistent store *if it exists*. We should just test this 
> using manager.hasService() to ensure proper operation when no 
> persistent store exists (StatusGenerator already has some 
> protection for this).
> 
Sounds reasonable, will add it.

> As for EventAwareCaching, it seems I forgot it during the 
> cache cleanup, and it should use the regular Store.ROLE 
> instead of using directly the persistent store.
> 
Thanks
Carsten

Re: [VOTE] Release on monday

[Bertrand Delacretaz]

Le 19 mai 04, à 10:49, Carsten Ziegeler a écrit :
...If noone objects I will release the current state on monday,
24th of May
+1, but won't be able to help (once again), leaving for a holiday 
tomorrow till Sunday.

-Bertrand

Re: [VOTE] Release on monday

[Ugo Cei]

Carsten Ziegeler wrote:
Or is there anything serious that I did oversee?
Nothing, apart a few failing anteater tests. I think those are due to 
faulty testcases more than to faulty code. Or maybe it's just wishful 
thinking. Anyway, +1 for a release on Monday. Hopefully I'll find some 
time to look after them in the next few days.

Ugo

Re: [IMP] Something is wrong with out stores

[Sylvain Wallez]

Carsten Ziegeler wrote:
The more I look into this store problem, the more I get confused.
I think I understood from Sylvains explanation that the persistent
store should only be used by our store as a back up.
Looking through our code, I found out, that some components
still use the persistent store:
- StatusGenerator
- ClearPersistentStoreAction
- EventAwareCaching
So, should we simply change them to use the store?
 

StatusGenerator explicitely display information about the various 
stores, and as Upayavira said ClearPersistentStoreAction clears, well... 
the persistent store.

So it can be considered legal for them to access the persistent store 
*if it exists*. We should just test this using manager.hasService() to 
ensure proper operation when no persistent store exists (StatusGenerator 
already has some protection for this).

As for EventAwareCaching, it seems I forgot it during the cache cleanup, 
and it should use the regular Store.ROLE instead of using directly the 
persistent store.

Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

RE: CInclude caching in pipelines

[Carsten Ziegeler]

José Ignacio París Prieto wrote:
> 
> Hello,
> I,ve 2 questions about CInclude and caching:
> - it seems to implement the CacheableProcessingComponent 
> interface, in order to support caching in a pipeline, but, 
> looking through the code, the "getKey" method ALWAYS RETURN 
> "1" for all instances of the component. It's supossed that 
> the key returned must be unique for each different result of 
> the cinclude transformation. is that ok?
> - moreover, this caching support is only activated if the 
> parameter "support-caching" is set to true (look at the setup 
> method), which is not documented.
> Are those true or am I losing something?  

Yes, they are true :)
The caching algorithm checks if a cached response is valid
based on the "input" of a pipeline component. The "input"
of a component are e.g. parameters, the source that is read
etc. But the component can rely on the fact that it always
gets the same XML stream.
So, in other words, the cinclude transformer has the same
behaviour if the same XML comes into the transformer. The
xml contains the same include statements etc. So, that's
why the key is simply "1".
For example, the file generator returns the source it reads
as the key (the uri) because this is the "input" for the generator.
It doesn't get any XML.

Now, caching is only enabled if you set the parameter, yes,
this is because of compatibility and because of ease-of-use.
The caching has been introduced very lately, so if this
would be the default behaviour some users would be surprised
to see now changes even if they change the included sources etc.
And this is of course also useful for highly dynamic includes,
development and testing.

HTH
Carsten 

Carsten Ziegeler 
Open Source Group, S&N AG
http://www.osoco.net/weblogs/rael/
> I'm pretending to 
> support the "If-modified-since" http header for pipelines. It 
> works for those which CInclude caching activated in that way, 
> but I think that something is wrong with the "1" key. 
> wouldn't be better return the src URI in that method?
> 
> Regards
> Jose
> 

[VOTE] Release on monday

[Carsten Ziegeler]

I think we fixed the most serious problems for 2.1.5 now.

If noone objects I will release the current state on monday,
24th of May. So the code freeze will continue until then.
This gives us some more days to test and possibly fix bugs.

Or is there anything serious that I did oversee?

Carsten 

Carsten Ziegeler 
Open Source Group, S&N AG
http://www.osoco.net/weblogs/rael/

CInclude caching in pipelines

[José Ignacio París Prieto]

Hello,
I,ve 2 questions about CInclude and caching:
- it seems to implement the CacheableProcessingComponent interface, in order
to support caching in a pipeline, but, looking through the code, the
"getKey" method ALWAYS RETURN "1" for all instances of the component. It's
supossed that the key returned must be unique for each different result of
the cinclude transformation. is that ok?
- moreover, this caching support is only activated if the parameter
"support-caching" is set to true (look at the setup method), which is not
documented.
Are those true or am I losing something?  I'm pretending to support the
"If-modified-since" http header for pipelines. It works for those which
CInclude caching activated in that way, but I think that something is wrong
with the "1" key. wouldn't be better return the src URI in that method?

Regards
Jose

Persistent storing should work now

[Carsten Ziegeler]

Due to our change to JCS I found a serious bug in our
own caching keys: the hash code wasn't always calculated
properly :(
This resulted in 

a) an unusable persistent store as after
an application restart the keys didn't match anymore 

and

b) other environments like CLI etc. couldn't use the cache
at all.

Both should now work (I only tested a) though).

Carsten 

Carsten Ziegeler 
Open Source Group, S&N AG
http://www.osoco.net/weblogs/rael/

RE: [IMP] Something is wrong with out stores

[Carsten Ziegeler]

Upayavira wrote:
> 
> Carsten Ziegeler wrote:
> 
> >The more I look into this store problem, the more I get confused.
> >
> >I think I understood from Sylvains explanation that the persistent 
> >store should only be used by our store as a back up.
> >Looking through our code, I found out, that some components 
> still use 
> >the persistent store:
> >- StatusGenerator
> >- ClearPersistentStoreAction
> >- EventAwareCaching
> >
> >So, should we simply change them to use the store?
> >  
> >
> Well, no. Surely the StatusGenerator is telling you the state 
> of the persistent store, the ClearPersistentStoreAction is, 
> well, need I say (not sure about the EventAwareCaching). 
> Probably what Sylvain was saying is that nothing stores 
> objects directly into the persistent store, they all go via 
> the default store. But, for status, etc, reasons, it seems 
> okay to me to access the persistent store directly.
> 
Sure, but with JCS/EHCache we don't have a persistent store
anymore as the "store" has the two-phase caching already 
implemented.

Carsten

Re: [IMP] Something is wrong with out stores

[Upayavira]

Carsten Ziegeler wrote:
The more I look into this store problem, the more I get confused.
I think I understood from Sylvains explanation that the persistent
store should only be used by our store as a back up.
Looking through our code, I found out, that some components
still use the persistent store:
- StatusGenerator
- ClearPersistentStoreAction
- EventAwareCaching
So, should we simply change them to use the store?
 

Well, no. Surely the StatusGenerator is telling you the state of the 
persistent store, the ClearPersistentStoreAction is, well, need I say 
(not sure about the EventAwareCaching). Probably what Sylvain was saying 
is that nothing stores objects directly into the persistent store, they 
all go via the default store. But, for status, etc, reasons, it seems 
okay to me to access the persistent store directly.

Upayavira

[IMP] Something is wrong with out stores

[Carsten Ziegeler]

The more I look into this store problem, the more I get confused.

I think I understood from Sylvains explanation that the persistent
store should only be used by our store as a back up.
Looking through our code, I found out, that some components
still use the persistent store:
- StatusGenerator
- ClearPersistentStoreAction
- EventAwareCaching

So, should we simply change them to use the store?

Carsten 

Carsten Ziegeler 
Open Source Group, S&N AG
http://www.osoco.net/weblogs/rael/

Re: Status of repository block and webdav question.

[Rolf Kulemann]

On Wed, 2004-05-19 at 09:10, Guido Casper wrote:
> Rolf Kulemann wrote:
> > What u mean with Repository block? IMHO there are currently two
> > approaches hosted within the repository bloch, which should be divided
> > normally.
> > 
> > 1.) SourceRepository which acts on various interfaces like
> > VersionableSource etc. 
> > 
> > 2.) Repository interface with a WEbDAV _only_ implementation which is
> > too flow oriented (no exception handling etc.)
> 
> These 2 (interfaces) are not all that different (like different 
> approaches) and I plan to merge them.

Sorry, but they are different to me. Repository acts on String like
paths and exposes services. The SourceRepository just acts on services
exposed by the various *Source interfaces. That looks to me like two
different approaches.

I'm curious about ur concrete merging thoughts. Would be cool if u share
ideas :)


-- 
Regards,

Rolf Kulemann

Re: Status of repository block and webdav question.

[Rolf Kulemann]

On Wed, 2004-05-19 at 08:58, Guido Casper wrote:
> Johann Romefort wrote:
> > Hi,
> > 
> > Could someone provide me with a quick note status about the repository 
> > block? Is there something already useable in the CVS?
> > Also I m wondering what are the pros and cons about using Slide block or 
> > WebDAV block.
> 
> My take on this is:
> 
> Consider using the Slide block for in-VM repository access for max 
> performance.

True.

> 
> Use WebDAV for remote repository access for max flexibility.

If u only need some simple access, so no transactions.

> 
> Both are to be considered unstable (i.e. alpha). Both contain parts 
> being used in productions systems today.
> 
> Both are likely to be influenced by JSR170 (which just went into public 
> review). But this IMHO heavily depends of the availability (and nature) 
> of a RI and how the Slide project/community is willing/able to adopt it.

Yes, we are all waiting for it, but I guess nobody should hold a breath
on it.

At the end, cocoon has no real repository integration, but various
approaches to access different kind of backends depending on ur special
situation. I do not say this is bad or good, I only say how it is.

Of course slide is integrated so one could say, cocoon has an rep.
integration, but that is not an repository abstraction which makes
applications using it independent of the implementation (slide).

-- 
Regards,

Rolf Kulemann

Re: Status of repository block and webdav question.

[Guido Casper]

Rolf Kulemann wrote:
What u mean with Repository block? IMHO there are currently two
approaches hosted within the repository bloch, which should be divided
normally.
1.) SourceRepository which acts on various interfaces like
VersionableSource etc. 

2.) Repository interface with a WEbDAV _only_ implementation which is
too flow oriented (no exception handling etc.)
These 2 (interfaces) are not all that different (like different 
approaches) and I plan to merge them.

Guido
--
Guido Casper
-
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5mailto:[EMAIL PROTECTED]
D-33100 Paderborn   http://www.s-und-n.de
-

Re: Status of repository block and webdav question.

[Rolf Kulemann]

On Wed, 2004-05-19 at 09:10, Guido Casper wrote:
> Rolf Kulemann wrote:
> > What u mean with Repository block? IMHO there are currently two
> > approaches hosted within the repository bloch, which should be divided
> > normally.
> > 
> > 1.) SourceRepository which acts on various interfaces like
> > VersionableSource etc. 
> > 
> > 2.) Repository interface with a WEbDAV _only_ implementation which is
> > too flow oriented (no exception handling etc.)
> 
> These 2 (interfaces) are not all that different (like different 
> approaches) and I plan to merge them.

+1. That makes sense. If I/we could help, I/we will do it :)

-- 
Regards,

Rolf Kulemann