[jBPM Development] - AttachmentTest failure
by Huisheng Xu
Huisheng Xu [http://community.jboss.org/people/rebody] created the discussion
"AttachmentTest failure"
To view the discussion, visit: http://community.jboss.org/message/538887#538887
--------------------------------------------------------------
Hi Alejandro,
I had updated current trunk. The org.jbpm.test.activity.mail.AttachmentTest failed. The test case reported as below:
### EXCEPTION ###########################################
13:20:12,799 INF | [DefaultCommandService] exception while executing command org.jbpm.pvm.internal.cmd.StartProcessInstanceInLatestCmd@1613b53
org.jbpm.api.JbpmException: could not send email: javax.mail.internet.MimeMessage@1aa0a15
at org.jbpm.pvm.internal.email.impl.MailSessionImpl.send(MailSessionImpl.java:60)
at org.jbpm.jpdl.internal.activity.MailActivity.perform(MailActivity.java:46)
at org.jbpm.jpdl.internal.activity.JpdlAutomaticActivity.execute(JpdlAutomaticActivity.java:15)
at org.jbpm.pvm.internal.model.op.ExecuteActivity.perform(ExecuteActivity.java:60)
at org.jbpm.pvm.internal.model.ExecutionImpl.performAtomicOperationSync(ExecutionImpl.java:657)
at org.jbpm.pvm.internal.model.ExecutionImpl.performAtomicOperation(ExecutionImpl.java:617)
at org.jbpm.pvm.internal.model.ExecutionImpl.start(ExecutionImpl.java:218)
at org.jbpm.pvm.internal.cmd.StartProcessInstanceInLatestCmd.execute(StartProcessInstanceInLatestCmd.java:65)
at org.jbpm.pvm.internal.cmd.StartProcessInstanceInLatestCmd.execute(StartProcessInstanceInLatestCmd.java:38)
at org.jbpm.pvm.internal.svc.DefaultCommandService.execute(DefaultCommandService.java:42)
at org.jbpm.pvm.internal.tx.StandardTransactionInterceptor.execute(StandardTransactionInterceptor.java:54)
at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.executeInNewEnvironment(EnvironmentInterceptor.java:53)
at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.execute(EnvironmentInterceptor.java:40)
at org.jbpm.pvm.internal.svc.RetryInterceptor.execute(RetryInterceptor.java:55)
at org.jbpm.pvm.internal.svc.SkipInterceptor.execute(SkipInterceptor.java:43)
at org.jbpm.pvm.internal.svc.ExecutionServiceImpl.startProcessInstanceByKey(ExecutionServiceImpl.java:70)
at org.jbpm.test.activity.mail.AttachmentTest.testVariableAttachment(AttachmentTest.java:84)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:164)
at org.jbpm.test.BaseJbpmTestCase.runTest(BaseJbpmTestCase.java:87)
at junit.framework.TestCase.runBare(TestCase.java:130)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:120)
at junit.framework.TestSuite.runTest(TestSuite.java:230)
at junit.framework.TestSuite.run(TestSuite.java:225)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
Caused by: javax.mail.MessagingException: IOException while sending message;
nested exception is:
javax.activation.UnsupportedDataTypeException: no object DCH for MIME type image/gif
at com.sun.mail.smtp.SMTPTransport.sendMessage(SMTPTransport.java:676)
at org.jbpm.pvm.internal.email.impl.MailSessionImpl.send(MailSessionImpl.java:51)
... 43 more
Caused by: javax.activation.UnsupportedDataTypeException: no object DCH for MIME type image/gif
at javax.activation.ObjectDataContentHandler.writeTo(DataHandler.java:896)
at javax.activation.DataHandler.writeTo(DataHandler.java:317)
at javax.mail.internet.MimeBodyPart.writeTo(MimeBodyPart.java:1403)
at javax.mail.internet.MimeBodyPart.writeTo(MimeBodyPart.java:874)
at javax.mail.internet.MimeMultipart.writeTo(MimeMultipart.java:444)
at com.sun.mail.handlers.multipart_mixed.writeTo(multipart_mixed.java:102)
at javax.activation.ObjectDataContentHandler.writeTo(DataHandler.java:894)
at javax.activation.DataHandler.writeTo(DataHandler.java:317)
at javax.mail.internet.MimeBodyPart.writeTo(MimeBodyPart.java:1403)
at javax.mail.internet.MimeMessage.writeTo(MimeMessage.java:1745)
at com.sun.mail.smtp.SMTPTransport.sendMessage(SMTPTransport.java:636)
... 44 more
The activation cannot find DataContentHandler(DCH) for Mime-Type image/gif. jBPM 4 are using activition-1.1.jar to provider javamail attach. When I change it to activation-1.1.1.jar, the attachmenttest could pass successfully.
I digg deeper and find out that activition-1.1.1.jar decide the dataContent's type, when the class of data content is byte[], it will write it to the content directly.
I saw there is a mailcap file in the mail-1.4.1.jar at META/mailcap. Here is the content.
#
# @(#)mailcap 1.8 05/04/20
#
# Default mailcap file for the JavaMail System.
#
# JavaMail content-handlers:
#
text/plain;; x-java-content-handler=com.sun.mail.handlers.text_plain
text/html;; x-java-content-handler=com.sun.mail.handlers.text_html
text/xml;; x-java-content-handler=com.sun.mail.handlers.text_xml
multipart/*;; x-java-content-handler=com.sun.mail.handlers.multipart_mixed; x-java-fallback-entry=true
message/rfc822;; x-java-content-handler=com.sun.mail.handlers.message_rfc822
#
# can't support image types because java.awt.Toolkit doesn't work on servers
#
#image/gif;; x-java-content-handler=com.sun.mail.handlers.image_gif
#image/jpeg;; x-java-content-handler=com.sun.mail.handlers.image_jpeg
As we can see, the image/gif and image/jpeg parts have been commented, so they won't be effect.
At the last, how could we solve this exception? Could we update activation-1.1.jar to activation-1.1.1.jar? Or we should do some other things to prevent the exception?
Any reply will be appreciate. Thank you.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/538887#538887]
Start a new discussion in jBPM Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years, 1 month
[JBoss Messaging Development] - Time taken for messages to failover in a cluster
by Atul Singh
Atul Singh [http://community.jboss.org/people/iamatul] created the discussion
"Time taken for messages to failover in a cluster"
To view the discussion, visit: http://community.jboss.org/message/538852#538852
--------------------------------------------------------------
Hi
I am new to JMS and have to deal with a very advanced issue because of some reasons. Would be thankful for any pointers as the available documentation on JBoss JMS clustering is very vague/complex/diifcult to understand.
I am running JBoss 5.1 GA. I will have a cluster of two nodes. I want to have a (one) distributed JMS queue. There will be MDBs running on both the queues reading from the single distributed queue. The documentation suggests that on each node the distributed queue will be partial. With this background I have the following questions
1. Does this means that a message inserted into the queue will be visible to the MDB on on node only *?*
2. If one of the node fails (say hardware crash) then will the messages on the failed node will become available on the partial queue on the working node ? If yes then how long will it take ?
Thanks a lot,
Any tips pointers are greatly appreciated.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/538852#538852]
Start a new discussion in JBoss Messaging Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years, 1 month
Re: [jboss-dev-forums] [JCA Development] - JcaXAResourceRecovery
by Jesper Pedersen
Jesper Pedersen [http://community.jboss.org/people/jesper.pedersen] replied to the discussion
"JcaXAResourceRecovery"
To view the discussion, visit: http://community.jboss.org/message/538845#538845
--------------------------------------------------------------
[14:07] <jpederse> asaldhan: so can I pass a null string as securityDomainName to createSecurityContext ?
[14:07] <asaldhan> jpederse: pass any dummy
[14:08] <jpederse> asaldhan: k, but I''m not seeing any setPrincipal() / setCredential() on SubjectInfo
[14:09] <asaldhan> jpederse: did u set it on SecurityContextAssociation?
[14:10] <jpederse> asaldhan: how ? It only takes the SecurityContext
[14:11] <jpederse> asaldhan: also; do I need the SecurityContextAssociation part at all ? I just need the Subject as a local variable
[14:11] <jpederse> asaldhan: this is not run in a context of something
[14:12] <jpederse> asaldhan: Its "ManagedConnection mc = mcf.createManagedConnection(subject, null)"
[14:14] <asaldhan> jpederse: but the creation of subject has to go through authentication. So at that time, the subjectfactory will look at the SCA for the latest SC and picks username/cred from there. After you have the subject, u then pass it to MCF
[14:14] <asaldhan> jpederse: so u need to do the SCA/SC/princ/cred
[14:15] <jpederse> asaldhan: k, then I just need to find the place where I input my username and password strings
[14:16] <jpederse> asaldhan: as the securityDomainName is null
[14:16] <asaldhan> jpederse: I have told u the sequence, I think u will have to figure out where to do the necessary things. The SDN should not be null. U r probably doing it wrong someplace
[14:17] <jpederse> asaldhan: look at my latest post - there isn't a security-domain configured in the -ds.xml
[14:17] <asaldhan> jpederse: there are two pieces: security to check whether u can create a subject. Once u have a subject, u pass it to the MCF. The MCF deals with the EIS.
[14:17] <jpederse> asaldhan: that is the common case for AS
[14:18] <asaldhan> jpederse: in that case, it probably just defaults to "other"
[14:18] <jpederse> asaldhan: yes, and I need the create the Subject - based on the information from the two use-cases
[14:18] <jpederse> asaldhan: I'm not talking about application-policy's
[14:18] <asaldhan> jpederse: if u have the AS setup, try debugging and seeing what the SD is for the case when -ds.xml does not have SD.
[14:18] <asaldhan> jpederse: the security domain translates to app policy
[14:19] <asaldhan> jpederse: SD = app policy defs
[14:19] <jpederse> asaldhan: yeah, I know - so it is probably the "other" case
[14:19] <asaldhan> jpederse: best is to debug the classic ds.xml usecases.[14:20] <jpederse> asaldhan: yeah, that would be the next thing
[14:21] <jpederse> asaldhan: and what about the principal / credential case ? I need to plug them in where ?
[14:22] <asaldhan> jpederse: dont know how the current ds setup does it.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/538845#538845]
Start a new discussion in JCA Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years, 1 month
Re: [jboss-dev-forums] [jBPM Development] - Mail template for custom MailProducer
by Alejandro Guizar
Alejandro Guizar [http://community.jboss.org/people/alex.guizar%40jboss.com] replied to the discussion
"Mail template for custom MailProducer"
To view the discussion, visit: http://community.jboss.org/message/538838#538838
--------------------------------------------------------------
> By the way, most user only create create a custom MailProducer to bypass the requirement of the default MailProducerImpl that mail recepients need to exist in the Indentity tables.
>
> ~~~~~~
> List<User> users = identitySession.findUsersById(userIds);
> ~~~~~
>
> Don't quite understand that, especially if I want the workflow to trigger an email to an external customer.
The code you indicate is guarded by a condition:
String userList = fromTemplate.getUsers();
if (userList != null) {
String[] userIds = tokenizeActors(userList, execution);
List<User> users = identitySession.findUsersById(userIds);
email.addFrom(resolveAddresses(users, addressResolver));
}
If you don't need users and groups from the identity tables, your template should only specify the *addresses* attribute to enumerate recipients. Avoiding the *users* and *groups* attributes also prevents access to the identity session. However, since you have looked at the source code you probably knew this already - am I missing something?
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/538838#538838]
Start a new discussion in jBPM Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years, 1 month
Re: [jboss-dev-forums] [JBoss Microcontainer Development] - JBoss Reflect Performance Javassist vs Introspection
by Kabir Khan
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion
"JBoss Reflect Performance Javassist vs Introspection"
To view the discussion, visit: http://community.jboss.org/message/538809#538809
--------------------------------------------------------------
> Kabir Khan wrote:
>
> I have modified the bootstrap project as shown in the attached patch to set JavassistTypeInfoFactoryImpl's classPoolFactory to be RepositoryClassPoolFactory. A quick check in the debugger shows this to kick in.
>
> I am now getting some exceptions on startup that I need to look into.
I modified JavassistTypeInfoFactoryImpl to give some extra output. When a class can not be found it ends up in this method:
private TypeInfo delegateToIntrospectionImplementation(ClassLoader cl, String name) throws ClassNotFoundException
{
System.out.println("======> " + name + " " + cl);
//Extra code just for debugging
ClassPool pool = poolFactory.getPoolForLoader(cl);
try
{
CtClass ct = pool.get(name);
}
catch(Exception alreadyHandled)
{
System.out.println("---> Not found in " + pool);
}
Class<?> clazz = cl.loadClass(name);
System.out.println("---> Loaded real class from " + clazz.getClassLoader());
try
{
CtClass ct = pool.get(name);
}
catch(Exception alreadyHandled)
{
System.out.println("---> Not found again in " + pool);
}
pool = poolFactory.getPoolForLoader(clazz.getClassLoader());
try
{
CtClass ct = pool.get(name);
System.out.println("---> Found in actual pool " + pool);
}
catch(Exception alreadyHandled)
{
System.out.println("---> Not found in actual pool " + pool);
}
//Extra code - END
IntrospectionTypeInfoFactory factory = new IntrospectionTypeInfoFactory();
return factory.getTypeInfo(name, cl);
}
Here is the output, this is during installing the beans from conf/bootstrap
17:16:06,954 INFO [JMXKernel] Legacy JMX core initialized
17:16:07,009 INFO [STDOUT] ======> org.jboss.aop.deployers.AspectManagerJMXRegistrar BaseClassLoader@47ac1adf{jmx-classloader:0.0.0$MODULE}
17:16:08,927 INFO [STDOUT] ---> Not found in [org.jboss.classpool.plugins.jbosscl.JBossClDelegatingClassPool@2002512083 [class path: BaseClassLoader@47ac1adf{jmx-classloader:0.0.0$MODULE}:] - dcl:BaseClassLoader@47ac1adf{jmx-classloader:0.0.0$MODULE} domain: [org.jboss.classpool.plugins.jbosscl.JBossClClassPoolDomain@101ebf5c name:DefaultDomain]]
17:16:08,930 INFO [STDOUT] ---> Loaded real class from BaseClassLoader@8a85268{aop-classloader:0.0.0$MODULE}
17:16:08,931 INFO [STDOUT] ---> Not found again in [org.jboss.classpool.plugins.jbosscl.JBossClDelegatingClassPool@2002512083 [class path: BaseClassLoader@47ac1adf{jmx-classloader:0.0.0$MODULE}:] - dcl:BaseClassLoader@47ac1adf{jmx-classloader:0.0.0$MODULE} domain: [org.jboss.classpool.plugins.jbosscl.JBossClClassPoolDomain@101ebf5c name:DefaultDomain]]
17:16:08,931 INFO [STDOUT] ---> Found in actual pool org.jboss.classpool.spi.AbstractClassPool@697579067 [class path: BaseClassLoader@8a85268{aop-classloader:0.0.0$MODULE}:] - dcl:BaseClassLoader@8a85268{aop-classloader:0.0.0$MODULE}
17:16:09,563 INFO [STDOUT] ======> org.jboss.aop.asintegration.jboss5.AOPAnnotationMetaDataParserDeployer BaseClassLoader@280bca{deployers-classloader:0.0.0$MODULE}
17:16:10,283 INFO [STDOUT] ---> Not found in [org.jboss.classpool.plugins.jbosscl.JBossClDelegatingClassPool@404225673 [class path: BaseClassLoader@280bca{deployers-classloader:0.0.0$MODULE}:] - dcl:BaseClassLoader@280bca{deployers-classloader:0.0.0$MODULE} domain: [org.jboss.classpool.plugins.jbosscl.JBossClClassPoolDomain@101ebf5c name:DefaultDomain]]
17:16:10,287 INFO [STDOUT] ---> Loaded real class from BaseClassLoader@8a85268{aop-classloader:0.0.0$MODULE}
17:16:10,289 INFO [STDOUT] ---> Not found again in [org.jboss.classpool.plugins.jbosscl.JBossClDelegatingClassPool@404225673 [class path: BaseClassLoader@280bca{deployers-classloader:0.0.0$MODULE}:] - dcl:BaseClassLoader@280bca{deployers-classloader:0.0.0$MODULE} domain: [org.jboss.classpool.plugins.jbosscl.JBossClClassPoolDomain@101ebf5c name:DefaultDomain]]
17:16:10,289 INFO [STDOUT] ---> Found in actual pool org.jboss.classpool.spi.AbstractClassPool@697579067 [class path: BaseClassLoader@8a85268{aop-classloader:0.0.0$MODULE}:] - dcl:BaseClassLoader@8a85268{aop-classloader:0.0.0$MODULE}
As you can see AspectManagerJMXRegistrar is loaded from the classloader used to install jmx.xml, and AOPAnnotationMetaDataParserDeployer from deployers.xml's classloader. If I use the pools for those loaders directly I get a NotFoundException. If I try to load the class from the loader directly it works, and in both cases the classes returned are loaded from the classloader used for aop.xml (AspectManagerJMXRegistrar comes from jboss-aop-asintegration-core.jar, and AOPAnnotationMetaDataParserDeployer comes from jboss-aop-deployers.jar).
Next I get an error that brings everything to a halt (with some extra debug information compared to the error message that is in svn):
17:16:13,036 ERROR [AbstractKernelController] Error installing to PreInstall: name=AOPClassLoaderDeployer state=Real: java.lang.NoClassDefFoundError: Unable to find class org.jboss.aop.asintegration.jboss5.AOPClassLoaderDeployer from org.jboss.osgi.integration.jbossas.AOPClassLoaderDeployerJBAS7909 in pool [org.jboss.classpool.plugins.jbosscl.JBossClDelegatingClassPool@404225673 [class path: BaseClassLoader@280bca{deployers-classloader:0.0.0$MODULE}:] - dcl:BaseClassLoader@280bca{deployers-classloader:0.0.0$MODULE} domain: [org.jboss.classpool.plugins.jbosscl.JBossClClassPoolDomain@101ebf5c name:DefaultDomain]]
at org.jboss.reflect.plugins.javassist.JavassistTypeInfoFactoryImpl.raiseClassNotFound(JavassistTypeInfoFactoryImpl.java:104) [jboss-reflect.jar:2.2.0-SNAPSHOT]
at org.jboss.reflect.plugins.javassist.JavassistTypeInfo.getSuperclass(JavassistTypeInfo.java:235) [jboss-reflect.jar:2.2.0-SNAPSHOT]
at org.jboss.beans.info.plugins.AbstractBeanInfoFactory.getMethods(AbstractBeanInfoFactory.java:262) [jboss-reflect.jar:2.2.0-SNAPSHOT]
at org.jboss.beans.info.plugins.AbstractBeanInfoFactory.getBeanInfo(AbstractBeanInfoFactory.java:152) [jboss-reflect.jar:2.2.0-SNAPSHOT]
at org.jboss.config.plugins.AbstractConfiguration.getBeanInfo(AbstractConfiguration.java:87) [jboss-reflect.jar:2.2.0-SNAPSHOT]
at org.jboss.kernel.plugins.config.AbstractKernelConfig.getBeanInfo(AbstractKernelConfig.java:80) [jboss-kernel.jar:2.2.0.Alpha9]
at org.jboss.kernel.plugins.config.AbstractKernelConfigurator.getBeanInfo(AbstractKernelConfigurator.java:78) [jboss-kernel.jar:2.2.0.Alpha9]
at org.jboss.kernel.plugins.config.AbstractKernelConfigurator.getBeanInfo(AbstractKernelConfigurator.java:97) [jboss-kernel.jar:2.2.0.Alpha9]
at org.jboss.kernel.plugins.dependency.PreInstallAction.installActionInternal(PreInstallAction.java:88) [jboss-kernel.jar:2.2.0.Alpha9]
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54) [jboss-kernel.jar:2.2.0.Alpha9]
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42) [jboss-kernel.jar:2.2.0.Alpha9]
at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) [jboss-dependency.jar:2.2.0.Alpha9]
at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) [jboss-dependency.jar:2.2.0.Alpha9]
at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) [jboss-dependency.jar:2.2.0.Alpha9]
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:377) [jboss-dependency.jar:2.2.0.Alpha9]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2042) [jboss-dependency.jar:2.2.0.Alpha9]
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1081) [jboss-dependency.jar:2.2.0.Alpha9]
at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1320) [jboss-dependency.jar:2.2.0.Alpha9]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1244) [jboss-dependency.jar:2.2.0.Alpha9]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1137) [jboss-dependency.jar:2.2.0.Alpha9]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:892) [jboss-dependency.jar:2.2.0.Alpha9]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:639) [jboss-dependency.jar:2.2.0.Alpha9]
at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBean(AbstractKernelDeployer.java:319) [jboss-kernel.jar:2.2.0.Alpha9]
at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDeployer.java:297) [jboss-kernel.jar:2.2.0.Alpha9]
at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deploy(AbstractKernelDeployer.java:130) [jboss-kernel.jar:2.2.0.Alpha9]
at org.jboss.kernel.plugins.deployment.BasicKernelDeployer.deploy(BasicKernelDeployer.java:76) [jboss-kernel.jar:2.2.0.Alpha9]
at org.jboss.bootstrap.impl.mc.deployer.TempBasicXMLDeployer.deploy(TempBasicXMLDeployer.java:92) [jboss-bootstrap-impl-mc.jar:2.1.0-SNAPSHOT]
at org.jboss.bootstrap.impl.mc.deployer.TempBasicXMLDeployer.deploy(TempBasicXMLDeployer.java:193) [jboss-bootstrap-impl-mc.jar:2.1.0-SNAPSHOT]
at org.jboss.bootstrap.impl.mc.server.AbstractMCServerBase.bootstrapMcAndDescriptors(AbstractMCServerBase.java:318) [jboss-bootstrap-impl-mc.jar:2.1.0-SNAPSHOT]
at org.jboss.bootstrap.impl.mc.server.AbstractMCServerBase.doStart(AbstractMCServerBase.java:265) [jboss-bootstrap-impl-mc.jar:2.1.0-SNAPSHOT]
at org.jboss.bootstrap.impl.as.server.AbstractJBossASServerBase.doStart(AbstractJBossASServerBase.java:381) [jboss-bootstrap-impl-as.jar:2.1.0-SNAPSHOT]
at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:413) [jboss-bootstrap-impl-base.jar:2.1.0-SNAPSHOT]
at java.lang.Thread.run(Thread.java:637) [:1.6.0_17]
This is caused by a call to CtClass.getSuperClass() for org.jboss.osgi.integration.jbossas.AOPClassLoaderDeployerJBAS7909 which has the deployers.xml classpool, but the superclass lives in the aop.xml classpool.
So something is going wrong during bootstrap, and it looks like the classpools can't see classes from the other pools within the domain, while the classloaders can see classes from the other loaders in the domain. What is weird is that from bootstrap.xml it looks like the RegisterModuleCallback (from aop.xml) should be deployed before jmx.xml and deployers.xml, but could there be anything else missing at this stage?
<bootstrap xmlns="urn:jboss:bootstrap:1.0">
<url>bootstrap/vfs.xml</url>
<url>bootstrap/classloader.xml</url>
<url>bootstrap/stdio.xml</url>
<url>bootstrap/kernel.xml</url>
<url>bootstrap/aop.xml</url>
<url>bootstrap/jmx.xml</url>
<url>bootstrap/deployers.xml</url>
<url>bootstrap/profile.xml</url>
</bootstrap>
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/538809#538809]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years, 1 month
[JBoss ESB Development] - Annotation based Action classes
by Tom Fennelly
Tom Fennelly [http://community.jboss.org/people/tfennelly] created the discussion
"Annotation based Action classes"
To view the discussion, visit: http://community.jboss.org/message/538803#538803
--------------------------------------------------------------
With subversion lockdown at the moment, I decided to have a look at how we could improve the Action class API... make it a bit easier to use.
So at the moment, to implement an Action you need to implement the ActionLifecycle interface (or one of it's derived interfaces/classes). Configuration is done through the universally hated ConfigTree, which must be supplied via constructor. In all... implementing an Action is quite ugly (imo).
After a few hours playing, I have the following working. You can implement an action that looks like the following:
public class Action1234 {
@ConfigProperty
private File pickupFile;
@ProcessMethod
public void processMethod(Message m) {
FileWriter writer = new FileWriter(pickupFile);
// etc....
}
}
No need to implement interfaces... no ConfigTree... configuration is reflectively injected via the @ConfigProperty annotation on the bean fields/setters.
The esb config for this looks just like any other action:
<action name="action" class="com.acme.Action1234">
<property name="pickupFile" value="./pickupFile.xml" />
</action>
It also supports @ProcessMethod implementations that take non ESB Message parameters e.g.
public class Action1234 {
@ProcessMethod
public OrderAcknowledgment processOrder(Order purchaseOrder) {
// Do your thing with the order...
return new OrderAcknowledgment(....);
}
}
In the above case, the Order instance needs to be set as the ESB Message payload i.e. the action configured before this action needs to create the Order (via transformation etc) and set it as the payload on the Message instance it returns. This Order will then get extracted from the ESB Message and passed into the processOrder method. Likewise with the OrderAcknowledgement return val... set on the ESB Message instance forwarded to the next action in the pipeline. All this is done using the standard MessagePayloadProxy get/set mechanism. Would be easy enough (I think) to add marshal/unmarshal support here, for marshaling e.g. an XML message payload into java objects that can then be used as args to the @ProcessMethod - opposite on the way out.
Lifecycle... initialize and destroy... add public no-arg methods and annotate them with @Initialize or @Destory.
The @ConfigProperty annotation for injecting the config params was lifeted from Smooks (called @ConfigParam in Smooks). It handles extraction of the config parameter (form the ConfigTree) and injection into the bean. Also handles all the decoding e.g. in the case above, decoding the string value into a java.io.File instance. Handles REQUIRED and OPTIONAL config params... "choices" etc. This removes a lot of noise from the code!!
All of this was done within the confines of the current Actions, ConfigTree etc APIs. The bean action is wrapped in a normal ConfigTree/ActionLifecycle action implementation (I currently call it BeanContainerAction). It did require a relatively small addition to the ActionProcessingPipeline to hook in this new type of action, wrapping it in the BeanContainerAction.
The @ConfigParam an lifecycle annotations could also be used on the listeners etc... thereby hiding our beloved ConfigTree from most users :)
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/538803#538803]
Start a new discussion in JBoss ESB Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years, 1 month