You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Manolo Gomez Lopez <pe...@gmail.com> on 2008/02/16 23:10:24 UTC
Deploying custom node types in jackrabbit
Hi,
We need to have custom node types in our system. I have two questions
regarding the deployment of those node types.
First, we would like to use the 3rd deployment model, where the repository
gets exposed using RMI, and we noticed (as others) that the remote stub
that one can get from the RMI server lacks of the appropriate methods needed
for registering custom node types. I've read somewhere that a change in the
server and client interfaces is needed to be able to register custom node
types but there's not many information available.
Can anyone give some hint on how to get the appropriate stubs that will
allow the clients of our model 3 jackrabbit to register custom node types?
Second, I am wondering if there are any plans to allow the registration of
custom node types without the need of invoking jackrabbit API
programmatically. As there exists a notation for describing node types and
their prefixes and namespaces, wouldn't it be easier to store node
definitions in files and let them be deployed in jackrabbit when found in a
given directory, following the J2EE pattern of deploying applications?
As deployed node types and namespaces at the end are represented using
files inside jackrabbit's data model on disk, maybe will be a good idea to
let administrators put node type definitions there for deployment...
greets,
Re: Deploying custom node types in jackrabbit
Posted by Ivan Latysh <iv...@gmail.com>.
Manolo Gomez Lopez wrote:
> But I also see that forcing an API method invocation as the *only* way of
> registering node types maybe is not the best solution for all deployment
> scenarios.
[skipped]
Custom node type register is 15 minute job, here is an example of how it can be
done.
// get node type manager
NodeTypeManagerImpl ntmgr = (NodeTypeManagerImpl)
workspace.getNodeTypeManager();
logger.info("Registering node types.");
InputStream cnd =
DefaultRepository.class.getClassLoader().getResourceAsStream("custom-node-types.cnd");
// prepare string builder
ByteArrayOutputStream sb = new ByteArrayOutputStream(1024);
// read node definition
copy(cnd, sb, 1024);
// parse and register node definition
StringTokenizer st = new StringTokenizer(sb.toString(), "\\[", true);
while (st.hasMoreTokens()) {
String nd = st.nextToken();
if ("[".equals(nd) && st.hasMoreTokens()) nd += st.nextToken();
try {
logger.debug("Registering node type {" + nd + "}");
ntmgr.registerNodeTypes(new ByteArrayInputStream(nd.getBytes()),
JackrabbitNodeTypeManager.TEXT_X_JCR_CND);
} catch (Exception e) {
if (null != e.getCause() &&
e.getCause().getMessage().contains("already exists")) {
logger.debug("Node {" + nd + "} already registered.", e);
} else {
logger.error("Unable to register node type {" + sb + "}", e);
}
}
}
public static void copy(InputStream in, OutputStream out, int buffer) throws
IOException {
byte[] buf = new byte[buffer];
int read;
while ((read = in.read(buf)) > 0) {
out.write(buf, 0, read);
}
}
--
Ivan Latysh
IvanLatysh@gmail.com
Re: Deploying custom node types in jackrabbit
Posted by James Abley <ja...@gmail.com>.
On 18/02/2008, Manolo Gomez Lopez <pe...@gmail.com> wrote:
> 2008/2/18, Stefan Guggisberg <st...@gmail.com>:
> >
> >
> > >while i agree it could be very convenient in certain scenarios i guess
> > >it can cause
> > >a lot of trouble (how do you handle removed types, illegal
> > >definitions, unsupported
> > >changes etc) if supported in core during bootstrapping. while editing
> > >a text based
> > >definition is certainly trivial, the effects of such changes might be
> > dramatic.
> >
> > >OTOH i think such a feature could be easily implemented as an external
>
> >tool/service.
> > >WDYT?
> >
> > cheers
> > stefan
> >
> > >
> > > Greets,
> > >
> >
>
>
> Yeah, sure, maybe an external tool will be a good idea, but it won't be
> trivial, it should support the three different models of accessing a
> jackrabbit repository, direct, JNDI, RMI... and a way of declaring
> namespaces, or at least guessing them from the provided CND files.
>
> I see that the API approach is well suited for the first two models of
> deployment, where the application code and jackrabbit reside in the same
> location (context). But I think it doesn't fully fit in the RMI scenario
> where there maybe exists a repository administrator and several clients
> without administrative rights, if one wants to control the types of nodes in
> the system.
>
> Maybe I am extending too far the current RMI interface and making jackrabbit
> more service than planned... which leads me to the following: Is there
> any ongoing effort for providing a web services or some sort of remote
> interface ( SOAP, RPC, REST ) to JCR repositories and jackrabbit in
> particular?
>
>
I think that the Apache Abdera project has done some work in terms of
exposing an AtomPub interface to a JCR repository, using jackrabbit as
the underlying implementation. I'm not sure how complete it is, or how
well it would meet your requirement though.
Cheers,
James
Re: Deploying custom node types in jackrabbit
Posted by Manolo Gomez Lopez <pe...@gmail.com>.
2008/2/18, Stefan Guggisberg <st...@gmail.com>:
>
>
> >while i agree it could be very convenient in certain scenarios i guess
> >it can cause
> >a lot of trouble (how do you handle removed types, illegal
> >definitions, unsupported
> >changes etc) if supported in core during bootstrapping. while editing
> >a text based
> >definition is certainly trivial, the effects of such changes might be
> dramatic.
>
> >OTOH i think such a feature could be easily implemented as an external
>tool/service.
> >WDYT?
>
> cheers
> stefan
>
> >
> > Greets,
> >
>
Yeah, sure, maybe an external tool will be a good idea, but it won't be
trivial, it should support the three different models of accessing a
jackrabbit repository, direct, JNDI, RMI... and a way of declaring
namespaces, or at least guessing them from the provided CND files.
I see that the API approach is well suited for the first two models of
deployment, where the application code and jackrabbit reside in the same
location (context). But I think it doesn't fully fit in the RMI scenario
where there maybe exists a repository administrator and several clients
without administrative rights, if one wants to control the types of nodes in
the system.
Maybe I am extending too far the current RMI interface and making jackrabbit
more service than planned... which leads me to the following: Is there
any ongoing effort for providing a web services or some sort of remote
interface ( SOAP, RPC, REST ) to JCR repositories and jackrabbit in
particular?
Greets,
Re: Deploying custom node types in jackrabbit
Posted by Stefan Guggisberg <st...@gmail.com>.
On Feb 18, 2008 1:26 PM, Manolo Gomez Lopez <pe...@gmail.com> wrote:
> Hi Stefan
>
> 2008/2/18, Stefan Guggisberg <st...@gmail.com>:
> >
> >
> >
> > > there was a related feature request:
> > > http://issues.apache.org/jira/browse/JCR-771
> >
> > > cheers
> > > stefan
>
>
>
> I must admit I dind't see that one before asking, sorry.
>
> I agree that maybe using the current internal serialization of custom node
> types (in repository/nodetypes) is not the best solution for helping in the
> deployment of custom node types (but certain not as hard as modifying an
> Oracle tablespace ;)).
>
> But I also see that forcing an API method invocation as the *only* way of
> registering node types maybe is not the best solution for all deployment
> scenarios.
>
> I am thinking in large deployments of pre-configured jackrabbit registries
> with lots of custom node types..., providing a way to give jackrabbit
> representations of the custom node types in CND format in some way at start
> time (other than via API) will certainly ease the deployment of those
> repositories.
>
> I am sure that already having an independent representation of custom node
> types and namespaces in CND (or its counterpart in XML) are solid
> foundations for the implementation os this feature.
>
> Don't you think this feature is worth a try and will be a good improvement
> for jackrabbit?
while i agree it could be very convenient in certain scenarios i guess
it can cause
a lot of trouble (how do you handle removed types, illegal
definitions, unsupported
changes etc) if supported in core during bootstrapping. while editing
a text based
definition is certainly trivial, the effects of such changes might be dramatic.
OTOH i think such a feature could be easily implemented as an external
tool/service.
WDYT?
cheers
stefan
>
> Greets,
>
Re: Deploying custom node types in jackrabbit
Posted by Manolo Gomez Lopez <pe...@gmail.com>.
Hi Stefan
2008/2/18, Stefan Guggisberg <st...@gmail.com>:
>
>
>
> > there was a related feature request:
> > http://issues.apache.org/jira/browse/JCR-771
>
> > cheers
> > stefan
I must admit I dind't see that one before asking, sorry.
I agree that maybe using the current internal serialization of custom node
types (in repository/nodetypes) is not the best solution for helping in the
deployment of custom node types (but certain not as hard as modifying an
Oracle tablespace ;)).
But I also see that forcing an API method invocation as the *only* way of
registering node types maybe is not the best solution for all deployment
scenarios.
I am thinking in large deployments of pre-configured jackrabbit registries
with lots of custom node types..., providing a way to give jackrabbit
representations of the custom node types in CND format in some way at start
time (other than via API) will certainly ease the deployment of those
repositories.
I am sure that already having an independent representation of custom node
types and namespaces in CND (or its counterpart in XML) are solid
foundations for the implementation os this feature.
Don't you think this feature is worth a try and will be a good improvement
for jackrabbit?
Greets,
Re: Deploying custom node types in jackrabbit
Posted by Stefan Guggisberg <st...@gmail.com>.
hi manolo
On Feb 16, 2008 11:10 PM, Manolo Gomez Lopez <pe...@gmail.com> wrote:
> Hi,
>
> We need to have custom node types in our system. I have two questions
> regarding the deployment of those node types.
>
>
> First, we would like to use the 3rd deployment model, where the repository
> gets exposed using RMI, and we noticed (as others) that the remote stub
> that one can get from the RMI server lacks of the appropriate methods needed
> for registering custom node types. I've read somewhere that a change in the
> server and client interfaces is needed to be able to register custom node
> types but there's not many information available.
>
>
> Can anyone give some hint on how to get the appropriate stubs that will
> allow the clients of our model 3 jackrabbit to register custom node types?
>
>
>
>
> Second, I am wondering if there are any plans to allow the registration of
> custom node types without the need of invoking jackrabbit API
> programmatically. As there exists a notation for describing node types and
> their prefixes and namespaces, wouldn't it be easier to store node
> definitions in files and let them be deployed in jackrabbit when found in a
> given directory, following the J2EE pattern of deploying applications?
there was a related feature request:
http://issues.apache.org/jira/browse/JCR-771
cheers
stefan
>
>
> As deployed node types and namespaces at the end are represented using
> files inside jackrabbit's data model on disk, maybe will be a good idea to
> let administrators put node type definitions there for deployment...
>
>
> greets,
>