I’m developing a RCP based app that uses a data access layer implemented using Spring Data JPA backed by hibernate. The annotated domain classes are in one jar/bundle, the Spring repositories and spring config to instantiate the datasource, entity manager, and transaction manager are in another bundle.These jars are used by other non-RCP apps across the project.I have all of the hibernate 3.6.8 jars and dependencies either wrapped and exposed through my own plugins or as OSGI bundles (jta, antlr, commons collections, etc) in the target platform. I’m using Eclipse Gemini Blueprint to manage the bundle spring contexts within the RCP app.
When the DAL bundle spring context is being initialized by the gemini extender, I get Hibernate related ClassDefNotFound exceptions, usually either on org.hibernate.ejb.HibernatePersistence or javax.persistence.spi.Persistenceprovider. I’ve tried putting all of the hibernate jars and dependencies in a single plugin that exports the javax and hibernate packages. I’ve tried setting Eclipse Buddy policies in the manifests of the plugins that I have control over, etc.
I haven’t been able to find any solution to this class loading issue between Spring and Hibernate under Eclipse RCP using Gemini. I’ve done past hibernate DAO projects within RCP by putting all of the hibernate jars in the same plugin as my domain and DAO classes, so only my classes are exported.
At this point I don’t think moving to a more OSGI friendly JPA provider like OpenJPA or EclipseLink is an option.
I found an answer to a slightly related question that suggested putting all of the spring jars and dependencies into a single plugin, with the hibernate jars and dependencies in another plugin with buddy policies set. This seems dirty when most of the jars involved are OSGi bundles.
I suppose I could create a plugin that holds the DAL jar, hibernate jars, and spring ORM jars, so they can all see each other.
Is there a clean way to get this to work?
The core bundle if you own it, add all the suspected bundles as registered buddies and make sure that you have defined packages or bundles are reuired otherwise sometimes buddy class loading is not going to work. If the loading is initiated from you bundle the eclipse buddy policy should cascade. Other option would be to modify the manfiest files in target bundles that are causing issues.
Related
Spring boot starter project provides extensive set of functionalities auto configured. But for our application we want to have only a subset of functionality. May be only one feature out of the spring boot starter project. So is it advised to have custom starter project on top of spring boot provided starter project to mask some of the features or write new starter project directly from lower level libraries?
Spring boot starter project provides extensive set of functionalities
auto configured
There are two separate concerns you are talking about.
I think the auto configured part is something which is Spring boot's opinionated way of configuring. As an example if in classpath it finds a in-memory database library ( like H2) it automatically creates a datasource (pointing to embedded in-memory database) which is available for autowiring without you writing the configuration in a Java config class. Of course you can create you own datasource of choice by including appropriate driver jar for that database. Similarly lots of other configurations are done by default by classpath scanning and availability of certain jars and classes.
The second part - is more of a dependency issue in general. Say you want to use web mvc part in Spring boot. This will require a consistent set of dependencies and transitive dependencies as well. Rather than finding and declaring the dependency in your build tool of choice ( maven, gradle etc) it has created the concept of starter projects where you simply mention the parent and all the right dependencies would be pulled on. This gives a great way to correctly lock your dependencies. However if you want to include any different version than what is provided by boot starter ( provided there is no compatibility issues with those different versions) you can still add explicitly in your build tool. For e.g., maven will by default include the highest version of a particular dependency among all available via transitive dependencies when it resolves dependency for an artifact.
I have tried ProGuard, YGuard tools.
These tools are able to obfuscate the code, but at runtime Spring IOC fails. The obfuscation renames all the packages and classes, thus bean injection does not work at runtime. Am using spring boot 1.5.7 and Maven.
DashO has support for Spring (i.e. the Wizard will automatically identify and configure Spring beans) and we published an article earlier this year about how to use DashO with a Spring Boot app (you have to extract BOOT-INF/classes manually, and configure the entry point manually).
You can download a trial for free, and have full access to our technical support if you have trouble getting it working.
Full disclosure: I work for the company that makes DashO.
I am working on a webapp which uses Primefaces as a view, and I inject Spring beans from other projects into JSF Managed beans.
I have an architectural problem:
I've created separate projects(modules) for each component that I use (Business Logic, Persistence, and others) and also create separate projects with their interfaces.
I want my webApp to depend only on the interface of the Business Logic, and to inject the implementation of the BL using Spring Dependency Injection.
I want to achive this recursively: Business logic to depend only on other interfaces, and to inject implementations using spring.
The problem is that having no dependency in the Maven pom file to the actual implementations, when I deploy the application (on a web logic server) the implementation jars are not deployed, and Spring doesn't find the beans to wire.
Is there a way to achieve decoupling without adding dependencies to actual implementations?
Can I include Spring's bean configuration files from other projects if the projects are not added as dependencies?
Did I figured this decoupling all wrong?
I appreciate your ideas.
Well obviously you need the dependencies in your maven pom else nothing will be included. You can add the dependencies with a scope of runtime which includes them in your final war but not during development (scope compile).
For loading the context of modules you might come-up with a naming convention and/or standard location for your files. With that you could do something like this in your web applications beans xml
<import resource="classpath*:/META-INF/spring/*-context.xml" />
This would load all files ending with -context.xml from the /META-INF/spring directory on the classpath (including jar files).
In the project our team's working on, we currently have 3 separate Spring projects which utilizes the same services. To avoid redunancy and code copy-pasting, we're planning to create a "common" project wherein all the three projects would be dependent on the common project. In this instance, is it possible to inject these services (perhaps using the #Service annotation) to the Controllers of the Spring projects?
EDIT:
I tried implementing this on my own and what I basically did was I configured the pom.xml to get the Spring Context 3.1.1 dependency (which are also being used by my Spring projects) for my "common" project. With that, I was able to annotate my service with #Service. Afterwards, on my Spring project, I set the component-scan to a level wherein my two projects would meet. On my Spring controller, I #Autowired the service from the "common" project. I ran the Spring project and apparently it worked. Is this the best way to do this?
That's absolutely fine, and standard. Spring (unlike CDI) couldn't care less whether your beans come from the current project or from an imported jar.
I'm using Spring and Spring Integration in a service implementation packaged as an OSGi bundle. The service is published by Blueprint, or more specifically Gemini Blueprint [http://www.springframework.org/schema/osgi]
<bean id="myService" class="org.example.mti.MyServiceImplementation"/>
<osgi:service ref="myService" interface="org.example.mti.api.MyService"/>
The context files are in META-INF/spring/applicationContext*.xml
This works fine for some stub services, like memory backed DAOs, which don't rely on libraries for their implementation. The services are registered and can be exercised by another bundle.
For more complicated services, where I'm using Spring Integration, the service implementation clearly needs access to the Spring classes, which are exported by the normal Spring library bundles.
I'm using Bundlor to manage the MANIFEST.MF file. I've tried Spring Bundlor 1.0.0.RELEASE and Eclipse Virgo Bundlor 1.1.0.M3.
My understanding is that Bundlor is meant to be able to scan the Blueprint context files to determine the classes required, but I'm not seeing anything terribly useful added to the Import-Package manifest header.
Import-Package:
org.example.dao,
org.example.domain,
org.example.mti.api,
javax.inject,
org.springframework.integration,
org.springframework.integration.annotation,
org.springframework.integration.support
When trying to run the bundle using Pax Exam, under Felix, I see ClassNotFoundException
java.lang.ClassNotFoundException:
org.springframework.integration.gateway.GatewayProxyFactoryBean
I've tried setting both the Bundle-Blueprint and Spring-Context manifest headers in manifest.mf, and they're copied to MANIFEST.MF, but no new Import-Package values are added.
Is it expected that adding, for example, an <int:gateway .../> into the blueprint context will allow Bundlor to correctly determine the runtime dependencies, such as the GatewayProxyFactoryBean above?
If Bundlor cannot determine the correct Import-Package value then how do you manage these 'internal' package requirements? It's unreasonable, I think, to have to list every possible package within some third party library. Is there some equivalent of the Import-Library I vaguely recall from Spring DM?
References:
http://static.springsource.org/s2-bundlor/1.0.x/user-guide/htmlsingle/user-guide.html
http://blog.springsource.org/2009/09/26/bundlor-adds-support-for-the-blueprint-service/
Answering my own question with a potential solution.
DynamicImport-Package: org.springframework.*
While this is a bit of a hack, it does work