Your message was not delivered due to the following reason(s):
Your message could not be delivered because the destination computer was
unreachable within the allowed queue period. The amount of time
a message is queued before it is returned depends on local configura-
Most likely there is a network problem that prevented delivery, but
it is also possible that the computer is turned off, or does not
have a mail system running right now.
Your message was not delivered within 4 days:
Host 188.8.131.52 is not responding.
The following recipients did not receive this message:
Please reply to postmaster(a)lists.jboss.org
if you feel this message to be in error.
Seam-dev is for OSS project development, not Enterprise Seam product
On 11 Mar 2009, at 15:15, Ondřej Skutka wrote:
> I'm doing FP01 release testing and I came across this issue:
> According to
> http://testify.test.redhat.com/plancases.cgi?op=view&id=14194 I should
> do this:
> "The documents for the seamFP have had all references to other
> support removed, as well as other changes. Verify that the
> is modified and that those modifications do not effect the various
> of the documents."
> However there is a Tomcat mentioned several times in the docs, for
> example in tutorial.html there is a chapter 'Running the examples on
> So my question is whether this is ok or in other words whether Tomcat
> has different position (from our POV) than Weblogic, Websphere...
Something that we've been discussing is the idea creating a security
audit checklist that will cover Seam and the ways it interacts with
the outside world; initially, we want to focus on JSF, Seam Remoting
(Ajax) and Servlet but we will also consider adding in WS including
JAX-RS, Wicket, GWT and perhaps others, though these are what I can
think off. This checklist would then be added to the Seam QA process
(which is run through at release time).
We were wondering if you would be able to work with us on this? My
suggestion is, that as you (I hope ;-) have a good understanding of
the general approaches that could be used to exploit a Seam that you
would be to work with us both on an initial list of areas to focus on,
and then help us develop the checklist.
Let us know :)
We got this long standing issue with Seam 2.1.1 and running TestNG from
Meaning our JBT 3 GA will go out with Seam 2.1 TestNG being broken :(
Everything works fine if we replace seam.jar with a seam 2.0 jar so I'm
inclined to think some component scanning changes causes this.
Any idea of what it could be ?
We had similar issues with AS and JSF earlier - what was the fixes for
Would just like to be able to have a workaround or at least an
explanation of why it is not working for Seam 2.1.x but for every other
previous release of Seam...
On Mon, Mar 2, 2009 at 9:03 PM, Solomon Duskis <sduskis(a)gmail.com> wrote:
> Are you actively working on that integration?
The integration work resulted in a preview release last summer, then
we waited for RE to stabilize and GA. I checked two weeks or so ago,
and Jozef had already upgraded the Seam integration code to compile
and run against RE GA 1.0.
There is a chapter in the Seam reference documentation that describes
the integration and features:
The remaining issues range from trivial to major, however, there is
not much critical functionality missing. Jozef, are you aware of
anything that has not already been reported in JIRA?
We bundle these activities under the "WS" component in Seam JIRA:
> version of RESTEasy. Do you have some time to help out with that, and to
> point me in the right direction for the current Seam/RESTEasy code?
The code is in Seam trunk which is the 2.1.x release line. So now that
RE GA is here we would certainly welcome any help on ironing out the
remaining issues. Have a look at the reported stuff in JIRA and see if
you like to pick something - even if it's assigned to me ;)
I will go through the list again as well and see if there is anything
missing and maybe set some priorities. Jozef, let us know what your
For the future and more elaborate Seam/REST integration work: There
are some great ideas floating around, mostly things people have been
discussing directly or posting on some mailing list or another. My
opinion has been so far that we get the basic stuff working in Seam
2.1.x and then wait for the Web Beans RI to stabilize and start with
the more advanced REST stuff (like XHTML representation mapping with
Facelets) in Seam 3.
Last week I "fixed" Hibernate tools by adding support for controlling cascade, insert, update and a few other things on associations.
In that progress I noticed that the reverse engineering were setting all collection associations cascade to "all" and not "none" which I believe would be the better to avoid surprises.
I changed it to 'none' since our hbm.xml generation were not generating cascade at that point anyway, but of course when coming to seam-gen we use annotations and in here CascadeType.ALL were being output - with the new hibernate tools no cascade is set because CascadeType.NONE is the default.
This is of course a change in the semantics of generation and I just want to check what we would *really* like to do...
1) does this change actually break seam-gen in any way ? (I don't think so because all assocations is explicitly updated anyway (afaics))
2) What default do you think we should use for reveng, ALL or NONE (or something else ?)
p.s. A swift reply would be appreciated since we are going for a GA build within a few days ;)
p.p.s. If we find a better default I can add a checkbox in the tools to enable to old default if needed.
p.p.p.s. For Pete: The bug I mentioned last night was simply another indentifier misspelling we found that for some
reason hadn't been patched in our build - so that is a separate issue I'm trying to find the cause for in https://jira.jboss.org/jira/browse/JBIDE-3880
I've asked Pete a few questions about SeamText and he said I should ask you
Exploring SeamText 2.1.0.beta1 ANTLR grammar we've discovered that
form/input elements are legal to use, so it is valid to write:
<form action="http://somesite.com"><input type="file" /><input type="submit"
I suppose it is not safe that the user is possible to type in forms. What do
you think about it?