You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by "ken.p" <ke...@gmail.com> on 2009/02/12 05:14:10 UTC
javax.jcr.NamespaceException
I ran to issue:
Exception in thread "main" javax.jcr.NamespaceException: : is not a
registered namespace
when using IBM jdk, it works fine on Sun jdk. Any work around available as
deployment environment will be on IBM jdk.
version 1.4.x
--
View this message in context: http://www.nabble.com/javax.jcr.NamespaceException-tp21969656p21969656.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: javax.jcr.NamespaceException
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Thu, Feb 12, 2009 at 12:08 PM, Thomas Fromm <tf...@inubit.com> wrote:
> Of course there are APIs... but implementing them will take alot of time
> instead extend from a class and overwrite some methods or have access to some
> members...
> Sure potentially the extended class needs to be modified after update, but
> this is a normal thing. The user is not forced to extend, but he has the
> option to with all possibilitys and risks.
Instead of extending internal Jackrabbit classes I would encourage you
to simply *modify* them. Get the source release or an svn checkout,
make the modifications you need, and build your own custom version of
Jackrabbit. The source is open. :-)
If your customizations are generally useful, you can contribute them
back and we'll include them in the next release. Alternatively, if you
have a good case for an extension that only makes sense in your
environment, you can propose that we add an extension point for
plugging in such custom behaviours. In this case I don't see why the
entire fix couldn't be included directly in Jackrabbit.
BR,
Jukka Zitting
Re: javax.jcr.NamespaceException
Posted by Thomas Fromm <tf...@inubit.com>.
On Thursday 12 February 2009 11:51, Stefan Guggisberg wrote:
> > I wrote an ugly workaround, which works for me.
> > (Normally you need also to extend/modify
> > org.apache.jackrabbit.core.query.lucene.FileBasedNamespaceMappings.java,
> > but thats not nessesary for me.)
> > Unfortunality the jackrabbit creators likes to use of private
> > methods/members. So extending their code is mostly impossible.
>
> i would argue that access modifiers in jackrabbit core have been
> chosen thoughtfully
> in general. the jackrabbit core classes are not primarily designed to
> be extensible.
> there are specific APIs that can be implemented. if a member or method has
> been declared private there's probably a good reason for it (e.g. the
> implementation might
> change in the future and therefore potentially break subclasses etc).
Of course there are APIs... but implementing them will take alot of time
instead extend from a class and overwrite some methods or have access to some
members...
Sure potentially the extended class needs to be modified after update, but
this is a normal thing. The user is not forced to extend, but he has the
option to with all possibilitys and risks.
just my 2 cents...
Re: javax.jcr.NamespaceException
Posted by Stefan Guggisberg <st...@gmail.com>.
On Thu, Feb 12, 2009 at 8:06 AM, Thomas Fromm <tf...@inubit.com> wrote:
> On Thursday 12 February 2009 05:14, ken.p wrote:
>> I ran to issue:
>> Exception in thread "main" javax.jcr.NamespaceException: : is not a
>> registered namespace
>>
>> when using IBM jdk, it works fine on Sun jdk. Any work around available as
>> deployment environment will be on IBM jdk.
>
> The problem is, that the IBM JDK allow no empty keys inside their property
> files.
>
> There exists a issue for Jackrabbit, but ATM nobody wants to fix it.
here's the issue:
http://issues.apache.org/jira/browse/JCR-888
i agree that there hasn't been a lot of enthousiasm to fix this issue.
i would argue that this is a rather exotic issue which doesn't affect
the majority of the users. it only occurs with the ibm jvm and the
workaround is to use another jvm (e.g. sun's).
OTOH i agree that it should be fixed eventually. feel free to contribute
a patch which doesn't break compatibility. see my related comment
on the issue.
> I wrote an ugly workaround, which works for me.
> (Normally you need also to extend/modify
> org.apache.jackrabbit.core.query.lucene.FileBasedNamespaceMappings.java, but
> thats not nessesary for me.)
> Unfortunality the jackrabbit creators likes to use of private methods/members.
> So extending their code is mostly impossible.
i would argue that access modifiers in jackrabbit core have been
chosen thoughtfully
in general. the jackrabbit core classes are not primarily designed to
be extensible.
there are specific APIs that can be implemented. if a member or method has been
declared private there's probably a good reason for it (e.g. the
implementation might
change in the future and therefore potentially break subclasses etc).
cheers
stefan
>
> public static class DefaultRepository extends RepositoryImpl implements
> Repository {
>
> public DefaultRepository(RepositoryConfig config) throws Exception {
> super(config);
> }
>
> protected NamespaceRegistryImpl createNamespaceRegistry(FileSystem fs)
> throws RepositoryException {
> return new MyNamespaceRegistryImpl(fs);
> }
> }
>
> public class MyNamespaceRegistryImpl extends NamespaceRegistryImpl {
>
>
> protected MyNamespaceRegistryImpl(FileSystem nsRegStore)
> throws RepositoryException {
> super(nsRegStore);
> }
>
> public void unregisterNamespace(String prefix)
> throws NamespaceException,
> UnsupportedRepositoryOperationException,
> AccessDeniedException, RepositoryException {
> if("".equals(prefix)){
> return;
> }
> super.unregisterNamespace(prefix);
> }
>
> public String[] getPrefixes() throws RepositoryException {
> List<String> prefixList=new ArrayList<String>();
> for(String prefix : super.getPrefixes()){
> prefixList.add(prefix);
> }
> if(!prefixList.contains("")){
> prefixList.add("");
> }
> return prefixList.toArray(new String[0]);
> }
>
> public String[] getURIs() throws RepositoryException {
> List<String> uriList=new ArrayList<String>();
> for(String uri : super.getPrefixes()){
> uriList.add(uri);
> }
> if(!uriList.contains("")){
> uriList.add("");
> }
> return uriList.toArray(new String[0]);
> }
>
> public String getURI(String prefix) throws NamespaceException {
> if("".equals(prefix)){
> return "";
> }
> return super.getURI(prefix);
> }
>
> public String getPrefix(String uri) throws NamespaceException {
> if("".equals(uri)){
> return "";
> }
> return super.getPrefix(uri);
> }
> }
>
>
>
Re: javax.jcr.NamespaceException
Posted by Thomas Fromm <tf...@inubit.com>.
On Thursday 12 February 2009 05:14, ken.p wrote:
> I ran to issue:
> Exception in thread "main" javax.jcr.NamespaceException: : is not a
> registered namespace
>
> when using IBM jdk, it works fine on Sun jdk. Any work around available as
> deployment environment will be on IBM jdk.
The problem is, that the IBM JDK allow no empty keys inside their property
files.
There exists a issue for Jackrabbit, but ATM nobody wants to fix it.
I wrote an ugly workaround, which works for me.
(Normally you need also to extend/modify
org.apache.jackrabbit.core.query.lucene.FileBasedNamespaceMappings.java, but
thats not nessesary for me.)
Unfortunality the jackrabbit creators likes to use of private methods/members.
So extending their code is mostly impossible.
public static class DefaultRepository extends RepositoryImpl implements
Repository {
public DefaultRepository(RepositoryConfig config) throws Exception {
super(config);
}
protected NamespaceRegistryImpl createNamespaceRegistry(FileSystem fs)
throws RepositoryException {
return new MyNamespaceRegistryImpl(fs);
}
}
public class MyNamespaceRegistryImpl extends NamespaceRegistryImpl {
protected MyNamespaceRegistryImpl(FileSystem nsRegStore)
throws RepositoryException {
super(nsRegStore);
}
public void unregisterNamespace(String prefix)
throws NamespaceException,
UnsupportedRepositoryOperationException,
AccessDeniedException, RepositoryException {
if("".equals(prefix)){
return;
}
super.unregisterNamespace(prefix);
}
public String[] getPrefixes() throws RepositoryException {
List<String> prefixList=new ArrayList<String>();
for(String prefix : super.getPrefixes()){
prefixList.add(prefix);
}
if(!prefixList.contains("")){
prefixList.add("");
}
return prefixList.toArray(new String[0]);
}
public String[] getURIs() throws RepositoryException {
List<String> uriList=new ArrayList<String>();
for(String uri : super.getPrefixes()){
uriList.add(uri);
}
if(!uriList.contains("")){
uriList.add("");
}
return uriList.toArray(new String[0]);
}
public String getURI(String prefix) throws NamespaceException {
if("".equals(prefix)){
return "";
}
return super.getURI(prefix);
}
public String getPrefix(String uri) throws NamespaceException {
if("".equals(uri)){
return "";
}
return super.getPrefix(uri);
}
}