The behavior of nested conversations and explicit conversation IDs seems
strange to me:
The *current* conversation ID is replaced with the explicit ID of a nested
conversation before the nested conversation is actually created... So my root
explicit converation ID always gets replaced by any
I removed the description from all entries in pages.xml. Fortunately I wasn't
using it for anyting yet. However that has made no change to the discussed
behavior. Navigating to different views within the same conversation changes
the viewId associated with the conversation.
View the
I need to keep using pages.xml as it's the only way to provide a URL
abstraction for action methods. I hope someday it supports even more free-form
URL patterns, actually.
It appears to me that when I navigate around within the same conversation, Seam
keeps track of the last viewId for that
When resuming an existing conversation with the same explicit id, it would be
nice to have some control over the view ID that the conversation is redirected
to. Right now of course it redirects to whatever view ID is set on the
conversation.
Typically I'm finding that when resuming a
Phrased differently, I guess this would be the idea of a conversation home.
Or, the idea of more control over conversation resuming...
Perhaps by default Seam could simply use the very first ViewId associated with
a conversation as the home view ID. Then, a new option in @Begin could be:
Please just don't break the ability to have multiple WARs in the same EAR!
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3952732#3952732
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3952732
Using Tomcat but need to do
I'm excited about the potential behind pages.xml, but there seems to be
limitations, especially with regards to the underlying JSF impl.
Chiefly, I've had no success in using a URL request path that does not map back
to an existing view file. For example, take the request:
As we discussed, I can work around this for Session scoped SFSB's by using the
JBoss specific @CacheInfo annotation, setting the timeout to be the same as an
HttpSession.
But what about Application scoped SFSB's? We run into this same problem due to
the aforementioned reasons in this thread.
OK.
Another idea: if there was a hook for Seam to set those in JBoss per component,
Seam could keep those in-sync with whatever settings were in web.xml regarding
conversation timeout and session timeout.
View the original post :
I asked the EJB3 forum. The default expiration on SFSB is 300 seconds.
There are custom JBoss annotations called @CacheConfig for both Simple and Tree
caches which allow this to be customized on a per-bean basis.
This all may prompt some clarification in the Seam docs? My general notion of
a
Thanks.
I see that I can also change this setting granularly using the @CacheConfig
annotation. I'd put this on the @Stateful implementation class, correct?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3951321#3951321
Reply to the post :
This is causing serious problems for our application. I tried switching to
EJB3Clustered to hopefully use the TreeCache, but for some reason it's still
using SimpleStatefulCache.
| javax.ejb.EJBNoSuchObjectException: Could not find Stateful bean:
3j001-gthwm3-eofzrkxj-1-eogs4rla-sb
|
To clarify, @Begin a conversation in a PAGE scoped component during the GET?
Wouldn't the PAGE scoped component get destroyed at the end of the lifecycle
making it unavailable if the conversation is then carried out?
How are other folks handling this? This issue would come into play with any
Is there logging somewhere that says:
Removing XYZ SFSB due to exception: blah blah..?
That might be helpful at least. We're getting EJBNoSuchObject exceptions in
our log all over the place with no clear reason why -- there are no other
exceptions in the log files.
Ryan
View the original
I'm seeing this in conjunction with a session scoped bean...
Without knowing a thing about the internals of SFSB, Seam, etc... is it
possible that any cache / expiration setting for the session scoped SFSB is
SHORTER than it needs to be?
I'm not sure where this value is held, but if my
What is the expiration time of an SFSB out of the SimpleStatefulCache?
Also, are there any other criteria for removing an SFSB from
SimpleStatefulCache. For example, I know that an unchecked exception thrown by
the SFSB will cause it to be removed.
Thanks,
Ryan
View the original post :
I get this exception without fail when Seam tries to destroy an object:
javax.ejb.EJBNoSuchObjectException: Could not find Stateful bean:
5c4o02-7eucln-eoekzs0b-1-eoel3ii8-2w
It's always in conjunction with:
11:56:27,202 WARN [Contexts] Could not destroy component: XYZ
It occurs for any
We use the begin-conversation-on-GET pattern extensively in our app --
typically when starting a conversation about a specific database object.
The problem with this model is that we're effectively creating far too many
unnecessary conversations as a user bounces around freeform in the web
Can/should conversations be used to keep track of a logged in user
(traditionally done with a session). I was thinking of the case where a user
signs in and a new conversation is started. This would effectively be the
root of the conversation stack for the lifetime of the user's interaction
I've been using @Begin and @End for a while now, in what I consider very basic
ways. All works relatively well. In an effort to get a deeper understanding
of conversations and perhaps use them in a more advanced way, I tried to see
what was going on under the covers:
| #{conversation.id}
This also is not multiple WAR (in one EAR) safe:
|private static boolean exists = false;
|
|protected AbstractSeamPhaseListener()
|{
| if (exists) log.warn(There should only be one Seam phase listener
per application);
| exists=true;
|}
|
View
Upgrading from 4.0.3 SP1 to 4.0.4 CR2.
JNDI used to be full class name of the @Consumer object..
In 4.0.4 it says that name is not bound.
What is it now?
Thanks,
Ryan
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3940570#3940570
Reply to the post :
FYI, I've tried:
- FQL of Consumer (ala 4.0.3SP1)
- ear/BeanName/local
- ear/BeanName/remote
The trail blazer is still using FQL of Producer now?
http://trailblazer.demo.jboss.com/EJB3Trail/serviceobjects/mdpojo/code/calculator.jsp.html
I'll try that.
View the original post :
This exception swallows up other exceptions, hiding the *real* reason for the
error. See the conclusion of:
http://www.jboss.com/index.html?module=bbop=viewtopict=81613
So, there is some method of yours that is causing an exception. Instead of
seeing the actual exception, you get this
He's not using SEMPPL + his own TX management. He's using his own TX
management despite SEMPPL.
He only moved away from SEMPPL to his own TX management when he could not
resolve the exception previously mentioned in this thread: could not register
synchronization with JTA TransactionManager,
anonymous wrote : Right, but SEMPPL does tx management. In fact, that is *all*
it does. If you want to do your own tx management, you don't need it.
As I read his thread, he did stop using SEMPPL and switched to the regular
SeamPhaseListener + custom TX management because he could not resolve
It wasn't clear to me that the synchronization exception is responsible for
swallowing up other exception causes. In a post in this same thread it was
said that either the application or JSF is swallowing exceptions, which
doesn't appear to be the case at all.
Is this exception masking
We built our application using Seam (beta 1) as an integral part. To that end,
Seam participates fully in translating URLs into view selection / creation
during GET requests.
For example, translating the URL:
/articles/db-driven-title.html
To perform this URL to view translation / setup,
Hmm... I didn't realize the scope of the page actions framework. Maybe
something like view-id=* might work. Let me play around with that.
Ryan
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3939942#3939942
Reply to the post :
CR2. If multiple WARs are in the same EAR, and both WARs are Seam
applications, then this method impl causes problems.
For example, one WAR is loading/seeing the pages.xml of the other WAR.
Please let me know if you need additional information.
Ryan
View the original post :
Upgrading from beta1 to CR2. Continuing to use
SeamExtendedManagedPhaseListener as always. I have a Session scoped component
that holds an entity reference. However, I'm now receiving a
LazyInitializationException when accessing that entity on the next request:
|
According to:
http://wiki.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration
scoping only works at the top-most level, in this case the EAR. So, there's no
way to scope off WARs from each other within the same EAR. You can only scope
off one EAR from other EARs.
Couldn't / shouldn't
Thanks. I converted those beans accordingly. No more LazyInitException.
Back to this error now, though:
| 11:02:43,668 ERROR [STDERR] org.hibernate.TransactionException: could not
register synchronization w
| ith JTA TransactionManager
| at
g.tomassoni, did you ever find a solution to your problem of:
could not register synchronization with JTA TransactionManager
We are experiencing this after upgrading Seam/Jboss/EJB3 and are unable to find
the source. Similar to your description, the first request works fine, and
then the
Between the phases listened to, and the ordering of the phase listeners in the
faces-config, I should be able to have them fire in whatever order I need
without extending Seam's phase listener.
What is the earliest phase point (before/after) where I should be able to start
accessing Seam
I need to be able to use Seam components during createView of a ViewHandler (at
least). This was working in beta 1, and we need to be to get back to that
ability to upgrade.
The problem with using Seam components then is that there is no conversation
until you get to afterPhase RESTORE_VIEW
Upgrading from beta 1 to CR1. We use a custom PhaseListener executing
afterPhase RESTORE_VIEW.
Unfortunately we're having several problems migrating this to CR1 (was working
in beta 1). This PhaseListener itself accesses Seam components so the timing
of it is obviously crucial to the
As long as we're on the topic, I could really use a scope that sits between
Application and Session. I implemented a quasi-scope myself using an
Application scoped bean + a Map, though it's not as clean as using a pure Seam
scope.
This is a specific case I realize, but maybe it would be cool
Hi Yannn,
I think you'll find the current stability of beta 2 perfectly acceptable for an
initial production release in May.
Best regards,
Ryan
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3926548#3926548
Reply to the post :
anonymous wrote : So, it seems to me that this potential for conflicts is more
a problem with the EJB spec itself than with our implementation.
True enough. Here's a suggestion for Seam, then. Given the built in naming
capacity of EJB via Entity/Stateful/Stateless(name=), what I'd like to see
I guess I always (incorrectly) assumed that JNDI lookups were automatically
isolated to the EAR that I'm in -- by nature preventing any conflicts across
EARs...
It's weird to me that by default multiple EARs share the same class / name
lookup space.
View the original post :
I'd definitely give a +1 vote for:
... @Component annotation that implies the @Name from the EJB name.
Ryan
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3922649#3922649
Reply to the post :
I don't know if it was a change in the ejb spec, Seam, or both, but my Seam
code has just become a whole lot more complicated and error prone with this new
release -- all with regard to the new JNDI naming requirements.
For example, my *.ejb contains code for multiple web applications. They
To preface, I appreciate the hard work and effort on this important project.
I hate to be abrupt, but this new JNDI name resolution behavior versus beta 1
is unusable for large applications. (Actually, in my opinion, even error prone
for small applications).
Beta 1 was simple,
I suppose it's ultimately a matter of aesthetics and it does have workarounds.
However, it is just one more thing I and others are going to have to keep in
mind while developing: Does this unqualified class name conflict with a class
name in another *package*. If so, then I have to give it a
anonymous wrote : Re: EJB3 will throw an exception if you have to EJBs with
the same EJB name in the same EAR.
Not currently. Instead, the application starts up perfectly -- without
exception, error, or warning. Two beans with the *same* JNDI are printed in
the log:
| 18:36:27,841 INFO
I'm confused about the interplay of these annotations on a SFSB.
As I understand it, to get Seam to remove the bean when the context ends, I
need to annotate:
@Destroy and @Remove on a method.
I need to capture expiration of that bean though. Where's the best place to
cleanup the bean or
Still using beta 1.
As recommended in the Seam docs, all of my beans have a method with @Destroy
@Remove on them. Beyond that, these methods are no-ops.
Yet, whenever the SeamListener runs to expire out the session, this shows up in
the error logs:
| java.lang.IllegalStateException: No
Re: Note that the conversation timeout stuff does not run in a background
thread. You have to hit the server witha request in the same session context to
actually force any timeouts that are due.
But, they would get expired in the background when the session expires,
right? Via SeamListener?
More of the stacktrace after my previous post:
| at org.jboss.seam.contexts.Contexts.callDestroyMethod(Unknown
Source)
| at org.jboss.seam.contexts.Contexts.destroy(Unknown Source)
| at org.jboss.seam.contexts.Lifecycle.endSession(Unknown Source)
| at
Regarding conversations, JBPM, workflow annotations, etc..
While appreciate that Seam is (hopefully just initially) standardizing on JBPM
for most workflow functionality, what I would LOVE to see is Seam also support
a more lightweight workflow engine that is geared towards a non-persistent
werpu,
I think something like your idea about the generic data model has been
previously discussed. You might want to check out this thread:
http://www.jboss.com/index.html?module=bbop=viewtopict=70199
Gavin actually came up with some related code but didn't appear to offer clear
advantages.
Thanks for the input. RE: My reverse engineered crud app stuff has the
freeform model you are describing.
I'm not sure where that's located at? I'd like to take a look and compare it
to what I'm doing.
Ryan
View the original post :
To prefix: I'm using Seam extended managed transactions.
I've run into a use-case that seems to lie somewhere in the realm of
conversations, yet doesn't quite fit current conversational semantics exactly.
Obviously conversations seem best suited to a page-to-page wizard style UI. A
flow with
Perhaps it's the notion of a save point that I'm getting at? A point
intermediary to the explicit end of the conversation where progress is
committed, but the conversation is NOT ended.
For the UserTransaction, it would be a commit/begin, and the current
conversation bean(s) would stay a part
I find that if a view contains very granular forms, then it is sometimes
convenient for the same backing bean to handle several of these forms. In
other words: a different action per form, where each action is on the same
backing bean.
This doesn't work well for server side Seam validation,
I'm missing something very basic here. I'm using the Seam managed extended
persistence + a conversation scoped bean. It's a very simple form that updates
values on an existing entity.
In my @Begin method, I load up the entity and store it the conversation bean.
The subsequent view shows the
Ah, I'm not insane! Thanks for the quick response. I didn't think merge was
necessary either. I'll try this right away.
Ryan
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3911991#3911991
Reply to the post :
A while back I suggested that create=true be the default for @In. Gavin didn't
think that would be very safe -- after further use I'd have to agree.
create=false makes sense as the @In default.
However, I can't get around the fact that in my use there are several component
beans that are
Hello, new to J2EE, and I have a deployment question.
We have two primary web applications: A and B. Each web application has its own
release cycle. For example, A will be updated quite a bit more frequently than
B. Therefore, we will package and deploy A and B in their own separate EARs.
The
60 matches
Mail list logo
