July 2009 - jboss-dev-forums - Jboss List Archives

[Design of JBoss ESB] - Re: HTTP response (status) codes should be returned through

by dward

The Subject got chopped. It should have read "HTTP response (status) codes should be returned through relevant gateways" View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4246264#4246264 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4246264

16 years, 8 months

1
0
0 / 0

[Design of JBoss ESB] - HTTP response (status) codes should be returned through rele

by dward

Here is the JIRA link: https://jira.jboss.org/jira/browse/JBESB-2761. "When the <jbr-provider/> (JBossRemotingGatewayListener using http protocol) or <http-provider/> (HttpGatewayListener) is used in a synchronous fashion, HTTP response (status) codes should be returned when there are "proxied" HTTP actions in the service's pipeline. This includes HttpRouter, SOAPClient, SOAPProcessor and SOAPProxy. This is similar to JBESB-2511, where response headers weren't always being propagated back, but now we're talking about the response (status) code." I have made the minor fixes necessary in my working copy of trunk, but before I commit them, would like some feedback. A few comments/questions: 1) Comment: The fix for this is quite simple: Just make sure that in the relavant actions, a Message property is set with the status code. For <jbr-provider/>, it means setting the HTTPMetadataConstants.RESPONSE_CODE property so that the JBossRemotingMessageComposer can pick it up. For <http-provider, it means setting the HttpMessageComposer.HTTP_RESPONSE_STATUS property so that the HttpMessageComposer can pick it up. 2) Comment: It should be noted that the *last* action in a pipeline will "win" with regards to the response code. So, say you had a HttpRouter action that sets the property with a 401 code, but then a SOAPClient action that sets it with a 200 code, the 200 would clobber the 401, and thus 200 would get returned to the client. 3) Question: As this is a change to current functionality, should we make a boolean property available (local to the action and/or global to the bus) which activates or deactivates this "feature"? It feels more like it was an oversight (bug) to me, but still, I don't want to change the status quo if it's going to mess people up... Maybe since the SOAPProxy is so new, it's default behavior would be to return the status code, but for SOAPClient and SOAPProcessor, it doesn't unless you enable it? 4) Question: I was able to change the stanard SOAPClient, but not the wise SOAPClient. There just wasn't an API available to me where I could do this. Should this be a new JIRA item just for the wise SOAPClient? Thanks! View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4246263#4246263 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4246263

16 years, 8 months

1
0
0 / 0

[Design of JBoss Build System] - Re: Overriding the default pom.xml during AS build

by jaikiran

Thanks Paul. I'll give this a try against the latest trunk. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4246253#4246253 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4246253

16 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: Java EE inter-module accessibility for Web Beans

by pete.muir＠jboss.org

"alesj" wrote : I'm missing a way to get all EJBs per this BDA. | e.g. per Module and per URL/jar --> how to get EJBs, as definition might be split: interfaces in one jar, impl in another "wolfc" wrote : Interfaces are always accessible on the CP for EJB impls. The BDA containing the EJBs should have no trouble returning them. The dependence is on the EJB, not it's interface definition. In practice, this means they should be defined as present in the BDA which defines their implementation, as Carlo says. If the interface isn't loadable by the impl, then you have a classloading problem anyway, and you won't get as far as starting WB. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4246248#4246248 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4246248

16 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: Java EE inter-module accessibility for Web Beans

by pete.muir＠jboss.org

