(This is the third try to post this messsage as it seems that the previous messages didn't go through...)
In order to help people use Seam on WebSphere, I have currently ready to
be committed, the artifacts to build a functional "booking" application
under WebSphere v7
The artifacts are grouped under a "websphere7-resources" directory that
groups the files tailored for WebSphere v7 and there is a
"build-websphere7.xml" file to build the ear file.
With this, this it is just a matter of running the build file, declaring
a connection pool in WebSphere and deploying the ear file on WebSphere
to get the "booking" application running on WebSphere v7
I plan also to review the section of the doc related to the usage of
seam on WebSphere v7 as what is in there is over-complicated and there
are may errors (and many jar are out opf date with seam 2.2 ...), and
also to include a section on how to configuire JNDI name resolution for
Seam with WebSphere v7 as it seems that many people have problems with this
- is the "booking" sample the right example to proposes this kind of thing?
- should it be better if I move my files from the "booking" sample to
the "je55/booking" sampleand make this work there? what is the
difference between both?
- is the structured proposed ok? ie the websphere7-resources directory
that contains the files specific to was and the build-webssphere7.xml
(very similar to what is done done in the "jpa" sample app)
I could commit this as soon as v2.2GA is out..
The Seam QE team has finished testing the 2.2.0 GA.
What was done:
- initial testing
- closing resolved JIRAs
- functional tests on JBoss 4.2.3 GA / JDK 5; JBoss 5.1.0 GA / JDK 6;
Tomcat 6 / JDK 6; JBoss embedded / JDK 5
- seam-gen tests
- Portlet Bridge
- Quick document review
- Manual testing examples without ftests: excel, guice, itext, mail,
metawidget, openid, tasks, ui
There are five unresolved JIRAs right now for the release:
- JBSEAM-4314 - Blog example needs additional jars for JBoss 4.x
Priority depends on whether we support JBoss 4.x. Do we?
- JBSEAM-4274 - hibernate-core.jar missing in Seam examples deployed to
Not sure whether it's valid.
- JBSEAM-4308 - Unable to run TestNG tests within JBDS due to missing
dependency - slf4j-api
- JBSEAM-4307 - Spring example needs cglib library
This is blocking deployment of one example.
- JBSEAM-4028 - way to outject someting in to the CURRENT conversation
even if a new one is started before the context is flushed
This is not a bug, it's a feature request.
Please review open issues and also review library changes in my 'initial
testing results' email. Marek didn't sort them all out.
These are library changes since 2.2.0.CR1:
testng.jar 5.6-200706070953 => 5.9-200903311355
Libraries needed in compile time:
jboss-common-core 2.0.4.GA => 2.2.3.GA
jboss-embedded-api beta3.SP7 => beta3.SP8
There is a problem validating xmls with jpdl-3.2.xsd schema. The
jpdl-3.2.xsd was replaced at http://jbpm.org/xsd/jpdl-3.2.xsd by
jpdl-4.0.xsd. I have reported this problem and it should be fixed soon.
I've started documenting the (uncommitted) performance improvements
I've enabled: http://www.seamframework.org/Documentation/HTTPClientserverOptimizationSt...
Later this week I'm going to roll out these changes on sfwk.org and
we'll see if it all works as expected. I'm also going to integrate the
Seam Remoting patch that allows caching of JS interfaces of several
Please have a look at the doc and tell me what I've been missing.
There is also one more thing we should discuss at some point for Seam 3:
We are duplicating lots of functionality in Seam that any JAX RS
implementation has. We should probably drop SeamResourceServlet and
maybe even SeamFilter in Seam3 and rebuild what we need on top of JAX-
RS. The downside is that we'd create a dependency on a JAX-RS
implementation. OTOH almost anyone might want one of these in the
I'm trying to verify this report: https://jira.jboss.org/jira/browse/JBSEAM-4299
If it is true, we need to fix the problem for the release.
Unfortunately the unit test works fine.
Because I'm on the road this weekend (through UMTS) and I forgot to
download the gigabytes of dependencies, I can't build and deploy a
real app. So I'll verify this on Monday - it's trivial though, feel
free to try before then and unblock the release.
Max and I discovered a way to change the permission scheme for a
project to correctly reflect the project members. The main change you
will see is that:
* even if you are a member of the committers group, you no longer have
committer privileges on the project - if I forgot to add you to the
list of project committers, then please ping me
* the assignee list is now limited to the list of project committers :-)
* more people now have admin rights (ability to add releases and
I want to upgrade TestNG from 5.6 to 5.9, however, there is this
comment in build/core.pom.xml:
<!-- Surefire can't cope with such a new version of testng, so we
have to specify it
here, otherwise ui build fails -->
After switching this to 5.9 I've had a clean build and tests. Can we
get this into 2.2 GA? If yes, I can probably commit some nice
enhancements to test infrastructure (dbunit, resteasy) tomorrow.
I am currently working on implementing Seam on part of a relatively high
traffic site (8k+ concurrent users) and optimizing our backend and frontend
to handle that traffic. When focusing on front-end, I'm trying to make sure
that the right HTTP caching headers are sent out -- but our Seam Remoting
/interface.js?componentName won't get cached due to it containing a query
string and the way browsers handle those
/remote.js always returns an HTTP 200 with the actual file contents,
whereas this file would only change with new Seam releases (is that
Also, neither of these JS files are combined, packed or minified.
The Seam Remoting InterfaceGenerator does have an interface cache for each
component, so at least that time is saved. But it still sends back
block all other downloads in the browser, this is especially noticeable with
load times, making the page seem slower.
A good potential solution (suggested by Dan Allen on twitter) to the first
issue... use the ReWrite filter. My guess would be something like this:
/interface/componentName.js --> interface.js?componentName
And if we sent the right HTTP caching headers, that would fix that issue
and browsers could cache it. But what about using multiple components? This
is what I propose...
these still are valid and "RESTful" URLs... and can be cached.
Is this something reasonable enough that I can take on as my first
Seam contribution? (Seems
(using the Java based YUI-compressor)
Please let me know your thoughts before I get started,