Today I started using Tomcat 5.5.7 instead of 5.0.28. It was fairly easy to install on my PowerBook - I just had to add the xerces and jmx JARs from the compat package to get things working. The one thing I noticed that's different from Tomcat 5.0.28 is that when I deploy any file, it reloads the context. This can be a pain when I'm just copying JSPs into the webapps directory. I'm willing to admit it could be a problem with my "maven deploy" goal, but since this didn't happen on 5.0.28, I suspect it's the newer version of Tomcat. On 5.0.28, the context was only auto-reloaded when I updated files in the classpath.
The main reason this was frustrating is because we look up a bunch of data from a web service on app startup. The API we're talking to is nice and slow and it takes almost 50 seconds to start our application. Rather than go back to the older version of Tomcat, I wrote some code to serialize all the ServletContext variables to disk, and then check for that file on startup. If the file exists, it deserializes it and puts all the objects back in the ServletContext. Works pretty good and certainly speeds up my development environment. After all this, I'll probably downgrade to 5.0.28. Auto-reloading when classpath files change seems like a better way to go.
Last night, I attended Denver's JUG meeting. Below are my notes from the event.
I'm at DJUG listening to Christian and Kris (from Adigio)
talk about their experience with using Spring, WebWork, Hibernate, Lucene
and SiteMesh to develop JUG
Central (I wonder if they knew
this name and concept already
exists?). JSPs are for the view and MySQL powers
the data. This presentation is designed to explain a bit about each framework,
and also tips/tricks and pitfalls they experienced when developing the site.
They started working on the application in August of last year and deployed
it into production in December.
Christian said they weren't going to go into the how for each framework,
but Kris has had quite a few slides on SiteMesh so far. I don't blame him
- it's a great tool and only a handful of folks (of about 50-60) have heard
of it.
SiteMesh Pitfalls: Poor integration with Velocity and some
other frameworks. BTW, if you're using Tapestry - Erik
Hatcher recently
created a JIRA patch with a Tapestry
Decorator.
Now Kris is talking about WebWork and since he's a framework
junkie, apparently
this is going to be the largest part of the presentation. I think one of
the nicest parts of WebWork is its auto-type conversion. The only other
frameworks I've seen that have this is are JSF and Tapestry. For those
that like WebWork and don't like JSF - you might find it disturbing that
the WebWork actions (and their tests) in AppFuse are very similar to
the JSF managed beans. I would take it as a compliment if I were a WebWork
developer.
One nice thing about XWork's action configuration is you can specify a "method"
parameter for a particular action. Struts recently added this with its MappingDispatchAction
.
I'm using this on my current project and it works quite well. Kris really
likes WebWork's front-page controller pattern - where you use the <ww:action>
tag to execute the action when the page is loaded. Personally, I don't have
a problem with going through actions to get to my view templates. Kris finished
up his WebWork piece with a plug for AppFuse (thanks!) and WebWork in Action.
Congrats to all the authors - wonder if it'll be published before WebWork
Live?
Now Christian is talking about Hibernate and its mapping files - and how you
can generate your database schema from them - or generate your mapping files
from a database. They used XDoclet to generate the mapping files in this
particular project.
Hibernate Pitfalls: Think about lazy-loading early. Problems
arise when you try to share Hibernate-managed objects across (Hibernate)
sessions transparently. Christian mentions that Spring's OpenSessionInViewFilter
is a nice way to solve the problem.
Hibernate Tips: Spring simplifies using Hibernate and makes
declarative transactions easy. Read Hibernate
in Action before starting
development. Plan to spend some time learning how to express your data model
with Hibernate relationships (one-to-one, one-to-many, many-to-many, etc.).
Christian is now talking about Spring and how it works. After thinking and
writing about Spring so much in the last year, I'll just skip over regurgitating
this part. ;-) His main recommendation: use real injection instead of appContext.getBean("beanName")
.
Other tools used: Lucene for searching and POI for indexing Word, Excel and
PowerPoint files. Velocity used for templating e-mail messages.
Service-oriented Architecture (SOA) with Business Process Execution
Language (BPEL)
Presented by Kevin Geminiuc and Owen Newnan from Policy Studies
This point of this presentation is to communicate what it's like to implement
BPEL in a J2EE Container. BPEL is a layer on top of web services. BPEL is
a programming language that you can use to program business processes. Allows
you to divorce your business process from being human-centric to being document-centric.
At Policy Studies, they're using iLog JRules rules engine and Oracle's BPEL
implementation.
Benefits:
- Process Visiblity
- Process Agility
- Powerful Language
- Open
- Backed by "the Big Boys" (BEA, Microsoft, IBM)
History: Formerly knows as BPEL4WS, WSBPEL. Open standards
based. Orchestrates web services with SOA.
Where we are today: Emerging technology (prepare to bang
your head against the wall). .NET and Java products exist, as well as J2EE
container integration.
BPEL is: |
BPEL is not: |
- A programming language for business processes
- A language for specifying e-business transactions
- XML-based layer atop WSDL
- A declarative and procedural language
|
- Designed for human workflow
- A JSR spec (207 and 208 are related though)
- Mature Technology
- Your typical web services application
- asynchrony as well as synchrony
- callbacks
- composite synchronous services
|
BPEL & WS Standards: BPEL, XPath, WSDL, WS-Addressing,
SOAP, XML-Schema, WSIF (Axis), TBD (WS-ReliableMessaging and JSRs 207/208).
Note that since BPEL depends on web services (which is not a truly reliable
service). Because of this, there are some proprietary extensions
available.
At this point, I became bored with the presentation and quit taking notes.
While the speakers had good intentions with their knowledge sharing, their
delivery needed some work. The code walkthrough and demos were presented
with a monotonous and unexcited tone, and a handful of folks left during
this part. In summary, BPEL looks like a good way to orchestrate your various
business processes. It allows you to call web services, EJBs and whatnot
simply by defining their locations and methods in XML.
In his demo, Kevin
used Oracle's BPEL Designer, which is an Eclipse
plugin that has
a nice drag-n-drop editor for managing your BPEL XML files. He also used
Oracle's BPEL
Process Manager, which seemed to be a lot like Jetspeed - you just
drop in the .ear and then deploy your processes to it. The only bad part
about the Process Manager is it's administration/deployment interface
only runs in IE.
If you're using BPEL in your projects, I'd be interested to hear the tools
you're using. As far as open-source BPEL process engines, they mentioned
Twister and ActiveBPEL.
I attended the Java User Group meeting tonight and managed to document a good portion of it. I hope to post it in the morning when I wake up. After the meeting, a number of us headed to the local brewery and enjoyed some brewskis together. We left around 11:20 and I made it home (riding my bike) at midnight. While it was 19°F when I rode to work this morning, the 26°F on the way home seemed a lot colder. Maybe it was the beer. Anyway, it's good to be home. Let's hope it warms up before I ride back in in 5 hours.