Re: [jboss-dev-forums] [JCA Development] - JcaXAResourceRecovery
by Jonathan Halliday
Jonathan Halliday [http://community.jboss.org/people/jhalliday] replied to the discussion
"JcaXAResourceRecovery"
To view the discussion, visit: http://community.jboss.org/message/541015#541015
--------------------------------------------------------------
Thanks Jesper. I took a quick look at those changesets and I have two points:
I may be misunderstandin ghte model, but it seems that ManagedConnectionFactoryDeployment.getXAResources() creates a new connection on each call, which is good in that if the db crashes and recovers whilst the app servers stays up, the system will effectively reconnect rather than continuing to use a stale connection. However, as far as I can tell, it's never disposing those connections. Since the recovery system will make one pass every two minutes by default, it's going to leak pretty badly. The integration SPI does not allow for explicit disposal, so the best bet is probably to keep a handle on the last connection used and on each call to getXAResources either validate it (i.e. ping the db to make sure it's still there) and reuse it, or explicitly release it and get a new one.
The XAResourceWrapperImpl usage appears to be applied only to XAResources used for recovery, not he ones used during normal transaction usage. It would be helpful to have the same wrapping applied to the XAResource handed out to the transaction manager during normal operation, as that would allow correlation in the logs between the tx run and the recovery. I'm guessing that's a fairly minor cutnpaste type fix - any chance of squeezing it in?
Thanks
Jonathan
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/541015#541015]
Start a new discussion in JCA Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 12 months
Re: [jboss-dev-forums] [JBoss Microcontainer Development] - Cannot load package from deployment that has dynamic imports
by Thomas Diesler
Thomas Diesler [http://community.jboss.org/people/thomas.diesler%40jboss.com] replied to the discussion
"Cannot load package from deployment that has dynamic imports"
To view the discussion, visit: http://community.jboss.org/message/541005#541005
--------------------------------------------------------------
A trace log is here
2010-05-04 09:04:13,584 TRACE [org.jboss.classloader.spi.base.BaseClassLoader] OSGiBundleClassLoader(a)1443800{org.apache.felix.log-1.0.0} loadClass org.osgi.service.log.LogEntry resolve=false
2010-05-04 09:04:13,584 TRACE [org.jboss.classloader.spi.base.BaseClassLoader] OSGiBundleClassLoader(a)1443800{org.apache.felix.log-1.0.0} aquireLockFairly Thread[Thread-2,5,main]
2010-05-04 09:04:13,584 TRACE [org.jboss.classloader.spi.base.BaseClassLoader] OSGiBundleClassLoader(a)1443800{org.apache.felix.log-1.0.0} aquiredLock Thread[Thread-2,5,main] holding=1
2010-05-04 09:04:13,585 TRACE [org.jboss.classloader.spi.base.BaseClassLoader] OSGiBundleClassLoader(a)1443800{org.apache.felix.log-1.0.0} load from domain org.osgi.service.log.LogEntry domain=OSGiClassLoaderDomain@174a6e2{OSGiClassLoaderDomain}
2010-05-04 09:04:13,585 TRACE [org.jboss.classloader.spi.base.BaseClassLoaderDomain] OSGiClassLoaderDomain@174a6e2{OSGiClassLoaderDomain} findLoader org/osgi/service/log/LogEntry.class classLoader=OSGiBundleClassLoader(a)1443800{org.apache.felix.log-1.0.0} allExports=false findInParent=true
2010-05-04 09:04:13,585 TRACE [org.jboss.classloader.spi.ClassLoaderDomain] OSGiClassLoaderDomain@174a6e2{OSGiClassLoaderDomain} org/osgi/service/log/LogEntry.class matches parent beforeFilter=<EVERYTHING>
2010-05-04 09:04:13,585 TRACE [org.jboss.classloader.spi.ClassLoaderDomain] OSGiClassLoaderDomain@174a6e2{OSGiClassLoaderDomain} load from parent org/osgi/service/log/LogEntry.class parent=ClassLoaderDomain@cb07ef{DefaultDomain}
2010-05-04 09:04:13,585 TRACE [org.jboss.classloader.spi.base.BaseClassLoaderDomain] ClassLoaderDomain@cb07ef{DefaultDomain} findLoader org/osgi/service/log/LogEntry.class classLoader=null allExports=true findInParent=true
2010-05-04 09:04:13,586 TRACE [org.jboss.classloader.spi.ClassLoaderDomain] ClassLoaderDomain@cb07ef{DefaultDomain} org/osgi/service/log/LogEntry.class does NOT match parent beforeFilter=[java], OSGI_CORE, [org.osgi.framework, org.osgi.framework.hooks, org.osgi.framework.hooks.service, org.osgi.framework.launch, org.osgi.service.condpermadmin, org.osgi.service.packageadmin, org.osgi.service.permissionadmin, org.osgi.service.startlevel, org.osgi.service.url, com.sun.xml.internal.bind.v2, javax.imageio, javax.imageio.stream, javax.management, javax.management.loading, javax.management.modelmbean, javax.management.monitor, javax.management.openmbean, javax.management.relation, javax.management.remote, javax.management.remote.rmi, javax.management.timer, javax.naming, javax.naming.event, javax.naming.spi, javax.net, javax.net.ssl, javax.security.cert, javax.xml.datatype, javax.xml.namespace, javax.xml.parsers, javax.xml.transform, javax.xml.transform.dom, javax.xml.transform.sax, javax.xml.transform.stream, javax.xml.validation, org.apache.log4j, org.jboss.beans.metadata.plugins.builder, org.jboss.beans.metadata.plugins, org.jboss.beans.metadata.spi.builder, org.jboss.beans.metadata.spi, org.jboss.dependency.spi, org.jboss.kernel.spi.dependency, org.jboss.logging, org.jboss.osgi.deployment.deployer, org.jboss.osgi.deployment.interceptor, org.jboss.osgi.spi.capability, org.jboss.osgi.spi.framework, org.jboss.osgi.spi.service, org.jboss.osgi.spi.util, org.jboss.osgi.spi, org.jboss.osgi.testing, org.jboss.osgi.vfs, org.jboss.vfs, org.w3c.dom, org.w3c.dom.bootstrap, org.w3c.dom.events, org.w3c.dom.ls, org.w3c.dom.ranges, org.w3c.dom.traversal, org.w3c.dom.views, org.xml.sax, org.xml.sax.ext, org.xml.sax.helpers]
2010-05-04 09:04:13,586 TRACE [org.jboss.classloader.spi.base.BaseClassLoaderDomain] ClassLoaderDomain@cb07ef{DefaultDomain} trying to load org/osgi/service/log/LogEntry.class from all exports of package org.osgi.service.log null
2010-05-04 09:04:13,586 TRACE [org.jboss.classloader.spi.ClassLoaderDomain] ClassLoaderDomain@cb07ef{DefaultDomain} org/osgi/service/log/LogEntry.class does NOT match parent afterFilter=<NOTHING>
2010-05-04 09:04:13,586 TRACE [org.jboss.classloader.spi.base.BaseClassLoaderDomain] OSGiClassLoaderDomain@174a6e2{OSGiClassLoaderDomain} not loading org/osgi/service/log/LogEntry.class from all exports
2010-05-04 09:04:13,587 TRACE [org.jboss.classloader.spi.base.BaseClassLoaderDomain] OSGiClassLoaderDomain@174a6e2{OSGiClassLoaderDomain} trying to load org/osgi/service/log/LogEntry.class from import FilteredDelegateLoader@11ff451{delegate=OSGiClassLoaderPolicy(a)553763{osgi.cmpn-4.2.0.200908310645}} for OSGiBundleClassLoader(a)1443800{org.apache.felix.log-1.0.0}
2010-05-04 09:04:13,587 TRACE [org.jboss.classloader.spi.filter.FilteredDelegateLoader] FilteredDelegateLoader@11ff451{delegate=OSGiClassLoaderPolicy(a)553763{osgi.cmpn-4.2.0.200908310645}} org/osgi/service/log/LogEntry.class matches resource filter=[org.osgi.service.log]
2010-05-04 09:04:13,588 TRACE [org.jboss.classloader.spi.base.BaseClassLoader] OSGiBundleClassLoader(a)1c79dfc{osgi.cmpn-4.2.0.200908310645} get resource locally org/osgi/service/log/LogEntry.class
2010-05-04 09:04:13,588 TRACE [org.jboss.classloader.spi.base.BaseClassLoader] OSGiBundleClassLoader(a)1c79dfc{osgi.cmpn-4.2.0.200908310645} got resource locally org/osgi/service/log/LogEntry.class
2010-05-04 09:04:13,588 TRACE [org.jboss.classloader.spi.base.BaseClassLoader] OSGiBundleClassLoader(a)1c79dfc{osgi.cmpn-4.2.0.200908310645} attemptLock Thread[Thread-2,5,main]
2010-05-04 09:04:13,589 TRACE [org.jboss.classloader.spi.base.BaseClassLoader] OSGiBundleClassLoader(a)1c79dfc{osgi.cmpn-4.2.0.200908310645} locked Thread[Thread-2,5,main] holding=1
2010-05-04 09:04:13,589 TRACE [org.jboss.classloader.spi.filter.FilteredDelegateLoader] FilteredDelegateLoader@11ff451{delegate=OSGiClassLoaderPolicy(a)553763{osgi.cmpn-4.2.0.200908310645}} org.osgi.service.log.LogEntry matches class filter=[org.osgi.service.log]
2010-05-04 09:04:13,589 TRACE [org.jboss.classloader.spi.base.BaseClassLoader] OSGiBundleClassLoader(a)1c79dfc{osgi.cmpn-4.2.0.200908310645} load class locally org.osgi.service.log.LogEntry
2010-05-04 09:04:13,592 TRACE [org.jboss.classloader.spi.base.BaseClassLoader] OSGiBundleClassLoader(a)1c79dfc{osgi.cmpn-4.2.0.200908310645} getPackage org.osgi.service.log
2010-05-04 09:04:13,593 TRACE [org.jboss.classloader.spi.base.BaseClassLoader] OSGiBundleClassLoader(a)1c79dfc{osgi.cmpn-4.2.0.200908310645} getPackage org.osgi.service.log domain=OSGiClassLoaderDomain@174a6e2{OSGiClassLoaderDomain}
2010-05-04 09:04:13,593 TRACE [org.jboss.classloader.spi.ClassLoaderDomain] OSGiClassLoaderDomain@174a6e2{OSGiClassLoaderDomain} org.osgi.service.log matches parent beforeFilter=<EVERYTHING>
2010-05-04 09:04:13,593 TRACE [org.jboss.classloader.spi.ClassLoaderDomain] OSGiClassLoaderDomain@174a6e2{OSGiClassLoaderDomain} get package from parent org.osgi.service.log parent=ClassLoaderDomain@cb07ef{DefaultDomain}
2010-05-04 09:04:13,594 TRACE [org.jboss.classloader.spi.ClassLoaderDomain] ClassLoaderDomain@cb07ef{DefaultDomain} org.osgi.service.log does NOT match parent beforeFilter=[java], OSGI_CORE, [org.osgi.framework, org.osgi.framework.hooks, org.osgi.framework.hooks.service, org.osgi.framework.launch, org.osgi.service.condpermadmin, org.osgi.service.packageadmin, org.osgi.service.permissionadmin, org.osgi.service.startlevel, org.osgi.service.url, com.sun.xml.internal.bind.v2, javax.imageio, javax.imageio.stream, javax.management, javax.management.loading, javax.management.modelmbean, javax.management.monitor, javax.management.openmbean, javax.management.relation, javax.management.remote, javax.management.remote.rmi, javax.management.timer, javax.naming, javax.naming.event, javax.naming.spi, javax.net, javax.net.ssl, javax.security.cert, javax.xml.datatype, javax.xml.namespace, javax.xml.parsers, javax.xml.transform, javax.xml.transform.dom, javax.xml.transform.sax, javax.xml.transform.stream, javax.xml.validation, org.apache.log4j, org.jboss.beans.metadata.plugins.builder, org.jboss.beans.metadata.plugins, org.jboss.beans.metadata.spi.builder, org.jboss.beans.metadata.spi, org.jboss.dependency.spi, org.jboss.kernel.spi.dependency, org.jboss.logging, org.jboss.osgi.deployment.deployer, org.jboss.osgi.deployment.interceptor, org.jboss.osgi.spi.capability, org.jboss.osgi.spi.framework, org.jboss.osgi.spi.service, org.jboss.osgi.spi.util, org.jboss.osgi.spi, org.jboss.osgi.testing, org.jboss.osgi.vfs, org.jboss.vfs, org.w3c.dom, org.w3c.dom.bootstrap, org.w3c.dom.events, org.w3c.dom.ls, org.w3c.dom.ranges, org.w3c.dom.traversal, org.w3c.dom.views, org.xml.sax, org.xml.sax.ext, org.xml.sax.helpers]
2010-05-04 09:04:13,594 TRACE [org.jboss.classloader.spi.base.BaseClassLoaderDomain] ClassLoaderDomain@cb07ef{DefaultDomain} trying to get package org.osgi.service.log from all exports null
2010-05-04 09:04:13,594 TRACE [org.jboss.classloader.spi.ClassLoaderDomain] ClassLoaderDomain@cb07ef{DefaultDomain} org.osgi.service.log does NOT match parent afterFilter=<NOTHING>
2010-05-04 09:04:13,594 TRACE [org.jboss.classloader.spi.ClassLoaderDomain] OSGiClassLoaderDomain@174a6e2{OSGiClassLoaderDomain} package not found in parent org.osgi.service.log parent=ClassLoaderDomain@cb07ef{DefaultDomain}
2010-05-04 09:04:13,594 TRACE [org.jboss.classloader.spi.base.BaseClassLoaderDomain] OSGiClassLoaderDomain@174a6e2{OSGiClassLoaderDomain} not getting package org.osgi.service.log from all exports
2010-05-04 09:04:13,595 TRACE [org.jboss.classloader.spi.base.BaseClassLoaderDomain] OSGiClassLoaderDomain@174a6e2{OSGiClassLoaderDomain} trying to get package org.osgi.service.log from imports [LazyFilteredDelegateLoader@a75737{factory=org.jboss.classloading.spi.dependency.policy.DynamicClassLoaderPolicyFactory(a)4f0853}] for OSGiBundleClassLoader(a)1c79dfc{osgi.cmpn-4.2.0.200908310645}
2010-05-04 09:04:13,595 TRACE [org.jboss.classloader.spi.filter.FilteredDelegateLoader] LazyFilteredDelegateLoader@a75737{factory=org.jboss.classloading.spi.dependency.policy.DynamicClassLoaderPolicyFactory(a)4f0853} org.osgi.service.log matches package filter=<EVERYTHING>
2010-05-04 09:04:13,595 TRACE [org.jboss.classloader.spi.base.BaseDelegateLoader] Factory did not create a delegate: org.jboss.classloading.spi.dependency.policy.DynamicClassLoaderPolicyFactory@4f0853
2010-05-04 09:04:13,595 WARN [org.jboss.classloader.spi.base.BaseDelegateLoader] Not getting package org.osgi.service.log from policy that has no classLoader: LazyFilteredDelegateLoader@a75737{factory=org.jboss.classloading.spi.dependency.policy.DynamicClassLoaderPolicyFactory(a)4f0853 filter=<EVERYTHING>}
2010-05-04 09:04:13,596 TRACE [org.jboss.classloader.spi.base.BaseClassLoaderDomain] OSGiClassLoaderDomain@174a6e2{OSGiClassLoaderDomain} trying to get package org.osgi.service.log from requesting OSGiBundleClassLoader(a)1c79dfc{osgi.cmpn-4.2.0.200908310645}
2010-05-04 09:04:13,596 TRACE [org.jboss.classloader.spi.ClassLoaderDomain] OSGiClassLoaderDomain@174a6e2{OSGiClassLoaderDomain} org.osgi.service.log does NOT match parent afterFilter=<NOTHING>
2010-05-04 09:04:13,596 TRACE [org.jboss.classloader.spi.base.BaseClassLoader] OSGiBundleClassLoader(a)1c79dfc{osgi.cmpn-4.2.0.200908310645} package not found org.osgi.service.log
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/541005#541005]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 12 months
[JBoss Microcontainer Development] - Cannot load package from deployment that has dynamic imports
by Thomas Diesler
Thomas Diesler [http://community.jboss.org/people/thomas.diesler%40jboss.com] created the discussion
"Cannot load package from deployment that has dynamic imports"
To view the discussion, visit: http://community.jboss.org/message/541003#541003
--------------------------------------------------------------
The symptom is that we see WARN messages like this
09:04:13,595 WARN [BaseDelegateLoader] Not getting package org.osgi.service.log from policy that has no classLoader: LazyFilteredDelegateLoader@a75737{factory=org.jboss.classloading.spi.dependency.policy.DynamicClassLoaderPolicyFactory(a)4f0853 filter=<EVERYTHING>}
09:04:13,599 WARN [BaseDelegateLoader] Not getting package org.osgi.service.log from policy that has no classLoader: LazyFilteredDelegateLoader@a75737{factory=org.jboss.classloading.spi.dependency.policy.DynamicClassLoaderPolicyFactory(a)4f0853 filter=<EVERYTHING>}
09:04:13,727 WARN [BaseDelegateLoader] Not getting package org.osgi.util.tracker from policy that has no classLoader: LazyFilteredDelegateLoader@a75737{factory=org.jboss.classloading.spi.dependency.policy.DynamicClassLoaderPolicyFactory(a)4f0853 filter=<EVERYTHING>
The reason seems that the http://fisheye.jboss.org/browse/JBossAS/projects/jboss-cl/tags/2.2.0.Alph... BaseClassLoaderDomain uses this sematics in getPackage
1. // Try the before attempt
2. // Next we try the old "big ball of mud" model
3. // Next we try the imports
4. // Finally use any requesting classloader
5. // Try the after attempt
In step #3 the imports also include the dynamic imports (even the EVERYTHING aka '*' imports)
The LazyFilteredDelegateLoader has no classloader associated and getPackage fails.
In OSGi dynamic imports are considered *after* the bundles embedded classpath.
I suggest we split getPackageFromImports in two variants and consider dynamic import between step #4 and #5
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/541003#541003]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 12 months
Re: [jboss-dev-forums] [jBPM Development] - JBPM-2537
by Maciej Swiderski
Maciej Swiderski [http://community.jboss.org/people/swiderski.maciej] replied to the discussion
"JBPM-2537"
To view the discussion, visit: http://community.jboss.org/message/540999#540999
--------------------------------------------------------------
Hi guys,
finally I found some time to look into this issue.
First of all I don't see anything wrong with adding methods (such as timeout or cancel) to activity behavior - to me they are regular life cycle methods of the activity. Especially that one of the core funtinalities is timers.
Next, ExternalActivityBehaviour is not modified. That's why new interface was created (TimeoutActivityBehaviour) and this interface is only implemented by TaskActivity.
I have tried the patch from jira (20100227-JBPM-2753) but unfortunately it is incomplete. There are few things missing - mainly those that Ronald posted inline. I made some modification to make it to work. So, currently both issues seems to have a solution:
- JBPM-2753 - uses timeout to close task
- JBPM-2807 - uses cancel to close task
Main change compared to Ronlad's changes is to make Timer to make use of new signaling - marking it as timeout aware. It uses new signal constructor introduced by Ronald.
I will put some comments and the patch into jira later today.
Let me know your comments.
Cheers,
Maciej
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/540999#540999]
Start a new discussion in jBPM Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 12 months
Re: [jboss-dev-forums] [JBoss Microcontainer Development] - ShrinkWrapDeployer
by Ales Justin
Ales Justin [http://community.jboss.org/people/alesj] replied to the discussion
"ShrinkWrapDeployer"
To view the discussion, visit: http://community.jboss.org/message/540998#540998
--------------------------------------------------------------
> The idea was to initiate the deployment with some specific metadata that describes deployment (file, directory, SWArchive, etc..). There would then be a series of deployers which look for these specific metadata types and would invoke the proper VFS mount/unmount operations for the deployment.
>
What you're describing is all already there.
* StructureMetaData -- perhaps all it's missing is some more exact deployment type info (file, dir, ...)
* jboss-structure.xml -- again, perhaps some more info on the type
But why exactly do you need this?
But who would provide this? If it's not pre-determined, then we need to figure this out.
And that's exactly why we have structure deployers.
Imo, the structure deployer are the only one's who know where and how to (un)mount things.
As they are the only one's that (should) understand the deployment structure.
With this, I already see some inconsistency; e.g. we do mounting in VFSClassLoaderClassPathDeployer [1].
This mean we're doing some things twice; e.g. 1st mounting war's libs, then doing this again for [1]
But I guess this is a workaround for dynamically added classpath entries?
Meaning we should be able to force people to do this themselves, hence it wouldn't be needed in [1], right?
> The key change is to align the structure deployers with the Deployer API and actually have deploy and undeploy operations.
>
Agreed, but this is big spi change, hence it will have to wait till v3.0.
And like you said, it will help us remove Automounter.
> Then you can introduce deployers in front of structure determination to handle proper mounting. With this change, all that would be needed to integrate the ShrinkWrap Archive deployment would be to create the deployment (in embedded, TorqueBox, etc.) with an attachment that would cause a special mounting deployer to pick up and mount the ArchiveFileSystem as apposed to the normal filesystem based mounting deployers.
You can already do this -- perhaps we cound only extend StructureContext to keep the ref to (VFS)Deployment.
e.g.
* add new structure deployer SWRP, before any other -> relative order < 0
* the root or our mounting point has unique suffix; e.g. root.swrp
* we then recognize this root in our SWRP, and properly mount it
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/540998#540998]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 12 months
Re: [jboss-dev-forums] [JBoss Web Services Development] - CXF jms integration
by Alessio Soldano
Alessio Soldano [http://community.jboss.org/people/alessio.soldano%40jboss.com] replied to the discussion
"CXF jms integration"
To view the discussion, visit: http://community.jboss.org/message/540977#540977
--------------------------------------------------------------
> Jim Ma wrote:
> >
> > * jbossws-endpoints.xml: generally speaking, I would allow users to avoid providing that in most cases. AFAICS, the reason for that file is just in getting the information on which jms destinations are to be used for the endpoints included in the deployment. I think this can also be specified through a user provided jboss-cxf.xml, hence we need to allow for that too.
> >
> There are following reasons I named it to general jbossws-endpoint.xml and not jms-endpoints.xml:
> a) Considering our spi framework and IL architecture, we can only creat the deployer in IL . That means the deployer is stack neutral and it should not only parse/deploy the stack specific deployment descriptor : for example jboss-cxf.xml.
OK, I see what you mean regarding the parsing deployer having to be in IL, you can just have DA in JBWS-CXF and those can't access container specific stuff. That's fine. I'm saying, however, that a user can just deploy his jboss-cxf.xml with jms endpoints and expect the information there to be picked up, regardless of the jbossws-endpoints.xml which he can of course avoid providing (why having multiple descriptors when we can just use the cxf one? do we *really* need that?). So, one of my points is, why don't we just avoid using that jbossws-endpoints.xml and parse the jboss-cxf.xml in a DA, populating the extended SPI metadata? What I'm missing here?
I think what Richard wrote was a good starting point, perhaps I'm missing some issues?
* extend our UMDM (located in SPI) to provide JMS endpoint abstractions
* extend our DA framework to distinguish DA aspects intended to create web based endpoints and jms based endpoints
* update our ASIL (concretely WSDeploymentAspectDeployer) to distinguish between Web DAs and JMS DAs
* implement CXF DA that will map jboss-cxf.xml MD to our UMDM (ensures CXF -> SPI (http://www.jboss.org/file-access/default/members/jbossws/images/wsf.png) dependency)
* implement ASIL DA that will create JMS MD from our UMDM (ensures http://www.jboss.org/file-access/default/members/jbossws/images/wsf.png ASIL -> SPI dependency)
* implement CXF DA that will register plain JMS endpoints with CXF (ensures http://www.jboss.org/file-access/default/members/jbossws/images/wsf.png CXF -> SPI dependency)
> b) There are other transports supported in CXF : invm, jbi. We can extend this file to support them . So it is only for jms transport .
Yes, right. The problem is that http transport is not going to be configured in that jbossws-endpoints.xml as that's completely done with the already existing jboss/javaee descriptors + (optional and just if you're using cxf) jboss-cxf.xml. So it's a kind of overlap.
While, in the long term, I agree with you it most probably makes sense to have a jbossws common way of configuring the jms transport even if that can already be done with cxf stack through jboss-cxf.xml, I still believe that:
- we don't need that for http transport, as we already have full means of configuration; moreover we need to keep things simple (in terms of user configuration)
- support for jms endpoint definition in jboss-cxf.xml is required
- we're not probably going to have invm and/or jbi transport with other stacks, so supporting them through cxf specific configuration only might be reasonable as far as we know today
> c) Combine our features (eg, jaxbintro configuration xml) and jbossws-endpoint.xml to generated CXF deployment configuraiton.
OK, I agree we need to have features like jaxbintro available with jms endpoints too. Good.
What I don't like is the need to configuring this in another descriptor (jbossws-endoints.xml), while that configuration already goes to jaxbintros.xml (which is stack neutral and used in other projects external to jbossws) and is already integrated in jbossws. Being able to simply go on using the already existing JaxbIntro DA for that should be the way to go here. We have to minimize the need of duplicated configuration and implementation of features for different transport.
> > Moreover, something else we should probably evaluate implementing (perhaps in CXF?) is an annotation for setting those destinations on the endpoint class (@JMSTransport or something like that). That said, yes, a user might still want to use xml for providing that info, in which case a configuration file like jbossws-endpoints.xml is fine.
> >
> Good point . This is my fourth reason to name it jbossws-endpoints.xml. The jms configuration can be defined in wsdl file, so user only need to specify the endpoint class name to deploy jms endpoints in CXF. We also need use this to enable the soap over jms in CXF .
I probably need to see a testcase with this usecase first, before commenting here.
> > * new SPI metadata: besides the naming not completely convincing me, I think the few info we need (jms destination addresses currently) should live at the Endpoint level, not higher than that and separated from that as they currently are in jms-integration branch. Jim, did you evaluate having a hierarchy for the SPI Endpoint (with the current one becoming HttpEndpoint and a new JMSEndpoint having the destinations' info)?
> >
>
> I evaluated to make new SPI metadata to extend the current SPI Endpoint. But I did not find benifit from it, as our DeploymentAspects was intended to process the SPI HttpEndpoint. It can
> not be reused to process JMSEndpoint too. Now I took the new SPI metadata as flag to dispatch the jms endpoint deployment . New created DeploymentAspect to deploy the jms endpoint and old DeploymentAspects to deploy http endpoint .
Well, the benefits is in a cleaner SPI. The existing DA meant for http endpoint will start requiring http endpoints, I think that's fine. We might also introduce a concept of http DA and jms DA, as Richard mentioned before.
Regarding that being used as a flag for dispatching to the JMS DA/deployers, sure, I agree you need some kind of flags, but nothing prevents you from basing the check on the endpoint's type.
> > Still on this topic, we might probably create the SPI JMSEndpoint at the same time as the Http one (currently the WSDeploymentBuilder::build seems to me to be creating the Deployment only, while the Endpoint is actually created later by the CXFEndpointsDeployment). The CXFEndpointsDeployment should probably just do the endpoint registration (perhaps even that can unified..?), with already existing spi endpoints
> >
> This is because the jms SPI Endpoint does not need the exsiting DeploymentAspect to process, and jms SPI Endpoint is created just for registry, and it's in different deploy flow. Do you see any other points we need to unify and reuse DeploymentAspect ?
No, at least not now. But as I mentioned above, we need to try minimizing the duplication, hence make possible to use the same DA when they're not specific to a given transport.
Generally speaking, deployment aspect could be modified so that they do actuall processing on the endpoint type they're meant for.
> > * WSEndpointsReadDeployer: while I was not able to think about this solution before for the destinations dependency management, what I don't like here is that it's not part of our DA group. Where does it run in the deployers' chain? can we unify things here (make it a DA)?
> It is running after the last DeploymentAspectDeployer and before KernelDeploymentDeployer. It's not possible to unify it to a DA. It needs the As dependency to create a BeanMetaData.
OK, understood, thanks. We can probably investigate and deal with this as a further optimization step later.
> > * do you already know whether the proposed architecture is going to work with CXF 2.3 SOAP-over-JMS-1.0 support too ( http://cxf.apache.org/docs/soap-over-jms-10-support.html http://cxf.apache.org/docs/soap-over-jms-10-support.html)?
> Yes. It supports the soap-over-jms. The current deployer architcture supports to deploy the endpoint class with wsdl file .
> I also uses the "soap-over-jms spec" style jms address to reprents the endpoint address for spec "alignment" .
Excellent, thanks. I think this might fall in the point above where I said I'd need to see a testcase... in that case we'll get back to this topic.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/540977#540977]
Start a new discussion in JBoss Web Services Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 12 months
