[JBoss-dev] WebServer: howto obtain the host and port generically
Hi all, during webservice deployment the WSDL file may specify a dummy port location. When feeding back the deployed WSDL I would like to (must) tweak the port location such that it reflects the actual URL the webservice is available at. For that purpose I'm looking for a generic way to figure out what host:port the JBoss WebServer is running at. I can access the tomcat4.x extra configuration and read out: Host XPath: /Server/Service/[EMAIL PROTECTED]'MainEngine'[EMAIL PROTECTED] Port XPath: /Server/Service/Connector[position()[EMAIL PROTECTED] Obviously, this will only work for tomcat4.x and gets me the port of the first Connector - assuming this is the http connector (not ideal)! Is there a better (generic) way? Cheers -thomas --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] WebServer: howto obtain the host and port generic ally
Hi, -Ursprüngliche Nachricht- Von: Thomas Diesler (E-mail) [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 21. November 2003 10:13 An: [EMAIL PROTECTED] Betreff: [JBoss-dev] WebServer: howto obtain the host and port generically Hi all, during webservice deployment the WSDL file may specify a dummy port location. When feeding back the deployed WSDL I would like to (must) tweak the port location such that it reflects the actual URL the webservice is available at. You may want to have a look at the servlet spec/implementation. From its initialisation on, any servlet (including our jboss.net transport servlets org.jboss.net.axis.server.AxisServiceServlet and org.jboss.net.ws4ee.server.WebInvokerServlet) has access to its javax.servlet.ServletConfig and hence its javax.servlet.ServletContext which, to my knowledge, will provide these bits of information. Since AxisServiceServlet is quasi-static to the webservice deployments, registering such data centrally (like in the org.jboss.net.axis.service.AxisService indexed with a transport protocol id http or so) should not be a problem. When it comes to the WebInvokerServlets, this could be a problem of the start order since servlet.init(config) will be called after JSR109Deployer.start() ... maybe we should implement the patching lazily such that the servlets register in the ServiceImplBean upon init(), but WSDL patching is not done until all related deployments have been started and the first WSDL request is done? CGJ ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-846551 ] expn in getConneciton makes pool count wrong
Bugs item #846551, was opened at 2003-11-21 12:45
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=846551group_id=22866
Category: JBossCX
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter McConnell (waltermcconnell)
Assigned to: Nobody/Anonymous (nobody)
Summary: expn in getConneciton makes pool count wrong
Initial Comment:
Red Hat 9 (2.4.20-6)
JDK 1.4.1_02
When a ResourceException is thrown from within the
getConnection method of a ManagedConnection, the pool
count becomes wrong. This happens because while a
permit is accepted in
InternalManagedConnecitonPool.getConnection() it is
never released in the case of an error.
BaseConnectionManager2 will never call returnConnection
on the connection manager in the case that
ManagedConnection.getConnecion() fails ..
its easy to reproduce .. just add this unit test to
BaseConnectionManagerUnitTestCase ... in order to get
the test to fail you will need to temporarily get the
TestManagedConnection to throw an exception in its
getConnecion method ..
public void
testExceptionInGetConnectionLeavesPoolCountWrong()
throws Exception
{
InternalManagedConnectionPool.PoolParams pp = new
InternalManagedConnectionPool.PoolParams();
pp.minSize = 0;
pp.maxSize = 5;
pp.blockingTimeout = 100;
pp.idleTimeout = 500;
ManagedConnectionFactory mcf = new
TestManagedConnectionFactory();
ManagedConnectionPool poolingStrategy = new
JBossManagedConnectionPool.OnePool(mcf, pp, log);
BaseConnectionManager2 cm = new
NoTxConnectionManager(ccm, poolingStrategy);
try{
Object mc = cm.allocateConnection(mcf, null);
} catch(Exception thrown) {
System.err.println(Caught Exception +
thrown.toString());
}
assertTrue(Wrong number of connections counted:
+ cm.getConnectionCount(), cm.getConnectionCount() == 0);
}
the fix seems pretty trivial too ... In
BaseConnectionManager2.allocateConnection() [line 473],
just wrap the call to mc.getConnection() with a
try/catch .. if it throws a ResoruceException then tell
the pooling strategy to return the connection, killing
it. Then re-throw the exception.
BaseConnectionManager2.java [Line 491 ]
try
{
Object connection = mc.getConnection(subject, cri);
registerAssociation(mc, connection);
if (ccm != null)
{
ccm.registerConnection(this, new
ConnectionRecord(mc, connection, cri));
} // end of if ()
return connection;
} catch(ResourceException thrown)
{
poolingStrategy.returnConnection(mc, true);
throw thrown;
}
I've also attached a test rar and a web app that will
show the problem in a running JBoss server .. after
deploying the lot into the deploy directory, then keep
an eye on the AvailableConnectionCount in the
ManagedConnectionPools MBean view .. you will see it
dropping towards 0 as you refresh the
http://localhost:8080/testwar page .. this is obviously
incorrect as when it hits 0, the pool will refuse
connections and the JBoss pool manager will blow ..
cheers,
Walter McConnell.
IONA Technologies.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=846551group_id=22866
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Sharing classes between WebContainer and JSR109Deployer *was* AW: [JBoss-dev] Re: deployment classloader in AbstractWebContaine r
-Ursprüngliche Nachricht-
Von: Scott M Stark [mailto:[EMAIL PROTECTED]
Gesendet: Donnerstag, 20. November 2003 15:34
An: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Betreff: [JBoss-dev] Re: deployment classloader in
AbstractWebContainer
The deployment localCl is only for finding resources, not
classes. The classes class loader is created/assigned by the
MainDeployer after init as this may be the class loader from
an encompassing deployment (ear). Class loading should not be
occurring until create.
All right. I changed the ws4ee classloading to use the subdeployment ucl
(which is indeed
equal to the parent [EJB,WAR] ucl, see DeploymentInfo(parent,...)).
Thanks to your hint, the observed inconsistencies in the EJB case thus went
away.
However, we still have the problem that bytecode from WEB-INF/classes and
WEB-INF/lib (which is referenced in the
webservice.xml, e.g., by defining a service endpoint interface, and needs to
be loaded by JSR109Service.start(...))
- either will never find its way into the war-ucl (tomcats
useJbossClassloader=no option)
- or wont be inserted until
AbstractWebContainer.start(...)-performDeploy(...) is executed
(which comes AFTER JSR109Service.start(...) due to ws4ee being a
subdeployment to the war).
The current workaround in JSR109Service.start(...) (which I know is
certainly conflicting with the idea of allowing scoped war classloading in
general) is to simply inject these urls into the war-ucl before trying to
load bytecode:
//TODO CGJ: we need to share classes between a war and its
//webservice-subdeployment. We do that, similar to the EJB case,
//by the dis sharing the ucl. However, we need to hence extend
the
//ucl with web-inf/classes and lib at this point.
//This somehow conflicts with the notion of jboss-decoupled
//classloading for which I would propose to add another
//slot into DeploymentInfo that carries the
//final Classloader applicationClassLoader as used by the
//individual containers and that should be constructed at
//initialisation time (or is equivalent to ucl per default).
URL warURL = sdi.parent.localUrl != null ? sdi.parent.localUrl :
sdi.parent.url;
String warPath=warURL.getFile();
try{
File classesDir = new File(warPath, WEB-INF/classes);
if (classesDir.exists())
sdi.parent.ucl.addURL(classesDir.toURL());
File libDir = new File(warPath, WEB-INF/lib);
if (libDir.exists())
{
File[] jars = libDir.listFiles();
int length = jars != null ? jars.length : 0;
for (int j = 0; j length; j++)
sdi.parent.ucl.addURL(jars[j].toURL());
}
} catch(MalformedURLException e) {
throw new DeploymentException(Could not extend ws4ee
deployment ucl.,e);
}
As a better solution which bundles the knowledge about war structure in a
central place and which is consistent with the existing classloading
options, I would propose to extend DeploymentInfo with another ClassLoader
applicationLoader; which could be equal to ucl per default, but which would
be set to the actual WebCtxLoader in the Tomcat case or a similar construct
for other web containers already during AbstractWebContainer.init(...)
calling a new ConcreteWebContainer.constructWebLoader(...) method. This
applicationLoader could then be consistently used by JSR109Service to load
shared classes.
What do you think?
CGJ
###
This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
For more information, connect to http://www.F-Secure.com/
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Sharing classes between WebContainer and JSR109Deployer *was* AW: [JBoss-dev] Re: deployment classloader in AbstractWebContaine r
Its seems to me that we need to instead of having the JSR109Service
be a competely seperate deployer from the AbstractWebContainer (which
by the way needs to be broken up into a deployer + a container to
address some class override issues), that the AbstractWebContainer either
needs to incorporate the processing of the webservice.xml descriptor,
or delegate directly to the JSR109Service as part of being a j2ee1.4
web app deployer. You actually had done this in the past, why did we
decide to make them completely seperated?
Adding the war jars to the parent web service deployment is not going
to be violating scoping as the scope of the web app and web service
have to be the same. Really the bigger issues is getting better
integration with tomcat5 so that we install or obtain the web app
class loader earlier on.
--
Scott Stark
Chief Technology Officer
JBoss Group, LLC
Jung , Dr. Christoph wrote:
All right. I changed the ws4ee classloading to use the subdeployment ucl
(which is indeed
equal to the parent [EJB,WAR] ucl, see DeploymentInfo(parent,...)).
Thanks to your hint, the observed inconsistencies in the EJB case thus went
away.
However, we still have the problem that bytecode from WEB-INF/classes and
WEB-INF/lib (which is referenced in the
webservice.xml, e.g., by defining a service endpoint interface, and needs to
be loaded by JSR109Service.start(...))
- either will never find its way into the war-ucl (tomcats
useJbossClassloader=no option)
- or wont be inserted until
AbstractWebContainer.start(...)-performDeploy(...) is executed
(which comes AFTER JSR109Service.start(...) due to ws4ee being a
subdeployment to the war).
The current workaround in JSR109Service.start(...) (which I know is
certainly conflicting with the idea of allowing scoped war classloading in
general) is to simply inject these urls into the war-ucl before trying to
load bytecode:
//TODO CGJ: we need to share classes between a war and its
//webservice-subdeployment. We do that, similar to the EJB case,
//by the dis sharing the ucl. However, we need to hence extend
the
//ucl with web-inf/classes and lib at this point.
//This somehow conflicts with the notion of jboss-decoupled
//classloading for which I would propose to add another
//slot into DeploymentInfo that carries the
//final Classloader applicationClassLoader as used by the
//individual containers and that should be constructed at
//initialisation time (or is equivalent to ucl per default).
URL warURL = sdi.parent.localUrl != null ? sdi.parent.localUrl :
sdi.parent.url;
String warPath=warURL.getFile();
try{
File classesDir = new File(warPath, WEB-INF/classes);
if (classesDir.exists())
sdi.parent.ucl.addURL(classesDir.toURL());
File libDir = new File(warPath, WEB-INF/lib);
if (libDir.exists())
{
File[] jars = libDir.listFiles();
int length = jars != null ? jars.length : 0;
for (int j = 0; j length; j++)
sdi.parent.ucl.addURL(jars[j].toURL());
}
} catch(MalformedURLException e) {
throw new DeploymentException(Could not extend ws4ee
deployment ucl.,e);
}
As a better solution which bundles the knowledge about war structure in a
central place and which is consistent with the existing classloading
options, I would propose to extend DeploymentInfo with another ClassLoader
applicationLoader; which could be equal to ucl per default, but which would
be set to the actual WebCtxLoader in the Tomcat case or a similar construct
for other web containers already during AbstractWebContainer.init(...)
calling a new ConcreteWebContainer.constructWebLoader(...) method. This
applicationLoader could then be consistently used by JSR109Service to load
shared classes.
What do you think?
CGJ
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Boost Your Car's Gas Mileage 27%+.....jag
FUEL SAVER PRO This revolutionary device Boosts Gas Mileage 27%+ by helping fuel burn better using three patented processes from General Motors. www.bb4n.org/?axel=49 PROVEN TECHNOLOGY A certified U.S. Environmental Protection Agency (EPA) laboratory recently completed tests on the new Fuel Saver. The results were astounding! Master Service, a subsidiary of Ford Motor Company, also conducted extensive emissions testing and obtained similar, unheard of results. The achievements of the Fuel Saver is so noteworthy to the environmental community, that Commercial News has featured it as their cover story in their June, 2000 edition. Take a test drive Today - www.bb4n.org/?axel=49 No more advertisements, thanks - http://www.aqmp.net/out5s/rem2e.asp flxuhvjlf d
[JBoss-dev] STOP-PAYING For Your PAY-PER-VIEW, Movie Channels, Mature Channels...isoke
Cable TV Subscribers Get Our Cable TV Filter and Stop-Paying For Your Pay-Per-View, Mature Channels, Movie Channels, Sporting Events... Find Out More - www.esavingsplus.com?refid=1001859429816 Don't worry, it's perfectly-legal. Check out our legal page on the site: www.esavingsplus.com?refid=1001859429816 No more advertisments - http://www.esavingsplus.com?unsub=1001859429816 wxz tdzwrj c yqeaopbo qf szey b
[JBoss-dev] Lig'in tum heyecanini bizimle yasayin!!!
Title: Lig'in tum heyecanini bizimle yasayin!! Bizden mail almak istemiyorsanz lutfen buraya tklaynz.
