I currently have two OSGi bundles (bundle1 and bundle2) both both exposing services through a blueprint in an EBA. In bundle2's blueprint.xml i want to reference a service from bundle1 and Inject it into the BuildService (code below), as BuildService will be used to call TicketService. This however results in a Timeout exception (also below). It seems like the BuildService never gets registered with OSGi. How would I make something like this work?
blueprint.xml for bundle1:
<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0" xmlns:bptx="http://aries.apache.org/xmlns/transactions/v1.0.0">
<bean id="TicketServiceBean" class="com.example.b2.impl.TicketServiceImpl">
<bptx:transaction value="Required" method="*" />
</bean>
<service ranking="0" id="TicketService" interface="com.example.b2.service.TicketService" ref="TicketServiceBean">
<service-properties>
<entry key="service.exported.interfaces" value="*" />
</service-properties>
</service>
</blueprint>
blueprint.xml for bundle2
<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">
<bean
id="BuildServiceImplBean"
class="com.example.b1.impl.BuildServiceImpl"
activation="eager" >
<property name="ticketService" ref="TicketServiceRef" />
</bean>
<service
id="BuildService"
ref="BuildServiceImplBean"
interface="com.example.b1.service.BuildService"
activation="eager">
<service-properties>
<entry key="service.exported.interfaces" value="*" />
</service-properties>
</service>
<reference
id="TicketServiceRef"
interface="com.example.b2.service.TicketService"
availability="mandatory"
activation="eager" />
</blueprint>
Implementation of the BuildService:
public class BuildServiceImpl implements BuildService {
private TicketService ticketService;
#Override
public TicketBuildResponse ticketBuild(TicketBuildRequest ticketBuildRequest) throws BuildServiceException {
//do stuff here
}
public TicketService getTicketService() {
return ticketService;
}
public void setTicketService(TicketService ticketService) {
this.ticketService = ticketService;
}
}
When starting up the application server (Websphere) I get the following exception:
BlueprintCont E org.apache.aries.blueprint.container.BlueprintContainerImpl$1 run Unable to start blueprint container for bundle com.example.b1.module due to unresolved dependencies [(objectClass=com.example.b2.service.TicketService)]
java.util.concurrent.TimeoutException
at org.apache.aries.blueprint.container.BlueprintContainerImpl$1.run(BlueprintContainerImpl.java:273)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:453)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:315)
at java.util.concurrent.FutureTask.run(FutureTask.java:150)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:736)
Here is the solution: The OSGi applications runtime treats remote services differently from local ones, because of the different default invocation semantics (local pass-by-reference versus remote pass-by-value). To prevent an application accidentally calling an exported service that is only designed for pass-by-value calls, it is hidden from local lookups.
The solution to this is to export the same bean twice, once for remote calls, and the second for local. In other words, you would add another <service /> element with the same configuration, but without the service.exported.interfaces property.
<service ranking="0" id="TicketServiceExport" interface="com.example.b2.service.TicketService" ref="TicketServiceBean">
<service-properties>
<entry key="service.exported.interfaces" value="*" />
</service-properties>
</service>
<service ranking="0" id="TicketService" interface="com.example.b2.service.TicketService" ref="TicketServiceBean"/>
There is actually also an osgi console in websphere and it can be found under [local websphere installation]/profiles/[profileName]/bin/osgiApplicationConsole.bat. Once lauched, help() gives you a list of commands. To see your imported services from SCA, you first connect to your application (e.g. connect(2), where the number of the application is given in the results of the list() command). You can then do services("(service.imported=true)") to see the service proxies that have been added by SCA . The command services() will list all the services in the application.
Related
I'm integrating Caching into my web application but for some reason Application Context failed to load when adding the #Cacheable annotation.
I have been trying to solve the issue for two days now, your help is really appreciated!
app.context.xml
<cache:annotation-driven cache-manager="EhCacheManagerBean" key-generator="customKeyGenerator" />
<bean id="EhCacheManagerBean" class="org.springframework.cache.ehcache.EhCacheCacheManager" p:cache-manager-ref="ehcacheBean" />
<bean id="ehcacheBean" class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean" p:configLocation="classpath:EhCache.xml" p:shared="true" />
<bean id ="customKeyGenerator" class="com.app.site.v2.cache.customKeyGenerator"/>
<bean id="siteService" class="com.app.site.v2.SiteService" primary="true"/>
EhCache.xml
<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://ehcache.org/ehcache.xsd"
updateCheck="true"
monitoring="autodetect"
dynamicConfig="true">
<diskStore path="java.io.tmpdir" />
<cache name="cacheSite"
maxEntriesLocalHeap="100"
maxEntriesLocalDisk="1000"
eternal="false"
timeToIdleSeconds="300"
timeToLiveSeconds="600"
memoryStoreEvictionPolicy="LFU"
transactionalMode="off">
<persistence strategy="localTempSwap" />
</cache>
Method that is being cached
public class SiteService implements ISiteService {
#Cacheable("cacheSite")
public JsonObject getSiteJson(String siteId, boolean istTranslated) { ... }
}
Exception that is being thrown
org.springframework.beans.factory.BeanNotOfRequiredTypeException: Bean named 'siteService' is expected to be of type 'com.app.site.v2.SiteService' but was actually of type 'com.sun.proxy.$Proxy57'
The comment of #yegdom is actually the right answer. When adding the Cacheable annotation, Spring generates a proxy which implements ISiteService. And somewhere in your code, you have a bean requiring SiteService, the implementation.
There are three solutions (in preference order):
Remove the useless interface... A single implementation is just adding complexity for no direct benefit. Removing it will force Spring to use a class proxy
Fix your dependency to use ISiteService
Add proxy-target-class="true" to cache:annotation-driven to tell Spring to create a class proxy
I really do not recommend the last one since you should always depend on the interface or always depend on the class (and delete the interface). Not both at the same time.
I can't get the blueprint right for using a service locally. The OSGi server (karaf) displays GracePeriod and eventually a timeout waiting on ILookupMfgService.
If I remove the reference line the bundle starts and has an ILookupMfgService available.
Any suggestions on what I'm doing wrong?
Thanks for helping with my learning!
Timothy
<blueprint default-activation="eager" xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:jpa="http://aries.apache.org/xmlns/jpa/v1.0.0" xmlns:tx="http://aries.apache.org/xmlns/transactions/v1.0.0" xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0"
xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0
http://www.w3.org/2001/XMLSchema-instance http://www.w3.org/2001/XMLSchema-instance
http://aries.apache.org/xmlns/jpa/v1.0.0 http://aries.apache.org/xmlns/jpa/v1.0.0
http://aries.apache.org/xmlns/transactions/v1.0.0 http://aries.apache.org/xmlns/transactions/v1.0.0
http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0 http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0 ">
<!-- implemenation of the service -->
<bean id="lookupMfgServiceStubImpl" class="com.services.jpa.LookupMfgServiceStub" scope="singleton"
init-method="init" />
<!-- create a service with the implementation -->
<service id="lookupMfgServiceStubLocal" ref="lookupMfgServiceStubImpl" interface="com.services.ILookupMfgService" />
<!-- create a reference for injecting into another bean - this line causes the GracePeriod / timeout -->
<reference id="lookupMfgServiceStubRef" interface="com.services.ILookupMfgService" availability="mandatory" ctivation="eager" />
<bean id="EntityImpl" class="com.services.jpa.Entity" scope="singleton" init-method="init">
<!-- use the service - won't work without the reference above being valid -->
<property name="lookupMfg" ref="lookupMfgServiceRef" />
</bean>
</blueprint>
without reference line
karaf#root()> services -p 123
com.server.services (123) provides:
----------------------------------------
objectClass = [com.services.ILookupMfgService]
osgi.service.blueprint.compname = lookupMfgServiceStubImpl
service.id = 932
----
You must not declare a mandatory reference to service exposed in the same blueprint/bundle. The container gets confused because it wants to start a service with a reference to a service that is not yet there (himself) which results in an unrecoverable GracePeriod.
A rough analogy of a reference is a Java Import from another package. The analogy of a service is a public class.
You need the import (=reference) if you want to use a class from a different package.
In your example you do not need the reference because you are within your bundle. You can reference your declared Bean directly instead:
<!-- implemenation of the service -->
<bean id="lookupMfgServiceStubImpl" class="com.services.jpa.LookupMfgServiceStub" scope="singleton"
init-method="init" />
<!-- create a service with the implementation -->
<service id="lookupMfgServiceStubLocal" ref="lookupMfgServiceStubImpl" interface="com.services.ILookupMfgService" />
<bean id="EntityImpl" class="com.services.jpa.Entity" scope="singleton" init-method="init">
<!-- use the service - won't work without the reference above being valid -->
<property name="lookupMfg" ref="lookupMfgServiceStubImpl" />
</bean>
p.s. If no no other bundle needs your LookupMfgService then you can even leave out the service declaration.
I am trying to use nested beans with a profile to setup an embedded jms broker when I am in dev mode. Here is my xml:
<beans ...>
...
other bean definition
...
<beans profile="embeddedBroker">
<!-- Configure an embedded ActiveMQ Broker with a TCP connector.
This broker is never set to start automatically by default, it is the broker service wrapper that
will take care to start it if configured to do so.
-->
<amq:broker id="jmsBroker" brokerId="EmbeddedBroker" brokerName="EmbeddedBroker"
persistent="false" useJmx="true" start="false">
<amq:plugins>
<!-- lets enable detailed logging in the broker but ignore ConnectionEvents -->
<amq:loggingBrokerPlugin logMessageEvents="true" logConnectionEvents="false"/>
<amq:timeStampingBrokerPlugin zeroExpirationOverride="1000" ttlCeiling="60000" futureOnly="true"/>
<amq:traceBrokerPathPlugin />
</amq:plugins>
<!-- Create a connector to give an external remote access to this broker. -->
<amq:transportConnectors>
<amq:transportConnector uri="tcp://127.0.0.1:35000" />
</amq:transportConnectors>
</amq:broker>
<!-- This broker service (wrapper) control the lifecycle of the jms broker defined above.
By default the internal broker will be initialized, but not started. It will usually be started only for
internal integration and unit tests.
-->
<bean id="jmsBrokerService" class="com.imetrik.global.common.jms.AMQBrokerService"
init-method="start"
destroy-method="stop">
<property name="broker" ref="jmsBroker" />
<property name="enabled" value="true" />
</bean>
</beans>
</beans>
But when I run my application with the correct profile, spring complain that the jmsBroker reference cannot be found!
Error creating bean with name 'jmsBrokerService' defined in class path resource [jms-beans.xml]: Cannot resolve reference to bean 'jmsBroker' while setting bean property 'broker';
Is there a way to fix that? Is it because the reference bean is not in the same namespace?
I know that if I put it out of the nested beans, it is working fine.
I am using Spring 4.1
I have a Spring app running inside a standalone JBoss EAP 6.2 (with its embedded HornetQ provider).
Messages are succcesfully put on the queue (I can see them in jboss-eap-6.2\standalone\data\messagingjournal\hornetq-data-1.hq because the queue is durable), but not picked up by the listener (a breakpoint inside the listener is not hit). I suspect something is missing from or wrong in the configuration but cannot see what. JBoss starts without any validation errors.
First, the excerpt from Spring's applicationContext.xml:
The JNDI names of the connection factory and queue match those in JBoss' standalone-full.xml
<jee:jndi-lookup id="jmsConnectionFactory" jndi-name="java:/JmsXA" resource-ref="false" proxy-interface="javax.jms.ConnectionFactory"/>
<jee:jndi-lookup id="myQueue" jndi-name="java:jboss/exported/jms/queue/myQueue"/>
<bean id="myHandler" class="com.example.MyHandler" />
<jms:listener-container destination-type="queue" acknowledge="auto" connection-factory="jmsConnectionFactory">
<jms:listener destination="java:jboss/exported/jms/queue/myQueue" ref="myHandler" method="processMessage" />
</jms:listener-container>
The message handler is declared as a Spring component and the class and method names match what is declared above:
#Component
public class MyHandler {
public void processMessage(MyMessage delaySendTransfer) {
//...
}
By default, Spring use the DynamicDestinationResolver for the listener container so it expects to receive a bean reference in the destination attribute of the listener. Since you are using a JNDI name, you should set the destination resolver strategy to jndiDestinationResolver.
<jms:listener-container destination-resolver="jndiDestinationResolver" destination-type="queue" acknowledge="auto" connection-factory="jmsConnectionFactory">
<jms:listener destination="java:jboss/exported/jms/queue/myQueue" ref="myHandler" method="processMessage" />
</jms:listener-container>
Replacing the destination attribute value with the bean reference should also do the trick :
<jms:listener-container destination-type="queue" acknowledge="auto" connection-factory="jmsConnectionFactory">
<jms:listener destination="myQueue" ref="myHandler" method="processMessage" />
</jms:listener-container>
I am using CXF generated code to connect to a remote web service over SSL and through a corporate proxy. The code works fine when the connection is established through the Java API and all SSL settings are set as system properties as follows.
System.setProperties("https.proxyHost", "myproxy.com");
System.setProperties("https.proxyPort", "8001");
System.setProperties("javax.net.ssl.keyStoreType", "pkcs12");
System.setProperties("javax.net.ssl.keyStore", "C:/keystore.p12");
System.setProperties("javax.net.ssl.keyStorePassword", "keypassword");
System.setProperties("javax.net.ssl.trustStore", "C:/cacerts");
System.setProperties("javax.net.ssl.trustStorePassword", "capassword");
MyWebService_Service ss = new MyWebService_Service(wsdlUrl, SERVICE_NAME);
MyWebService service = ss.getMyWebServicePort();
Using this code I can now call the service methods and everything works as expected. My problems occur when I try to set up the same configuration with Spring, which is our preferred approach since we are already using Spring extensively.
My Spring config:
<!-- relevant snippet from spring context -->
<import resource="classpath:META-INF/cxf/cxf.xml" />
<import resource="classpath:META-INF/cxf/cxf-extension-soap.xml" />
<import resource="classpath:META-INF/cxf/cxf-extension-http.xml" />
<jaxws:client id="webservice" serviceName="myns:MyWebService" endpointName="myns:MyWebServicePort"
address="https://bigserver.com:5012/blah/TheWebService"
serviceClass="com.mycomp.MyWebService" />
<http:conduit name="{myns}MyWebServicePort.http-conduit">
<http:tlsClientParamenters disableCNCheck="true" secureSocketProtocol="TLS">
<sec:trustManagers>
<sec:keyStore type="JKS" password="capassword" file="c:/cacerts" />
</sec:trustmanagers>
<sec:keyManagers>
<sec:keyStore type="pkcs12" password="keypassword" file="c:/keystore.p12" />
</sec:keyManagers>
</http:tlsClientParamenters>
<http:client ProxyServer="myproxy.com" ProxyServerPort="8001" />
</http:conduit>
In both cases, the web service client is deployed within a web application. In the second case, access to the web service results in a
javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate
Edit: I am using CXF version 2.2.
Have you tried adding the next property to your client parameters?
**useHttpsURLConnectionDefaultHostnameVerifier="false"**
Looks like this: