June 2008 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: Deploying Ears and Wars through ProfileService

by mark.spritzler

Perfect View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4158013#4158013 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4158013

16 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: Deploying Ears and Wars through ProfileService

by scott.stark＠jboss.org

Yes, testMCBeansDeploymentType, testSarDeploymentType, testWarDeploymentType: | public void testWarDeploymentType() | throws Exception | { | ManagementView mgtView = getManagementView(); | Set<String> names = mgtView.getDeploymentNamesForType(KnownDeploymentTypes.JavaEEWebApplication.getType()); | | The KnownDeploymentTypes value is only used to obtain the string form of the type as the ManagementView api uses a string type since its really an arbitrary notion that we don't want to restrict with an enum. The KnownDeploymentTypes is just a convenience for the well known deployment types. The DeployUnitTestCase checks for the deployment types it deploys, but it just uses the string type directly. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4158003#4158003 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4158003

16 years, 3 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBMETA-44, ws annotation processing for references

by alessio.soldano＠jboss.com

This said, here is the current implementation for finding out the serviceImplClass and targetClassName used for the bind (from NativeServiceRefBinderJAXWS): | String serviceImplClass = null; | | // #1 Use the explicit @WebServiceRef.value | if (wsref != null && wsref.value() != Object.class) | serviceImplClass = wsref.value().getName(); | | // #2 Use the target ref type | if (serviceImplClass == null && targetClass != null && Service.class.isAssignableFrom(targetClass)) | serviceImplClass = targetClass.getName(); | | // #3 Use <service-interface> | if (serviceImplClass == null && serviceRef.getServiceInterface() != null) | serviceImplClass = serviceRef.getServiceInterface(); | | // #4 Use javax.xml.ws.Service | if (serviceImplClass == null) | serviceImplClass = Service.class.getName(); | | // #1 Use the explicit @WebServiceRef.type | if (wsref != null && wsref.type() != Object.class) | targetClassName = wsref.type().getName(); | | // #2 Use the target ref type | if (targetClassName == null && targetClass != null && Service.class.isAssignableFrom(targetClass) == false) | targetClassName = targetClass.getName(); | We have (#4) setting javax.xml.ws.Service as serviceImplClass when #1, #2 and #3 give no result. This imho hides an error, ie. not failing when @WebServiceRef.type is not set and the annotation has type (class) target. As a matter of fact, the javaee 5 doc says (https://java.sun.com/javaee/5/docs/api/javax/xml/ws/WebServiceRef.html): anonymous wrote : | type | | public abstract Class type | | The Java type of the resource. For field annotations, the default is the type of the field. For method annotations, the default is the type of the JavaBeans property. For class annotations, there is no default and this must be specified. | Thomas, do you have an opinion about this? I think this implementation is simply a bit looser, nothing more. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4158002#4158002 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4158002

16 years, 3 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBMETA-44, ws annotation processing for references

by alessio.soldano＠jboss.com

"alex.loubyansky(a)jboss.com" wrote : Should there be a default value for the service-interface then? IMHO no. Btw, I've just re-deployed the JBWS-2171 appclient in debug mode on AS500Beta4 and as I expected the service-interface attribute is null.The bind process doesn't fail because the annotatedElement is set, since this is a jaxws service ref. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157995#4157995 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157995

16 years, 3 months

1
0
0 / 0

[Design of JBoss ESB] - redelivery

by jurgenvb

Hi, I have a ESB service that needs as an action to push a message via a proxy mechanism to a remote server. How could I accomplish that the ESB retries the service at a later time if there is a connection problem to the remote server (accessed trough the proxy) ? Currently I throw an exception in the service action when the proxy call fails. I am aware of the built-in ESB redelivery service, but this one does not seem to work when an exception is thrown in the action processing of a service. Thanks for your feedback. Jurgen. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157993#4157993 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157993

16 years, 3 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Deployment redeploy

by scott.stark＠jboss.org

Ok, I see. That is typical behavior for a directory. We'll have to look to the metadata files for root's that are directories to restore the behavior from the 4.x layers. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157989#4157989 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157989

16 years, 3 months

1
0
0 / 0

[Design of JBoss/Tomcat Integration] - Re: JBAS-5268 - Mapping legacy web classloading rules

by scott.stark＠jboss.org

"adrian(a)jboss.org" wrote : I'm trying to figure out how the old configuration worked in terms of precedence | of all the different flags for parent first or scoped classloading. | | It complicated by having two flags for java2ClassLoadingCompliance in jboss-web.xml | one on the class-loading element and another on the loader repository. | | We still aren't doing it properly for the legacy configurations. | | As far as I can tell, the attribute on the class-loading element controls behaviour | at the tomcat classloader level in 4.2.x, but the flag on the loader repository config | controls the entire hierarchical loader repository. | The final value will be overridden by each depending on what you are trying to achieve. | That is correct. "adrian(a)jboss.org" wrote : | So I think the rules are supposed to be (below true means delegate to parent first). | | a) class-loading attribute = true + no loader repository config => true | b) class-loading attribute = false + no loader repository config => false | c) class-loading attribute = true + loader repository config = true => true | d) class-loading attribute = false + loader repository config = true => false | e) class-loading attribute = true + loader repository config = false => true (1) | f) class-loading attribute = false + loader repository config = false => false | | NOTE (1) is for the edge case where some other classloader is in the web-app's | loader repository. Since the loader repository has a scoped definition, | classes in that other classloader would be prefered before the default classloading | domain. | | I think we doing everything correct, except case (d). | i.e. the loader repository config saying delegate to the parent first is overridding | the class-loading attribute saying do scoped classloading. | | This is because JBossWebAppParsingDeployer is not looking at the | class-loading attribute when setting up the LoaderRepositoryConfig. | | But this code needs moving the WarClassLoaderDeployer anyway | with it constructing the new ClassLoadingMetaData directly. Yes, I agree with this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157986#4157986 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157986

16 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Constants in interfaces

by timfox

I've seen at least one place (ConnectionParams) where constants are put in th e interface - in a kind of weird mixture of static and non static. This is generally considered bad practice since constants are part of the implementation, not the interface. I'll move them, but we should avoid this kind of thing in the future. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157980#4157980 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157980

16 years, 3 months

1
0
0 / 0

[Design of POJO Server] - [jboss-metadata] Release 1.0.0.Beta21

by ALRubinger

I've got an issue pending release: http://jira.jboss.com/jira/browse/JBMETA-57 Are we currently waiting on anything else? I see Alexey's got the Unit Tests for JBoss50Creator passing now as well. Also, there's no Beta21 release in JIRA. ;) S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157975#4157975 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157975

16 years, 3 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: container integration naming issue

by thomas.diesler＠jboss.com

16 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums June 2008