You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by François Cassistat <f...@maya-systems.com> on 2009/11/13 22:23:31 UTC
David's Model question : nt:unstructured and SNS
David's Model gives good advices and I already followed his suggestions.
However, there is something I don't understand. He says "Learn to love nt:unstructured (& friends) in development." (and I think he is right) and later, "Beware of Same Name Siblings (SNS)". But, in the documentation, nt:unstructured allows SNS.
Is there an easy way to disallow SNS other than defining a new node type and setting all new nodes in this type, so I can get ItemExistException on save to prevent SNS from happening?
Frank
Re: David's Model question : nt:unstructured and SNS
Posted by Guo Du <mr...@gmail.com>.
On Mon, Nov 16, 2009 at 12:49 PM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> Although that would be non-standard w.r.t JCR, I think such a "don't
> accept same-name siblings" configuration flag might be useful. It is
> relatively easy to end up with same-name siblings without really
> meaning to.
I don't think a system wide flag to disable SNS is possible. As there
are some system nodes in jcr:system come with same-name siblings.
A custom node definition could solve this problem by design, I
couldn't see the problem here.
-Guo
Re: David's Model question : nt:unstructured and SNS
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Nov 13, 2009 at 11:21 PM, Tobias Bocanegra <tr...@day.com> wrote:
> 2009/11/13 François Cassistat <f...@maya-systems.com>:
>> ...Is there an easy way to disallow SNS other than defining a new node type and setting all
> new nodes in this type, so I can get ItemExistException on save to prevent SNS
> from happening?
>
> unfortunately not an easy one like changing the configuration....
Although that would be non-standard w.r.t JCR, I think such a "don't
accept same-name siblings" configuration flag might be useful. It is
relatively easy to end up with same-name siblings without really
meaning to.
-Bertrand
Re: David's Model question : nt:unstructured and SNS
Posted by Ard Schrijvers <a....@onehippo.com>.
On Tue, Nov 17, 2009 at 1:10 PM, Rakesh Vidyadharan <ra...@sptci.com> wrote:
>
> On 17 Nov 2009, at 5:32:13 AM, Ard Schrijvers wrote:
>> I do not agree, and fortunately, mapping jcr nodes to simple java
>> objects which again can be accessed from jsp / freemarker / velocity
>> scripts feels much more natural to me, is quite easy: I do not want to
>> burden other developers with handling all the jcr stuff, catching all
>> the exceptions, handling defaults, writing complex queries (do you
>> really like to write search queries? It is part of the JCR API, but I
>> am glad I went through all that once, and made a simple java interface
>> for it (similar to jr-ocm, only targeted for large repositories
>> avoiding slow queries, and supporting more website convenient
>> searches, like multiple scoped kind of queries).
>
> I am using http://kenai.com/projects/jcrcms/sources/svn/content/trunk/src/app/com/sptci/cms/site/model/NodeBean.java?rev=17 - a simple generic map wrapper around a node that can be used for tempting systems easily. Not final yet, but it works.
I would recommend to add some ObjectConverter capable of mapping
primary nodetypes to certain beans. Then, your NodeBean could be
something like the base fallback bean. With generics you can then add
methods to your base bean like below. You could take a look at [1].
Regards Ard
[1] http://svn.hippocms.org/repos/hippo/ecm/site-toolkit/trunk/content-beans/src/main/java/org/hippoecm/hst/content/beans/
public <T> T getBean(String relPath, Class<T> beanMappingClass) {
try {
Object o = this.objectConverter.getObject(node, relPath);
if(o == null) {
log.debug("Cannot get bean for relpath {} for current
bean {}.", relPath, this.getPath());
return null;
}
if(!beanMappingClass.isAssignableFrom(o.getClass())) {
log.debug("Expected bean of type '{}' but found of
type '{}'. Return null.", beanMappingClass.getName(),
o.getClass().getName());
return null;
}
return (T)o;
}
catch (ObjectBeanManagerException e) {
log.warn("Cannot get Object at relPath '{}' for '{}'",
relPath, this.getPath());
}
return null;
}
>
> Rakesh
Re: David's Model question : nt:unstructured and SNS
Posted by Rakesh Vidyadharan <ra...@sptci.com>.
On 17 Nov 2009, at 5:32:13 AM, Ard Schrijvers wrote:
> I do not agree, and fortunately, mapping jcr nodes to simple java
> objects which again can be accessed from jsp / freemarker / velocity
> scripts feels much more natural to me, is quite easy: I do not want to
> burden other developers with handling all the jcr stuff, catching all
> the exceptions, handling defaults, writing complex queries (do you
> really like to write search queries? It is part of the JCR API, but I
> am glad I went through all that once, and made a simple java interface
> for it (similar to jr-ocm, only targeted for large repositories
> avoiding slow queries, and supporting more website convenient
> searches, like multiple scoped kind of queries).
I am using http://kenai.com/projects/jcrcms/sources/svn/content/trunk/src/app/com/sptci/cms/site/model/NodeBean.java?rev=17 - a simple generic map wrapper around a node that can be used for tempting systems easily. Not final yet, but it works.
Rakesh
Re: David's Model question : nt:unstructured and SNS
Posted by Ard Schrijvers <a....@onehippo.com>.
Hello Bertrand,
On Mon, Nov 16, 2009 at 10:15 PM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> Hi Ard,
>
> On Mon, Nov 16, 2009 at 2:39 PM, Ard Schrijvers
> <a....@onehippo.com> wrote:
>> ...Just wondering: where does jackrabbit-ocm fit in then? I do not have
>> that much experience with it, but it feels like JCR-to-object to me.
>> Only use it when your really really have to :-)))?...
>
> Actually...yes and no.
>
> After rereading this thread I'd say something like "if you're coming
> from a relational world where object-to-DB mapping is the norm, think
> twice before using it in the JCR world. You might not need it, as the
> JCR API is much closer to what you need at the content application
> level".
I do not agree, and fortunately, mapping jcr nodes to simple java
objects which again can be accessed from jsp / freemarker / velocity
scripts feels much more natural to me, is quite easy: I do not want to
burden other developers with handling all the jcr stuff, catching all
the exceptions, handling defaults, writing complex queries (do you
really like to write search queries? It is part of the JCR API, but I
am glad I went through all that once, and made a simple java interface
for it (similar to jr-ocm, only targeted for large repositories
avoiding slow queries, and supporting more website convenient
searches, like multiple scoped kind of queries).
Anyways, I think it is just a matter of taste. I mainly just do not
agree to add it to David's rules to avoid jcr-to-object. I encourage
developers to avoid direct jcr calls in our environment :-))
Regards Ard
> -Bertrand
>
Re: David's Model question : nt:unstructured and SNS
Posted by Fabián Mandelbaum <fm...@gmail.com>.
wow! What a healthy discussion I've fired! :-)
My use of DAO (as in DATA Access Object) is to abstract the (granted,
small, *but* only when you've got used to it) complexities of JCR API
to to-be users of my storage (store, retrieve, findByXXX, etc.)
classes while controlling the properties the nt:unstructured nodes of
my system can have.
It's not (at least in my case) used as a DB replacement, nor with any
OCM tools, just a plain store(FilePlusMetadata myObject) kind of
thing, where FilePlusMetadata has both the file to store and the
properties I want to store about it, there's no room for a potential
developer (re)using storage to be able to store other properties
appart from the ones I'm interested into.
I also think that JCR is suited as an OCM solution... or else don't
just ask to add another rule to David's Model, ask also to remove the
OCM-related packages/API (please don't! I'm sure many users use 'em
;))
Thanks
On Mon, Nov 16, 2009 at 6:15 PM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> Hi Ard,
>
> On Mon, Nov 16, 2009 at 2:39 PM, Ard Schrijvers
> <a....@onehippo.com> wrote:
>> ...Just wondering: where does jackrabbit-ocm fit in then? I do not have
>> that much experience with it, but it feels like JCR-to-object to me.
>> Only use it when your really really have to :-)))?...
>
> Actually...yes and no.
>
> After rereading this thread I'd say something like "if you're coming
> from a relational world where object-to-DB mapping is the norm, think
> twice before using it in the JCR world. You might not need it, as the
> JCR API is much closer to what you need at the content application
> level".
>
> -Bertrand
>
--
Fabián Mandelbaum
IS Engineer
Re: David's Model question : nt:unstructured and SNS
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Ard,
On Mon, Nov 16, 2009 at 2:39 PM, Ard Schrijvers
<a....@onehippo.com> wrote:
> ...Just wondering: where does jackrabbit-ocm fit in then? I do not have
> that much experience with it, but it feels like JCR-to-object to me.
> Only use it when your really really have to :-)))?...
Actually...yes and no.
After rereading this thread I'd say something like "if you're coming
from a relational world where object-to-DB mapping is the norm, think
twice before using it in the JCR world. You might not need it, as the
JCR API is much closer to what you need at the content application
level".
-Bertrand
Re: David's Model question : nt:unstructured and SNS
Posted by Ard Schrijvers <a....@onehippo.com>.
On Mon, Nov 16, 2009 at 1:50 PM, Alexander Klimetschek <ak...@day.com> wrote:
> On Mon, Nov 16, 2009 at 13:47, Bertrand Delacretaz
> <bd...@apache.org> wrote:
>> Maybe David's model [1] needs Rule #8: don't use JCR-to-object
>> mappings unless you really really have to ;-)
I think it just depends on your what your used to. I guess this is
coming from a Sling pov, right ;-)
>
> He he, right. @David, what do you think? ;-)
Just wondering: where does jackrabbit-ocm fit in then? I do not have
that much experience with it, but it feels like JCR-to-object to me.
Only use it when your really really have to :-)))?
Regards Ard
>
> Regards,
> Alex
>
> --
> Alexander Klimetschek
> alexander.klimetschek@day.com
>
Re: Item not found exception for root node
Posted by Alexander Klimetschek <ak...@day.com>.
On Mon, Nov 16, 2009 at 22:35, Phukan, Anit <An...@intuit.com> wrote:
> I get this jcr exception while running tests on my application now :
> ...
> Caused by: javax.jcr.ItemNotFoundException:
> cafebabe-cafe-babe-cafe-babecafebabe
> at
> org.apache.jackrabbit.core.ItemManager.createItemInstance(ItemManager.ja
> va:463)
> at
> org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:319)
> at
> org.apache.jackrabbit.core.ItemManager.getRootNode(ItemManager.java:280)
> at
> org.apache.jackrabbit.core.SessionImpl.getRootNode(SessionImpl.java:750)
>
>
> Is it because my repository got corrupted possibly? I am not able to
> access even the root node now. It was working fine for me till this
> morning with the same code.
Are there any other exceptions listed lower in the stack trace as root cause?
cafebabe-cafe-babe-cafe-babecafebabe is the fixed uuid for the root
node - not finding it means there is something broken at the
persistence manager level. Maybe an I/O, disk or network problem.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Item not found exception for root node
Posted by "Phukan, Anit" <An...@intuit.com>.
Hi,
Could someone provide some insight.....
I get this jcr exception while running tests on my application now :
Exception in thread "main" javax.xml.ws.soap.SOAPFaultException:
javax.jcr.ItemNotFoundException: cafebabe-cafe-babe-cafe-babecafebabe
at
com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fau
lt.java:178)
at
com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFault
Builder.java:119)
at
com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHa
ndler.java:108)
at
com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHa
ndler.java:78)
at
com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107)
Caused by: javax.jcr.ItemNotFoundException:
cafebabe-cafe-babe-cafe-babecafebabe
at
org.apache.jackrabbit.core.ItemManager.createItemInstance(ItemManager.ja
va:463)
at
org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:319)
at
org.apache.jackrabbit.core.ItemManager.getRootNode(ItemManager.java:280)
at
org.apache.jackrabbit.core.SessionImpl.getRootNode(SessionImpl.java:750)
Is it because my repository got corrupted possibly? I am not able to
access even the root node now. It was working fine for me till this
morning with the same code.
Thanks
Anit
-----Original Message-----
From: Alexander Klimetschek [mailto:aklimets@day.com]
Sent: Monday, November 16, 2009 12:34 PM
To: users@jackrabbit.apache.org
Subject: Re: David's Model question : nt:unstructured and SNS
On Mon, Nov 16, 2009 at 13:50, Alexander Klimetschek <ak...@day.com>
wrote:
> On Mon, Nov 16, 2009 at 13:47, Bertrand Delacretaz
> <bd...@apache.org> wrote:
>> Maybe David's model [1] needs Rule #8: don't use JCR-to-object
>> mappings unless you really really have to ;-)
>
> He he, right. @David, what do you think? ;-)
No, just kidding. That model should really stay focused on content
modeling, not application/development best practices.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: David's Model question : nt:unstructured and SNS
Posted by Alexander Klimetschek <ak...@day.com>.
On Mon, Nov 16, 2009 at 13:50, Alexander Klimetschek <ak...@day.com> wrote:
> On Mon, Nov 16, 2009 at 13:47, Bertrand Delacretaz
> <bd...@apache.org> wrote:
>> Maybe David's model [1] needs Rule #8: don't use JCR-to-object
>> mappings unless you really really have to ;-)
>
> He he, right. @David, what do you think? ;-)
No, just kidding. That model should really stay focused on content
modeling, not application/development best practices.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: David's Model question : nt:unstructured and SNS
Posted by Alexander Klimetschek <ak...@day.com>.
On Mon, Nov 16, 2009 at 13:47, Bertrand Delacretaz
<bd...@apache.org> wrote:
> Maybe David's model [1] needs Rule #8: don't use JCR-to-object
> mappings unless you really really have to ;-)
He he, right. @David, what do you think? ;-)
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: David's Model question : nt:unstructured and SNS
Posted by François Cassistat <f...@maya-systems.com>.
Sure ! :)
I think JCR is a great fit-all standard. And OCM can be a great RAD
tool (and this is why I started trying JackRabbit instead of SQL
databases). So let's use whatever best fits our needs.
But what's great with David's model is that, in its current form, it
seems to apply well to both cases.
Frank
Le 09-11-16 à 14:17, Bertrand Delacretaz a écrit :
> 2009/11/16 François Cassistat <f...@maya-systems.com>:
>> ...I see this from a RAD and object database perspective.
>>
>> OCM provides a sort of CRUD interface on objects. Defining an
>> object is
>> simple and fast, then you specify the location and begin using it.
>> No need
>> to worry about structures and everything. Maybe OCM have
>> limitations and is
>> not optimal, but software is written fast and easier to be changed.
>> This is
>> perfect for iterative development where changes are likely to be
>> asked...
>
> Thanks for sharing your point of view, and if that works for you we
> shouldn't say you're doing the wrong thing!
>
> I'm coming from a content management point of view where JCR fits very
> nicely in the picture as is, with (IMHO) no need for extra layers. But
> your example shows that depending on your environment and goals,
> there's space for OCM.
>
> -Bertrand
Re: David's Model question : nt:unstructured and SNS
Posted by Bertrand Delacretaz <bd...@apache.org>.
2009/11/16 François Cassistat <f...@maya-systems.com>:
> ...I see this from a RAD and object database perspective.
>
> OCM provides a sort of CRUD interface on objects. Defining an object is
> simple and fast, then you specify the location and begin using it. No need
> to worry about structures and everything. Maybe OCM have limitations and is
> not optimal, but software is written fast and easier to be changed. This is
> perfect for iterative development where changes are likely to be asked...
Thanks for sharing your point of view, and if that works for you we
shouldn't say you're doing the wrong thing!
I'm coming from a content management point of view where JCR fits very
nicely in the picture as is, with (IMHO) no need for extra layers. But
your example shows that depending on your environment and goals,
there's space for OCM.
-Bertrand
Re: David's Model question : nt:unstructured and SNS
Posted by François Cassistat <f...@maya-systems.com>.
Le 09-11-16 à 13:12, Alexander Klimetschek a écrit :
> 2009/11/16 François Cassistat <f...@maya-systems.com>:
>> I think JCR+OCM is perfect for rapid development.
>
> Please explain: why should adding a code layer be more rapid?
>
I see this from a RAD and object database perspective.
OCM provides a sort of CRUD interface on objects. Defining an object
is simple and fast, then you specify the location and begin using it.
No need to worry about structures and everything. Maybe OCM have
limitations and is not optimal, but software is written fast and
easier to be changed. This is perfect for iterative development where
changes are likely to be asked.
> I agree that the JCR layer might not cover all typical operations in
> convenient methods, but you can provide helper methods for that (eg.
> jackrabbit-jcr-commons) that make life easier but still only depend on
> the JCR API.
>
It is true, but for me, if you generalize helper methods to the
extreme, you get something that looks like OCM anyway. Maybe you can
make something as complex and more flexible, and this could be a great
thing.
>> The only complexity it
>> adds is on performances, I found the code to be more readable with
>> OCM.
>>
>> Maybe I do not have much experience with "low-level" JCR
>> programming, but
>> the problem with manipulating nodes is that you get all kind of
>> variables
>> which you never know how to name (parentNode, node, subNode[],
>> nodeToDelete,
>> newNode, etc.) and it becomes unreadable and when your code gets
>> bigger.
>
> I guess in most cases utility methods, as mentioned above, will solve
> this. In addition, suggesting you have a simple node = object mapping,
> I don't see why you shouldn't get the same "complexity" of variable
> names with your DAO entities. And nobody forces you to use "node" in
> the variable name. Using scripting, property access becomes even
> simpler (see Apache Sling, Javascript or the ValueMap from the sling
> api). Only in Java the "getProperty()" way of reading properties might
> be a bit cumbersome, but IMO nothing that is so bad that it should add
> a new layer, dependencies and more code:
>
> Node user = session.getRootNode().getNode("home/users/johndoe");
> user.getProperty("name").getString();
> ....
>
Yes, like I said, I lack experience manipulating nodes (before I tried
JCR, I was using active records on my projects).
The problems I have with naming nodes variables are :
- If I made utility methods, you don't know how what the node is, your
variable get named "nodeThing" generally.
- When using a non-general method, you should already have something
like an User object named user and you end up calling your node
userNode because you don't know how to make the name distinct and easy
to read.
Anyway, I just wanted to say that working with nodes add a certain
complexity on your code because the code itself does not represent
visually the tree's hierarchy since it is flatten (as could XSLT could
be, by example). If you are working with many nodes on different
location and doNotWantNamesToBeThatLong, this gave me readability
problems.
>> I found myObject.save() to be straightforward and clean.
>
> A problem with object.save() is often that you don't really know the
> scope of the session/transaction. Explicit handling is better, eg. in
> the context of webapps it's typically one session per request. JCR 2.0
> goes fully onto this and deprecates Item.save() (albeit still
> supported by Jackrabbit) and only allows a Session.save().
>
You are right.
A generalisation is never perfect, but when it fits for 95% of my
needs, I can afford making exception cases for the other 5%.
> Regards,
> Alex
>
> --
> Alexander Klimetschek
> alexander.klimetschek@day.com
François
Re: David's Model question : nt:unstructured and SNS
Posted by Alexander Klimetschek <ak...@day.com>.
2009/11/16 François Cassistat <f...@maya-systems.com>:
> I think JCR+OCM is perfect for rapid development.
Please explain: why should adding a code layer be more rapid?
I agree that the JCR layer might not cover all typical operations in
convenient methods, but you can provide helper methods for that (eg.
jackrabbit-jcr-commons) that make life easier but still only depend on
the JCR API.
> The only complexity it
> adds is on performances, I found the code to be more readable with OCM.
>
> Maybe I do not have much experience with "low-level" JCR programming, but
> the problem with manipulating nodes is that you get all kind of variables
> which you never know how to name (parentNode, node, subNode[], nodeToDelete,
> newNode, etc.) and it becomes unreadable and when your code gets bigger.
I guess in most cases utility methods, as mentioned above, will solve
this. In addition, suggesting you have a simple node = object mapping,
I don't see why you shouldn't get the same "complexity" of variable
names with your DAO entities. And nobody forces you to use "node" in
the variable name. Using scripting, property access becomes even
simpler (see Apache Sling, Javascript or the ValueMap from the sling
api). Only in Java the "getProperty()" way of reading properties might
be a bit cumbersome, but IMO nothing that is so bad that it should add
a new layer, dependencies and more code:
Node user = session.getRootNode().getNode("home/users/johndoe");
user.getProperty("name").getString();
....
> I found myObject.save() to be straightforward and clean.
A problem with object.save() is often that you don't really know the
scope of the session/transaction. Explicit handling is better, eg. in
the context of webapps it's typically one session per request. JCR 2.0
goes fully onto this and deprecates Item.save() (albeit still
supported by Jackrabbit) and only allows a Session.save().
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: David's Model question : nt:unstructured and SNS
Posted by François Cassistat <f...@maya-systems.com>.
Le 09-11-16 à 07:47, Bertrand Delacretaz a écrit :
> On Mon, Nov 16, 2009 at 1:38 PM, Alexander Klimetschek <aklimets@day.com
> > wrote:
>> ...I see the point for DAOs only when you really want to be sure that
>> application coders can only use the properties you designed for them.
>> Or when you have a relational model and are required to map it onto
>> an
>> object model, but that's not the case with JCR. An OCM only adds an
>> additional layer of code and complexity....
>
> +1
>
> Maybe David's model [1] needs Rule #8: don't use JCR-to-object
> mappings unless you really really have to ;-)
>
I would not agree on this one. I found JCR very pertinent as a
replacement for Object databases. I am mixing the two concepts to fit
all my needs.
I think JCR+OCM is perfect for rapid development. The only complexity
it adds is on performances, I found the code to be more readable with
OCM.
Maybe I do not have much experience with "low-level" JCR programming,
but the problem with manipulating nodes is that you get all kind of
variables which you never know how to name (parentNode, node,
subNode[], nodeToDelete, newNode, etc.) and it becomes unreadable and
when your code gets bigger. I found myObject.save() to be
straightforward and clean.
> -Bertrand
>
> [1] http://wiki.apache.org/jackrabbit/DavidsModel
Re: David's Model question : nt:unstructured and SNS
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, Nov 16, 2009 at 1:38 PM, Alexander Klimetschek <ak...@day.com> wrote:
> ...I see the point for DAOs only when you really want to be sure that
> application coders can only use the properties you designed for them.
> Or when you have a relational model and are required to map it onto an
> object model, but that's not the case with JCR. An OCM only adds an
> additional layer of code and complexity....
+1
Maybe David's model [1] needs Rule #8: don't use JCR-to-object
mappings unless you really really have to ;-)
-Bertrand
[1] http://wiki.apache.org/jackrabbit/DavidsModel
Re: IndexWriter lucene exception
Posted by Thomas Müller <th...@day.com>.
Hi,
The table already exists:
> Caused by: java.sql.SQLException: There is already an object named 'J_PM_DEFAULT_REFS' in the database.
Could you provide more details as described at
http://wiki.apache.org/jackrabbit/QuestionsAndAnswers "Reporting
Problems"?
Regards,
Thomas
On Wed, Nov 18, 2009 at 2:06 AM, Phukan, Anit <An...@intuit.com> wrote:
> Did anyone get the following type of exception while trying to use org.apache.jackrabbit.core.persistence.bundle.MSSqlPersistenceManager with jndi lookup for datasource.
>
>
> javax.jcr.RepositoryException: Cannot instantiate persistence manager org.apache.jackrabbit.core.persistence.bundle.MSSqlPersistenceManager: Schema generation error: Issuing statement: create table J_PM_DEFAULT_REFS (NODE_ID binary(16) not null, REFS_DATA image not null) : Schema generation error: Issuing statement: create table J_PM_DEFAULT_REFS (NODE_ID binary(16) not null, REFS_DATA image not null)
> at org.apache.jackrabbit.core.RepositoryImpl.createPersistenceManager(RepositoryImpl.java:1292)
> at org.apache.jackrabbit.core.RepositoryImpl.access$800(RepositoryImpl.java:109)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>
> Caused by: java.sql.SQLException: Schema generation error: Issuing statement: create table J_PM_DEFAULT_REFS (NODE_ID binary(16) not null, REFS_DATA image not null)
> at org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager.checkSchema(BundleDbPersistenceManager.java:449)
> at org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager.init(BundleDbPersistenceManager.java:565)
> at org.apache.jackrabbit.core.RepositoryImpl.createPersistenceManager(RepositoryImpl.java:1288)
> ... 46 more
> Caused by: java.sql.SQLException: There is already an object named 'J_PM_DEFAULT_REFS' in the database.
> at net.sourceforge.jtds.jdbc.SQLDiagnostic.addDiagnostic(SQLDiagnostic.java:365)
> at net.sourceforge.jtds.jdbc.TdsCore.tdsErrorToken(TdsCore.java:2781)
> at net.sourceforge.jtds.jdbc.TdsCore.nextToken(TdsCore.java:2224)
> at net.sourceforge.jtds.jdbc.TdsCore.getMoreResults(TdsCore.java:628)
> at net.sourceforge.jtds.jdbc.JtdsStatement.processResults(JtdsStatement.java:525)
> at net.sourceforge.jtds.jdbc.JtdsStatement.executeSQL(JtdsStatement.java:487)
> at net.sourceforge.jtds.jdbc.JtdsStatement.executeImpl(JtdsStatement.java:664)
> at net.sourceforge.jtds.jdbc.JtdsStatement.executeUpdate(JtdsStatement.java:1120)
> at net.sourceforge.jtds.jdbc.JtdsStatement.executeUpdate(JtdsStatement.java:1073)
> at org.jboss.resource.adapter.jdbc.WrappedStatement.executeUpdate(WrappedStatement.java:249)
> at org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager.checkSchema(BundleDbPersistenceManager.java:438)
>
> Any advice would be appreciated.
>
> Thanks
> Anit
>
> -----Original Message-----
> From: Phukan, Anit [mailto:Anit_Phukan@intuit.com]
> Sent: Tuesday, November 17, 2009 3:54 PM
> To: Dave Brosius; users@jackrabbit.apache.org
> Subject: RE: IndexWriter lucene exception
>
> Thanks Dave,
>
>
>
> I was able to move ahead after including dependency for lucene_core version 2.4.1.
>
>
>
> Now I am getting a different JAAS related error while trying to do a simple login to the started repository. I am just using the SimpleLoginLodule of jackrabbit in LoginModule of security config.
>
>
>
> 15:52:14,595 INFO [RepositoryImpl] SecurityManager = class org.apache.jackrabbit.core.security.simple.SimpleSecurityManager
>
> 15:52:15,017 ERROR [UsersRolesLoginModule] Failed to load users/passwords/role files
>
> java.io.IOException: No properties file: users.properties or defaults: defaultUsers.properties found
>
> at org.jboss.security.auth.spi.Util.loadProperties(Util.java:198)
>
> at org.jboss.security.auth.spi.UsersRolesLoginModule.loadUsers(UsersRolesLoginModule.java:186)
>
> at org.jboss.security.auth.spi.UsersRolesLoginModule.createUsers(UsersRolesLoginModule.java:200)
>
> at org.jboss.security.auth.spi.UsersRolesLoginModule.initialize(UsersRolesLoginModule.java:127)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
>
>
> Regards
>
> Anit
>
>
>
> ________________________________
>
> From: Dave Brosius [mailto:dbrosius@mebigfatguy.com]
> Sent: Tuesday, November 17, 2009 3:49 PM
> To: users@jackrabbit.apache.org
> Cc: Phukan, Anit
> Subject: RE: IndexWriter lucene exception
>
>
>
> The closest thing to that constructor in 1.4.3 is
>
> public IndexWriter(Directory d, Analyzer a, boolean create)
>
> http://svn.apache.org/viewvc/lucene/java/tags/lucene_1_4_3/src/java/org/apache/lucene/index/IndexWriter.java?revision=150679&view=markup
>
> looks like you need version 2.1.0 at a minimum
>
> http://svn.apache.org/viewvc/lucene/java/tags/lucene_2_1_0/src/java/org/apache/lucene/index/IndexWriter.java?revision=507623&view=markup
>
>
> -----Original Message-----
> From: "Phukan, Anit" <An...@intuit.com>
> Sent: Tuesday, November 17, 2009 5:54pm
> To: users@jackrabbit.apache.org
> Subject: IndexWriter lucene exception
>
> Hi,
>
> Did anyone encounter this type of error while starting up the repository? I am using lucene version 1.4.3 and jackrabbit-core version 1.5.5. Could it be because I am using out of sync jars for these two?
>
>
> java.lang.NoSuchMethodError: org.apache.lucene.index.IndexWriter.<init>(Lorg/apache/lucene/store/Directory;Lorg/apache/lucene/analysis/Analyzer;)V
> at org.apache.jackrabbit.core.query.lucene.AbstractIndex.<init>(AbstractIndex.java:145)
> at org.apache.jackrabbit.core.query.lucene.VolatileIndex.<init>(VolatileIndex.java:65)
> at org.apache.jackrabbit.core.query.lucene.MultiIndex.resetVolatileIndex(MultiIndex.java:952)
> at org.apache.jackrabbit.core.query.lucene.MultiIndex.<init>(MultiIndex.java:298)
> at org.apache.jackrabbit.core.query.lucene.SearchIndex.doInit(SearchIndex.java:456)
> at org.apache.jackrabbit.core.query.AbstractQueryHandler.init(AbstractQueryHandler.java:59)
> at org.apache.jackrabbit.core.SearchManager.initializeQueryHandler(SearchManager.java:553)
> at org.apache.jackrabbit.core.SearchManager.<init>(SearchManager.java:239)
> at org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.getSearchManager(RepositoryImpl.java:1723)
> at org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.doPostInitialize(RepositoryImpl.java:1923)
> at org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.initialize(RepositoryImpl.java:1836)
> at org.apache.jackrabbit.core.RepositoryImpl.initStartupWorkspaces(RepositoryImpl.java:483)
> at org.apache.jackrabbit.core.RepositoryImpl.<init>(RepositoryImpl.java:324)
> at org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:621)
> at org.apache.jackrabbit.core.jndi.BindableRepository.createRepository(BindableRepository.java:140)
> at org.apache.jackrabbit.core.jndi.BindableRepository.init(BindableRepository.java:116)
> at org.apache.jackrabbit.core.jndi.BindableRepository.<init>(BindableRepository.java:105)
> at org.apache.jackrabbit.core.jndi.BindableRepositoryFactory.getObjectInstance(BindableRepositoryFactory.java:51)
> at org.apache.jackrabbit.core.jndi.RegistryHelper.registerRepository(RegistryHelper.java:74)
>
>
> Thanks
> Anit
>
> -----Original Message-----
> From: Janne Jalkanen [mailto:janne.jalkanen@ecyrd.com]
> Sent: Tuesday, November 17, 2009 1:12 PM
> To: users@jackrabbit.apache.org
> Subject: Re: David's Model question : nt:unstructured and SNS
>
>
> On 17 Nov 2009, at 14:50, Sandro Boehme wrote:
>
>> Alexander Klimetschek schrieb:
>>> 2009/11/16 Fabián Mandelbaum <fm...@gmail.com>:
>>>> It's simpler than fiddling around with this low-level stuff actually:
>>>>
>>>> Just create a DAO to abstract all JCR operations (as you should be
>>>> doing already)
>>> (To give my usual opinion about object content mapping and JCR:) If
>>> you use DAOs this of course is a straight-forward solution (but only
>>> for the code that uses the DAO layer), but I think that using JCR
>>> directly is not "low-level" stuff:
>> In my opinion an OCM adds statical type checking and the ability to add functionality (e.g. finder methods) to this types.
>
> JSPWiki uses a layer on top of JCR to
> a) provide type/range checking for some values, and
> b) to provide backwards API compatibility.
>
> /Janne
>
>
Re: IndexWriter lucene exception
Posted by Lars Michele <la...@tu-dortmund.de>.
Hi.
> Can someone tell me why I am getting this error with jackrabbit 1.6 for the JAAS login module even though I am disabling the securitymanager option.
>
Because jackrabbit is like any other webapp secured in JBoss with a
default security config. Have a look at login-config.xml
(<application-policy name="other">).
More details on securing a webapp in JBoss:
http://www.jboss.org/community/wiki/SecureAWebApplicationInJBoss
Regards,
Lars
> INFO [RepositoryImpl] SecurityManager = class org.apache.jackrabbit.core.security.simple.SimpleSecurityManager
> 16:12:17,113 ERROR [UsersRolesLoginModule] Failed to load users/passwords/role files
> java.io.IOException: No properties file: users.properties or defaults: defaultUsers.properties found
> at org.jboss.security.auth.spi.Util.loadProperties(Util.java:198)
> at org.jboss.security.auth.spi.UsersRolesLoginModule.loadUsers(UsersRolesLoginModule.java:186)
> at org.jboss.security.auth.spi.UsersRolesLoginModule.createUsers(UsersRolesLoginModule.java:200)
> at org.jboss.security.auth.spi.UsersRolesLoginModule.initialize(UsersRolesLoginModule.java:127)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
>
>
> Thanks
>
> Anit
RE: IndexWriter lucene exception
Posted by "Phukan, Anit" <An...@intuit.com>.
Hi,
Can someone tell me why I am getting this error with jackrabbit 1.6 for the JAAS login module even though I am disabling the securitymanager option.
INFO [RepositoryImpl] SecurityManager = class org.apache.jackrabbit.core.security.simple.SimpleSecurityManager
16:12:17,113 ERROR [UsersRolesLoginModule] Failed to load users/passwords/role files
java.io.IOException: No properties file: users.properties or defaults: defaultUsers.properties found
at org.jboss.security.auth.spi.Util.loadProperties(Util.java:198)
at org.jboss.security.auth.spi.UsersRolesLoginModule.loadUsers(UsersRolesLoginModule.java:186)
at org.jboss.security.auth.spi.UsersRolesLoginModule.createUsers(UsersRolesLoginModule.java:200)
at org.jboss.security.auth.spi.UsersRolesLoginModule.initialize(UsersRolesLoginModule.java:127)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
Thanks
Anit
-----Original Message-----
From: Phukan, Anit [mailto:Anit_Phukan@intuit.com]
Sent: Tuesday, November 17, 2009 5:07 PM
To: users@jackrabbit.apache.org
Subject: RE: IndexWriter lucene exception
Did anyone get the following type of exception while trying to use org.apache.jackrabbit.core.persistence.bundle.MSSqlPersistenceManager with jndi lookup for datasource.
javax.jcr.RepositoryException: Cannot instantiate persistence manager org.apache.jackrabbit.core.persistence.bundle.MSSqlPersistenceManager: Schema generation error: Issuing statement: create table J_PM_DEFAULT_REFS (NODE_ID binary(16) not null, REFS_DATA image not null) : Schema generation error: Issuing statement: create table J_PM_DEFAULT_REFS (NODE_ID binary(16) not null, REFS_DATA image not null)
at org.apache.jackrabbit.core.RepositoryImpl.createPersistenceManager(RepositoryImpl.java:1292)
at org.apache.jackrabbit.core.RepositoryImpl.access$800(RepositoryImpl.java:109)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
Caused by: java.sql.SQLException: Schema generation error: Issuing statement: create table J_PM_DEFAULT_REFS (NODE_ID binary(16) not null, REFS_DATA image not null)
at org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager.checkSchema(BundleDbPersistenceManager.java:449)
at org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager.init(BundleDbPersistenceManager.java:565)
at org.apache.jackrabbit.core.RepositoryImpl.createPersistenceManager(RepositoryImpl.java:1288)
... 46 more
Caused by: java.sql.SQLException: There is already an object named 'J_PM_DEFAULT_REFS' in the database.
at net.sourceforge.jtds.jdbc.SQLDiagnostic.addDiagnostic(SQLDiagnostic.java:365)
at net.sourceforge.jtds.jdbc.TdsCore.tdsErrorToken(TdsCore.java:2781)
at net.sourceforge.jtds.jdbc.TdsCore.nextToken(TdsCore.java:2224)
at net.sourceforge.jtds.jdbc.TdsCore.getMoreResults(TdsCore.java:628)
at net.sourceforge.jtds.jdbc.JtdsStatement.processResults(JtdsStatement.java:525)
at net.sourceforge.jtds.jdbc.JtdsStatement.executeSQL(JtdsStatement.java:487)
at net.sourceforge.jtds.jdbc.JtdsStatement.executeImpl(JtdsStatement.java:664)
at net.sourceforge.jtds.jdbc.JtdsStatement.executeUpdate(JtdsStatement.java:1120)
at net.sourceforge.jtds.jdbc.JtdsStatement.executeUpdate(JtdsStatement.java:1073)
at org.jboss.resource.adapter.jdbc.WrappedStatement.executeUpdate(WrappedStatement.java:249)
at org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager.checkSchema(BundleDbPersistenceManager.java:438)
Any advice would be appreciated.
Thanks
Anit
-----Original Message-----
From: Phukan, Anit [mailto:Anit_Phukan@intuit.com]
Sent: Tuesday, November 17, 2009 3:54 PM
To: Dave Brosius; users@jackrabbit.apache.org
Subject: RE: IndexWriter lucene exception
Thanks Dave,
I was able to move ahead after including dependency for lucene_core version 2.4.1.
Now I am getting a different JAAS related error while trying to do a simple login to the started repository. I am just using the SimpleLoginLodule of jackrabbit in LoginModule of security config.
15:52:14,595 INFO [RepositoryImpl] SecurityManager = class org.apache.jackrabbit.core.security.simple.SimpleSecurityManager
15:52:15,017 ERROR [UsersRolesLoginModule] Failed to load users/passwords/role files
java.io.IOException: No properties file: users.properties or defaults: defaultUsers.properties found
at org.jboss.security.auth.spi.Util.loadProperties(Util.java:198)
at org.jboss.security.auth.spi.UsersRolesLoginModule.loadUsers(UsersRolesLoginModule.java:186)
at org.jboss.security.auth.spi.UsersRolesLoginModule.createUsers(UsersRolesLoginModule.java:200)
at org.jboss.security.auth.spi.UsersRolesLoginModule.initialize(UsersRolesLoginModule.java:127)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Regards
Anit
________________________________
From: Dave Brosius [mailto:dbrosius@mebigfatguy.com]
Sent: Tuesday, November 17, 2009 3:49 PM
To: users@jackrabbit.apache.org
Cc: Phukan, Anit
Subject: RE: IndexWriter lucene exception
The closest thing to that constructor in 1.4.3 is
public IndexWriter(Directory d, Analyzer a, boolean create)
http://svn.apache.org/viewvc/lucene/java/tags/lucene_1_4_3/src/java/org/apache/lucene/index/IndexWriter.java?revision=150679&view=markup
looks like you need version 2.1.0 at a minimum
http://svn.apache.org/viewvc/lucene/java/tags/lucene_2_1_0/src/java/org/apache/lucene/index/IndexWriter.java?revision=507623&view=markup
-----Original Message-----
From: "Phukan, Anit" <An...@intuit.com>
Sent: Tuesday, November 17, 2009 5:54pm
To: users@jackrabbit.apache.org
Subject: IndexWriter lucene exception
Hi,
Did anyone encounter this type of error while starting up the repository? I am using lucene version 1.4.3 and jackrabbit-core version 1.5.5. Could it be because I am using out of sync jars for these two?
java.lang.NoSuchMethodError: org.apache.lucene.index.IndexWriter.<init>(Lorg/apache/lucene/store/Directory;Lorg/apache/lucene/analysis/Analyzer;)V
at org.apache.jackrabbit.core.query.lucene.AbstractIndex.<init>(AbstractIndex.java:145)
at org.apache.jackrabbit.core.query.lucene.VolatileIndex.<init>(VolatileIndex.java:65)
at org.apache.jackrabbit.core.query.lucene.MultiIndex.resetVolatileIndex(MultiIndex.java:952)
at org.apache.jackrabbit.core.query.lucene.MultiIndex.<init>(MultiIndex.java:298)
at org.apache.jackrabbit.core.query.lucene.SearchIndex.doInit(SearchIndex.java:456)
at org.apache.jackrabbit.core.query.AbstractQueryHandler.init(AbstractQueryHandler.java:59)
at org.apache.jackrabbit.core.SearchManager.initializeQueryHandler(SearchManager.java:553)
at org.apache.jackrabbit.core.SearchManager.<init>(SearchManager.java:239)
at org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.getSearchManager(RepositoryImpl.java:1723)
at org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.doPostInitialize(RepositoryImpl.java:1923)
at org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.initialize(RepositoryImpl.java:1836)
at org.apache.jackrabbit.core.RepositoryImpl.initStartupWorkspaces(RepositoryImpl.java:483)
at org.apache.jackrabbit.core.RepositoryImpl.<init>(RepositoryImpl.java:324)
at org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:621)
at org.apache.jackrabbit.core.jndi.BindableRepository.createRepository(BindableRepository.java:140)
at org.apache.jackrabbit.core.jndi.BindableRepository.init(BindableRepository.java:116)
at org.apache.jackrabbit.core.jndi.BindableRepository.<init>(BindableRepository.java:105)
at org.apache.jackrabbit.core.jndi.BindableRepositoryFactory.getObjectInstance(BindableRepositoryFactory.java:51)
at org.apache.jackrabbit.core.jndi.RegistryHelper.registerRepository(RegistryHelper.java:74)
Thanks
Anit
-----Original Message-----
From: Janne Jalkanen [mailto:janne.jalkanen@ecyrd.com]
Sent: Tuesday, November 17, 2009 1:12 PM
To: users@jackrabbit.apache.org
Subject: Re: David's Model question : nt:unstructured and SNS
On 17 Nov 2009, at 14:50, Sandro Boehme wrote:
> Alexander Klimetschek schrieb:
>> 2009/11/16 Fabián Mandelbaum <fm...@gmail.com>:
>>> It's simpler than fiddling around with this low-level stuff actually:
>>>
>>> Just create a DAO to abstract all JCR operations (as you should be
>>> doing already)
>> (To give my usual opinion about object content mapping and JCR:) If
>> you use DAOs this of course is a straight-forward solution (but only
>> for the code that uses the DAO layer), but I think that using JCR
>> directly is not "low-level" stuff:
> In my opinion an OCM adds statical type checking and the ability to add functionality (e.g. finder methods) to this types.
JSPWiki uses a layer on top of JCR to
a) provide type/range checking for some values, and
b) to provide backwards API compatibility.
/Janne
RE: IndexWriter lucene exception
Posted by "Phukan, Anit" <An...@intuit.com>.
Did anyone get the following type of exception while trying to use org.apache.jackrabbit.core.persistence.bundle.MSSqlPersistenceManager with jndi lookup for datasource.
javax.jcr.RepositoryException: Cannot instantiate persistence manager org.apache.jackrabbit.core.persistence.bundle.MSSqlPersistenceManager: Schema generation error: Issuing statement: create table J_PM_DEFAULT_REFS (NODE_ID binary(16) not null, REFS_DATA image not null) : Schema generation error: Issuing statement: create table J_PM_DEFAULT_REFS (NODE_ID binary(16) not null, REFS_DATA image not null)
at org.apache.jackrabbit.core.RepositoryImpl.createPersistenceManager(RepositoryImpl.java:1292)
at org.apache.jackrabbit.core.RepositoryImpl.access$800(RepositoryImpl.java:109)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
Caused by: java.sql.SQLException: Schema generation error: Issuing statement: create table J_PM_DEFAULT_REFS (NODE_ID binary(16) not null, REFS_DATA image not null)
at org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager.checkSchema(BundleDbPersistenceManager.java:449)
at org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager.init(BundleDbPersistenceManager.java:565)
at org.apache.jackrabbit.core.RepositoryImpl.createPersistenceManager(RepositoryImpl.java:1288)
... 46 more
Caused by: java.sql.SQLException: There is already an object named 'J_PM_DEFAULT_REFS' in the database.
at net.sourceforge.jtds.jdbc.SQLDiagnostic.addDiagnostic(SQLDiagnostic.java:365)
at net.sourceforge.jtds.jdbc.TdsCore.tdsErrorToken(TdsCore.java:2781)
at net.sourceforge.jtds.jdbc.TdsCore.nextToken(TdsCore.java:2224)
at net.sourceforge.jtds.jdbc.TdsCore.getMoreResults(TdsCore.java:628)
at net.sourceforge.jtds.jdbc.JtdsStatement.processResults(JtdsStatement.java:525)
at net.sourceforge.jtds.jdbc.JtdsStatement.executeSQL(JtdsStatement.java:487)
at net.sourceforge.jtds.jdbc.JtdsStatement.executeImpl(JtdsStatement.java:664)
at net.sourceforge.jtds.jdbc.JtdsStatement.executeUpdate(JtdsStatement.java:1120)
at net.sourceforge.jtds.jdbc.JtdsStatement.executeUpdate(JtdsStatement.java:1073)
at org.jboss.resource.adapter.jdbc.WrappedStatement.executeUpdate(WrappedStatement.java:249)
at org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager.checkSchema(BundleDbPersistenceManager.java:438)
Any advice would be appreciated.
Thanks
Anit
-----Original Message-----
From: Phukan, Anit [mailto:Anit_Phukan@intuit.com]
Sent: Tuesday, November 17, 2009 3:54 PM
To: Dave Brosius; users@jackrabbit.apache.org
Subject: RE: IndexWriter lucene exception
Thanks Dave,
I was able to move ahead after including dependency for lucene_core version 2.4.1.
Now I am getting a different JAAS related error while trying to do a simple login to the started repository. I am just using the SimpleLoginLodule of jackrabbit in LoginModule of security config.
15:52:14,595 INFO [RepositoryImpl] SecurityManager = class org.apache.jackrabbit.core.security.simple.SimpleSecurityManager
15:52:15,017 ERROR [UsersRolesLoginModule] Failed to load users/passwords/role files
java.io.IOException: No properties file: users.properties or defaults: defaultUsers.properties found
at org.jboss.security.auth.spi.Util.loadProperties(Util.java:198)
at org.jboss.security.auth.spi.UsersRolesLoginModule.loadUsers(UsersRolesLoginModule.java:186)
at org.jboss.security.auth.spi.UsersRolesLoginModule.createUsers(UsersRolesLoginModule.java:200)
at org.jboss.security.auth.spi.UsersRolesLoginModule.initialize(UsersRolesLoginModule.java:127)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Regards
Anit
________________________________
From: Dave Brosius [mailto:dbrosius@mebigfatguy.com]
Sent: Tuesday, November 17, 2009 3:49 PM
To: users@jackrabbit.apache.org
Cc: Phukan, Anit
Subject: RE: IndexWriter lucene exception
The closest thing to that constructor in 1.4.3 is
public IndexWriter(Directory d, Analyzer a, boolean create)
http://svn.apache.org/viewvc/lucene/java/tags/lucene_1_4_3/src/java/org/apache/lucene/index/IndexWriter.java?revision=150679&view=markup
looks like you need version 2.1.0 at a minimum
http://svn.apache.org/viewvc/lucene/java/tags/lucene_2_1_0/src/java/org/apache/lucene/index/IndexWriter.java?revision=507623&view=markup
-----Original Message-----
From: "Phukan, Anit" <An...@intuit.com>
Sent: Tuesday, November 17, 2009 5:54pm
To: users@jackrabbit.apache.org
Subject: IndexWriter lucene exception
Hi,
Did anyone encounter this type of error while starting up the repository? I am using lucene version 1.4.3 and jackrabbit-core version 1.5.5. Could it be because I am using out of sync jars for these two?
java.lang.NoSuchMethodError: org.apache.lucene.index.IndexWriter.<init>(Lorg/apache/lucene/store/Directory;Lorg/apache/lucene/analysis/Analyzer;)V
at org.apache.jackrabbit.core.query.lucene.AbstractIndex.<init>(AbstractIndex.java:145)
at org.apache.jackrabbit.core.query.lucene.VolatileIndex.<init>(VolatileIndex.java:65)
at org.apache.jackrabbit.core.query.lucene.MultiIndex.resetVolatileIndex(MultiIndex.java:952)
at org.apache.jackrabbit.core.query.lucene.MultiIndex.<init>(MultiIndex.java:298)
at org.apache.jackrabbit.core.query.lucene.SearchIndex.doInit(SearchIndex.java:456)
at org.apache.jackrabbit.core.query.AbstractQueryHandler.init(AbstractQueryHandler.java:59)
at org.apache.jackrabbit.core.SearchManager.initializeQueryHandler(SearchManager.java:553)
at org.apache.jackrabbit.core.SearchManager.<init>(SearchManager.java:239)
at org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.getSearchManager(RepositoryImpl.java:1723)
at org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.doPostInitialize(RepositoryImpl.java:1923)
at org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.initialize(RepositoryImpl.java:1836)
at org.apache.jackrabbit.core.RepositoryImpl.initStartupWorkspaces(RepositoryImpl.java:483)
at org.apache.jackrabbit.core.RepositoryImpl.<init>(RepositoryImpl.java:324)
at org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:621)
at org.apache.jackrabbit.core.jndi.BindableRepository.createRepository(BindableRepository.java:140)
at org.apache.jackrabbit.core.jndi.BindableRepository.init(BindableRepository.java:116)
at org.apache.jackrabbit.core.jndi.BindableRepository.<init>(BindableRepository.java:105)
at org.apache.jackrabbit.core.jndi.BindableRepositoryFactory.getObjectInstance(BindableRepositoryFactory.java:51)
at org.apache.jackrabbit.core.jndi.RegistryHelper.registerRepository(RegistryHelper.java:74)
Thanks
Anit
-----Original Message-----
From: Janne Jalkanen [mailto:janne.jalkanen@ecyrd.com]
Sent: Tuesday, November 17, 2009 1:12 PM
To: users@jackrabbit.apache.org
Subject: Re: David's Model question : nt:unstructured and SNS
On 17 Nov 2009, at 14:50, Sandro Boehme wrote:
> Alexander Klimetschek schrieb:
>> 2009/11/16 Fabián Mandelbaum <fm...@gmail.com>:
>>> It's simpler than fiddling around with this low-level stuff actually:
>>>
>>> Just create a DAO to abstract all JCR operations (as you should be
>>> doing already)
>> (To give my usual opinion about object content mapping and JCR:) If
>> you use DAOs this of course is a straight-forward solution (but only
>> for the code that uses the DAO layer), but I think that using JCR
>> directly is not "low-level" stuff:
> In my opinion an OCM adds statical type checking and the ability to add functionality (e.g. finder methods) to this types.
JSPWiki uses a layer on top of JCR to
a) provide type/range checking for some values, and
b) to provide backwards API compatibility.
/Janne
RE: IndexWriter lucene exception
Posted by "Phukan, Anit" <An...@intuit.com>.
Thanks Dave,
I was able to move ahead after including dependency for lucene_core version 2.4.1.
Now I am getting a different JAAS related error while trying to do a simple login to the started repository. I am just using the SimpleLoginLodule of jackrabbit in LoginModule of security config.
15:52:14,595 INFO [RepositoryImpl] SecurityManager = class org.apache.jackrabbit.core.security.simple.SimpleSecurityManager
15:52:15,017 ERROR [UsersRolesLoginModule] Failed to load users/passwords/role files
java.io.IOException: No properties file: users.properties or defaults: defaultUsers.properties found
at org.jboss.security.auth.spi.Util.loadProperties(Util.java:198)
at org.jboss.security.auth.spi.UsersRolesLoginModule.loadUsers(UsersRolesLoginModule.java:186)
at org.jboss.security.auth.spi.UsersRolesLoginModule.createUsers(UsersRolesLoginModule.java:200)
at org.jboss.security.auth.spi.UsersRolesLoginModule.initialize(UsersRolesLoginModule.java:127)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Regards
Anit
________________________________
From: Dave Brosius [mailto:dbrosius@mebigfatguy.com]
Sent: Tuesday, November 17, 2009 3:49 PM
To: users@jackrabbit.apache.org
Cc: Phukan, Anit
Subject: RE: IndexWriter lucene exception
The closest thing to that constructor in 1.4.3 is
public IndexWriter(Directory d, Analyzer a, boolean create)
http://svn.apache.org/viewvc/lucene/java/tags/lucene_1_4_3/src/java/org/apache/lucene/index/IndexWriter.java?revision=150679&view=markup
looks like you need version 2.1.0 at a minimum
http://svn.apache.org/viewvc/lucene/java/tags/lucene_2_1_0/src/java/org/apache/lucene/index/IndexWriter.java?revision=507623&view=markup
-----Original Message-----
From: "Phukan, Anit" <An...@intuit.com>
Sent: Tuesday, November 17, 2009 5:54pm
To: users@jackrabbit.apache.org
Subject: IndexWriter lucene exception
Hi,
Did anyone encounter this type of error while starting up the repository? I am using lucene version 1.4.3 and jackrabbit-core version 1.5.5. Could it be because I am using out of sync jars for these two?
java.lang.NoSuchMethodError: org.apache.lucene.index.IndexWriter.<init>(Lorg/apache/lucene/store/Directory;Lorg/apache/lucene/analysis/Analyzer;)V
at org.apache.jackrabbit.core.query.lucene.AbstractIndex.<init>(AbstractIndex.java:145)
at org.apache.jackrabbit.core.query.lucene.VolatileIndex.<init>(VolatileIndex.java:65)
at org.apache.jackrabbit.core.query.lucene.MultiIndex.resetVolatileIndex(MultiIndex.java:952)
at org.apache.jackrabbit.core.query.lucene.MultiIndex.<init>(MultiIndex.java:298)
at org.apache.jackrabbit.core.query.lucene.SearchIndex.doInit(SearchIndex.java:456)
at org.apache.jackrabbit.core.query.AbstractQueryHandler.init(AbstractQueryHandler.java:59)
at org.apache.jackrabbit.core.SearchManager.initializeQueryHandler(SearchManager.java:553)
at org.apache.jackrabbit.core.SearchManager.<init>(SearchManager.java:239)
at org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.getSearchManager(RepositoryImpl.java:1723)
at org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.doPostInitialize(RepositoryImpl.java:1923)
at org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.initialize(RepositoryImpl.java:1836)
at org.apache.jackrabbit.core.RepositoryImpl.initStartupWorkspaces(RepositoryImpl.java:483)
at org.apache.jackrabbit.core.RepositoryImpl.<init>(RepositoryImpl.java:324)
at org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:621)
at org.apache.jackrabbit.core.jndi.BindableRepository.createRepository(BindableRepository.java:140)
at org.apache.jackrabbit.core.jndi.BindableRepository.init(BindableRepository.java:116)
at org.apache.jackrabbit.core.jndi.BindableRepository.<init>(BindableRepository.java:105)
at org.apache.jackrabbit.core.jndi.BindableRepositoryFactory.getObjectInstance(BindableRepositoryFactory.java:51)
at org.apache.jackrabbit.core.jndi.RegistryHelper.registerRepository(RegistryHelper.java:74)
Thanks
Anit
-----Original Message-----
From: Janne Jalkanen [mailto:janne.jalkanen@ecyrd.com]
Sent: Tuesday, November 17, 2009 1:12 PM
To: users@jackrabbit.apache.org
Subject: Re: David's Model question : nt:unstructured and SNS
On 17 Nov 2009, at 14:50, Sandro Boehme wrote:
> Alexander Klimetschek schrieb:
>> 2009/11/16 Fabián Mandelbaum <fm...@gmail.com>:
>>> It's simpler than fiddling around with this low-level stuff actually:
>>>
>>> Just create a DAO to abstract all JCR operations (as you should be
>>> doing already)
>> (To give my usual opinion about object content mapping and JCR:) If
>> you use DAOs this of course is a straight-forward solution (but only
>> for the code that uses the DAO layer), but I think that using JCR
>> directly is not "low-level" stuff:
> In my opinion an OCM adds statical type checking and the ability to add functionality (e.g. finder methods) to this types.
JSPWiki uses a layer on top of JCR to
a) provide type/range checking for some values, and
b) to provide backwards API compatibility.
/Janne
IndexWriter lucene exception
Posted by "Phukan, Anit" <An...@intuit.com>.
Hi,
Did anyone encounter this type of error while starting up the repository? I am using lucene version 1.4.3 and jackrabbit-core version 1.5.5. Could it be because I am using out of sync jars for these two?
java.lang.NoSuchMethodError: org.apache.lucene.index.IndexWriter.<init>(Lorg/apache/lucene/store/Directory;Lorg/apache/lucene/analysis/Analyzer;)V
at org.apache.jackrabbit.core.query.lucene.AbstractIndex.<init>(AbstractIndex.java:145)
at org.apache.jackrabbit.core.query.lucene.VolatileIndex.<init>(VolatileIndex.java:65)
at org.apache.jackrabbit.core.query.lucene.MultiIndex.resetVolatileIndex(MultiIndex.java:952)
at org.apache.jackrabbit.core.query.lucene.MultiIndex.<init>(MultiIndex.java:298)
at org.apache.jackrabbit.core.query.lucene.SearchIndex.doInit(SearchIndex.java:456)
at org.apache.jackrabbit.core.query.AbstractQueryHandler.init(AbstractQueryHandler.java:59)
at org.apache.jackrabbit.core.SearchManager.initializeQueryHandler(SearchManager.java:553)
at org.apache.jackrabbit.core.SearchManager.<init>(SearchManager.java:239)
at org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.getSearchManager(RepositoryImpl.java:1723)
at org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.doPostInitialize(RepositoryImpl.java:1923)
at org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.initialize(RepositoryImpl.java:1836)
at org.apache.jackrabbit.core.RepositoryImpl.initStartupWorkspaces(RepositoryImpl.java:483)
at org.apache.jackrabbit.core.RepositoryImpl.<init>(RepositoryImpl.java:324)
at org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:621)
at org.apache.jackrabbit.core.jndi.BindableRepository.createRepository(BindableRepository.java:140)
at org.apache.jackrabbit.core.jndi.BindableRepository.init(BindableRepository.java:116)
at org.apache.jackrabbit.core.jndi.BindableRepository.<init>(BindableRepository.java:105)
at org.apache.jackrabbit.core.jndi.BindableRepositoryFactory.getObjectInstance(BindableRepositoryFactory.java:51)
at org.apache.jackrabbit.core.jndi.RegistryHelper.registerRepository(RegistryHelper.java:74)
Thanks
Anit
-----Original Message-----
From: Janne Jalkanen [mailto:janne.jalkanen@ecyrd.com]
Sent: Tuesday, November 17, 2009 1:12 PM
To: users@jackrabbit.apache.org
Subject: Re: David's Model question : nt:unstructured and SNS
On 17 Nov 2009, at 14:50, Sandro Boehme wrote:
> Alexander Klimetschek schrieb:
>> 2009/11/16 Fabián Mandelbaum <fm...@gmail.com>:
>>> It's simpler than fiddling around with this low-level stuff actually:
>>>
>>> Just create a DAO to abstract all JCR operations (as you should be
>>> doing already)
>> (To give my usual opinion about object content mapping and JCR:) If
>> you use DAOs this of course is a straight-forward solution (but only
>> for the code that uses the DAO layer), but I think that using JCR
>> directly is not "low-level" stuff:
> In my opinion an OCM adds statical type checking and the ability to add functionality (e.g. finder methods) to this types.
JSPWiki uses a layer on top of JCR to
a) provide type/range checking for some values, and
b) to provide backwards API compatibility.
/Janne
Re: David's Model question : nt:unstructured and SNS
Posted by Christophe Lombart <ch...@gmail.com>.
Nice Discussion !
After making different projects based on Jackrabbit & OCM, my opinion is
changing (don't blame me, I'm one of the committer of the Jackrabbit OCM
!). I came from the ORM technologies for building applications with many
layers. The more layers we had, the better it was. But now, my opinion is
changing because we are building content applications in a different way .
Indeed, there are new concepts & new technologies that can help us to have a
simpler architecture (aka OSGI, REST & JCR or "Sling ;-)"). With all of
that, OCM is not mandatory. I know, it is a long debate but I'm very
surprising on how we have simplified the code for a customer application,
just by using Sling (without speaking about the dev time). Read more on
[1].
Concerning OCM, I'm changing my opinion because (in a random order) :
- JCR code on server side is very fast. Adding more layers & mapping will
decrease the performance and add complexity in the architecture.
- The server codes are generally smalls. So, using the JCR API is not a
problem (even if JCR code is more verbose).
- JCR is a standard, OCM is not. OCM has to reimplement all JCR features in
another/non standard API.
- JCR spec is simple to learn for a developer (no annotations, no mapping).
The model is simple : Items, Nodes, Properties for everything. JCR code can
be more generic.
- Changing the content model is easier with JCR than with OCM. Difficulties
to follow : "data first, structure later" with OCM.
Again, don't blame me but I think OCM was not a good idea. Make a try with
Sling and you will see how the JCR code can be simple.
[1] Just for the fun :
http://www.slideshare.net/lars3loff/the-zero-bullshit-architecture (sorry
for the "free marketing" but it is so true)
2009/11/17 Janne Jalkanen <ja...@ecyrd.com>
>
> On 17 Nov 2009, at 14:50, Sandro Boehme wrote:
>
> > Alexander Klimetschek schrieb:
> >> 2009/11/16 Fabián Mandelbaum <fm...@gmail.com>:
> >>> It's simpler than fiddling around with this low-level stuff actually:
> >>>
> >>> Just create a DAO to abstract all JCR operations (as you should be
> >>> doing already)
> >> (To give my usual opinion about object content mapping and JCR:) If
> >> you use DAOs this of course is a straight-forward solution (but only
> >> for the code that uses the DAO layer), but I think that using JCR
> >> directly is not "low-level" stuff:
> > In my opinion an OCM adds statical type checking and the ability to add
> functionality (e.g. finder methods) to this types.
>
> JSPWiki uses a layer on top of JCR to
> a) provide type/range checking for some values, and
> b) to provide backwards API compatibility.
>
> /Janne
>
Re: David's Model question : nt:unstructured and SNS
Posted by Janne Jalkanen <ja...@ecyrd.com>.
On 17 Nov 2009, at 14:50, Sandro Boehme wrote:
> Alexander Klimetschek schrieb:
>> 2009/11/16 Fabián Mandelbaum <fm...@gmail.com>:
>>> It's simpler than fiddling around with this low-level stuff actually:
>>>
>>> Just create a DAO to abstract all JCR operations (as you should be
>>> doing already)
>> (To give my usual opinion about object content mapping and JCR:) If
>> you use DAOs this of course is a straight-forward solution (but only
>> for the code that uses the DAO layer), but I think that using JCR
>> directly is not "low-level" stuff:
> In my opinion an OCM adds statical type checking and the ability to add functionality (e.g. finder methods) to this types.
JSPWiki uses a layer on top of JCR to
a) provide type/range checking for some values, and
b) to provide backwards API compatibility.
/Janne
Re: David's Model question : nt:unstructured and SNS
Posted by Sandro Boehme <sa...@gmx.de>.
Alexander Klimetschek schrieb:
> 2009/11/16 Fabián Mandelbaum <fm...@gmail.com>:
>> It's simpler than fiddling around with this low-level stuff actually:
>>
>> Just create a DAO to abstract all JCR operations (as you should be
>> doing already)
>
> (To give my usual opinion about object content mapping and JCR:) If
> you use DAOs this of course is a straight-forward solution (but only
> for the code that uses the DAO layer), but I think that using JCR
> directly is not "low-level" stuff:
>
> - JCR Node already is like a DAO, and a more flexible one (nt:unstructured)
> - nodetypes can give you validation
> - session (+ transactions) provide all you need for managing the
> object's lifetime and separation into sessions
> - access control, versioning, search etc. are quite high-level IMO, so
> you should use them directly
>
> I see the point for DAOs only when you really want to be sure that
> application coders can only use the properties you designed for them.
> Or when you have a relational model and are required to map it onto an
> object model, but that's not the case with JCR. An OCM only adds an
> additional layer of code and complexity.
>
> Just my 2 cents...
> Alex
>
In my opinion an OCM adds statical type checking and the ability to add
functionality (e.g. finder methods) to this types.
Cheers,
Sandro
--
Sandro Böhme
Systems Development
Project Management
Wir nutzen Technologien, um unsere Kunden glücklich zu machen.
Und uns selbst.
inovex GmbH
Karlsruher Strasse 71
D-75179 Pforzheim
Tel: 07231 31 91-80
Fax: 07231 31 91-91
sandro.boehme@inovex.de
www.inovex.de
Sitz der Gesellschaft: Pforzheim
AG Mannheim, HRB 502126
Geschäftsführer: Stephan Müller
Re: David's Model question : nt:unstructured and SNS
Posted by Rakesh Vidyadharan <ra...@sptci.com>.
On 16 Nov 2009, at 6:38:34 AM, Alexander Klimetschek wrote:
> 2009/11/16 Fabián Mandelbaum <fm...@gmail.com>:
>> It's simpler than fiddling around with this low-level stuff actually:
>>
>> Just create a DAO to abstract all JCR operations (as you should be
>> doing already)
>
> (To give my usual opinion about object content mapping and JCR:) If
> you use DAOs this of course is a straight-forward solution (but only
> for the code that uses the DAO layer), but I think that using JCR
> directly is not "low-level" stuff:
>
> - JCR Node already is like a DAO, and a more flexible one (nt:unstructured)
> - nodetypes can give you validation
> - session (+ transactions) provide all you need for managing the
> object's lifetime and separation into sessions
> - access control, versioning, search etc. are quite high-level IMO, so
> you should use them directly
>
> I see the point for DAOs only when you really want to be sure that
> application coders can only use the properties you designed for them.
> Or when you have a relational model and are required to map it onto an
> object model, but that's not the case with JCR. An OCM only adds an
> additional layer of code and complexity.
>
> Just my 2 cents...
> Alex
I think there is a confusion when using the term DAO. It can mean Data Access Object or Data(base) Abstraction Object (better termed repository). I believe the OP was using it in the second sense, which just means do not directly use session.save, but use dao.save( node ) instead.
Rakesh
Rakesh
Re: David's Model question : nt:unstructured and SNS
Posted by Alexander Klimetschek <ak...@day.com>.
2009/11/16 Fabián Mandelbaum <fm...@gmail.com>:
> It's simpler than fiddling around with this low-level stuff actually:
>
> Just create a DAO to abstract all JCR operations (as you should be
> doing already)
(To give my usual opinion about object content mapping and JCR:) If
you use DAOs this of course is a straight-forward solution (but only
for the code that uses the DAO layer), but I think that using JCR
directly is not "low-level" stuff:
- JCR Node already is like a DAO, and a more flexible one (nt:unstructured)
- nodetypes can give you validation
- session (+ transactions) provide all you need for managing the
object's lifetime and separation into sessions
- access control, versioning, search etc. are quite high-level IMO, so
you should use them directly
I see the point for DAOs only when you really want to be sure that
application coders can only use the properties you designed for them.
Or when you have a relational model and are required to map it onto an
object model, but that's not the case with JCR. An OCM only adds an
additional layer of code and complexity.
Just my 2 cents...
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: David's Model question : nt:unstructured and SNS
Posted by Fabián Mandelbaum <fm...@gmail.com>.
It's simpler than fiddling around with this low-level stuff actually:
Just create a DAO to abstract all JCR operations (as you should be
doing already), and in that DAO's store() (or whatever is called)
method make a check for node existence before storing the new node, et
voilà !
Something like:
public void store(Object o) throws RespositoryException {
String path = getStoragePathFromObject(o); // The absolute path
where o should be stored based on o's key fields
if (!session.itemExists(path)) {
// Code to store Object o here
} else {
throw new ItemExistsException(String.format("There already exists
an object stored at %s", path));
}
}
That is, a variation on the "wrapper" suggestion you got 1st. Even
more, you can do other things instead of throwing an exception, you
can try to store the object at another place, or whatever your
application needs.
On Sat, Nov 14, 2009 at 7:35 AM, Guo Du <mr...@gmail.com> wrote:
> 2009/11/14 François Cassistat <f...@maya-systems.com>:
>> I was looking for something like changing the default behavior of
>> nt:structured, but I think it may cause problems since /jcr:system & friends
>> use SNS.
> The build in node types such as nt:unstructured are protected at
> runtime, so you cannot delete or update them. But didn't try to update
> builtin_nodtypes.cnd before repository start. It's not recommend
> anyway.
>
> Just another notes on my previous sample, the childNodeDefinition
> onParentVersion="IGNORE" is different from nt:unstructured.
>
> Good luck!
>
> --Guo
>
--
Fabián Mandelbaum
IS Engineer
Re: David's Model question : nt:unstructured and SNS
Posted by Guo Du <mr...@gmail.com>.
2009/11/14 François Cassistat <f...@maya-systems.com>:
> I was looking for something like changing the default behavior of
> nt:structured, but I think it may cause problems since /jcr:system & friends
> use SNS.
The build in node types such as nt:unstructured are protected at
runtime, so you cannot delete or update them. But didn't try to update
builtin_nodtypes.cnd before repository start. It's not recommend
anyway.
Just another notes on my previous sample, the childNodeDefinition
onParentVersion="IGNORE" is different from nt:unstructured.
Good luck!
--Guo
Re: David's Model question : nt:unstructured and SNS
Posted by François Cassistat <f...@maya-systems.com>.
Yes, it seems like I was thinking. I should create my own type like
Guo Du propose and make some kind of wrapper like Tobias propose. I
wanted to make sure there was not something I missed before working on
a solution.
I was looking for something like changing the default behavior of
nt:structured, but I think it may cause problems since /jcr:system &
friends use SNS.
thank you,
Frank
Le 09-11-13 à 17:06, Guo Du a écrit :
> 2009/11/13 François Cassistat <f...@maya-systems.com>:
>> Is there an easy way to disallow SNS other than defining a new node
>> type and setting all new nodes in this type, so I can get
>> ItemExistException on save to prevent SNS from happening?
>
> The nt:folder doesn't allow SNS. If your application doesn't like
> nt:folder, you may create a custom node type like following sample.
> It's the same as nt:unstructured except the SNS validation.
>
> <nodeType name="nt:nosamesiblings"
> isMixin="false"
> hasOrderableChildNodes="true">
> <supertypes>
> <supertype>nt:base</supertype>
> </supertypes>
> <childNodeDefinition name="*"
> defaultPrimaryType="nt:xunstructured"
> sameNameSiblings="false"
> autoCreated="false" mandatory="true"
> onParentVersion="IGNORE" protected="false"/>
> <propertyDefinition name="*"
> requiredType="undefined"
> autoCreated="false"
> mandatory="false"
> onParentVersion="COPY"
> protected="false"
> multiple="false"/>
> <propertyDefinition name="*"
> requiredType="undefined"
> autoCreated="false"
> mandatory="false"
> onParentVersion="COPY"
> protected="false"
> multiple="true"/>
> </nodeType>
>
> As this node type could be interesting for some people, it might be
> good to provide by default.
>
> -Guo
Le 09-11-13 à 17:21, Tobias Bocanegra a écrit :
> hi,
>
> 2009/11/13 François Cassistat <f...@maya-systems.com>:
>> David's Model gives good advices and I already followed his
>> suggestions.
>>
>> However, there is something I don't understand. He says "Learn to
>> love nt:unstructured (& friends) in development." (and I think he
>> is right) and later, "Beware of Same Name Siblings (SNS)". But, in
>> the documentation, nt:unstructured allows SNS.
>>
>> Is there an easy way to disallow SNS other than defining a new node
>> type and setting all new nodes in this type, so I can get
>> ItemExistException on save to prevent SNS from happening?
>
> unfortunately not an easy one like changing the configuration. i see
> the following options:
> 1) create your own "nt:unstructured"
> 2) create a wrapper around the JCR interface and do the check yourself
> in 'addNode() and move()'. theoretically there are many more places
> you need to check - but those are the most common ones.
> 3) hack the builtin_nodtypes.cnd and change the definition of
> nt:unstructured. but i strongly discourage doing this. you're probably
> have a lot of problems later.
>
> regards, toby
Re: David's Model question : nt:unstructured and SNS
Posted by Tobias Bocanegra <tr...@day.com>.
hi,
2009/11/13 François Cassistat <f...@maya-systems.com>:
> David's Model gives good advices and I already followed his suggestions.
>
> However, there is something I don't understand. He says "Learn to love nt:unstructured (& friends) in development." (and I think he is right) and later, "Beware of Same Name Siblings (SNS)". But, in the documentation, nt:unstructured allows SNS.
>
> Is there an easy way to disallow SNS other than defining a new node type and setting all new nodes in this type, so I can get ItemExistException on save to prevent SNS from happening?
unfortunately not an easy one like changing the configuration. i see
the following options:
1) create your own "nt:unstructured"
2) create a wrapper around the JCR interface and do the check yourself
in 'addNode() and move()'. theoretically there are many more places
you need to check - but those are the most common ones.
3) hack the builtin_nodtypes.cnd and change the definition of
nt:unstructured. but i strongly discourage doing this. you're probably
have a lot of problems later.
regards, toby
Re: David's Model question : nt:unstructured and SNS
Posted by Guo Du <mr...@gmail.com>.
2009/11/13 François Cassistat <f...@maya-systems.com>:
> Is there an easy way to disallow SNS other than defining a new node type and setting all new nodes in this type, so I can get ItemExistException on save to prevent SNS from happening?
The nt:folder doesn't allow SNS. If your application doesn't like
nt:folder, you may create a custom node type like following sample.
It's the same as nt:unstructured except the SNS validation.
<nodeType name="nt:nosamesiblings"
isMixin="false"
hasOrderableChildNodes="true">
<supertypes>
<supertype>nt:base</supertype>
</supertypes>
<childNodeDefinition name="*"
defaultPrimaryType="nt:xunstructured" sameNameSiblings="false"
autoCreated="false" mandatory="true"
onParentVersion="IGNORE" protected="false"/>
<propertyDefinition name="*"
requiredType="undefined"
autoCreated="false"
mandatory="false"
onParentVersion="COPY"
protected="false"
multiple="false"/>
<propertyDefinition name="*"
requiredType="undefined"
autoCreated="false"
mandatory="false"
onParentVersion="COPY"
protected="false"
multiple="true"/>
</nodeType>
As this node type could be interesting for some people, it might be
good to provide by default.
-Guo