You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by "ASF subversion and git services (JIRA)" <ji...@apache.org> on 2013/12/17 19:24:07 UTC

[jira] [Commented] (JENA-328) NodeValue makes assumptions about ClassLoader --- "nasty problem in OSGi environments"

    [ https://issues.apache.org/jira/browse/JENA-328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13850739#comment-13850739 ] 

ASF subversion and git services commented on JENA-328:
------------------------------------------------------

Commit 1551647 from [~andy.seaborne] in branch 'jena/trunk'
[ https://svn.apache.org/r1551647 ]

JENA-328 : Armour the file access code against SecurityExceptions.

> 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.
>            Assignee: Damian Steer
>            Priority: Minor
>             Fix For: ARQ 2.9.4
>
>         Attachments: Apache Tomcat 7.0.26 - Error report.htm
>
>
> 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 was sent by Atlassian JIRA
(v6.1.4#6159)