Re: How do I specify the graffito jcr mapping for classes that extend ArrayList
If you have time, I will add add a new unit test with an ArrayList (hope for
this wk).
br,
Christophe
On 5/31/07, rajab57 [EMAIL PROTECTED] wrote:
Hi,
Thanks for the reply.
I will refer to the jackrabbit project in future. I did not realize that
the
process has happened.
I looked at the example for HashMap. And I have implemented the case of
ArrayList, Set etc.
In this scenario this ElementsList extends ArrayList. And I was not sure
how
I can specify that mapping.
Thanks again,
Raji
Christophe Lombart wrote:
The jcr mapping tools has been moved into the Jackrabbit project (
http://jackrabbit.apache.org). I advise you to use the Jackrabbit
mailing
list.
FYI, ArrayList are supportedd by default.
If you want to support your own collection/map class :
1/ your collection/map class have to implement the ManagableCollection
interface.
2/ You have to specify the collection class name in the mapping file.
We have a unit test with an specific HashMap. That's exactly the same
for
collection like ArrayList, ...
* See the class HashMapElement which implement the interface
ManageableCollection
* See the unit test HashMapTest.
* Check in the mapping file jcrmapping.xml the mapping descriptor for
the
class o.a.j.ocm.testmodel.hashmap.Main which contains a descriptor based
on
the HashMapElement class.
HTH
Christophe
On 5/31/07, rajab57 [EMAIL PROTECTED] wrote:
Example
import java.util.ArrayList;
import java.util.ListIterator;
public class MainClass {
private ElementsList elements;
}
public class ElementsList extends ArrayListElements {
private static final long serialVersionUID = 1L;
}
public class Element {
private String name ;
private String id ;
}
--
View this message in context:
http://www.nabble.com/How-do-I-specify-the-graffito-jcr-mapping-for-classes-that-extend-ArrayList-tf3848661.html#a10901203
Sent from the Graffito - Dev mailing list archive at Nabble.com.
--
View this message in context:
http://www.nabble.com/How-do-I-specify-the-graffito-jcr-mapping-for-classes-that-extend-ArrayList-tf3848661.html#a10901887
Sent from the Graffito - Dev mailing list archive at Nabble.com.
Re: [VOTE] Retire the Graffito project
+1 On 6/1/07, Jukka Zitting [EMAIL PROTECTED] wrote: Hi, As discussed before, now that the JCR mapping component has been moved to the Jackrabbit project I propose to retire the Graffito project from the Apache Incubator. The Graffito codebase would be moved to dormant state from where it can still be resurrected if renewed interest appears. So, please vote on retiring the Graffito project. The result of this vote, if positive, will be used as a recommendation to the Incubator PMC to formally retire Graffito. [ ] +1, retire the Graffito project [ ] -1, do not retire the Graffito project BR, Jukka Zitting
Re: [RESULT] [VOTE] Move JCR Mapping to Jackrabbit
I have some stuff to commit (probably at the end of the day). Can we wait until tomorrow ? If not, I will make changes in the new svn repo. Thanks, Christophe On 4/23/07, Jukka Zitting [EMAIL PROTECTED] wrote: Hi, On 4/17/07, Jukka Zitting [EMAIL PROTECTED] wrote: As already discussed, I'd like to formally propose moving the JCR Mapping codebase and related pieces of code (http://svn.apache.org/repos/asf/incubator/graffito/trunk/jcr/) to the Apache Jackrabbit project. Please vote on whether to move the codebase. The vote is open for the next 72 hours, with binding votes from the Graffito PPMC. The vote passes with five binding +1 votes and three non-binding +1 votes. As the parallel vote on the Jackrabbit mailing list also passed, I will now proceed to move the codebase. The binding votes were: +1 Sandro Böhme +1 Christophe Lombart +1 Oliver Kiessler +1 Alexandru Popescu +1 Jukka Zitting The non-binding votes were: +1 Ruchi Goel +1 Felix Meschberger +1 Carsten Ziegeler BR, Jukka Zitting
Re: [RESULT] [VOTE] Move JCR Mapping to Jackrabbit
Ok probably for tomorrow in the morning. Thanks, Christophe On 4/23/07, Jukka Zitting [EMAIL PROTECTED] wrote: Hi, On 4/23/07, Christophe Lombart [EMAIL PROTECTED] wrote: I have some stuff to commit (probably at the end of the day). Can we wait until tomorrow ? If not, I will make changes in the new svn repo. No problem, there's no rush to get this done. Just ping me when you're ready. Meanwhile I'll try to figure out if we can move the open JCR Mapping issues over to the Jackrabbit project in Jira. BR, Jukka Zitting
Re: [RESULT] [VOTE] Move JCR Mapping to Jackrabbit
tha's ok now. We can move the code. Thanks Christophe On 4/23/07, Christophe Lombart [EMAIL PROTECTED] wrote: Ok probably for tomorrow in the morning. Thanks, Christophe On 4/23/07, Jukka Zitting [EMAIL PROTECTED] wrote: Hi, On 4/23/07, Christophe Lombart [EMAIL PROTECTED] wrote: I have some stuff to commit (probably at the end of the day). Can we wait until tomorrow ? If not, I will make changes in the new svn repo. No problem, there's no rush to get this done. Just ping me when you're ready. Meanwhile I'll try to figure out if we can move the open JCR Mapping issues over to the Jackrabbit project in Jira. BR, Jukka Zitting
[jira] Assigned: (GRFT-131) ResidualProperties Converter uses wrong AtomicType Converter on update
[ https://issues.apache.org/jira/browse/GRFT-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart reassigned GRFT-131: --- Assignee: Christophe Lombart ResidualProperties Converter uses wrong AtomicType Converter on update -- Key: GRFT-131 URL: https://issues.apache.org/jira/browse/GRFT-131 Project: Graffito Issue Type: Bug Components: JCR-Mapping Affects Versions: 1.0-a1-dev Reporter: Felix Meschberger Assigned To: Christophe Lombart Fix For: 1.0-a1-dev Attachments: GRFT-131.diff When writing back data, the ResidualPropertiesCollectionConverterImpl.internalSetProperties method looks at the type of the Java object to find the atomic type converter instead of getting the converter according to the collection descriptor. This may lead to NullPointerExceptions in case the concrete type is an extension (or implementation) of the declared type. I am currently working on a patch to attache to this bug. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GRFT-106) Avoid INFINITE RECURSION when Object Model has cycles.
[ https://issues.apache.org/jira/browse/GRFT-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart resolved GRFT-106. - Resolution: Fixed Fix Version/s: ocm-1.0 Solve by using an object cache. This is not yet a complete cache system but this small cache is used per persistenceManager and only for retrieve requests. It allows to perform circular lookups (as by crossreferenced objects) that would result in non-terminating loops without such a cache. Later I would like to implement a complete object cache support. Something like in Hibernate or OJB. There is a good description here : http://db.apache.org/ojb/docu/guides/objectcache.html. I think we have similar needs but we have to define a proposal for this kind of feature with the most useful use cases. Avoid INFINITE RECURSION when Object Model has cycles. -- Key: GRFT-106 URL: https://issues.apache.org/jira/browse/GRFT-106 Project: Graffito Issue Type: Improvement Components: JCR-Mapping Reporter: Dan Connelly Assigned To: Christophe Lombart Priority: Critical Fix For: ocm-1.0 The default ObjectConverterImpl is restricted to acyclic graphs in the object model. Many Java object models are NOT acyclic. For instance, I am on your Friends list. Yoar are on my Friends list. Java encourages such structures. Almost any large object model in Java will have hidden cycles. Saving an Object Model that contains cycles using Graffito causes an infinite recursion. Clearly, it is important to maintain a 1-to-1 correspondence between Nodes and Objects to prevent this. In the absence of Multiple Parent Nodes, it will be necessary to use REFERENCE or UNDEFINED Items in place of the 2nd (or greater) Node representing a given Object. My preference si that the default ObjectConverterImpl should support REFERENCE.,Failing this, use of UNDEFINED also solves this problem and would acceptable (as default). Whether or not REFERENCE is used, both insertion and retrieval must provide a reasonable result. A custom ojbect converter should be available to switch UNDEFINED to REFERENCE, or vice versa. Also, it is probably best to keep the targeted, well-defined Nodes close to the Root Node.This implies that the default ObjectConverterImpl should implement a Breadth-First, rather than a Depth-First, traversal of the Object Model on both insertion and retrieval. Again, if the default is Depth-First, a custom object converter should be available that implements Breadth-First. Admittedly, support for (2 representations) X (2 traversals) implies a drastic refactoring and/or rewriting of the ObjectConverterImpl class. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Move JCR Mapping to Jackrabbit
of course +1. Thanks for your help Jukka. Christophe On 4/17/07, Jukka Zitting [EMAIL PROTECTED] wrote: Hi, As already discussed, I'd like to formally propose moving the JCR Mapping codebase and related pieces of code (http://svn.apache.org/repos/asf/incubator/graffito/trunk/jcr/) to the Apache Jackrabbit project. Please vote on whether to move the codebase. The vote is open for the next 72 hours, with binding votes from the Graffito PPMC. I will call a parallel vote on the Jackrabbit PMC to accept the codebase. The move will happen only if both votes pass. [ ] +1 Move JCR Mapping to Jackrabbit [ ] -1 Do not move the component because ... Here's my +1 BR, Jukka Zitting
[jira] Assigned: (GRFT-106) Avoid INFINITE RECURSION when Object Model has cycles.
[ https://issues.apache.org/jira/browse/GRFT-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart reassigned GRFT-106: --- Assignee: Christophe Lombart Avoid INFINITE RECURSION when Object Model has cycles. -- Key: GRFT-106 URL: https://issues.apache.org/jira/browse/GRFT-106 Project: Graffito Issue Type: Improvement Components: JCR-Mapping Reporter: Dan Connelly Assigned To: Christophe Lombart Priority: Critical The default ObjectConverterImpl is restricted to acyclic graphs in the object model. Many Java object models are NOT acyclic. For instance, I am on your Friends list. Yoar are on my Friends list. Java encourages such structures. Almost any large object model in Java will have hidden cycles. Saving an Object Model that contains cycles using Graffito causes an infinite recursion. Clearly, it is important to maintain a 1-to-1 correspondence between Nodes and Objects to prevent this. In the absence of Multiple Parent Nodes, it will be necessary to use REFERENCE or UNDEFINED Items in place of the 2nd (or greater) Node representing a given Object. My preference si that the default ObjectConverterImpl should support REFERENCE.,Failing this, use of UNDEFINED also solves this problem and would acceptable (as default). Whether or not REFERENCE is used, both insertion and retrieval must provide a reasonable result. A custom ojbect converter should be available to switch UNDEFINED to REFERENCE, or vice versa. Also, it is probably best to keep the targeted, well-defined Nodes close to the Root Node.This implies that the default ObjectConverterImpl should implement a Breadth-First, rather than a Depth-First, traversal of the Object Model on both insertion and retrieval. Again, if the default is Depth-First, a custom object converter should be available that implements Breadth-First. Admittedly, support for (2 representations) X (2 traversals) implies a drastic refactoring and/or rewriting of the ObjectConverterImpl class. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GRFT-84) ObjectConverterImpl wrong behavior when manipulating autoCreate and protected properties
[ https://issues.apache.org/jira/browse/GRFT-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart resolved GRFT-84. Resolution: Fixed Fix Version/s: ocm-1.0 From now, the ocm tools is supporting all kind of jcr properties. see the unit test : PersistenceManagerJcrPropertyTest.java ObjectConverterImpl wrong behavior when manipulating autoCreate and protected properties Key: GRFT-84 URL: https://issues.apache.org/jira/browse/GRFT-84 Project: Graffito Issue Type: Bug Components: JCR-Mapping Affects Versions: 1.0-a1-dev Reporter: Alexandru Popescu Assigned To: Christophe Lombart Priority: Critical Fix For: ocm-1.0 1/ autocreated properties When writting a property it ignores the autoCreated properties. But according to JSR-170 the autoCreated properties are writtable, so IMO these should not be ignored. The only requirement related to autoCreated properties is that they should have a default value, but this is required to be provided by the node definition. 2/ protected properties There is no check against the protected properties. According to JSR-170 these can be read, but cannot be write, so an attempt to write such a property should result in an exception. The current implementation relies on the repository to throw this exception, but IMO a better behavior would be not to attempt to write it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GRFT-130) Some classes use JDK 5 autoboxing
[ https://issues.apache.org/jira/browse/GRFT-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart resolved GRFT-130. - Resolution: Fixed Fix Version/s: ocm-1.0 Patch applied. Felix, can you check if it is ok ? Thanks Some classes use JDK 5 autoboxing - Key: GRFT-130 URL: https://issues.apache.org/jira/browse/GRFT-130 Project: Graffito Issue Type: Bug Reporter: Felix Meschberger Fix For: ocm-1.0 Attachments: GRFT-130.diff The AtomicTest and UndefinedTypeConverterImpl classes employ Java 5 autoboxing functionality which is not available on Java 1.4 platform also supported by Jackrabbit and JCR. Additionally, the UndefinedTypeConverterImpl class contains a potential class ClassCasst issue in inthat an Integer object is cast to Long. Attaching a patch, which uses explicit boxing/unboxing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GRFT-129) ResidualProperties Converter may fail
[ https://issues.apache.org/jira/browse/GRFT-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart reassigned GRFT-129: --- Assignee: Christophe Lombart ResidualProperties Converter may fail - Key: GRFT-129 URL: https://issues.apache.org/jira/browse/GRFT-129 Project: Graffito Issue Type: Bug Components: JCR-Mapping Reporter: Felix Meschberger Assigned To: Christophe Lombart Attachments: GRFT-129.diff When storing data, the ResidualPropertiesCollectionConverterImpl class first removes all properties matching the name pattern and then sets these properties. In the case of protected properties like jcr:primaryType this mechanism fails and prevents the properties from being saved. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GRFT-129) ResidualProperties Converter may fail
[ https://issues.apache.org/jira/browse/GRFT-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart resolved GRFT-129. - Resolution: Fixed Patch applied. Felix, can you check if it is ok ? ResidualProperties Converter may fail - Key: GRFT-129 URL: https://issues.apache.org/jira/browse/GRFT-129 Project: Graffito Issue Type: Bug Components: JCR-Mapping Reporter: Felix Meschberger Assigned To: Christophe Lombart Attachments: GRFT-129.diff When storing data, the ResidualPropertiesCollectionConverterImpl class first removes all properties matching the name pattern and then sets these properties. In the case of protected properties like jcr:primaryType this mechanism fails and prevents the properties from being saved. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GRFT-84) ObjectConverterImpl wrong behavior when manipulating autoCreate and protected properties
[ https://issues.apache.org/jira/browse/GRFT-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484225 ] Christophe Lombart commented on GRFT-84: Default values constraints setting are missing in the jcr mapping descriptor. I will modify the field-descriptor class in order to support them. ObjectConverterImpl wrong behavior when manipulating autoCreate and protected properties Key: GRFT-84 URL: https://issues.apache.org/jira/browse/GRFT-84 Project: Graffito Issue Type: Bug Components: JCR-Mapping Affects Versions: 1.0-a1-dev Reporter: Alexandru Popescu Assigned To: Christophe Lombart Priority: Critical 1/ autocreated properties When writting a property it ignores the autoCreated properties. But according to JSR-170 the autoCreated properties are writtable, so IMO these should not be ignored. The only requirement related to autoCreated properties is that they should have a default value, but this is required to be provided by the node definition. 2/ protected properties There is no check against the protected properties. According to JSR-170 these can be read, but cannot be write, so an attempt to write such a property should result in an exception. The current implementation relies on the repository to throw this exception, but IMO a better behavior would be not to attempt to write it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GRFT-128) Add support for default value and constraints
Add support for default value and constraints - Key: GRFT-128 URL: https://issues.apache.org/jira/browse/GRFT-128 Project: Graffito Issue Type: Improvement Components: JCR-Nodemanagement Affects Versions: ocm-1.0 Reporter: Christophe Lombart Fix For: ocm-1.0 the jcr node type management tools should support default value and constraints setting. The mapping descriptor model should be also modify to support them. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: copying and moving node
Any kind of contribution in this are welcome. Christophe On 3/21/07, ruchi goel [EMAIL PROTECTED] wrote: Hi, I have a requirement for copying ad moving node from one location to another. Jackrabbit supports it via Session and workspace impl , but PersistenceManager does not expose it . Has such a requirement already been raised ? Or is this a new requirement and needs contribution ? Thanks, Ruchi
Re: Folder-File relationship in versioning
On 3/9/07, ruchi goel [EMAIL PROTECTED] wrote: Hi, My Folder is non-versionable but Files under the folder are versionable. The test which is in PersistenceManagerJcrNodeTypeTest.java adds file as child of folder .So, you do persistenceManager.insert(folder);* *persistenceManager.save(); How will I do the checkout and checkin separately for file ? I believe , I need to do save and checkin the file independently from folder. yes. See the class PersistenceManagerBasicVersionning for more examples. *//- // Insert a folder (class mapped to jcr:folder) with one file (class mapped to jcr:file) //- Resource resource = new Resource(); resource.setData(new ByteArrayInputStream(this is the content.getBytes())); resource.setLastModified(Calendar.getInstance()); resource.setMimeType(plain/text); File file = new File(); file.setResource(resource); Folder folder = new Folder(); folder.setPath(/folder1); folder.addChild(file); persistenceManager.insert(folder); persistenceManager.save(); * Thanks, Ruchi* *
[jira] Resolved: (GRFT-40) Advanced support for JCR properties and node
[ https://issues.apache.org/jira/browse/GRFT-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart resolved GRFT-40. Resolution: Fixed All subisssues are resolved. Advanced support for JCR properties and node Key: GRFT-40 URL: https://issues.apache.org/jira/browse/GRFT-40 Project: Graffito Issue Type: Task Components: JCR-Mapping Reporter: Christophe Lombart Assigned To: Christophe Lombart Fix For: 1.0-a1-dev - We have to support the following JCR Types : * PropertyType.NAME * PropertyType.PATH * PropertyType.REFERENCE * PropertyType.UNDEFINED - Map UUID and the path into the POJO object - Check if mandatory auto created properties are well managed. More unit test are required. - Support for same-name siblings : the query service should supported it ans we have also to support the method : node.getNodes(nodepattern). We have also to check if the insert, update and delete methods support correctly the same-name sibling. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: property attributes in jcrmapping versus property attributes in custom_nodetypes.xml ?
Hi Ruchi, This is not mandatory to add the jcr property attributes in the jcr mapping. There are used only by another component (see the subproject jcr-nodemanagement) in order to create, from the jcrmapping file, the desired jcr node types . By this way, you have only one file to manage but you have to import them from this tools. Anyway, I will chek where there are used in the persitence manager implementation and change the code if needed. Thanks, Christophe On 3/8/07, ruchi goel [EMAIL PROTECTED] wrote: Hi, I am writing a jcrMapping.xml which will map my java classes to custom node types. My custom_nodetypes.xml already has nodetype with properties which have attributes requiredType=String autoCreated=false mandatory=true onParentVersion=COPY protected=false multiple=true / Then why do I need to add similar attributes in jcrmapping for each property.* Refer in following extract :* * !ATTLIST field-descriptor fieldName CDATA #REQUIRED fieldType CDATA #IMPLIED jcrName CDATA #IMPLIED id (true | false) false path (true | false) false jcrType (String | Date | Long | Double | Boolean | Binary) #IMPLIED jcrAutoCreated (true | false) false jcrMandatory (true | false) false jcrOnParentVersion (COPY | VERSION | INITIALIZE | COMPUTE | IGNORE | ABORT) COPY jcrProtected (true | false) false jcrMultiple (true | false) false * Which one takes the priority ? The one in jcrmapping.xml or the one in custom_nodetypes.xml Thanks, Ruchi
Re: property attributes in jcrmapping versus property attributes in custom_nodetypes.xml ?
On 3/8/07, ruchi goel [EMAIL PROTECTED] wrote: Christophe Lombart wrote: Hi Ruchi, This is not mandatory to add the jcr property attributes in the jcr mapping. There are used only by another component (see the subproject jcr-nodemanagement) in order to create, from the jcrmapping file, the desired jcr node types . By this way, you have only one file to manage but you have to import them from this tools. Thanks. But if I continue with strategy of maintaining both the mapping and nodetypes files, *Which one takes the precedence ? The default ones in jcrmapping.xml or the one which I specified in custom_nodetypes.xml The one which you specify in yhr custom_nodetypes. e.g for a property *jcrMultiple is default to false in mapping file . If I specified multiple=truefor the same node property in nodetypes file , then which one takes precedence ? -Ruchi * * Anyway, I will chek where there are used in the persitence manager implementation and change the code if needed. Thanks, Christophe On 3/8/07, ruchi goel [EMAIL PROTECTED] wrote: Hi, I am writing a jcrMapping.xml which will map my java classes to custom node types. My custom_nodetypes.xml already has nodetype with properties which have attributes requiredType=String autoCreated=false mandatory=true onParentVersion=COPY protected=false multiple=true / Then why do I need to add similar attributes in jcrmapping for each property.* Refer in following extract :* * !ATTLIST field-descriptor fieldName CDATA #REQUIRED fieldType CDATA #IMPLIED jcrName CDATA #IMPLIED id (true | false) false path (true | false) false jcrType (String | Date | Long | Double | Boolean | Binary) #IMPLIED jcrAutoCreated (true | false) false jcrMandatory (true | false) false jcrOnParentVersion (COPY | VERSION | INITIALIZE | COMPUTE | IGNORE | ABORT) COPY jcrProtected (true | false) false jcrMultiple (true | false) false * Which one takes the priority ? The one in jcrmapping.xml or the one in custom_nodetypes.xml Thanks, Ruchi
[jira] Resolved: (GRFT-124) Add support for the Undefine JCR type
[ https://issues.apache.org/jira/browse/GRFT-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart resolved GRFT-124. - Resolution: Fixed Now there is a new converter for undefine jct type see the class : UndefinedTypeConverterImpl. Add support for the Undefine JCR type --- Key: GRFT-124 URL: https://issues.apache.org/jira/browse/GRFT-124 Project: Graffito Issue Type: Sub-task Components: JCR-Mapping Reporter: Christophe Lombart Fix For: 1.0-a1-dev Create another atomic type converter to support the undefine jcr type. * we could map the Undefined jcr type into the Object java type. * In the javax.jcr.Value class, there is no method get this object value. It requires to check the jcr prop type and than use the more appropriate method in javax.jxr.Value. Is it correct ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GRFT-125) Add UUID support
[ https://issues.apache.org/jira/browse/GRFT-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478902 ] Christophe Lombart commented on GRFT-125: - I just committed some changes : 1/ add a new method in the persistence manager : getObjectByUuid(String uuid) 2/ In order to map a bean field into the node uuid, it is possible to add the following field-descriptor in any class-descriptor : field-descriptor fieldName=myUuid uudi=true / notes : path is still mandatory in each class descriptor, otherwise we have to review the PersistenceManager API (add in almost all public methods a new arg : String path). the uuid field is optional. 3/ the uuid can be defined in an ancestor class. Add UUID support Key: GRFT-125 URL: https://issues.apache.org/jira/browse/GRFT-125 Project: Graffito Issue Type: Sub-task Reporter: Christophe Lombart Assigned To: Christophe Lombart Fix For: 1.0-a1-dev Until now, only the path was used to retrieve content and makes references. Of course, in some situation UUID becomes more important. Furthermore supporting uuid is mandatory if we want to support reference jcr type. Here is a proposal to support UUID : 1/ Modify the PersistenceManager API : * add method getObject(String uuid) * Is it necessary to overload methods used to manage versions and locks ? 2/ Review the mapping descriptor in order to map a pojo attribute into the node UUID (readonly) : field-descriptor fieldName=myUuid uudi=true / From now, it is possible to specify the path attribute and/or the uuid attribute in the java classes. Both fields are optional. So, we have to review the classes PersistenceManagerImpl and ObjectConverterImpl which depend strongly on the path attribute. 3/ Specify in a class-descriptor the jcr type mix:referenceable . This can be done with one of the following way : a. In the class descriptor definition : class-descriptor className= jcrNodeType=... jcrMixinTypes=mix:referencable b. or in the primary node type definition associated to the java class 4/ It should possible to defined the uuid field in an ancestor class descrptor (similar to the path field descriptor) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GRFT-125) Add UUID support
[ https://issues.apache.org/jira/browse/GRFT-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart resolved GRFT-125. - Resolution: Fixed see my previous comments. Add UUID support Key: GRFT-125 URL: https://issues.apache.org/jira/browse/GRFT-125 Project: Graffito Issue Type: Sub-task Reporter: Christophe Lombart Assigned To: Christophe Lombart Fix For: 1.0-a1-dev Until now, only the path was used to retrieve content and makes references. Of course, in some situation UUID becomes more important. Furthermore supporting uuid is mandatory if we want to support reference jcr type. Here is a proposal to support UUID : 1/ Modify the PersistenceManager API : * add method getObject(String uuid) * Is it necessary to overload methods used to manage versions and locks ? 2/ Review the mapping descriptor in order to map a pojo attribute into the node UUID (readonly) : field-descriptor fieldName=myUuid uudi=true / From now, it is possible to specify the path attribute and/or the uuid attribute in the java classes. Both fields are optional. So, we have to review the classes PersistenceManagerImpl and ObjectConverterImpl which depend strongly on the path attribute. 3/ Specify in a class-descriptor the jcr type mix:referenceable . This can be done with one of the following way : a. In the class descriptor definition : class-descriptor className= jcrNodeType=... jcrMixinTypes=mix:referencable b. or in the primary node type definition associated to the java class 4/ It should possible to defined the uuid field in an ancestor class descrptor (similar to the path field descriptor) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GRFT-126) Add support for the Reference jcr type
[ https://issues.apache.org/jira/browse/GRFT-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478912 ] Christophe Lombart commented on GRFT-126: - I just commited the following point : * There is a new atomic converter (ReferenceTypeConverterImpl) which can be used to map a String attribute into a jcr property (based on the reference type). ex. : field-descriptor fieldName=reference2A jcrName=reference2A converter=org.apache.portals.graffito.jcr.persistence.atomictypeconverter.impl.ReferenceTypeConverterImpl / in this example, the jcr prop reference2A will contains a valid uuid. * There is a new bean converter (ReferenceBeanConverterImpl) which can be used to map a bean attribute into a jcr reference property. ex.: bean-descriptor fieldName=a jcrName=a converter=org.apache.portals.graffito.jcr.persistence.beanconverter.impl.ReferenceBeanConverterImpl / In this example, the jcr prop a' will contain a valid uuid but in the java object graph, the object matching to this uuid will be loaded. * See the unit test : PersistenceManagerUuidTest to get more details. I'm going to work on uuid/reference support in collections. Add support for the Reference jcr type Key: GRFT-126 URL: https://issues.apache.org/jira/browse/GRFT-126 Project: Graffito Issue Type: Sub-task Reporter: Christophe Lombart Assigned To: Christophe Lombart Supporting reference could be done in different ways. Just a couple of ideas (which required more investigation ) : * Define a field-descriptor which will contain an uuid to point to another object. * Define a bean descriptor which is mapped to a jcr prop of type reference. * Define a collection of properties based on the type Reference. * Define a collection containing some referenced beans. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Fwd: javadocs for Jackrabbit1.2 API]
Hi, You should ask this kind of question on the Jackrabbit mailing list. On 2/27/07, ruchi goel [EMAIL PROTECTED] wrote: -- Forwarded message -- From: ruchi goel [EMAIL PROTECTED] To: users@jackrabbit.apache.org Date: Mon, 26 Feb 2007 12:40:59 +0530 Subject: javadocs for Jackrabbit1.2 API Hi, Can someone point me to the location for Javadocs for Jackrabbit1.2API. Jackrabbit1.1 is available at http://jackrabbit.apache.org/api-1/index.html Thanks, Ruchi
Re: dtd for custom_nodetypes.xml
On 2/23/07, ruchi goel [EMAIL PROTECTED] wrote: *where CUSTOM_NODETYPE_CONFIG is custom_nodetypes.xml Is this not a standard way to register nodetypes ? This is only dependent o Jackrabbit1.2 API !! Following JCR-170, there is not a standard way to register node types. I think this point will be in the JCR-283.
[jira] Updated: (GRFT-125) Add UUID support
[ https://issues.apache.org/jira/browse/GRFT-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart updated GRFT-125: Description: Until now, only the path was used to retrieve content and makes references. Of course, in some situation UUID becomes more important. Furthermore supporting uuid is mandatory if we want to support reference jcr type. Here is a proposal to support UUID : 1/ Modify the PersistenceManager API : * add method getObject(String uuid) * Is it necessary to overload methods used to manage versions and locks ? 2/ Review the mapping descriptor in order to map a pojo attribute into the node UUID (readonly) : field-descriptor fieldName=myUuid uudi=true / From now, it is possible to specify the path attribute and/or the uuid attribute in the java classes. Both fields are optional. So, we have to review the classes PersistenceManagerImpl and ObjectConverterImpl which depend strongly on the path attribute. 3/ Specify in a class-descriptor the jcr type mix:referenceable . This can be done with one of the following way : a. In the class descriptor definition : class-descriptor className= jcrNodeType=... jcrMixinTypes=mix:referencable b. or in the primary node type definition associated to the java class 4/ It should possible to defined the uuid field in an ancestor class descrptor (similar to the path field descriptor) was: Until now, only the path was used to retrieve content and makes references. Of course, in some situation UUID becomes more important. Furthermore supporting uuid is mandatory if we want to support reference jcr type. Here is a proposal to support UUID : 1/ Modify the PersistenceManager API : * add method getObject(String uuid) * Is it necessary to overload methods used to manage versions and locks ? 2/ Review the mapping descriptor in order to map a pojo attribute into the node UUID (readonly) : field-descriptor fieldName=myUuid uudi=true / From now, it is possible to specify the path attribute and/or the uuid attribute in the java classes. Both fields are optional. So, we have to review the classes PersistenceManagerImpl and ObjectConverterImpl which depend strongly on the path attribute. 3/ Specify in a class-descriptor the jcr type mix:referenceable . This can be done with one of the following way : a. In the class descriptor definition : class-descriptor className= jcrNodeType=... jcrMixinTypes=mix:referencable b. or in the primary node type definition associated to the java class Add UUID support Key: GRFT-125 URL: https://issues.apache.org/jira/browse/GRFT-125 Project: Graffito Issue Type: Sub-task Reporter: Christophe Lombart Assigned To: Christophe Lombart Fix For: 1.0-a1-dev Until now, only the path was used to retrieve content and makes references. Of course, in some situation UUID becomes more important. Furthermore supporting uuid is mandatory if we want to support reference jcr type. Here is a proposal to support UUID : 1/ Modify the PersistenceManager API : * add method getObject(String uuid) * Is it necessary to overload methods used to manage versions and locks ? 2/ Review the mapping descriptor in order to map a pojo attribute into the node UUID (readonly) : field-descriptor fieldName=myUuid uudi=true / From now, it is possible to specify the path attribute and/or the uuid attribute in the java classes. Both fields are optional. So, we have to review the classes PersistenceManagerImpl and ObjectConverterImpl which depend strongly on the path attribute. 3/ Specify in a class-descriptor the jcr type mix:referenceable . This can be done with one of the following way : a. In the class descriptor definition : class-descriptor className= jcrNodeType=... jcrMixinTypes=mix:referencable b. or in the primary node type definition associated to the java class 4/ It should possible to defined the uuid field in an ancestor class descrptor (similar to the path field descriptor) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: dtd for custom_nodetypes.xml
If you want to register new node type, I advise you to read the following page : http://jackrabbit.apache.org/doc/nodetype/index.html. We are using the custom_nodestypes.xml only for the unit test. Later, we have to think about a more robust solution to register node types from the ocm tools. Anyway, I didn't find the dtd but it is quite simple to use it - sorry On 2/22/07, ruchi goel [EMAIL PROTECTED] wrote: Hi, Where can I finddtd for custom_nodetypes.xml used for registering custom nodetypes ? Thanks, Ruchi
Re: using jcr-mapping layer to access repsitory over RMI
On 2/15/07, ruchi goel [EMAIL PROTECTED] wrote: I have a question : Here is extract from the report: /The Content Model : -- * Our content model has to be extensible without imposing specific content types./ Why do you say so ? Isn't it already extensible with a flexibility of adding more content types ? In fact I was thinking of dropping the idea of having my document inherited from nt:file . Instead use , something which can be mapped to nt:unstructured , so that I can have root cms object, completely extensible , with all services acting at the this object and available to all child content types. Yes, the JCR is extensible, of course. But if our persistence service stores business objects (pojo) into a JCR repo, this persistence's service should not impose the usage of a specific object model. Right now, it is not possible to extends the Graffito Object model easily To be more flexible, the current CmsObject class has to be deleted in the Graffito framework. Another question is are there any timelines decided for this refactoring work ? It will depend on the contribution. Personally, I'm working on the first release of the OCM tools but if someone wants to work on OCM issues, I can start the refactoring.
Re: design query when using standard jcr nodetypes (nt:folder,nt:file)
Hi Ruchi, As you can see in another thread, we are going to speak about the Graffito content model. So please, joins us in the other thread. On 2/14/07, ruchi goel [EMAIL PROTECTED] wrote: Now, if I want to use nt:file and nt:folder , so that I have custom node types ps:folder and ps:file ineriting from nt:folder and nt:file , is it still possible to have similar flexibilty as above , in terms of designing a generic framework . I feel I am stuck because evenif I have somethig like ps:base (with additional properties) inheriting from nt:base , ps:folder inherits from nt:folder and cannot inherit properties from ps:base. Within JCR, you are not mandatory to use the predefined node types like nt:file, nt:folder ... I don't know your application requirements but why not to build a new content model. I mean define your own node types ? Thanks, Christophe
Re: Graffito status followup
Ok, it sounds great ! Before starting the refactoring, I would like to be sure that everybody is agreed. Can we summarize like this : Main goals --- * Review the project to be more attractive and increase the community size. * Refactoring the Graffito project in order to be more a content management framework instead of a complete CMS product. As an alternative to many cms products, Graffito wants to provide a more modular approach. Refactoring the project : --- * Framework means a series of components/services that can be running alone (or integrated into specific applications). The framework offers also an integration with other existing frameworks/components. One good example is an integration with existing workflow engines like JBPM, OsWorkflow, * We have to define the component lists (in the first time, only for the Graffito core layer). * The first component to review is the current PersistenceManager. This one aims to access to different JCR content repositories which can contain any kind of content. Other backend systems will not be supported because it will add more complexities (eg. node type management, ...). * Each component has its own set of artifacts (jar, config file, dependencies...). * The code repository has to be reviewed in order to match to this new goal. The Content Model : -- * Our content model has to be extensible without imposing specific content types. * The persistence layer will use the OCM tools to map java classes into a JCR repo. * A tools is required to register a new class definition into a JCR repo. When registring a new java class, this tools will create the corresponfing node types. Register a new content java class has to be as simple as register a new jcr node type. Let me know if it makes sense for you. br, Christophe On 2/14/07, Jukka Zitting [EMAIL PROTECTED] wrote: Hi, On 2/14/07, Christophe Lombart [EMAIL PROTECTED] wrote: On 2/14/07, Jukka Zitting [EMAIL PROTECTED] wrote: What I'm most interested in at this level is the content model. Currently Graffito has a predefined set of Document and other content types, but also uses generic bean persistence. Should the Graffito Content Model be fixed by better specifying the core content interfaces, or should the Graffito Core support arbitrary content objects? Good question. So, this is certainly the first tech aspect to review. Our persistence layer should not force the developer to use a specific content model. He should have the freedom to define its own interfaces and classes. The current CmsObject has be also optional. JCR and our OCM tools gives us this kind of flexibility. So, it should be possible to have similar think in the core Graffito components. At least try to have it with a prototype. Agreed. Having a fixed content model would effectively make Graffito just another content management system instead of a framework for such systems. However, having a flexible content model poses a number of open questions like how to handle typing or how to enforce specific relationships between documents or objects. JCR handles this quite nicely with the node type system. This is actually one of the main reasons why I'd rather make Graffito just JCR-based, as otherwise we'll need to come up with a similar typing mechanism that covers also other backend systems. BR, Jukka Zitting
Re: Graffito status followup
On 2/14/07, Jukka Zitting [EMAIL PROTECTED] wrote: Hi, On 2/14/07, Christophe Lombart [EMAIL PROTECTED] wrote: Before starting the refactoring, I would like to be sure that everybody is agreed. Can we summarize like this : +1, sounds good to me. * Framework means a series of components/services that can be running alone (or integrated into specific applications). The framework offers also an integration with other existing frameworks/components. We might want to consider applying the OSGi component model in Graffito to help integration with other tools. +1 . Let's talk later on that topic. There's a jcr-classloader component in Jackrabbit contribs that might come in handy. ok I will review it. I'd also be interested in investigating options for content-to-object mappings as opposed to object-to-content mappings. I.e. could we automatically expose JCR content as Java objects (instead or in addition to JCR Nodes) to enable effortless integration with various JavaBean tools. What do you mean by content-to-object mapping. Can give some use cases ? The OCM tools is supporting both mapping I think no ?
[jira] Created: (GRFT-123) Use jackrabbit 1.2.1
Use jackrabbit 1.2.1 Key: GRFT-123 URL: https://issues.apache.org/jira/browse/GRFT-123 Project: Graffito Issue Type: Improvement Components: JCR-Mapping, JCR-Nodemanagement Reporter: Christophe Lombart Priority: Minor Fix For: 1.0-a1-dev Use Jackarabit 1.2.1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Graffito status followup
Ah yes, just one comment : How to organise/split the work ? Who is volonteer to work on a specific part ? 1/ There is the first release for the JCR Mapping tools ( see http://mail-archives.apache.org/mod_mbox/incubator-graffito-dev/200702.mbox/[EMAIL PROTECTED]) 2/ The refactoring of the persistence manager. 3/ and maybe the documentations, exemples, review the site, ... I'm volonteer to work one the persistence manager refactorin if someone wants to work on the OCM tools. Christophe On 2/14/07, Jukka Zitting [EMAIL PROTECTED] wrote: Hi, On 2/2/07, Jukka Zitting [EMAIL PROTECTED] wrote: The ASF board asked us to report again this month on the outcome of the project status discussion we had recently. It seems that there's marked interest in the project, but as of now not much is happening. I'd like to resume the discussion and hopefully arrive in a conclusion that we could include in the next Incubator report. I've written the following report for Graffito this month. Please comment by the end of today if there's something you'd like to change in the report. Graffito (This is the extra followup report requested by the board last month.) Graffito is a framework for content-based applications, especially in portlet environments. Graffito entered incubation on September 20, 2004. The recent discussion on the status of the Graffito project has concluded with some concrete action items (see http://mail-archives.apache.org/mod_mbox/incubator-graffito-dev/200702.mbox/[EMAIL PROTECTED]). The plan is to realign Graffito to be more a content management framework instead of a complete CMS product and to better leverage the features of JCR content repositories. The effect of these plans on commit activity remains to be seen, but as of now the general feeling around the project is positive. Hopefully we'll have some concrete results to show by the time of the next report. BR, Jukka Zitting
Re: creating custom node types inheriting from nt:folder using jcr mapping
Hi Ruchi, It seems to be ok. Send me your unit tests and you model classes. It is a good exemple to add and I will have time to help you this afternoon. br, Christophe On 2/8/07, ruchi goel [EMAIL PROTECTED] wrote: Hi, I want to use jcr mapping layer for creating custom node type folder which should inherit from nt:folder I have following custom_nodetype.xml nodeTypes xmlns:nt=http://www.jcp.org/jcr/nt/1.0; xmlns:jcr=http://www.jcp.org/jcr/1.0; xmlns:rep=internal xmlns:mix=http://www.jcp.org/jcr/mix/1.0; nodeType name=folder isMixin=false hasOrderableChildNodes=false primaryItemName= supertypes supertypent:folder/supertype /supertypes/nodeType /nodeTypes I have following jcrmapping descriptor class-descriptor className=com.sun.portal.cms.model.HeirarchyContent jcrNodeType=nt:hierarchyNode discriminator=false !-- Field-descriptor is used to map simple attributes to jcr property -- field-descriptor fieldName=path path=true / field-descriptor fieldName=creationDate jcrName=jcr:created / / /class-descriptor class-descriptor className=com.sun.portal.cms.model.Folder jcrNodeType=folder extend=com.sun.portal.cms.model.HeirarchyContent discriminator=false !-- Field-descriptor is used to map simple attributes to jcr property -- field-descriptor fieldName=path path=true / / collection-descriptor fieldName=children proxy=false jcrNodeType=nt:hierarchyNode elementClassName=com.sun.portal.cms.model.HeirarchyContent collectionConverter= org.apache.portals.graffito.jcr.persistence.collectionconverter.impl.NTCollectionConverterImpl / /class-descriptor The problem is I am able to retrieve the items which are properties but I do not see any child node definitions in folder. Ideally since folder is inheriting from nt:folder , it should get a childnode definition of type nt:heirrarchynodeType Is there anything I am missing ? Checked out PersistenceAutoTest.java but it uses all custom nodetypes which are inherited from nt:base and so , it has childnodedefintions in custom node type definition. Help appreciated. Thanks, Ruchi
Re: [Fwd: Re: creating custom node types inheriting from nt:folder using jcr mapping]
Hi Ruchi,
I just commited a new unit test. it contains a mapping for nt:folder nt:file.
This is the first draft :-) . I'm going to work on it. I will add more
unit tests.
See the mapping file : jcrmapping-jcrnodetypes.xml
See the unit test : PersistenceManagerJcrNodeTypeTest
The current ocm implementation forces to use an extra class for the
jcr:resource.
This should be nice to map directly into the file class attributes.
Let me know if you need more help
br,
Christophe
On 2/8/07, ruchi goel [EMAIL PROTECTED] wrote:
-- Forwarded message --
From: ruchi goel [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Date: Thu, 08 Feb 2007 14:38:50 +0530
Subject: Re: creating custom node types inheriting from nt:folder using jcr
mapping
Thanks. Please find attached model classes . I do not have a clearly
isolated unit test case, since I have created a netbeans project where I
am using this.
But these are the two functionalities I am trying to achieve :
public void testSaveFolder(FolderModelService folderService){
//Test Save
//insert an Ad in repository
Folder folder = new Folder();
folder.setPath(/cms/folder2);
Collection content = new ArrayList();
content.add(new Folder(subfolder2));
folder.setChildren(content);
folderService.saveFolder(folder);
}
public void testReadFolder(FolderModelService folderService){
Folder folder = (Folder)folderService.getFolder(/cms/folder2);
System.out.print(folder Info : + folder.getCreationDate());
}
Thanks,
Ruchi
Christophe Lombart wrote:
Hi Ruchi,
e
It seems to be ok. Send me your unit tests and you model classes.
It is a good exemple to add and I will have time to help you this
afternoon.
br,
Christophe
On 2/8/07, ruchi goel [EMAIL PROTECTED] wrote:
Hi,
I want to use jcr mapping layer for creating custom node type folder
which should inherit from nt:folder
I have following custom_nodetype.xml
nodeTypes xmlns:nt=http://www.jcp.org/jcr/nt/1.0;
xmlns:jcr=http://www.jcp.org/jcr/1.0; xmlns:rep=internal
xmlns:mix=http://www.jcp.org/jcr/mix/1.0;
nodeType name=folder isMixin=false
hasOrderableChildNodes=false primaryItemName=
supertypes
supertypent:folder/supertype
/supertypes/nodeType
/nodeTypes
I have following jcrmapping descriptor
class-descriptor className=com.sun.portal.cms.model.HeirarchyContent
jcrNodeType=nt:hierarchyNode discriminator=false
!-- Field-descriptor is used to map simple attributes to jcr
property --
field-descriptor fieldName=path path=true /
field-descriptor fieldName=creationDate jcrName=jcr:created /
/
/class-descriptor
class-descriptor className=com.sun.portal.cms.model.Folder
jcrNodeType=folder
extend=com.sun.portal.cms.model.HeirarchyContent
discriminator=false
!-- Field-descriptor is used to map simple attributes to jcr
property --
field-descriptor fieldName=path path=true /
/
collection-descriptor fieldName=children proxy=false
jcrNodeType=nt:hierarchyNode
elementClassName=com.sun.portal.cms.model.HeirarchyContent
collectionConverter=
org.apache.portals.graffito.jcr.persistence.collectionconverter.impl.NTCollectionConverterImpl
/
/class-descriptor
The problem is I am able to retrieve the items which are properties but
I do not see any child node definitions in folder. Ideally since folder
is inheriting from nt:folder , it should get a childnode definition of
type nt:heirrarchynodeType
Is there anything I am missing ?
Checked out PersistenceAutoTest.java but it uses all custom nodetypes
which are inherited from nt:base and so , it has childnodedefintions in
custom node type definition.
Help appreciated.
Thanks,
Ruchi
/*
* HeirarchyContent.java
*
* Created on February 7, 2007, 2:10 PM
*
* To change this template, choose Tools | Template Manager
* and open the template in the editor.
*/
package com.sun.portal.cms.model;
import java.util.Date;
/**
*
* @author ruchi goel
*/
public class HeirarchyContent {
String path;
Date creationDate;
/** Creates a new instance of HeirarchyContent */
public HeirarchyContent() {
}
public Date getCreationDate(){
return creationDate;
}
public void setPath(String path){
this.path = path;
}
public void setCreationDate(Date creationDate){
this.creationDate = creationDate;
}
public String getPath(){
return path;
}
}
/*
* Folder.java
*
* Created on February 7, 2007, 10:45 AM
*
* To change this template, choose Tools | Template Manager
* and open the template in the editor.
*/
package com.sun.portal.cms.model;
import java.util.Collection;
import java.util.ArrayList;
/**
*
* @author ruchi goel
*/
public class Folder extends HeirarchyContent {
Collection children;
/** Creates a new instance of Folder */
public Folder() {
} ;
public Folder(String path) {
this.path = path;
}
public void
[jira] Assigned: (GRFT-40) Advanced support for JCR properties and node
[ https://issues.apache.org/jira/browse/GRFT-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart reassigned GRFT-40: -- Assignee: Christophe Lombart Advanced support for JCR properties and node Key: GRFT-40 URL: https://issues.apache.org/jira/browse/GRFT-40 Project: Graffito Issue Type: Task Components: JCR-Mapping Reporter: Christophe Lombart Assigned To: Christophe Lombart Fix For: 1.0-a1-dev - We have to support the following JCR Types : * PropertyType.NAME * PropertyType.PATH * PropertyType.REFERENCE * PropertyType.UNDEFINED - Map UUID and the path into the POJO object - Check if mandatory auto created properties are well managed. More unit test are required. - Support for same-name siblings : the query service should supported it ans we have also to support the method : node.getNodes(nodepattern). We have also to check if the insert, update and delete methods support correctly the same-name sibling. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: graffito with remote repository
Hi Ruchi, We are not yet working on that but of course all contributions and comments in this area are welcome. br, Christophe On 2/7/07, ruchi goel [EMAIL PROTECTED] wrote: Hi, Can I use graffito , with Jackrabbit configured to use remote repository ? -Ruchi
Re: using jcr mapping for Document Management System
On 2/6/07, ruchi goel [EMAIL PROTECTED] wrote: Hi, I am trying to design Document Management System using JSR170 impl(Jackrabbit). Checked out graffito framework but it has its own complex layers for persistence conversion, versioning, locking. What is it complex the complete Graffito Stack or the JCR OCM tools (JCR/object mapping) ? JSR170 impl already provides implementation for versioning, locking etc. I found jcrmapping layer very useful for persistence , services and mapping java objects to nodetypes. Few questions : 1. Is it a good idea to use only jcr mapping layer and design a Document Management System .? Depend on JSR170 impl for versioning, locking etc. You are free to do it but personnally I think it is not a good design. You are mixing 2 different kind of API in the persistence layer. Maybe for performance reasons, it could be justifified. That's the same with JDBC Hibernate. 2. Checked out the model for CmsObject,Document,Folder and their corresponding mapping files in test code . These seem to inherit from nt:base and then all basic properties fr files/folders seem to havebeen custom defined. Why can't we use nt:folder as supertype for graffito:folder and nt:file as supertype for graffito:document and inherit the properties as it is , instead of defining them in mapping files. Well, this situaiton is used only for the unit tests. We should add more unit tests with the classical jct node types like nt:folder, The OCM tools gives you the freedom to define your own content model and map them to the more appropriate jcr node type. You are not mandatory to use the CmsObject, Document, Folder classes. Sorry for the confusion in the unit tests. br, Christophe
Re: using jcr mapping for Document Management System
On 2/6/07, ruchi goel [EMAIL PROTECTED] wrote: OK. So, if I have a ps:folder inheriting from nt:folder , how do I access from my model the properties which are nherited from nt:folder. You should create a new class descriptor which maps a java class to a ps:folder. In this class descriptor try to map the ps:folder properties into the java class attribute. If I remember correctly, nt:file has not a lot of properties (creation date + children def based on HierarchyNode).
Re: JCR Mapping release
ok good points. I will try to help. What about the doc for this release. I'm currently reviewing it. Christophe On 2/2/07, Jukka Zitting [EMAIL PROTECTED] wrote: Hi, I'd like to push for the release of the JCR Mapping tool as a precondition of the discussed move to the Apache Jackrabbit project. To get started I suggest we create a target release like 0.9 in Jira and use it to track all the issues that should be solved before the release. Browsing quickly through the current JCR Mapping issues it seems that at least the following would be good candidates for a release: GRFT-40 Advanced support for JCR properties and node GRFT-72 Bug in org.apache.portals.graffito.jcr.persistence.atomictypeconverter.impl.UtilDateTypeConverterImpl GRFT-74 Provide Readme's for subprojects jcr-mapping and jcr-nodemanagement GRFT-84 ObjectConverterImpl wrong behavior when manipulating autoCreate and protected properties GRFT-99 ManageableCollectionUtil should not throw unsupported JcrMapping exception GRFT-106 Avoid INFINITE RECURSION when Object Model has cycles. I have some spare cycles over the next few weeks, so I can participate in making things happen. BR, Jukka Zitting
Re: documentation of Graffito JCR mapping :advanced mapping stratagies
Hi Ruchi, this work is under progress but I have no time to work on it now. All contributions are welcome. On 1/30/07, ruchi goel [EMAIL PROTECTED] wrote: Hi , Is the documentation for advanced mapping stratagies for graffito jcr mapping available anywhere ? Has the work been done in this area ? Thanks, Ruchi
Re: versions and locks for jcr mapping ?
Yes, see in the PersistenceManager API. On 1/30/07, ruchi goel [EMAIL PROTECTED] wrote: Is versions and locks available for graffito's jcr mapping layer ? Documentation does not have any info on this. Thanks, Ruchi
Re: Graffito status
Same for me : sounds good to me On 1/14/07, Michael Wechner [EMAIL PROTECTED] wrote: Jukka Zitting wrote: Hi, On 1/10/07, Jukka Zitting [EMAIL PROTECTED] wrote: Pinging the mailing list for opinions on what to include in the Graffito status report. Thanks all for comments and ideas! See the end of this message for the report I drafted based on the discussion. sounds good to me Michi BR, Jukka Zitting Graffito is a framework for content-based applications, especially in portlet environments. Graffito entered incubation on September 20, 2004. Top three items to resolve before graduation: 1. Build a self-sustaining community 2. Create an incubating Graffito release 3. Move the JCR mapping component to the Jackrabbit project There hasn't been much activity in the Graffito project since the last report. A discussion on what to do with the project that still hasn't reached critical mass after over two years of incubation is currently taking place. The perceived complexity of the project is seen by many as a barrier to start using or contributing to Graffito. Splitting the project into more manageable component projects was raised as one potential approach to reviving the codebase and project community. -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED] +41 44 272 91 61
Re: Graffito status
Just for the history, we start the dev before the first JCR stable impl and when JCR was not like today. this is one of the reasons why the architecture is like this (based on a series of plugin used to access to heterogenous content servers). The PersistenceManager uses those plugins to access to the different content server at the same time.The PersistenceManager is a good way to vistualize your content server into the same tree. Each content request are sent to the persistence manager which has the responsability to work with the appropriate content server. If the new Graffito goal is to access to only one content repo from your apps, yes we can simplify the architecture but the persistence manager is working right now (at least 70% stable :-) ) Of course we can improve it but it makes its job. Furthermore, it is more interesting to access to different content servers in the same time (even if there are all based on JCR). So, I'm not sure the architecture could be simplify here. What do you think about that ? Using JCR in all cases will not reduce the architecture complexity but it will reduce the work of course. br, Christophe On 1/11/07, Carsten Ziegeler [EMAIL PROTECTED] wrote: Christophe Lombart wrote: On 1/10/07, Torgeir Veimo [EMAIL PROTECTED] wrote: On Wed, 2007-01-10 at 16:16 +0100, Christophe Lombart wrote: So Please give us your point of view and we will take a decision after that. I find it a bit diffuse what the project is all about. Is it a sandbox of ideas or some sort of AppFuse for web publishing? Well the main goal is the build a ECM plateform like Alfresco and many others (but with a clean license :-) ) Here is the architecture : http://incubator.apache.org/graffito/architecture.html Is it make sense for you ? I guess this has been discussed before, but I'm curious anyway :) Wouldn't it simplify the architecture and reduce the work if Graffito would be based on JCR only instead of supporting various store implementations? I thought JCR can already handle this. Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Graffito status
On 1/11/07, Torgeir Veimo [EMAIL PROTECTED] wrote: On Thu, 2007-01-11 at 09:00 +0100, Christophe Lombart wrote: Furthermore, it is more interesting to access to different content servers in the same time (even if there are all based on JCR). So, I'm not sure the architecture could be simplify here. What do you think about that ? I thought one of the goals of JCR was to be _the_ common api for content repositories. Abstracting away JCR might seem rational to one developer, but for another it's a drawback. Does the persistence manager provide all the services that the JCR api provides, such as versioning, transaction, types properties, xpath and sql queries, etc? Day after day yes What about jackrabbit enhancements, such as node type registration etc? In my point of view, this should be managed by the JCR plugin (not the persistence manager). We like to make abstraction by using some layers. It increases the architecture complexity and code but you are more independent of the technologies you are using. This choice can be review but personally I think it is more interesting to make abstraction. The Graffito complexity can be reduce here : either we want to use the JCR API in our different content services or we want to maximize abstraction by using POJO's (like now). If the second solution is our choice, we have to find a way to increase the Graffito community because it is a big deal. -- Torgeir Veimo [EMAIL PROTECTED]
Re: Graffito status
Thanks Jukka, this is the good time to think about that. Due to my daily work, it is not possible to work on all Graffito aspects but I would like to continue to work on smaller components like the OCM tools. I'm just finishing my long vacations and now I'm ready to finalise the OCM doc. When this work is done, the JCR Mapping will be ready for its first release. After a long incubation process, the Graffito community is not yet there and the Graffito goal is too big for a couple of mans. Personnally, I would like to : 1/ Move OCM tools into Jackrabbit. 2/ Depending on the feedback on this discussion : review the Graffito goals, split the projects or retire the project. of course, without this kind of feedback, we cannot take a decision. We can also review the priorities. 1/ Build the first JCR Mapping version. 2/ Review and finalyse the persistence layer (add the JCR support, review the security). 3/ Add new components (workflow, ...) 4/ Build applications (RSS, news management, forum, ...). I think we made an error to build everything on the same time in order to give a small demo the community. This is not good for this kind of project. So Please give us your point of view and we will take a decision after that. br, Christophe sorry for sounding stupid, but what this component do exactly? Object Content Mapping (see on http://incubator.apache.org/graffito/jcr-mapping/index.html) Is the description of the architecture still accurate? yes. The ocm tools can be used in a JCR Graffito plugin to access to a JCR repo (not yet implemented). http://incubator.apache.org/graffito/architecture.html but what about the rest of the project? No activity for a long time Should we do something to try building a more active community around the project? How ?
Re: Graffito status
On 1/10/07, Torgeir Veimo [EMAIL PROTECTED] wrote: On Wed, 2007-01-10 at 16:16 +0100, Christophe Lombart wrote: So Please give us your point of view and we will take a decision after that. I find it a bit diffuse what the project is all about. Is it a sandbox of ideas or some sort of AppFuse for web publishing? Well the main goal is the build a ECM plateform like Alfresco and many others (but with a clean license :-) ) Here is the architecture : http://incubator.apache.org/graffito/architecture.html Is it make sense for you ?
[jira] Resolved: (GRFT-122) Proxy is not supported with ParentBeanConverter
[ http://issues.apache.org/jira/browse/GRFT-122?page=all ] Christophe Lombart resolved GRFT-122. - Resolution: Fixed Fixed Proxy is not supported with ParentBeanConverter --- Key: GRFT-122 URL: http://issues.apache.org/jira/browse/GRFT-122 Project: Graffito Issue Type: Bug Components: JCR-Mapping Affects Versions: 1.0-a1-dev Reporter: Christophe Lombart Assigned To: Christophe Lombart Fix For: 1.0-a1-dev It is not possible to useproxy with a bean field converted with the ParentBeanConverterImpl -- 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: (GRFT-121) Deploying Graffito portlets causes dojo support problems.
Deploying Graffito portlets causes dojo support problems. - Key: GRFT-121 URL: http://issues.apache.org/jira/browse/GRFT-121 Project: Graffito Issue Type: Bug Components: Portlets Affects Versions: 1.0-a1-dev Reporter: Christophe Lombart Fix For: 1.0-a1-dev From Mikko Wuokko deploying graffito portlets to Jetspeed seems to break the dojo support. It produces dojo is not defined. -- 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: Graffito breaking Jetspeed dojo?
I will create a new Jira issue. Usually, I test Graffito on J2 without dojo. Thanks for the feedback Christophe On 11/22/06, Mikko Wuokko [EMAIL PROTECTED] wrote: Hi. I have noticed that after deploying graffito portlets to Jetspeed, all the dojo functionality gives you an error dojo is not defined. This happens as far as saw in the permission manager, portlet selector as well as in the whole desktop. All gives you the same error and the desktop does not produce anything visual. I'm using the latest trunk versions of both Jetspeed and Graffito. I know that both are under heavy development, but I didn't saw anything on the mailinglists about this issue. -Mikko
Re: permissions howto
Hi Evangelos, is there any documentation for the meaning of these: Apply only on the current cms object Apply the desired permission only on the current object (selected in the Graffito browser). Apply on all documents each subfolders If the current object displayed in the Graffito browser is a folder, apply the desired permission on all folder children (documents subfolders) recursively. Apply on this level (not on subfolders) If the current object displayed in the Graffito browser is a folder , apply the desired permission on all folder children ( not recursively ). If I need to have a users folder under root and in there X user folders with only/full permission to X user how should I set up? This is only an example : /JetspeedDs (root folder) : Apply on this level (not on subfolders) view /role/user Apply on all documents each subfoldersall /role/admin /JetspeedDs/users Nothing //JetspeedDs/users/christophe Apply on all documents each subfolders all /user/christophe Apply only on the current cms objectall /user/christophe The last one is not mandatory. It can be used if the user christophe is authorized to modify its folder attributes (description, title). With the default configuration, the portal users cannot access to the edit mode for the Graffito browser. This has to be reviewed for your use cases (and find a way to disable some action in the edit mode). HTH Christophe
Re: create graffito folder when a j2 user created
Are you using the default graffito permission ?
Are you using the admin user to create the new user folder ?
Can you send me the complete stack trace ?
I'm interesting to receive the patch for this feature (even if there
are some bugs). It will be easier to check your error.
br,
Christophe
On 11/3/06, Evangelos Vlachogiannis [EMAIL PROTECTED] wrote:
Hi,
I would like to create a graffito folder when a new user is created. So
I have created a graffito service and call it from inside jetspeed
PortalAdministrationImpl.java as you can see in attachment. Could you
please tell me if I am doing something wrong as I get a graffito
permission (not sufficent perm) exception?
thnx,
Vangelis
--
---
Evangelos Vlachogiannis
Researcher - PhD. Candidate
Contact: http://www.syros.aegean.gr/users/evlach/contactme.php
---
Index: PortalAdministrationImpl.java
===
--- PortalAdministrationImpl.java (revision 344)
+++ PortalAdministrationImpl.java (revision 345)
@@ -17,6 +17,7 @@
import java.io.FileReader;
import java.io.StringWriter;
+import java.lang.reflect.Method;
import java.security.Principal;
import java.security.PrivilegedAction;
import java.util.Collection;
@@ -53,6 +54,8 @@
import org.apache.jetspeed.security.User;
import org.apache.jetspeed.security.UserManager;
import org.apache.jetspeed.security.UserPrincipal;
+import org.apache.jetspeed.services.JetspeedPortletServices;
+import org.apache.jetspeed.services.PortletServices;
import org.apache.velocity.VelocityContext;
import org.apache.velocity.app.VelocityEngine;
import org.springframework.mail.MailException;
@@ -259,8 +262,7 @@
// deep copy from the default folder template
tree, creating a deep-copy of the template
// in the new user's folder tree
Folder source =
innerPageManager.getFolder(innerFolderTemplate);
-innerPageManager.deepCopyFolder(source,
Folder.USER_FOLDER + innerUserName, innerUser);
-
+innerPageManager.deepCopyFolder(source,
Folder.USER_FOLDER + innerUserName, innerUser);
return null;
}
catch (FolderNotFoundException e1) {
@@ -290,13 +292,49 @@
log.error(Registration Error: Failed to create user folders for +
userName + , + pe.toString());
throw pe;
}
-
+
+try
+{
+ User theAdminUser = userManager.getUser(admin);
+JetspeedException pe1 = (JetspeedException)
Subject.doAsPrivileged(theAdminUser.getSubject(), new PrivilegedAction()
+{
+public Object run()
+{
+try
+ {
+ System.out.print(login fix start);
+PortletServices services =
JetspeedPortletServices.getSingleton();
+Object userFolderService =
services.getService(UserFolderService);
+ String className =
userFolderService.getClass().getName();
+ Class userFolderManagerClass =
Class.forName(className);
+ Class[] argClasses = {String.class};
+ Object[] args = {innerUserName};
+ Method method =
userFolderManagerClass.getMethod(initializeUser, argClasses);
+ method.invoke(userFolderService, args);
+ System.out.print(login fix end);
+ }
+ catch(Exception e)
+ {
+ //e.printStackTrace();
+ System.out.print(login fix failed+
e.getMessage());
+ }
+
+return null;
+}
+}, null);
+}
+catch(Exception e)
+{
+
+}
+
}
catch (Exception e)
{
log.error(Registration Error: Failed to create registered user + userName
+ , + e.toString());
throw new RegistrationException(e);
-}
+}
+
}
[jira] Created: (GRFT-115) Specify the mapping strategy with JDK 1.5 annotations
Specify the mapping strategy with JDK 1.5 annotations - Key: GRFT-115 URL: http://issues.apache.org/jira/browse/GRFT-115 Project: Graffito Issue Type: New Feature Components: JCR-Mapping Reporter: Christophe Lombart Use java jdk 1.5 annotations in stead of specifying a class descriptor in the xml mapping file. I propose to create a new subproject in trunk/jcr/annotations. This one can be build with a specific maven goal. By this way, jdk 1.4 is still supporting with the current xml mapping file. -- 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: (GRFT-116) Define a default mapping strategy for lazy developers
Define a default mapping strategy for lazy developers - Key: GRFT-116 URL: http://issues.apache.org/jira/browse/GRFT-116 Project: Graffito Issue Type: Improvement Reporter: Christophe Lombart If there is not class-descriptor for a specific persistent class, use a default mapping strategy. In the first time, this default mapping strategy can be used only in simple situations and has some limitations (eg. proxies, inheritance, interface are not supported). We have to specify the rules used for this default mapping stategy. -- 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: (GRFT-113) Simple Text editor does not save after edit
[ http://issues.apache.org/jira/browse/GRFT-113?page=comments#action_12445132 ] Christophe Lombart commented on GRFT-113: - Is the bug occur in the following scenario ? 1/ connect as admin 2/ In the Graffito portlet, click on edit 3/ select the tab subfolders documents 4/ add document - Populate the content field and select simple text - click on next. 5/ add text content, click on insert the document. the simple text is inserted. I also review the simple text update and it works. Please give me more details. Simple Text editor does not save after edit --- Key: GRFT-113 URL: http://issues.apache.org/jira/browse/GRFT-113 Project: Graffito Issue Type: Bug Components: Portlets Reporter: Evangelos Vlachogiannis Attachments: patch-text_edit_save.txt Simple Text editor does not save after edit. -- 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: (GRFT-117) Provide custom converter for atomic fields
Provide custom converter for atomic fields -- Key: GRFT-117 URL: http://issues.apache.org/jira/browse/GRFT-117 Project: Graffito Issue Type: Improvement Reporter: Christophe Lombart We have the possibility to defined custom converter for bean and collection descriptor but not for atomic fields. -- 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: (GRFT-64) Add support for JCR Lock
[ http://issues.apache.org/jira/browse/GRFT-64?page=all ] Christophe Lombart resolved GRFT-64. Resolution: Fixed The unit test has been added Add support for JCR Lock Key: GRFT-64 URL: http://issues.apache.org/jira/browse/GRFT-64 Project: Graffito Issue Type: New Feature Components: JCR-Mapping Affects Versions: 1.0-a1-dev Reporter: Christophe Lombart Assigned To: Christophe Lombart Attachments: PersistenceManager.patch, PersistenceManagerImpl.patch -- 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: (GRFT-114) Filter expression build wrong with Filter.addOr/AndFilter
[ http://issues.apache.org/jira/browse/GRFT-114?page=all ] Christophe Lombart reassigned GRFT-114: --- Assignee: Christophe Lombart Filter expression build wrong with Filter.addOr/AndFilter - Key: GRFT-114 URL: http://issues.apache.org/jira/browse/GRFT-114 Project: Graffito Issue Type: Bug Components: JCR-Mapping Affects Versions: 1.0-a1-dev Reporter: Felix Meschberger Assigned To: Christophe Lombart Attachments: GRFT-114.diff If the JCR expression of the Filter to be add-ed or or-ed in is empty, a syntactically incorrect JCR expression may be created on the target filter. Example: Let f1 be a Filter with JCR expression @xyz=5 and f2 be a Filter with an empty JCR expression. Calling f1.addOrFilter(f2) results in the JCR expression (@xyz=5) or (). -- 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: (GRFT-104) Support versionning without node type definition
[ http://issues.apache.org/jira/browse/GRFT-104?page=comments#action_12444989 ] Christophe Lombart commented on GRFT-104: - It is possible to add the mixin type 'mix:versionable' in the class descriptor like this : class-descriptor className=org.apache.portals.graffito.jcr.testmodel.A jcrNodeType=nt:unstructured jcrMixinTypes=mix:versionable !-- Add here field, bean and collection desctipors -- /class-descriptor Support versionning without node type definition Key: GRFT-104 URL: http://issues.apache.org/jira/browse/GRFT-104 Project: Graffito Issue Type: Improvement Components: JCR-Mapping Affects Versions: 1.0-a1-dev Reporter: Christophe Lombart Priority: Minor Fix For: 1.0-a1-dev From Ruchi Goel : It is possible to perform versioning operations on custom node type but not on nt:unstructured (without a custom node type definition). The JSR170 spec allows versioning of a node of type nt:unstructured , by specifying node.addMixin(mix:versionable) I want to version a java object mapped to node of type nt:unstructured. -- 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: (GRFT-104) Support versionning without node type definition
[ http://issues.apache.org/jira/browse/GRFT-104?page=all ] Christophe Lombart resolved GRFT-104. - Resolution: Fixed Support versionning without node type definition Key: GRFT-104 URL: http://issues.apache.org/jira/browse/GRFT-104 Project: Graffito Issue Type: Improvement Components: JCR-Mapping Affects Versions: 1.0-a1-dev Reporter: Christophe Lombart Priority: Minor Fix For: 1.0-a1-dev From Ruchi Goel : It is possible to perform versioning operations on custom node type but not on nt:unstructured (without a custom node type definition). The JSR170 spec allows versioning of a node of type nt:unstructured , by specifying node.addMixin(mix:versionable) I want to version a java object mapped to node of type nt:unstructured. -- 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: (GRFT-113) Simple Text editor does not save after edit
[ http://issues.apache.org/jira/browse/GRFT-113?page=comments#action_12444991 ] Christophe Lombart commented on GRFT-113: - I cannot reproduce the problem here. Can you give more information The text editor can save after edit. Simple Text editor does not save after edit --- Key: GRFT-113 URL: http://issues.apache.org/jira/browse/GRFT-113 Project: Graffito Issue Type: Bug Components: Portlets Reporter: Evangelos Vlachogiannis Attachments: patch-text_edit_save.txt Simple Text editor does not save after edit. -- 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: (GRFT-106) Avoid INFINITE RECURSION when Object Model has cycles.
[ http://issues.apache.org/jira/browse/GRFT-106?page=comments#action_12443528 ] Christophe Lombart commented on GRFT-106: - * What about the auto* settings (auto-retrieve,auto-update auto-insert). Those settings can limit graph load and updates ? * Reference is not supported but we can also use the auto* settings. Avoid INFINITE RECURSION when Object Model has cycles. -- Key: GRFT-106 URL: http://issues.apache.org/jira/browse/GRFT-106 Project: Graffito Issue Type: Improvement Components: JCR-Mapping Reporter: Dan Connelly Priority: Critical The default ObjectConverterImpl is restricted to acyclic graphs in the object model. Many Java object models are NOT acyclic. For instance, I am on your Friends list. Yoar are on my Friends list. Java encourages such structures. Almost any large object model in Java will have hidden cycles. Saving an Object Model that contains cycles using Graffito causes an infinite recursion. Clearly, it is important to maintain a 1-to-1 correspondence between Nodes and Objects to prevent this. In the absence of Multiple Parent Nodes, it will be necessary to use REFERENCE or UNDEFINED Items in place of the 2nd (or greater) Node representing a given Object. My preference si that the default ObjectConverterImpl should support REFERENCE.,Failing this, use of UNDEFINED also solves this problem and would acceptable (as default). Whether or not REFERENCE is used, both insertion and retrieval must provide a reasonable result. A custom ojbect converter should be available to switch UNDEFINED to REFERENCE, or vice versa. Also, it is probably best to keep the targeted, well-defined Nodes close to the Root Node.This implies that the default ObjectConverterImpl should implement a Breadth-First, rather than a Depth-First, traversal of the Object Model on both insertion and retrieval. Again, if the default is Depth-First, a custom object converter should be available that implements Breadth-First. Admittedly, support for (2 representations) X (2 traversals) implies a drastic refactoring and/or rewriting of the ObjectConverterImpl class. -- 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: (GRFT-111) Extend Bean/Collection/FieldDescriptor with support for node type management tools
[ http://issues.apache.org/jira/browse/GRFT-111?page=all ] Christophe Lombart closed GRFT-111. --- Resolution: Fixed I added the unit tests. Felix, can you check if it is ok. Extend Bean/Collection/FieldDescriptor with support for node type management tools -- Key: GRFT-111 URL: http://issues.apache.org/jira/browse/GRFT-111 Project: Graffito Issue Type: Improvement Reporter: Felix Meschberger Assigned To: Christophe Lombart Attachments: GRFT-111.zip, GRFT-111_NodeTypeManagement.diff, NodeTypeManagerImpl.java I started working with Graffito JCR-Mapping some weeks ago noticing that it actually implements what I planned to implement in my own tool - and more :-) So I started to like that thing. While working on it I thought, that it would be nice to define node types based on the mapping definitions and also noticed, that this is actually also supported by the mapping descriptors. Still, the support by the descriptors has some drawbacks: Field descriptors are thought to only map to properties, while collection and bean descriptors are thought to only map to child nodes. Consequently the field descriptors support attributes for property definition while bean and collection definitions support attributes for child node definition. While this assumption is mostly true, it fails in the case of multi-valued properties, which is implemented using a collection descriptor. I myself implemented another CollectionConverter, which supports residual jcrName values. Also in this case, the collection descriptor maps properties. Hence I proopse to extend the bean and collection descriptors with attributes for property definition. Namely I propose the addition of jcrType and jcrMultiple attributes which should contain the property type and multi-value flag respectively. The respective BeanDescriptor and CollectionDescriptor classes are to be extended for these attributes. To further simplify node type management tools, I further propose, to define two interfaces - PropertyDefDescriptor and ChildNodeDefDescriptor - which may be used by node type management tools to extract the relevant information to define properties and child nodes. The FieldDescriptor will only implement the PropertyDefDescriptor while the BeanDescriptor and CollectionDescriptor classes will implement both interfaces. The node type management tool will then have to apply heuristics to decide, whether a property or a child node should be defined. Attached you will find the patchs to the FieldDescriptor, BeanDescriptor and CollectionDescriptor classes as well as the proposed interfaces. -- 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: (GRFT-111) Extend Bean/Collection/FieldDescriptor with support for node type management tools
[ http://issues.apache.org/jira/browse/GRFT-111?page=all ] Christophe Lombart resolved GRFT-111. - Resolution: Fixed Now it is resolved - unit tests are there Extend Bean/Collection/FieldDescriptor with support for node type management tools -- Key: GRFT-111 URL: http://issues.apache.org/jira/browse/GRFT-111 Project: Graffito Issue Type: Improvement Reporter: Felix Meschberger Assigned To: Christophe Lombart Attachments: GRFT-111.zip, GRFT-111_NodeTypeManagement.diff, NodeTypeManagerImpl.java I started working with Graffito JCR-Mapping some weeks ago noticing that it actually implements what I planned to implement in my own tool - and more :-) So I started to like that thing. While working on it I thought, that it would be nice to define node types based on the mapping definitions and also noticed, that this is actually also supported by the mapping descriptors. Still, the support by the descriptors has some drawbacks: Field descriptors are thought to only map to properties, while collection and bean descriptors are thought to only map to child nodes. Consequently the field descriptors support attributes for property definition while bean and collection definitions support attributes for child node definition. While this assumption is mostly true, it fails in the case of multi-valued properties, which is implemented using a collection descriptor. I myself implemented another CollectionConverter, which supports residual jcrName values. Also in this case, the collection descriptor maps properties. Hence I proopse to extend the bean and collection descriptors with attributes for property definition. Namely I propose the addition of jcrType and jcrMultiple attributes which should contain the property type and multi-value flag respectively. The respective BeanDescriptor and CollectionDescriptor classes are to be extended for these attributes. To further simplify node type management tools, I further propose, to define two interfaces - PropertyDefDescriptor and ChildNodeDefDescriptor - which may be used by node type management tools to extract the relevant information to define properties and child nodes. The FieldDescriptor will only implement the PropertyDefDescriptor while the BeanDescriptor and CollectionDescriptor classes will implement both interfaces. The node type management tool will then have to apply heuristics to decide, whether a property or a child node should be defined. Attached you will find the patchs to the FieldDescriptor, BeanDescriptor and CollectionDescriptor classes as well as the proposed interfaces. -- 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] Reopened: (GRFT-111) Extend Bean/Collection/FieldDescriptor with support for node type management tools
[ http://issues.apache.org/jira/browse/GRFT-111?page=all ] Christophe Lombart reopened GRFT-111: - Ooops close by error - sorry Extend Bean/Collection/FieldDescriptor with support for node type management tools -- Key: GRFT-111 URL: http://issues.apache.org/jira/browse/GRFT-111 Project: Graffito Issue Type: Improvement Reporter: Felix Meschberger Assigned To: Christophe Lombart Attachments: GRFT-111.zip, GRFT-111_NodeTypeManagement.diff, NodeTypeManagerImpl.java I started working with Graffito JCR-Mapping some weeks ago noticing that it actually implements what I planned to implement in my own tool - and more :-) So I started to like that thing. While working on it I thought, that it would be nice to define node types based on the mapping definitions and also noticed, that this is actually also supported by the mapping descriptors. Still, the support by the descriptors has some drawbacks: Field descriptors are thought to only map to properties, while collection and bean descriptors are thought to only map to child nodes. Consequently the field descriptors support attributes for property definition while bean and collection definitions support attributes for child node definition. While this assumption is mostly true, it fails in the case of multi-valued properties, which is implemented using a collection descriptor. I myself implemented another CollectionConverter, which supports residual jcrName values. Also in this case, the collection descriptor maps properties. Hence I proopse to extend the bean and collection descriptors with attributes for property definition. Namely I propose the addition of jcrType and jcrMultiple attributes which should contain the property type and multi-value flag respectively. The respective BeanDescriptor and CollectionDescriptor classes are to be extended for these attributes. To further simplify node type management tools, I further propose, to define two interfaces - PropertyDefDescriptor and ChildNodeDefDescriptor - which may be used by node type management tools to extract the relevant information to define properties and child nodes. The FieldDescriptor will only implement the PropertyDefDescriptor while the BeanDescriptor and CollectionDescriptor classes will implement both interfaces. The node type management tool will then have to apply heuristics to decide, whether a property or a child node should be defined. Attached you will find the patchs to the FieldDescriptor, BeanDescriptor and CollectionDescriptor classes as well as the proposed interfaces. -- 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: (GRFT-108) Digester fails to load descriptor classes when using different class loaders
[ http://issues.apache.org/jira/browse/GRFT-108?page=all ] Christophe Lombart reassigned GRFT-108: --- Assignee: Christophe Lombart Digester fails to load descriptor classes when using different class loaders Key: GRFT-108 URL: http://issues.apache.org/jira/browse/GRFT-108 Project: Graffito Issue Type: Improvement Affects Versions: 1.0-a1-dev Environment: Graffito SVN checkout Rev. 448648 Reporter: Felix Meschberger Assigned To: Christophe Lombart Attachments: GRFT-108.fm.20061006.diff With issue GRFT-100 a patch has been applied to the ReflectionUtils class to support custom class loaders for mapped classes. There is a similar issue regarding the loading of class descriptors using Digester: If the Digester is loaded by a different class loader than the jcr mapping library, the digester cannot load the descriptor classes. The Digester class provides a setClassLoader() method which allows for setting a custom class loader. As the classes to be loaded are part of the jcr mapping library, the class loader of the DigesterDescriptorReader class, which uses the Digester to load class descriptions, should be set on the digester. -- 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: (GRFT-108) Digester fails to load descriptor classes when using different class loaders
[ http://issues.apache.org/jira/browse/GRFT-108?page=all ] Christophe Lombart resolved GRFT-108. - Resolution: Fixed Patch applied thanks Digester fails to load descriptor classes when using different class loaders Key: GRFT-108 URL: http://issues.apache.org/jira/browse/GRFT-108 Project: Graffito Issue Type: Improvement Affects Versions: 1.0-a1-dev Environment: Graffito SVN checkout Rev. 448648 Reporter: Felix Meschberger Assigned To: Christophe Lombart Attachments: GRFT-108.fm.20061006.diff With issue GRFT-100 a patch has been applied to the ReflectionUtils class to support custom class loaders for mapped classes. There is a similar issue regarding the loading of class descriptors using Digester: If the Digester is loaded by a different class loader than the jcr mapping library, the digester cannot load the descriptor classes. The Digester class provides a setClassLoader() method which allows for setting a custom class loader. As the classes to be loaded are part of the jcr mapping library, the class loader of the DigesterDescriptorReader class, which uses the Digester to load class descriptions, should be set on the digester. -- 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: (GRFT-103) AtomicTypeConversion on retrieve omitted (fails) when NodeTypePerHierarchy Discriminator
[ http://issues.apache.org/jira/browse/GRFT-103?page=all ] Christophe Lombart reassigned GRFT-103: --- Assignee: Christophe Lombart AtomicTypeConversion on retrieve omitted (fails) when NodeTypePerHierarchy Discriminator --- Key: GRFT-103 URL: http://issues.apache.org/jira/browse/GRFT-103 Project: Graffito Issue Type: Bug Components: JCR-Mapping Reporter: Dan Connelly Assigned To: Christophe Lombart Priority: Critical ObjectConverterImpl#retrieveSimpleFields has this guard for one branch of its logic: for populating the retrieved object: if (classDescriptor.usesNodeTypePerHierarchyStrategy() classDescriptor.hasDiscriminator()) When this test is true, then there is *no type conversion* on fields. The code attempts to set object field directly from the string, getValue().getString(), value for the node property. This fails for an int field mapped from the object. If I force this test the *false*, then the retrieve works and there is no failure. While it is not entirely clear to me how the inheritance maaping strategy is chosen or how it is implemented, it does not seem reasonable that the strategy selection should affect field conversions. In my code, the same mapping file is used for the write and the read whatever variations in mapping I choose. One variation I have tried is to remove all extend= class attributes in the mapping. However, he inheritance strategy remained at NodeTypePerHiearchy and the retrieve continued to fail. BTW: The DTD comment says extends but the !ATTLIST requires it to be extend. Confusing.Since extend is optional and not ambiguous, why would I ever want to provide it in the mapping? -- 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: (GRFT-103) AtomicTypeConversion on retrieve omitted (fails) when NodeTypePerHierarchy Discriminator
[ http://issues.apache.org/jira/browse/GRFT-103?page=all ] Christophe Lombart resolved GRFT-103. - Resolution: Fixed Fixed. I reviewed the method retrieveSimpleFields in order to support a better type convertion. I added this case in the unit test. Let me know if something is wrong. AtomicTypeConversion on retrieve omitted (fails) when NodeTypePerHierarchy Discriminator --- Key: GRFT-103 URL: http://issues.apache.org/jira/browse/GRFT-103 Project: Graffito Issue Type: Bug Components: JCR-Mapping Reporter: Dan Connelly Assigned To: Christophe Lombart Priority: Critical ObjectConverterImpl#retrieveSimpleFields has this guard for one branch of its logic: for populating the retrieved object: if (classDescriptor.usesNodeTypePerHierarchyStrategy() classDescriptor.hasDiscriminator()) When this test is true, then there is *no type conversion* on fields. The code attempts to set object field directly from the string, getValue().getString(), value for the node property. This fails for an int field mapped from the object. If I force this test the *false*, then the retrieve works and there is no failure. While it is not entirely clear to me how the inheritance maaping strategy is chosen or how it is implemented, it does not seem reasonable that the strategy selection should affect field conversions. In my code, the same mapping file is used for the write and the read whatever variations in mapping I choose. One variation I have tried is to remove all extend= class attributes in the mapping. However, he inheritance strategy remained at NodeTypePerHiearchy and the retrieve continued to fail. BTW: The DTD comment says extends but the !ATTLIST requires it to be extend. Confusing.Since extend is optional and not ambiguous, why would I ever want to provide it in the mapping? -- 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: (GRFT-109) Prevent NullPointerException with
[ http://issues.apache.org/jira/browse/GRFT-109?page=all ] Christophe Lombart reassigned GRFT-109: --- Assignee: Christophe Lombart Prevent NullPointerException with - Key: GRFT-109 URL: http://issues.apache.org/jira/browse/GRFT-109 Project: Graffito Issue Type: Improvement Components: JCR-Mapping Reporter: Edgar Poce Assigned To: Christophe Lombart Priority: Trivial Attachments: 061009_nodescriptor.patch -- 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: (GRFT-109) Prevent NullPointerException with
[ http://issues.apache.org/jira/browse/GRFT-109?page=all ] Christophe Lombart resolved GRFT-109. - Resolution: Fixed Patch applied. It returns an IncorrectPersistentClassException instead of a generic JcrException. Prevent NullPointerException with - Key: GRFT-109 URL: http://issues.apache.org/jira/browse/GRFT-109 Project: Graffito Issue Type: Improvement Components: JCR-Mapping Reporter: Edgar Poce Assigned To: Christophe Lombart Priority: Trivial Attachments: 061009_nodescriptor.patch -- 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: (GRFT-111) Extend Bean/Collection/FieldDescriptor with support for node type management tools
[ http://issues.apache.org/jira/browse/GRFT-111?page=all ] Christophe Lombart reassigned GRFT-111: --- Assignee: Christophe Lombart Extend Bean/Collection/FieldDescriptor with support for node type management tools -- Key: GRFT-111 URL: http://issues.apache.org/jira/browse/GRFT-111 Project: Graffito Issue Type: Improvement Reporter: Felix Meschberger Assigned To: Christophe Lombart Attachments: GRFT-111.zip, NodeTypeManagerImpl.java I started working with Graffito JCR-Mapping some weeks ago noticing that it actually implements what I planned to implement in my own tool - and more :-) So I started to like that thing. While working on it I thought, that it would be nice to define node types based on the mapping definitions and also noticed, that this is actually also supported by the mapping descriptors. Still, the support by the descriptors has some drawbacks: Field descriptors are thought to only map to properties, while collection and bean descriptors are thought to only map to child nodes. Consequently the field descriptors support attributes for property definition while bean and collection definitions support attributes for child node definition. While this assumption is mostly true, it fails in the case of multi-valued properties, which is implemented using a collection descriptor. I myself implemented another CollectionConverter, which supports residual jcrName values. Also in this case, the collection descriptor maps properties. Hence I proopse to extend the bean and collection descriptors with attributes for property definition. Namely I propose the addition of jcrType and jcrMultiple attributes which should contain the property type and multi-value flag respectively. The respective BeanDescriptor and CollectionDescriptor classes are to be extended for these attributes. To further simplify node type management tools, I further propose, to define two interfaces - PropertyDefDescriptor and ChildNodeDefDescriptor - which may be used by node type management tools to extract the relevant information to define properties and child nodes. The FieldDescriptor will only implement the PropertyDefDescriptor while the BeanDescriptor and CollectionDescriptor classes will implement both interfaces. The node type management tool will then have to apply heuristics to decide, whether a property or a child node should be defined. Attached you will find the patchs to the FieldDescriptor, BeanDescriptor and CollectionDescriptor classes as well as the proposed interfaces. -- 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: (GRFT-111) Extend Bean/Collection/FieldDescriptor with support for node type management tools
[ http://issues.apache.org/jira/browse/GRFT-111?page=comments#action_12443370 ] Christophe Lombart commented on GRFT-111: - Patch applied for the jcr-mapping subproject. Right now, it is not possible to apply the patch for the node type manager because it depends on com.day.crx. Can we avoid this dependency ? Is it not possible to dependent only on Jackrabbit add (maybe) add more flexibility in this manager to support other JCR impl. Felix, what do you think about that ? Extend Bean/Collection/FieldDescriptor with support for node type management tools -- Key: GRFT-111 URL: http://issues.apache.org/jira/browse/GRFT-111 Project: Graffito Issue Type: Improvement Reporter: Felix Meschberger Assigned To: Christophe Lombart Attachments: GRFT-111.zip, NodeTypeManagerImpl.java I started working with Graffito JCR-Mapping some weeks ago noticing that it actually implements what I planned to implement in my own tool - and more :-) So I started to like that thing. While working on it I thought, that it would be nice to define node types based on the mapping definitions and also noticed, that this is actually also supported by the mapping descriptors. Still, the support by the descriptors has some drawbacks: Field descriptors are thought to only map to properties, while collection and bean descriptors are thought to only map to child nodes. Consequently the field descriptors support attributes for property definition while bean and collection definitions support attributes for child node definition. While this assumption is mostly true, it fails in the case of multi-valued properties, which is implemented using a collection descriptor. I myself implemented another CollectionConverter, which supports residual jcrName values. Also in this case, the collection descriptor maps properties. Hence I proopse to extend the bean and collection descriptors with attributes for property definition. Namely I propose the addition of jcrType and jcrMultiple attributes which should contain the property type and multi-value flag respectively. The respective BeanDescriptor and CollectionDescriptor classes are to be extended for these attributes. To further simplify node type management tools, I further propose, to define two interfaces - PropertyDefDescriptor and ChildNodeDefDescriptor - which may be used by node type management tools to extract the relevant information to define properties and child nodes. The FieldDescriptor will only implement the PropertyDefDescriptor while the BeanDescriptor and CollectionDescriptor classes will implement both interfaces. The node type management tool will then have to apply heuristics to decide, whether a property or a child node should be defined. Attached you will find the patchs to the FieldDescriptor, BeanDescriptor and CollectionDescriptor classes as well as the proposed interfaces. -- 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: (GRFT-105) Allow custom ProxyManager
[ http://issues.apache.org/jira/browse/GRFT-105?page=all ] Christophe Lombart reassigned GRFT-105: --- Assignee: Christophe Lombart Allow custom ProxyManager - Key: GRFT-105 URL: http://issues.apache.org/jira/browse/GRFT-105 Project: Graffito Issue Type: Improvement Components: JCR-Mapping Reporter: Dan Connelly Assigned To: Christophe Lombart Kindly 1) Make ProxyManager an interface. 2) Provide a 3-arg consttructor for ObjectConverterImpl. Allow some ProxyManagerImpl as the 3rd arg. -- 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: (GRFT-105) Allow custom ProxyManager
[ http://issues.apache.org/jira/browse/GRFT-105?page=all ] Christophe Lombart resolved GRFT-105. - Resolution: Fixed fix - Let me know if something is wrong Allow custom ProxyManager - Key: GRFT-105 URL: http://issues.apache.org/jira/browse/GRFT-105 Project: Graffito Issue Type: Improvement Components: JCR-Mapping Reporter: Dan Connelly Assigned To: Christophe Lombart Kindly 1) Make ProxyManager an interface. 2) Provide a 3-arg consttructor for ObjectConverterImpl. Allow some ProxyManagerImpl as the 3rd arg. -- 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: cannot import!!
The components subproject has no dependencies to the graffito portlets subproject (applications/graffito-portlets). Why do you want to use ServiceAccessor in ContentIndexServiceImpl ? It is better to use injection to access to another service. On 10/17/06, Evangelos Vlachogiannis [EMAIL PROTECTED] wrote: Hi list, I have met a strange behavior: When I just add in class components/src/java/org/apache/portals/graffito/services/search/impl/ContentIndexServiceImpl.java the import org.apache.portals.graffito.portlets.util.ServiceAccessor; and try to compile using maven allBuild I compile get error saying that there is not org.apache.portals.graffito.portlets.util package!!! Any ideas pls before I get crazy?? Thnx, Vangelis -- Best regards, Christophe
Re: cannot import!!
If the cmsObject paramter is a Document :
1/ Cast into Document to get the stream
2/ Add the content in the index
On 10/17/06, Evangelos Vlachogiannis [EMAIL PROTECTED] wrote:
What I want to do is to get the DocumentStream so that I can add the
content in index. Here is my changes: Any proposal how to replace that
class please?
Index:
components/src/java/org/apache/portals/graffito/services/search/impl/ContentIndexServiceImpl.java
===
---
components/src/java/org/apache/portals/graffito/services/search/impl/ContentIndexServiceImpl.java
(revision 463916)
+++
components/src/java/org/apache/portals/graffito/services/search/impl/ContentIndexServiceImpl.java
(working copy)
@@ -34,9 +34,11 @@
import org.apache.portals.graffito.model.core.CmsObject;
import org.apache.portals.graffito.model.core.VersionnedContent;
import org.apache.portals.graffito.persistence.ContentPersistenceService;
+import org.apache.portals.graffito.portlets.util.ServiceAccessor;
+import org.apache.portals.graffito.services.dm.DocumentModelService;
import org.apache.portals.graffito.services.search.ContentIndexService;
-/**
+/**
*
* Default implementation for [EMAIL PROTECTED]
org.apache.portals.graffito.services.core.ContentIndexService}
*
@@ -157,13 +159,19 @@
doc.add(Field.Keyword(CREATION_DATE_FIELD,
DateField.dateToString(cmsObject.getCreationDate(;
doc.add(Field.Keyword(LAST_MODIFIED_DATE_FIELD,
DateField.dateToString(cmsObject.getLastModified(;
+DocumentModelService cms =
ServiceAccessor.getDocumentService();
+org.apache.portals.graffito.model.dm.Document doc1 =
cms.getDocument(cmsObject.getUri());
+String s = new
String(doc1.getDocumentStream().getContentByte(),utf-8);
+doc.add(Field.Text(contents, s)); //this only for text
documents
+
+//TODO: add more more mime type (pdfbox.org for pdf etc...)
+
// Add version info
if (cmsObject instanceof VersionnedContent)
{
//TODO : add Version infos
}
-
indexWriter.addDocument(doc);
indexWriter.optimize();
result = true;
@@ -171,7 +179,9 @@
catch (IOException e)
{
log.error(Error while adding document into the Lucene
index , e);
-}
+} catch (ContentManagementException e) {
+log.error(Error while getting the contents of the document
to add to the Lucene index , e);
+}
finally
{
try
Christophe Lombart wrote:
The components subproject has no dependencies to the graffito
portlets subproject (applications/graffito-portlets).
Why do you want to use ServiceAccessor in ContentIndexServiceImpl ? It
is better to use injection to access to another service.
On 10/17/06, Evangelos Vlachogiannis [EMAIL PROTECTED] wrote:
Hi list,
I have met a strange behavior: When I just add in class
components/src/java/org/apache/portals/graffito/services/search/impl/ContentIndexServiceImpl.java
the
import org.apache.portals.graffito.portlets.util.ServiceAccessor;
and try to compile using maven allBuild I compile get error saying that
there is not org.apache.portals.graffito.portlets.util package!!! Any
ideas pls before I get crazy??
Thnx,
Vangelis
--
Evangelos Vlachogiannis
Researcher - University of the Aegean
ContactMore: http://www.syros.aegean.gr/users/evlach/contactme.php
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.408 / Virus Database: 268.13.4/477 - Release Date: 16/10/2006
--
Best regards,
Christophe
Re: JCR-Mapping: Mapping multiple properties or child nodes to a single field
This is a nice feature. Please, add it into Jira. -- Best regards, Christophe On 10/17/06, Felix Meschberger [EMAIL PROTECTED] wrote: Hi all, While working on our project, I encountered the need to map multiple properties (or child nodes) to a single field. I think, such a mapping can be implemented using a CollectionDescriptor whose name is a pattern suitable for the Node.getProperties(String pattern) and Node.getNodes(String pattern), resp. Of course, best would be to base such an implementing on a Map type field. Hence I implemented a ResidualPropertiesCollectionConverterImpl mapping multiple properties and a ResidualNodesCollectionConverterImpl mapping multiple child nodes as well as ManagedHashMap to support both classes. I could imagine, that such functionality could be of use for others, too. Therefore I am willing to give them to the project. Attached, you will find the three classes. NB: Currently the classes are in our own package, which would of course should be fixed when integrating with the JCR-Mapping project. What do you think ? Regards Felix
Re: JCR-Mapping: Extend Bean/Collection/FieldDescriptor with support for node type management tools
No comment :-) Thanks for this contribution. I'm waiting for your new jira issue. -- Best regards, Christophe On 10/17/06, Felix Meschberger [EMAIL PROTECTED] wrote: Hi all, I started working with Graffito JCR-Mapping some weeks ago noticing that it actually implements what I planned to implement in my own tool - and more :-) So I started to like that thing. While working on it I thought, that it would be nice to define node types based on the mapping definitions and also noticed, that this is actually also supported by the mapping descriptors. Still, the support by the descriptors has some drawbacks: Field descriptors are thought to only map to properties, while collection and bean descriptors are thought to only map to child nodes. Consequently the field descriptors support attributes for property definition while bean and collection definitions support attributes for child node definition. While this assumption is mostly true, it fails in the case of multi-valued properties, which is implemented using a collection descriptor. I myself implemented another CollectionConverter, which supports residual jcrName values. Also in this case, the collection descriptor maps properties. Hence I proopse to extend the bean and collection descriptors with attributes for property definition. Namely I propose the addition of jcrType and jcrMultiple attributes which should contain the property type and multi-value flag respectively. The respective BeanDescriptor and CollectionDescriptor classes are to be extended for these attributes. To further simplify node type management tools, I further propose, to define two interfaces - PropertyDefDescriptor and ChildNodeDefDescriptor - which may be used by node type management tools to extract the relevant information to define properties and child nodes. The FieldDescriptor will only implement the PropertyDefDescriptor while the BeanDescriptor and CollectionDescriptor classes will implement both interfaces. The node type management tool will then have to apply heuristics to decide, whether a property or a child node should be defined. Attached you will find the patchs to the FieldDescriptor, BeanDescriptor and CollectionDescriptor classes as well as the proposed interfaces. What do you think of these extensions ? They certainly make my life easier, as I implemented a very simple node type management tool. Thanks for any comments. Regards Felix
Re: [jira] Commented: (GRFT-102) Accessibility of portal content produced by authoring tool (kupu)
Hi, That's strange. Do you have the emptySessionPath=true in the tomcat server.xml ? the kupu editor is using a servlet which requires to share the session with the portlet. Connector port=8080 maxHttpHeaderSize=8192 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false redirectPort=8443 acceptCount=100 connectionTimeout=2 disableUploadTimeout=true emptySessionPath=true / Christophe On 10/14/06, Evangelos Vlachogiannis [EMAIL PROTECTED] wrote: Hi Christophe, should I config something before using it? Graffito Content Browser on edit mode it says No content found in this folder. Use the edit mode to add new content. and whatever tab I press nothing happens. I guess I miss something here... regards, Vangelis Christophe Lombart wrote: Thanks you very much for your help In order to support put method instead of post, there are a couple of major changes. On 10/13/06, Evangelos Vlachogiannis (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/GRFT-102?page=comments#action_12442060 ] Evangelos Vlachogiannis commented on GRFT-102: -- Thanks a lot for that Christophe. I ll test that, try to understand changes and take it further asap. Accessibility of portal content produced by authoring tool (kupu) - Key: GRFT-102 URL: http://issues.apache.org/jira/browse/GRFT-102 Project: Graffito Issue Type: Improvement Components: Portlets Environment: Now running on ie and mozilla but for accessibility should support all browsers (maybe consider an applet editor ??) Reporter: Evangelos Vlachogiannis Priority: Minor Attachments: patch.txt Current version of kupu html editor produces really very bad markup in terms of accessibility but even for validity. For instance the font tag must really be avoided - use css style instead (like new 1.3.5 ver does). So a shift to the new version is a step towards better accessibility. Further, these are other relating problems that should be solved: 1. currently the editor portlet page in jetspeed contains 2 html tags which is really unacceptable!!. 2. Seeking for real xhtml (a base for accessibility) the editor should provide only semantic markup. For example could provide strong instead of bold and emphasis instead of underline or/and provide bold bolder etc using css. 3. For a portal creating content it actually means creating a page fragment. This means that the editor should allow for global markup and also provide apropriate css classes for styling according to JSR-168. Well, most of the issues are actually concern the editor and I might submit also to kupu but I find important to sync such work. This subject is actually one of my research interests and could find more information of this work (Portal Accessibility Guidelines Extensions) at http://www.syros.aegean.gr/users/evlach/page/ -- 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 -- Evangelos Vlachogiannis Researcher - University of the Aegean ContactMore: http://www.syros.aegean.gr/users/evlach/contactme.php -- Best regards, Christophe
Re: search
this is not yet implemented. There is a simple search component which can be used in any kind of portlets. On 10/12/06, Evangelos Vlachogiannis [EMAIL PROTECTED] wrote: Hi list, I would like to ask is there a working search portlet for graffito that we could use with jetspeed2. I have seen there are some relating java classes but looking in portlet.xml there is no such a config.. so I would like to know about the status and aims of this work. thanks a lot, Vangelis -- Best regards, Christophe
Re: Does Graffito provide standalone CMS functionality?
Hi Andreas, Graffito looks very promising to me, but I'm not sure how well it will perform if used standalone. Much of your current work seems to be directed towards support of portals, more specifically the Jetspeed server, and towards JCR on the persistence layer - FileSystemContentStore is, in essence, empty. Also it looks to me that you support documents with binary content only. The suggested Article/News module does not seem to exist yet. This is not difficult to build new services to manage specific content like articles, news, ... I have something for a news management but I'm too busy to review it in details. We can work together on that. Thus I'm not sure if my system would benefit from using Graffito. Do you have any thoughts or insights on this? Graffito fit to your needs (if you are agree to develop new components). Again I can help. this is not an important work. Are there any projects you know about which already use standalone Graffito? Yes, I'm using graffito on customer site. It is a Struts web application running on Spring.it is a specific document management and publication system for an important european institution. Unfortunatly, you have to defined your own user interface if you want to use Graffito in standalone mode. I'm very amazing by the GWT web framework and I think it is should be nice to have some Graffito JCR UI components for this one. Right now, it is difficult to support all existing web framework. Also, does Graffito already support version 2.0 of Spring, which was released just two days ago (don't blame me, my collegues decided to switch ignoring my needs and without applying any caution it seems :-/)? No yet migrated :-( -- Best regards, Christophe
[jira] Assigned: (GRFT-102) Accessibility of portal content produced by authoring tool (kupu)
[ http://issues.apache.org/jira/browse/GRFT-102?page=all ] Christophe Lombart reassigned GRFT-102: --- Assignee: Christophe Lombart Accessibility of portal content produced by authoring tool (kupu) - Key: GRFT-102 URL: http://issues.apache.org/jira/browse/GRFT-102 Project: Graffito Issue Type: Improvement Components: Portlets Environment: Now running on ie and mozilla but for accessibility should support all browsers (maybe consider an applet editor ??) Reporter: Evangelos Vlachogiannis Assigned To: Christophe Lombart Priority: Minor Attachments: patch.txt Current version of kupu html editor produces really very bad markup in terms of accessibility but even for validity. For instance the font tag must really be avoided - use css style instead (like new 1.3.5 ver does). So a shift to the new version is a step towards better accessibility. Further, these are other relating problems that should be solved: 1. currently the editor portlet page in jetspeed contains 2 html tags which is really unacceptable!!. 2. Seeking for real xhtml (a base for accessibility) the editor should provide only semantic markup. For example could provide strong instead of bold and emphasis instead of underline or/and provide bold bolder etc using css. 3. For a portal creating content it actually means creating a page fragment. This means that the editor should allow for global markup and also provide apropriate css classes for styling according to JSR-168. Well, most of the issues are actually concern the editor and I might submit also to kupu but I find important to sync such work. This subject is actually one of my research interests and could find more information of this work (Portal Accessibility Guidelines Extensions) at http://www.syros.aegean.gr/users/evlach/page/ -- 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: portlet content mode prototype
Hi edgar, I just deployed the portlet war and it works. I'm not sure it is the most recent one. I have not all features (check-in check-out, ...). Do I have to build from the source to get thoses features ? br Christophe On 9/21/06, Philip Mark Donaghy [EMAIL PROTECTED] wrote: That would be cool if someone had an online demo. On 9/21/06, Torgeir Veimo [EMAIL PROTECTED] wrote: On 21 Sep 2006, at 08:45, Philip Mark Donaghy wrote: I tried the wysiwyg portlet out, this is one of the best portlets I have ever seen. I'm looking forward to collaborating with you. I checked back for the source but it's gone, sniff .`( Did either of you have it running online somewhere to demo? -- Torgeir Veimo [EMAIL PROTECTED] -- Philip Donaghy donaghy.blogspot.com del.icio.us/donaghy/philip Skype: philipmarkdonaghy Office: +33 5 56 60 88 02 Mobile: +33 6 20 83 22 62
Re: portlet content mode prototype
Compare to the existing Graffito codebase, this is completely another approach to build content portlets (100% dependent on the JCR API ). Christophe
Re: portlet content mode prototype
I just deployed the war maybe I forgot to do something. On 9/21/06, Edgar Poce [EMAIL PROTECTED] wrote: On 9/21/06, Christophe Lombart [EMAIL PROTECTED] wrote: no. Do you see a tab in help mode with the label versioning?. I see only a info tab page then, for some reason it's not working correctly :(, there are at least 8 tabs. I'll try to upload a demo and let you know. -- Best regards, Christophe
Re: portlet content mode prototype
Here is the error in the log. An error occurred at line: 10 in the jsp file: /WEB-INF/jsp/cms/info.jsp Generated servlet error: The operator + is undefined for the argument type(s) java.lang.Object, java.lang.Object On 9/21/06, Edgar Poce [EMAIL PROTECTED] wrote: I see, it doesn't work, the info tab shows: Portlet is Not Available: graffito-jcr-portlets-1.0::WYSIWYG portlet Reason: null is there any error in the tomcat log? On 9/21/06, Evangelos Vlachogiannis [EMAIL PROTECTED] wrote: and a public live demo http://guportal.gunet.gr/jetspeed/portal/Public what I have deployed. Evangelos Vlachogiannis wrote: some result here. I have just deployed that. No other tab. I only changed the repo path in web.xml. Do I need to config something? O/H Christophe Lombart ??: I just deployed the war maybe I forgot to do something. On 9/21/06, Edgar Poce [EMAIL PROTECTED] wrote: On 9/21/06, Christophe Lombart [EMAIL PROTECTED] wrote: no. Do you see a tab in help mode with the label versioning?. I see only a info tab page then, for some reason it's not working correctly :(, there are at least 8 tabs. I'll try to upload a demo and let you know. -- Evangelos Vlachogiannis Researcher - University of the Aegean ContactMore: http://www.syros.aegean.gr/users/evlach/contactme.php -- Best regards, Christophe
Re: portlet content mode prototype
Edgar, Did you already uploaded the new war ? still the same problem here. br, Christophe On 9/21/06, Edgar Poce [EMAIL PROTECTED] wrote: It's uploaded now. sorry for the inconvenience. On 9/21/06, Christophe Lombart [EMAIL PROTECTED] wrote: Here is the error in the log. An error occurred at line: 10 in the jsp file: /WEB-INF/jsp/cms/info.jsp Generated servlet error: The operator + is undefined for the argument type(s) java.lang.Object, java.lang.Object On 9/21/06, Edgar Poce [EMAIL PROTECTED] wrote: I see, it doesn't work, the info tab shows: Portlet is Not Available: graffito-jcr-portlets-1.0::WYSIWYG portlet Reason: null is there any error in the tomcat log? On 9/21/06, Evangelos Vlachogiannis [EMAIL PROTECTED] wrote: and a public live demo http://guportal.gunet.gr/jetspeed/portal/Public what I have deployed. Evangelos Vlachogiannis wrote: some result here. I have just deployed that. No other tab. I only changed the repo path in web.xml. Do I need to config something? O/H Christophe Lombart ??: I just deployed the war maybe I forgot to do something. On 9/21/06, Edgar Poce [EMAIL PROTECTED] wrote: On 9/21/06, Christophe Lombart [EMAIL PROTECTED] wrote: no. Do you see a tab in help mode with the label versioning?. I see only a info tab page then, for some reason it's not working correctly :(, there are at least 8 tabs. I'll try to upload a demo and let you know. -- Evangelos Vlachogiannis Researcher - University of the Aegean ContactMore: http://www.syros.aegean.gr/users/evlach/contactme.php -- Best regards, Christophe
Re: portlet content mode prototype
On 9/21/06, Edgar Poce [EMAIL PROTECTED] wrote: I'd like to make clear that I'm not in a crusade in favor of jcr. I'm interested in seeing the features I'm talking independently of implementation details. Sorry if I'm being repetitive, but my interest is seeing 1. CMS features for j2 portal site, 2. integration of portlet contents to the portal site hierarchy, 3. and a reusable portlet content mode; 4. a webdav interface would be cool but not strictly necessary for me. Yes, we have the same targets. what do you mean exactly by integration of portlet contents to the portal site hierarchy ? That's why I'd like to know if the graffito community agress these are goals in the scope of graffito? and in case it's in the scope I'd like to know how it should be implemented. I'm open to work with other approaches, see my other thread about the page manager impl. In my point of view, JCR is a nice API for the persistence layer (but not on business logic/service layer and not on the interface layer ). I like an application which makes abstraction on the technology to used. I don't know how we can provide both solutions in the Graffito project for the same target. This project is not always clear for some people. So supporting both approach will add more complexities to understand our goals. Now, it should be nice to get feedback/comments from others. Furthermore, J2 has its own object model. Adding cms features into J2, is it not supporting the J2 object model in a content repo in order to have features like versionning, locking, search, ... ? Let's continue to discuss that on your thread abouth the page manager impl. br, edgar Christophe -- Best regards, Christophe
Re: j2 page manager status
Hi Edgar, What do you mean with only? I'm not sure if I understand you correctly. I understand that graffito should provide an implementation of the page manager interface in order to provide a set of cms services to manage the pages, folders, links, fragments, etc. ok sorry for the confusion. Yes, this is what I mean. Most of the page manager component in j2 seems to be implemented by pojos. Can these objects be reused or should they be reimplemented to be included as a graffito service? In theory, pojo can be reused. Graffito is using the Persistence service to store object in the right content repo. Thoses components should use it when they want to update, retrieve, ... the J2 content objects like pages, folders, ... I see interfaces for some services under the services package, but I don't see any interface specifying what a service is and what's the contract to add a new service. What are the requirements to include a new service in graffito?. The is one requirement for building a new service. Add a getter or a constructor to inject the Persistence service ref. By this way, the new service can use it to store, retrieve, ... the content objects. I see that the page manager depends heavily on the j2 security component. Should graffito reimplement the security service or it can depend on the secutiry api to manage the security? In case there's need to reimplement the j2 security component, could we use the j2 secutiry spi or we should implement all the security api? By default, the Graffito security is using the J2 security components (which is maybe a problem to use Graffito in another portal application). So, Graffito is also heavily depending on J2 security components (maybe too much :-) ). I don't see in the api how this service pluggability works. How is it supposed a new service will be added at runtime? This is not yet implemented but it is a nice feature to have. I absolutely agree with you, unfortunately I'm still in a stage where I'm not sure my questions have sense :(. Well I understand because this project is not well documented.
[jira] Created: (GRFT-104) Support versionning without node type definition
Support versionning without node type definition Key: GRFT-104 URL: http://issues.apache.org/jira/browse/GRFT-104 Project: Graffito Issue Type: Improvement Components: JCR-Mapping Affects Versions: 1.0-a1-dev Reporter: Christophe Lombart Priority: Minor Fix For: 1.0-a1-dev From Ruchi Goel : It is possible to perform versioning operations on custom node type but not on nt:unstructured (without a custom node type definition). The JSR170 spec allows versioning of a node of type nt:unstructured , by specifying node.addMixin(mix:versionable) I want to version a java object mapped to node of type nt:unstructured. -- 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: documentation on Versioning
Hi Ruchi, I added this issue in Jira. For this kind of issue, you can add it yourself. By this way, we are sure that you request will be reviewed. br, Christophe On 9/15/06, ruchi goel [EMAIL PROTECTED] wrote: Is documentation on versioning available in svn ? It is not yet posted on the site . In OCM , is it possible to version a node without creating a custom node type .The JCR mapping descriptor does not talk anything about it. The versioning tests which are available, perform versioning operations on custom node type. But JSR170 allows versioning of a node of type nt:unstructured , by specifying node.addMixin(mix:versionable) I want to version a java object mapped to node of type nt:unstructured , via OCM -Ruchi
[jira] Commented: (GRFT-99) ManageableCollectionUtil should not throw unsupported JcrMapping exception
[
http://issues.apache.org/jira/browse/GRFT-99?page=comments#action_12436643 ]
Christophe Lombart commented on GRFT-99:
Dan,
I'm sorry but I forget some details on this issue. If I understand, you want a
generic implementation for the interface ManageableCollection (based on the
java collection).
ManageableCollectionUtil should not throw unsupported JcrMapping exception
Key: GRFT-99
URL: http://issues.apache.org/jira/browse/GRFT-99
Project: Graffito
Issue Type: Improvement
Components: JCR-Mapping
Affects Versions: 1.0-a1-dev
Environment: All
Reporter: Dan Connelly
Many times, the object model'd code cannot be altered for ocm.
To avoid the unsupported exception in almost all such cases, use a
delegating wrapper class to encapsulate a Collection.The wrapper class
implements MaangeableCollection.
Since delegation is a performance hit, make the test below the last resort
for *object* conversion in the method:
public static ManageableCollection getManageableCollection(Object object)
Proposed catchall test and program action:
if (object instanceof Collection) {
return new ManageableCollectionImpl((Collection)object);
}
--
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: (GRFT-101) Allow developer to supply newInstace method in subclass of ObjectConverterImpl
[
http://issues.apache.org/jira/browse/GRFT-101?page=comments#action_12436645 ]
Christophe Lombart commented on GRFT-101:
-
Dan,
Can you provide a patch for this issue ?
Allow developer to supply newInstace method in subclass of
ObjectConverterImpl
Key: GRFT-101
URL: http://issues.apache.org/jira/browse/GRFT-101
Project: Graffito
Issue Type: Improvement
Affects Versions: 1.0-a1-dev
Environment: JCR Mapping
Reporter: Dan Connelly
I used a simple change in ObjectConverterImpl. This allows me to use a
Factory class (in place of JavaBean constructors) in my object model.
I added the following method to ObjectConverterImpl.:
protected Object newInstance(String className) {
return ReflectionUtils.newInstance(className);
}
Elsewhere in ObjectConverterImpl, it will now invoke
this.newInstance(classDescriptor.getClassName());
every where that is previously invoked
ReflectionUtils.newInstance(classDescriptor.getClassName());
Now I can over-ride the newInstance method in MyObjectConverterImpl (which
subclasses ObjectConverterImpl). This allows me to construct objects for my
model using its Factory class.
--
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: Vote : Jukka as new new Graffito mentor
Thanks for your vote. Following the incubator discussion, it seems that the vote was necessary. Others are +1 (one missing vote : Oliver). Do we have to wait or can we accept now Jukka as mentor ? If yes, how Jukka can have an write access to the codebase. br Christophe On 9/18/06, David Sean Taylor [EMAIL PROTECTED] wrote: Christophe Lombart wrote: Dear Committers, Following the recent discussion in the general incubation mailing list (see [1] ), I would like to start a vote to nominate Jukka Zitting as new mentor for the Graffito project. Due to his activities in the Jackrabbit project (Chair developer) and his incubation experience with Jackrabbit, he will be a great help for our team. Jukka is also imply in the new JCR specification as a member of the expert group. As you can see in the mailing archive and in our jira issues, Jukka has already send us patches, comments and advises. So please, make a vote to nominate Jukka as a new Graffito mentor. Here is my vote : +1 +1
Re: Re: Vote : Jukka as new new Graffito mentor
Opps sorry. All votes are +1. Welcome to Jukka. Happy to see you in our team. I didn't know the ASF procedures in all details. So, what is the next step ? Christophe On 9/20/06, Oliver Kiessler [EMAIL PROTECTED] wrote: hi christophe, Others are +1 (one missing vote : Oliver). Do we have to wait or can we accept now Jukka as mentor ? If yes, how Jukka can have an write access to the codebase. I gave my vote three days ago. It's +1. regards, oliver -- Best regards, Christophe
Re: Re: Vote : Jukka as new new Graffito mentor
No problem for me. Thanks! On 9/20/06, Jukka Zitting [EMAIL PROTECTED] wrote: Hi, On 9/20/06, Christophe Lombart [EMAIL PROTECTED] wrote: Opps sorry. All votes are +1. Welcome to Jukka. Happy to see you in our team. I didn't know the ASF procedures in all details. So, what is the next step ? Thanks! I'll take the issue to the incubator mailing list and unless anyone says anything opposite, I'll add myself to the project records. I should already have commit access due to being a member of the Incubator PMC. BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development -- Best regards, Christophe
[jira] Assigned: (GRFT-96) Patch home page grammar
[ http://issues.apache.org/jira/browse/GRFT-96?page=all ] Christophe Lombart reassigned GRFT-96: -- Assignee: Christophe Lombart Patch home page grammar --- Key: GRFT-96 URL: http://issues.apache.org/jira/browse/GRFT-96 Project: Graffito Issue Type: Improvement Components: Documentation Affects Versions: 1.0-a1-dev Reporter: Philip Mark Donaghy Assigned To: Christophe Lombart Attachments: patch.txt Just some improvements to the way the home page reads. -- 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: (GRFT-97) Deployment documentation link and tidiness
[ http://issues.apache.org/jira/browse/GRFT-97?page=all ] Christophe Lombart reassigned GRFT-97: -- Assignee: Christophe Lombart Deployment documentation link and tidiness -- Key: GRFT-97 URL: http://issues.apache.org/jira/browse/GRFT-97 Project: Graffito Issue Type: Improvement Components: Documentation Affects Versions: 1.0-a1-dev Reporter: Philip Mark Donaghy Assigned To: Christophe Lombart Attachments: patch.txt Patch corrects a broken link and improves presentation. -- 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
