I am having an issues with Wildfly 15.0.0 that it's not crating a JNDI for an EJB that is implementing both local and remote interfaces. My classes are as follows:
Local interface:
#Local
public interface BlockingManagerRemote{
}
Remote interface:
#Remote
public interface BlockingManagerLocal{
}
implementation:
#Remote({BlockingManagerRemote.class})
#Local({BlockingManagerLocal.class})
#Stateless
public class BlockingManager
implements BlockingManagerRemote, BlockingManagerLocal {
}
I get the following message first:
2019-03-13 12:09:57,459 INFO [org.jboss.as.ejb3.deployment] (MSC service thread 1-3) WFLYEJB0111: No jndi bindings will be created for EJB BlockingManager since no views are exposed
And When trying to inject this EJB in another class as follows:
#Remote({BusinessUserManagerRemote.class})
#Local({BusinessUserManagerLocal.class})
#Stateless
public class BusinessUserManager
implements BusinessUserManagerLocal, BusinessUserManagerRemote {
#EJB
private BlockingManagerLocal blockingManager;
}
I get this exception:
2019-03-13 12:09:58,469 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.subunit."mpaymentapp-ear.ear"."mpaymentapp-service-1.0.3-SNAPSHOT.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.subunit."mpaymentapp-ear.ear"."mpaymentapp-service-1.0.3-SNAPSHOT.jar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of subdeployment "mpaymentapp-service-1.0.3-SNAPSHOT.jar" of deployment "mpaymentapp-ear.ear"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:151)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1738)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1700)
at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1558)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1364)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYEE0052: Failed to install component BusinessUserManager
at org.jboss.as.ee.component.deployers.ComponentInstallProcessor.deploy(ComponentInstallProcessor.java:109)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:144)
... 8 more
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYEJB0406: No EJB found with interface of type 'com.cit.mpaymentapp.common.blocking.BlockingManagerLocal' for binding com.cit.mpaymentapp.service.registration.BusinessUserManager/blockingManager
at org.jboss.as.ejb3.deployment.processors.EjbInjectionSource.getResourceValue(EjbInjectionSource.java:90)
at org.jboss.as.ee.component.deployers.ComponentInstallProcessor.processBindings(ComponentInstallProcessor.java:263)
at org.jboss.as.ee.component.deployers.ComponentInstallProcessor.access$000(ComponentInstallProcessor.java:80)
at org.jboss.as.ee.component.deployers.ComponentInstallProcessor$1.handle(ComponentInstallProcessor.java:215)
at org.jboss.as.ee.component.ClassDescriptionTraversal.run(ClassDescriptionTraversal.java:54)
at org.jboss.as.ee.component.deployers.ComponentInstallProcessor.deployComponent(ComponentInstallProcessor.java:218)
at org.jboss.as.ee.component.deployers.ComponentInstallProcessor.deploy(ComponentInstallProcessor.java:101)
... 9 more
The same code was working on JBOSS EAP6. Why Wildfly is not recognizing the local interface BlockingManagerLocal?
I think you should implement your Interfaces as plain java interfaces and add the annotation #LocalBean instead of #Local to your bean implementation.
Remote EJBs should be avoided. I recommend using Rest interfaces instead.
Related
As the title says. I have some EJBs in an EAR and I have a client jar providing remote methods to a JSF app also sitting in liberty (different server/machine). The client jar tries to access the remote EJBs via lookup.
This is breaking my heart for two days now. As the title says...
I am aware of other stackoverflow questions from the past and I am aware of the following resources:
https://www.ibm.com/docs/en/was-liberty/core?topic=liberty-using-enterprise-javabeans-remote-interfaces
https://github.com/OpenLiberty/open-liberty/blob/release/dev/com.ibm.ws.ejbcontainer.remote_fat/test-applications/RemoteClientWeb.war/src/com/ibm/ws/ejbcontainer/remote/client/web/RemoteTxAttrServlet.java
I have tried every combination provided in the above but no joy.
I use (wlp-javaee8.21.0.0.8) with javaee8 feature enabled, this enables everything else I need e.g. ejb-3.2, ejbRemote-3.2, jndi-1.0 and a few others)
I have an EAR my-ear that contains a module my-module-1.0.4-SNAPSHOT.jar which contains my beans. I am using gradle/liberty plugin and IntelliJ.
I am using tests from within IntelliJ in the client jar module to try to access the remote beans.
My myEAR deploys fine and starts up fine and the app shows running in admincenter. In messages.log I see my EJB bindings. Just picking one example.
[16/08/21 10:58:42:384 IST] 00000022
com.ibm.ws.ejbcontainer.osgi.internal.NameSpaceBinderImpl I
CNTR0167I: The server is binding the
my.org.functiona.ejb.advance.MyAdvance interface of the MyAdvanceBean
enterprise bean in the my-module-1.0.4-SNAPSHOT.jar module of the
my-ear application. The binding location is:
ejb/my-ear/my-module-1.0.4-SNAPSHOT.jar/MyAdvanceBean#my.org.functiona.ejb.advance.MyAdvance
[16/08/21 10:58:42:385 IST] 00000022
com.ibm.ws.ejbcontainer.osgi.internal.NameSpaceBinderImpl I
CNTR0167I: The server is binding the
my.org.functiona.ejb.advance.MyAdvance interface of the MyAdvanceBean
enterprise bean in the my-module-1.0.4-SNAPSHOT.jar module of the
my-ear application. The binding location is:
my.org.functiona.ejb.advance.MyAdvance [16/08/21 10:58:42:385 IST]
00000022 com.ibm.ws.ejbcontainer.runtime.AbstractEJBRuntime
I CNTR0167I: The server is binding the
my.org.functiona.ejb.advance.MyAdvance interface of the MyAdvanceBean
enterprise bean in the my-module-1.0.4-SNAPSHOT.jar module of the
my-ear application. The binding location is:
java:global/my-ws-ear/my-module-1.0.4-SNAPSHOT.jar/MyAdvanceBean!my.org.functiona.ejb.advance.MyAdvance
This is my corresponding interface:
package my.org.functiona.ejb.advance;
import javax.ejb.Remote;
#Remote
public interface MyAdvance {
This is my corresponding implementation:
package my.org.functiona.ejb.advance;
import javax.ejb.EJB;
import javax.ejb.Stateless;
import javax.ejb.TransactionAttribute;
#Stateless(mappedName = "MyAdvance")
#TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
public class MyAdvanceBean implements MyAdvance {
Like I said, its breaking my heart. I tried every combination of provided in the (patchy) documentation and other sources. The most progress I made was by accessing "corbaname::localhost:2809/NameService" through a default InitialContext().lookup. So at least I was able to confirm I can gwet through to the NameService. But any subsequent bean lookup using that context with any combination of the names provided in messages.log or in the code snippets from documentation all fail with the exception below.
javax.naming.NameNotFoundException [Root exception is org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0]
Same for InitialContext() lookups where I prefix the names with "corbaname::localhost:2809/NameService#".
I tried
ejb/my-ear/my-module-1.0.4-SNAPSHOT.jar/MyAdvanceBean#my.org.functiona.ejb.advance.MyAdvance
ejb/global/my-ear/my-module-1.0.4-SNAPSHOT.jar/MyAdvanceBean#my.org.functiona.ejb.advance.MyAdvance
ejb/my-ear/my-module-1.0.4-SNAPSHOT.jar/MyAdvance#my.org.functiona.ejb.advance.MyAdvance
ejb/global/my-ear/my-module-1.0.4-SNAPSHOT.jar/MyAdvance#my.org.functiona.ejb.advance.MyAdvance
java:global/my-ear/my-module-1.0.4-SNAPSHOT.jar/MyAdvance#my.org.functiona.ejb.advance.MyAdvance
java:global/my-ear/my-module-1.0.4-SNAPSHOT.jar/MyAdvanceBean#my.org.functiona.ejb.advance.MyAdvance
my.org.functiona.ejb.advance.MyAdvance
and probably a few others
I replaced the # sign with an exclamation mark in all of the above. And went through it again.
I tried corbaloc:: and corbaloc:iiop: for context. Nothing.
I am no web dev expert but this feels very try and error and I dont feel it should be like that. I understand in websphere proper I could identify the names in the admin console but then I'm not even certain websphere proper and liberty behave the same way.
Sine accessing EJBs from remote seems bread & butter stuff I assume I am overlooking something basic and silly due to my inexperience.
Any pointers anyone? Thank you so much for your time reading this.
Carsten
Edit: server.xml
<server description="disbCoreServer">
<featureManager>
<feature>javaee-8.0</feature>
<feature>adminCenter-1.0</feature>
<feature>websocket-1.1</feature>
</featureManager>
<quickStartSecurity userName="admin" userPassword="carsten" />
<!-- To access this server from a remote client add a host attribute to the following element, e.g. host="*" -->
<httpEndpoint id="defaultHttpEndpoint"
host="${hostname}"
httpPort="${default.http.port}"
httpsPort="${default.https.port}">
<accessLogging filepath="${com.ibm.ws.logging.log.directory}/accessLog.log" logFormat='%h %i %u %t "%r" %s %b %{R}W' />
<tcpOptions soReuseAddr="true" />
</httpEndpoint>
<include location="appConfXML/disb_core_jndi.xml"/>
<include location="appConfXML/disb_core_jdbc.xml"/>
<include location="appConfXML/disb_core_jms.xml"/>
<include location="appConfXML/disb_core_mail.xml"/>
</server>
The example provided through the FAT test (remoteLookup) works just fine. I just didnt have all my ducks in a row.
https://github.com/OpenLiberty/open-liberty/blob/release/dev/com.ibm.ws.ejbcontainer.remote_fat/test-applications/RemoteClientWeb.war/src/com/ibm/ws/ejbcontainer/remote/client/web/RemoteTxAttrServlet.java
My scenario is serverA hosting EJBs and serverB running the remote client calling serverA's EJBs.
Steps on serverB are:
Get (local) InitialContext with no properties: InitialContext initialContext = new InitialContext();
With the above lookup the remote Context: Context remoteContext = (Context) initialContext.lookup("corbaname::remotehost:remotePort/NameService");
With the remoteContext lookup the EJB remote interfaces and 'narrow' and cast them to appropriate type
String lookupName = "ejb/global" + "/" + "MyAppName" + "/" + "MyModuleName" + "/" + jndiName;
Object remoteObj = remoteContext.lookup(lookupName);
return interfaceClass.cast(PortableRemoteObject.narrow(remoteObj, interfaceClass));
Where
"MyAppName" is my apps name, the name of the EAR in my case (without .jar)
"MyModuleName" is the name of the EJB module within my EAR (without .jar)
and jndiName is the bean name / fully qualified interface name separated by exclamation mark e.g. "MyBean!myorg.ejb.interfaces.MyBeanIfc"
Call the interfaces to remotely execute serverA EJB code
Note: When running serverA and serverB on the same machine (e.g. localhost) ensure they are not operating on the same port for NameService.
Thanks to everyone who tried to help!
Here is the DbConfig of my spring-boot application.
#Configuration
#EnableTransactionManagement
public class DBConfig
{
#Bean
public LocalSessionFactoryBean sessionFactory()
{
....
}
#Bean
public DataSource aaDataSource()
{
.....
}
public PlatformTransactionManager transactionManager()
{
....
}
private Properties hibernateProperties()
{
....
}
}
Here is my test class
#RunWith(SpringJUnit4ClassRunner.class)
#SpringApplicationConfiguration(classes = Application.class)
#WebAppConfiguration
public class ApplicationTests {
#Test
public void contextLoads() {
}
}
Its a gradle project.
when I run gradlew clean build locally, I get successful build since my connection settings in application.properties matches my sql connection.
But when I run from jenkins box in our qa environment (the database is qa one), the build fails with following exception.
java.lang.IllegalStateException: Failed to load ApplicationContext
....
Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'entityManagerFactory' defined in class path resource [org/springframework/boot/autoconfigure/orm/jpa/HibernateJpaAutoConfiguration.class]: Bean instantiation via factory method failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean]: Factory method 'entityManagerFactory' threw exception; nested exception is com.zaxxer.hikari.pool.PoolInitializationException: Exception during pool initialization
at org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:599)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1123)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1018)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(Abstract
.....
Caused by: com.zaxxer.hikari.pool.PoolInitializationException: Exception during pool initialization
at com.zaxxer.hikari.pool.BaseHikariPool.initializeConnections(BaseHikariPool.java:544)
at com.zaxxer.hikari.pool.BaseHikariPool.<init>(BaseHikariPool.java:171)
at com.zaxxer.hikari.pool.HikariPool.<init>(HikariPool.java:60)
at com.zaxxer.hikari.pool.HikariPool.<init>(HikariPool.java:48)
.....
Caused by: java.sql.SQLException: Access denied for user 'admin1'#'localhost' (using password: YES)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:998)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3835)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3771)
I tried running gradlew clean build -Dspring.profiles.active=qa with application-qa.properties in the src/main/resources/ that have qa db settings. The build still failed with same exception.
I have two options.
run the build skipping datasource bean creation. I still need my units tests to be run since they don't rely on datasource
or pass the right settings to gradle build so that application context is created.
I prefer second option to get it working
If your requirement is that you control this externally (i.e., via the command line when launching Gradle), you can then modify your Gradle test task configuration as follows.
test {
systemProperty("spring.profiles.active", project.properties.get("springProfiles"))
// ...
}
And then you can set a value for springProfiles like this: gradlew clean build -PspringProfiles=ci (where ci is the name of the profile you want active on the CI server).
The above will make spring.profiles.active available as a JVM system property for your tests; however, you'd still need to set the active profiles for the Spring TestContext Framework.
To do that, you need to annotate your test class with #ActiveProfiles, but instead of passing in static profiles you'd need to implement a custom ActiveProfilesResolver and register it via #ActiveProfiles(resolver = MyCustomResolver.class). Your customer resolver could then read then simply return the value of the spring.profiles.active system property.
Another option is to implement a custom ApplicationContextInitializer that programmatically sets the active profiles (similar to the custom ActiveProfilesResolver). You can configure one of those via #SpringApplicationConfiguration(initializers = MyCustomInitializer.class).
And yet another option would be to programmatically set the active profiles directly in your SpringApplication -- for example, based on a system property or environment variable.
So, you have several options.
I have a project with Spring MVC and Spring Boot and I use IntelliJ.
My Project is like this :
main -> java -> mypackage -> authentification -> WebSecurityConfig.java
-> configuration -> ApplicationConfiguration.java
-> controller -> WelcomeMessageController.java
-> service -> WelcomeMessageService.java
-> Impl -> WelcomeMessageServiceImpl.java
test -> java -> mypackage -> WelcomeMessageTest.java
I annotate the service implementation with #Service.
I annotate the configuration file with
#Configuration
#ComponentScan(basePackages = "mypackage")
In the controller, I inject the service with
#Autowired
WelcomeMessageService welcomeMessageService;
In the test class, I inject the same service with the same annotation:
#Autowired
WelcomeMessageService welcomeMessageService;
I annotate the test class with :
#RunWith(SpringJUnit4ClassRunner.class)
#ContextConfiguration(classes = ApplicationConfiguration.class, loader = SpringApplicationContextLoader.class)
#WebAppConfiguration
In the controller, the injection works fine but in the test class, IntelliJ says:
Could not autowire. No beans of type WelcomeService found.
When I run the test it works, but I don't understand why IntelliJ says that it can't find the bean.
I found this topics that says that it happens some time with IntelliJ but I don't want to use the #SuppressWarnings annotation.
Does anyone have another solution to solve this problem ?
For me it was a component scan issue my models are in a separate module then my Spring Boot App. Normally, #SpringBootApplication has a #ComponentScan which when not specified will scan as follows:
Either {#link #basePackageClasses} or {#link #basePackages} (or
its alias * {#link #value}) may be specified to define specific
packages to scan. If specific * packages are not defined, scanning
will occur from the package of the * class that declares this
annotation.
If your SpringBootApp Main class is on a different package then you want to specify the ComponentScan. Same thing if you are using multiple modules, specify it on your Configuration class.
Config class Annotations:
#Configuration
#ComponentScan(basePackages = "app.data")
Testclass Annotations:
#RunWith(SpringJUnit4ClassRunner.class)
#SpringBootTest(classes = { PropertyPlaceholderAutoConfiguration.class, DynamoConfig.class })
I had the same issue of not being able to AutowWire beans into the Integration test classes. Your question helped me in solving that with the addition of "ContextConfiguration" annocation instead of "SpringApplicationConfiguration" which I was using.
However the only difference I can see now is that you are missing the #EnableAutoConfiguration in the Application class (which extendends SpringBootServletInitializer) or the class where you have your #Configuration.
Hopefully that should resolve your issue. Bottom line is this is caused to inappropriate annotations at in this very specific case.
I can not get my Spring MVC application to run as an OSGi bundle. This one has completely stumped me.
I'm trying to run a Spring 3 MVC bundle, but when starting up it can not find the namespace handlers required to use Spring. I've included the necessary import-packages, for org.springframework.context. I've checked that the org.springframework.context.config.ContextNamespaceHandler is installed on the Virgo server. There are no errors on starting the bundle in the server - so I'm pretty sure dependencies must be fulfilled.
Here's the exception I get when I try to make a request to the MVC dispatcher servlet;-
org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected exception parsing XML document from ServletContext resource [/WEB-INF/mvc-dispatcher-servlet.xml]; nested exception is org.springframework.beans.FatalBeanException: NamespaceHandler class [org.springframework.context.config.ContextNamespaceHandler] for namespace [http://www.springframework.org/schema/context] not found; nested exception is java.lang.ClassNotFoundException: org.springframework.context.config.ContextNamespaceHandler not found from bundle [com.osgi-test.spring-mvc-bundle]
org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:412)
org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:334)
org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:302)
org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:143)
org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:178)
org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:149)
org.eclipse.gemini.blueprint.context.support.OsgiBundleXmlApplicationContext.loadBeanDefinitions(OsgiBundleXmlApplicationContext.java:170)
org.eclipse.gemini.blueprint.context.support.OsgiBundleXmlApplicationContext.loadBeanDefinitions(OsgiBundleXmlApplicationContext.java:140)
org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:130)
org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:467)
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:397)
org.eclipse.gemini.blueprint.context.support.AbstractDelegatedExecutionApplicationContext.access$301(AbstractDelegatedExecutionApplicationContext.java:60)
org.eclipse.gemini.blueprint.context.support.AbstractDelegatedExecutionApplicationContext$1.run(AbstractDelegatedExecutionApplicationContext.java:168)
org.eclipse.gemini.blueprint.util.internal.PrivilegedUtils.executeWithCustomTCCL(PrivilegedUtils.java:85)
org.eclipse.gemini.blueprint.context.support.AbstractDelegatedExecutionApplicationContext.normalRefresh(AbstractDelegatedExecutionApplicationContext.java:164)
org.eclipse.gemini.blueprint.context.support.AbstractDelegatedExecutionApplicationContext$NoDependenciesWaitRefreshExecutor.refresh(AbstractDelegatedExecutionApplicationContext.java:78)
org.eclipse.gemini.blueprint.context.support.AbstractDelegatedExecutionApplicationContext.refresh(AbstractDelegatedExecutionApplicationContext.java:157)
org.springframework.web.servlet.FrameworkServlet.createWebApplicationContext(FrameworkServlet.java:442)
org.springframework.web.servlet.FrameworkServlet.createWebApplicationContext(FrameworkServlet.java:458)
org.springframework.web.servlet.FrameworkServlet.initWebApplicationContext(FrameworkServlet.java:339)
org.springframework.web.servlet.FrameworkServlet.initServletBean(FrameworkServlet.java:306)
org.springframework.web.servlet.HttpServletBean.init(HttpServletBean.java:127)
javax.servlet.GenericServlet.init(GenericServlet.java:244)
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
org.eclipse.virgo.web.tomcat.support.ApplicationNameTrackingValve.invoke(ApplicationNameTrackingValve.java:33)
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
java.lang.Thread.run(Thread.java:722)
The Manifest file in the bundle looks like this;-
Manifest-Version: 1.0
Export-Package: com.osgi-test.external;version="0.0.1.SNAPSHOT"
Bundle-ClassPath: .,WEB-INF/classes
Built-By: seth
Tool: Bnd-1.50.0
Bundle-Name: spring-mvc-bundle
Created-By: Apache Maven Bundle Plugin
Build-Jdk: 1.7.0_06
Bundle-Version: 0.0.1.SNAPSHOT
Bnd-LastModified: 1347110247719
Bundle-ManifestVersion: 2
Bundle-SymbolicName: com.osgi-test.spring-mvc-bundle
Import-Package: com.osgi-test.external,javax.servlet.http;version="
[2.4,3)",org.eclipse.virgo.web.dm;version="[3.0,4)",org.springfram
ework.context;version="[3.0,4)",org.springframework.stereotype;ver
sion="[3.0,4)",org.springframework.validation;version="[3.0,4)",or
g.springframework.web;version="[3.0,4)",org.springframework.web.bi
nd.annotation;version="[3.0,4) ",org.springframework.web.servlet;v
ersion="[3.0,4)"
Archiver-Version: Plexus Archiver
I read an article that suggested making use of the
org.eclipse.virgo.web.dm.ServerOsgiBundleXmlWebApplicationContext
(http://www.eclipse.org/forums/index.php/m/635463/)
might help - however made no difference for me.
I have also tried removing the ContextLoaderListener in the web.xml - but again that didn't help.
At this point, I'm lost for ideas. Any help, massively appreciated.
http://thomaskratz.blogspot.in/2012/03/osgi-spring-dispatcherservlet.html
Please check this site, I think spring has issues with registering dispatcher servlet directly. But if you use the workaround mentioned in the above blog, it should work.
I am actually adding the code snippet which I tried here for reference:
Add the following to Activator of the plugin:
Activator.context = bundleContext;
ServiceReference ref = context.getServiceReference(HttpService.class.getName());
HttpService service = (HttpService) context.getService(ref);
DispatcherServlet servlet = new DispatcherServlet();
Dictionary<String, String> initparam = new Hashtable<String, String>();
initparam.put("contextConfigLocation", "/WebContent/WEB-INF/spring-servlet.xml");
initparam.put("contextClass", "spring3osgi.BAC");
ClassLoader loader = Thread.currentThread().getContextClassLoader();
Thread.currentThread().setContextClassLoader(this.getClass().getClassLoader());
// this is to register the controller
service.registerServlet("/Spring3OSGi", servlet, initparam, null);
// provide alias to the WebContent folder
service.registerResources("/Spring3OSGiWebContent", "/WebContent", service.createDefaultHttpContext());
Create a class BAC
import org.springframework.osgi.web.context.support.OsgiBundleXmlWebApplicationContext;
public class BAC extends OsgiBundleXmlWebApplicationContext {
public BAC() {
super();
setBundleContext(Activator.getContext());
}
}
I don't know much about Spring MVC, but for Spring I know there is SpringDM specially for OSGi environments. Maybe you could have a look to http://static.springsource.org/osgi/docs/1.2.1/reference/html/web.html#web:spring-mvc. Hopefully it will help you a little bit.
I want to use logger in my java web application.
I'm using JBossAS 6.0.0.final, cdi (weld), jsf ... etc. Seam solder proposes to use an abstract logger is not tying to a concrete implementation (slf4j, log4j, etc) using jboss-logging api.
In order to get this logger in your code will need to write
# Inject
org.jboss.logging.Logger log
seam-solder.jar has the producer for this logger.
package org.jboss.seam.solder.log;
...
class LoggerProducers
{
# Produces
org.jboss.logging.Logger produceLog (InjectionPoint injectionPoint) {}
}
When I deploying my application, I get an error
15:51:18,300 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] Error installing to Start: name=vfs:///C:/Java/jboss-6.0.0.Final/server/default/deploy/kamis-web-client.5.0.0-SNAPSHOT.ear_WeldBootstrapBean state=Create: org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [Logger] with qualifiers [#Default] at injection point [[field] #Inject private ru.kamis.suite.webclient.web.breadcrumbs.BreadcrumbsManager.log]
This is due to the seam-solder.jar has not META-INF/beans.xml file, and it is necessary for cdi container.
If to add beans.xml file in seam-solder.jar manually, then the application works WELL.
How to do without hacks?
To build my application I use maven, so my solution is not comfortable and NOT fine.
PS: Former weld-extensions project contained META-INF/beans.xml file in jar.
with seam-solder-3.0.0.Beta1 there should be no need to modify the jar