How do I get Bundlor to generate Import-Package for OSGi Blueprint dependencies - spring

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

Related

Least intrusive way to add Spring task scheduling to a non-Spring web project?

How should I add Spring task scheduling to a non-Spring war project? Currently, the web project only has a maven dependency to org.mitre.dsmiley.httpproxy:smiley-http-proxy-servlet. It's just a simple proxy servlet now. SpringBoot is probably not a good fit for this problem as I want to keep the war artifact the deployment model. I do not want to run it embedded in a stand-alone container. I'm looking for the least intrusive approach. Any suggestions?
If you are planning to deploy the app to a server that supports Servlet 3.0, then it is actually quite easy to use Spring Boot in a traditional, war deployment model.
What you need to do is:
Extend SpringBootServletInitializer, which in turn implements WebApplicationInitializer and can configure the servlet context.
Specify the war packaging in your pom.xml (which you probably already have)
Set the provided scope for the spring-boot-starter-tomcat dependency, so that an embedded server is not created when your application runs.
See the reference guide for more details.

Structuring Spring application with decoupled modules

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).

Java EE 6 - Why does an interceptor project need to be declared as ejb-jar and not simply a jar?

I was able to determine what I needed to do to get my interceptor working; however, I don't understand why I had to do that. All of the projects I am using my interceptor project in are either jar / war and CDI-enabled.
I thought CDI covered both EJB beans, regular POJO beans, properties, and anything resolveable via EL. And ... that to register an interceptor for CDI beans, I could simply declare it in beans.xml. None of my projects are EARs.
Now that I have it working by building the project as an ejb-jar, that is the main thing, but am I wrong in thinking it should work in beans.xml alone and building the project as just a regular jar?
Please point me to any documentation that specifies this clearly, everything on oracle's site indicates beans.xml should suffice.
Walter

CQ5 Spring integration

Is the any way to perform integration CQ5 platform with Spring framework?
I would like to use Spring IoC capabilities to make my code more clear and efficient.
UPDATE
Hello againg, seems that I found solution.
Guys here developed Slice framework that really redices amound of code and made CQ5 development easier.
You probably want to check out Eclipse Gemini Blueprint, or it's original incarnation Spring Dynamic Modules. The Blueprint project basically gives you an easy way to create Spring enabled bundles in an OSGi environment.
As shsteimer mentions, Spring distributions before 3.2.0 were OSGi bundles, so could be dropped into an OSGi environment and you could probably use them directly. Spring 3.2.0 bundles and above are now available through the SpringSource ERB. However, Blueprint gets around or helps with some of the boilerplate OSGi stuff that you would otherwise have to do.
On a past project, I was able to get Spring JDBC working inside of CQ (to support some legacy code so we didn't have to re-write it). My memory is that the spring jar files already come "OSGI-ified" and so it was just a matter of figuring out all the layers of dependency needed for JDBC to work inside of CQ, and adding all the jars to the repository in an /apps/myApp/install folder.
Long story short, I'm not sure about IoC, but you might check to see if it's already packaged as an OSGI version which you can simply use without too much hassle.

Eclipse RCP, Spring, Hibernate Class Loading Issue

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.

Resources