As part of the evolution of my software I'm trying to move Spring's configuration from XML to annotation-based configuration (I found it easier to manipulate certain configuration elements).
All works fine as long as I'm running unit tests in Maven, but when I'm trying to use the produced signed jar from another module of my project, I get errors stating that signer information from a CGLIB enhanced class doesn't match other classes in the same package.
Looking into the matter I could find that apparently Spring will always use CGLIB to enhance #Configuration classes, and then that CGLIB doesn't seem to play nice with signed jars since its dynamically created classes reside in the same package as the original.
Has anyone figured a way to use Java Configuration in signed jars ?
PS: I double checked the package name isn't present anywhere else ;)
After raising this same issue on Spring JIRA (https://jira.spring.io/browse/SPR-12833), it appears that there is indeed a conflict between CGLIB and signed jars that impacts Spring-based application.
That said a simple workaround consists in using a #Component annotation on the class instead of #Configuration. I'm not 100% sure what the side effects could be but it worked fine for me.
I had a similar problem with AOP proxies which use CGLIB. I dug a little bit deeper and found out that this issue has been already solved in original CGLIB repository. I hope spring team will merge it into their version of CGLIB. Until they will fix it, I use my workaround with custom class loader for ApplicationContext with disabled security checks.
I described this solution in my blog, I hope it'll be useful for somebody.
Related
I am currently working on a solution for testing EJB 3 Services with JUnit.
(Yes, I have looked at ejb3unit but it doesn't work for me. Yes, I have looked at container-integrated testing with openEJB but that didn't work out neither..)
So my question is what would be the way for resolving #EJB annotated Dependencies? And I don't mean by using a DI Framework like Weld, Guice or Spring. The solution should be applicable for plain old JUnit Tests -> without using an EJB Container like JBoss, Glassfish or openEJB.
I was able to replace the injection of the entity manager via #PersistenceContext with a little hack using java reflections. So how would I do that for dependencies with #EJB annotation?
(I wouldn't mind building and resolving the dependency tree myself, just looking for ideas ;) )
Greetings from Germany,
p.s.
Not sure why you're against the solution you proposed.
I was about to offer stuff like Arquillian, but hey - you don't want to have a container involved.
I just want to be sure about the reason you don't want container, before I move on to some ideas (though I did not test them) -
With JBoss AS 7.x deployment time of enterprise application servers was vastly reduced,
Not to mention that with Arquillian you have a deployment API, and you can decide what you will deploy (i.e - deploy for example just a single bean for a given test).
However, I do respect you question, so here are some ideas -
A. You mentioned you managed to inject an EntityManager using reflection - how did you do that? Why not apply the same to your beans?
B. If you're encountering problems with A, why not develop your own injection code , based on cglib , for example (in order to create Proxy not just for interface, but also for classes).
This way, when an object of the class is created,
you will be able to intercept the default CTOR, and scan for fields annotated with #Ejb.
I would suggest using some sort of configuration file that maps for each bean interface how to instantiate an appropriate class, and run this flow recurisevely (as the injected bean might have a field with #EJB annotation as well).
Pay attention that if you decide to use this method of work, you'll be implementing some sort of "mini dependnecy injection framework" - besides the fact that personally I would be interested in seeing your code ( :) ) I think you should carefully think why you don't want to use an "already made solution.
Note regarding the Arquillian suggestions, that still requires an EJB Container like JBoss, GlassFish, or OpenEJB.
If the problem is just finding and including all the dependencies, try this jar that includes all the required dependencies for EJB Lite:
http://repo1.maven.org/maven2/org/apache/openejb/openejb-lite/4.0.0/openejb-lite-4.0.0.jar
Include that in your test classpath (no other jars needed) then just boot the embedded container:
EJBContainer container = EJBContainer.createEJBContainer();
MyBean bean = (MyBean) container.getContext().lookup("java:global/myModleName/MyBean");
Working example here
Have you look at Arquillian?
You can find all the documentation on the project page: http://www.jboss.org/arquillian.html
I use Spring with long xml files for beans.
Is it possible at edit time to check if the names of the classes are correct and all references exist?
Try using STS, customized eclipse IDE with plugins, from Springsource. It have even auto-completion, error-checking features for writing spring's configuration(bean.xml) files.
UPDATE
For further details & features: Features of STS
As others have mentioned, this is the responsibility of an IDE before application runtime, or a simpler class that attempts to load the configuration if spinning up the app is cost-prohibitive.
The major IDEs (Elipse, NetBeans, and Intellij) all have strong Spring support. This includes class completion, jumping between config file usage(s) and definition, gutter marks to indicate a class is a Spring bean, etc.
Many Spring supported IDEs make suggestion of what the class name should be during editing. For example, Netbeans suggests this while you are typing the class names or other known attributes. However, it cannot be forced to check whether the class names you use really exist.
Without additional coding effort (for example writing your own xml editor), I do not think so. That's why annotations have been invented. You can move your configuration from xml files to annotated Java classes and methods. Then your compiler will do the work automatically.
I'm facing the following problem: I have one module in my webapp that needs jaxb 1.x and the other module needs jaxb 2.x. The first module doesn't work with the new version of jaxb, and the opposite. How can I use these two jars in one project?
Thanks.
For a regular application, usually very different versions use different package names. If this is the case, you can use them both at once without problem. However if they are the same, you can use jarjar to rename the package.
However since you are using a web container each application should use the version you deploy and not the other version. i.e. the web container works it out for you.
OSGi is another container which manages the versions much more explicitly and give you more control over these issues (however I believe you need it just for this)
You have got a jar-hell issue. Generally speaking in normal java environment it's impossible to solve this problem. You have to force modularization into your project by using OSGI. Starting point: http://www.osgi.org/About/HowOSGi
If you are using the JAXB reference implementation, then you can use your JAXB 1 models with the JAXB 2 runtime by including the jaxb1-impl.jar.
http://jaxb.java.net/faq/index.html#running1Apps
As Shaman said is imposible to resolve this issue.
Let's see: the servlet container JRE has only one classloader, and this classloader can load and use one class from jaxb or the other, but not both that will give you a classdefnotfound exception or something similar.
You can not solve this directly:
you can get the code (is opensource) and change the package of one to another name so the classloader can use both. I do not recommend you this solution, is a bad one.
Better is that you migrate the code to use the most modern API (jaxb 2)
I have couple of beans defined in the applicationContext.xml file and found if I made mistake(say typo) with the bean's name, spring won't complain anything and go ahead load the invalidate configuration. doesn't spring do the checking automatically? and how can i implement schema validation on the applicationContext.xml file? thanks.
IntelliJ IDEA has a wonderful support for Spring, including:
detecting broken references (bean does not exist, has a wrong type, etc.)
completing bean names when Ctrl+Space is pressed (along with narrowing the list to only the beans matching by type)
discovering missing/duplicated beans when #Resource/#Autowired is used and it will fail to autowire at runtime
quick navigation between Java and application context XML
...and lots more
Also I strongly recommend writing Spring smoke integration test. It doesn't have to test anything, just context startup (you would be amazed, how many errors it discovers).
To avoid errors in spring context I suggest you to use a plugin which checks its contents, for instance springIDE or SpringSource Tool Suite. In this way the plugin validates your spring contexts during development and you can find errors before the execution of your application.
in addition to this problem , i had problems with detecting duplicate bean ids that would get overridden unintentionally among others but finally i found this open-source project that helps you write JUnit unit tests that going to detect these problems. it was very easy to use and solved my problemsm it's called Beanoh
I've inherited two fairly non-trivial codebases that uses spring for configuring the applications. Now I need to reconfigure the applications. But lots of the configuration is provided through autowiring so it is almost impossible to find out what the actual configuration is.
The projects are moderately sized, some 20-ish maven modules per project including integration test modules and such. Most modules define a few application contexts for various purposes, that contain one or two local spring config files along with one or two from the core modules it depends on. The result is a myriad of configurations, and that I cannot alter a class or variable name (or setter method) without risking breaking dependencies in some upstream or downstream module, even if no such dependency is visible anywhere in the project.
How do I work effectively with autowired dependencies in spring?
Can anyone, perhaps someone who actually likes autowiring, provide some insight into how you work with them effectively?
(I also inherited a small project that combines xml-files, autowiring and annotation-driven config, making dependency relations completely intractable, but I'll save those annotations for a separate question later)
You can perform re-factoring of auto wired beans using Intellij (I have version 9 Ultimate). Also Intellij has an option of making autowiring dependencies explicit. Link Provided below
http://blogs.jetbrains.com/idea/2009/03/making-spring-autowired-dependencies-explicit/
What IDE are you using? Spring STS (an Eclipse based IDE) has a lot of tools for working with Spring annotations and autowiring as well as good set of refactoring tools.