[JBoss Web Services Development] - Re: jms transport support in jbossws-cxf
by richard.opalka@jboss.com
"jim.ma" wrote : So this correct jms address deployer should be ordered after TomcatDeployer(the war actually started).
|
| What do you think about this ?
|
We shouldn't rely on Tomcat deployer :(
The fact you'll place your new deployer after tomcat deployer
doesn't mean war is deployed and ready to service after
tomcat deployer finishes its job. For example if there's a war with many
dependencies on other archives, this war won't be started until dependencies are satisfied.
IOW your prediction ordered after TomcatDeployer(the war actually started) is wrong.
BTW we had many troubles in the past with such expectations
and it took us months to fix that. Now all the JBossWS deployers
are executed before tomcat deployer by purpose.
"jim.ma" wrote :
| BTW, I also tried the native jms transport sample . I see there is only jms endpoint registered . The http endpoint is not been list in the services list page . Is it intended ?
|
I don't know the details of that native sample, but if endpoint in JMS sample is accessible via http, it should be registered with endpoints registry and it's a bug if it isn't.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262884#4262884
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262884
15 years, 2 months
[JBoss Microcontainer Development POJO Server] - Re: integration with the Papaki annotation indexer/repositor
by emuckenhuber
"dimitris(a)jboss.org" wrote : Rather than keep going with the dog-fight, why not putting down the exact requirements/usecase for this module (papaki), or is this already discussed elsewhere?
|
I haven't found a discussion on the goals of papaki - so i'll just add a few thoughts. Not all related to papaki, but just describing some of the problems i see with the annotation scanning. Maybe that helps that we can define clearer requirements what papaki should provide and what has to be done elsewhere.
* unified API, independent of the scanning strategy (precompiled or runtime) - as when writing deployers integration code it should not matter where this information comes from. The precompiled index has to be optional, since the spec requires runtime scanning. So either a precompiled index exists or we have to generate it during deployment time.
So that we really have a reusable index, which should be used by all deployers and we only do scanning once (or use the index).
* jboss-metadata - for example jboss-metadata is just asking the AE to get a list of classes which have a given top-level annotation (e.g. @Stateful). Then loading the class and do a separate annotation processing with java reflect. This is also because AE does not have enough information about inheritance, which is needed for all the EE annotation processing.
Beside jboss-metadata there are not many users of AnnotationEnvironment, but we really should avoid having things like getClassloader().loadClass(metaData.getClassName()).getAnnotation(X) if possible.
* jboss-mdr integration - this index should be reused in the MDR as well, as mentioned earlier in this thread.
* inclusion/exclusion of deployments, .jars, classes - we need a way to exclude stuff from annotation scanning, as we are mostly just doing too much scanning. Basically we already have jboss-scanning.xml - which makes sense for our own deployments. Still we need a programmatic way of excluding stuff like:
- if the deployment is not an EE5/EE6 deployment we can just skip any annotation scanning,
- if isMetaDataComplete()
- afaik the new servlet spec requires to exclude .jars (web-fragments), where we should be able to skip scanning as well.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262866#4262866
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262866
15 years, 2 months