[JBoss Seam] - Problem with @OneToOne relations
by madsph
In my application I have a one-to-one relation between my user entity and my address entity.
Addresses are loaded into the system from an external source, afterwards users are created manually and the correct address is then associated with the user.
My problem is that I am allowed to attach the same address to multiple users, without any problems saving the user entity. When trying to access the user again I get an error because the one-to-one relation has been violated. Is there a way to use annotations to ensure that the uniqueness is not violated so that I get a validation error when trying to persist or update my user entity, rather than having the application to fall apart because the datamodel was corrupted?
In my entity classes I have the following.
User:
@OneToOne(optional = true)
@JoinColumn(name = "address_id", nullable = true, unique = true)
public Address getAddress()
{
return address;
}
Address:
@OneToOne(mappedBy = "address")
public Xuser getXuser() {
return xuser;
}
public void setXuser(Xuser xuser) {
this.xuser = xuser;
}
Thanks
Mads
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4080802#4080802
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4080802
18 years, 7 months
[JBoss Seam] - Re: Problems using ajax validation in seam-gen
by pete.muir＠jboss.org
"vincent.latombe" wrote : And does this timeout represents the amount of time the call must wait before failing, or is it the amount of time we estimate this call should take?
IMO These two metrics aren't independent. I think the timeout needs to be set to n * timeout + m, where n & m need to be determined through experiment. In essence I think the timeout needs to be set to somewhat longer than the expected time the method will take to execute.
"vincent.latombe" wrote : I think the second option is better. A method should declare how much time it typically takes to execute, so that if a new call occurs, it can wait for this time. By extension, if we have n calls waiting and we've got a n+1-th call coming, this new call must take into consideration all timeouts defined by previous calls and sum them up, to determine the amount of time it should wait.
Ok, interesting. I'm not entirely sure I see the benefit of this as it doesn't cancel requests that are taking too long to execute. I can see two scenarios:
1) We have the same method (e.g. Damien's example of a total being calculated) for which it doesn't matter if it isn't called every being called many many times. In this case I would think something like:
Request 1 -> getTotal is processed for > concurrentRequestTimeout
Request 2 -> gets dropped
Request 3 -> gets processed
Request 4 -> gets dropped
Request 5 -> gets dropped
Request 6 -> gets processd
would be ideal - just some of the requests are processed (this is what currently happens)
2) We have a method which we must execute every time. In this case executing the method asynchronously and polling for a result from the page would be a better approach IMO.
anonymous wrote : "pete.muir(a)jboss.org" wrote : 4) Make it easier to disable the warning message on a per request basis - it really means one thing if your conversation times out as you were idle (in this case you want something like "Sorry, you were idle too long and your workspace has been lost") and something completely different if you have a concurrent request timeout ("Sorry, you are swamping the server, please slow down!")
| |
| That would be a plus, but it shouldn't be necessary if the timeout handling works correctly
|
Ok, but I don't think we're ever going to reach a magic point where this just works ootb (short of just serializing all requests into a queue of infinite length with no timeouts). And even when you're concurrent requests working nicely, you may still have some outside factor (e.g. server has heavy load from another process) which causes your concurrent calls to not be executed within the timeout and you may or may not want to notify the user of this.
"damienharvey" wrote : As you say in option 3, something like ignoreDupRequests would be handy, but sometimes you may well want the behaviour that Vincent has coded - ie. I want all of my requests to be processed eventually (within reason). Mind you I suppose that could be accomplished with a very long timeout...
Yes, exactly.
"damienharvey" wrote : What are the downsides of increasing this timeout? For instance what is the danger in setting it to a stupidly large number (perhaps equal to the conversation timeout)?
That if you have a very long running method that is called many times by ajax it may consume much of your processing power, and not timeout. This is why I think you need a sensible default, with the option of increasing it on a per method basis.
anonymous wrote : When the period times out it doesn't just abort the call, it ends the conversation . If you compare a Conversation to a Session, you wouldn't expect a Session to expire just because a page couldn't load.
AFAICS it doesn't *end* the conversation, it just kicks you out of it and into another (temporary) conversation - so the previous conversation is still there, but not active. I agree, this isn't very friendly.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4080796#4080796
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4080796
18 years, 7 months
[JBoss Seam] - Seam and RichFaces Tree component problem
by pjolep
Hi everybody,
since last Sunday I'm trying to get RichFaces Tree component working.. unfortunately inefficaciously-:)
The best I've got is a ClassCastException:)
I was following example from http://livedemo.exadel.com/richfaces-demo/richfaces/tree.jsf?s=classic
Only thing I added is:
@Name("library")
@Scope(ScopeType.SESSION)
to annotate Library class as a Seam Bean, all the others pieces of code are absolutely identical with given example. Maybe it's important to say that I've used Facelets too.
JBoss server log has only following exception:
11:39:18,421 ERROR [STDERR] Sep 4, 2007 11:39:18 AM com.sun.facelets.FaceletViewHandler handleRenderException
SEVERE: Error Rendering View[/main.xhtml]
java.lang.ClassCastException: org.richfaces.demo.tree.Library_$$_javassist_1
at org.richfaces.component.AbstractTreeDataModel.setWrappedData(AbstractTreeDataModel.java:63)
at org.richfaces.component.UITree.createDataModel(UITree.java:497)
at org.richfaces.component.UITree.createDataModel(UITree.java:520)
at org.ajax4jsf.ajax.repeat.UIDataAdaptor.getExtendedDataModel(UIDataAdaptor.java:522)
at org.ajax4jsf.ajax.repeat.UIDataAdaptor.setRowKey(UIDataAdaptor.java:302)
at org.ajax4jsf.ajax.repeat.UIDataAdaptor.setRowKey(UIDataAdaptor.java:287)
at org.richfaces.renderkit.TreeRendererBase.writeContent(TreeRendererBase.java:393)
at org.richfaces.renderkit.TreeRendererBase.encodeChildren(TreeRendererBase.java:284)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:812)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:886)
at javax.faces.render.Renderer.encodeChildren(Renderer.java:137)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:812)
at org.ajax4jsf.framework.renderer.RendererBase.renderChild(RendererBase.java:282)
at org.ajax4jsf.framework.renderer.RendererBase.renderChildren(RendererBase.java:262)
at org.richfaces.renderkit.html.PanelRenderer.doEncodeChildren(PanelRenderer.java:189)
at org.richfaces.renderkit.html.PanelRenderer.doEncodeChildren(PanelRenderer.java:184)
at org.ajax4jsf.framework.renderer.RendererBase.encodeChildren(RendererBase.java:121)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:812)
at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.encodeRecursive(HtmlBasicRenderer.java:271)
at com.sun.faces.renderkit.html_basic.GridRenderer.encodeChildren(GridRenderer.java:242)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:812)
at org.ajax4jsf.framework.renderer.RendererBase.renderChild(RendererBase.java:282)
at org.ajax4jsf.framework.renderer.RendererBase.renderChildren(RendererBase.java:262)
at org.richfaces.renderkit.html.PanelRenderer.doEncodeChildren(PanelRenderer.java:189)
at org.richfaces.renderkit.html.PanelRenderer.doEncodeChildren(PanelRenderer.java:184)
at org.ajax4jsf.framework.renderer.RendererBase.encodeChildren(RendererBase.java:121)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:812)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:886)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:892)
at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:577)
at org.ajax4jsf.framework.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:108)
at org.ajax4jsf.framework.ajax.AjaxViewHandler.renderView(AjaxViewHandler.java:233)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:106)
at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:251)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:144)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:245)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
at org.jboss.seam.debug.hot.HotDeployFilter.doFilter(HotDeployFilter.java:63)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:87)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:63)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:46)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.ajax4jsf.framework.ajax.xmlfilter.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:127)
at org.ajax4jsf.framework.ajax.xmlfilter.BaseFilter.doFilter(BaseFilter.java:277)
at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:40)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:140)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:595)
Thank you very much for any suggestion,
Igor.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4080790#4080790
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4080790
18 years, 7 months