Re: [jboss-dev-forums] [JBoss ESB Development] - SOAPProxy initialization and deployment ordering
by Kevin Conner
Kevin Conner [http://community.jboss.org/people/Kevin.Conner%40jboss.com] replied to the discussion
"SOAPProxy initialization and deployment ordering"
To view the discussion, visit: http://community.jboss.org/message/541585#541585
--------------------------------------------------------------
> proxing services exposed on localhost requires the services to be written in JBossWS
Sorry, but this is not true. If you mean that to proxy a service within the same VM then that is certainly the case by default.
> trying to proxy a localhost service will cause the Server Restart to Freeze.
Proxying a webservice within the same VM, over HTTP, will freeze as the web endpoints are not enabled until the server has started, there is a valve within the web server which controls this. You can, however, workaround this by using the internal notation.
> if the remote service is temporarily unavailable, the whole service containing the SOAP-Proxy will fail deploying
Yes, this is deliberate at present because we publish the derived WSDL and validate the configuration at that point. As mentioned earlier in the week though, this is easy to work around by using a local copy of the WSDL and will give you the behaviour you require.
Kev
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/541585#541585]
Start a new discussion in JBoss ESB Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years
Re: [jboss-dev-forums] [JBoss ESB Development] - SOAPProxy initialization and deployment ordering
by Brad Davis
Brad Davis [http://community.jboss.org/people/bradsdavis] replied to the discussion
"SOAPProxy initialization and deployment ordering"
To view the discussion, visit: http://community.jboss.org/message/541582#541582
--------------------------------------------------------------
SoapProxy is meant to take a service and expose it on the ESB. However, proxing services exposed on localhost requires the services to be written in JBossWS. Otherwise, trying to proxy a localhost service will cause the Server Restart to Freeze. The server will get to the point of trying to proxy, and then will try and attempt to load the WSDL definition to proxy from the LocalHost, which is not yet available because the server has not completed starting up. This does not time out, and leads to an unresponsive SOA-P server.
Additionally, in the case the Web Service being proxied is not on the same box, the following situation could occur. If the SOA-P server is restarting and tries to fetch the remote Service to proxy, if the remote service is temporarily unavailable, the whole service containing the SOAP-Proxy will fail deploying. This is not ideal, since other services may be dependant on the failed SOAP-Proxy service, leading to a domino affect of many services failing.
Idealy, the service would start, and hitting the SOAP-Proxy would return a service temporarily unavailable code, or Soap-Fault. However, it is crucial that the service start and also that the service continues to periodically try and Proxy the remote service to ensure when it comes online, the server can service requests appropriately.
So to summarize, I think it should be Lazily initialized, and in the case that the service is unavailable when it does Lazily initialize, I believe that we should actively try to re-engage with the Proxied Web Service. Otherwise, when the remote services comes back online, if your organization has built against the ESB, even though the service is now available, the ESB Service will remain indefinately down until server restart.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/541582#541582]
Start a new discussion in JBoss ESB Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years
[JBoss Microcontainer Development POJO Server] - Implementing a non-flat deployment for Weld Integration
by Flavia Rainone
Flavia Rainone [http://community.jboss.org/people/flavia.rainone%40jboss.com] created the discussion
"Implementing a non-flat deployment for Weld Integration"
To view the discussion, visit: http://community.jboss.org/message/541531#541531
--------------------------------------------------------------
This thread is for https://jira.jboss.org/jira/browse/WELDINT-1 WELDINT-1.
Taking a look at how the deployers are implemented today, I figured I should start by creating a non-flat version of WeldDiscoveryEnvironment first, so we could have a new environment input fot the new non-flat Deployment implementation.
There a few assumptions I'm making right now that I would like to validate:
- the deployment continues to exist per top level only, the only difference we are going to have is in the BeanDeploymentArchives (BDAs)
- if Deployment.loadBeanDeploymentArchive requests for a non-existing BDA, I should search for all archives in the deployment that are not currently BDAs. If one archive containing the requested class is found, I create a BDA for it and return it.
If the assumptions above are correct, the main question I have right now regards two different deployments that can see each other. So, in the scenario described by the Deployment interface javadoc example, whereas we have ejb-jar A and ear B. This is going to be translated in two different deployments, each one containg one or more BDAs (in the case of the ejb-jar, one BDA only). Since those BDAs can see each other, there must be a way for me to reach Deployment A BDAs from Deployment B BDAs. Is there some SPI in the current implementation of weld integration that supports that?
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/541531#541531]
Start a new discussion in JBoss Microcontainer Development POJO Server at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years
Re: [jboss-dev-forums] [JBoss Microcontainer Development] - ClassPool bootstrap refactoring
by Kabir Khan
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion
"ClassPool bootstrap refactoring"
To view the discussion, visit: http://community.jboss.org/message/541501#541501
--------------------------------------------------------------
I have modified JBoss AOP and my local bootstrap/aop.xml to understand the new classpool setup. AS boots up properly with this and all the aop AS testsuite passes apart from ScopedWovenDependencyTestCase and NotWovenScopedDependencyTestCase. I have reproduced the problem I see for those in kernel with the following test
public void testInstallAndUninstallDependencyWithExtraState() throws Throwable
{
getKernel().getController().addState(ControllerState.newState(), ControllerState.INSTALLED);
installAndUninstallDependencyWithExtraState();
//context2 goes in scoped controller and depends on context1
ControllerContext context2 = assertInstall(offSetNumber(1), "Name2", ControllerState.INSTANTIATED);
//context1 goes in main controller
ControllerContext context1 = assertInstall(offSetNumber(0), "Name1", ControllerState.INSTALLED);
context1 = assertContext("Name1");
context2 = assertContext("Name2");
assertUninstall("Name1"); //Gives error
assertContext("Name2", ControllerState.INSTANTIATED);
assertUninstall("Name2");
assertNotInstalled("Name1");
assertNotInstalled("Name2");
}
The error is
> 1357 WARN [AbstractKernelController] Error uninstalling from Installed: name=Name2 state=Installed
>
> java.lang.NullPointerException
>
> at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1632)
>
> at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1476)
>
> at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1541)
>
> at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1476)
>
> at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:760)
>
> at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:673)
>
> at org.jboss.test.kernel.dependency.support.TestUtil.uninstall(TestUtil.java:110)
>
> at org.jboss.test.kernel.dependency.support.ScopedTestUtil.uninstall(ScopedTestUtil.java:81)
>
> at org.jboss.test.kernel.dependency.test.OldAbstractKernelDependencyTest.uninstall(OldAbstractKernelDependencyTest.java:118)
>
> at org.jboss.test.kernel.dependency.test.OldAbstractKernelDependencyTest.assertUninstall(OldAbstractKernelDependencyTest.java:151)
>
> at org.jboss.test.kernel.dependency.test.ExtraStateTestCase.testInstallAndUninstallDependencyWithExtraState(ExtraStateTestCase.java:95)
>
>
It is getting confused somewhere about the ControllerStateModel.ControllerStateWrappers
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/541501#541501]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years
Re: [jboss-dev-forums] [JBoss Web Services Development] - CXF jms integration
by Richard Opalka
Richard Opalka [http://community.jboss.org/people/richard.opalka%40jboss.com] replied to the discussion
"CXF jms integration"
To view the discussion, visit: http://community.jboss.org/message/541305#541305
--------------------------------------------------------------
> Jim Ma wrote:
>
> Sorry , I may do not explain this problem well . We now create SPI endpoint from ServletMetaData in web.xml . How to distinguish the jms tranport endpoint and create jms endpoint/MD from the user provided jbossws-cxf.xml
You can start separate jbossws-dev forum thread for that. But I'd think about it like *How CXF does it?*
> Jim Ma wrote:
>
> AFAIK, the hornetq deployers create BeanMetaData for queue/topic deployment descriptor
> and KernalDeploymentDeployer will start/stop these BeanMetaData represents queue/topic created by hornetq deployers.
> I understood your suggestion : use deployer input to put the JMS DA after the deployer deployed jms destination. In AS5 , we should put JMSDA after the last real stage deployer ServiceDeployer . AS6, we put JMSDA after KernalDeploymentDeployer. IOW, we do not rely on AS deployer frameworks' deployment dependency mechinism , we rely on the deployer order to resolve the deployment dependency. If this is acceptable and if you do not see any other problems , I will follow your suggestion (as your pseudocode shows) to rewrite .
I don't see the conflict here with the suggestions I provided you. Deployers ordering is working properly these days.
But as discussed on IRC, forget about AS 5 integration. Just go forward with AS 6 ;)
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/541305#541305]
Start a new discussion in JBoss Web Services Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years