On Tue, 2004-05-18 at 14:33, Johann Romefort wrote:
Hi,
Could someone provide me with a quick note status about the repository
block?
IMHO, cocoon has no real repository integration.
Is there something already useable in the CVS?
Also I m wondering what are the pros and cons about using
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
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
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_
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
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
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
-
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
[EMAIL PROTECTED] wrote:
section
titleThe Store (aka main Store)/title
p
The store (role emStore.ROLE/em) is used to store objects that are
serializable.
Ummm... Hate repeating [1] myself but this is not correct. See
DefaultStore (which extends
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
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,
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
On Wed, May 19, 2004 at 08:52:52AM -0400, Vadim Gritsenko wrote:
snip/
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
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
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=29103.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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),
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=29103.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
--- 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
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
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
47 matches
Mail list logo
