[
https://issues.apache.org/jira/browse/JENA-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin W. updated JENA-328:
---------------------------
Description:
com.hp.hpl.jena.sparql.expr.NodeValue.java: in lines 175ff:
A new instance of a DatatypeFactory is created with .newInstance() --- there
assumptions are made about the classloader. Such things make it difficult to
use Jena in an OSGi-Environment like Virgo.
Here's my fix: (get the correct classloader first and call newInstance with
that classloader as parameter)
{
try {
ClassLoader cl =
com.hp.hpl.jena.sparql.expr.NodeValue.class.getClassLoader();
xmlDatatypeFactory =
DatatypeFactory.newInstance(DatatypeFactory.DATATYPEFACTORY_IMPLEMENTATION_CLASS,
cl) ; }
catch (DatatypeConfigurationException ex)
{ throw new ARQInternalErrorException("Can't create a javax.xml
DatatypeFactory", ex) ; }
}
This fix did it for me. However, the JavaDoc for
DatatypeFactory.DATATYPEFACTORY_IMPLEMENTATION_CLASS states "Users should not
refer to this field; it is intended only to document a factory implementation
detail. "
NOTE: furthermore I added the original exception ex to:
throw new ARQInternalErrorException("Can't create a javax.xml DatatypeFactory",
ex)
I think I have seen similar situations in the Jena source code several times
--- I would like to see the original exception handed over when new ones are
created whenever possible. Using Jena in an OSGi-Environment this would make my
life a lot easier.... ;)
Should i file separate bugs for these things in the future?
For more information on OSGi and classloaders see also
http://stackoverflow.com/questions/1043109/why-cant-jaxb-find-my-jaxb-index-when-running-inside-apache-felix
Hanno Fietz wrote there "... quite nasty problem in OSGi environments when
you're using libraries that aren't designed for OSGi and make assumptions about
the classloader they get."
was:
com.hp.hpl.jena.sparql.expr.NodeValue.java: in lines 175ff:
A new instance of a DatatypeFactory is created with .newInstance() --- there
assumptions are made about the classloader. Such things make it difficult to
use Jena in an OSGi-Environment like Virgo.
Here's my fix: (get the correct classloader first and call newInstance with
that classloader as parameter)
{
try {
ClassLoader cl =
com.hp.hpl.jena.sparql.expr.NodeValue.class.getClassLoader();
xmlDatatypeFactory =
DatatypeFactory.newInstance(DatatypeFactory.DATATYPEFACTORY_IMPLEMENTATION_CLASS,
cl) ; }
catch (DatatypeConfigurationException ex)
{ throw new ARQInternalErrorException("Can't create a javax.xml
DatatypeFactory", ex) ; }
}
This fix did it for me. However, the JavaDoc for
DatatypeFactory.DATATYPEFACTORY_IMPLEMENTATION_CLASS states "Users should not
refer to this field; it is intended only to document a factory implementation
detail. "
NOTE: furthermore I added the original exception ex to:
throw new ARQInternalErrorException("Can't create a javax.xml DatatypeFactory",
ex)
For more information on OSGi and classloaders see also
http://stackoverflow.com/questions/1043109/why-cant-jaxb-find-my-jaxb-index-when-running-inside-apache-felix
Hanno Fietz wrote there "... quite nasty problem in OSGi environments when
you're using libraries that aren't designed for OSGi and make assumptions about
the classloader they get."
Summary: NodeValue makes assumptions about ClassLoader --- "nasty
problem in OSGi environments" (was: NodeValue makes assumptions about
ClassLoader --- "nasty problem is OSGi environments")
> NodeValue makes assumptions about ClassLoader --- "nasty problem in OSGi
> environments"
> --------------------------------------------------------------------------------------
>
> Key: JENA-328
> URL: https://issues.apache.org/jira/browse/JENA-328
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ, Jena
> Affects Versions: Jena 2.7.3
> Environment: OSGi: Virgo Server for Apache Tomcat
> Reporter: Martin W.
> Priority: Minor
>
> com.hp.hpl.jena.sparql.expr.NodeValue.java: in lines 175ff:
> A new instance of a DatatypeFactory is created with .newInstance() --- there
> assumptions are made about the classloader. Such things make it difficult to
> use Jena in an OSGi-Environment like Virgo.
> Here's my fix: (get the correct classloader first and call newInstance with
> that classloader as parameter)
> {
> try {
> ClassLoader cl =
> com.hp.hpl.jena.sparql.expr.NodeValue.class.getClassLoader();
> xmlDatatypeFactory =
> DatatypeFactory.newInstance(DatatypeFactory.DATATYPEFACTORY_IMPLEMENTATION_CLASS,
> cl) ; }
> catch (DatatypeConfigurationException ex)
> { throw new ARQInternalErrorException("Can't create a javax.xml
> DatatypeFactory", ex) ; }
> }
> This fix did it for me. However, the JavaDoc for
> DatatypeFactory.DATATYPEFACTORY_IMPLEMENTATION_CLASS states "Users should not
> refer to this field; it is intended only to document a factory implementation
> detail. "
> NOTE: furthermore I added the original exception ex to:
> throw new ARQInternalErrorException("Can't create a javax.xml
> DatatypeFactory", ex)
> I think I have seen similar situations in the Jena source code several times
> --- I would like to see the original exception handed over when new ones are
> created whenever possible. Using Jena in an OSGi-Environment this would make
> my life a lot easier.... ;)
> Should i file separate bugs for these things in the future?
> For more information on OSGi and classloaders see also
> http://stackoverflow.com/questions/1043109/why-cant-jaxb-find-my-jaxb-index-when-running-inside-apache-felix
> Hanno Fietz wrote there "... quite nasty problem in OSGi environments when
> you're using libraries that aren't designed for OSGi and make assumptions
> about the classloader they get."
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
