Spring fails to find @Component bean if classpath scanning is used

[GoogleCodeExporter]

What version of the product are you using? On what operating system?

onejar-maven-plugin 1.4.0, Windows XP

What steps will reproduce the problem?

    Using onejar-maven-plugin in an annotation-based Spring project.
Chances are that it’s the classpath scanning that is the problem.

    I had the following setup:

    Class:

    package com.example;

    @Component("transformer")
    public class MyTransformer {

    Spring config:

    <context:component-scan base-package="com.example" />

    Bootstrapping code:

        public static void main(String[] args) {
            ApplicationContext context = new
ClassPathXmlApplicationContext("applicationContext.xml");
            MyTransformer transformer = (MyTransformer)
context.getBean("transformer");
            transformer.run();
        }

    I got the following exception:

    NoSuchBeanDefinitionException: No bean named 'transformer' is defined

    I then switched to this config, still using annotation-based dependency
autowire, but requiring an explicit bean definition:

    Spring config:

    <context:annotation-config />
    <bean id="transformer" class="com.example.MyTransformer" />

Original issue reported on code.google.com by ulrik.sandberg on 17 Apr 2009 at 11:26

[GoogleCodeExporter]

Thanks for your report!

This is interesting, and I sure hope it's fixable too :)) My gut feeling says 
it's
related to upstream OneJar's classloading tricks.

Good thing you have a workaround in the meantime.

/Hugo

Original comment by hugo.josefson.old@gmail.com on 17 Apr 2009 at 11:39

• Changed state: Accepted

[GoogleCodeExporter]

I have a large project where explicit definition will cause me to take a step
backward into the land of XML hell ;-) Any updates on fix for this would be 
fantastic !

Original comment by alanole...@gmail.com on 23 May 2009 at 2:06

[GoogleCodeExporter]

Alan, thanks for the reminder.

Now I'm quite certain the problem is located at the One-JAR level, rather than 
being
specific for how this Maven plugin collects your jar. For that reason, I'm 
closing
this bug as WontFix, and have filed a bug against the One-JAR project on 
SourceForge.

Please everyone who is interested in this bug, follow this upstream bug instead:
https://sourceforge.net/tracker/?func=detail&aid=2796172&group_id=111153&atid=65
8457

I noticed that One-JAR author Simon Tuffs apparently offers expedited bug 
fixing for
money. That may be smart to take advantage of if your company relies on One-JAR 
:)
Here's his page about Professional Support:
http://one-jar.sourceforge.net/index.php?page=support&file=support

/Hugo

Original comment by hugo.josefson.old@gmail.com on 24 May 2009 at 8:24

• Changed state: WontFix

[GoogleCodeExporter]

Definitely, the problem is located at the One-Jar level. But it needs several 
fixed
to One-Jar to get it running with Spring Annotation Scanning:
- One-jar ignores the package directories in findResources
- Spring can't deal with "onejar" as protocol for URLs
-> Solution: use zip protocol and write an UrlStreamHandler
- Spring expects the main.jar to be a file in the file system
-> Solution: write a wrapper for JarFile and JarURLConnection to get everything 
running
after 8 hours my project starts from one jar! 
My code is based on todays 0.97-SnapShot and is attached below. 

But be careful: My code is a real hack, but works for me. I can't give any 
garanties.

Original comment by sebast...@the-herolds.de on 22 Apr 2010 at 10:40

Attachments:

• src.zip

[GoogleCodeExporter]

Thanks for taking the time to submit this patch to one-jar for support of 
Spring. 
I'm currently working on the 0.97 release and will make sure to roll this in.  

Simon.

Original comment by simontu...@gmail.com on 20 May 2010 at 5:57

[GoogleCodeExporter]

I have integrated the patch provided by Sebastian into one-jar 0.97, and there 
is now
an RC2 release available here:

https://sourceforge.net/projects/one-jar/files/one-jar/one-jar-0.97-RC2/one-jar-
boot-0.97.jar/download

The patch passed my regression suite without problems.  

Simon.

(All software is a hack at some level of abstraction)

Original comment by simontu...@gmail.com on 29 May 2010 at 6:30

• Changed state: Fixed

[GoogleCodeExporter]

Further information (as requested by another user)

The root cause is the way that Spring discovers classes which have been 
annotated as @Components by scanning the codebase.  Spring only supports a 
limited set of URL protocols (jar, zip, etc), whereas OneJar was returning its 
'onejar:' protocol in the URL's.  The solution was to change the nature of the 
URLs returned by findResources() to to be 'jar:'.  This was a complex change, 
and took it took some time to ensure that there were no other side-effects.  
This appears to work for this case, and does not break the other test cases.  A 
better solution would be for Spring to allow a pluggable annotation scanner 
that could be adapted to the classloader in charge of the application.

Original comment by simontu...@gmail.com on 8 Jun 2010 at 4:42

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

please make put a SNAPSHOT out in the maven repo ASAP.

Original comment by hanas...@gmail.com on 9 Jun 2010 at 2:34

[GoogleCodeExporter]

Note that I had difficulties concerning classpath URL's in spring with onejar, 
the solution was actually offered by onejar as an extra option in the manifest, 
see my issue:
http://code.google.com/p/onejar-maven-plugin/issues/detail?id=33

Original comment by bwijsmul...@gmail.com on 27 Dec 2011 at 12:50