That's great to hear. I've just downloaded the latest nightly, and will give
it a try.
Here's a question. I see two ways of approaching deploying sub-deployment
archives with these tools. One would be to have the war project have a .war
archive in Project Archives, the ejb jars have their
We had recently decided to stop using JBoss Tools because of their dependence
on WTP, which has been too buggy for us. This was unfortunate, because all our
work is Seam based, and the seam tools are really nice.
Now that Jboss Tools 2.1 supports seam projects that aren't WTP-based, I'm
There are two issues here, both of which may be too specific to more
complicated EAR deployments to be worth fixing in the projects that jboss tools
generates in its wizard.
(1) I'm using junit rather than testng, because the latter's output leaves much
to be desired, and we have testing tools
Ok, but for example, your SMPC in your components.xml shouldn't be specified in
multiple components.xml, but it may be injected all over the ear(*), in
different EJB modules. So if the validator is going to be useful, it has to
look in other projects for components, yes?
(*) This is the only
By default the jboss-tools generated war project within an ear project doesn't
have the EAR libraries checked as exported on the Order / Export tab of the
Java Build Path settings. Should it be, so that the test project picks up the
EAR libs when it runs?
View the original post :
Also...while I agree it's simple, it's a little problematic. Because I have
ejb jars in my ear which need to reference libs in the ear which the WAR
doesn't need to reference. But to make the test project able to test the code
in the EJB jars, I have to make the WAR reference those EJB libs
Hi,
If a component in an EJB project injects a component that is described in the
war project's components.xml, it works fine at runtime, but I get Uknown
context variable name in the IDE.
Is there a way to make the EJB project realize that it should look in the war
project for the
So after many hours, I'm finally grokking how the four projects work together,
and I like it :)
But I don't understand how the -test project is supposed to pick up its jar
dependencies for things that live in .ear/lib. The -ejb and -war projects get
the Ear Libraries magic library that picks
Hi,
If I take a seam-gen 2.0.1.GA generated project in Eclipse 3.3 with the
2.0.0.GA Jboss Tools plugins, and check the checkbox in Seam Settings and
pick a runtime, I don't get any of the features I expect, like completion of
EL, components listed in the Seam Components tab, etc. I didn't
I have a SLSB that is a seam component, and has a method annotated with
@Asychronous, with quartz as the underlying scheduler.
This method gets called asynchronously correctly _sometimes_, but as often as
not, it fails and I see this in the logs:
| 2008-01-08 13:46:30,857 ERROR [STDERR]
Hello,
ManagedPersistenceContext, upon passivation, checks to see if the entity
manager is dirty, and if not, closes it. I presume this is intended as an
optimization. But in a clustered environment, where a snapshot of the session
is taken upon each request that dirties the session,
[EMAIL PROTECTED] wrote : cpopetz wrote : where anAsyncMethod() is a method
marked @Aysnchronous. (I'd mark the observer itself as @Asynchronous, but that
gets ignored.)
|
| There is an open feature request for this to be supported (I think it makes
good sense).
|
Wonderful, thanks
Hi,
I'm experiencing an exception under heavy load using hibernate, which I believe
is a javassist bug.
The code that ProxyFactory.makeForwarder generates to invoke the handler is:
| * if (methods[index * 2] == null) {
| * methods[index * 2]
| * =
I have:
Events.instance().raiseTransactionSuccessEvent(doLongWorkAfterTxIsDone);
and
@Observer(doLongWorkAfterTxIsDone)
public void doWork() {
aSLSB.anAsyncMethod();
}
where anAsyncMethod() is a method marked @Aysnchronous. (I'd mark the observer
itself as @Asynchronous, but that gets
This bug:
http://jira.jboss.org/jira/browse/JBSEAM-2357
is preventing me from dropping our code, so I'm curious what the timeline is
for a seam release that contains its fix, or if I should patch 2.0.0GA locally
with this change:
Thanks for the information on the timeline. I'm running with the latest
nightly snapshot, which allows me to continue load testing, though I'm
reluctant to deploy to production with it.
With regard to the mailing list, I'm not so much looking for development
discussions. What I'm interested
I have multiple ears which are built out of the same source tree on different
branches that need to co-exist in one Jboss instance. I can use scoped
repositories to ensure the classes don't conflict, but I'm trying to determine
the best way to avoid the conflict that occurs with Seam's
I'm in the midst of transitioning a pretty large web app to use ejb3.0/seam.
The app was in sort of a post-Struts1.2 state, i.e. several years of rolling
our own internal framework to solve design problems until a decent web
framework could come along.
It seems like seam/jsf/ejb3.0 matches
I'm experiencing the following problem with seam 2.0.0CR3, hibernate 3.2.5ga,
hibernate EM 3.3.1 GA. I'm running with the embedded jboss EJB3 container
that's packaged with seam, so I'm not sure of its version number, but I don't
think this behavior is specific to the embedded container.
I
Doh, I see. I have to make the stateless, which the example in the docs did
(though it didn't describe why it did so.)
I still think it's a little strange to have the @Unwrap annotation being used
in that way. It would be better to have an @UponInjection annotation, which is
called
cpopetz wrote : Doh, I see. I have to make the stateless, which the example
in the docs did (though it didn't describe why it did so.)
| :)
My make the stateless should have been make the factory stateless but
because I wrapped factory in brackets it disappeared.
View the original post
Is there any timeline or roadmap for 2.0? Or can someone from the JBoss team
wager a guess and when 2.0 will be final? Quarter-year accuracy would be
enough for me.
We've been considering transitioning a rather large codebase to Seam, as it
seems to do a lot of things that we've rolled
22 matches
Mail list logo
