[Design of JBoss ESB] - Re: Http Gateway - requirements please...
by tfennelly
So that was some basic configuration. How about adding security etc?
I think whatever we do here will translate into adding appropriate configurations to the web.xml of the generated .war. Seems like there are 2 approaches to this:
1. Add a strict config model inside the ESB config file whereby we only allow certain configurations and we manually map those appropriately to the web.xml going into the generated .war sub deployment.
2. We allow the user to specify a suplemental web.xml that gets merged into the generated web.xml. The user would define the "extra" configs as per the web.xml schema. We could allow them specify this inline in the esb config, or externally. We might want to restrict the config types we allow in this e.g. you can't define any servlet/filter configs etc??
Same would apply to jboss-web.xml.
So what are the pros/cons to these approaches? Other approaches?
The existing http gateway also supports configuration of allowed http methods. Do we need to bring this along?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237955#4237955
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237955
17 years
[Design of JBoss Web Services] - EJBContext as an attachment in WebServiceContext
by jaikiran
Currently in our EJB3 StatelessContainer http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/core/src/main/... we have WSCallbackImpl which is a callback for BeanContext creation and removal:
static class WSCallbackImpl implements BeanContextLifecycleCallback
| {
| private ExtensibleWebServiceContext jaxwsContext;
| private javax.xml.rpc.handler.MessageContext jaxrpcMessageContext;
|
| public WSCallbackImpl(javax.xml.rpc.handler.MessageContext jaxrpc, ExtensibleWebServiceContext jaxws)
| {
| jaxrpcMessageContext = jaxrpc;
| jaxwsContext = jaxws;
| }
|
| public void attached(BeanContext beanCtx)
| {
| // JAX-RPC MessageContext
| StatelessBeanContext sbc = (StatelessBeanContext)beanCtx;
| sbc.setMessageContextJAXRPC(jaxrpcMessageContext);
|
| // JAX-WS MessageContext
| BeanProperty beanProp = sbc.getWebServiceContextProperty();
| if (beanProp != null)
| {
| EJBContext ejbCtx = beanCtx.getEJBContext();
| jaxwsContext.addAttachment(EJBContext.class, ejbCtx);
| beanProp.set(beanCtx.getInstance(), jaxwsContext);
| }
| }
|
| public void released(BeanContext beanCtx)
| {
| StatelessBeanContext sbc = (StatelessBeanContext)beanCtx;
| sbc.setMessageContextJAXRPC(null);
|
| BeanProperty beanProp = sbc.getWebServiceContextProperty();
| if (beanProp != null)
| beanProp.set(beanCtx.getInstance(), null);
| }
| }
As seen in the code, on the BeanContext callback, we attach the EJBContext as an attachment to the WebServiceContext. Does JBossWS still require this EJBContext within the WebServiceContext or can we stop attaching this?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237949#4237949
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237949
17 years
[Design of JBoss ESB] - Re: Http Gateway - requirements please...
by tfennelly
So just looking at some configuration aspects (not implementation).... with the current http gateway (based on the embedded tomcat), you specify the listen address and port as part of defining a provider. Then on the bus definition, you specify the context e.g.
<http-provider name="myhttp" host="localhost" port="9999">
| <http-bus busid="http1" context="/orders" />
| </http-provider>
With the non embedded tomcat approach that we are proposing, a http bus will use the AS/ESB Server's http services and so there will be no configuring of the host and port. As already stated, the ESB deployment process will create a war sub deployment for the gateway. The gateway will then be deployed as with the normal war deployment process. So the provider/bus definition could be something as simple as:
<http-provider name="http">
| <http-bus busid="orders" context="/orders" />
| </http-provider>
Or just infer the context from the busid ala:
<http-provider name="http">
| <http-bus busid="orders" />
| <http-bus busid="queries" />
| </http-provider>
The listener config at the moment looks like this:
<http-listener name="httplistener" busidref="orders" is-gateway="true" />
That works fine I think. One downside is that it seems to mean that we're restricted to a 1:1 bus:listener relationship for http. What if we added a "urlPattern" type config (mapping to the same in the web.xml) option on the listener (or provider perhaps?). That would allow a single bus to be used across multiple listeners e.g.
<!-- "Dogs" order Service.... -->
| <http-listener name="httplistener" busidref="orders" urlPattern="/dogs/*" is-gateway="true" />
|
| <!-- "Cats" order Service.... -->
| <http-listener name="httplistener" busidref="orders" urlPattern="/cats/*" is-gateway="true" />
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237948#4237948
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237948
17 years
[Design of JBoss Build System] - Re: maven.opts for building thirdparty module
by pgier
"jaikiran" wrote : That partially helped me solve the issue. Using
|
| ./build.sh -Dmaven.opts="-Dskip-download-sources -Dversion.org.jboss.ejb3=1.1.7 -Dversion.org.jboss.ejb3.common.client=1.0.0
| | -Dversion.org.jboss.ejb3.core.client=1.1.7 -Dversion.org.jboss.ejb3.proxy.client=1.0.1 -Dversion.org.jboss.ejb3.proxy.clustered.client=1.0.1 -Dversion.org.jboss.ejb3.security.client=1.0.0"
| |
|
|
You shouldn't be using -Dmaven.opts anymore. Did you try
./build.sh -Dskip-download-sources -Dversion.org.jboss.ejb3=1.1.7 -Dversion.org.jboss.ejb3.common.client=1.0.0
| -Dversion.org.jboss.ejb3.core.client=1.1.7 -Dversion.org.jboss.ejb3.proxy.client=1.0.1 -Dversion.org.jboss.ejb3.proxy.clustered.client=1.0.1 -Dversion.org.jboss.ejb3.security.client=1.0.0
|
You're right about the issue in the Ant tasks, they probably aren't passing all the properties correctly. I will look into that today.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237936#4237936
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237936
17 years
[Design of JBoss Web Services] - Re: JBossWS Deployers Integration - Fixing Strategy
by richard.opalka＠jboss.com
Current JBossWS + AS5 integration isn't implemented properly.
There are two main issues with it:
ad1) We're not reusing provided AS deployers architecture/concept.
Instead of reusing it we're reimplementing the same architecture
pattern on our own. It made sence to do it in the past
when we were supporting AS 40, AS 42 and AS 50 but now when AS 5x is
supported only it doesn't make sence anymore.
Correcting JBossWS integration with AS deployers architecture will
also allow other AS projects to better integrate with JBossWS seamlessly
(see JBAS-5935).
ad2) Second problem is we're doing not just metadata processing stuff
in deployers processing layer. Many of the current deployment aspects
have to be executed in Servlet lifecycle methods to prevent
"chicken and egg" problem we're facing at the present
(see JBWS-2370).
These deployment aspects that will be moved to servlet lifecycle methods
will also be executed per endpoint not per deployment like is it now.
The following JBossWS deployment aspects will be removed from deployers chain (will be moved to servlet lifecycle methods):
* EndpointLifecycleDeploymentAspect
* EndpointHandlerDeploymentAspect
* EndpointRecordProcessorDeploymentAspect
* EventingDeploymentAspect
* ServiceEndpointInvokerDeploymentAspect
* RMDeploymentAspect
* EagerInitializeDeploymentAspect
* EndpointMetricsDeploymentAspect
* EndpointAddressDeploymentAspect
The following JBossWS deployment aspects will stay in deployers processing chain (but will be reimplemented to use AS deployers approach instead):
* RuntimeLoaderDeploymentAspect
* PublishContractDeploymentAspect
* JAXBIntroDeploymentAspect
* UnifiedMetaDataDeploymentAspect
* ContextPropertiesDeploymentAspect
* ModifyWebMetaDataDeploymentAspect
* BackwardCompatibleContextRootDeploymentAspect
* BackwardCompatibleURLPatternDeploymentAspect
* EndpointRegistryDeploymentAspect
* EndpointNameDeploymentAspect
* InjectionMetaDataDeploymentAspect
* ContainerMetaDataDeploymentAspect
* WebAppGeneratorDeploymentAspect
* WebAppDeploymentAspect
* VirtualHostDeploymentAspect
WS deployer hooks will be reimplemented too (will become AS deployers)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237925#4237925
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237925
17 years