Finally, Beta2 of the Seam JMS project is now available. This is mostly a minor improvement release:
1. Support for TopicBuilders and QueueBuilders, simple interfaces for sending and receiving messages with JMS. To use one, just inject a reference:
@Inject QueueBuilder queueBuilder;
Then, choose destinations and send messages:
queueBuilder.destination("jms/SomeQueue").send("This is my text");
No need for complicated objects or anything. In addition, the TopicBuilder supports Subtopics. Subtopics are based around message selectors, using a String property sm_jms_subtopic.
2. Changes in the mapping APIs. Instead of using @Routing(RouteType.INGRESS) or @Routing(RouteType.EGRESS) you can simply use @Inbound and @Outbound. I figure this will be easier to read and remember.
3. Some big documentation clean ups occurred, and I'm still working on some more.
Visit the module homepage here: http://sfwk.org/Seam3/JMSModule
Grab the download here: http://sourceforge.net/projects/jboss/files/Seam/JMS
Visit the Seam Community Forums with any questions, comments or issues!
Saturday, June 4, 2011
Sunday, April 17, 2011
Running CDI Source on JBoss AS 6
For those unaware, last month an initiative called CDI Source was announced by Rick Hightower. It looks like their goals are pretty similar to Seam, a tool I've been using for a few years now; and most recently started actually contributing to!
I was curious yesterday (mostly because it was pouring here all day) to see what had come of it, and happened to notice they were first tackling CDI & Spring interoperability. Not a bad move I thought, Spring already has all of the add-ons you would be looking for (arguably too many), so being able to bring that in to a CDI enabled application makes a lot of sense. I would still argue that Spring really needs to be able to delegate down to an underlying CDI implementation in these cases, mostly for performance reasons.
I decided to clone their repositories. They have two currently, one is their underlying beancontainer and another for examples (they also host a resin plugin for maven, but out of scope..). When I cloned and started digging in to it, I found some things that were cool (tests worked out of the box) and some things I didn't like (platform dependence). I built the main project, no issue. I built the example spring app, had an issue there - tests didn't run. So I rebuilt without tests, generated a WAR file. I then tried to deploy it to JBoss AS 6. No luck, talk about nearly killing a VM. I deployed to a stopped JBoss instance, and attempted to start up, received a lot of classloader based errors (missing XAManager, base classloader setup wrong, etc). Never fun, though reminded me of the issues I have in Seam JMS :-)
When I dug into the code, I found a few problems. The biggest I saw was due to all of the extra dependencies that Spring pulls in, deployment to a full application server (as it always used to be) was going to be a challenge. I tried marking dependencies as provided, but no luck. Still were being pulled in for some reason. So I decided to pull out the pre-maven rule book and ripping out libraries under WEB-INF/lib. I was able to string the list down to these:
As of this morning, I saw that Rick had also been working on it, and made essentially the same change I did to the code to make it work with Weld.
I was curious yesterday (mostly because it was pouring here all day) to see what had come of it, and happened to notice they were first tackling CDI & Spring interoperability. Not a bad move I thought, Spring already has all of the add-ons you would be looking for (arguably too many), so being able to bring that in to a CDI enabled application makes a lot of sense. I would still argue that Spring really needs to be able to delegate down to an underlying CDI implementation in these cases, mostly for performance reasons.
I decided to clone their repositories. They have two currently, one is their underlying beancontainer and another for examples (they also host a resin plugin for maven, but out of scope..). When I cloned and started digging in to it, I found some things that were cool (tests worked out of the box) and some things I didn't like (platform dependence). I built the main project, no issue. I built the example spring app, had an issue there - tests didn't run. So I rebuilt without tests, generated a WAR file. I then tried to deploy it to JBoss AS 6. No luck, talk about nearly killing a VM. I deployed to a stopped JBoss instance, and attempted to start up, received a lot of classloader based errors (missing XAManager, base classloader setup wrong, etc). Never fun, though reminded me of the issues I have in Seam JMS :-)
When I dug into the code, I found a few problems. The biggest I saw was due to all of the extra dependencies that Spring pulls in, deployment to a full application server (as it always used to be) was going to be a challenge. I tried marking dependencies as provided, but no luck. Still were being pulled in for some reason. So I decided to pull out the pre-maven rule book and ripping out libraries under WEB-INF/lib. I was able to string the list down to these:
- aopalliance-1.0.jar
- aspectjrt-1.6.11.M2.jar
- aspectjweaver-1.6.11.M2.jar
- beancontainer-api-1.0-SNAPSHOT.jar
- commons-beanutils-1.8.0.jar
- commons-collections-3.1.jar
- commons-dbcp-1.3.jar
- commons-digester-2.0.jar
- commons-fileupload-1.2.1.jar
- commons-pool-1.5.4.jar
- dom4j-1.6.1.jar
- flexjson-2.1.jar
- jcl-over-slf4j-1.6.1.jar
- joda-time-1.6.jar
- slf4j-api-1.6.1.jar
- slf4j-log4j12-1.6.1.jar
- spring-aop-3.0.5.RELEASE.jar
- spring-asm-3.0.5.RELEASE.jar
- spring-aspects-3.0.5.RELEASE.jar
- spring-beans-3.0.5.RELEASE.jar
- springbridge-1.0-SNAPSHOT.jar
- spring-context-3.0.5.RELEASE.jar
- spring-context-support-3.0.5.RELEASE.jar
- spring-core-3.0.5.RELEASE.jar
- spring-expression-3.0.5.RELEASE.jar
- spring-jdbc-3.0.5.RELEASE.jar
- spring-js-resources-2.2.1.RELEASE.jar
- spring-orm-3.0.5.RELEASE.jar
- spring-tx-3.0.5.RELEASE.jar
- spring-web-3.0.5.RELEASE.jar
- spring-webmvc-3.0.5.RELEASE.jar
- tiles-api-2.2.1.jar
- tiles-core-2.2.1.jar
- tiles-jsp-2.2.1.jar
- tiles-servlet-2.2.1.jar
- tiles-template-2.2.1.jar
As of this morning, I saw that Rick had also been working on it, and made essentially the same change I did to the code to make it work with Weld.
Tuesday, April 5, 2011
Seam JMS 3.0.0.Beta1 is now available
I am ecstatic to announce the release of Seam JMS 3.0.0.Beta1 to the wild. This is the first release of the module intended for deployment on JBoss AS 6. With this release we have added support for both egress (outbound to a JMS Queue/Topic) and ingress (inbound from a JMS Queue/Topic) event routes. We also provide a simplified messaging API for use within applications.
Downloads
The Seam JMS 3.0.0.Beta1 package can be downloaded at http://sourceforge.net/projects/jboss/files/Seam/JMS
Documentation
You can find our Reference Guide as well as API Docs
Maven Users
The easiest way to get started in a maven project is to include the following dependency in your project. You'll need to make sure you have a repository reference to the JBoss Community Repository.
APIs
The core API for the module is around the MessageManager interface. This provides a series of convenient methods
Deployment Capabilities
You can also statically define routes within your application, both ingress and egress. You can define interfaces defining routes. Further details can be read in the Reference Guide.
Downloads
The Seam JMS 3.0.0.Beta1 package can be downloaded at http://sourceforge.net/projects/jboss/files/Seam/JMS
Documentation
You can find our Reference Guide as well as API Docs
Maven Users
The easiest way to get started in a maven project is to include the following dependency in your project. You'll need to make sure you have a repository reference to the JBoss Community Repository.
<dependency>
<groupid>org.jboss.seam.jms</groupid>
<artifactid>seam-jms</artifactid>
<version>3.0.0.Beta1</version>
</dependency>
APIs
The core API for the module is around the MessageManager interface. This provides a series of convenient methods
Deployment Capabilities
You can also statically define routes within your application, both ingress and egress. You can define interfaces defining routes. Further details can be read in the Reference Guide.
Subscribe to:
Posts (Atom)