October 2006 - jboss-dev-forums - Jboss List Archives

[Design the new POJO MicroContainer] - Re: JBMICROCONT-105, structural deployer, vfs refactoring

by scott.stark＠jboss.org

My main requirement is that there be support for explicitly declaring the structure: subdeployments, classpath (including ordering), metdata paths, etc. It always has been a pain/weakness to rely on the packaging determining this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978645#3978645 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978645

19 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Parameter matching issue?

by scott.stark＠jboss.org

Right, I knew the workaround. We should just have consistent resolution logic such that a deployment that works with version 1 of a class, continues to work with version 2 provided that version 2 is backward compatibile. The case of adding single argument ctors to a class is guarenteed to be backward compatibile. I see this related issue: http://jira.jboss.com/jira/browse/JBMICROCONT-40 but its not about trying to have consistent resolution. Its really about telling the user that the current configuration is amiguous, and the choice made by the mc needs to be validated. Is there another issue I'm missing that uses the parameter type in the ctor selection? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978636#3978636 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978636

19 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - JBMICROCONT-105, structural deployer, vfs refactoring

by scott.stark＠jboss.org

In terms of getting a stable mc spi for jboss5, resolving the current structural deployers/vfs isArchive issue is an important one. I created JBMICROCONT-105 to get this done. Let's hash out an spi that both jboss5/ejb3 embedded/hem can work with. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978635#3978635 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978635

19 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - 2.0.0.GA release

by scott.stark＠jboss.org

We need to get an mc release out for use in the jboss5 beta. I put a tentative date of Nov 3 as we are targetting Nov 10 for the jboss5 release. We need to get the 30+ issues assigned and scheduled to get this done. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978632#3978632 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978632

19 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBWS-1133 - Exploded JSR-181 POJO Deployment Fails Redep

by scott.stark＠jboss.org

1 is the direction will be moving towards in head as that layer that actually deploys the web app should just be given the metadata that describes what the web app consists of. Any number of other deployers can have run earlier in the deployment phase to produce this metadata from various sources. A hybrid approach that moves closer to what is needed in jboss5 would be a plugin into the tomcat deployer that allowed modification of the WebMetaData. This needs to be an optional plugin binding so that we don't have to pulling in the entire webservice stack for a tomcat only config. If the plugin has modifed that data, then the tomcat deployer can write out a modified web.xml and reference it via the alt-dd. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978626#3978626 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978626

19 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBWS-1079 - Incorrect WSDL to Java mapping for anonymous

by darran.lofthouse＠jboss.com

In that case I will leave the generated classname the same as shortening it is just going to increase the chance of a naming conflict, I will just fix the generation of the jaxrpc-mapping file to match the name of the class we do generate. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978623#3978623 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978623

19 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBWS-1093 - normal servlets the web.xml is modified as i

by darran.lofthouse＠jboss.com

For Tomcat I see there are two/three different paths that can lead us to rewriting the web.xml The class TomcatServiceEndpointPublisher starts a scanning thread to periodicaly check the JBossWS deploy folder, if a new archive is found this will cause the archive to be processed and the web.xml to be rewritten. I cant get JBossWS to deploy to Tomcat at the moment to test this out but as the scanner thread is already running within Tomcat shouldn't it already have a classloader? The second/third parth is when the deployer is called from the testsuite or when it is called from the command line, in this scenario the only classloader we have is the system classloader. This classloader should still have the JBossWS classes on the classpath. The only time we really need the classloader is to load the classes of the endpoints to check if the class is annotated with @WebService. What else do you see us needing available on the classpath? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978621#3978621 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978621

19 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBWS-1133 - Exploded JSR-181 POJO Deployment Fails Redep

by darran.lofthouse＠jboss.com

Personally I prefer option 2 as well as this means for all deployments we will allways be working with a clean web.xml and it means the user never sees their web.xml modified. The downside of this approach is that for it to work 3 different products need to change. Tomcat needs to be changed so that the 'altDDName' attribute is exposed. At the moment I can access this from JBoss as: - Context ctx = (Context) server.getAttribute(objectName, "managedResource"); | ctx.setAltDDName(metaData.getAltDD()); However this is a bit of a hack and if we are going to use it it should be exposed properly. Secondly the WebMetaData class will need modifying so include an attribute to hold the name of the new web.xml so that TomcatDeployer can pass it to Tomcat. The earliest we could get this in would be for JBoss 4.0.6.GA and once in JBossWS would not be compatible with previous JBossAS versions. Having said that despite the number of projects affected this is probably the simplest to implement, just a few lines of changes in each product. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978616#3978616 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978616

19 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBWS-1133 - Exploded JSR-181 POJO Deployment Fails Redep

by jason.greene＠jboss.com

I actually like option 2 the best. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978597#3978597 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978597

19 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBWS-1093 - normal servlets the web.xml is modified as i

by jason.greene＠jboss.com

The issue with tomcat is that there isnt a classloader or even a parent clasloader available at this time in the process. Basically we need to create a classloader that follows the tomcat classpath. -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978593#3978593 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978593

19 years, 5 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 October 2006