[JBoss Messaging] - Re: JBoss 5.0.0 Beta3 Messaging Client
by cfergus
For this context, maven is like ant. Difference being that it will try to contact a maven repository on the internet and download the dependencies if they don't exist locally. I am telling maven to look locally.
My classpath is:
${messaging_home}\jboss-messaging-client.jar
${jboss5_home}\server\default\lib\jboss-remoting.jar
${jboss5_home}\client\jbossall-client.jar
${jboss5_home}\server\default\lib\log4j.jar
${jboss5_home}\lib\javassist.jar
${jboss5_home}\lib\jboss-aop-jdk50.jar
${jboss5_home}\lib\trove.jar
I'm using a build.xml from the messaging 1.4.1.Beta1 download as a template, but there are some inconsistencies with jboss5. The code below is taken from jboss-messaging-1.4.1.Beta1\examples\topic\build.xml:
${jboss.home}/server/${jboss.configuration}/lib/javassist.jar
The above file does not exist in the /server/default/lib directory
${jboss.home}/server/${jboss.configuration}/deploy/jboss-aop-jdk50.deployer/jboss-aop-jdk50.jar
The above folder (jboss-aop...) does not exist in the deploy directory due to the "deployer" folder structure of jboss5.
${jboss.home}/server/${jboss.configuration}/deploy/jboss-aop-jdk50.deployer/trove.jar
Same as previous entry.
As a result, I scavenged for these files elsewhere in jboss5. With the classpath described at top, I get the following:
java.lang.NoClassDefFoundError: org/jboss/metadata/spi/signature/Signature
I expect this is a classpath issue related to version mismatch. But if what's rolled in with jboss5 isn't sufficient, I don't know where next to look.
Any thoughts on what jars should (not) be included? I would be very happy to see code similar to the jboss-messaging examples, but verified to work with jboss5 beta3. Anybody know of such code?
Thanks for your help in this matter.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4126372#4126372
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4126372
18 years, 2 months
[Remoting] - Concurrency Issue (ClassCastException) in MicroRemoteClientI
by pms917
JBoss 4.2.1.GA (which includes jboss-remoting 2.2.1.GA)
Using EJB3 with ClassLoader isolation and Call-By-Value
We have two ears (A, B) running in the same jboss, which each make a call to a third ear (C), deployed in a second jboss, to retrieve data objects. The class definitions for the data objects are contained in a shared jar file that each ear has in its "lib" directory.
When A and B both make a call to C at the same time, one of the ears will usually receive a ClassCastException since the data objects that are returned are in the other ear's ClassLoader. Additionally, once this problem occurs, it will continue to occur until the jboss instance is restarted.
We have made a code change in MicroRemoteClientInvoker, which has almost completely eliminated the ClassCastException. In the few cases where it does still occur, it doesn't cause the jboss to get into the state where it keeps on occurring, so it seems that there is still a problem beyond the below code change.
MicroRemoteClientInvoker's invoke(InvocationRequest invocationReq) method is, in part, the following in jboss-remoting 2.2.1.GA [and seemingly unchanged in newer versions]:
| UnMarshaller unmarshaller = getUnMarshaller();
|
| // ...marshaller code removed...
|
| if (unmarshaller == null)
| {
| // creating a new classloader containing the remoting class loader (for remote classloading)
| // and the current thread's class loader. This allows to load remoting classes as well as
| // user's classes.
| ClassLoader remotingClassLoader =
| new RemotingClassLoader(getClassLoader(), Thread.currentThread().getContextClassLoader());
|
| // try by locator (in case unmarshaller class name specified)
| unmarshaller = MarshalFactory.getUnMarshaller(getLocator(), getClassLoader());
| if (unmarshaller == null)
| {
| unmarshaller = MarshalFactory.getUnMarshaller(getDataType(), getSerializationType());
| if (unmarshaller == null)
| {
| // went as far as possible to find a unmarshaller, will have to give up
| throw new InvalidMarshallingResource(
| "Can not find a valid unmarshaller for data type: " + getDataType());
| }
| setUnMarshaller(unmarshaller);
| }
| unmarshaller.setClassLoader(remotingClassLoader);
| }
|
I see two potential problems:
1) The member variable for the unmarshaller gets set by "setUnMarshaller(unmarshaller);". However, it seems that multiple ears can be using the same instance of the MicroRemoteClientInvoker, so, either there should be no member variable for the unmarshaller (i.e. it should be kept local to the invoke method) or multiple ears shouldn't be using the same MicroRemoteClientInvoker.
2) MarshalFactory doesn't seem to have any synchronization. I didn't spend much time trying to see if there is a specific problem with the lack of synchronization, but I did synchronize around the entire unmarshaller conditional on the MarshalFactory.class.
The timing that seems to have been causing the problem is:
<Call1 and Call2 are each from different ears/ClassLoaders in the same jboss instance. They are both calls to a service in a different jboss.>
t=0; Call1 gets the local unmarshaller which is null
t=1; Call1 goes into the code above, gets the unmarshaller, and sets the member variable with "setUnMarshaller(unmarshaller)"
t=2; Call2 gets the local unmarshaller which is now the same as what Call1 got
t=3; Call2 does not go into the above conditional since the unmarshaller is not null, so it doesn't call "unmarshaller.setClassLoader(remotingClassLoader);" (*!which means it is using the same classloader as Call1!*)
t=4; a ClassCastException follows
The modified code which is working for us is below. The entire conditional synchronizes on MarshalFactory.class (which may not be neccessary) and the "setUnMarshaller(unmarshaller)" is commented out (which keeps the unmarshaller member variable null, so all calls to invoke get the proper unmarshaller and set it with the proper ClassLoader).
| synchronized (MarshalFactory.class) {
| if (unmarshaller == null)
| {
| // creating a new classloader containing the remoting class loader (for remote classloading)
| // and the current thread's class loader. This allows to load remoting classes as well as
| // user's classes.
| ClassLoader remotingClassLoader =
| new RemotingClassLoader(getClassLoader(), Thread.currentThread().getContextClassLoader());
|
| // try by locator (in case unmarshaller class name specified)
| unmarshaller = MarshalFactory.getUnMarshaller(getLocator(), getClassLoader());
| if (unmarshaller == null)
| {
| unmarshaller = MarshalFactory.getUnMarshaller(getDataType(), getSerializationType());
| if (unmarshaller == null)
| {
| // went as far as possible to find a unmarshaller, will have to give up
| throw new InvalidMarshallingResource(
| "Can not find a valid unmarshaller for data type: " + getDataType());
| }
| //setUnMarshaller(unmarshaller);
| }
| unmarshaller.setClassLoader(remotingClassLoader);
| }
| }
|
I apologize for not having a test case ready, but we're still trying to get everything fully tested and stable in production now that we have the above code changes. Please let us know if any additional information is required. Any help is appreciated.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4126367#4126367
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4126367
18 years, 2 months
[JBoss Seam] - Re: SMPC and could not enlist in transaction exception
by asookazian
After doing some root-cause analysis I was able to reproduce the behavior with a simpler set of code as below. The key thing here is that by default, the transaction type in EJB3/JPA is REQUIRES. If you set getNoteLogList() and getPeers() methods' transaction types to REQUIRES_NEW, the exception is *not* reproduceable.
This indicates that when use case is executed (user navigates to JSF), there is a distributed transaction that is happening b/c BoIcomsEntityManager SMPC is based on db 1 and CoxIMEntityManager SMPC is based on db 2 and the first transaction is propagating to the 2nd one.
.xhtml:
<!DOCTYPE composition PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
| "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
| <ui:composition xmlns="http://www.w3.org/1999/xhtml"
| xmlns:s="http://jboss.com/products/seam/taglib"
| xmlns:ui="http://java.sun.com/jsf/facelets"
| xmlns:f="http://java.sun.com/jsf/core"
| xmlns:h="http://java.sun.com/jsf/html"
| xmlns:rich="http://richfaces.ajax4jsf.org/rich"
| xmlns:a4j="https://ajax4jsf.dev.java.net/ajax"
| xmlns:c="http://java.sun.com/jstl/core"
| template="layout/template.xhtml">
|
|
|
| <ui:define name="mainContent">
|
| <h:form>
|
| <!-- <h:dataTable value="#{testPeerAction.getPeers()}"/> -->
|
| <h:dataTable value="#{testUserBean.getNoteLogList()}"/>
|
| <h:dataTable value="#{testPeerAction.getPeers()}"/>
|
| </h:form>
|
| </ui:define>
| </ui:composition>
|
It doesn't matter what order the methods are listed in the above .xhtml (you will get the exception for the latter method).
TestUserBean SFSB:
import java.util.List;
|
| import javax.ejb.Remove;
| import javax.ejb.Stateful;
| import javax.persistence.EntityManager;
|
| import org.jboss.seam.annotations.Destroy;
| import org.jboss.seam.annotations.In;
| import org.jboss.seam.annotations.Logger;
| import org.jboss.seam.annotations.Name;
| import org.jboss.seam.annotations.Out;
| import org.jboss.seam.log.Log;
|
|
| @Stateful
| @Name("testUserBean")
| public class TestUserBean implements TestUserLocal {
|
| @Logger
| private Log log;
|
| @In(value="BoIcomsEntityManager")
| EntityManager emICOMS;
|
| @Out(required=false)
| private List testNoteLogList;
|
| //(a)TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
| public List getNoteLogList() {
| log.info("in getNoteLogList()");
|
| testNoteLogList = emICOMS.createQuery("SELECT san "+
| "FROM TblSecurityAuditNote san")
| .getResultList();
|
| log.info("in getNoteLogList(): testNoteLogList.size() = " + testNoteLogList.size());
|
| return testNoteLogList;
|
| }
|
| @Remove @Destroy
| public void destroy() {}
|
| }
TestPeerAction SFSB:
import java.util.List;
| import java.util.ListIterator;
| import java.util.Map;
| import java.util.TreeMap;
|
| import javax.ejb.Remove;
| import javax.ejb.Stateful;
| import javax.persistence.EntityManager;
|
| import org.jboss.seam.ScopeType;
| import org.jboss.seam.annotations.Destroy;
| import org.jboss.seam.annotations.In;
| import org.jboss.seam.annotations.Logger;
| import org.jboss.seam.annotations.Name;
| import org.jboss.seam.annotations.Scope;
| import org.jboss.seam.log.Log;
|
| import com.cox.beans.entity.User;
| import com.cox.util.SecurityAuditConstants;
| import com.cox.util.SecurityAuditProperties;
|
| @Stateful
| @Name("testPeerAction")
| //using Session scope so that the processValueChange instance variables will not be nulled out...
| @Scope(ScopeType.SESSION)
| public class TestPeerAction implements TestPeerLocal {
|
| @In(value="CoxIMEntityManager")
| EntityManager emCoxIM;
|
| @Logger
| private Log log;
| private Long employeeId;
| private List peerList;
|
| @Remove @Destroy
| public void destroy() {
|
| }
|
| //(a)TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
| public Map<String, Long> getPeers() {
|
| Boolean hardCodeEmployeeId = Boolean.parseBoolean(SecurityAuditProperties.getPropertyObject().getProperty(SecurityAuditConstants.HARD_CODE_EMPLOYEE_ID));
|
| if (hardCodeEmployeeId && employeeId == null) {
| employeeId = Long.parseLong(SecurityAuditProperties.getPropertyObject().getProperty(SecurityAuditConstants.EMPLOYEE_ID));
| }
|
| Map<String,Long> map = new TreeMap<String,Long>();
|
| peerList = emCoxIM.createQuery("SELECT user1 "+
| "FROM User user1 "+
| "WHERE user1.hierarchyPath in "+
| "(SELECT user2.hierarchyPath "+
| "FROM User user2 "+
| "WHERE user2.employeeId = :employeeId "+
| "AND user2.isActive = 1) "+
| "AND user1.isActive = 1 ")
| .setParameter("employeeId", employeeId)
| .getResultList();
|
| log.info("in getPeers(): peerList.size() = " + peerList.size());
|
| ListIterator<User> it = peerList.listIterator();
| while(it.hasNext()) {
| User user = (User)it.next();
| map.put(user.getFirstName()+ " " + user.getLastName(), user.getEmployeeId());
| }
|
| return map;
| }
|
|
| }
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4126364#4126364
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4126364
18 years, 2 months
[JBossWS] - Re: Juddi broken on 4.2.1 + 4.2.2
by petrovs
pleamon wrote on Dec 4, 2007: anonymous wrote : I've been using jboss AS 4.0.5 GA and 4.2.0 GA and have been successfully using the juddi service as my uddi registry. When I move to 4.2.1 GA or 4.2.2 GA I now get this:
| ERROR [org.jboss.jaxr.juddi.JUDDIServlet] org.jboss.ws.core.soap.TextImpl
| java.lang.ClassCastException: org.jboss.ws.core.soap.TextImpl
| at org.jboss.jaxr.juddi.JUDDIServlet.doPost(JUDDIServlet.java:120)
| at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
| at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
| ...
Yes, JBoss 4.2.2 ships with a broken jUDDI implementation. JBoss adds its own org.jboss.jaxr.juddi.JUDDIServlet (located under ${JUDDI_SAR}/juddi.war/WEB-INF/classes) on the top of Apache's juddi. This class contains a bug in doPost() method.
The cause of the problem is mentioned in JBossWS JIRA (you have to scroll all the way down to Richard Oplaka's comment from Jan 8, 2008):
http://jira.jboss.com/jira/browse/JBWS-1905
On JUDDI side this problem is documented here: https://issues.apache.org/jira/browse/JUDDI-114
Looks like JBoss developers changed JBossWS code to follow SOAP specification (see discussion here: http://www.jboss.org/?module=bb&op=viewtopic&t=100782) but forgot to fix multiple clients of their code (JUDDIServlet included). The problematic pattern is here: SOAPBody soapReqBody = soapReq.getSOAPBody();
| Element uddiReq = (Element)soapReqBody.getFirstChild();
If you can patch JUDDIServlet, replace the above fragment with something like this and it will work fine:
SOAPBody soapReqBody = soapReq.getSOAPBody();
| Iterator elements = soapReqBody.getChildElements();
| Element uddiReq = null;
| while ( elements.hasNext() ){
| Object element = elements.next();
| if ( element instanceof Element ){
| uddiReq = (Element) element;
| break;
| }
| }
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4126361#4126361
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4126361
18 years, 2 months
[JBoss Seam] - Re: Trinidad SelectManyShuttle with seam ?
by gjeudy
Yes I figured later you can use both trinidad and richfaces.
I switched to rich:listShuttle component which did not require me any extra coding, I just kept using the same backing bean. The rich:listShuttle works as expected, I had to add the seam entity converter in converter attribute though, converter="#{org.jboss.seam.ui.entityConverter}"
Below is the backing bean code in case you still want to look at it.
package a.b.c;
|
| import java.text.ParseException;
| import java.util.Calendar;
| import java.util.Date;
| import java.util.List;
|
| import javax.ejb.Remove;
| import javax.ejb.Stateful;
| import javax.persistence.EntityManager;
| import javax.persistence.PersistenceContext;
|
| import org.jboss.seam.ScopeType;
| import org.jboss.seam.annotations.Destroy;
| import org.jboss.seam.annotations.Factory;
| import org.jboss.seam.annotations.In;
| import org.jboss.seam.annotations.Logger;
| import org.jboss.seam.annotations.Name;
| import org.jboss.seam.annotations.Out;
| import org.jboss.seam.annotations.Scope;
| import org.jboss.seam.core.FacesMessages;
| import org.jboss.seam.log.Log;
|
| import a.b.c.d.RefReleasePackage;
| import a.b.c.d.e.RefReleasePackageItemImpl;
| import a.b.c.d.ReferenceDomain;
| import a.b.c.d.e.RefDomainSearchActionLocal;
| import a.b.c.d.ReleasePackageService;
| import a.b.c.d.CommonUtils;
| import a.b.c.d.RDMConstants;
|
| @Stateful
| @Name("refDomainSearch")
| @Scope(ScopeType.SESSION)
| public class RefDomainSearchActionBean implements RefDomainSearchActionLocal {
|
| @PersistenceContext(unitName = RDMConstants.RDM_PERSISTENCE_UNIT_NAME)
| private EntityManager em;
|
| @Logger
| private Log log;
|
| private String searchString;
| private int pageSize;
| private int page;
|
| private List<ReferenceDomain> refDomains;
|
| private List<ReferenceDomain> selectedRefDomains;
|
|
| @In(required = true, create=true)
| @Out(required = true, scope = ScopeType.SESSION)
| private ReleasePackageService releasePackageService;
|
| @In(required = false)
| @Out(required = false)
| private RefReleasePackage relPkg;
|
| public void find() {
| page = 0;
| queryRefDomains();
| }
|
| public void nextPage() {
| page++;
| queryRefDomains();
| }
|
| public boolean isNextPageAvailable() {
| return refDomains != null && refDomains.size() == pageSize;
| }
|
| /**
| * TODO Could write this HQL using Criteria programming model instead.
| * Then you get compile time validation of the query.
| */
| @SuppressWarnings("unchecked")
| public void queryRefDomains() {
|
| // TODO optimize the fetching takes around 25 secs today.
| refDomains = em.createQuery(
| "select rd from ReferenceDomainImpl rd " +
| "where lower(rd.domainName) like #{pattern} or lower(rd.domainDescription) like #{pattern} " +
| "or exists ( from ReferenceDomainInstanceImpl rdi " +
| "where rdi.referenceDomain.id = rd.id " +
| "and " +
| "(lower(rdi.codeValue) like #{pattern} " +
| "or lower(rdi.shortDescription) like #{pattern} " +
| "or lower(rdi.description) like #{pattern}))" +
| "order by rd.domainName")
| .setMaxResults(pageSize).setFirstResult(page * pageSize).getResultList();
| }
|
| public int getPageSize() {
| return pageSize;
| }
|
| public void setPageSize(int pageSize) {
| this.pageSize = pageSize;
| }
|
| @Factory(value = "pattern", scope = ScopeType.EVENT)
| public String getSearchPattern() {
| return searchString == null ? "%" : '%' + searchString.toLowerCase().replace('*', '%') + '%';
| }
|
| public String getSearchString() {
| return searchString;
| }
|
| public void setSearchString(String searchString) {
| this.searchString = searchString;
| }
|
|
| public List<ReferenceDomain> getRefDomains() {
| return refDomains;
| }
|
| public List<ReferenceDomain> getSelectedRefDomains() {
| return selectedRefDomains;
| }
|
| public void setSelectedRefDomains(List<ReferenceDomain> selectedRefDomains) {
| this.selectedRefDomains = selectedRefDomains;
| }
|
| /**
| * TODO remove from bean, just added for tests.
| * @return
| */
| public String updatePackageItems() {
| log.info("Inside ReleasePackageAction.updatePackageItems");
|
| Date toDate = null;
| try {
| toDate = CommonUtils.getSQLDateFromString(RDMConstants.DEFAULT_VALID_TO_DT);
| } catch (ParseException pe) {
| throw new RuntimeException(pe);
| }
|
| for (ReferenceDomain refDomain : selectedRefDomains) {
| RefReleasePackageItemImpl item = new RefReleasePackageItemImpl(refDomain, relPkg, Calendar.getInstance().getTime(), toDate);
|
| relPkg.addRefReleasePackageItem(item);
| }
| selectedRefDomains.clear();
| relPkg = releasePackageService.updateReleasePackage(relPkg);
| FacesMessages.instance().add("Release Package: #{relPkg.releasePackageNm} is successfully updated");
| return "/editPackageItems.seam";
| }
|
| @Destroy
| @Remove
| public void destroy() {
| }
| }
Thanks,
-Guillaume
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4126355#4126355
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4126355
18 years, 2 months