We Keep Coding

Sending jms messages from wildfly

I'm working on jms base wildfly application (wildfly 8, java 7). I have to use event driven library based on Rx Java. I want to send jms message from on even listener which I have to provide to library function to. The problem is that standard EJB based mechanisms for sending jms messages does not work from inside Rx Java handlers. The wild guess is that I can not inject / use annotation based EJB jms mechanisms inside Rx Java stream as they are not spawned by the EJB container (or pass EJB beans as Rx Java handlers). I have tried to send jms messages from EJB singleton as from standalone java application following tutorial like this. The problem is have with this approach is that standalone instance of wildfly can not find dependency for index factory org.jboss.naming.remote.client.InitialContextFactory. Or wildfly won't even deploy if I try to add maven dependency
<dependency>
<groupId>org.wildfly</groupId>
<artifactId>wildfly-jms-client-bom</artifactId>
<version>${version.wildfly}</version>
<type>pom</type>
</dependency>
to my application fat jar. Any ideas would be greatly appreciated as my understanding of EJB is quite lacking in this matter.

You can use EJBs without dependency injection making a lookup to InitialContext.
After code the Singleton EJB you need to know the "EJB name on JNDI registry" after that you can do:
Context ctx = new InitialContext()
MyStatlessBeanInterface bean = ctx.lookup("FULL NAME BEAN");
bean.sendJMSMessage();
Wilfly prints the EJB name in the console at deployment, but you can read about conventions in:
https://docs.jboss.org/author/display/AS71/JNDI+Reference
Also you can get more information about lookup in:
https://docs.oracle.com/cd/E16439_01/doc.1013/e13981/usclient003.htm

How to add a EJB Interceptor programmatically?

I'm trying to add a Interceptor in a EJB at runtime programmatically via CDI extensions.
This EJB exposes a Remote interface for remote calls. But I'm trying to add this Interceptor in the implementation class of this EJB adding the #Interceptors annontation like in this other SO question (CDI Extensions - Add Interceptors in ProcessAnnotatedType phase)
I think the CDI Extension only executes after the EJB are already registered because the Interceptor is never called.
But, for test purpose I have successfully register and execute an Interceptor programmatically in a simple CDI Bean.
The problem is when I'm try to register in a EJB.
Am I missing something?
Edit:
I'm using Wildfly 8

I think the key problem here is the difference between #Interceptors (EJB ones) and #Interceptor (CDI ones). CDI does not govern EJB container hence adding the EJB annotation (#Interceptors) in CDI extension won't necessarrily kick EJB logic into effect - EJB container might have started at that moment and it won't know of the annotation. Furthermore the CDI extension would add this annotation to the AnnotatedType which is a structure EJB probably won't make use of. On the other hand, all this really depends on the application server as it is responsible for CDI/EJB integration hence as a "bonus" the behavior might differ between AS.
CDI extension is something which allows you to hook into CDI bootstrap lifecycle, therefore you are able to use/enable/add CDI interceptors. I would try going that way instead. BTW even the SO question you referred to speaks of beans.xml/#Priority for enablement which means it uses CDI interceptors and not EJB ones.
Also, an EJB bean should automatically become CDI bean therefore you can attach CDI interceptor to it without changing the bean itself.

RESTful service in Karaf without blueprint xml

I am new to Karaf, hence was looking for resources to create a project for RESTful web services using felix annotations and without the use of BundleActivator class(i mean by an actual class that needs to be written by me, but its ok if some compiler or maven plugin does the same for me) and blueprint xml file. So far I got success in the first part(BundleActivator part) which now after compilation auto creates my MANIFEST.MF with import and export statements, creates the relevant XML file for each component class, and packages it into a a nice jar bundle which works very well when I deploy it on Karaf container. But what is not working is the RESTful services. The bundle is deployed correctly, but the REST urls are not exposed and hence I am unable to access them.
Please help me in getting this done. I don't want to write an XML file which needs to be modified everytime there is an addition or deletion of a rest service.
Thanks

If you want to completely avoid blueprint then you should use cxf-dosgi. You simply annotate your rest service using jaxrs and publish it as an OSGi service with some special properties.
See the cxf-dosgi rest sample.
The example uses the standard DS annotation and the maven bundle plugin to create the DS component xml on the fly.
If you prefer to have blueprint at runtime then you can use the blueprint-maven-plugin. See this example.

I figured out a way to do so without using the CXF feature. That is, create a component class and in activate method get the object of ConfigurationAdmin and put the required context path against the jersy server process(using jersey publisher jar). Using this mehtod, I was able to deploy any rest/serlvet in Karaf without using blueprint.xml file. I hope this helps.

Programaticly create datasource for JBoss 4.2.x

Would it be possible to programmaticly create a data source in jboss and still have a valid jndi entry for the entity manager to use?
Creating the data source is where I am lost, I hope I can use a MBean that runs on stat-up to handle this.
This would not be my preferred method, but the application I am working on has a global configuration file hosted on another server I am suppose to use for configuration.
update: In this instance I need to create a data source programticly or change the jdbc url of an exsiting datasource. I don't know the DB server url until runtime.

Rather than poking around in the guts of JBoss in order to do this, I suggest using a 3rd-party connection pool utility, such as Apache Commons DBCP. There are instructions on how to programmatically register a DBCP datasource on JNDI here.
The first two lines of the sample code should be unnecessary, just create the default InitialContext and then rebind the datasource reference into it as described.

Here's a post that describes how to create a jboss service archive (SAR) that you can put in your EAR that will deploy a data source when the EAR is deployed, and remove it when the EAR in undeployed.

How do you use WebServiceMessageDrivenBean in Spring-WS?

How do you use the the org.springframework.ws.transport.jms.WebServiceMessageDrivenBean class from the Java Spring Framework - Spring-WS project?
There is very little documentation or examples available on the web.

From what I gather from reading the javadocs it looks like this allows a Spring WebServiceMessageReceiver to be invoked using a JMS client instead of a web services client. Hopefully that's right, because the rest of this is based on that assumption.
The basics of is should match with how you create a regular Spring message driven bean. There is a little bit of documentation on how to do that in the Spring Reference Manual. Also see the AbstractEnterpriseBean Javadoc for some additional information about how the Spring context is retrieved.
The extra configuration required for a WebServiceMessageDrivenBean appear to be a ConnectionFactory, a WebServiceMessageFactory, and your WebServiceMessageReceiver. These need to use the bean names specified in the Javadoc for the WebServiceMessageDrivenBean. The bean names are "connectionFactory", "messageFactory", and "messageReceiver" respectively.

Using the WebServiceMessageDrivenBean is very similar to the Spring support for Message Driven Beans (MDBS).
First you create a MDB:
public class HelloWorldMessageDrivenBean extends WebServiceMessageDrivenBean {
private static final long serialVersionUID = -2905491432314736668L;
}
That is it as far as the MDB goes!
Next you configure the MDB by adding the following following to the MDB definition in the ejb-jar.xml:
<env-entry>
<description></description>
<env-entry-name>ejb/BeanFactoryPath</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>
application-context.xml
</env-entry-value>
</env-entry>
This tells the Spring MDB support classes where to pick up your Spring configuration file.
You can now configure your endpoints either in the application-context.xml file or in addition using the annotation support.