[JBoss Seam] - seam and maven
by ericomtx
I'm trying to deploy a sample app from the current site :
http://software.softeu.cz/seam/usage.html
When I run the command mvn jboss:deploy -e
I get the error :
[INFO] No server specified for authentication - using defaults
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Mojo error occurred: Server returned HTTP response code: 505 for URL: http://localhost:8080/jmx-console/
HtmlAdaptor?action=invokeOpByName&name=jboss.system:service%3DMainDeployer&methodName=deploy&argType=java.net.U
RL&arg0=file:C:\java\helloApp\target/helloApp.war
If I try to copy and paste the target war file to %JBOSS_HOME%\server\default\deploy I get the following error in JBoss log :
ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/helloApp]] Exception sending context initialized event to listener instance of class org.jboss.web.jsf.integration.config.JBossJSFConfigureListener
java.lang.ClassCastException: org.apache.xerces.jaxp.SAXParserFactoryImpl
I'm trying to run this sample to use Seam with Maven
Is this a good sample ? Is there any other sample or archetype to use seam with maven ?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4108729#4108729
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4108729
18 years, 5 months
[JBoss Seam] - EntityHome throws 'EntityManager is closed' when app marked
by superflav
I'm working on an application that makes extensive use of Seam's EntityHome base class to manage entity bean instances. This works great in a non-clustered environment, but is causing "java.lang.IllegalStateException: EntityManager is closed" exceptions to be thrown when the web application is clustered by marking it distributable in web.xml.
Stepping through the EntityHome code, I've found that if an EntityHome's entityManager is closed but not nulled at the end of a request, subsequent requests to the same EntityHome instance will result in "java.lang.IllegalStateException: EntityManager is closed".
We've circumvented this issue by implementing a "@PrePassivate" method on our EntityHomes that takes care of nulling out the entityManager prior to passivation. This does the job in terms of getting rid of the "EntityManager is closed" problem, but another problem is introduced in its place. When managing an entity bean instance in one request, and attempting to update/persist it in a subsequent request results in "org.hibernate.PersistentObjectException: detached entity passed to persist".
We've circumvented this 2nd issue by merging the EntityHome's associated entity bean instance into the current request's entityManager instance and re-setting the merged entity bean instance as the EntityHome's associated entity bean instance.
Once we've gotten around both of these issues, we're able to deploy our app in a clustered environment and have it failover without any problems. However, given that the Seam-managed persistence context is touted as being able to anonymous wrote : "...supports transparent failover of extended persisence contexts, without the need to replicate any persistence context state between nodes..." (Chapter 8 in the Seam Manual), I'm left scratching my head, wondering why we had to jump through all of these hoops to get our app to work in a clustered environment.
So, just to prove that there was nothing specific to our app that was causing the problem, I used seam-gen to create a new project and generate entities from a very simple (one table, 2 columns) existing database schema. The app built, deployed and otherwise worked just as expected without me having to change a thing. Then I went in and added distributable to web.xml, and the same problems that I described above began surfacing.
I was able to get the seam-genned app to work with by implementing a @PrePassivate method and an "attachInstanceToEntityManager()" method that is called by overridden isManaged(), persist(), remove() and update() on my one and only EntityHome. Code from this class is pasted in below, but does anyone have any deeper insight on Seam-managed persistence contexts used in EntityHomes in an app that is distributable? I'm hoping that either a) we're taking the wrong approach when clustering our app, or b) this is something that will be cleaned up in an upcoming version of Seam. It's easy enough to get around in simple cases, but could get pretty tedious when working with entity bean instances that are made up of complex object graphs.
package com.mydomain.widget;
|
| import javax.ejb.PrePassivate;
|
| import org.jboss.seam.annotations.Name;
| import org.jboss.seam.annotations.Transactional;
| import org.jboss.seam.framework.EntityHome;
|
| @Name("widgetHome")
| public class WidgetHome extends EntityHome<Widget> {
|
| public void setWidgetWidgetId(Integer id) {
| setId(id);
| }
|
| public Integer getWidgetWidgetId() {
| return (Integer) getId();
| }
|
| @Override
| protected Widget createInstance() {
| Widget widget = new Widget();
| return widget;
| }
|
| public void wire() {
| }
|
| public boolean isWired() {
| return true;
| }
|
| public Widget getDefinedInstance() {
| return isIdDefined() ? getInstance() : null;
| }
|
| ////
| // code below here was not auto-genned by seam-gen, but everything above was
| ////
|
| /**
| * Need to null out entityManagers prior to passivation so that they'll get
| * reinitialized upon subsequent reqests. Failing to do this in a clustered
| * environment will result in "EntityManager is closed" error messages.
| */
| @PrePassivate
| public void prePassivate() {
| setEntityManager(null);
| }
|
| /**
| * if super.isManaged() returns false, but getInstance() has an Id, then
| * instance needs to be re-attached to the entityManager in order to
| * prevent "detached entity passed to persist" exceptions.
| */
| private void attachInstanceToEntityManager() {
| if (!super.isManaged() && getInstance().getWidgetId() != null) {
| setInstance(getEntityManager().merge(getInstance()));
| }
| }
|
| @Override
| @Transactional
| public boolean isManaged() {
| attachInstanceToEntityManager();
| return super.isManaged();
| }
|
| @Override
| @Transactional
| public String persist() {
| attachInstanceToEntityManager();
| return super.persist();
| }
|
| @Override
| @Transactional
| public String remove() {
| attachInstanceToEntityManager();
| return super.remove();
| }
|
| @Override
| @Transactional
| public String update() {
| attachInstanceToEntityManager();
| return super.update();
| }
| }
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4108719#4108719
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4108719
18 years, 5 months
[JBossWS] - Re: Soap service returning complex objects(Such as hashmaps)
by mwkohout
at least in my instance I get the same result as before.
btw, I'm running the version javaws that comes default with jboss 4.2.1GA. I don't suppose this annotation change fixed your issue because you were on the new version of jbossws?
I suppose the next step is to see if it's a parsing error or just a bad response by capturing the envelope in my log.
huh. this is the call that would return a hashmap with one key/value pair in it. To my untrained eyes there isn't anything in the response.
| 17:12:18,874 DEBUG [SOAPContentElement] -----------------------------------
| 17:12:18,874 DEBUG [SOAPContentElement] Transitioning from OBJECT_VALID to XML_VALID
| 17:12:18,874 DEBUG [ObjectContent] getXMLFragment from Object [xmlType={http://webService.core.ictr.umn.edu/}hashMap,javaType=class java.util.HashMap]
| 17:12:18,874 DEBUG [JAXBSerializer] serialize: [xmlName=return,xmlType={http://webService.core.ictr.umn.edu/}hashMap]
| 17:12:18,874 DEBUG [JAXBSerializer] serialized: <return/>
| 17:12:18,874 DEBUG [ObjectContent] xmlFragment: [source=<return/>]
| 17:12:18,874 DEBUG [SOAPContentElement] -----------------------------------
| 17:12:18,875 TRACE [MessageTrace] Outgoing Response Message
| <env:Envelope xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'>
| <env:Header>
| <seam:conversationId xmlns:seam='http://www.jboss.org/seam/webservice'>6</seam:conversationId>
| </env:Header>
| <env:Body>
| <n1:getStudiesResponse xmlns:n1='http://webService.core.ictr.umn.edu/'>
| <return/>
| </n1:getStudiesResponse>
| </env:Body>
| </env:Envelope>
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4108715#4108715
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4108715
18 years, 5 months
[JBoss jBPM] - jbpm-jpdl-3.2.GA - jbpm-console - ERROR - workflow.jbpm_id_u
by jeckles933
im trying to get the jbpm-console to work, search for tasks -> select view for an item, get this error (see below)
jbpm_id_user does not exist, and i cant find it in the create db scripts. looks like this table was in 3.1. Im new to jpbm, so i could be completely missing something. and help would be great!
Caused by: com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: Table 'workflow.jbpm_id_user' doesn't exist
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:936)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2941)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1623)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1715)
at com.mysql.jdbc.Connection.execSQL(Connection.java:3249)
at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1268)
at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:1403)
at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeQuery(WrappedPreparedStatement.java
:236)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4108713#4108713
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4108713
18 years, 5 months
[JBoss jBPM] - Re: Using JBPM for document workflow in a Java/Flex CMS soft
by jimrigsbee
I would need to know more details of your use case to answer best. But I'll give you some general ideas and let you go from there.
If the state of the document is part of your workflow, store it in a process variable as part of the context of the current state of your workflow. In this way you only have the state in one place.
If you need to access the repo via processes other than jBPM workflows, and need to know the current status of that document, then store the state there. When you get the current workflow step, it should be a quick matter to get the node from the repository service in JBPM and make the appropriate call (don't remember off hand) to get the attribute in the content repository that corresponds to the status of the document.
Please post what you decide and why so that others can benefit from your experience.
Regards,
Jim Rigsbee
Red Hat Inc.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4108711#4108711
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4108711
18 years, 5 months