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

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

by heiko.braun＠jboss.com

16 years, 3 months

1
0
0 / 0

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

by heiko.braun＠jboss.com

Container integration depicts container compatibility, but at the same time SPI compatibility. Furthermore it can have maintenance releases. To me this gives us something like: [container]-[spi]-[release] i.e. (leaving square brackets for readability) [jboss5.0.0.CR1]-[3.0.2]-[1] which is identical to what thomas suggested jbossws-jboss-[500beta4]-[3.0.2-SNAPSHOT]- [classifier] View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157930#4157930 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157930

16 years, 3 months

1
0
0 / 0

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

by adrian＠jboss.org

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. 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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157928#4157928 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157928

16 years, 3 months

1
0
0 / 0

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

by alessio.soldano＠jboss.com

Still thinking if this could be acceptable / could work, however my first understanding of what Heiko said was that the artifact id could carry the name of container it was released for, ie: | <dependency> | <groupId>org.jboss.ws</groupId> | <artifactId>jbossws-jboss500Beta4</artifactId> | <version>3.0.3-SNAPSHOT</version> | </dependency> | <dependency> | <groupId>org.jboss.ws</groupId> | <artifactId>jbossws-jboss500CR1</artifactId> | <version>3.0.3-SNAPSHOT</version> | </dependency> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157927#4157927 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157927

16 years, 3 months

1
0
0 / 0

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

by thomas.diesler＠jboss.com

well, there are various other options. - jbossws-jboss500beta4-3.0.2-SNAPSHOT - jbossws-jboss-500beta4-3.0.2-SNAPSHOT (classifier) - module per container with single dependency View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157922#4157922 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157922

16 years, 3 months

1
0
0 / 0

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

by richard.opalka＠jboss.com

Well this is a general issue that affects all AS modules that have different (shorter) lifecycle than AS as whole has. We should ask other AS folks/leads how do they plan to deal with this kind of issues in the future and if it was investigated before mavenization process. In case there will be no appropriate and correct solution to this problem our release cycle will have to follow AS release cycle what we don't want :( View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157919#4157919 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157919

16 years, 3 months

1
0
0 / 0

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

by richard.opalka＠jboss.com

"thomas.diesler(a)jboss.com" wrote : What now? Unfortunately this is the maven artifacts naming issue. AFAIK maven doesn't enable you to specify buildnumber for non-snapshot artifacts :( View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157917#4157917 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157917

16 years, 3 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: [JBWS-2187] javax.xml.ws.Service handlers and thread saf

by darran.lofthouse＠jboss.com

>From my understanding of the evolution of this API I believe that the Observer/Observable patters was used when the configuration was set on the Service rather than when it was set on the Port - as the configuration was being set on the factory for the Ports is made sense that the Ports were notified of configuration changes to update themselves. However since the change of the API to make the configuration changed on the Port I also do not see how this would be required any more. I don't think the fix is just a case of cloning the handler chain it is the whole configuration that needs to be cloned into the Port the ConfigProvider has the following properties: - - ConfigFile - ConfigName - SecurityConfig I think when a Port is created the handlers and the configuration settings should be cloned from the Service but then further changes to these values on the Port will cause the Port to 'forget' the values loaded from the Service and load them locally to the Port. The Port can still make use of methods on the Service to perform the actual loading but these need to be thread safe to cope with concurrent calls and to prevent affecting the other Port instances. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157915#4157915 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157915

16 years, 3 months

1
0
0 / 0

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

by thomas.diesler＠jboss.com

Consider this: #1 you put the container integration in AS trunk #2 you 'mvn deploy' jbossws-jboss-5.0.0-SNAPSHOT from AS trunk #3 CR1 gets released #4 you 'mvn deploy' jbossws-jboss-5.0.0.CR1 from AS trunk #5 you work on jbossws-3.0.3 and need to update jbossws-jboss-5.0.0.CR1 What now? Heiko's naming scheme does not work because you cannot have a dependency on the same artifact with different versions | <dependency> | <groupId>org.jboss.ws</groupId> | <artifactId>jbossws-jboss</artifactId> | <version>5.0.0.Beta4</version> | </dependency> | <dependency> | <groupId>org.jboss.ws</groupId> | <artifactId>jbossws-jboss</artifactId> | <version>5.0.0.CR1</version> | </dependency> | | | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157913#4157913 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157913

16 years, 3 months

1
0
0 / 0

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

by alesj

"scott.stark(a)jboss.org" wrote : Why the profile is looking down to the jsp level is something that needs to be looked at. Its the Profile.getModifiedDeployments call implementation that has this behavior. | | basic.ProfileImpl.getModifiedDeployments | else if( root.hasBeenModified() ) | this goes down to File.lastModified for directories Which does this anonymous wrote : | I understand that we monitor the top level deployment for changes (in this case the jmx-console.war directory) so any changes in the directory content (addtions/removals/updates) causes it's date to be modified, which in turn triggers the re-deployment. Just ran a simple test to verify this 100%. | public class DirChecker implements Runnable | { | private static File dir = new File("C:\\tmp"); | private long lastModified; | | public static void main(String[] args) | { | DirChecker target = new DirChecker(); | target.lastModified = dir.lastModified(); | new Thread(target).start(); | } | | public void run() | { | boolean changed = false; | while (changed == false) | { | long lm = dir.lastModified(); | if (lm > lastModified) | { | System.out.println("lm = " + lm); | changed = true; | } | } | } | } | So I don't see how are you gonna pull this one off in a short time/simple change - w/o metadata change tracking. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157896#4157896 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157896

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