[Design of JBoss ESB] - Re: Publish ESB services to web services
by jim.ma
"Kevin.Conner(a)jboss.com" wrote : "jim.ma" wrote : The mainly intention for it is we can make the Request/Response class as a subclass of esb Message.
| But why is this a requirement? What is wrong with using POJOs and populating a created message?
|
When we want to put the below class in request message body , which message body should I use ? RawBody, MapBody or ObjectBody?
org.jboss.esb.Request {
| public String foo;
| public byte[] bar;
| }
what will be added to message body ?
body.add(requestObj)
or
body.add("foo", "foovalue");
body.add("bar", "barvalue");
If later is right, use the subclass can simplify adding the filed value in message body.(move the add(key, value) code to parent class and subclass can put all field value sby calling this.setMessageBodys()).
"Kevin.Conner(a)jboss.com" wrote :
| To fit in with the current code it would be better if it was handled as follows.
| payloadProxy = new MessagePayloadProxy(config)
| and then something like the following
|
| | Message message = MessageFactory.getInstance().getMessage();
| | payloadProxy.setPayload(message, <incoming request>);
| | ... evaluate pipeline ...
| | Object response = payloadProxy.getPayload(responseMessage);
| |
|
Does payloadProxy get payLoad from the default location ? If there are multiple objects in message body , does it also work?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4148594#4148594
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4148594
18 years
[Design the new POJO MicroContainer] - Classloading and versioning
by alesj
While hacking the demo, I had 'problems' creating this 'expected' behavior:
I have foo.jar which contains FooBar service.
This FooBar service uses two other services - AlesService and ScottService.
| <bean name="FooBarService" class="org.jboss.foo.FooBarService">
| <property name="alesService"><inject/></property>
| <property name="scottService"><inject/></property>
| </bean>
|
Then I have two similar jars - acme1 and acme2.
Containing AlesService(Impl) and ScottService(Impl).
acme1 has all classes in version 1.
Where acme2 has ales package in version 2 and scott package in version 3.
Then I have the following classloading metadata in foo.jar:
| <classloading xmlns="urn:jboss:classloading:1.0" export-all="NON_EMPTY">
| <capabilities>
| <package name="org.jboss.acme.foo" version="1"/>
| </capabilities>
| <requirements>
| <package name="org.jboss.acme.ales" from="1" to="2" from-inclusive="true"/>
| <package name="org.jboss.acme.scott" from="3" to="4" from-inclusive="true"/>
| </requirements>
| </classloading>
|
Expecting that FooBar would use AlesService(Impl) from acme1 and ScottService(Impl) from acme2.
But that's not what happened when using the bootstrap configuration similar to what we use in AS5_trunk. :-(
Either I don't know how to properly configure this, or it's broken. ;-)
The problems that I've found:
When ClassLoaderPolicy returns non-null getExported delegate loader, this gets cached in BaseClassLoaderDomain::classLoadersByPackageName
| if (packageNames != null && info.getExported() != null)
| {
| for (String packageName : packageNames)
| {
| List<ClassLoaderInformation> list = classLoadersByPackageName.get(packageName);
| if (list == null)
| {
| list = new CopyOnWriteArrayList<ClassLoaderInformation>();
| classLoadersByPackageName.put(packageName, list);
| }
| list.add(info);
|
and this is then used when looking up the class in other bundles as well, but w/o knowing the right version:
BaseClassLoaderDomain::findLoaderInExports
| List<ClassLoaderInformation> list = classLoadersByPackageName.get(packageName);
| if (trace)
| log.trace(this + " trying to load " + name + " from all exports of package " + packageName + " " + list);
| if (list != null && list.isEmpty() == false)
| {
| for (ClassLoaderInformation info : list)
| {
| BaseDelegateLoader exported = info.getExported();
|
| // See whether the policies allow caching/blacklisting
| BaseClassLoaderPolicy loaderPolicy = exported.getPolicy();
| if (loaderPolicy == null || loaderPolicy.isCacheable() == false)
| canCache = false;
| if (loaderPolicy == null || loaderPolicy.isBlackListable() == false)
| canBlackList = false;
|
| if (exported.getResource(name) != null)
| {
| if (canCache)
| globalClassCache.put(name, exported);
| return exported;
| }
| }
| }
|
So, when attempting to load class with the same name from foo.jar's classlaoder, but expecting it in diff version, I still get the previous one.
OK, then I disabled this exported usage - either by returning null on getExported or null getPackageNames.
Still didn't work as expected. :-(
Now the version-unaware delegates were kicking in:
BaseClassLoaderDomain::findLoaderInImports
| for (DelegateLoader delegate : delegates)
| {
| if (trace)
| log.trace(this + " trying to load " + name + " from import " + delegate + " for " + info.getClassLoader());
| if (delegate.getResource(name) != null)
| {
| info.cacheLoader(name, delegate);
| return delegate;
| }
| }
|
where by default in CLPolicy we return exported, which is just filtered by package names - no version awareness.
So again the previous classloader was picked.
What I had to do then - and I don't see why this isn't default behavior - is the following piece of code:
| public DelegateLoader getDelegateLoader(Module module, Requirement requirement)
| {
| List<Capability> capabilities = getCapabilities();
| if (capabilities != null && capabilities.isEmpty() == false)
| {
| for(Capability capability : capabilities)
| {
| if (capability.resolves(this, requirement))
| return new FilteredDelegateLoader(getPolicy(), new CapabilityFilter(capability));
| }
| // none of the capabilities match - don't put it as delegate
| return null;
| }
| return super.getDelegateLoader(module, requirement);
| }
|
| public class CapabilityFilter implements ClassFilter
| {
| private Capability capability;
|
| public CapabilityFilter(Capability capability)
| {
| if (capability == null)
| throw new IllegalArgumentException("Null capability.");
|
| this.capability = capability;
| }
|
| public boolean matchesClassName(String className)
| {
| return matchesPackageName(ClassLoaderUtils.getClassPackageName(className));
| }
|
| public boolean matchesResourcePath(String resourcePath)
| {
| return matchesPackageName(ClassLoaderUtils.getResourcePackageName(resourcePath));
| }
|
| public boolean matchesPackageName(String packageName)
| {
| if (capability instanceof ExportPackages)
| {
| ExportPackages ep = (ExportPackages)capability;
| Set<String> packages = ep.getPackageNames(null);
| if (packages != null && packages.contains(packageName))
| return true;
| }
|
| return false;
| }
| }
|
This finally got me to my expected behavior. :-)
All this code can be found here:
- http://anonsvn.jboss.org/repos/jbossas/projects/demos/osgi/
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4148569#4148569
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4148569
18 years
[Design of JBoss ESB] - Re: Maven ESB plugin
by Andre1001
"Andre1001" wrote :
|
| - There seems to be two Maven plugins which package .esb files (jboss-maven-plugin and jboss-packaging-maven-plugin). Which one is the "official"?
|
|
Now I understand. Both are useful in some way:
jboss-maven-plugin - to start/stop/deploy applications
jboss-packaging-maven-plugin - to package applications
"Andre1001" wrote :
|
| - How do you guys automate deploy and undeploy by JMX? I've been trying with the following pom, but without sucess. Harddeploy works, but just copy the package to /deploy directory.
|
|
This is undeploying/deploying:
| <plugin>
| <groupId>org.codehaus.mojo</groupId>
| <artifactId>jboss-maven-plugin</artifactId>
| <version>1.3.1</version>
| <executions>
| <execution>
| <id>jboss-undeploy</id>
| <phase>clean</phase>
| <goals>
| <goal>undeploy</goal>
| </goals>
| </execution>
| <execution>
| <id>jboss-deploy</id>
| <phase>pre-integration-test</phase>
| <goals>
| <goal>deploy</goal>
| </goals>
| </execution>
| </executions>
| <configuration>
| <jbossHome>${user.home}/java/jboss-4.2.0.GA</jbossHome>
| <fileName>${project.build.directory}/${project.build.finalName}.esb</fileName>
| </configuration>
| </plugin>
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4148563#4148563
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4148563
18 years, 1 month
[Design of JBoss Transaction Services] - bug in BaseWrapperManagedConnection?
by nlmarco
Hello *,
I've stumbled over a problem when switching to XA transactions: I got quite often exceptions like these:
452592 ERROR (francois(a)chezfrancois.jfire.org) [Persist] Update of object "org.nightlabs.jfire.trade.Offer@1ac1a3c" using statement "UPDATE `JFIRETRADE_OFFER` SET `STATE_ORGANISATION_ID_OID`=?, `STATE_STATE_ID_OID`=?, `OPT_VERSION`=? WHERE `OFFER_ID`=? AND `OFFER_IDPREFIX`=? AND `ORGANISATION_ID`=?" failed : java.sql.SQLException: Can't set autocommit to 'true' on an XAConnection
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:946)
at com.mysql.jdbc.jdbc2.optional.ConnectionWrapper.setAutoCommit(ConnectionWrapper.java:103)
at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.checkTransaction(BaseWrapperManagedConnection.java:429)
at org.jboss.resource.adapter.jdbc.WrappedConnection.checkTransaction(WrappedConnection.java:525)
at org.jboss.resource.adapter.jdbc.WrappedConnection.prepareStatement(WrappedConnection.java:184)
at org.datanucleus.store.rdbms.SQLController.getStatementForUpdate(SQLController.java:229)
at org.datanucleus.store.rdbms.request.UpdateRequest.execute(UpdateRequest.java:229)
at org.datanucleus.store.rdbms.RDBMSPersistenceHandler.updateTable(RDBMSPersistenceHandler.java:336)
at org.datanucleus.store.rdbms.RDBMSPersistenceHandler.updateObject(RDBMSPersistenceHandler.java:312)
at org.datanucleus.state.JDOStateManagerImpl.flush(JDOStateManagerImpl.java:4610)
at org.datanucleus.ObjectManagerImpl.flushInternal(ObjectManagerImpl.java:2707)
at org.datanucleus.ObjectManagerImpl.flush(ObjectManagerImpl.java:2647)
at org.datanucleus.jdo.AbstractPersistenceManager.flush(AbstractPersistenceManager.java:1956)
at org.datanucleus.jdo.connector.ConnectionXAResource.end(ConnectionXAResource.java:78)
at org.jboss.resource.connectionmanager.xa.JcaXAResourceWrapper.end(JcaXAResourceWrapper.java:58)
at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelPrepare(XAResourceRecord.java:259)
at com.arjuna.ats.arjuna.coordinator.BasicAction.doPrepare(BasicAction.java:2871)
at com.arjuna.ats.arjuna.coordinator.BasicAction.doPrepare(BasicAction.java:2828)
at com.arjuna.ats.arjuna.coordinator.BasicAction.prepare(BasicAction.java:2382)
at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1783)
at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:90)
at com.arjuna.ats.arjuna.AtomicAction.end(AtomicAction.java:216)
at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commit(TransactionImple.java:228)
at org.jboss.ejb.plugins.TxInterceptorCMT.endTransaction(TxInterceptorCMT.java:501)
at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:361)
at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:168)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:648)
at org.jboss.ejb.Container.invoke(Container.java:960)
at sun.reflect.GeneratedMethodAccessor118.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.invocation.unified.server.UnifiedInvoker.invoke(UnifiedInvoker.java:231)
at sun.reflect.GeneratedMethodAccessor148.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:288)
at $Proxy16.invoke(Unknown Source)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:734)
at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:560)
at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:383)
at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:165)
I first thought, it was a bug in DataNucleus, but since DataNucleus works fine in other JavaEE servers, I digged deeper into it and took a look into the sources of JBoss 4.2.0. I saw that the method org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection#checkTransaction() accesses the field jdbcAutoCommit directly:
if (jdbcAutoCommit != underlyingAutoCommit)
| {
| con.setAutoCommit(jdbcAutoCommit);
| underlyingAutoCommit = jdbcAutoCommit;
| }
...even though there is a getter for it, which takes the field inManagedTransaction into account:
boolean isJdbcAutoCommit()
| {
| return inManagedTransaction? false: jdbcAutoCommit;
| }
Together with the code in the method cleanup(), which sets jdbcAutoCommit to true, this is IMHO responsible for my problem.
I downloaded JBoss 4.2.2 and tried it again - the bug still exists in the newest stable version, as well.
Am I right, is that a bug in this class? Could you please fix it?
Best regards, Marco :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4148507#4148507
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4148507
18 years, 1 month