Moved up to Seam 2.0 CR3, and JBoss 4.2.2. I also optimized some code, got rid of some useless error logging, etc...

Hopefully it will perform a little better:) So far it seems to process incoming e-mail much faster, which was a bottleneck under load.

Enjoy!

I am working on a new application, which will require some scheduled jobs. I used EJB3 Timers in 10MinuteMail, but now Seam includes and uses Quartz, an open source scheduling system. So I figured I'd try the new hotness.

So far, it's been a rough road, and I'm not 100% up and running yet (hence the part 1 in the title), but I wanted to share what I've learned along the way as the Seam documentation is lacking a lot of information (although some of what's below mirrors the Seam documentation).

First you have to enable the Quartz engine for handling @Asynchronous methods. Add this line to your components.xml file:

<async:quartz-dispatcher />

I also found that I had to define the async namespace in my component.xml (generated by seam-gen from Seam 2.0 CR1):

xmlns:async="http://jboss.com/products/seam/async"

Then I set up my method:

@Asynchronous
public QuartzTriggerHandle scheduleSiteCheck(@Expiration
Date pWhen, @IntervalDuration
Long pInterval, Long pSiteId) {
Site site = (Site) entityManager.createQuery("from Site where id = :id").setParameter("id", pSiteId)
.getSingleResult();
checkSite(site);
return null;
}

(more...)

This is from a post Jeremy Sears made here on the ATG_Tech Google Group, but I thought it was nice and clear and worth reposting. All credit to Jeremy for this:

"In general, the design pattern for updating an order is as follows:

1. Acquire lock-manager write lock on profile id from the /atg/commerce/order/LocalLockManager
2. Begin Transaction
3. Synchronize on the Order object.
4. Modify Order
5. Call OrderManager.updateOrder()
6. Release Order synchronization
7. End Transaction
8. Release lock-manager write lock on profile id from the /atg/commerce/order/LocalLockManager

If you extend atg.commerce.order.purchase.PurchaseProcessFormHander, then steps 1,2,7 & 8 are done for you in the beforeSet and afterSet method implementations. Steps 3&6 are no longer strictly necessary, but are still good practice. Steps 3-6 should be performed manually in your application code. Calling step 5 within the transaction is mandatory and the lock manager work should always wrap the transaction to prevent some rare transaction race conditions. "

Adding a CAPTCHA to a form using Seam is easy now that Seam is bundling jCaptcha.

The Seam documentaiton is good, and can be found in section 13.9 here:

http://docs.jboss.com/seam/2.0.0.CR2/reference/en/html/security.html#d0e7755

If you used seam-gen to create your project, you will need to make a few changes.

First, you need to modify your project's ant build script to deploy the captcha jar into your ear (or possibly .war). In the target "ear" of the build.xml file, you will find a list of many jar files being copied from your project's lib directory into the ear. Simply add the captcha jar to that list, like this:

<include name="lib/jcaptcha-all-1.0-RC6.jar"></include>

Now that the jar is deploying, you need to reference it in the application.xml file found under your project's resources/META-INF directory. Add this entry:

<module>
<ejb>lib/jcaptcha-all-1.0-RC6.jar</ejb>
</module>

If you used seam-gen you will find that the Seam Resource Servlet is already defined in your web.xml so the step defined in the documentation in section 13.9.1 is not necessary.

(more...)

I recently setup a dev/build server with Jira, Confluence, Hudson, ATG (with two web apps and the atg admin), Oracle (with web admin), and Postgres (with web admin). I'm running everything independantly, and everything is listening on it's own high number port. This makes the URLs ugly, and finding what you want tricky.

I used Apache 2.2 and mod_proxy_http to wrap all of the services in the Apache running on port 80.

Any Apache 2.2 installation should come with mod_proxy and mod_proxy_http. You may need to activate them with something like this:
LoadModule proxy_module /usr/lib/apache2/modules/mod_proxy.so
LoadModule proxy_http_module /usr/lib/apache2/modules/mod_proxy_http.so

then set a basic configuration for security:
ProxyRequests Off
ProxyPreserveHost On

<Proxy *>
Order deny,allow
Allow from all
</Proxy>

It's best to ensure all the applications you are trying to wrap are listening at context roots, not the base URL/port. So you want hudson on :9000/hudson/ or whatever your setup has (for instance: java -jar hudson.war --httpPost=9000 --prefix=/hudson ). Same for Jira and everything else.

Then setup your proxy mappings in your apache configs.

ProxyPass /jira http://localhost:8080/jira
ProxyPassReverse /jira http://localhost:8080/jira
<Location /jira>
Order allow,deny
Allow from all
</Location>

Repeat for all of your applications. Then just restart apache to pickup all the changes:

apachectl restart

So now we have Jira at host/jira, Confluence at host/confluence, Hudson at host/hudson, and so on. Pretty, easy to book mark, easy to cross link. It just looks more professional.