Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spring component scanning does not work within JBoss EJB container [SPR-5120] #9793

Closed
spring-issuemaster opened this issue Aug 27, 2008 · 48 comments

Comments

@spring-issuemaster
Copy link
Collaborator

commented Aug 27, 2008

Pedro Santos opened SPR-5120 and commented

The spring scanner functionality do not work when I create my ApplicationContext from a EJB managed by JBoss. I do test the same spring application context on diferents enviroments. Just on a managed EJB on a JBoos it is not workin.

EJB code
appContext = new GenericApplicationContext();
ClassPathBeanDefinitionScanner scanner = new ClassPathBeanDefinitionScanner(appContext);
scanner.scan("com");
appContext.refresh();

Annotated class
@Service
public class TransactionService {

Exception
ERROR: org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'transactionService' is defined


Affects: 2.5.5

Attachments:

Issue Links:

  • #10814 JBoss AS 5.0 VFS handling (SPR-5120) backport 2.5.X ("is depended on by")
  • #11051 Context Scanning doesnt work in Jboss 5 ("is duplicated by")
  • #10013 PathMatchingResourcePatternResolver.determineRootDir fails for jar on JBoss
  • #10454 PersistenceUnitReader#determinePersistenceUnitRootUrl returns wrong root url on JBoss 5, causing no detection of entity beans

Referenced from: commits 184f63f, 10c30f0, 64c46d4

24 votes, 34 watchers

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 27, 2008

Juergen Hoeller commented

Well, I suppose that the JBoss EJB container does not properly resolve your "com" package in the classpath there. This is what Spring's component scanner relies on.

You could give the following a try:

myEjb.getClass().getClassLoader().getResources("com")

and see what gets returned there. If that unexpectedly correctly resolves all roots of the "com" package in the classpath, try the following:

appContext.setClassLoader(myEjb.getClass().getClassLoader());

before calling the component scanner. In general, always make sure that the ApplicationContext is configured with the correct target ClassLoader.

Juergen

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 28, 2008

Pedro Santos commented

The classloader correct resolves the jar resources, the problem are ocuring when spring try to get the resouce as a File object and can't do that cause the protocol used is "vfszip".

class: ResourceUtils
method: getFile
implementation:
if (!URL_PROTOCOL_FILE.equals(resourceUrl.getProtocol())) {
throw new FileNotFoundException(
description + " cannot be resolved to absolute file path " +
"because it does not reside in the file system: " + resourceUrl);
}

There is one workaround for it? Except the xml one...

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 28, 2008

Juergen Hoeller commented

When exactly is that ResourceUtils.getFile method called during component scanning in your case? I suppose during PathMatchingResourcePatternResolver.findPathMatchingResources? The actual problem is then probably the preceding isJarURL check that doesn't detect "vfszip" as jar files yet...

I've added "vfszip" for 2.5.6; this will be available in tonight's 2.5.6 snapshot (http://static.springframework.org/downloads/nightly/snapshot-download.php?project=SPR). It would be great if you could give that snapshot a try against your JBoss environment...

Juergen

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 28, 2008

Pedro Santos commented

Exactly:

org.springframework.core.io.support.PathMatchingResourcePatternResolver.findPathMatchingResources(PathMatchingResourcePatternResolver.java:336)
org.springframework.core.io.support.PathMatchingResourcePatternResolver.getResources(PathMatchingResourcePatternResolver.java:263)
org.springframework.context.support.AbstractApplicationContext.getResources(AbstractApplicationContext.java:1019)
org.springframework.context.support.GenericApplicationContext.getResources(GenericApplicationContext.java:192)
org.springframework.context.annotation.ClassPathScanningCandidateComponentProvider.findCandidateComponents(ClassPathScanningCandidateComponentProvider.java:177)
org.springframework.context.annotation.ClassPathBeanDefinitionScanner.doScan(ClassPathBeanDefinitionScanner.java:201)
org.springframework.context.annotation.ClassPathBeanDefinitionScanner.scan(ClassPathBeanDefinitionScanner.java:180)

ok, i will test this on 2.5.6 version. I return the result...

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Sep 1, 2008

Pedro Santos commented

the incompatibility still remains, I'm geting this error now:

Caused by: java.io.FileNotFoundException: C:\jboss\server\default\deploy\VO-ejbEAR.ear\VO-ejb.jar\com (the system can't find de specified path)
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.<init>(Unknown Source)
at java.util.jar.JarFile.<init>(Unknown Source)
at java.util.jar.JarFile.<init>(Unknown Source)
at org.springframework.core.io.support.PathMatchingResourcePatternResolver.doFindPathMatchingJarResources(PathMatchingResourcePatternResolver.java:448)
at org.springframework.core.io.support.PathMatchingResourcePatternResolver.findPathMatchingResources(PathMatchingResourcePatternResolver.java:339)
at org.springframework.core.io.support.PathMatchingResourcePatternResolver.getResources(PathMatchingResourcePatternResolver.java:263)
at org.springframework.context.support.AbstractApplicationContext.getResources(AbstractApplicationContext.java:1019)
at org.springframework.context.annotation.ClassPathScanningCandidateComponentProvider.findCandidateComponents(ClassPathScanningCandidateComponentProvider.java:182)
... 100 more

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Sep 1, 2008

Pedro Santos commented

I was looking at the problem... the "vfszip" url protocol is not recognized as a JarURLConnection.
So the String urlFile of resource is /C:/jboss/server/default/deploy/VO-ejbEAR.ear/VO-ejb.jar/com/. This format isn't expected on doFindPathMatchingJarResources implementation.
What rapens is that the jarFileUrl is incorrectly resolved as "C:\jboss\server\default\deploy\VO-ejbEAR.ear\VO-ejb.jar\com" (with the package 'com' path) and de jar can't be located on system.

I search this protocol on internet and find no documentation for it... this kind of improvment can to be made?

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Sep 1, 2008

Juergen Hoeller commented

I'm not aware of any such protocol documentation either...

You could try to debug the doFindPathMatchingJarResources method and see what it encounters there: in particular, what kind of URLConnection it gets that isn't a JarURLConnection. Unfortunately, if we are not getting a URLConnection that allows us to introspect the contents of the affected archive, then all we can do is to try to locate the archive file in the file system (the code path where the exception above comes from) . The latter doesn't work properly if the jar is nested in another archive, such as in an EAR file.

Juergen

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Oct 22, 2008

Juergen Hoeller commented

I'm afraid we can't do anything about this for the moment. To be reopened once there is way to perform such scanning on JBoss - if there is enough demand for Spring component scanning in a JBoss EJB jar to begin with.

Juergen

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Dec 30, 2008

Daniel Gredler commented

It's unfortunate that ResourceUtils.isJarURL(URL) was modified to account for JBoss 5's new VFS URLs, but PathMatchingResourcePatternResolver.doFindPathMatchingJarResources(Resource, String) was not updated to account for these URLs.

As per the code comments in doFindPathMatchingJarResources, this method assumes a JAR URL format of "jar:path!/entry"; however, VFS apparently doesn't include the exclamation character(ie, "jar:path/entry" instead of "jar:path!/entry"). It should be sufficient to look for ".jar/" (or any of the other JAR variants: EAR, WAR, etc) instead of "!/", with appropriate modifications to the path split indices.

The resolution to this bug is "deferred"; are you planning on fixing this for 3.0.0? Do you plan on releasing a 2.5.7? Thanks for any info!

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 5, 2009

Al Robertson commented

I'm getting the same problem. And just to clarify, it's not just EJB jars. It's any jar at the EAR level, referenced from the WAR manifest classpath.
We have our spring config contained in such a jar so it's a bit of a JBoss5 blocker at the moment.
I'll try and dig up some more info about vfszip.
Al

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 10, 2009

Ales Justin commented

You can use my VFS based impl of ResourcePatternResolver.
Read more about it here:

Juergen, what would be the best place for this code?
Some our place? - Then I need to find a better more common/general place for it than AS sub-project.
Or should we host it under Spring code?

Perhaps you can also update the VFS usage in JBoss5
as we've encountered some serious performance problems:

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 20, 2009

Ales Justin commented

Attaching a jboss-as-spring-int.jar which includes this VFS bridge.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 29, 2009

dkp commented

This really is a very big problem, it occurs indeed in any jar or war inside an ear.

Justin, I'm sorry if this is a stupid question, but I don't understand how I have to use your provided jar file. Where do I place it, and how do I make spring use it ?

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 29, 2009

Ales Justin commented

And you need to place the jar somewhere in app's classpath.
Either directly in the app or in more global JBoss server/common/lib.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 29, 2009

dkp commented

thx

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Mar 9, 2009

Marius Bogoevici commented

Juergen,

I re-opened the issue, since there currently is an implementation that is capable to treat the VFS URLs correctly. As Ales has mentioned before, the Spring Deployer in JBoss already uses a ResourcePatternResolver that solves this problem.

The implementation is here:
http://anonsvn.jboss.org/repos/jbossas/trunk/spring-int/src/main/org/jboss/spring/io/

However, what lacks at this point, is a proper way to easily integrate this with the mainstream Spring code. The only way for an ApplicationContext to customize its ResourcePatternResolver is by overriding getResourcePatternResolver(). In practice, this means that for being able to use Spring in JBoss AS5, one needs to create its own ApplicationContext subtypes for being able to deal with such scenarios as classpath scanning for bean definitions, or using pattern-based context configuration locations. Otherwise, regular applications (including simple wars) won't work out of the box, when it comes to dealing with pattern-based resource paths. Typical failure scenarios and user-provided solutions are listed here:

http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4213444

(The main cause being that the bootstrapped XmlWebApplicationContext uses a ServletContextResourcePatternResolver, which in turn delegates to its base PathMatchingResourcePatternResolver, which cannot treat the resource path correctly, nor be easily replaced with the extended VFSResourcePatternResolver, unless the user modifies the code or extends the base class).

So, what seems to be needed here is a pluggable mechanism, so that a specific protocol, such as vfszip, could be resolved (resource loaded, path scanned, etc) through a specific strategy (like, for example, VFSResourcePatternResolver), that could be picked up from the classpath (and provided as part of the JBoss support libraries).

Regards,
Marius

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Mar 17, 2009

Ales Justin commented

I refactored our Spring integration into separate project:

This VFS support is now a module in this new integration project
and I also renamed the last "io" package to "vfs":

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Apr 28, 2009

David Ward commented

At Alfresco we also struggled getting our Spring-based framework working on JBoss 5. We have lots of bean definition files using classpath-based pattern matching. E.g.:

Code:
<import resource="classpath*:alfresco/patch/*-context.xml"/>

FYI I eventually created a subclass of XmlWebApplicationContext that used a generalized version of Ales's VFSResourcePatternResolver that subclassed ServletContextResourcePatternResolver. I had to fix the logic to deal with relative path matching and matching of directories. I also made the resolver behave as normal on other app servers when not dealing with vfs URLs.

See http://svn.alfresco.com/repos/alfresco-open-mirror/alfresco/HEAD/root/projects/core/source/java/org/alfresco/config/JBossEnabledWebApplicationContext.java and associated classes.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented May 3, 2009

John A commented

So I just want to make sure I get this correct, before I decide how to approach it..

The Alfresco guys and the JBoss guys both seem to have (very similar) resolutions to this issue, which seem to indicate fixing it by handling VFS a bit nicer.

so if I check out and compile the source here: http://anonsvn.jboss.org/repos/jbossas/projects/spring-int/trunk/vfs/src/main/java/org/jboss/spring/vfs/ then build my app against that, everything should be fine then, right? i'd have to replace my classpathxml with these new jboss friendly ones?

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented May 3, 2009

Ales Justin commented

Afaik, Marius just finished porting/matching Alfresco's fixes to our codebase.
This is the xml app context class that knows how to handle vfs: http://anonsvn.jboss.org/repos/jbossas/projects/spring-int/trunk/deployers/src/main/java/org/jboss/spring/factory/VFSXmlWebApplicationContext.java

The whole project is mavenized, hence it's trivial to build the artifacts.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented May 3, 2009

John A commented

Sorry, but which "project" is that? I don't see spring-int anywhere on the jboss site. Is this something that's going to come w/ 5.1?

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented May 3, 2009

Ales Justin commented

It's not meant to be a "real" project atm (at least not yet).
Currently it's only meant to provide missing glue code for various pieces.
I do think we'll eventually setup a proper project page, w/ downloads and all.
But atm you need to build it on your own from here: http://anonsvn.jboss.org/repos/jbossas/projects/spring-int/trunk/
(ps: I'll create a proper 1.0.0.Alpha1 release soon; once we resolve some of the ongoing issues)

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented May 4, 2009

John A commented

Ok, so making this change did in fact fix my issue. However, there seems to be some compatibility issues w/ loading Hibernate resources. Currently, we're calling getResources("classpath*:**/*.hbm.xml") against the app context. Any ideas for a work around? If it helps I'm currently running this against JB-AS 5.1

Thanks!

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented May 4, 2009

Marius Bogoevici commented

John,

Can you provide some details on the issues you're encountering? Error messages, etc?

Thanks,
Marius

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented May 4, 2009

John A commented

We have a chunk of code

public static Resource[] getResources(String path) {
	Resource[] res;
	try {
		res = ac.getResources(path);
	} catch (IOException e) {
		throw new InitException("i/o error while asking for resources, path:" + path,e);
	}
	return res;
}

Which is invoked in the following manner: CoreInit.getResources("classpath*:**/*.hbm.xml")

And ac is now a VFSXmlWebApplicationContext.

The exception gets thrown. This works fine on a tomcat install w/o the VFSXmlWebApplicationContext, so I assume something similar has to get fixed to make this work.

The relevant part of the exception:

Caused by: java.io.IOException: Child not found opt/jboss/jboss-5.1.0.CR1/server/default/deployers/jbossweb.deployer/ for MemoryContextHandler@1682498437[path= context=vfsmemory://4sg3s5y-u98501-fuba1p5t-1-fuba29fj-28 real=vfsmemory://4sg3s5y-u98501-fuba1p5t-1-fuba29fj-28], available children: []
at org.jboss.virtual.plugins.registry.DefaultVFSRegistry.findHandler(DefaultVFSRegistry.java:108)
at org.jboss.virtual.plugins.registry.DefaultVFSRegistry.getFile(DefaultVFSRegistry.java:87)
at org.jboss.virtual.plugins.registry.DefaultVFSRegistry.getFile(DefaultVFSRegistry.java:120)
at org.jboss.virtual.VFS.getRoot(VFS.java:264)
at org.jboss.spring.vfs.VFSResourcePatternResolvingHelper.getVFSResources(VFSResourcePatternResolvingHelper.java:77)
at org.jboss.spring.vfs.VFSResourcePatternResolvingHelper.locateResources(VFSResourcePatternResolvingHelper.java:61)
at org.jboss.spring.vfs.VFSServletContextResourcePatternResolver.findPathMatchingResources(VFSServletContextResourcePatternResolver.java:51)
at org.springframework.core.io.support.PathMatchingResourcePatternResolver.getResources(PathMatchingResourcePatternResolver.java:244)
at org.springframework.context.support.AbstractApplicationContext.getResources(AbstractApplicationContext.java:1019)
... 78 more

Not sure why it's trying to go all the way down there. I embedded the JAR files in the war file (which is in an ear file).

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented May 4, 2009

Marius Bogoevici commented

OK, thanks, I'll look into it.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented May 7, 2009

Marius Bogoevici commented

John,

The issue you were encountering was due to https://jira.jboss.org/jira/browse/JBVFS-109, which will be fixed in JBoss 5.1.0GA. See the issue for more details.

Regards,
Marius

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented May 7, 2009

Juergen Hoeller commented

Marius, Ales,

It would be great if we could extract the minimum that's needed to make classpath scanning work on JBoss 5, and include it in Spring 3.0 proper. However, I'm a bit unclear on what it actually takes there.

Does the situation change on JBoss 5.1? Do we really need full-fledged VFS API usage in order to sort this out? We could bake reflective checks into PathMatchingResourcePatternResolver itself, I suppose... Concrete patches against PathMatchingResourcePatternResolver would be very welcome - possibly using VFS API internally only, guarded by some VFS API presence checks.

Compiling PathMatchingResourcePatternResolver against a VFS API jar wouldn't be a problem, as long as that optional API usage does not impose runtime requirements on non-JBoss users. Compare PathMatchingResourcePatternResolver's existing optional use of Equinox OSGi API, if present.

Juergen

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented May 7, 2009

Marius Bogoevici commented

Juergen,

Thanks for the reply. Good to see this being sorted out before the release of 3.0 :).

I'll upload a patch shortly, tomorrow at latest. Is there any way to backport this to 2.5.x? Case in which I could provide a similar patch for that, too.

Noted your comments - it's pretty much what I had in mind for this, too. The VFS API we are working against does not change in 5.1, but there is a strict VFS issue (JBVFS-109) mentioned above, which affects JBoss AS 5.0 (now fixed), and which makes using "classpath*:**/<something>" resources problematic.

Marius

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented May 12, 2009

Marius Bogoevici commented

Juergen,

I added a patch for this issue, which overrides the default behaviour of PathMatchingResourcePatternResolver in the case of JBoss 5.x.

This compiles against JBoss-vfs 2.1.0.GA which can be acquired from here (and it can run against newer versions, like 2.1.2 GA and higher).

Thanks,
Marius

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented May 12, 2009

Canny Duck commented

Please provide a 2.5.X backport. This is a heay weight problem at the moment.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented May 12, 2009

David Ward commented

Thanks for the acknowledgement on the source. Note that I also had to change RECURSE_LEAVES_ONLY to RECURSE to get equivalent behaviour to base Spring (which would return directories as well as files matching a pattern). I also think it would be worthwhile if VFSResource extended AbstractResource (as in the Alfresco implementation) so that hashCode, equals, etc. are implemented. Without this, I'm surprised you can add a VFSResource to a HashSet!

Also, do we still need VFS support in ResourceLoader (as in the Alfresco implementation)? Would getResource("mypath/myresource").getFile() throw an exception where otherwise it wouldn't have on JBoss 4 or Tomcat?

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented May 13, 2009

Marius Bogoevici commented

David,

Thanks for pointing these things out - you can add a VFSResource to a HashSet - but, yes - the main problem is that if you have overlapping patterns your Resources will be added twice, not quite something you want to see.

Actually, there is an issue with treating "classpath:<resource-path>" correctly and I will upload another patch shortly.

Marius

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented May 13, 2009

Marius Bogoevici commented

So, here's the new patch: vfs-fixes-2.patch.

It incorporates the additions to VfsResource indicated by David, as well as some further changes.

Juergen, I think that isolating delegation in ResourceUtil was the right decision in this case, even if making ResourceUtil know about the delegates expands its scope for a bit.

Having to choose between addressing the issue by modifying the ResourceLoader (as we have done in jboss-spring-int) to return a different Resource implementation and trying to make the existing Resource implementations work correctly, I went for the latter. So this makes sure that on a JBoss Application Server, URLs and URIs starting with "vfszip:" are processed correctly by ResourceUtils.getFile(), as well as making sure that resources having URLs starting with vfs* are navigated correctly.

Cheers, and thanks the feedback,
Marius

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented May 13, 2009

Marius Bogoevici commented

vfs-fixes-3.patch:

A small fix adding equals() and hashCode() implementations to VFSResource (the default is based on getDescription() which delegates to VirtualFileHandler).

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented May 27, 2009

Antony Stubbs commented

Related to http://jira.springsource.org/browse/SPR-5784 - probably actually duplicated by. But demonstrates the issue none-the-less.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented May 27, 2009

Antony Stubbs commented

P.s. http://jira.springsource.org/browse/SPR-5784 also demonstrates a quick work-around for my situation.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jun 11, 2009

Paul Dzilenski commented

Are the changes in the "vfs-fixes-3.patch" patch going to be incorporated into Spring 3.0 RC1?

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 14, 2009

Stefan Schmidt commented

In our Roo 1.0.0.RC1 testing of the petclinic.roo script against JBoss 5.10.GA we encounter an exception which appears to be related to this issue:

Context initialization failed
org.springframework.beans.factory.BeanDefinitionStoreException: Could not resolve bean definition resource pattern [classpath*:applicationContext*.xml]; nested exception is java.io.FileNotFoundException: File not found
at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:190)
at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:149)
at org.springframework.web.context.support.XmlWebApplicationContext.loadBeanDefinitions(XmlWebApplicationContext.java:125)
at org.springframework.web.context.support.XmlWebApplicationContext.loadBeanDefinitions(XmlWebApplicationContext.java:93)

Juergen, I'd be happy to test any new Spring Framework snapshot you produce against Roo and JBoss 5 and see if it is resolves the above. Please just let me know.

-Stefan

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 13, 2009

Andre Paes Rodrigues commented

The component scanning is not working even for .class files inside WEB-INF/classes, not just jar files. For that JBoss uses the vfsfile protocol, which is also not supported by Spring. This is a big blocker for us since we're trying to migrate our applications from JBoss 4.2.3 to JBoss 5.1.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 14, 2009

Marius Bogoevici commented

Attached "jboss-spring-int-vfs.jar" that contains utilities for handling classpath scanning in JBoss AS5.

For web applications, use org.jboss.spring.vfs.context.VFSXmlWebApplicationContext throught the 'contextClass' parameter in either ContextLoaderListener, or DispatcherServlet.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 14, 2009

Marius Bogoevici commented

Andre,

See my comment above. You can also take a look at the whole http://anonsvn.jboss.org/repos/jbossas/projects/spring-int/branches/1_0/.

Hope that helps,
Marius

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Sep 11, 2009

Thomas Risberg commented

I have committed a revised patch for this issue. Moved methods from ResourceUtils to a separate ResourceHandlingUtils in the core.io.support package to avoid dependency cycles between packages.

-Thomas

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Sep 16, 2009

David Ward commented

At Alfresco we found that the VFSResource implementation still didn't work with some of our webapps that would work in Tomcat.

For example this context file that uses ".." in a relative URL

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE beans PUBLIC '-//SPRING//DTD BEAN//EN' 'http://www.springframework.org/dtd/spring-beans.dtd'>
<beans>
<!--
The bean definitions for this subsystem are shared by the ldap and ldap-ad subsystems with different property
defaults
-->
<import resource="../common-ldap-context.xml" />
</beans>

We fixed our own VFSResource implementation as follows

public Resource createRelative(String relativePath) throws IOException
{
    return new VFSResource(VFS.getRoot(new URL(getURL(), relativePath)));
}

Please consider reopening this issue and fixing as above.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Sep 17, 2009

Marius Bogoevici commented

Thomas,

FIrst, thanks for comitting the patch. Also, David is right - and I made the changes in our code as per https://jira.jboss.org/jira/browse/JBSPRING-4, so it would be a good idea if same would be done for Spring 3.0.

Thanks,
Marius

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Sep 17, 2009

Thomas Risberg commented

modified createRelative according to David Ward's suggestion for JBSPRING-4

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Sep 24, 2009

Sundar Sankarnarayanan commented

Hi All
Thanks for making the component scan work. Even though this Jira talks of EJB with Jboss 5, I was wondering if component-scanning in general would work with Jboss 5.

I had posted something on the forum a while back (http://forum.springsource.org/showthread.php?t=71541) and had not created a jira for my problem as I felt it was related to the one mentioned here. Am putting in this component to make sure if I was right or not.

Thanks
Sundar

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.