The documentation says they default to conversation scope but as far as I can
tell they are going to event. Am I missing something?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3956643#3956643
Reply to the post :
http://www.jboss.com/index.html?module=bb&o
That's actually how I had it. The reason I made the change is that I have CRUD
type functionality broken up over two SFSB components. One of them handles new
object creation and the other handles list/update/delete. When I create a new
object however, even if I inject the list/update bean int
Right, but as I understand the @DataModel annotation it doesn't outject the
actual annotated List into PAGE scope, it outjects a DataModel that wraps the
List, so why then when the DataModel is reconstituted is it overwriting the
perfectly good version of the wrapped List that is still containe
Ok, I'm obviously not being very clear.
I have a conversation scoped bean which contains a List. The List is outjected
using @DataModel(value="model", scope = ScopeType.PAGE). The DataModel is then
used in the normal way:
...
Now when the response is submitted I understand that a serialized
I see your point, but this seems to be mostly related to the @DataModel
annotation and it's implementation. What worries me more than the fact that my
@DataModelSelection is serialized and becomes a detached object is that every
object in the List that was outjected using @DataModel becomes det
I realized that shortly after I sent the post. Turns out serialization is
occuring because I had my @DataModel outjected to the page scope. I can see
why some type of storage within the component tree would be necessary between
requests, but couldn't the value binding be stored instead and the
I've switched from using the @PersistenceContext annotation to using seam
managed persistence with @In(create = true) and now I'm getting behavior that
doesn't make any sense to me. I load a list of objects, outject them as a
@DataModel then recieve the selected as a @DataModelSelection and try
Marco,
Using request parameters is absolutely not the right way to do it. Your
original concept is correct, it seems like it just needs some tweaking. To
tell you the truth, I'm not really sure why you are using Seam to create your
Item instances in the first place. Try removing the @In(crea
Injection occurs either on a field or on a setter depending on where you place
the @In annotation. It seems to me like you are confusing injection with jsf
data binding however. What exactly is happening and what did you expect?
View the original post :
http://www.jboss.com/index.html?module=
I'm not sure your problem is Seam related. Take a closer look at your
selectOneMenu, what it's outputting to the page and how your converter is
decoding the request params.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3949362#3949362
Reply to the post :
h
That would totally depend on your application. Having a conversation scope
available doesn't mean you should never use the session, it just gives you
another choice for storing data that should outlive the page which creates it
but which isn't necessary for the duration of the user's interactio
I'm having a problem with SFSB inheritence that seems very odd to me. I have
an abstract class/interface which is extended by a concrete implementation.
The superclass defines an abstract getEntityManager() method which returns an
EntityManager that has been injected using seam managed persist
I appreciate your feedback but not only have I tried it that way, I haven't
tried it any other way. I'm actually injecting the component into a field of
the local interface type, so just calling the method proves that it's available
as part of the SFSB. I've also checked the logs to make sure
It does seem to have fixed the problem. I'm surprised no one has run across
that before.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3949228#3949228
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3949228
__
It's seam managed, @In(create = true) and it works like a charm as long as the
method being called isn't part of the super-class/interface.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3949205#3949205
Reply to the post :
http://www.jboss.com/index.html?modu
I have no doubt that you are the man Gavin :) However is a seam managed entity
manager considered an extended persistence context? What I've done to my code
is to change:
@PersistenceContext(type=EXTENDED)
EntityManager entityManager;
to:
@In(create=true)
EntityManager entityManager;
along
Not sure if this is helpful or not, but the DAOs are injected using the @EJB
annotation.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3947808#3947808
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3947808
---
Hmm... This doesn't seem to be working the way I hoped it would. Let me
explain in a bit more detail.
I would really rather not tie the SLSB DAOs to Seam so that they are as
reusable between projects as possible, therefore they are using the plain
vanilla @PersistenceContext annotation. When
Well, in case anyone else is looking for this I'll answer my own question. It
seems that the following property in persistence.xml will do the trick:
Replace the value with the class that implements your naming strategy. I
haven't tested this yet but I believe it does work.
View the origina
The value attribute of the @DataModel is the name that it is outjected as.
Each @DataModel should have a @DataModelSelection with the same value which
will recieve the selected row. If there is only one DataModel/Selection then
the value attribute is not necessary for obvious reasons.
Try:
@
I am coming across a bit of a design dillema and I am curious about what others
are doing.
The issue is that within a long running conversation I might have several SFSB
components handling logical chunks of whatever is getting done. Those beans
often communicate with each other through the bi
I have a drill down menu with top level categegories which contain a variable
number of options, and I am using a conversation scoped stateful session bean
to manage the menu's state. Because opening any of the top level categories
may begin the conversation each corresponds to a toggleCategory
Hi. I'm trying to set up a project using the Embedded EJB container. All is
well, except that for the life of me I can't find a way to change the hibernate
naming strategy used by the EntityManager. Can anybody point me in the right
direction here? As far as I'm aware, it can't be set via a stan
Hi. I'm trying to set up a project using the Embedded EJB container. All is
well, except that for the life of me I can't find a way to change the hibernate
naming strategy used by the EntityManager. Can anybody point me in the right
direction here? As far as I'm aware, it can't be set via a
Take a look at the docs folder within the distribution.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3939649#3939649
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3939649
-
25 matches
Mail list logo
