classpath:/ and mappingDirectoryLocations under solaris

[sutter2k]

I seem to have no problem on windows,linux, or parts of our application that load under tomcat(on any os). i.e. tomcat is loading the classpath.

However, our agent cannot load under solaris(the web interface works fine).

The entry looks like this.



<bean id="sessionFactory" class="org.springframework.orm.hibernate.LocalSessionFact oryBean" singleton="true">
<property name="mappingDirectoryLocations">
<list>
<value>classpath&#58;com/diamondip/ipcontrol/model</value>
</list>
</property>



The only ways I can get this to work are.
--> manually specify all the mapping resources.
-->or. unjar our incontrol.jar add the directory to the classpath (we will not do this, since it screws us up for upgrades). We would like to blow away incontrol.jar everytime.

Has anyone seen similiar type of problems when loading classpath resources?

java.io.FileNotFoundException: class path resource [com/diamondip/ipcontrol/mode
l] cannot be resolved to absolute file path because it does not reside in the fi
le system: URL=[jar:file:/export/home/inc1.0_build37/classes/incontrol.jar!/com/
diamondip/ipcontrol/model]
at org.springframework.core.io.ClassPathResource.getF ile(ClassPathResour
ce.java:108)
at org.springframework.orm.hibernate.LocalSessionFact oryBean.afterProper
tiesSet(LocalSessionFactoryBean.java:337)
at org.springframework.beans.factory.support.Abstract AutowireCapableBean
Factory.invokeInitMethods(AbstractAutowireCapableB eanFactory.java:948)
at org.springframework.beans.factory.support.Abstract AutowireCapableBean
Factory.createBean(AbstractAutowireCapableBeanFact ory.java:284)
at org.springframework.beans.factory.support.Abstract AutowireCapableBean
Factory.createBean(AbstractAutowireCapableBeanFact ory.java:204)
at org.springframework.beans.factory.support.Abstract BeanFactory.getBean
(AbstractBeanFactory.java:199)
at org.springframework.beans.factory.support.Abstract BeanFactory.getBean
(AbstractBeanFactory.java:136)
at org.springframework.beans.factory.support.DefaultL istableBeanFactory.
preInstantiateSingletons(DefaultListableBeanFactor y.java:218)
at org.springframework.context.support.AbstractApplic ationContext.refres
h(AbstractApplicationContext.java:279)
at org.springframework.context.support.ClassPathXmlAp plicationContext.<i
nit>(ClassPathXmlApplicationContext.java:81)
at org.springframework.context.support.ClassPathXmlAp plicationContext.<i
nit>(ClassPathXmlApplicationContext.java:66)
at com.diamondip.netcontrol.taskmgr.TaskManager.start up(TaskManager.java
:231)
at com.diamondip.netcontrol.taskmgr.TaskManager.main( TaskManager.java:39
0)
bash-2.05$[/code]

[sutter2k]

Perhaps this is a bug in org.springframework.core.io.ClassPathResource.

Springs test for !!URL_PROTOCOL_FILE.equals(url.getProtocol()) is incorrect(missing condition).

It seems like its failing for "jar:file".


public File getFile&#40;&#41; throws IOException &#123;
URL url = getURL&#40;&#41;;
/*if &#40;!URL_PROTOCOL_FILE.equals&#40;url.getProtocol&#40;&#41;&#41;&#41; &#123;
throw new FileNotFoundException&#40;getDescription&#40;&#41; + " cannot be resolved to absolute file path " +
"because it does not reside in the file system&#58; URL=&#91;" + url + "&#93;"&#41;;
&#125;*/
return new File&#40;URLDecoder.decode&#40;url.getFile&#40;&#41;&#41;&#41;;
&#125;

[sutter2k]

