You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by shepy <vl...@yahoo.com> on 2007/08/01 11:11:17 UTC
Adding new node types
Hello,
I'm using JR as repository server. I need to register new node types.
Where is the best place to do this? I don't want to do this from client
application. I see two possibilities:
1) Extend RepositoryStartupServlet and do this on init.
2) use RepositoryStartupServlet init-param to do this (if it exists)
Or is there some other possibility?
Thanks.
--
View this message in context: http://www.nabble.com/Adding-new-node-types-tf4198867.html#a11942091
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: How to manage JCR Types with JackRabbit? - a contrast with DDL
Posted by Stefan Guggisberg <st...@gmail.com>.
hi shaun,
On 9/5/07, sbarriba <sb...@yahoo.co.uk> wrote:
> Hi all,
> I was hoping to drive out a best practise for JackRabbit type management on
> this thread but no takers yet.
well, you hit a soft spot... ;-)
comments follow inline
> Anyone got any interesting comments ......
> ..... or are there better solutions out there for CND management that I'm
> missing?
> Regards,
> Shaun.
>
> -----Original Message-----
> From: sbarriba [mailto:sbarriba@yahoo.co.uk]
> Sent: 27 August 2007 10:29
> To: users@jackrabbit.apache.org
> Subject: How to manage JCR Types with JackRabbit? - a contrast with DDL
>
> Hi all,
> I agree with recent threads on why not to modify the custom_nodetypes.xml
> directly. I personally have not yet found a good resource describing best
> practises for managing JCR types with JackRabbit - for example I know there
> are some limitations on what reRegisterNodeTypes() can achieve. So I've
> tried to list common type operations below to prompt discussion on how types
> should be managed in JackRabbit - and determine if the type management
> should/could be enhanced to avoid the need for migration scripts.
personally i think node type modifications should be fully supported.
currently only a subset of operations is implemented, namely those that don't
affect existing content (e.g. adding non-manadatory properties etc).
those operations that do affect existing content (like removing a
property definition)
are IMO very hard to implement and we haven't yet found an elegant way
of tackling the involved complexity/issues.
>
> I've detailed 6 use cases below using a relational DDL analogy - I recognise
> that JCR is not trying to emulate a relational DB but there are similarities
> in the complexities encountered.
>
> Use Case 1: "Create Table" Master
> Use Case 2: "Create Table" Incremental
> Use Case 3: "Drop Table"
> Use Case 4: "Alter Table Drop Column"
> Use Case 5: "Alter Table Add Column"
> Use Case 6: "Alter Table modify Column"
>
> The use cases reference an ACME JCR repository including a number of types.
> I've included Q: questions on areas of debate.
>
> Use Case 1: "Create Table" Master
> ------------------------------------
> For an empty workspace its sufficient to:
> * create a master ACME .cnd file with all of the required types (Type
> acme:A, Type acme:B)
> * call NodeTypeManagerImpl.registerNodeTypes()
>
> Use Case 2: "Create Table" Incremental
> ------------------------------------
> If I decide to add a new type (Type acme:C) to an existing JCR repository
> its sufficient to:
> * create a fragment .cnd file with the new type (Type acme:C)
> * call NodeTypeManagerImpl.registerNodeTypes()
> * I also need to add Type acme:C to my master acme.cnd file for clean
> installations
>
> Use Case 3: "Drop Table"
> -------------------------
> I decide I no longer need "Type acme:A". In DDL I'd write a drop table
> script and I'd have to ensure my table is not the target of any foreign key
> constraint. In JCR I think I just need to:
> * call NodeTypeRegistry.unregisterNodeType()
>
> Looking at the implementation I don't believe this currently deletes
> instances of Type acme:A that exist, leaving me with the requirement to
> write a custom migration script to navigate the repository deleting
> instances of this type.
the current implementation doesn't (yet) support node type deregistration.
>
> Q1: Should unregisterNodeType delete instances of that type, and fail if the
> deleting any instances breaks a constraint?
IMO yes. but that's exactly the tricky part. you'd need an exclusive lock
over the entire repository and you'd need find all occurrences in every
workspace (potentially containing a *lot* of items)...
>
> Use Case 4: "Alter Table Drop Column"
> -------------------------
> It is a common requirement to drop properties you no longer need e.g. drop
> property "acmne:foo" from Type acme:A. As with "Drop table" I think you
> currently have to:
> * write and run a migration script which iterates through all instances of
> Type acme:A and delete the property,
> * call reRegisterNodeType() passing the new definition of "Type acme:A"
> minus "acme:foo".
>
> Q2: Does reRegisterNodeType() currently allow you to drop properties?
currently no.
> Q3: Should calling reRegisterNodeType() automatically drop properties that
> were present in the old definition but not in the new?
yes. see previous comment.
>
> Use Case 5: "Alter Table Add Column"
> -------------------------
> As with "Drop Column" there is common required to add new properties e.g.
> add property "acme:bar" to Type acme:A. I think you currently have to:
> * call reRegisterNodeType() passing the new definition of "Type acme:A" with
> "acme:bar".
> * write and run a migration script which iterates through all instances of
> Type acme:A and adds the property (if its mandatory)
> In DDL the new column would inherit any DEFAULT value assigned to the
> property.
>
> Q4: Does reRegisterNodeType() automatically add any "default" values for
> newly added properties?
no.
>
> Use Case 6: "Alter Table modify Column"
> -------------------------
> This is less common, but sometimes you wish to change the type e.g. property
> "acme:bar" changes from string to long. This is generally a difficult thing
> to do. I presume the only way to deal with this in JCR is to:
> * rereregister Type acme:A with a acme:bar_tmp property with the same
> definition as the existing type
> * run a migration script which copies the value of "acme:bar" to
> "acme:bar_tmp" and then drops the "acme:bar" property.
> * reregister Type acme:A with definition of "acme:bar" changed.
> * run a migration script which reads "acme:bar_tmp", casts and stores in
> "acme:bar"
> * reregister Type acme:A having removed the definition of "acme:bar_tmp"
>
> All thoughts welcome,
sorry for the late response.
cheers
stefan
> Regards,
> Shaun
>
>
>
> -----Original Message-----
> From: Stefan Guggisberg [mailto:stefan.guggisberg@gmail.com]
> Sent: 02 August 2007 10:04
> To: users@jackrabbit.apache.org
> Subject: Re: Adding new node types
>
> On 8/1/07, Krenn, Christian <ch...@bearingpoint.com> wrote:
> > Hi!
> >
> > I had the same problem. There is something that the jackrabbit devs use
> > for unit tests. It's in the -> repository/nodetypes. There you have to
> > put a file called custom_nodetypes.xml. in the jackrabbit.core.nodetypes
> > there is a file called builtin_nodetypes.xml, which you can use as
> > template.
> > You have also to put a new entry to
> > repository/namespace/ns_reg.properties.
>
> note that those files are *not* meant to be user-manipulated. they are
> jackrabbit-internal system files. by manually editing those you
> may risk data loss/corruption.
>
> see e.g.
> http://thread.gmane.org/gmane.comp.apache.jackrabbit.user/2374/focus=2418
> http://thread.gmane.org/gmane.comp.apache.jackrabbit.user/536/focus=539
> http://thread.gmane.org/gmane.comp.apache.jackrabbit.user/659/focus=664
>
> cheers
> stefan
>
> >
> > So you needn't to do the registry everytime on the clientside because
> > it's automatically done on server startup.
> >
> > bye
> >
> > -----Original Message-----
> > From: shepy [mailto:vladoseprak@yahoo.com]
> > Sent: Mittwoch, 01. August 2007 11:11
> > To: users@jackrabbit.apache.org
> > Subject: Adding new node types
> >
> >
> > Hello,
> >
> > I'm using JR as repository server. I need to register new node types.
> > Where is the best place to do this? I don't want to do this from client
> > application. I see two possibilities:
> >
> > 1) Extend RepositoryStartupServlet and do this on init.
> > 2) use RepositoryStartupServlet init-param to do this (if it exists)
> >
> > Or is there some other possibility?
> >
> > Thanks.
> > --
> > View this message in context:
> > http://www.nabble.com/Adding-new-node-types-tf4198867.html#a11942091
> > Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
> >
> >
> ****************************************************************************
> ***********************
> > The information in this email is confidential and may be legally
> privileged. Access to this email by anyone other than the intended addressee
> is unauthorized. If you are not the intended recipient of this message, any
> review, disclosure, copying, distribution, retention, or any action taken or
> omitted to be taken in reliance on it is prohibited and may be unlawful. If
> you are not the intended recipient, please reply to or forward a copy of
> this message to the sender and delete the message, any attachments, and any
> copies thereof from your system.
> >
> ****************************************************************************
> ***********************
> >
> > BearingPoint INFONOVA GmbH
> > Sitz: Unterpremstatten bei Graz
> > Firmenbuchgericht: Landesgericht fur ZRS Graz
> > Firmenbuchnummer: FN 44354b
> >
>
>
RE: How to manage JCR Types with JackRabbit? - a contrast with DDL
Posted by sbarriba <sb...@yahoo.co.uk>.
Hi all,
I was hoping to drive out a best practise for JackRabbit type management on
this thread but no takers yet.
Anyone got any interesting comments ......
..... or are there better solutions out there for CND management that I'm
missing?
Regards,
Shaun.
-----Original Message-----
From: sbarriba [mailto:sbarriba@yahoo.co.uk]
Sent: 27 August 2007 10:29
To: users@jackrabbit.apache.org
Subject: How to manage JCR Types with JackRabbit? - a contrast with DDL
Hi all,
I agree with recent threads on why not to modify the custom_nodetypes.xml
directly. I personally have not yet found a good resource describing best
practises for managing JCR types with JackRabbit - for example I know there
are some limitations on what reRegisterNodeTypes() can achieve. So I've
tried to list common type operations below to prompt discussion on how types
should be managed in JackRabbit - and determine if the type management
should/could be enhanced to avoid the need for migration scripts.
I've detailed 6 use cases below using a relational DDL analogy - I recognise
that JCR is not trying to emulate a relational DB but there are similarities
in the complexities encountered.
Use Case 1: "Create Table" Master
Use Case 2: "Create Table" Incremental
Use Case 3: "Drop Table"
Use Case 4: "Alter Table Drop Column"
Use Case 5: "Alter Table Add Column"
Use Case 6: "Alter Table modify Column"
The use cases reference an ACME JCR repository including a number of types.
I've included Q: questions on areas of debate.
Use Case 1: "Create Table" Master
------------------------------------
For an empty workspace its sufficient to:
* create a master ACME .cnd file with all of the required types (Type
acme:A, Type acme:B)
* call NodeTypeManagerImpl.registerNodeTypes()
Use Case 2: "Create Table" Incremental
------------------------------------
If I decide to add a new type (Type acme:C) to an existing JCR repository
its sufficient to:
* create a fragment .cnd file with the new type (Type acme:C)
* call NodeTypeManagerImpl.registerNodeTypes()
* I also need to add Type acme:C to my master acme.cnd file for clean
installations
Use Case 3: "Drop Table"
-------------------------
I decide I no longer need "Type acme:A". In DDL I'd write a drop table
script and I'd have to ensure my table is not the target of any foreign key
constraint. In JCR I think I just need to:
* call NodeTypeRegistry.unregisterNodeType()
Looking at the implementation I don't believe this currently deletes
instances of Type acme:A that exist, leaving me with the requirement to
write a custom migration script to navigate the repository deleting
instances of this type.
Q1: Should unregisterNodeType delete instances of that type, and fail if the
deleting any instances breaks a constraint?
Use Case 4: "Alter Table Drop Column"
-------------------------
It is a common requirement to drop properties you no longer need e.g. drop
property "acmne:foo" from Type acme:A. As with "Drop table" I think you
currently have to:
* write and run a migration script which iterates through all instances of
Type acme:A and delete the property,
* call reRegisterNodeType() passing the new definition of "Type acme:A"
minus "acme:foo".
Q2: Does reRegisterNodeType() currently allow you to drop properties?
Q3: Should calling reRegisterNodeType() automatically drop properties that
were present in the old definition but not in the new?
Use Case 5: "Alter Table Add Column"
-------------------------
As with "Drop Column" there is common required to add new properties e.g.
add property "acme:bar" to Type acme:A. I think you currently have to:
* call reRegisterNodeType() passing the new definition of "Type acme:A" with
"acme:bar".
* write and run a migration script which iterates through all instances of
Type acme:A and adds the property (if its mandatory)
In DDL the new column would inherit any DEFAULT value assigned to the
property.
Q4: Does reRegisterNodeType() automatically add any "default" values for
newly added properties?
Use Case 6: "Alter Table modify Column"
-------------------------
This is less common, but sometimes you wish to change the type e.g. property
"acme:bar" changes from string to long. This is generally a difficult thing
to do. I presume the only way to deal with this in JCR is to:
* rereregister Type acme:A with a acme:bar_tmp property with the same
definition as the existing type
* run a migration script which copies the value of "acme:bar" to
"acme:bar_tmp" and then drops the "acme:bar" property.
* reregister Type acme:A with definition of "acme:bar" changed.
* run a migration script which reads "acme:bar_tmp", casts and stores in
"acme:bar"
* reregister Type acme:A having removed the definition of "acme:bar_tmp"
All thoughts welcome,
Regards,
Shaun
-----Original Message-----
From: Stefan Guggisberg [mailto:stefan.guggisberg@gmail.com]
Sent: 02 August 2007 10:04
To: users@jackrabbit.apache.org
Subject: Re: Adding new node types
On 8/1/07, Krenn, Christian <ch...@bearingpoint.com> wrote:
> Hi!
>
> I had the same problem. There is something that the jackrabbit devs use
> for unit tests. It's in the -> repository/nodetypes. There you have to
> put a file called custom_nodetypes.xml. in the jackrabbit.core.nodetypes
> there is a file called builtin_nodetypes.xml, which you can use as
> template.
> You have also to put a new entry to
> repository/namespace/ns_reg.properties.
note that those files are *not* meant to be user-manipulated. they are
jackrabbit-internal system files. by manually editing those you
may risk data loss/corruption.
see e.g.
http://thread.gmane.org/gmane.comp.apache.jackrabbit.user/2374/focus=2418
http://thread.gmane.org/gmane.comp.apache.jackrabbit.user/536/focus=539
http://thread.gmane.org/gmane.comp.apache.jackrabbit.user/659/focus=664
cheers
stefan
>
> So you needn't to do the registry everytime on the clientside because
> it's automatically done on server startup.
>
> bye
>
> -----Original Message-----
> From: shepy [mailto:vladoseprak@yahoo.com]
> Sent: Mittwoch, 01. August 2007 11:11
> To: users@jackrabbit.apache.org
> Subject: Adding new node types
>
>
> Hello,
>
> I'm using JR as repository server. I need to register new node types.
> Where is the best place to do this? I don't want to do this from client
> application. I see two possibilities:
>
> 1) Extend RepositoryStartupServlet and do this on init.
> 2) use RepositoryStartupServlet init-param to do this (if it exists)
>
> Or is there some other possibility?
>
> Thanks.
> --
> View this message in context:
> http://www.nabble.com/Adding-new-node-types-tf4198867.html#a11942091
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>
>
****************************************************************************
***********************
> The information in this email is confidential and may be legally
privileged. Access to this email by anyone other than the intended addressee
is unauthorized. If you are not the intended recipient of this message, any
review, disclosure, copying, distribution, retention, or any action taken or
omitted to be taken in reliance on it is prohibited and may be unlawful. If
you are not the intended recipient, please reply to or forward a copy of
this message to the sender and delete the message, any attachments, and any
copies thereof from your system.
>
****************************************************************************
***********************
>
> BearingPoint INFONOVA GmbH
> Sitz: Unterpremstatten bei Graz
> Firmenbuchgericht: Landesgericht fur ZRS Graz
> Firmenbuchnummer: FN 44354b
>
Re: How to manage JCR Types with JackRabbit? - a contrast with DDL
Posted by greg power <gr...@googlemail.com>.
Hi all,
I'd like to add another use case to Shaun's list:
Use Case 7: Fix Naive Relation
Suppose I find a naive many-to-many relation in some application based on
Hibernate/POJO or EJB. What would I do to fix this? Steps might be:
1) Fix the domain model (maybe add a class or two)
2) Fix the Hibernate mappings/EJB notations (to reflect 1)
3) Write a SQL script to copy the existing tables, drop the old ones, create
& populate replacement tables etc (to reflect 1 & 2)
Being new to jcr I expect to make some howling misjudgments over node
definitions etc and I will want to fix them. From reading the forum it seems
that doing so will be easier said than done and this is giving me the
collywobbles.
What seems be to missing is the SQL script element. Brute force it might be,
but it is brutally effective in the real world. I realize there are problems
here: a) jcr is much richer that RDBMS, b) RDBMS has three decades
development under it's belt. I also hear Stefan:
>
> Q1: Should unregisterNodeType delete instances of that type, and fail if
> the
> deleting any instances breaks a constraint?
"IMO yes. but that's exactly the tricky part. you'd need an exclusive lock
over the entire repository and you'd need find all occurrences in every
workspace (potentially containing a *lot* of items)..."
What is the way forward with this? Surely either the tried and tested
concept of the brute force script (at owner's risk, of course) should by
default be inherited by jcr, or there should be a shiny, new, elegant
alternative in the jcr pipeline?
regards
gregor
--
View this message in context: http://www.nabble.com/Adding-new-node-types-tp11942091p16527745.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
How to manage JCR Types with JackRabbit? - a contrast with DDL
Posted by sbarriba <sb...@yahoo.co.uk>.
Hi all,
I agree with recent threads on why not to modify the custom_nodetypes.xml
directly. I personally have not yet found a good resource describing best
practises for managing JCR types with JackRabbit - for example I know there
are some limitations on what reRegisterNodeTypes() can achieve. So I've
tried to list common type operations below to prompt discussion on how types
should be managed in JackRabbit - and determine if the type management
should/could be enhanced to avoid the need for migration scripts.
I've detailed 6 use cases below using a relational DDL analogy - I recognise
that JCR is not trying to emulate a relational DB but there are similarities
in the complexities encountered.
Use Case 1: "Create Table" Master
Use Case 2: "Create Table" Incremental
Use Case 3: "Drop Table"
Use Case 4: "Alter Table Drop Column"
Use Case 5: "Alter Table Add Column"
Use Case 6: "Alter Table modify Column"
The use cases reference an ACME JCR repository including a number of types.
I've included Q: questions on areas of debate.
Use Case 1: "Create Table" Master
------------------------------------
For an empty workspace its sufficient to:
* create a master ACME .cnd file with all of the required types (Type
acme:A, Type acme:B)
* call NodeTypeManagerImpl.registerNodeTypes()
Use Case 2: "Create Table" Incremental
------------------------------------
If I decide to add a new type (Type acme:C) to an existing JCR repository
its sufficient to:
* create a fragment .cnd file with the new type (Type acme:C)
* call NodeTypeManagerImpl.registerNodeTypes()
* I also need to add Type acme:C to my master acme.cnd file for clean
installations
Use Case 3: "Drop Table"
-------------------------
I decide I no longer need "Type acme:A". In DDL I'd write a drop table
script and I'd have to ensure my table is not the target of any foreign key
constraint. In JCR I think I just need to:
* call NodeTypeRegistry.unregisterNodeType()
Looking at the implementation I don't believe this currently deletes
instances of Type acme:A that exist, leaving me with the requirement to
write a custom migration script to navigate the repository deleting
instances of this type.
Q1: Should unregisterNodeType delete instances of that type, and fail if the
deleting any instances breaks a constraint?
Use Case 4: "Alter Table Drop Column"
-------------------------
It is a common requirement to drop properties you no longer need e.g. drop
property "acmne:foo" from Type acme:A. As with "Drop table" I think you
currently have to:
* write and run a migration script which iterates through all instances of
Type acme:A and delete the property,
* call reRegisterNodeType() passing the new definition of "Type acme:A"
minus "acme:foo".
Q2: Does reRegisterNodeType() currently allow you to drop properties?
Q3: Should calling reRegisterNodeType() automatically drop properties that
were present in the old definition but not in the new?
Use Case 5: "Alter Table Add Column"
-------------------------
As with "Drop Column" there is common required to add new properties e.g.
add property "acme:bar" to Type acme:A. I think you currently have to:
* call reRegisterNodeType() passing the new definition of "Type acme:A" with
"acme:bar".
* write and run a migration script which iterates through all instances of
Type acme:A and adds the property (if its mandatory)
In DDL the new column would inherit any DEFAULT value assigned to the
property.
Q4: Does reRegisterNodeType() automatically add any "default" values for
newly added properties?
Use Case 6: "Alter Table modify Column"
-------------------------
This is less common, but sometimes you wish to change the type e.g. property
"acme:bar" changes from string to long. This is generally a difficult thing
to do. I presume the only way to deal with this in JCR is to:
* rereregister Type acme:A with a acme:bar_tmp property with the same
definition as the existing type
* run a migration script which copies the value of "acme:bar" to
"acme:bar_tmp" and then drops the "acme:bar" property.
* reregister Type acme:A with definition of "acme:bar" changed.
* run a migration script which reads "acme:bar_tmp", casts and stores in
"acme:bar"
* reregister Type acme:A having removed the definition of "acme:bar_tmp"
All thoughts welcome,
Regards,
Shaun
-----Original Message-----
From: Stefan Guggisberg [mailto:stefan.guggisberg@gmail.com]
Sent: 02 August 2007 10:04
To: users@jackrabbit.apache.org
Subject: Re: Adding new node types
On 8/1/07, Krenn, Christian <ch...@bearingpoint.com> wrote:
> Hi!
>
> I had the same problem. There is something that the jackrabbit devs use
> for unit tests. It's in the -> repository/nodetypes. There you have to
> put a file called custom_nodetypes.xml. in the jackrabbit.core.nodetypes
> there is a file called builtin_nodetypes.xml, which you can use as
> template.
> You have also to put a new entry to
> repository/namespace/ns_reg.properties.
note that those files are *not* meant to be user-manipulated. they are
jackrabbit-internal system files. by manually editing those you
may risk data loss/corruption.
see e.g.
http://thread.gmane.org/gmane.comp.apache.jackrabbit.user/2374/focus=2418
http://thread.gmane.org/gmane.comp.apache.jackrabbit.user/536/focus=539
http://thread.gmane.org/gmane.comp.apache.jackrabbit.user/659/focus=664
cheers
stefan
>
> So you needn't to do the registry everytime on the clientside because
> it's automatically done on server startup.
>
> bye
>
> -----Original Message-----
> From: shepy [mailto:vladoseprak@yahoo.com]
> Sent: Mittwoch, 01. August 2007 11:11
> To: users@jackrabbit.apache.org
> Subject: Adding new node types
>
>
> Hello,
>
> I'm using JR as repository server. I need to register new node types.
> Where is the best place to do this? I don't want to do this from client
> application. I see two possibilities:
>
> 1) Extend RepositoryStartupServlet and do this on init.
> 2) use RepositoryStartupServlet init-param to do this (if it exists)
>
> Or is there some other possibility?
>
> Thanks.
> --
> View this message in context:
> http://www.nabble.com/Adding-new-node-types-tf4198867.html#a11942091
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>
>
****************************************************************************
***********************
> The information in this email is confidential and may be legally
privileged. Access to this email by anyone other than the intended addressee
is unauthorized. If you are not the intended recipient of this message, any
review, disclosure, copying, distribution, retention, or any action taken or
omitted to be taken in reliance on it is prohibited and may be unlawful. If
you are not the intended recipient, please reply to or forward a copy of
this message to the sender and delete the message, any attachments, and any
copies thereof from your system.
>
****************************************************************************
***********************
>
> BearingPoint INFONOVA GmbH
> Sitz: Unterpremstatten bei Graz
> Firmenbuchgericht: Landesgericht fur ZRS Graz
> Firmenbuchnummer: FN 44354b
>
Re: Adding new node types
Posted by Stefan Guggisberg <st...@gmail.com>.
On 8/1/07, Krenn, Christian <ch...@bearingpoint.com> wrote:
> Hi!
>
> I had the same problem. There is something that the jackrabbit devs use
> for unit tests. It's in the -> repository/nodetypes. There you have to
> put a file called custom_nodetypes.xml. in the jackrabbit.core.nodetypes
> there is a file called builtin_nodetypes.xml, which you can use as
> template.
> You have also to put a new entry to
> repository/namespace/ns_reg.properties.
note that those files are *not* meant to be user-manipulated. they are
jackrabbit-internal system files. by manually editing those you
may risk data loss/corruption.
see e.g.
http://thread.gmane.org/gmane.comp.apache.jackrabbit.user/2374/focus=2418
http://thread.gmane.org/gmane.comp.apache.jackrabbit.user/536/focus=539
http://thread.gmane.org/gmane.comp.apache.jackrabbit.user/659/focus=664
cheers
stefan
>
> So you needn't to do the registry everytime on the clientside because
> it's automatically done on server startup.
>
> bye
>
> -----Original Message-----
> From: shepy [mailto:vladoseprak@yahoo.com]
> Sent: Mittwoch, 01. August 2007 11:11
> To: users@jackrabbit.apache.org
> Subject: Adding new node types
>
>
> Hello,
>
> I'm using JR as repository server. I need to register new node types.
> Where is the best place to do this? I don't want to do this from client
> application. I see two possibilities:
>
> 1) Extend RepositoryStartupServlet and do this on init.
> 2) use RepositoryStartupServlet init-param to do this (if it exists)
>
> Or is there some other possibility?
>
> Thanks.
> --
> View this message in context:
> http://www.nabble.com/Adding-new-node-types-tf4198867.html#a11942091
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>
> ***************************************************************************************************
> The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.
> ***************************************************************************************************
>
> BearingPoint INFONOVA GmbH
> Sitz: Unterpremstatten bei Graz
> Firmenbuchgericht: Landesgericht fur ZRS Graz
> Firmenbuchnummer: FN 44354b
>
RE: Adding new node types
Posted by "Krenn, Christian" <ch...@bearingpoint.com>.
Hi!
I had the same problem. There is something that the jackrabbit devs use
for unit tests. It's in the -> repository/nodetypes. There you have to
put a file called custom_nodetypes.xml. in the jackrabbit.core.nodetypes
there is a file called builtin_nodetypes.xml, which you can use as
template.
You have also to put a new entry to
repository/namespace/ns_reg.properties.
So you needn't to do the registry everytime on the clientside because
it's automatically done on server startup.
bye
-----Original Message-----
From: shepy [mailto:vladoseprak@yahoo.com]
Sent: Mittwoch, 01. August 2007 11:11
To: users@jackrabbit.apache.org
Subject: Adding new node types
Hello,
I'm using JR as repository server. I need to register new node types.
Where is the best place to do this? I don't want to do this from client
application. I see two possibilities:
1) Extend RepositoryStartupServlet and do this on init.
2) use RepositoryStartupServlet init-param to do this (if it exists)
Or is there some other possibility?
Thanks.
--
View this message in context:
http://www.nabble.com/Adding-new-node-types-tf4198867.html#a11942091
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
***************************************************************************************************
The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.
***************************************************************************************************
BearingPoint INFONOVA GmbH
Sitz: Unterpremstatten bei Graz
Firmenbuchgericht: Landesgericht fur ZRS Graz
Firmenbuchnummer: FN 44354b