[jira] Resolved: (JCR-393) WebDAV Library: VersionControlledResource constant lists wrong method
[ http://issues.apache.org/jira/browse/JCR-393?page=all ] angela resolved JCR-393: Fix Version: 1.0.1 Resolution: Fixed fixed rev. 393414 Note: The current solution of listing dav-methods supported by a particular type of resource is not very satifying. Mainly due to the fact that RFC 3253 defines various feature sets that may or may not be supported. The single-string constant does not reflect this. I will post a separate enhancement request that should address this. WebDAV Library: VersionControlledResource constant lists wrong method - Key: JCR-393 URL: http://issues.apache.org/jira/browse/JCR-393 Project: Jackrabbit Type: Bug Components: webdav Reporter: angela Assignee: angela Priority: Trivial Fix For: 1.0.1 VersionControlledResource .methods_checkedIn constant lists UNCHECKOUT which is obviously wrong. RFC3253 lists the UNCHECKOUT method as mandatory method for checked-out vc-resource for the 'checkout-in-place' feature. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-393) WebDAV Library: VersionControlledResource constant lists wrong method
[ http://issues.apache.org/jira/browse/JCR-393?page=all ] angela updated JCR-393: --- Version: 1.0 WebDAV Library: VersionControlledResource constant lists wrong method - Key: JCR-393 URL: http://issues.apache.org/jira/browse/JCR-393 Project: Jackrabbit Type: Bug Components: webdav Versions: 1.0 Reporter: angela Assignee: angela Priority: Trivial Fix For: 1.0.1 VersionControlledResource .methods_checkedIn constant lists UNCHECKOUT which is obviously wrong. RFC3253 lists the UNCHECKOUT method as mandatory method for checked-out vc-resource for the 'checkout-in-place' feature. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (JCR-394) WebDAV Library: Define method-set constants that reflect the feature set.
WebDAV Library: Define method-set constants that reflect the feature set. - Key: JCR-394 URL: http://issues.apache.org/jira/browse/JCR-394 Project: Jackrabbit Type: Improvement Components: webdav Versions: 1.0 Reporter: angela Priority: Minor The current solution of listing dav-methods supported by a particular type of resource within a String constant is not satifying: - Handling and concatenation of the various constants is cumbersome. - They don't use the constants defined with the DavMethod utility. - DavMethod class defines a couple of utility methods to determine if a requested method is part or affected by a particular feature, while the 'method-set' is defined with the resource interfaces. and mainly: - RFC 3253 defines various feature sets that may or may not be supported and combined. The single-string constant does not reflect these sets. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-392) Accessing element by number does not work
[
http://issues.apache.org/jira/browse/JCR-392?page=comments#action_12374156 ]
Oliver Wehrens commented on JCR-392:
The full code for this example is:
import org.apache.jackrabbit.core.jndi.RegistryHelper;
import javax.jcr.*;
import javax.jcr.query.Query;
import javax.jcr.query.QueryManager;
import javax.jcr.query.QueryResult;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import java.util.Hashtable;
public class JackrabbitBug {
public static void main(String[] args) {
String configFile = repository.xml;
String repHomeDir = repository;
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,
org.apache.jackrabbit.core.jndi.provider.DummyInitialContextFactory);
env.put(Context.PROVIDER_URL, localhost);
InitialContext ctx = null;
try {
ctx = new InitialContext(env);
RegistryHelper.registerRepository(ctx,
repo,
configFile,
repHomeDir,
true);
Repository r = (Repository) ctx.lookup(repo);
SimpleCredentials cred = new SimpleCredentials(userid,
.toCharArray());
Session session = r.login(cred, null);
Workspace ws = session.getWorkspace();
Node rn = session.getRootNode();
Query q;
QueryManager qm = ws.getQueryManager();
QueryResult qr;
for (int i=0;i6;i++) {
Node child = rn.addNode(entry);
child.setProperty(title, title +i);
child.setProperty(content, content +i);
session.save();
}
// try both position()=last() and entry[5] both do not work as
expected
System.out.println(Now it should display the last (or this 5th
entry with //entry[5]));
q = qm.createQuery(//entry[position()=last()], Query.XPATH);
qr = q.execute();
NodeIterator it = qr.getNodes();
while (it.hasNext()) {
Node n = it.nextNode();
System.out.println(n.getProperty(content).getValue().getString());
}
} catch (NamingException e) {
e.printStackTrace();
} catch (RepositoryException e) {
e.printStackTrace();
}
}
}
Accessing element by number does not work
-
Key: JCR-392
URL: http://issues.apache.org/jira/browse/JCR-392
Project: Jackrabbit
Type: Bug
Components: query
Environment: svn version 393179M
Reporter: Oliver Wehrens
I have a bunch of wiki:entries stored in my workspace. If I create the
following code:
q = qm.createQuery(//wiki:entry[5], Query.XPATH);
qr = q.execute();
NodeIterator it = qr.getNodes();
The Nodeiterator reports all entries back, bot just the 5th.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (JCR-392) Accessing element by number does not work
[ http://issues.apache.org/jira/browse/JCR-392?page=all ] Marcel Reutegger reassigned JCR-392: Assign To: Marcel Reutegger Accessing element by number does not work - Key: JCR-392 URL: http://issues.apache.org/jira/browse/JCR-392 Project: Jackrabbit Type: Bug Components: query Versions: 0.9, 1.0 Environment: svn version 393179M Reporter: Oliver Wehrens Assignee: Marcel Reutegger I have a bunch of wiki:entries stored in my workspace. If I create the following code: q = qm.createQuery(//wiki:entry[5], Query.XPATH); qr = q.execute(); NodeIterator it = qr.getNodes(); The Nodeiterator reports all entries back, bot just the 5th. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-388) add support for RFC 3253 to the simple server
[
http://issues.apache.org/jira/browse/JCR-388?page=comments#action_12374168 ]
angela commented on JCR-388:
while reviewing the patch i looked for reason the missing size in the
version-report as well.
i'd say this caused by again the missing handler for versions: the
DirListingExportHandler is lazy and does not calculate the resulting size.
regarding the review: i' ll try to write down the findings (mostly minor
improvements and things i think are not solved gracefully in the original code
of the 'jcr-server') and will upload my suggestions in a separate patch as soon
as i'm done and performed some minimal tests.
since i would like to take advantage of your patch to think about a better
structure and how we can package things ('simple' is probably not an appropiate
package name), i would suggest that to have this solved before we commit the
extensions.
hope that's fine.
add support for RFC 3253 to the simple server
-
Key: JCR-388
URL: http://issues.apache.org/jira/browse/JCR-388
Project: Jackrabbit
Type: New Feature
Components: webdav
Versions: 0.9
Reporter: jeremi Joslin
Assignee: angela
Priority: Minor
Attachments: rfc.zip
http://www.ietf.org/rfc/rfc3253.txt
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: my custom access manager
On Wed, 2006-04-12 at 13:35 +0200, Paco Avila wrote: I am developing my custom AccessManager for my jacrabbit based project. User access information is stored in the Nodes. So, I need to access this Node Properties in my custom AccessManager. But I can't because this property access is also checked for security access and will loop until infinite :( How can I access this properties without invoking the AccessManager again? I think it's the general concensus that the best way to implement node stored ACLs in jackrabbit 1.0 is to set up a repository listener at application start-up that logs in with special credentials that your access manager recognises and honours. This listener then keeps a map ACLs, keyed on nodeid, which your access manager uses to get at ACLs when authorising operations on nodes. -- Torgeir Veimo [EMAIL PROTECTED]
[jira] Assigned: (JCR-395) Using transactions leads to memory leak
[ http://issues.apache.org/jira/browse/JCR-395?page=all ]
Tobias Bocanegra reassigned JCR-395:
Assign To: Tobias Bocanegra
Using transactions leads to memory leak
---
Key: JCR-395
URL: http://issues.apache.org/jira/browse/JCR-395
Project: Jackrabbit
Type: Bug
Components: transactions
Reporter: Przemo Pakulski
Assignee: Tobias Bocanegra
There is global static map in XASessionImpl class which stores all Xids and
TransactionContexts
/**
* Global transactions
*/
private static final Map txGlobal = new HashMap();
It looks like this map is never cleared, even after end of transaction. It
leads to memory leak because TransactionContexts and all nested objects
(including XASessionImpl) are still referenced and couldn't be freed.
Proposed solution : Is it posssible to add just single line which will remove
TransactionContext from static map at the end of transaction ?
if (flags == TMSUCCESS || flags == TMFAIL) {
associate(null);
-- txGlobal.remove(xid);
} else if (flags == TMSUSPEND) {
associate(null);
} else {
throw new XAException(XAException.XAER_INVAL);
}
If this is not acceptable, then we have to unreference TransactionContext in
another way.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (JCR-395) Using transactions leads to memory leak
[ http://issues.apache.org/jira/browse/JCR-395?page=all ]
Tobias Bocanegra closed JCR-395:
Using transactions leads to memory leak
---
Key: JCR-395
URL: http://issues.apache.org/jira/browse/JCR-395
Project: Jackrabbit
Type: Bug
Components: transactions
Reporter: Przemo Pakulski
Assignee: Tobias Bocanegra
Fix For: 1.1
There is global static map in XASessionImpl class which stores all Xids and
TransactionContexts
/**
* Global transactions
*/
private static final Map txGlobal = new HashMap();
It looks like this map is never cleared, even after end of transaction. It
leads to memory leak because TransactionContexts and all nested objects
(including XASessionImpl) are still referenced and couldn't be freed.
Proposed solution : Is it posssible to add just single line which will remove
TransactionContext from static map at the end of transaction ?
if (flags == TMSUCCESS || flags == TMFAIL) {
associate(null);
-- txGlobal.remove(xid);
} else if (flags == TMSUSPEND) {
associate(null);
} else {
throw new XAException(XAException.XAER_INVAL);
}
If this is not acceptable, then we have to unreference TransactionContext in
another way.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (JCR-395) Using transactions leads to memory leak
[ http://issues.apache.org/jira/browse/JCR-395?page=all ]
Tobias Bocanegra resolved JCR-395:
--
Fix Version: 1.1
Resolution: Fixed
fixed.
New Revision: 393452
Using transactions leads to memory leak
---
Key: JCR-395
URL: http://issues.apache.org/jira/browse/JCR-395
Project: Jackrabbit
Type: Bug
Components: transactions
Reporter: Przemo Pakulski
Assignee: Tobias Bocanegra
Fix For: 1.1
There is global static map in XASessionImpl class which stores all Xids and
TransactionContexts
/**
* Global transactions
*/
private static final Map txGlobal = new HashMap();
It looks like this map is never cleared, even after end of transaction. It
leads to memory leak because TransactionContexts and all nested objects
(including XASessionImpl) are still referenced and couldn't be freed.
Proposed solution : Is it posssible to add just single line which will remove
TransactionContext from static map at the end of transaction ?
if (flags == TMSUCCESS || flags == TMFAIL) {
associate(null);
-- txGlobal.remove(xid);
} else if (flags == TMSUSPEND) {
associate(null);
} else {
throw new XAException(XAException.XAER_INVAL);
}
If this is not acceptable, then we have to unreference TransactionContext in
another way.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Erstellt: (JCR-396) RMI published Repository using the jcr-rmi library gets lots over time
RMI published Repository using the jcr-rmi library gets lots over time -- Key: JCR-396 URL: http://issues.apache.org/jira/browse/JCR-396 Project: Jackrabbit Type: Bug Components: rmi Versions: 1.0 Environment: Jackrabbit Rev. 393410 WebApp Reporter: Felix Meschberger Assigned to: Felix Meschberger Fix For: 1.1 The jcr-server/webapp project contains a servlet - RepositoryStartupServlet - which may be used in a web app to start a repository and optionally register the repository with JNDI and RMI. To register the repository with JNDI, the jcr-rmi library is used to create a Remote repository instance, which is registered with the RMI registry. Inside the RMI implementation mechanisms based on stub classes created by the RMI compiler are created to make the remote repository available remotely. This includes creating a object table to map remote references to local objects. This table stores references to the local object as weak references to support distributed garbage collection. Over time, it may now be that this remote repository instance is actually collected and the object table cannot access it anymore thus preventing the repository from being accessed remotely. To prevent this from happening, the RepositoryStartupServlet must keep a strong reference to the remote repository and drop this reference when the servlet is destroyed and the repository unregistered. *NOTE:* This is an issue to all long running applications which publish repository instances over RMI using the jcr-rmi library. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (JCR-397) Webdav Library: MultiStatusResponse calls DavResource#getProperties() in case of PROPFIND by property.
Webdav Library: MultiStatusResponse calls DavResource#getProperties() in case of PROPFIND by property. -- Key: JCR-397 URL: http://issues.apache.org/jira/browse/JCR-397 Project: Jackrabbit Type: Improvement Components: webdav Versions: 1.0 Reporter: angela Priority: Minor The MultiStatusResponse calls DavResource.getProperties() even if only a subset of the properties was requested by PROPFIND. Since DavResource provides getProperty(DavPropertyName), the MultiStatusResponse could could be improved. Note: The current implementation(s) of the DavResource build the complete property set even if only a single property is accessed. This should be reviewed as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Aktualisiert: (JCR-396) RMI published Repository using the jcr-rmi library gets lost over time
[ http://issues.apache.org/jira/browse/JCR-396?page=all ] Felix Meschberger updated JCR-396: -- Summary: RMI published Repository using the jcr-rmi library gets lost over time (was: RMI published Repository using the jcr-rmi library gets lots over time) RMI published Repository using the jcr-rmi library gets lost over time -- Key: JCR-396 URL: http://issues.apache.org/jira/browse/JCR-396 Project: Jackrabbit Type: Bug Components: rmi Versions: 1.0 Environment: Jackrabbit Rev. 393410 WebApp Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: 1.1 Attachments: RepositoryStartupServlet_patch_fm_20060412.diff The jcr-server/webapp project contains a servlet - RepositoryStartupServlet - which may be used in a web app to start a repository and optionally register the repository with JNDI and RMI. To register the repository with JNDI, the jcr-rmi library is used to create a Remote repository instance, which is registered with the RMI registry. Inside the RMI implementation mechanisms based on stub classes created by the RMI compiler are created to make the remote repository available remotely. This includes creating a object table to map remote references to local objects. This table stores references to the local object as weak references to support distributed garbage collection. Over time, it may now be that this remote repository instance is actually collected and the object table cannot access it anymore thus preventing the repository from being accessed remotely. To prevent this from happening, the RepositoryStartupServlet must keep a strong reference to the remote repository and drop this reference when the servlet is destroyed and the repository unregistered. *NOTE:* This is an issue to all long running applications which publish repository instances over RMI using the jcr-rmi library. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Erledigt: (JCR-396) RMI published Repository using the jcr-rmi library gets lost over time
[ http://issues.apache.org/jira/browse/JCR-396?page=all ] Felix Meschberger resolved JCR-396: --- Resolution: Fixed Fixed applying the patch in Rev. 393456 RMI published Repository using the jcr-rmi library gets lost over time -- Key: JCR-396 URL: http://issues.apache.org/jira/browse/JCR-396 Project: Jackrabbit Type: Bug Components: rmi Versions: 1.0 Environment: Jackrabbit Rev. 393410 WebApp Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: 1.1 Attachments: RepositoryStartupServlet_patch_fm_20060412.diff The jcr-server/webapp project contains a servlet - RepositoryStartupServlet - which may be used in a web app to start a repository and optionally register the repository with JNDI and RMI. To register the repository with JNDI, the jcr-rmi library is used to create a Remote repository instance, which is registered with the RMI registry. Inside the RMI implementation mechanisms based on stub classes created by the RMI compiler are created to make the remote repository available remotely. This includes creating a object table to map remote references to local objects. This table stores references to the local object as weak references to support distributed garbage collection. Over time, it may now be that this remote repository instance is actually collected and the object table cannot access it anymore thus preventing the repository from being accessed remotely. To prevent this from happening, the RepositoryStartupServlet must keep a strong reference to the remote repository and drop this reference when the servlet is destroyed and the repository unregistered. *NOTE:* This is an issue to all long running applications which publish repository instances over RMI using the jcr-rmi library. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: my custom access manager
On Wed, 2006-04-12 at 16:59 +0200, Paco Avila wrote: El mié, 12-04-2006 a las 13:55 +0200, Torgeir Veimo escribió: On Wed, 2006-04-12 at 13:35 +0200, Paco Avila wrote: I am developing my custom AccessManager for my jacrabbit based project. User access information is stored in the Nodes. So, I need to access this Node Properties in my custom AccessManager. But I can't because this property access is also checked for security access and will loop until infinite :( How can I access this properties without invoking the AccessManager again? I think it's the general concensus that the best way to implement node stored ACLs in jackrabbit 1.0 is to set up a repository listener at application start-up that logs in with special credentials that your access manager recognises and honours. This listener then keeps a map ACLs, keyed on nodeid, which your access manager uses to get at ACLs when authorising operations on nodes. Can I look at any source with sample code? I don't have any AccessManager implementation like just yet. There was another member of this mailing list who said he'd implemented something along this line. Search the archives for overwrite isGranted; maybe he can share what he's got so far. -- Torgeir Veimo [EMAIL PROTECTED]
[jira] Updated: (JCR-391) WebDAV method invocation trying to create a new resource should fail with 409 (Conflict) if parent resource does not exist
[ http://issues.apache.org/jira/browse/JCR-391?page=all ] Julian Reschke updated JCR-391: --- Attachment: diff.txt OK, as Angela pointed out, this is because Litmus is trying a shallow copy, which currently isn't implemented. Returning 403 in this case is correct. However, there seems to be a very simple workaround which does not only make Litmus happy, but may also help in some real-world cases: only reject the request here if the source resource indeed is a collection (otherwise WebDAV semantics for Depth: 0 and Depth: Infinity are identical). (attached) WebDAV method invocation trying to create a new resource should fail with 409 (Conflict) if parent resource does not exist -- Key: JCR-391 URL: http://issues.apache.org/jira/browse/JCR-391 Project: Jackrabbit Type: Bug Components: webdav Reporter: Julian Reschke Priority: Minor Attachments: diff.txt This is Litmus test case copy_nodestcoll. An attempt is made to COPY an existing resource to a new location, where the parent collection of the resource-to-be-created does not exist. RFC2518 asks for status code 409 (Conflict) instead of 403 (Forbidden) in this case. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (JCR-398) maven2 repository
maven2 repository - Key: JCR-398 URL: http://issues.apache.org/jira/browse/JCR-398 Project: Jackrabbit Type: Improvement Reporter: David J. M. Karlsen Priority: Minor Could somebody care to upload jackrabbit to maven2 repo's at ibiblio? (ideally libraries, javadocs, source, pom's - but at least the lib's) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
