Re: Persisting beans in the content repository
It seems that we have the same target : http://incubator.apache.org/graffito/jcr-mapping/index.html br Christophe On 10/10/06, Nicolas Modrzyk [EMAIL PROTECTED] wrote: Hi All, We've developed something called a bean coder for our application. We've made it open source in case other people would want to use it. With it, you can easily persist some java beans to the repository, and retrieve them at any time. The pretty cool thing is that it plays nicely with the repository searches facility so that you can quickly and easily retrieve some persisted objects from list or maps. A short tutorial is available at the following URL: http://www.openwfe.org/openwfe-jcr-beancoder.html Not sure this is suitable for everyone, especially developers concerned with more complete solutions (like ..?), but this has been working very well so far in our production environment, so just felt like we should contribute back something to the community. Regards, Nicolas John,
Re: Persisting beans in the content repository
Hi Christophe, A few people pointed out graffito already, and I was greatly impressed as I've said in a previous email. We have the same goal indeed and I also like the comments on hibernate which I find very valid. But as written on the page you've been liking to, there has been no release yet. Also surfing the svn repository, no code has been committed since december last year, so I thought the project was not developed anymore and nobody denied my impression on a previous post. Therefore, this was developped. Regards, Niko On Oct 12, 2006, at 5:36 PM, Christophe Lombart wrote: It seems that we have the same target : http://incubator.apache.org/graffito/jcr-mapping/index.html br Christophe On 10/10/06, Nicolas Modrzyk [EMAIL PROTECTED] wrote: Hi All, We've developed something called a bean coder for our application. We've made it open source in case other people would want to use it. With it, you can easily persist some java beans to the repository, and retrieve them at any time. The pretty cool thing is that it plays nicely with the repository searches facility so that you can quickly and easily retrieve some persisted objects from list or maps. A short tutorial is available at the following URL: http://www.openwfe.org/openwfe-jcr-beancoder.html Not sure this is suitable for everyone, especially developers concerned with more complete solutions (like ..?), but this has been working very well so far in our production environment, so just felt like we should contribute back something to the community. Regards, Nicolas John,
Re: Persisting beans in the content repository
Hi Nicolas, Some guys already used this OCM tools. The code seems to be quite stable for us. So, we are almost ready for the first release but there is a plan (at least some discussion) to move this tools inside jackrabbit. See the last Graffito status info on http://wiki.apache.org/incubator/October2006. FYI, upcoming features like cache, reference management, ... are planned for the next release. We are in a transition period that's why there are not a lot of activities on this tools. br Christophe On 10/12/06, Nicolas Modrzyk [EMAIL PROTECTED] wrote: Hi Christophe, A few people pointed out graffito already, and I was greatly impressed as I've said in a previous email. We have the same goal indeed and I also like the comments on hibernate which I find very valid. But as written on the page you've been liking to, there has been no release yet. Also surfing the svn repository, no code has been committed since december last year, so I thought the project was not developed anymore and nobody denied my impression on a previous post. Therefore, this was developped. Regards, Niko On Oct 12, 2006, at 5:36 PM, Christophe Lombart wrote: It seems that we have the same target : http://incubator.apache.org/graffito/jcr-mapping/index.html br Christophe On 10/10/06, Nicolas Modrzyk [EMAIL PROTECTED] wrote: Hi All, We've developed something called a bean coder for our application. We've made it open source in case other people would want to use it. With it, you can easily persist some java beans to the repository, and retrieve them at any time. The pretty cool thing is that it plays nicely with the repository searches facility so that you can quickly and easily retrieve some persisted objects from list or maps. A short tutorial is available at the following URL: http://www.openwfe.org/openwfe-jcr-beancoder.html Not sure this is suitable for everyone, especially developers concerned with more complete solutions (like ..?), but this has been working very well so far in our production environment, so just felt like we should contribute back something to the community. Regards, Nicolas John,
Re: Persisting beans in the content repository
Hi Alexandru, I did not try it, but I read the doc online for jcr-mapping: http://incubator.apache.org/graffito/jcr-mapping/simple-strategies/ introduction-strategies.html Graffito sounded way more complete when you want to write the whole mapping strategy. The bean mapper sounded simpler for basic functional use. We did not have more requirements than map the bean to the repository(with good speed) so that its fields were searchable using the regular query manager. Niko On Oct 12, 2006, at 6:11 PM, Alexandru Popescu wrote: On 10/12/06, Nicolas Modrzyk [EMAIL PROTECTED] wrote: Hi Christophe, A few people pointed out graffito already, and I was greatly impressed as I've said in a previous email. We have the same goal indeed and I also like the comments on hibernate which I find very valid. But as written on the page you've been liking to, there has been no release yet. Also surfing the svn repository, no code has been committed since december last year, so I thought the project was not developed anymore and nobody denied my impression on a previous post. Therefore, this was developped. Nicolas, all the above are valid points. However, the source base haven't changed a lot because it was stable enough (I am using it in production). Also, we (Christophe and myself) haven't done much work on it as both have been quite busy lately and also we were thinking on what new features should we include. I am wondering if you tried it before starting to work on your project ;-) ? ./alex -- .w( the_mindstorm )p. Regards, Niko On Oct 12, 2006, at 5:36 PM, Christophe Lombart wrote: It seems that we have the same target : http://incubator.apache.org/graffito/jcr-mapping/index.html br Christophe On 10/10/06, Nicolas Modrzyk [EMAIL PROTECTED] wrote: Hi All, We've developed something called a bean coder for our application. We've made it open source in case other people would want to use it. With it, you can easily persist some java beans to the repository, and retrieve them at any time. The pretty cool thing is that it plays nicely with the repository searches facility so that you can quickly and easily retrieve some persisted objects from list or maps. A short tutorial is available at the following URL: http://www.openwfe.org/openwfe-jcr-beancoder.html Not sure this is suitable for everyone, especially developers concerned with more complete solutions (like ..?), but this has been working very well so far in our production environment, so just felt like we should contribute back something to the community. Regards, Nicolas John,
Re: Commented: (JCR-352) Upgrade to Lucene 2.0
Chen Shaopeng (JIRA jira at apache.org writes: When will Jackrabbit upgrade to Lucene 2.0? I just looked at the JCR 1.1 source code in Subversion, and it is still dependent on Lucene 1.4.3, invoking deprecated methods that have been removed from Lucene 2.0. Thanks a lot. I am one of those who is waiting deperately for jackrabbit moving to Lucene 1.9x or 2.0 We use flat class loader for our jboss for some reason. My app uses Lucene 1.9.1 and jackrabbit repository uses 1.4.3, and hence both can not exist in same server. Thanks, EKnath
Re: Persisting beans in the content repository
FYI, this is not yet documented but you can use inheritance, interface and use proxies to performance reasons. There are also other possibilities to increase performances. The ocm tools can be also to customized to map simple beans and collection in general. On 10/12/06, Nicolas Modrzyk [EMAIL PROTECTED] wrote: Hi Alexandru, I did not try it, but I read the doc online for jcr-mapping: http://incubator.apache.org/graffito/jcr-mapping/simple-strategies/ introduction-strategies.html Graffito sounded way more complete when you want to write the whole mapping strategy. The bean mapper sounded simpler for basic functional use. We did not have more requirements than map the bean to the repository(with good speed) so that its fields were searchable using the regular query manager. Niko On Oct 12, 2006, at 6:11 PM, Alexandru Popescu wrote: On 10/12/06, Nicolas Modrzyk [EMAIL PROTECTED] wrote: Hi Christophe, A few people pointed out graffito already, and I was greatly impressed as I've said in a previous email. We have the same goal indeed and I also like the comments on hibernate which I find very valid. But as written on the page you've been liking to, there has been no release yet. Also surfing the svn repository, no code has been committed since december last year, so I thought the project was not developed anymore and nobody denied my impression on a previous post. Therefore, this was developped. Nicolas, all the above are valid points. However, the source base haven't changed a lot because it was stable enough (I am using it in production). Also, we (Christophe and myself) haven't done much work on it as both have been quite busy lately and also we were thinking on what new features should we include. I am wondering if you tried it before starting to work on your project ;-) ? ./alex -- .w( the_mindstorm )p. Regards, Niko On Oct 12, 2006, at 5:36 PM, Christophe Lombart wrote: It seems that we have the same target : http://incubator.apache.org/graffito/jcr-mapping/index.html br Christophe On 10/10/06, Nicolas Modrzyk [EMAIL PROTECTED] wrote: Hi All, We've developed something called a bean coder for our application. We've made it open source in case other people would want to use it. With it, you can easily persist some java beans to the repository, and retrieve them at any time. The pretty cool thing is that it plays nicely with the repository searches facility so that you can quickly and easily retrieve some persisted objects from list or maps. A short tutorial is available at the following URL: http://www.openwfe.org/openwfe-jcr-beancoder.html Not sure this is suitable for everyone, especially developers concerned with more complete solutions (like ..?), but this has been working very well so far in our production environment, so just felt like we should contribute back something to the community. Regards, Nicolas John, -- Best regards, Christophe
Re: Pulling binary data from a property
hi shane,
On 10/11/06, Shane Preater [EMAIL PROTECTED] wrote:
Hi Stefan,
Thanks for the help. I will put further questions to the user list. Sorry
about that.
I am using the RMI implementation to aquire a repository instance so this
maybe my problem.
The repository is acquired through JNDI and then I simply acquire the
correct node using session.getRootNode(); then node.getNode(myNode);
Hopefully this will help narrow the problem down.
this is probably a bug in the RMI stream handling code. please
create a jira issue and include all relevant information.
thanks
stefan
Shane.
On 11/10/06, Stefan Guggisberg [EMAIL PROTECTED] wrote:
hi shane,
On 10/11/06, Shane Preater [EMAIL PROTECTED] wrote:
Hi,
I have a property on a node called 'blobData' this property has been
loaded
using the following snippet:
ValueFactory factory = session.getValueFactory();
Value value = factory.createValue(new ByteArrayInputStream(data));
node.setProperty(propertyName, value);
Then obviously further on a call to session.save(); is used to persist
this.
I am now trying to get this binary information back from the property
using:
InputStream inputStream = node.getProperty(property)
.getStream();
int readInt = 0;
while ((readInt = inputStream.read()) = 0) {
outputStream.write(readInt);
}
return outputStream.toByteArray();
However this always returns an empty byte array as the first call to
inputStream.read() returns -1 indicating the end of the stream.
Could someone point me in the direction of my error.
your code looks fine so far. if you are directly accessing a local
jackrabbit
instance i guess the error must be in that part of the code that you
didn't
provide. if you're accessing a remote jackrabbit instance through RMI
there could be an issue wrt stream handling in the RMI implementation.
in any case it would be good if you could provide a complete code sample.
btw: the users list would be more appropriate for such questions.
cheers
stefan
Thanks,
Shane.
Re: Alfresco + Jackrabbit
I must admit that I have not yet done so. I am currently mostly lurking on this list. I have an idea for an IT project using a content repository, but I have not had the time/resources to pursue it. Nicolas wrote: This is an excellent idea. Did you try using Alfresco's one? Is it working well? On 10/11/06, Robert r. Sanders [EMAIL PROTECTED] wrote: Actually one thing that I find really interesting about Alfresco - in case anyone wants to implement it as an add-on to Jackrabbit - is the CIFS layer which supposedly allows good access to the server (as a document server) from Windows clients. Having tried mapping a WeDAV location as a network drive I can say that it really doesn't work in a usable fashion. I would imagine that using the jCIFS library it would be possible to write something similar for a more generic JSR-170 provider... -- Robert r. Sanders Chief Technologist iPOV (334) 821-5412 www.ipov.net
Re: Alfresco + Jackrabbit
Hi Robert, Actually one thing that I find really interesting about Alfresco - in case anyone wants to implement it as an add-on to Jackrabbit - is the CIFS layer which supposedly allows good access to the server (as a document server) from Windows clients. I would imagine that using the jCIFS library it would be possible to write something similar for a more generic JSR-170 provider... I think this would be a good idea too, as a matter of fact we already looked into the feasibility of something like that and it seems to work just fine. Some random access performance drawbacks if we want to keep it strictly bound to the JCR API. jCIFS though is a CIFS client, right? At least I have not found a CIFS server other than Starlasoft's / Alfresco's? Am I looking in the wrong place? Having tried mapping a WeDAV location as a network drive I can say that it really doesn't work in a usable fashion. Really? So far I experienced a generally suboptimal perfomance but it works just as well as CIFS for me, both on MacOSX and Windows. What issues did you encounter? regards, david
Re: Alfresco + Jackrabbit
I think this would be a good idea too, as a matter of fact we already looked into the feasibility of something like that and it seems to work just fine. Some random access performance drawbacks if we want to keep it strictly bound to the JCR API. jCIFS though is a CIFS client, right? At least I have not found a CIFS server other than Starlasoft's / Alfresco's? Am I looking in the wrong place? Duh, I believe I had the two mixed up. I don't know why; overly optimistic thinking I guess. Having tried mapping a WeDAV location as a network drive I can say that it really doesn't work in a usable fashion. Really? So far I experienced a generally suboptimal perfomance but it works just as well as CIFS for me, both on MacOSX and Windows. What issues did you encounter? We tried Win2k client machines connecting to a Subversion server set to auto-version. Opening a web folder worked ok; but trying to map that to a drive letter seemed to result in all sorts of issues, one of which I believe was an infinite loop in the login prompt. Its been over a year, so the details have gotten kind of fuzzy. Anyway, we were trying to use non-WebDAV aware programs (e.g. Flash, Wave file editors, etc...) and this also seemed to often result in zero-byte files being stored on the server. Maybe a different combination on the server-side would have fixed the issue, I can't say. regards, david
[ANNOUNCE] Apache Jackrabbit 1.1 released
The Apache Jackrabbit community is pleased to announce the release of Apache Jackrabbit version 1.1. The release is available for download at: http://jackrabbit.apache.org/downloads.cgi Release Notes -- Apache Jackrabbit -- Version 1.1 Introduction The Apache Jackrabbit project is an effort to build and maintain an open source implementation of the Content Repository for Java Technology API (JCR) specified in the Java Specification Request 170 (JSR-170). The project also produces a various tools and components related to the JCR API. Apache Jackrabbit 1.1 is an incremental release that fixes a number of issues and introduces some new features. The most notable changes in this release include the removal of the Xerces dependency and a set of performance improvements. See the included change history for details. See the Apache Jackrabbit website at http://jackrabbit.apache.org/ for more information. Release Contents The main contents of this release are the Apache Jackrabbit core content repository implementation and the related general-purpose JCR utilities: jackrabbit-core-1.1-src.jar jackrabbit-core-1.1.jar jackrabbit-jcr-commons-1.1.jar This release contains also additional components that offer extra functionality for use with either Apache Jackrabbit core or any JCR compliant content repository. These modules should be considered beta quality: * RMI network layer for the JCR API. jackrabbit-jcr-rmi-1.1-src.jar jackrabbit-jcr-rmi-1.1.jar * Deployable Jackrabbit installation with WebDAV support for JCR. jackrabbit-jcr-server-1.1-src.jar jackrabbit-jcr-webdav-1.1.jar jackrabbit-jcr-client-1.1.jar jackrabbit-jcr-server-1.1.jar jackrabbit-server-1.1.war * J2EE Connector Architecture (JCA) resource adapter for Jackrabbit. jackrabbit-jca-1.1-src.jar jackrabbit-jca-1.1.rar * Text indexing filters for Jackrabbit. Includes example filters for Adobe PDF and MS Excel, PowerPoint, and Word. jackrabbit-index-filters-1.1-src.jar jackrabbit-index-filters-1.1.jar All components are released as a source jar file and one or more compiled binary files. All files contain a README.txt file with more information. Note that external runtime dependencies are only included for the war and rar archives. Other dependencies can be downloaded either manually or automatically using the Maven build system. Each release file is accompanied by SHA1 and MD5 checksums and a PGP signature. The public key used for the signatures can be found in the KEYS file located in the parent directory. Upgrading from 1.0 -- Apache Jackrabbit 1.1 is fully compatible with the 1.0 release. An Apache Jackrabbit 1.0 installation can be upgraded by replacing the relevant jar files with the new versions. No changes to repository contents are needed. Known Issues The known issues in this release are listed below: [JCR-586] Removing a mixin that adds a same-name-sibling child node ... [JCR-578] QueryParser.parse(...) parses wrong the [EMAIL PROTECTED] and ... [JCR-575] unicode escapes in files generated by JJTree [JCR-574] MsExcelTextFilter throws Exception. Repository is not startable [JCR-568] incorrect jcr:uuid on frozen subnode [JCR-566] Versioning with restore and transactions [JCR-564] Remove geronimo JTA as a runtime dependency [JCR-563] encode/decode [JCR-562] 'OR' in XPath query badly interpreted [JCR-550] ObservationManagerFactory) - OutOfMemoryError when re-indexing ... [JCR-546] Deadlock during checkin [JCR-544] JCR-Server: Workspace.restore not mapped correctly [JCR-538] failing Node.checkin() or Node.checkout() might leave ... [JCR-537] Failure to remove a versionable node [JCR-529] New versions added after a restore have bad version name [JCR-522] XPath parser too tolerant [JCR-517] Reserved status of namespace jcr not enforced. [JCR-449] inconsistency in internal version items during commits [JCR-441] Session logout doesn't release locks acquired using addLockToken [JCR-435] Node.update() does not work correct for SNS [JCR-406] If header evaluation compliance provlems [JCR-392] Accessing element by number does not work [JCR-385] ClassCastExeption when executing union queries [JCR-320] BinaryValue equals fails for two objects with two different ... [JCR-43] Restore on node creates same-name-sibling of OPV-Version child ... [JCR-18] Multithreading issue with versioning See the issue tracker at http://issues.apache.org/jira/browse/JCR for more details. Change History -- Changes since 1.0.1: New features [JCR-561] Add support to provide custom classloader for class ... [JCR-521] Add a method public boolean hasNodeType(String name) in ... [JCR-409] Safe namespace registration [JCR-313] Allow to configure DB persistence managers through JDNI [JCR-248] create configuration on InputStream Improvements [JCR-565] Refactor ObservationManagerFactory
[jira] Updated: (JCR-562) 'OR' in XPath query badly interpreted
[ http://issues.apache.org/jira/browse/JCR-562?page=all ]
Przemo Pakulski updated JCR-562:
Attachment: JCR-562.patch
The attached patch contains fix and following test case :
public void testLogicalExpression() throws Exception {
Node foo = testRootNode.addNode(foo);
foo.setProperty(a, 1);
foo.setProperty(b, 2);
foo.setProperty(c, 3);
Node bar = testRootNode.addNode(bar);
bar.setProperty(a, 0);
bar.setProperty(b, 2);
bar.setProperty(c, 0);
Node bla = testRootNode.addNode(bla);
bla.setProperty(a, 1);
bla.setProperty(b, 0);
bla.setProperty(c, 3);
testRootNode.save();
String sql = SELECT * FROM nt:unstructured WHERE a=1 and b=2
or c=3;
Query q =
superuser.getWorkspace().getQueryManager().createQuery(sql, Query.SQL);
QueryResult result = q.execute();
checkResult(result, new Node[]{foo, bla});
String xpath = //[EMAIL PROTECTED] and @b=2 or @c=3] ;
q =
superuser.getWorkspace().getQueryManager().createQuery(xpath, Query.XPATH);
result = q.execute();
checkResult(result, new Node[]{foo, bla});
}
'OR' in XPath query badly interpreted
-
Key: JCR-562
URL: http://issues.apache.org/jira/browse/JCR-562
Project: Jackrabbit
Issue Type: Bug
Components: core
Affects Versions: 1.0.1
Reporter: Szymon Kuzniak
Attachments: JCR-562.patch, tree.JPG
executing query: //[EMAIL PROTECTED] and @b=2 or @c=3] leads to creating
wrong query tree. The builded tree looks like for query: //[EMAIL PROTECTED]
and @b=2 and @c=3](see attachement). using brackets resolves the problem, but
without brackets output query is different from input query. When AND and OR
are switched(so the OR is in first palce - //[EMAIL PROTECTED] or @b=2 and
@c=3]) everything is ok.
--
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-591) XPath position function does not work
XPath position function does not work
-
Key: JCR-591
URL: http://issues.apache.org/jira/browse/JCR-591
Project: Jackrabbit
Issue Type: Bug
Components: query
Affects Versions: 1.0.1
Reporter: Przemo Pakulski
Priority: Minor
Expression with position function are supported in XPath but does not work.
All rows are returned when equality operator is used.
public void testXPathPosition() throws Exception {
Node foo = testRootNode.addNode(name);
Node bar = testRootNode.addNode(name);
testRootNode.save();
String xpath = //name[position()=2];
Query q =
superuser.getWorkspace().getQueryManager().createQuery(xpath, Query.XPATH);
QueryResult result = q.execute();
checkResult(result, 1);
checkResult(result, new Node[]{bar});
}
--
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: Persisting beans in the content repository
Christophe, Given the thing we like in our tool, is the fact that no configuration is needed, you just need a reference to the node you want to store the bean, could that be fitted in Graffito by any means ? Also, what Timur said on the thread on the server side: http://www.theserverside.com/news/thread.tss?thread_id=42547#219899 He had the api to also do the reverse. Meaning, he could create a bean from some data available in the repository. I could imagine use-cases where this could be useful. Would this be possible within Graffito ? Niko but there is a plan (at least some discussion) to move this tools inside jackrabbit. would that be committed in the contrib section ? would there be fo
JCR Apps and Exchangable
Hi All, I just comparing several of JCR tech and use it in my company for case study 1. Liferay - www.meruvian.com 2. Alfresco -- www.meruvian.com/mspace 3. Magnolia -- www.intercitra.com I just finding a way, which one is the real JCR, because in my opinion any JCR apps can move the data from one JCR to another JCR, or merging all the JCR apps to share the same JCR repo. my problem 1. I just try to save my Magnolia data, and make another CMS that can read Magnolia data, because I find that Magnolia dont have feature to show the content in sort by date which for me it is a basic feature for CMS, and to make a module on top of Magnolia, I still cannot get the guide. 2. alfresco, I want to implement several digital library based on Alfresco, but I see that to develop a module i need to learn to develop aspect, need to learn more, but in the spirit of JCR, I want to develop a simple JCR apps using Jackrabbit, and try to move. I find difficulty, because my Jackrabbit View is still cannot work in alfresco 's JCR my question is, how to make test that my apps can be moveable from one JCR ot another JCR apps, it is possible i got that Jackrabbit have XML feature, to import and export, but anyone have try another apps? it is possible?
Re: JCR Apps and Exchangable
Hi Frans, Your question is a bit like asking how to I move my application from postgresql to mysql given that both postgres and mysql are using SQL as a language to access the data. You even have tools to import/export data in both of them. As a short answer, you can't. Most of the cms have custom nodes that can be read but surely cannot be shown or handled properly by other CMS. 1. I just try to save my Magnolia data, and make another CMS that can read Magnolia data, because I find that Magnolia dont have feature to show the content in sort by date which for me it is a basic feature for CMS, and to make a module on top of Magnolia, I still cannot get the guide. I am crossposting to the user of magnolia. To create a module for it, you basically copy and paste an other module and start creating your own. The guys are busy with a industrial production-ready 3.0 version, so the documentation is still a bit behind. I don't understand your problem on sorting by dates, this is just a simple query on the jcr, and any of the CMS can do that (magnolia included). Hope I have, to some extend, answered your question. Do not hesitate to ask more on the project's user list. Regards, Nicolas,
