Good news everyone!
I now have a cover image selected for the book, Arquillian Testing Guide. It's going to be the 1964 World's Fair, home of the climactic battle from Men In Black.
Going with the photographer next weekend to take the pictures. One step closer to getting a pre-order up.
Sunday, January 20, 2013
Sunday, January 13, 2013
And then I wrote a book
I started writing a similar blog post to this around New Year's but after reading it a few times it didn't quite convey what I was hoping for.
If you've been living under a rock, I wrote a book. Yes, I can finally say I wrote it. First draft is completely in the publisher's hands and reviews going on. So far I've done one chapter's final draft but have plenty more to do over the next six weeks or so. Hopefully nothing major comes up.
The book's subject is Arquillian, the leading deployment automation and extension framework for java testing. It pushed me to learn more about the tools and even question what I knew about how they worked. Overall, I think readers who are new to Arquillian or even automated testing will find it very useful. It's being published by Packt, and it fits into their "Getting Started" area of books so it's not meant for more advanced users, but generally novices.
One thing I should point out is that I am being paid to write the book. If you're not aware, I lost my mother about seven years ago to pancreatic cancer. The Pancreas Multidisciplinary Cancer Team at Johns Hopkins takes donations so I've decided to donate a portion of the proceeds in my mother's name to the team.
If you've been living under a rock, I wrote a book. Yes, I can finally say I wrote it. First draft is completely in the publisher's hands and reviews going on. So far I've done one chapter's final draft but have plenty more to do over the next six weeks or so. Hopefully nothing major comes up.
The book's subject is Arquillian, the leading deployment automation and extension framework for java testing. It pushed me to learn more about the tools and even question what I knew about how they worked. Overall, I think readers who are new to Arquillian or even automated testing will find it very useful. It's being published by Packt, and it fits into their "Getting Started" area of books so it's not meant for more advanced users, but generally novices.
One thing I should point out is that I am being paid to write the book. If you're not aware, I lost my mother about seven years ago to pancreatic cancer. The Pancreas Multidisciplinary Cancer Team at Johns Hopkins takes donations so I've decided to donate a portion of the proceeds in my mother's name to the team.
Tuesday, November 20, 2012
LinkedIn Updates
Well, if it's not already known, I recently left Burlington Coat Factory and joined the team at Sparta Systems. The most curious thing to note is the influx of LinkedIn views, connection requests and overall traffic. I'm used recruiters pinging me occasionally on LinkedIn saying, roughly, "OMG I have the greatest job for you ever email me for details." Then you email them and receive back jobs all over the state/rough conditions. Worst yet, you do end up interviewing with these people and they can be completely disorganized to the point where the job is clearly too painful.
I will say I found LinkedIn to be a very useful tool during my job search. I was able to research the people I was interviewing with before hand, what companies they came from and how they were related previously. Also gave me a good idea about what they may be looking for in a new recruit. Made a world of difference.
I will say I found LinkedIn to be a very useful tool during my job search. I was able to research the people I was interviewing with before hand, what companies they came from and how they were related previously. Also gave me a good idea about what they may be looking for in a new recruit. Made a world of difference.
Sunday, August 26, 2012
Arquillian, WebLogic with a HIbernate Enabled WebApp
For some upcoming work related applications, I decided to give a try to Arquillian and WebLogic. Our constraint though was to ensure that we're using Hibernate, since we get very odd results when using EclipseLink in our WebLogic apps.
We're targetting WebLogic 12c for new applications, which ships with tools like SLF4J, Weld in our app server. Lots of libraries are already loaded in your application as a result:
- SLF4J
- Javassist
- Jersey
- Jackson/Jettison
As a result of all of these libraries being available, you can get some very unexpected results trying to drop Hibernate in to your application. In my case I was using it as a JPA implementation. This is what my persistence.xml looks like as a result:
jdbc/LocalApps
name="hibernate.hbm2ddl.auto" value="update"/>
name="hibernate.transaction.jta.platform"
In this scenario, I was using a MySQL database, where the connection was available as jdbc/LocalApps. You can see on line 6 that I have set my JPA provider to Hibernate. I ensured that Hibernate was in my project using the following dependency:
hibernate-entitymanager
4.1.5.SP1
javassist
org.javassist
I had to remove javassist from Hibernate's dependency since it will conflict with Weld. If you don't, you will receive deployment failures. The javassist version deployed with WebLogic is binary compatible with Hibernate 4.1.5.SP1. If you do not make this change, CDI injection will not work with your application.
Next up, we have to deal with an AST/ANTLR issue. Hibernate uses AST for query object reading. When you create a query "select p from Person p" it uses AST to read these tokens. WebLogic's version is not binary compatible, so you cannot simply exclude the library. You have to include it in your application. In order to allow WebLogic core and your application to operate, you'll need the following weblogic.xml in your WAR file
Now you should be able to deploy your Hibernate Web App on WebLogic 12c. Now if you're like me, you want to start testing this application. You'll want to define the following Deployment method in yoru arquillian test case
The first four lines tell ShrinkWrap to gather all dependencies in the pom file - this will include hibernate as well. Similar to what we have to do to build the real deployment, we need to add a few extra items. We'll need the weblogic.xml used to deploy the application, as well as the persistence.xml. Note that you must use addAsResource and include the file location. In order to ease my testing, I added the following to my build section of the pom file:
src/main/resources
src/main/webapp/WEB-INF
web
This will add these locations to your test classpath. This should simplify gathering files. This could also be used if you are working with ArquillianDrone to test your web app. Hopefully with these tips, you can simplify any pains when using Arquillian and WebLogic.
The source code for this tutorial can be found here: https://github.com/johnament/tad-arquillian-weblogic-hibernate
Happy Testing!
We're targetting WebLogic 12c for new applications, which ships with tools like SLF4J, Weld in our app server. Lots of libraries are already loaded in your application as a result:
- SLF4J
- Javassist
- Jersey
- Jackson/Jettison
As a result of all of these libraries being available, you can get some very unexpected results trying to drop Hibernate in to your application. In my case I was using it as a JPA implementation. This is what my persistence.xml looks like as a result:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
value="org.hibernate.service.jta.platform.internal.WeblogicJtaPlatform" />
In this scenario, I was using a MySQL database, where the connection was available as jdbc/LocalApps. You can see on line 6 that I have set my JPA provider to Hibernate. I ensured that Hibernate was in my project using the following dependency:
org.hibernate
I had to remove javassist from Hibernate's dependency since it will conflict with Weld. If you don't, you will receive deployment failures. The javassist version deployed with WebLogic is binary compatible with Hibernate 4.1.5.SP1. If you do not make this change, CDI injection will not work with your application.
Next up, we have to deal with an AST/ANTLR issue. Hibernate uses AST for query object reading. When you create a query "select p from Person p" it uses AST to read these tokens. WebLogic's version is not binary compatible, so you cannot simply exclude the library. You have to include it in your application. In order to allow WebLogic core and your application to operate, you'll need the following weblogic.xml in your WAR file
1 2 3 4 5 |
|
Now you should be able to deploy your Hibernate Web App on WebLogic 12c. Now if you're like me, you want to start testing this application. You'll want to define the following Deployment method in yoru arquillian test case
File[] libs = DependencyResolvers.use(MavenDependencyResolver.class).loadEffectivePom("pom.xml").importAllDependencies().resolveAsFiles();WebArchive wa = ShrinkWrap.create(WebArchive.class,"foo.war").addClasses(BasicEntity.class,BasicEntityDAO.class).addAsLibraries(libs).addAsWebInfResource("web/weblogic.xml","weblogic.xml").addAsWebInfResource(EmptyAsset.INSTANCE, "beans.xml").addAsResource("META-INF/persistence.xml","META-INF/persistence.xml");
The first four lines tell ShrinkWrap to gather all dependencies in the pom file - this will include hibernate as well. Similar to what we have to do to build the real deployment, we need to add a few extra items. We'll need the weblogic.xml used to deploy the application, as well as the persistence.xml. Note that you must use addAsResource and include the file location. In order to ease my testing, I added the following to my build section of the pom file:
src/test/resources
This will add these locations to your test classpath. This should simplify gathering files. This could also be used if you are working with ArquillianDrone to test your web app. Hopefully with these tips, you can simplify any pains when using Arquillian and WebLogic.
The source code for this tutorial can be found here: https://github.com/johnament/tad-arquillian-weblogic-hibernate
Happy Testing!
Saturday, June 4, 2011
Seam JMS 3.0.0.Beta2 is now out!
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!
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!
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)