Re: [jboss-dev-forums] [JBoss ESB Development] - Camel integration input requested
by David Ward
David Ward [http://community.jboss.org/people/dward] replied to the discussion
"Camel integration input requested"
To view the discussion, visit: http://community.jboss.org/message/548554#548554
--------------------------------------------------------------
> o Is the jboss.esb lib directory the only recommended place to put component libraries? It's certainly possible to put it in one of the higher level AS lib directories. Is it possible to bundle them with the ESB application? Do we recommend against these other methods?
Right now it is recommended to put component libraries in server/default/deploy/jbossesb.sar/lib/ for AS4 and server/default/deployers/esb.deployer/lib/ for AS5, because that is all that has been tested with so far. ;) I might go back and give the other options a try if I have time, but right now there are pleny of other 4.9 issues that need to be addressed first.
> o Component jars in the jboss.esb lib directory will be loaded during server startup. Correct me if I'm wrong, but adding additional jars here will require the ESB sar to be redeployed or (more likely) the server restarted. Might want to point this out.
Are you saying add it to the wiki page? That's fine. I will note that I don't think that this is a problem. If you are adding component jars, then you are most likely adding non-trivial (aka: important) functionality - functionality that in the real world should go through an organization's standard test + release cycles. "Hot deploy" is a nice feature for developers, but in my experience production systems get "bounced" when adding this level of functionality.
> o Having a single class loading space for additional components means that there can only be one version of a component in the ESB runtime at any given time. Probably worth mentioning this point.
True, but this would not be the first place in the ESB (or AS, for that matter) where there is "a" version of a library.
> o There is a distinct possibility that one of the many camel components will include jars that we already have in the ESB or the AS already. If the versions of these dependencies are different than things can go boom. Isolating the class space with class loader repository might be one way to address this. Another way to address it is to say "YMMV". ;-)
Jumping through the dependency hoops is something that we all are used to. I'm not saying we shouldn't try to make this easier, or try things like class loader isolation and such - we definitely should. But again, we need to wrap up the other 4.9 issues first.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/548554#548554]
Start a new discussion in JBoss ESB Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 3 months
[EJB 3.0 Development] - Unexpected behaviour when binding to java:comp and @Startup beans
by Marius Bogoevici
Marius Bogoevici [http://community.jboss.org/people/marius.bogoevici] created the discussion
"Unexpected behaviour when binding to java:comp and @Startup beans"
To view the discussion, visit: http://community.jboss.org/message/548547#548547
--------------------------------------------------------------
So, for Weld-int we bind a BeanManager to java:comp/BeanManager. In order to make it accessible to EJBs, the binding procedure works like this:
1) Obtain the JavaEEComponent which corresponds to the EJBs DU
2) From the JavaEEComponent, obtain the Context (which represents java:comp for said component)
3) Bind the BeanManager
As a bit of background, one of the interceptors that are applied to CDI-enabled EJBs is injected with a @Resource("java:comp/BeanManager")
This works fine, as long as the EJB is not a @Startup bean. For the latter, the lookup that is performed during EJBContainer.startup() seems to miss the JavaEEComponent (debugging ComponentObjectFactory shows that CurrentComponent.get() returns null and thus JavaEEComponent is ignored - so that the BeanManager that is bound to JavaEEComponent's context is not found).
So, I'm looking forward to some clarifications concerning this - mainly to discuss what's the best way to move forward:
a) open a JIRA, fix the issue, or
b) use the SwitchBoard
Thanks,
Marius
Message was edited by: Marius Bogoevici, typo in title
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/548547#548547]
Start a new discussion in EJB 3.0 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 3 months
Re: [jboss-dev-forums] [JBoss ESB Development] - Annotation based Action classes
by Keith Babo
Keith Babo [http://community.jboss.org/people/kcbabo] replied to the discussion
"Annotation based Action classes"
To view the discussion, visit: http://community.jboss.org/message/548544#548544
--------------------------------------------------------------
I think everyone agrees that this is a great thing to do. A few pieces of feedback:
o It would be great to get a basic wiki page/article built around this functionality. You have most of the content already between this thread and the implementation in your workspace. It's just easier to get a sense of the scope of the feature when it's all in one place. We will need this anyway to document the feature for users.
o Looks like this is the current list of supported annotations. Did I miss any?
* @OnExceptionMethod
* @OnSuccessMethod
* @ProcessMethod
* @ConfigProperty
* @Destroy
* @Initialize
* @BodyParam
* @PropertyParam
o Recommend dropping "Method" from the above annotion names.
o We could take this one step further and add an @Action annotation at the class level. This would eliminate the need to extend AbstractActionPipelineProcessor or implement the Lifecycle and PipelineProcessor interfaces; you have already defined annotations for all the methods on these interfaces. All we need to do is add a basic delegate implementation that would wrap the annotated action and dispatch to annotated methods as appropriate.
o I did not see @BodyParam and @PropertyParam in the fisheye changeset you published. In fact, they are not in your workspace either AFAICT. Do I have to pay extra for those? ;-) I checked out the processing in BeanContainerAction and it looks like you support both a "name" property in the annotation as well as search based on the annotated parameter's type. For examples, I would use the former syntax as it's much clearer where the body and property are coming from.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/548544#548544]
Start a new discussion in JBoss ESB Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 3 months
Re: [jboss-dev-forums] [JBoss ESB Development] - WSDL11Reader.java has problems w/ included WSDL
by Dave Siracusa
Dave Siracusa [http://community.jboss.org/people/davesiracusa] replied to the discussion
"WSDL11Reader.java has problems w/ included WSDL"
To view the discussion, visit: http://community.jboss.org/message/548307#548307
--------------------------------------------------------------
2010-06-15 06:37:16,399 40465821 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (HDScanner:) Error installing to Start: name=jboss.esb.vfszip:/C:/ybd/ESB-Tools/jboss-soa-p.5.0.0/jboss-as/server/default/deploy/bpesbservices-1.0.0-SNAPSHOT.esb/ state=Create
org.jboss.soa.esb.listeners.lifecycle.ManagedLifecycleException: Error configuring action processing pipeline
at org.jboss.soa.esb.listeners.message.MessageAwareListener.doInitialise(MessageAwareListener.java:191)
at org.jboss.soa.esb.listeners.lifecycle.AbstractManagedLifecycle.initialise(AbstractManagedLifecycle.java:133)
at org.jboss.soa.esb.listeners.lifecycle.ManagedLifecycleController.initialiseInstances(ManagedLifecycleController.java:109)
at org.jboss.soa.esb.listeners.lifecycle.ManagedLifecycleController.start(ManagedLifecycleController.java:66)
at org.jboss.soa.esb.listeners.deployers.mc.EsbDeployment.start(EsbDeployment.java:126)
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:597)
at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:243)
at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:111)
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:72)
at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:221)
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1633)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.system.ServiceController.doChange(ServiceController.java:688)
at org.jboss.system.ServiceController.start(ServiceController.java:460)
at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:163)
at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:99)
at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1179)
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1633)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
at org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:371)
at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:256)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: org.jboss.soa.esb.ConfigurationException: Unexpected exception while instantiating action instance
at org.jboss.soa.esb.listeners.message.ActionProcessorMethodInfo.getActionClassInstance(ActionProcessorMethodInfo.java:359)
at org.jboss.soa.esb.listeners.message.ActionProcessorMethodInfo.getActionClassInstance(ActionProcessorMethodInfo.java:340)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.<init>(ActionProcessingPipeline.java:275)
at org.jboss.soa.esb.listeners.message.MessageAwareListener.doInitialise(MessageAwareListener.java:185)
... 61 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at org.jboss.soa.esb.listeners.message.ActionProcessorMethodInfo.getActionClassInstance(ActionProcessorMethodInfo.java:355)
... 64 more
Caused by: java.lang.NullPointerException
at org.jboss.ws.metadata.wsdl.xmlschema.JBossXSEntityResolver.getXMLInputSource(JBossXSEntityResolver.java:170)
at org.jboss.ws.metadata.wsdl.xmlschema.JBossXSEntityResolver.resolveEntity(JBossXSEntityResolver.java:136)
at org.apache.xerces.impl.XMLEntityManager.resolveEntity(Unknown Source)
at org.apache.xerces.impl.xs.XMLSchemaLoader.resolveDocument(Unknown Source)
at org.apache.xerces.impl.xs.traversers.XSDHandler.resolveSchema(Unknown Source)
at org.apache.xerces.impl.xs.traversers.XSDHandler.constructTrees(Unknown Source)
at org.apache.xerces.impl.xs.traversers.XSDHandler.parseSchema(Unknown Source)
at org.apache.xerces.impl.xs.XMLSchemaLoader.loadSchema(Unknown Source)
at org.apache.xerces.impl.xs.XMLSchemaLoader.loadGrammar(Unknown Source)
at org.jboss.ws.tools.JavaToXSD.parseSchema(JavaToXSD.java:181)
at org.jboss.ws.tools.wsdl.WSDL11Reader.processTypes(WSDL11Reader.java:415)
at org.jboss.ws.tools.wsdl.WSDL11Reader.processTypes(WSDL11Reader.java:430)
at org.jboss.ws.tools.wsdl.WSDL11Reader.processDefinition(WSDL11Reader.java:180)
at org.jboss.ws.tools.wsdl.WSDLDefinitionsFactory.parse(WSDLDefinitionsFactory.java:129)
at org.jboss.soa.esb.actions.soap.proxy.SOAPProxy.<init>(SOAPProxy.java:174)
... 69 more
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/548307#548307]
Start a new discussion in JBoss ESB Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 3 months
[JBoss ESB Development] - WSDL11Reader.java has problems w/ included WSDL
by Dave Siracusa
Dave Siracusa [http://community.jboss.org/people/davesiracusa] created the discussion
"WSDL11Reader.java has problems w/ included WSDL"
To view the discussion, visit: http://community.jboss.org/message/548301#548301
--------------------------------------------------------------
I'm running into an issue w/ an external web service exposed via ESB/SOAPProxy. The returned root WSDL, includes a child WSDL (using wsdl:include) that defines the type/schema as well as other required elements.
The WSDL validates just fine in eclipse, soapui.
WSDL11Reader.java is failing while processing because it expects some those elements in the root WSDL file.
It ends up with a null pointer exception.
public WSDLDefinitions processDefinition(Definition srcWsdl, URL wsdlLoc) throws IOException, WSDLException
{
log.trace("processDefinition: " + wsdlLoc);
destWsdl = new WSDLDefinitions();
destWsdl.setWsdlTypes(new XSModelTypes());
destWsdl.setWsdlOneOneDefinition(srcWsdl);
destWsdl.setWsdlNamespace(Constants.NS_WSDL11);
processNamespaces(srcWsdl);
processTopLevelElements(srcWsdl);
processTypes(srcWsdl, wsdlLoc);
processUnknownExtensibilityElements(srcWsdl, destWsdl);
processServices(srcWsdl);
if (getAllDefinedBindings(srcWsdl).size() != destWsdl.getBindings().length)
processUnreachableBindings(srcWsdl);
cleanupTemporaryFiles();
return destWsdl;
}
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/548301#548301]
Start a new discussion in JBoss ESB Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 3 months