You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by David Buchmann <da...@liip.ch> on 2011/05/27 13:38:22 UTC
remove existing namespace
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi,
i noticed that the jcr remoting applet of jackrabbit does not support
the unregisterNamespace method. next thing i tried is the jackrabbit
- --cli option, but again i only see the registernamespace operation.
is there a way to remove an existing namespace? or to correct a wrong
namespace?
say i have registered
myns => http://something
and notice that the correct namespace would be http://some-thing
the only possibility i found is re-registering a mapping that moves
http://something to a different prefix, then add "myns" with the correct
uri again.
but this way, the wrong namespace with a dummy mapping will stay in my
repository forwever... can i get rid of it?
cheers,david
- --
Liip AG // Agile Web Development // T +41 26 422 25 11
CH-1700 Fribourg // PGP 0xA581808B // www.liip.ch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk3fjSoACgkQqBnXnqWBgIveSACfXBEZ5qAiJ5m0lLya9Dsy638H
pUEAoJBmhfT86n8jybNCMk+D9tIIqLr3
=FhTs
-----END PGP SIGNATURE-----
Re: remove existing namespace
Posted by David Buchmann <da...@liip.ch>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi angela,
thanks a lot for the clarification, now i know for sure :-)
cheers,
david
Am 30.05.2011 15:46, schrieb Angela Schreiber:
> hi david
>
>> i noticed that the jcr remoting applet of jackrabbit does not support
>> the unregisterNamespace method. next thing i tried is the jackrabbit
>> - --cli option, but again i only see the registernamespace operation.
>>
>> is there a way to remove an existing namespace? or to correct a wrong
>> namespace?
>
> while the jcr-remoting supports unregistration of namespaces, i think
> this doesn't work due to a limitation in jackrabbit-core, which doesn't
> support unregistration of namespaces:
>
> the API method implementation in
> org.apache.jackrabbit.core.NamespaceRegistryImpl#unregisterNamespace
> states:
>
> /**
> * as we can't guarantee that there are no references to the specified
> * namespace (in names of nodes/properties/node types etc.) we simply
> * don't allow it.
> */
>
> regards
> angela
>
>> but this way, the wrong namespace with a dummy mapping will stay in my
>> repository forwever... can i get rid of it?
>
> you could modify the corresponding ns*.properties file if you are
> really sure that you know what you are doing... but this is obviously
> not recommended for the same reasons mentioned in the code.
- --
Liip AG // Agile Web Development // T +41 26 422 25 11
CH-1700 Fribourg // PGP 0xA581808B // www.liip.ch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk3k2DsACgkQqBnXnqWBgIu8agCgvYzebLepzjKSTKq1Awr8usMC
0IMAnjb4s6WPVSnAKI9fI2873PTb63gm
=jMRX
-----END PGP SIGNATURE-----
Re: remove existing namespace
Posted by Angela Schreiber <an...@adobe.com>.
hi david
> i noticed that the jcr remoting applet of jackrabbit does not support
> the unregisterNamespace method. next thing i tried is the jackrabbit
> - --cli option, but again i only see the registernamespace operation.
>
> is there a way to remove an existing namespace? or to correct a wrong
> namespace?
while the jcr-remoting supports unregistration of namespaces, i think
this doesn't work due to a limitation in jackrabbit-core, which doesn't
support unregistration of namespaces:
the API method implementation in
org.apache.jackrabbit.core.NamespaceRegistryImpl#unregisterNamespace
states:
/**
* as we can't guarantee that there are no references to the specified
* namespace (in names of nodes/properties/node types etc.) we simply
* don't allow it.
*/
regards
angela
> but this way, the wrong namespace with a dummy mapping will stay in my
> repository forwever... can i get rid of it?
you could modify the corresponding ns*.properties file if you are
really sure that you know what you are doing... but this is obviously
not recommended for the same reasons mentioned in the code.