The @Name on entity classes is already handled as a special case. Method
interception is disabled. Here is what the @Name gives you for entity classes:
1. give access to entity class via a context variable name for convenience of
capturing form data related to the entity without needing to do a
There is some confusion (at least, I perceive there to be) over the purpose of
the two source directories in the structure of projects created by seam-gen and
how they relate to XML component configuration (via components.xml).
The two source directories are:
model
action
The names are
If I have any say in the matter, I would like to see these changes (or some
variation of them) integrated. seam-gen had a lot of other areas where it
needed attention, which was addressed for the 2.0 release. Once we are beyond
2.0, I think we can continue to make seam-gen produce better and
fixed
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4092410#4092410
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4092410
___
jboss-user mailing list
jboss-user@lists.jboss.org
There was a change in seam-gen starting with Seam 2.0.0.CR2 regarding how the
generated classes are organized when generate-entities is executed.
Old way:
src/model/com/domain/projectname/model/EntityName.java
src/action/com/domain/projectname/model/EntityNameHome.java
Ah, sorry!
At the same time, thank you for making me aware of this problem. I never
thought about what it would do to existing projects. I was totally focused on
the new project scenario.
I have reverted part of the change. Here is how it will work:
1. When running ./seam setup for the first
Given that we agree on the general principle, and I have had my chance to voice
my rant, let's dig further into the underlying issue.
Is putting the JBoss Embedded runtime in Tomcat's classpath an unreasonable
request? (this is a real question, not hypothetical)
In Seam 1.2.1, it was possible
I am going to go out on a limb here and say that Tomcat is what got us in the
hot water that is burning our skin today. The whole viewpoint that application
servers are big and heavyweight is antiquated. What people don't realize is
that Tomcat is more proprietary and difficult to use than just
I wouldn't jump to it being a bug just yet. Most likely there is a restriction
in the Hibernate validator that perhaps wasn't being applied before. I will try
to take a look at it, but I am pretty jammed for time right now.
However, what I can promise is that I am going to see if IBM will let
@Stateful
| @Name(Seam in Action)
| public class SeamBook extends Book {
|
| @Out(required = false)
| private String author;
|
| @Out(required = false)
| private String publisher;
|
| public String showMeTheAuthor() {
| author = Dan Allen;
| return
ellenzhao wrote : I read Michael Yuan + Thomas Heute's Seam book, it's pretty
good but information in that book needs to be updated since Seam is under
drastic change. Most of the time, I find Seam reference manual pretty
sufficient. I open the reference in a single html and global search is
Very good...but what I really want is to attach A to B so that we can get this
data out of here. I am assuming that is the long term goal. We don't need just
another forum software. We need this data in another forum software.
View the original post :
I was doing some playing around with defining components in seam, using the
components.xml to provide overrides, when I came across behavior I did not
expect. What I am trying to do is use the components.xml file to effectively
uninstall a component, or to put it in other terms, prevent the
What I wouldn't give for pointing Hibernate search at the database that holds
this forum data. I have no doubt the information about Seam in this forums is
extensive. But I cannot find shit with this search. And it is a shame, because
it means people ask the same questions repeatedly. I happen
I would like to get a sense if anyone would be interested in the @In annotation
supporting multiple scopes. Right now, your only option is either one explicit
scope, or a hierarchical search of all the scopes. I can imagine that there are
times when you want to look in a handful of scopes, but
Oh, and one other thing. By making this a multi-value attribute, the user can
override the order in which the scopes are searched. They are searched in the
order specified!
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4064370#4064370
Reply to the post :
I now have a patch if anyone is interested.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4064377#4064377
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4064377
___
jboss-user
The semantics of how it searches a given scope would remain the same as it is
today. Meaning, if you put scope = ScopeType.CONVERSATION, then it will just do
Component.getInstance(value, ScopeType.CONVERSATION). This patch just let's
you work multiple scopes, but the lookup is still the same.
I believe it has to do with the fact that a DataModel is either attached to the
scope of the owning component or it is placed in PAGE context when used on a
stateless component. The restriction has to do with how Seam maintains the row
selection. It isn't meant to be tossed out into the great
I have requested that there be a way in the SeamTest to get the request-scope
attributes (and also set one). http://jira.jboss.org/jira/browse/JBSEAM-1657
Ah, and I can justify why now (car rides are always useful for these things).
In the Expressions class (and perhaps JSF in general), you
You know, as I contemplate this, I realize that whose court it belongs is a
toss up. The LengthValidator returns false if the property is not a String. On
the other hand, a char can only be length 1 or null. So it is a pointless
validation in this case. I think the right step is for seam-gen to
Gavin, I appreciate your point that what seam-gen should not be deemed
production ready. However, you should at least be able to perform an insert.
With this annotation on the char property, the validator fails. Now, arguably
the validator should not fail because a char is in fact a length of
Okay, I have submitted an issue and suggested change for the Hibernate
Validator. After all, java.lang.Character does satisfy @Length(max = 1). What
is valid is valid. Stupid, but valid. I rest my case.
http://opensource.atlassian.com/projects/hibernate/browse/HV-33
View the original post :
dan.j.allen wrote : Gavin, I appreciate your point that what seam-gen should
not be deemed production ready.
Sorry, that should read what seam-gen creates should not necessarily be sent
straight to production.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp
One of the big benefits of Seam over plain JSF is that if you want, you can
eliminate all logic XML and have just a sprinkling of configuration XML. In
fact, you will see this point made by Michael Yuan in the JBoss Seam book.
However, one of the coolest features of Seam, page actions, is not
Please see (and vote for) issue http://jira.jboss.com/jira/browse/JBSEAM-1619
which explains how to get a seam-gen app working on Glassfish. I think there
is some problem with Glassfish V1 using Hibernate as the JPA provider, so you
have to use Glassfish V2.
View the original post :
Actually, this concern is legitimate. I can confirm that both of you are
correct. If you run the seam examples, they work perfectly. If you use your
own setup with jsf-facelets-1.1.11.jar, then you get an error when trying to
use the bare ui:insert /. Apparently, seam has a modified (or
[EMAIL PROTECTED] wrote : .xhtml is just the default: you can use anything
you like
Well, yes. My point was more should we rather than can we. I'll I am
saying is that if we do use xhtml, and we are going to ask all the vendors to
help us with tag completion and validation based on this
There is a chance that this question is going to be perceived as heretical, but
I feel that I either need to speak now or hold my peace.
Is XHTML really a good choice for the file extension and doctype for Facelets
templates?
Consider my argument. When we use xhtml as a file extension and
Thanks for the reply. So my understanding is that the embedded EJB container
will not look for or process the -ds.xml files in any way. Those files are
strictly for use by the JBoss application server.
Please correct me if I am wrong, otherwise I don't expect a follow-up.
View the original
I am trying to understand the difference between jboss-beans.xml and the JCA
datasources configured in the *-ds.xml file (where * can be anything) when used
with the microcontainer. (In this case, jboss-beans.xml is defining a
datasource.) If I take out jboss-beans.xml it appears that Seam
If the Spring listener is configured above the Seam listener in web.xml, then
Seam complains loudly that a component is being accessed outside the context of
a web application when adding the SpringComponent.
java.lang.IllegalStateException: Attempted to invoke a Seam component outside
the
If the ExceptionFilter is configured (using web:exception-filter in
components.xml) and a UserTransaction is not available in JNDI, then the filter
bails when it calls ExceptionFilter#rollbackTransactionIfNecessary() in the
finally block. Those folks who are using Seam without the transaction
Sorry, it's not in the finally block, but it is in that filter.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4029410#4029410
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4029410
I realize that it may seem silly to use Seam in a non-JTA environment because
of all the wonderful features it offers when the app runs under that umbrella.
However, I am experimenting with Seam in a completely stateless environment,
where all transaction and session related stuff are hidden
True, a poor choice of words. I guess since it is just a log message, it
doesn't affect the executing of the application in anyway. On the other hand,
it does sound an alarm which isn't necessarily a problem with the application.
I cannot really offer a recommendation for a change unless
This may be a silly question, but bare with me. Is it possible to have an
extended persistence context without using an EntityManager (rather a native
Hibernate Session)? By that, I mean that you can retrieve an object, render
the view, and on postback, the following will still be true,
Hmm, what you said makes perfect sense, though I feel that I did not do a good
job of stating my question. As a proud owner of JPwH I can positively say that
I understand that Hibernate is a provider of the JPA standard (and a very good
one!)
Let me try to be a bit more clear. I want to put
I realize that FacesContext is not available on a Seam remoting call because
the request does not go through the JSF lifecycle. However, since the
FacesContext is null, the Spring beans EL integration also goes out the window.
Instead, Seam uses an internal UnifiedELValueBinding that is
Oh yeah! I finally figured out a way to do away with the need for the
delegating variable resolver all together, which in my mind really feels like
the right solution to this problem! I am now using seam:component to expose
my Spring bean as a native Seam component instance rather than
Okay, I'm the ass. Sorry for wasting your time. Chapter 8.3 describes this
very clearly with the Seam-managed SessionFactory and FlushMode feature of
Hibernate. I also didn't read close enough (or slow enough) to realize that
the session-factory-jndi-name attribute is actually the name of the
Are there any thoughts on a tag, or some adapter built into Seam, that helps to
iterate over a java.util.Set? I figured this one would have gotten far enough
under your skin, Gavin, that you would scratch at it until JSF bled ;)
While we are on the topic, are we allowed to bash the JSF spec
Ah, makes perfect sense, now that you point it out. My mind was being to
narrow, thinking that the scope was entirely within the Seam source. Thanks
for the quick response.
To avoid having to answer this question time and again, you might just want to
add that hint to the usage statement in
When is JBoss going to use Seam to rewrite these forums? I swear, I could
really use the workspace feature when trying to navigate between threads,
search and posting! PHPBB drives me batty!
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4007523#4007523
When I use the seam-gen generate-entities target to reverse engineer my
database, it does a great job ;) However, the resulting entity classes don't
use the Entity.java template from the seam-gen source code. However, if I use
the seam-gen new-entity target, it does. Is there any reason?
The
I understand my problem. In this particular case, my entity being outjected is
a Seam component but not marked with a scope. Therefore, it is taking on the
default EVENT scope. If I don't specify the scope on the @Out annotation, my
data is placed in the event context, and thus the data does
Gavin et al,
I am still a bit confused about which scope to use for the @Out annotation.
Let me provide a brief example and hopeful it demonstrates my misunderstanding.
I have the following stub backing bean:
@Name( userManager )
| @Scope(CONVERSATION)
| public class UserManagerBean {
|
I suppose I should also mention that in this case, the user is also annotated
with @DataModelSelection.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3988562#3988562
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3988562
48 matches
Mail list logo