I take that back. There is a problem. But not with
/*if &#40;!URL_PROTOCOL_FILE.equals&#40;url.getProtocol&#40;&#41;&#41;&#41; &#123;
throw new FileNotFoundException&#40;getDescription&#40;&#41; + " cannot be resolved to absolute file path " +
"because it does not reside in the file system&#58; URL=&#91;" + url + "&#93;"&#41;;
&#125;*/

Really wierd.

[Colin Sampaleanu]

Well, actually there's nothing weird about this :-)

MappingDirectoryLocations needs directories on the filesystem, or really Resources that can resolve to that. It needs to feed Hibernate java File objects which represent these directories.

Now it's kind of a miracle that it works for you even when your jar is unjared. A classpath resouce, as I read the description of Classloader.getResource:
"""Finds the resource with the given name. A resource is some data (images, audio, text, etc) that can be accessed by class code in a way that is independent of the location of the code. The name of a resource is a '/'-separated path name that identifies the resource."""
As I read this, a legal classpath resource name needs the object at the end of the path, not just the path (as you are feeding it). But whatever, in the case that the classpath is expanded on the filesystem, you will get a URL which is a file:xxxx URL pointing to that directory on the filesystem. That can be converted to a File object. In the case of a jar file, you will get a URL of the fomr jar:xxxx that is handled by the system via the jar url handler. There is simply no way you can conver that to a File object, since you are talking about something in a zip file.

So the long and the short of it, is that you will have to point to your mapping files individually, if you want them on the classpath.

[sutter2k]

Thank you, for taking the time to explain this in detail.

Matt

[rnayani]

We tried configuring the LocalSessionFactoryBean to locate the hibernate mapping files in a jar or directory. Neither seems to work. We get the error:

java.io.FileNotFoundException: class path resource [classpath*:hibernate-mapping] cannot be resolved to URL because it does not exist
at org.springframework.core.io.ClassPathResource.getU RL(ClassPathResource.java:147)
at org.springframework.core.io.ClassPathResource.getF ile(ClassPathResource.java:154)
at org.springframework.orm.hibernate.LocalSessionFact oryBean.afterPropertiesSet(LocalSessionFactoryBean .java:463)

Here's how we tried to configure the sessionfactory:

<property name="mappingJarLocations">
<list>
<value>classpath:hibernate-mappings.jar</value>
</list>
</property>

where hibernate-mappings.jar was in the root of the ear

and we tried:

<property name="mappingDirectoryLocations">
<list>
<value>classpath*:hibernate-mapping</value>
</list>
</property>

where the directory was in the root directory of the ear.

Neither works. I saw in your posting that you got it to work with the directory on the file system. Am I doing something wrong? We also tried giving the absolute path of the directory and jar - that didn't work either.

[ccanning]

But in the end, isn't this an error. If I use the standard java class loaders, it correctly finds the files. It is only Spring's code that doesn't. I used to have some code to prove this. If I find the code, I will post it. Shouldn't we file this as a bug?


Well, actually there's nothing weird about this :-)

MappingDirectoryLocations needs directories on the filesystem, or really Resources that can resolve to that. It needs to feed Hibernate java File objects which represent these directories.

Now it's kind of a miracle that it works for you even when your jar is unjared. A classpath resouce, as I read the description of Classloader.getResource:
"""Finds the resource with the given name. A resource is some data (images, audio, text, etc) that can be accessed by class code in a way that is independent of the location of the code. The name of a resource is a '/'-separated path name that identifies the resource."""
As I read this, a legal classpath resource name needs the object at the end of the path, not just the path (as you are feeding it). But whatever, in the case that the classpath is expanded on the filesystem, you will get a URL which is a file:xxxx URL pointing to that directory on the filesystem. That can be converted to a File object. In the case of a jar file, you will get a URL of the fomr jar:xxxx that is handled by the system via the jar url handler. There is simply no way you can conver that to a File object, since you are talking about something in a zip file.

So the long and the short of it, is that you will have to point to your mapping files individually, if you want them on the classpath.