[JBoss Web Services Development] New message: "Operation in WSDL not backed up by a service implementation"
by Sameer Pokarna
JBoss development,
A new message was posted in the thread "Operation in WSDL not backed up by a service implementation":
http://community.jboss.org/message/532885#532885
Author : Sameer Pokarna
Profile : http://community.jboss.org/people/sameerpokarna2
Message:
--------------------------------------------------------------
Hi All,
I am trying an approach where I have some operations in the WSDL, but there is no backing implementation. My requirement is that the implementation will be built based on some parameters during runtime. I can have an interface for the WSDL operation, but not the implementation.
Any ideas how this can be accomplished? This can work, because the invocation can be handled by the handler in the handler chain, for example, as one mechanism. There can be other hooks where the actual implementation can be implemented. But, I am unable to deploy a service where the implementation is missing.
Thanks in advance for any ideas.
Regards,
Sameer
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/532885#532885
16 years
[JBoss Microcontainer Development] New message: "Re: jboss-classpool-jbosscl.jar on AS bootstrap classpath"
by Ales Justin
JBoss development,
A new message was posted in the thread "jboss-classpool-jbosscl.jar on AS bootstrap classpath":
http://community.jboss.org/message/532880#532880
Author : Ales Justin
Profile : http://community.jboss.org/people/alesj
Message:
--------------------------------------------------------------
> Can that jar be removed from the classpath, or is there a particular reason to keep it that way?
It looks like we need to split this part out.
With moving Reflect on Javasist impl, we will need Classpool at bootstrap phase.
Which means we'll need jboss-classpool-jbosscl there as well.
But at that time the Module that kicks in won't be depoyers based Module -- AbstractDeploymentClassLoaderPolicyModule.
Since VFSClassLoaderDomainRegistry only kicks in after -- in aop.xml,
the split to jboss-classpool-deployers (currently this is the only class that would get in) would do it --> adding this jar to aop-classloader.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/532880#532880
16 years
[Javassist Development] New message: "Re: Problems with proxy classes and a proposed resolution"
by Andrew Dinn
JBoss development,
A new message was posted in the thread "Problems with proxy classes and a proposed resolution":
http://community.jboss.org/message/532866#532866
Author : Andrew Dinn
Profile : http://community.jboss.org/people/adinn
Message:
--------------------------------------------------------------
Here are the diffs for my modified version of the proxy factory code against the current trunk.
The cache works without leaks and supports serialization. By default classes are created to use the old writeReplace implementation which now reuses proxy classes but still fails to serialize inherited fields.
However, if you disable generation of the writeReplace method then you can serialize and deserialize the +full+ object state so long as you do it using a ProxyObjectOutputStream and ProxyObjectInputStream. The static field ProxyFactory.useWriteReplace represents the default setting for new factories. It is initialized to true to retain backwards compatiility. you can reset this default or else you can configure the behaviour of each new factory by calling factory.setuseWriteReplace(boolean).
Also, I have modified static field ProxyFactory.useCache along the same lines. It defines the default behaviour for new factories. So, iIf you reset this field to false and create a factory then it will not install its classes in the cache. You can also oevrride the setting per factory by calling factory.setUseCache(boolean).
See the javadoc in ProxyFactory, ProxyObjectOutputStream and ProxyObjectInputStream for full details.
n.b. I managed to avoid having to change the naming scheme for generated classes. I did have to introduce a method filter signature to the iidentity criteria for a class. This is, a byte[] which enncodes the behaviour of a method filter instance.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/532866#532866
16 years