[JBoss Seam] - Integrating Seam with EJB container
by maek1975
Hi
I have two modules, a web-module and an ejb-module. In the web-module I have some @Stateless annotated Action classes. In the ejb-module I have a number of stateless session beans etc. I also have a j2ee-module that used for deployment.
The problem is that JBOSS finds and registers/starts my ejb's that resides under the ejb-module, but not those actions that resides under web-module. How do I tell JBoss to look for @Stateless under the web-module as well.
In the ejb-module (under meta-inf), I have ejb-jar.xml, persistendce.xml etc.
My ejb jar looks like the following:
<ejb-jar xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd"
version="3.0">
<interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
<assembly-descriptor>
<interceptor-binding>
<ejb-name>*</ejb-name>
<interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
</interceptor-binding>
</assembly-descriptor>
</ejb-jar>
In the web-module (under web-inf), I have components.xml, faces-config.xml, web.xml etc.
components.xml:
true
#{ejbName}/local
<!-- half second wait for conversation lock on concurrent requests -->
500
<!-- 120 second conversation timeout -->
120000
cid
clr
<!--
/main.xhtml
-->
faces-config.xml:
<faces-config>
<!-- Phase listener needed for all Seam applications -->
<phase-listener>org.jboss.seam.jsf.SeamPhaseListener</phase-listener>
</faces-config>
web.xml:
<web-app version="2.5"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
<!-- Seam -->
<listener-class>org.jboss.seam.servlet.SeamListener</listener-class>
<!-- MyFaces -->
<listener-class>org.apache.myfaces.webapp.StartupServletContextListener</listener-class>
<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>client</param-value>
</context-param>
<context-param>
<param-name>facelets.DEVELOPMENT</param-name>
<param-value>true</param-value>
</context-param>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
<!-- Faces Servlet Mapping -->
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>*.seam</url-pattern>
</servlet-mapping>
<!-- JSP -->
<jsp-config>
<jsp-property-group>
<url-pattern>*.jsp</url-pattern>
<is-xml>true</is-xml>
</jsp-property-group>
</jsp-config>
</web-app>
In j2ee-application-module, under meta-inf, I have the application.xml which contains:
<display-name>Ratten</display-name>
RattenBusiness.jar
<web-uri>RattenWeb.war</web-uri>
<context-root>/</context-root>
I also have an empty jboss-app.xml.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3984142#3984142
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3984142
19Â years, 8Â months
[JBoss Seam] - Re: Seam and tomahawk-sandbox graphicimagedynamic
by frehan
"frehan" wrote : "petemuir" wrote : http://jroller.com/page/pmuir?entry=dynamicimagecomponent_for_jsf
| |
| | And, as pointed out, A4J has a component as well. I would steer clear of tomahawk where possible and especially sandbox.
|
|
| Thanks for your reply!
| I have tried the A4J component, but I always get an Application context not available when using it with seam.
|
| I have also tried your component, but I am not using faclets so I did a taglib to work with jsp/jsf (seam) but I get exceptions about missing metohds, and more.. I will try to post the stacktrace..
|
| /F
Stacktrace:
2006-11-08 14:47:35,406 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/camitzadmin].[jsp]] Servlet.service() for servlet jsp threw exception
org.apache.jasper.JasperException: Unable to compile class for JSP
An error occurred at line: 99 in the jsp file: /app/imageUpload.jsp
Generated servlet error:
The method setPageContext(PageContext) is undefined for the type DynamicImageComponent
An error occurred at line: 99 in the jsp file: /app/imageUpload.jsp
Generated servlet error:
The method setParent(UIComponent) in the type UIComponentBase is not applicable for the arguments (Tag)
An error occurred at line: 99 in the jsp file: /app/imageUpload.jsp
Generated servlet error:
The method doStartTag() is undefined for the type DynamicImageComponent
Generated servlet error:
The method doEndTag() is undefined for the type DynamicImageComponent
Generated servlet error:
The method reuse(Tag) in the type TagHandlerPool is not applicable for the arguments (DynamicImageComponent)
Generated servlet error:
The method reuse(Tag) in the type TagHandlerPool is not applicable for the arguments (DynamicImageComponent)
at org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:84)
at org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:328)
at org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:414)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:297)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:276)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:264)
at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:563)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:303)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:463)
at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:398)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301)
at org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:416)
at org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:234)
at org.jboss.seam.jsf.SeamViewHandler.renderView(SeamViewHandler.java:59)
at org.jboss.seam.jsf.SeamViewHandler.renderView(SeamViewHandler.java:59)
at org.ajax4jsf.framework.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:101)
at org.ajax4jsf.framework.ajax.AjaxViewHandler.renderView(AjaxViewHandler.java:197)
at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:384)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:138)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:144)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.jboss.seam.servlet.SeamExceptionFilter.doFilter(SeamExceptionFilter.java:45)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.jboss.seam.servlet.SeamRedirectFilter.doFilter(SeamRedirectFilter.java:30)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
at java.lang.Thread.run(Thread.java:595)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3984141#3984141
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3984141
19Â years, 8Â months
[JBoss Seam] - Re: EntityManger-per-user-session...
by bkyrlach
"iradix" wrote : I think you're biggest problem is you haven't gotten your head wrapped around the conversational model yet. It definitely takes time and I'd recommend that the first thing you do is at least skim through the Seam reference documentation in it's entirety.
I've read the documentation in it's entirety at least 20-30 times now.
"iradix" wrote : That being said, I'll try to explain as best I can.
|
| anonymous wrote : I don't understand this part at all. I know that if I stick the edited activity back into the users collection of activites and have the correct cascade type, that when I save the updated user, it will save the updated activity as well.
|
| Where you're going wrong here is you don't need to stick the activity back into the list if it's already there.
Hibernate documentation says specifically that I'm responsable for managing both sides of a bi-directional relationship. I've never experienced the behavior you're talking about, and even though I'm injecting my EntityManager through the @PersistenceContext, I'm pretty sure it's still conversationally scoped becuase I specififed it in the following way...
| @PersistenceContext(type=PersistenceContextType.EXTENDED, unitName="testDatabase")
| EntityManager em;
|
"iradix" wrote : If you are using a conversationally scoped EM (which is what my suggestions are based on) then there will only be one version of each activity per conversation, whether that activity was retrieved through user.getActivities or through SELECT..... That's how an EntityManager works and it's important to understand that.
This is true only if that conversationally scoped EM has the User bean as an attached instance. Otherwise, it will most definitely not recognize that the detached entity comming from the users activities collection is the same as the attached entity being injected from the conversation scope.
"iradix" wrote : So rather than the view that you provided, what I'm talking about is the edit view where you will have values bound like:
|
|
| | Name: <h:inputText value="#{selectedActivity.name}"/>
| |
|
| When the update data model phase happens the name would be updated on the one and only version of the selected Activity, which is managed by your conversation scoped EM, and when the transaction is commited it will be updated. After that anytime you access user.getActivities() you will see the updated activity and it will be reflected in the database. Does that make more sense?
That does not happen in my code, and my EM is conversation scoped because it is an extended persistence context managed by a conversationally scoped SFSB. (do you still call them session beans if they're not session scoped... lol)
"iradix" wrote : anonymous wrote : I guess that's what I'm saying. I'm not sure I'd call it spanning more than one conversation. In reality, user is a session scoped bean representing the currently logged in user.
|
| Well, since a session may contain many conversations, then your User object at least has the capability of spanning more than one and that should be factored in. Again, this seems to be an issue with your understanding of how conversations, and more specifically conversation scoped EMs work. You cannot use the @PersistenceContext annotation to specify a conversation scoped EM.
Okay, I need to read more carefully. You're saying that even though the owner of this EM is conversationally scoped, and the PersistenceContextType is extended, that it's not a conversationally scoped EM? I thought the whole point of setting it to extended was that Seam garuntee's me that the same EM will be available across multiple method calls to the same object (in this case, ActivityActions). In fact, both the DVDStore and the Booking app don't use an EM set up through components.xml and injected using the @In annotation.
"iradix" wrote : It needs to be injected using the @In annotation, and if you've configured that correctly (see the docs on how) Seam will magically make sure that the same EM gets injected into every bean within the same conversation.
Okay, I'm completly re-working my demo app to use what you've specified. Somehow, I have a feeling we're still not communicating the whole picture to eachother, but I'm willing to learn. :)
"iradix" wrote : As far as persistence units are concerned, I've never had the need to deal with more than one on a project, but I'd imagine if I did I could create 2 Seam managed EMs, one for each persistence context and then your example would become:
|
|
|
| | @In(create="true")
| | EntityManager manager1;
| |
| | @In(create="true")
| | EntityManager manager2;
| |
|
| Where manager1 and manager2 are both properly configured, conversation scoped EMs.
I didn't at first realize you were talking about configuring EM's through the use of components.xml. In that case, it's perfectly trivial to inject multiple EntityManagers tied to different persistence contexts.
"iradix" wrote :
| Make more sense?
|
No, but I'm working on some demo code to see if I can begin to understand. Also, even though I'm grateful for your help, this has also seemed to stray a long way from what I was originally asking, which is... why is it so bad to just have a Session scoped EM. However, I'd be much more interested in getting it to work the "correct way" than to find out why the wrong way is wrong.
/sigh
P.s. You say that I never have to merge, but in reality, em.find(User.class, userId) is doing the same thing (not the same operation, but I mean what it's doing is querying the database and reattaching my detached user). The whole point of my question is, why do I have to always worry about my session scoped objects becomming detached because the scope of my persistence context < scope of my seam component. I don't care if it's em.find() or em.merge(), both seem kind of silly to have to do each time. It seems to me that it should be entity managers job to keep track of this for me, rather than me having to worry in every business method on every action to ensure that all of my objects are attached to the current entity manager.
Especially when you think of a user with a large collection of activities. Then you can imagine that just editing one activity requires a database trip that could bring back 3-4k records or more. I mean, that's not going to be the case here, of course, but I'm just wondering why it needs to be this way.
Don't get me wrong, I'm reading what you've posted and I'm even reworking my example to see if I can make some sense of what you're saying. I'm always trying to learn more.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3984138#3984138
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3984138
19Â years, 8Â months
[Installation, Configuration & Deployment] - Map type attribute for an XMBean
by bossy
I want to include an attribute to an XMBean that is of type Map. I need to store in it key/value pairs. I have a class called ConfigXMBean with methods public Map getMyMapProperty() and public void setMyMapProperty(Map prop). In my config-xmbean.xml file I have the following description:
<attribute access="read-write" getMethod="getMyMapProperty" setMethod="setMyMapProperty">
| <description>My Map Property </description>
| <name>setMyMapProperty</name>
| <type>java.util.Map</type>
| </attribute>
I also have the following persistence descriptor for this mbean:
<descriptors>
| <persistence persistPolicy="OnUpdate"
| persistPeriod="10"
| persistLocation="${jboss.server.data.dir}"
| persistName="JNDIMap.ser"/>
| <currencyTimeLimit value="10"/>
| <state-action-on-update value="keep-running"/>
| <persistence-manager value="org.jboss.mx.persistence.ObjectStreamPersistenceManager" />
| </descriptors>
The problem is when I change the value of this property by adding an item, it doesn't persist the property - that is when I restart JBoss I loose the item I added before.
My questions are:
- is it possible to have a Map attribute for an MBean,
- if Yes - is it possible to persist it the way I'm trying to do it or am I missing something?
Thanks.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3984137#3984137
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3984137
19Â years, 8Â months
[Installation, Configuration & Deployment] - Re: Is there a order in which jboss loads it's deployed appl
by jaikiran
anonymous wrote : Is there a order in which jboss loads it's deployed applications
Yes.
anonymous wrote : and if so can this order be influenced?
Yes again. There's a jboss-service.xml file in %JBOSS_HOME%/server/default/conf (replace "default", in this path, with whatever server configuration you are using) which specifies a URLComparator which is used by the DeploymentScanner for ordering the deployments.
Extract from that file:
anonymous wrote :
| The URLComparator can be used to specify a deployment ordering
| for deployments found in a scanned directory. The class specified
| must be an implementation of java.util.Comparator, it must be able
| to compare two URL objects, and it must have a no-arg constructor.
| Two deployment comparators are shipped with JBoss:
| - org.jboss.deployment.DeploymentSorter
| Sorts by file extension, as follows:
| "sar", "service.xml", "rar", "jar", "war", "wsr", "ear", "zip",
| "*"
| - org.jboss.deployment.scanner.PrefixDeploymentSorter
| If the name portion of the url begins with 1 or more digits, those
| digits are converted to an int (ignoring leading zeroes), and
| files are deployed in that order. Files that do not start with
| any digits will be deployed first, and they will be sorted by
| extension as above with DeploymentSorter.
By default it is set to org.jboss.deployment.DeploymentSorter. You can provide your own implementation if these 2 classes shipped by JBoss do not meet your requirements
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3984135#3984135
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3984135
19Â years, 8Â months