"alesj" wrote : I've implemented an initial version of this - it's commited in the WB-ri-int trunk. | | But thinking about it, the Deployment API seems wrong or useless. :-) Remember that what the EE spec(s) provide are accessibility rules for classes, not a classloading structure. It's possible to implement the rules in fairly flat, simple fashion, as JBoss does. It would also be possible to produce a much more rigid, hierarchical structure that implements the rules. WB is the RI of 299, so needs to support any impl of the rules. But let's take another case entirely - an OSGi container - here there are some complex rules based on imports that define what classes are and aren't accessible, and this structure needs to be able to represent this too. anonymous wrote : (a) why "List of BDAs" or what determines the order What order? Order isn't particularly important, CDI supports multiple beans that resolve to the same type/binding. It narrows these down itself. I guess I can add some note to the API that the returned list should be ordered in the way the CL would read archives for classloading. anonymous wrote : (b) "Circular dependencies will be detected and ignored by the container" It's quite easy to define a circular accessibility structure such as: ejb-jar1.jar defines it can access ejb-jar2.jar, and ejb-jar2.jar defines it can access ejb-jar1.jar. In this case you would add ejb-jar1.jar to the BDA list for ejb-jar2.jar, and ejb-jar2.jar to the BDA list for ejb-jar1.jar. anonymous wrote : I though the whole point of having BeanDeploymentArchive was to be able to get all accessible BDA's. | e.g. one jar in ear sees all other jars, but doesn't see war's classes/ and lib/*.jar | | Currently I just map the hierarchy/structure, | but this seems pretty much the same as existing flat Deployment. Yes it is - and tbh I didn't expect much more complex for JBoss AS as it uses a very flat classloading structure. Things I want to check we support: * using an ejb-jar not deployed inside the app, but deployed at the top level * using extensions defined in manifest.mf http://java.sun.com/javase/6/docs/technotes/guides/jar/jar.html#Main%20At... and [url]http://java.sun.com/javase/6/docs/technotes/guides/extensions/spec.html View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4246247#4246247 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4246247

16 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: Java EE inter-module accessibility for Web Beans

by alesj

And we'll also need to change how we gather all container names to declare dependency on them: | // call dynamic dependency creator for EJBs | ParameterMetaDataBuilder install = bootstrap.addInstallWithParameters("createDepenencies", "DynamicDependencyCreator", null, ControllerState.CONFIGURED); | install.addParameterMetaData(Object.class.getName(), bootstrapName); | install.addParameterMetaData(Iterable.class.getName(), bootstrap.createInject(ejbServicesValue.getUnderlyingValue(), "ejbContainerNames")); | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4246246#4246246 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4246246

16 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: Java EE inter-module accessibility for Web Beans

by pete.muir＠jboss.org

anonymous wrote : Perhaps all we need is getAccessibleBDAs on BDA? There are two differences between Deployment and BeanDeploymentArchive. First is to allow representing both EAR and WAR. Whilst it would be sensible to represent a WAR as a BDA, it wouldn't make sense to represent an EAR as a BDA (it doesn't have any classes in it, it doesn't have any beans.xml in it). Second is that Deployment supports loadBeanDeploymentArchive which allows Web Beans to discover which BDA any class in the classpath is in. For example, take an archive (not CDI enabled) like: foo.jar - Foo.class some user might, using a CDI API, add a custom Bean to application which uses Foo as it's "beanClass". At this point WB needs to know where Foo fits into the accessibility graph, and hence which EE modules can load it. At this point WB will call loadBeanDeploymentArchive(Foo.class) so it can associate the custom bean with it's accessiblity rules. It's further complicated by the fact that the BDA returned at this point wasn't previously a BDA, so needs adding into the accessibility hierarchy (so WB will re-request the entire graph after the deployment phase in which users can add beans). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4246245#4246245 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4246245

16 years, 8 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: Implementation of the ConnectionManager Service

by jesper.pedersen

Another area is of course the test suite for the JCA implementation - currently under | testsuite/src/main/org/jboss/test/jca | testsuite/src/main/org/jboss/test/jcaprops | in Branch_5_x. The main thing here is that the test suite has to be converted into depending on MC constructs instead of the old JMX bus. Furthermore - a lot of the tests in the suites is timing dependant, which should be eliminated in the new test suite - e.g. we can't use Thread.sleep() and similar constructs. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4246243#4246243 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4246243

16 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: Java EE inter-module accessibility for Web Beans

by wolfc

Interfaces are always accessible on the CP for EJB impls. The BDA containing the EJBs should have no trouble returning them. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4246235#4246235 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4246235

16 years, 8 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: Implementation of the ConnectionManager Service

by jesper.pedersen

We had an application server meeting last week ;) Yes, looking at the current implementation in Branch_5_x is a good start. And like you said look into refactoring too: 1) No inner classes 2) Use an interface for class variables, so we don't depend on the implementation 3) Create a package for each area - NoTx, Tx, ... 4) Use Java 5 as much as possible (especially java.util.concurrent) Other things to keep in mind is https://jira.jboss.org/jira/browse/JBJCA-30 - but that really ties into 2). Just let me know if you have any questions - we can follow up with design of each area in new threads. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4246231#4246231 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4246231

16 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums July 2009