[JBoss Seam] - Validation issue in adapted Registration example
by chopin
Hi,
in order to build my first seam application, I decided to adapt the Registration example. In the first step I changed the name of the context root and the jar, war, and ear files to myapp. After deploying everything works fine except JSF-Hibernate validation. Validation is only done during persisting the object. In case of invalid data no data constraints will be displayed. Why Seam or JSF does not trigger validation before persisting the user object?
I changed the following files of the Registration example:
application.xml
- <web-uri>jboss-seam-registration.war</web-uri> -> <web-uri>myapp.war</web-uri>
- <context-root>/seam-registration</context-root> -> <context-root>/myapp</context-root>
- jboss-seam-registration.jar -> myapp.jar
jboss-app.xml
- seam.jboss.org:loader=seam-registration -> seam.jboss.org:loader=myapp
components.xml
- <core:init jndi-pattern="jboss-seam-registration/#{ejbName}/local"/> -> <core:init jndi-pattern="myapp/#{ejbName}/local"/>
Without these changes JSF-Hibernate validation works fine.
Any Ideas?
Thanks in advance
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4021791#4021791
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4021791
19Â years, 1Â month
[EJB 3.0] - Re: How to look up one of the many interfaces that a bean im
by ALRubinger
Right...so the proxy object is going to be created by JBoss and will implement all the interfaces you designate.
When your client does a lookup for this object, it's going to get loaded by the classloader, along with all dependencies it has.
So if the definition in the classfile is something like (I'm making up some JBoss classnames for simplicity's sake) "Proxy$1 extends JbossRemoteProxy implements MyRemoteIF", then your client must have MyRemoteIF on its classpath (even though you just want the functionality defined in the superclass Interface1 at compile time, the actual object you're working with at runtime is what's most important here).
So, I propose you do something like the following:
public abstract class MyClassBase {
|
| ... all your business logic defined by Interface1 and Interface2...
| }
@Remote
| public interface Interface1{}
@Remote
| public interface Interface2{}
@Stateless
| @RemoteBinding(JndiBinding="MyCompany/MySessionBean1/remote")
| public class MyClass1 extends MyClassBase implements Interface1{}
@Stateless
| @RemoteBinding(JndiBinding="MyCompany/MySessionBean2/remote")
| public class MyClass2 extends MyClassBase implements Interface2{}
..this way, you'll have centralized your logic into one base class, and deployed the Stateless Beans separately such that one need not have any knowledge of the other.
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4021779#4021779
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4021779
19Â years, 1Â month
[JBoss Seam] - Re: Seam Email - IllegalStateException: No Factories configu
by petemuir
"bsmithjj" wrote : Pete,
|
| Here is a report on the classloader situation just before I invoke my SLSB that sends email:
Sorry, I meant on entry to the method called by JSF (i.e. is something changing your classloader between JSF calling the action method and you calling the MailSenderBean) or is the action method being called with the UCL as the class loader? Something like:
public String dsaProvision() {
| System.out.println(this.getClass().getClassLoader());
| // rest of the method
public String userManagerApproveAccessRequest() {
| System.out.println(this.getClass().getClassLoader());
| // rest of the method
For me (at least in the mail example where I'm working on this) at the entry to a send method (called directly by JSF) the classloader is WebAppClassLoader, whether it's a Seam managed JavaBean or a SLSB.
anonymous wrote : For now, I've put the facelets (and other) jars in both the ear and the war - the emails are going out, but there are still some issues with some of the libraries.
Sure, but this strikes me as a hack that could come back and bite you later on...
anonymous wrote : I assume that the Servlet/Portlet contexts use the webapp classloader...?
On testing this I found that facesContext, externalContext and externalContext.response all were using the UCL not the WebAppClassLoader (which was unexpected).
Perhaps the UCL is getting used because myfaces is in the ear, not in a jsf-libs/the war?
Lets see which classloader is getting for calling your methods, and I'll check some more examples/projects and see whether its always the WebAppClassLoader or whether it can be the UCL. I suspect we need someone who actually knows about JBoss and it's classloaders at this point though (I *certainly* don't :( ).
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4021773#4021773
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4021773
19Â years, 1Â month
[EJB 3.0] - Re: Aliases in Queries
by micho
Thanks for your answer.
How do I have to name the property an a query in my example
@Column(name = "peter")
| public String getHugo()
| { return mHugo; }
|
peter, Hugo, mHugo
the doku says
The logical column name is defined by the Hibernate NamingStrategy implementation. The default EJB3 naming
| strategy use the physical column name as the logical column name. Note that this may be different than the
| property name (if the column name is explicit). Unless you override the NamingStrategy, you shouldn't worry
| about that.
I understood that the pysical name is the name in the database, that´s wrong?
from User as u where (u.Hugo = :name)
throws the same exception
from User where (Hugo = :name)
throws a grammar exception.
The query, thats ok
"from User where (peter = :name)") .setParameter ("name", "y")
retrieves all User Objects with paremater "peter" = "y"
How can I turn on the SQL debugging.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4021758#4021758
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4021758
19Â years, 1Â month
[EJB 3.0] - Re: Aliases in Queries
by mazzï¼ jboss.com
First, as I understand it, the @Column annotation defines the actual database column name but has no bearing on how the ORM tool identifies this column in the JPQL query language.
@Column(name = "peter")
public String getHugo()
This entity's column is "Hugo" when you identify it in your JPQL queries. "peter" is the actual name of the column in the database, and is used when the JPA implementation (Hibernate in JBoss EJB's case) builds the actual SQL that it sends to the database. So, I definitely see why u.peter fails - it should be u.hugo.
I don't know what that first query is doing... "peter = :name". Turn on Hibernate SQL debugging (show_sql=true) to look at the actual SQL its issuing - that usually tells you alot about what's happening.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4021752#4021752
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4021752
19Â years, 1Â month