Hi,
there seems to be a bug in org.apache.slide.structure.StructureImpl and
also in org.apache.slide.structure.ObjectNode introduced by your changes.
Symptoms: When creating objects from the data part of the Domain.xml
file that are already there, they are not linked to the root collection
/.
Hi Christophe,
you can find the status of the JSR 170 at
http://www.jcp.org/en/jsr/detail?id=170
You can find an implementation in the proposals folder in the CVS
repository (or nightly build).
Oliver
Christophe Lombart wrote:
What is the status on JCP 170 ?
Is there some developement on
Hi Peter,
thanks for helping!
Nevermann, Dr., Peter wrote:
Hi Oliver,
thanks for the pointers. Unfortunately, I couldn't reproduce the problem at
my side - therefore I would be glad if you could send me your Domain.xml
file if the changes I checked-in do not remedy your problem.
My Domain.xml
check
XMLFileDescriptorsStore and update it if appropriate. I will supply the
patch for it! Right now the CVS server does not seem to be up and
working, so and can not make a diff. I will try again later that day or
tomorrow!
Thanks for helping :)
Oliver
Oliver Zeigermann wrote:
Nevermann, Dr
The missing patch
Index: src/stores/slidestore/file/XMLFileDescriptorsStore.java
===
RCS file:
/home/cvspublic/jakarta-slide/src/stores/slidestore/file/XMLFileDescriptorsStore.java,v
retrieving revision 1.6
diff -u -w -r1.6
Hi Grant,
I think your patch is very good. It helped me quite a bit. Thanks :)
Unfortunately, after having a look at the JTA implementation in Slide I
discovered there might be a problem:
SlideTransaction seems to guarantee to the enlisted XAResouces (in our
case Slide services and practically
.
I haven't tested branching.
I've been using a Jboss 3.x transaction manager, which has a similar one
thread per transaction implementation.
-Grant
Oliver Zeigermann wrote:
Hi Grant,
I think your patch is very good. It helped me quite a bit. Thanks :)
Unfortunately, after having a look
Hi Peter,
we are currently trying to make our store binding enabled. It occurs to
me that we will not only have to adapt our own store, but also have to
replace org.apache.slide.store.StandardStore. This is quite a drastic
change as this class implements one of Slides most prominent features:
Hi Peter,
thanks for the quick and extensive answer :)
we are currently trying to make our store binding enabled. It
occurs to
me that we will not only have to adapt our own store, but
also have to
replace org.apache.slide.store.StandardStore.
Why that?
This is quite a drastic
change as
which
help binding enabling in the stores.
Regards,
Peter
-Original Message-
From: Oliver Zeigermann [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 24, 2003 09:08
To: Slide Developers Mailing List
Subject: Re: Support for Binding
Hi Peter,
thanks for the quick and extensive answer
Dear Slide community,
my employer C1 Financial Services GmbH has donated a transactional
file store to the Slide project. It should be in the CVS by now and be
scheduled for the 2.0 release. It is based on the reference
implementation slidestore.file.XMLFileDescriptorsStore and
Martin Holz wrote:
my employer C1 Financial Services GmbH has donated a transactional
file store to the Slide project. It should be in the CVS by now and be
scheduled for the 2.0 release. It is based on the reference
implementation slidestore.file.XMLFileDescriptorsStore and
Hallo Martin,
thanks for the quick reply.
Martin Holz wrote:
Oliver Zeigermann [EMAIL PROTECTED] writes:
There still seem to be some bugs left, presumably mainly taken over from
the reference implementation. We will do our best to further analyze and
fix them.
FileResourceManager.saveState
the noise. It was a configuration error. I had two
stores, which used the same working directory.
Now everything is fine.
Oliver Zeigermann [EMAIL PROTECTED] writes:
Martin Holz writes:
A minor point, shouldn't you use
File dir = new File(workDir,txId)
instead of
File dir = new File(workDir
That's fine :)
As Stefan pointed out you can disable the cache. That was something I
had forgotten about. I thought I had to fix the StandardStore first and
then continue with fixes for my store that were hard to fix because of
inaccurate caching.
In short: I will do some fixes on the tx file
There seems to be another bug in ObjectNode:
In getChildren() there is a check for childrenCache being null. If it
is, the cache will be recomputed. The cache will be reset on every
addition or removal of a binding or a child which is correct.
Unfortunately when copyObject() is called like
cache.
*
* @author a href=mailto:[EMAIL PROTECTED]Oliver Zeigermann/a
* @version $Revision: 1.0$
*/
public class TxLRUObjectCache {
protected Map globalCache;
protected Map txChangeCaches;
protected Map txDeleteCaches;
protected int hits = 0;
protected int misses = 0
Duncan McLean wrote:
Thanks Oliver, I'll try to take a look at this to see if it helps. I will
say I agree with Martin though, I think fixing StandardStore as well would
be a good idea. I can only think that people would appreciate a faster
StandardStore. Anyone who has made something that relies
Peter!
Thanks a lot for all your support :)
Oliver
Nevermann, Dr., Peter wrote:
Checked-in of the patch is done.
Regards,
Peter
-Original Message-
From: Oliver Zeigermann [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 16, 2003 13:58
To: Slide Developers Mailing List
Subject: Re
There seems to be a bug in NamespaceConfig.getUsersPath(). It returns
null in initialization:
Thread [main] (Suspended (breakpoint at line 860 in SecurityImpl))
SecurityImplAllGrant(SecurityImpl).getPrincipal(SlideToken) line: 860
SecurityImplAllGrant(SecurityImpl).hasPermission(SlideToken,
Hi Ingo,
thanks for helping!
This indeed eliminates the null pointer. But the real problem is there
is nothing stored in usersPath and it is thus . Also, when you do not
authorize, your userId will be .
In LockImpl.computeSubjectUriFromPrincipal
the statement
Martin Holz wrote:
Oliver Zeigermann [EMAIL PROTECTED] writes:
Martin Holz wrote:
TxLRUObjectCache(tx(object)).
Or is this too much?
No. It is usefull. However my problem was the syntax of the name:
A(B(C))) vs A.B.C How do you configure log4j for the first
case?
You are right, let's use
org.apache.slide.util.*;
import org.apache.slide.util.ObjectCache;
import javax.transaction.xa.XAException;
import javax.transaction.xa.Xid;
import org.apache.slide.util.logger.Logger;
/**
* Store that allows for transactional caching of data.
*
* @author a href=mailto:[EMAIL PROTECTED]Oliver Zeigermann
Hi,
I have a big struggle integrating our tx file store as well as the tx
cache into Slide. While problems with store and cache in themselves are
under control, the glue between them and Slide causes trouble.
Especially in concurrent scenarios I experience problems.
Maybe someone can help by
Sorry for reading this lengthy post and BIG THANKS for comments in advance,
Ooops, hope you are not sorry :)
Wanted to say:
*Thanks* for reading this lengthy post and BIG THANKS for comments in
advance
-
To unsubscribe,
Hi Christopher,
thanks for commenting!
Christopher Lenz wrote:
The rdbms.J2EEStore was my attempt to refactor the JDBC and J2EE stores
based on a new schema submitted by Ashok Kumar. Unfortunately it was
never finished, and AFAIK it doesn't even work correctly in its current
incarnation.
Hi,
when reading internally from a stream to fill contentBytes or content in
getContent() and getContentBytes() the input stream gets nulled
afterwards, but not closed.
Patch is attached.
Oliver
Index: NodeRevisionContent.java
Next version of caching store. Fixed some tx stuff, added precashing to
ensure multiple usages of content and made things a bit more robust.
Oliver Zeigermann wrote:
Hi,
attached to this post are the new classes for caching.
Caching now uses A.B.C notation for logging and is fully configurable
Oliver Zeigermann wrote:
We know the store is not in stable state, yet. So, please continue to
report errors.
Next step to a stable store.
FIXES:
AbstractTxFileStoreService:
- Transaction will be marked for rollback upon system error or deadlock
- minor flaws
StoreLogger:
- logging of message
are confusing.
rgds
CB
- Original Message -
From: Oliver Zeigermann [EMAIL PROTECTED]
To: Slide Developers Mailing List [EMAIL PROTECTED]
Sent: Friday, October 24, 2003 5:33 AM
Subject: Re: REQUEST FOR HELP/COMMENT: Store problems
Hi Christopher,
thanks for commenting!
Christopher Lenz wrote
Hi,
in all test cases for locking there is a mismatch between the expected
and received response in element owner. The DAV server returns
A:href xmlns:A=DAV: / in CDATA block
thus the expected response should be
lt;A:href xmlns:A=DAV: /gt;
as the whole response is in a CDATA block already.
Seems to be a whitespace issue in Crimson. Unfortunately I can not use
Xerces, as it requires full URLs as system identifiers and certain ids
are missing the protocol.
Any hints?
Thanks in advance,
Oliver
Oliver Zeigermann wrote:
Hi,
in all test cases for locking there is a mismatch
Hi Jaboc,
Jacob Lund wrote:
Hi Oliver and Peter!
I think there are a couple of files missing for the TX store:
ByteSizeLimitedObjectCache.java
TxLRUObjectCache.java
TxCacheStore.java
Hmmm. The tx store should work without this new caching. Just tried it
with the StandardStore and did not
to do here?
Peter, do you have this problem as well or am I doing anything wrong
here? If it is a general problem I would volunteer to fix it.
Oliver
Oliver Zeigermann wrote:
Seems to be a whitespace issue in Crimson. Unfortunately I can not use
Xerces, as it requires full URLs as system
I suppose it is intended. Stores get resolved over the Uri class and
will be enlisted into the current transaction only if they not already
are. So, there should be no problem.
Although not completely on topic, have a look at:
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgNo=2117
- Original Message -
From: Oliver Zeigermann [EMAIL PROTECTED]
To: Slide Developers Mailing List [EMAIL PROTECTED]
Sent: Friday, October 24, 2003 5:33 AM
Subject: Re: REQUEST FOR HELP/COMMENT: Store problems
Hi Christopher,
thanks for commenting!
Christopher Lenz wrote:
The rdbms.J2EEStore
method
(instead of addScope) and all implementations are storing a single Scope
instance in a member variable, though we have not any usage of it.
Regards,
Stefan Lützkendorf
Oliver Zeigermann wrote:
I suppose it is intended. Stores get resolved over the Uri class and
will be enlisted
Hi Colin, hi Ashok, hi all!
If you reposted and donated the latest version of your code I will
promise to do my best to merge it with the other versions / branches.
This could be good for us all, as our efforts can be combined!
Anyway (just observations / questions, no exposing or anything
Hello, Peter,
thanks for letting us participate :)
Nevermann, Dr., Peter wrote:
1) User group relationships will not be mapped anymore to the URI
hierarchy
Instead, the DAV:group-member-set and DAV:group-membership properties are
used which allows for many-to-many relationships between users
[EMAIL PROTECTED] wrote:
2.) Why do you think the approach in org.apache.slide.store.impl.rdbms
is better than yours? Why is there an adapter? Also, where do you see a
nicer Java approach?
Well with the adaptor then different DB optimizations maybe more easily
accommodated.
Also I prefer more
Martin Dulisch wrote:
In WebDAV principals are also represented as resources. These
have the properties. You can find a detailed description here:
http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-12.htm#_Toc53484905
Thanks Martin, this makes things clear to me. I am not very good in
Michael Smith wrote:
Be warned that NONE of the JDBC/J2EE based stores can be safely used
with access control, unless you take care to never set an ACL with more
than one ACE. See the discussion of this a few months back as to why
(fixing it requires minor db schema changes).
Ahhh. Thanks for
[EMAIL PROTECTED] wrote:
Resubmitting the latest J2EEStore related classes from our CVS. I have
incorporated the point(1) raised by Oliver. Now we have nested
try..final blocks for each.
Thanks alot Ashok. I will try it out soon.
I understand you agree to have it merged with the other store
Oliver Zeigermann wrote:
[EMAIL PROTECTED] wrote:
2.) Why do you think the approach in
org.apache.slide.store.impl.rdbms is better than yours? Why is there
an adapter? Also, where do you see a
nicer Java approach?
Well with the adaptor then different DB optimizations maybe more easily
Oliver Zeigermann wrote:
Maybe we should think
about a third store using this adapter that also explicitely makes use
of connection pooling, e.g. using DBCP.
Which really is not necessary as you can configure the driver which can
well be org.apache.commons.dbcp.PoolingDriver.
Besides I
Message -
From: Oliver Zeigermann [EMAIL PROTECTED]
To: Slide Developers Mailing List [EMAIL PROTECTED]
Sent: Wednesday, November 05, 2003 5:43 AM
Subject: Re: [VOTE]: J2EE-Adapter or Not
Oliver Zeigermann wrote:
Maybe we should think
about a third store using this adapter that also explicitely
There still is some odd behavior when closing resources in finally
blocks in Ashok's code. Only the final statement will throw a
ServiceAccessException on error while closing. I'd say either throw
always or never...
So, always or never?
Oliver
Oliver Zeigermann wrote:
OK. I think we waited
Christophe Lombart wrote:
I'm trying to use J2EEStore with MySql (with adapter :-)) ). I also
modifed this store in order to support DBCP.
Unfortunatly, I got some deadlock issues when this store makes some delete.
Do you know how to solve this problem ?
Without deletes, everything works fine,
Got the initial version running now. Had to change minor stuff only.
Have no SQLServer installation so tested it on Sybase as this only meant
very little changes in schema and query. Manual tests look good, need to
run the testsuite and especially the concurrent tests...
Fixes on ACE still
secs (!)
PROPFIND ~ 17 secs
READ ~ 12 - 20 secs
DELETE ~ 35 - 45 secs
Oliver Zeigermann wrote:
Got the initial version running now. Had to change minor stuff only.
Have no SQLServer installation so tested it on Sybase as this only meant
very little changes in schema and query. Manual tests look
Nevermann, Dr., Peter wrote:
WRT the Slide 2.0 release: we know that is time for a new release and know
about how important it is for you all. You are completely right! The only
problem seem to be that we cannot find somebody willing to manage the
release process. Also, there are currently areas
Martin Dulisch wrote:
Oliver Zeigermann wrote:
Nevermann, Dr., Peter wrote:
WRT the Slide 2.0 release: we know that is time for a new
release and know about how important it is for you all. You
are completely right! The only problem seem to be that we
cannot find somebody willing to manage
Stefano Mazzocchi wrote:
1) what's the status of the tree? I found out that contributed WebDAVGUI
is out of synch with the various libraries and it seems dead. I also
find the distribution way too tomcat centric.
That's true if you want to use Slide authentication for the container. I
agree
Just wondering, why does ObjectNode support serializability in the first
place?
Oliver
Steve Vaughan wrote:
Although ObjectNode implements Serializable, one of its fields (BindingList)
is not. BindingList has only one field, which is a Vector. Is their any
reason why BindingList should not
Martin Dulisch wrote:
Well, I just proposed myself for the job of the release
manager on the user list. If poeple accept me for this job or
anybody else volunteers for it, (hopefully) few things stand
in the way of a first milestone release in the near future.
Certainly, I will need commit access
complete DISMAY performance measurements showed no significant
difference to the untuned version. *Sigh*
Because this version is cleaned and at least does *not run slower* and
some deadlocking spots have already been removed, I proposed to continue
on this track.
Comments?
Oliver
Oliver Zeigermann
Stefano Mazzocchi wrote:
On 12 Nov 2003, at 09:30, Oliver Zeigermann wrote:
Stefano Mazzocchi wrote:
I'm using it with Jetty and it doesn't have any problem. But, like I
said, I found the process of taking out pieces from tomcat rather
painful.. not something that a newbie would do without
Stefano Mazzocchi wrote:
TODO
- many oddities including permissions occasionally mixed up (still in
spite of ACE fix)
- confusion about branches and versions
- Some sort of deadlocks occur on delete and insert when having an
isolation level higher than read committed. These can hardly be real
Martin Dulisch wrote:
Stefano Mazzocchi wrote:
On 13 Nov 2003, at 12:36, Oliver Zeigermann wrote:
Status report of J2EE-Store. Some stuff done, big amount of
work left...
what is the difference between a J2EE store and a JDBC store?
As far as I know the J2EE store uses the connection pool from
Martin Holz wrote:
- ports to other major databases. I can do Oracle, but will need help
with others
I will try it on Postgres.
Fine :)
I found, that access control has much impact on performance,
since slide has to visit all parent nodes. Without caching
enabled for the security store, slide
Stefano Mazzocchi wrote:
BTW, did you guys ever considered the use of a lazy pattern for updates?
a-la messaging file system?
Basically, you have a memory store that saves in a log file (sort of an
equivalent of a messaging file system) some events. the log file is
already open and buffered by
For everyone subscribed to the dev list only: Discussion about the new
release has been started in the user list. Please keep the discussion in
that list.
Oliver
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
Steve Vaughan wrote:
On Thursday 13 November 2003 10:19 am, Oliver Zeigermann wrote:
As I recently discussed with Christophe some sort of write-back cache
could not only buffer reading, but also writing. As described above it
would be synced with persistent store upon commit (or upon prepare?
hmmm
Jacob Lund wrote:
Just a note!
My testing of the J2EE store showed a big difference between the JDBC driver
vendors! Microsoft was clearly the slowest one of the drivers I did tests
on!
One of the better ones was from DataDirect!
Thanks, just tried the one from DataDirect and it seemed to be
starting with a release plan and
the election (often by lazy acclamation) of the release manager.
so, it's probably best to invite anyone from the user list who's
interested over to the dev (rather than vice-versa).
- robert
On 13 Nov 2003, at 15:29, Oliver Zeigermann wrote:
For everyone subscribed
[COPIED FROM USERS LIST, THIS IS HERE IN THE DEV LIST IS THE RIGHT POST
TO FOLLOW UP]
Hi everyone!
I understand those votes from active committers which are
+1 from Martin
+1 from Ingo
+1 from Peter
mean:
1. We actually should start a release process now
2. I should be the release manager
If
Hi!
As you may have seen, commit access has finally been granted to me and I
added a directory for code that is no longer supported or needed. I'd
propose to make this the new home for the stores in the slidestore
package. I guess this is a significant step, right? Do we need a vote?
Oliver
Hi!
I have just committed the initial proposal for the merged RBDMS store
into the proposal section of the CVS. It should work with the current
ACL-12 implementation, although no extensive testing has been done yet.
To sum things up:
- Adapter concept has been taken over from the work
Hi, again!
Added the new kernel store ExtendedStore (aka TxCacheStore) to the
CVS. It provides transactional caching for descriptors as well as
content. Caching is based on LRUMap from commons-collections. Added this
to the lib dir and also into build.xml
The store is meant as a replacement
Hi!
I am glad to announce the tx store version I just cheched in is now
stable. What does stable mean? It passed all functional tests of the
testsuite except the ones I will name below, in other words as stable as
it gets. Additionally, under concurrent stress tests with up to 100
parallel
I have come across the fact that you can either log a message or a
throwable. Of course you can cope with this with two logging statements,
first logging message, second throwable. As this isn't too obvious, I
thought we might add a new method to interface
org.apache.slide.util.logger.Logger
Folks, sorry for that, but because I moved locking from the stores to
the kernel to have it available for kernel level caching, I forgot to
move the logger as well. That's way Slide does not build any more.
Moving the StoreLogger from the stores to the util package in the kernel
should fix the
Stefano Mazzocchi wrote:
[snip]
the past as well, but it's a good practice to avoid that since it gives
a sloppy impression to the users if the fresh checkout doesn't build..
and they are very likely to run away instead of report back]
Right. Thanks to Jacob for reporting and not running away
Stefano Mazzocchi wrote:
I think users should be able to do
cvs co jakarta-slide
ant
./slide
and get it running. The required (non-optional) jars should be included
in the download or fetched by the build script from jar repositories
(the only problem seems to be JTA which is under the Sun
Stefano Mazzocchi wrote:
On 15 Nov 2003, at 00:47, Oliver Zeigermann wrote:
Stefano Mazzocchi wrote:
I think users should be able to do
cvs co jakarta-slide
ant
./slide
and get it running. The required (non-optional) jars should be
included in the download or fetched by the build script
Martin Holz wrote:
MemoryStore and and the database stores at slidestore are a problem,
since there is no direct replacement available.
Hmmm. I though the replacement for the database store would be the JDBC
/ J2EE we are currently merging and getting to work. It is available in
the
Mike Oliver wrote:
#1 I believe it is less than desireable to require jars to be moved out
of the webapp and into Tomcat's commons for a lot of reasons, not the
least of which is the compatibility of other webapps and classpath
problems (with other webapps on that same Tomcat) you introduce by
Martin Holz wrote:
Mike Oliver [EMAIL PROTECTED] writes:
Please clarify. I am using the XMLDestriptorStore and
FileContentStore and would like to know if they are in the attic and
if so, replaced by ???
I would consider them obsolete. They should be replaced by
As it seems to be clear by now there will be a 2.0 release. This
includes there will be milestone releases before the final one which
will be available as binaries *in pricipal*.
The problem for me is what a Slide binary release may look like... I
have seen the 1.0.x binary comes as a Tomcat
Hi Richard,
this sounds pretty interesting. As I did not even know before there
existed such a wrapper, I am hardly the right person to evaluate your
work. Though, what I can offer is you send this to me directly (not to
the list to avoid branching) and I check it into the proposals section
Mike Oliver wrote:
Then would it not be a good idea to package the binaries such that the
starting working version uses the Tx stores?
Yes
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
org.apache.slide.search
- Webdav layer
Ingo Brunberg:
- Client library
Oliver Zeigermann:
- stores
- kernel org.apache.slide.store
- kernel org.apache.slide.util
What about these kernel packages? Anybody feeling responsible?
- org.apache.slide.authenticate
- org.apache.slide.common
- org.apache.slide.content
Hmmm. I guess RUNNING.txt is for 1.0.x, isn't it?
Oliver
Mike Oliver wrote:
I have been working through getting the latest CVS version of Slide to
run on a Linux Red Hat 9 machine with the build coming from Ant in
Eclipse, and here are my notes.
I did a good build with Ant setting /clean/
What JDK should be supported in the 2.0 relase?
My proposal: JDK1.3 required, JDK1.4 recommended as JDK1.2 or less are
hardly used in serious server applications, am I wrong? Anyway if JDK1.2
is aimed to I would need to make slight modifications of my tx file
store, but it should be possible.
Stefano Mazzocchi wrote:
I think we need a little plan of action. (of course, since I'm not an
active committer, I don't get to vote, but at least I'll share some of
my experience in these things).
new generation number
-
From a user perspective, Slide appeared dead for too
starting with a release plan and
the election (often by lazy acclamation) of the release manager.
so, it's probably best to invite anyone from the user list who's
interested over to the dev (rather than vice-versa).
- robert
On 13 Nov 2003, at 15:29, Oliver Zeigermann wrote:
For everyone
doing the cvs co/update.
HTH,
-chris
Oliver Zeigermann wrote:
Hi Robert, hi all,
I have a hard time figuring out how to update the docs. While I seem
to have found out how to actually deploy modified pages on the web
server I suspect, those pages in the Slide pages are not native HTML
Summing up content from other threads:
Main question: What should a binary Slide release look like?
I understand people want something to download and go. Store issue can
be solved without an RDBMS by using tx file store. Prolem is Slide is
not standalone and can only be used with a web
Issues:
1.) What features not yet implemented should go into the Slide 2.0 release?
2.) What needs to be fixed in order to have a first milestone release?
3.) What is in already in the pipeline?
Oliver
-
To unsubscribe,
to reduce the number of
deserialization requests. Serialization is made to a temporary file during
the prepare phase, and commit simply moves the serialized version to the
appropriate location.
-Steve
On Wednesday 12 November 2003 08:49 am, Oliver Zeigermann wrote:
Interesting! When do you
noticed by more, please *correct me*):
Active Committers:
- Ingo Brunberg
- Jürgen Pill
- Peter Nevermann
- Martin Wallmer
- Stefan Guggisberg
- Oliver Zeigermann
Currently Inactive Committers:
- Remy Maucherat
- B. C. Holmes
- Christopher Lenz
- Craig R. McClanahan
- Dave Bryson
- Dirk Verbeeck
- Sung
Oliver Zeigermann wrote:
1.) What features not yet implemented should go into the Slide 2.0 release?
There has been a patch JTA patch proposed by Grant Gongaware some time
ago. This made the transaction manager implmentation configurable to use
the containers instead of Slides integratied TM
Oliver Zeigermann wrote:
3.) What is in already in the pipeline?
Binding implementation for tx file store is in my pipeline. Could be
augmented to include j2ee store.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
Oliver Zeigermann wrote:
1.) What features not yet implemented should go into the Slide 2.0 release?
I observed a lot of overhead in MacroImpl when copying, moving and
deleting resources. I thought it might be a good idea have some sort of
tunneling of this upper tier task to the store itself
1.) What features not yet implemented should go into the Slide 2.0 release?
Tx caching in ExtendedStore does not have locking, but relies on the
cached store for correctness. If the store does not use a conservative
locking protocol isolation might be compromised.
Oliver Zeigermann wrote:
1.) What features not yet implemented should go into the Slide 2.0 release?
If Slide is considered a content repository as a combination of
underlying stores, global locks that live for the duration of a
transaction might be considered. A generic multilevel lock
Oliver Zeigermann wrote:
1.) What features not yet implemented should go into the Slide 2.0
release?
Tx caching in ExtendedStore does not have locking, but relies on the
cached store for correctness. If the store does not use a conservative
locking protocol isolation might be compromised
Forgot
Christopher Taylor and Chris Sharp who contributed documentation.
(Checked in, but not visible on the website or in the local docs, but
only in XML source). Need to work on this...
Oliver Zeigermann wrote:
Trying to update the docs now. Who is to be considered an active
committer? I'd
More contributors:
- Marc Décugis (XMLDescriptorsStore)
- Colin Britton (database stores)
Oliver Zeigermann wrote:
Trying to update the docs now. Who is to be considered an active
committer? I'd say committers can only decide themselves if they are
still active. So please augment / correct my
Setting a date seems to be too early as we have not discussed what
features will be in 2.0, what will be deferred to 2.x or even 3.x. We
also have not defined any milestones.
The most important issue, though, is both file and DB store pass all
tests in our testsuite (at least functional ones)
1 - 100 of 996 matches
Mail list logo
