[JBoss-dev] AW: jboss 4 build system changes, possible jboss.net and catalinaimpact.
David, Thanks for the notice. Unfortunately, I have no exact idea about the differences of the jboss-xdoclet and the version that Frederick was getting by the xdoclet guys (must have been something between 1.1 and 1.2 with some bugs fixed?). Frederick, could you please synchronize with David on the global xdoclet version? AFAIK, xdoclet only affects the flash sample and not the testsuite (which did run fine with Jetty on Monday, so I´ll test it again). I guess that we won´t backport the build changes to 3.2? I´m going to migrate the latest jboss.net status into 3.2 this week, so I´d have to be a bit careful about what to sync and what not ... Do you have any cvs tricks for back-integration? I´m very used to the comfortable perforce integration feature, but I guess that I need to compare the absolute branches with diff here, right? CGJ -Ursprüngliche Nachricht- Von: David Jencks [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 11. September 2002 00:15 An: Jung Christoph; jboss-dev Cc: Bruce Scharlau Betreff: jboss 4 build system changes, possible jboss.net and catalina impact. I replaced many of the repetitive elements in the build.xml files with parameter entities, including the definition of xdoclet tasks. As far as I can tell this hasn't affected anything according to the testsuite. However, one effect is that xdoclet is now always the global xdoclet in thirdparty. Previously it looks like a local version was being used in jboss.net. I don't know if there are any tests of jboss.net: the module appears to compile fine. If this has broken something let me know. I'd prefer to fix it in xdoclet if possible since the xdoclet 1.2 release is imminent. I also don't know if the catalina module still works and don't know how to test it. I only partially converted that build.xml, leaving the previous definitions commented out. Again, info appreciated. thanks david jencks ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: AW: [JBoss-dev] JBoss.net now supports Axis RC1 - update
Bruce,
Thanks for the hint. IMHO, the whole stuff should deploy packed as well as
unpacked. I will have a look
at the Catalina/unpacked variant when I have some spare time this afternoon.
CGJ
-Ursprüngliche Nachricht-
Von: Bruce Scharlau [mailto:[EMAIL PROTECTED]]
Gesendet: Dienstag, 10. September 2002 17:37
An: [EMAIL PROTECTED]
Betreff: Re: AW: [JBoss-dev] JBoss.net now supports Axis RC1 - update
At 14:18 10/09/2002 +0200, you wrote:
Bruce,
That is strange. Could you please try to debug the exact Null variable
that causes the Exception. In EmbeddedCatalinaServiceSX, it says:
private void createWebContext(final WebApplication appInfo, URL warUrl,
final WebDescriptorParser webAppParser) throws Exception
{
ClassLoader loader = Thread.currentThread().getContextClassLoader();
WebMetaData metaData = appInfo.getMetaData();
String ctxPath = metaData.getContextRoot();
appInfo.setName(warUrl.getPath());
appInfo.setClassLoader(loader);
appInfo.setURL(warUrl);
final StandardContext context = (StandardContext)
catalina.createContext(ctxPath, warUrl.getFile());
The last line being the exception-raising 354 one after my count. If
warUrl would be null, then it should already crash at 351, shouldn´t
it? If catalina would be null, my guess is that the whole service would
be flawed ... Can you get any other web application to run under
catalina? What about the management-console?
It would be a tremendous help if you could find out what jboss-net.war
in sar makes different to other services (and IMHO it should work with
the compressed version, too, maybe you need to compress both the
war/wsr ingredients and the jboss-net.sar?
Puzzled,
CGJ
Christoph,
just tried the jboss-net.ear deployed in jboss-jetty and it works fine. I
can get the adminService wsdl file no problem, and noted a typo in the
web.xml file. You have
servlet-mapping
servlet-nameJBossAxisAdminServlet/servlet-name
url-pattern/servlet/AxisAdminServlet/url-pattern
/servlet-mapping
but the index.hmtl page for the admin looks to: servlet/AdminServlet
Anyways, this works under jetty, but NOT tomcat/catalina
I gotta go now, but will pursue this some more tomorrow.
cheers,
Bruce
Dr. Bruce Scharlau
Dept. of Computing Science
University of Aberdeen
Aberdeen AB24 3UE
01224 272193
http://www.csd.abdn.ac.uk/~bscharla
mailto:[EMAIL PROTECTED]
---
This sf.net email is sponsored by: OSDN - Tired of that same old cell phone?
Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390
___
Jboss-development mailing list [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
###
This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
For more information, connect to http://www.F-Secure.com/
---
In remembrance
www.osdn.com/911/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-607684 ] jboss.net fails to deploy on catalina
Bugs item #607684, was opened at 2002-09-11 09:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=607684group_id=22866 Category: JBossSOAP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Dr. Christoph Georg Jung (cgjung) Assigned to: Dr. Christoph Georg Jung (cgjung) Summary: jboss.net fails to deploy on catalina Initial Comment: Actually, there are two symptoms. One is appearing in head and has to do with exploded deployment leading to nullpointers in EmbeddedCatalinaService. The other one is in 3.0.1 release and seems to hint to a wrong servlet mapping. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=607684group_id=22866 --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] WG: thirdParty mess at head? *Was* AW: JBoss.net compilation fails on HEAD
-Ursprüngliche Nachricht-
Von: Jung , Dr. Christoph
Gesendet: Mittwoch, 11. September 2002 09:49
An: 'Juha-P Lindfors'
Cc: '[EMAIL PROTECTED]'
Betreff: thirdParty mess at head? *Was* AW: JBoss.net compilation fails on
HEAD
Juha, others
I cannot get head to compile at various points: management, jetty, ...
Maybe we should try a complete checkout again?
Most modules seem to have problem with thirdparty references, methinks? I
have no idea what would be the best order to resolve that mess.
Btw. Why are there two crimson.jar (one in apache, one in sun/jaxp, the
latter being the one that is more complete IMHO) in thirdparty?
CGJ
-Ursprüngliche Nachricht-
Von: Juha-P Lindfors [mailto:[EMAIL PROTECTED]]
Gesendet: Mittwoch, 11. September 2002 09:00
An: Jung , Dr. Christoph
Betreff: JBoss.net compilation fails on HEAD
Just tried to pull and compile CVS head but it fails for me.
Are you working on something, did I just get a bad checkout?
compile-classes:
[mkdir] Created dir: D:\jboss-all\jboss.net\output\classes\main
[javac] Compiling 56 source files to
D:\jboss-all\jboss.net\output\classes\main
D:\jboss-all\jboss.net\src\main\org\jboss\net\axis\server\AxisAdminServlet.j
ava:23:
cannot
access javax.servlet.http.HttpServlet
file javax\servlet\http\HttpServlet.class not found
protected AxisServer server=null;
^
D:\jboss-all\jboss.net\src\main\org\jboss\net\axis\server\FlashAxisServiceSe
rvlet.java:12:
package javax.servlet does not exist
import javax.servlet.ServletException;
^
D:\jboss-all\jboss.net\src\main\org\jboss\net\axis\server\FlashAxisServiceSe
rvlet.java:13:
package javax.servlet.http does not exist
import javax.servlet.http.HttpServletRequest;
^
D:\jboss-all\jboss.net\src\main\org\jboss\net\axis\server\FlashAxisServiceSe
rvlet.java:14:
package javax.servlet.http does not exist
import javax.servlet.http.HttpServletResponse;
^
D:\jboss-all\jboss.net\src\main\org\jboss\net\axis\server\FlashAxisServiceSe
rvlet.java:15:
package javax.servlet.http does not exist
import javax.servlet.http.HttpServletRequestWrapper;
^
D:\jboss-all\jboss.net\src\main\org\jboss\net\axis\server\FlashAxisServiceSe
rvlet.java:152
: cannot resolve symbol
symbol : class HttpServletRequest
location: class org.jboss.net.axis.server.FlashAxisServiceServlet
public void doPost(HttpServletRequest req, HttpServletResponse
res)
^
D:\jboss-all\jboss.net\src\main\org\jboss\net\axis\server\FlashAxisServiceSe
rvlet.java:152
: cannot resolve symbol
symbol : class HttpServletResponse
location: class org.jboss.net.axis.server.FlashAxisServiceServlet
public void doPost(HttpServletRequest req, HttpServletResponse
res)
^
D:\jboss-all\jboss.net\src\main\org\jboss\net\axis\server\FlashAxisServiceSe
rvlet.java:153
: cannot resolve symbol
symbol : class ServletException
location: class org.jboss.net.axis.server.FlashAxisServiceServlet
throws ServletException, IOException {
^
D:\jboss-all\jboss.net\src\main\org\jboss\net\axis\server\FlashAxisServiceSe
rvlet.java:58:
cannot resolve symbol
symbol : class HttpServletRequestWrapper
location: class
org.jboss.net.axis.server.FlashAxisServiceServlet.FilteredHttpServletReque
st
public class FilteredHttpServletRequest extends
HttpServletRequestWrapper {
^
D:\jboss-all\jboss.net\src\main\org\jboss\net\axis\server\FlashAxisServiceSe
rvlet.java:70:
cannot resolve symbol
symbol : class HttpServletRequest
location: class
org.jboss.net.axis.server.FlashAxisServiceServlet.FilteredHttpServletReque
st
public FilteredHttpServletRequest(HttpServletRequest req)
^
D:\jboss-all\jboss.net\src\main\org\jboss\net\axis\ServiceFactory.java:15:
warning: org.ap ache.axis.configuration.DefaultEngineConfigurationFactory in
org.apache.axis.configuration has been deprecated import
org.apache.axis.configuration.DefaultEngineConfigurationFactory;
^
D:\jboss-all\jboss.net\src\main\org\jboss\net\taglib\FlashParametersTag.java
:18:
package j
avax.servlet.jsp.tagext does not exist
import javax.servlet.jsp.tagext.TagSupport;
^
D:\jboss-all\jboss.net\src\main\org\jboss\net\taglib\FlashParametersTag.java
:19:
package j
avax.servlet.jsp does not exist
import javax.servlet.jsp.JspTagException;
^
D:\jboss-all\jboss.net\src\main\org\jboss\net\taglib\FlashParametersTag.java
:20:
package j
avax.servlet.jsp does not exist
import javax.servlet.jsp.JspWriter;
^
D:\jboss-all\jboss.net\src\main\org\jboss\net\taglib\FlashParametersTag.java
:64:
cannot re
solve symbol
symbol : class TagSupport
location: class
[JBoss-dev] [ jboss-Bugs-594137 ] SOAPAction not set
Bugs item #594137, was opened at 2002-08-12 19:13
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=594137group_id=22866
Category: JBossSOAP
Group: v3.0 Rabbit Hole
Status: Open
Resolution: Remind
Priority: 5
Submitted By: Marius Kotsbak (mkotsbak)
Assigned to: Dr. Christoph Georg Jung (cgjung)
Summary: SOAPAction not set
Initial Comment:
The auto-generated wsdl-file is missing soapAction,
whch should be th e same as wsdl:operation name.
This is neccesary for M$ Soap toolkit to work, and
maybe other SOAP implementations like for perl.
wsdl:operation name=insertPerson HERE - V
***HERE-*** wsdlsoap:operation soapAction=/
wsdl:input
wsdlsoap:body use=encoded
encodingStyle=http://schemas.xmlsoap.org/soap/encoding/;
namespace=xxx/
/wsdl:input
wsdl:output
wsdlsoap:body use=encoded
encodingStyle=http://schemas.xmlsoap.org/soap/encoding/;
namespace=xxx/
/wsdl:output
/wsdl:operation
--
Comment By: Marius Kotsbak (mkotsbak)
Date: 2002-09-11 10:30
Message:
Logged In: YES
user_id=366650
Here is the error when using the wsdl-file directly with
empty soapAction from MS Soap toolkit:
SOAP-ENV:Envelope
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/;
SOAP-ENV:Body
SOAP-ENV:Fault
faultcode
xmlns:ns1=http://xml.apache.org/axis/;ns1:Client.NoSOAPAction/faultcode
faultstringno SOAPAction header!/faultstring
detail
ns2:stackTrace
xmlns:ns2=http://xml.apache.org/axis/;no SOAPAction header!
at
org.apache.axis.transport.http.AxisServlet.doPost(AxisServlet.java:509)
at
javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at
javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:344)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:313)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:554)
at
org.mortbay.jetty.servlet.WebApplicationHandler.handle(WebApplicationHandler.java:199)
at
org.mortbay.http.HttpContext.handle(HttpContext.java:1572)
at
org.mortbay.http.HttpContext.handle(HttpContext.java:1522)
at
org.mortbay.http.HttpServer.service(HttpServer.java:795)
at org.jboss.jetty.Jetty.service(Jetty.java:531)
at
org.mortbay.http.HttpConnection.service(HttpConnection.java:784)
at
org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:941)
at
org.mortbay.http.HttpConnection.handle(HttpConnection.java:799)
at
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:186)
at
org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:322)
at
org.mortbay.util.ThreadPool$JobRunner.run(ThreadPool.java:713)
at java.lang.Thread.run(Thread.java:536)
/ns2:stackTrace
/detail
/SOAP-ENV:Fault
/SOAP-ENV:Body
/SOAP-ENV:Envelope)
I will send a question about this to the axis-list with
reference to this bug
--
Comment By: Dr. Christoph Georg Jung (cgjung)
Date: 2002-09-09 12:25
Message:
Logged In: YES
user_id=175199
I looked again at the Axis Emitter code and there is the
following line in writeBindingOperation:
// If the soapAction option is OPERATION, force
// soapAction to the name of the operation. If NONE,
// force soapAction to .
// Otherwise use the information in the operationDesc.
String soapAction = ;
if (getSoapAction().equals(OPERATION)) {
soapAction = oper.getName();
} else if (getSoapAction().equals(NONE)) {
soapAction = ;
} else {
soapAction = desc.getSoapAction();
if (soapAction == null) {
soapAction = ;
}
}
I guess it should not be up to the provider meta-data (the
adapter code that ties Axis to various target services, such
as EJB, MBean and the like) but up to the invocation chain
(i.e., whether there is an HTTPActionHandler) to set the
emitter to mode Operation or whatelse. I find the Axis meta-
data interface sometimes very obscure anyway.
You could report it to Axis, but since SOAP1.2 SOAPAction
is no more mandatory as I understand. I´m not sure whether
this will give you any satisfactory answer.
What about the following: You will get the possibility to
subclass jboss.net.axis.server.EJBProvider in order to set the
emitter to mode operation?
--
Comment By: Marius Kotsbak (mkotsbak)
Date: 2002-09-09 09:45
Message:
Logged In: YES
user_id=366650
Which provider do you refer to?
Provider? I use MS soap toolkit on the client side.
If this is a bug, then it would be an Axis bug, because we
fully rely on, e.g., the EJBProvider and
[JBoss-dev] [ jboss-Bugs-594137 ] SOAPAction not set
Bugs item #594137, was opened at 2002-08-12 19:13
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=594137group_id=22866
Category: JBossSOAP
Group: v3.0 Rabbit Hole
Status: Open
Resolution: Remind
Priority: 5
Submitted By: Marius Kotsbak (mkotsbak)
Assigned to: Dr. Christoph Georg Jung (cgjung)
Summary: SOAPAction not set
Initial Comment:
The auto-generated wsdl-file is missing soapAction,
whch should be th e same as wsdl:operation name.
This is neccesary for M$ Soap toolkit to work, and
maybe other SOAP implementations like for perl.
wsdl:operation name=insertPerson HERE - V
***HERE-*** wsdlsoap:operation soapAction=/
wsdl:input
wsdlsoap:body use=encoded
encodingStyle=http://schemas.xmlsoap.org/soap/encoding/;
namespace=xxx/
/wsdl:input
wsdl:output
wsdlsoap:body use=encoded
encodingStyle=http://schemas.xmlsoap.org/soap/encoding/;
namespace=xxx/
/wsdl:output
/wsdl:operation
--
Comment By: Dr. Christoph Georg Jung (cgjung)
Date: 2002-09-11 10:46
Message:
Logged In: YES
user_id=175199
Now, here we are. That´s a bug in the MS-SOap Toolkit, if
you ask me:
From AxisServlet:
private String getSoapAction(HttpServletRequest req)
throws AxisFault
{
String soapAction =(String)req.getHeader
(HTTPConstants.HEADER_SOAP_ACTION);
if (soapAction == null) {
AxisFault af = new AxisFault(Client.NoSOAPAction,
JavaUtils.getMessage
(noHeader00,
SOAPAction),
null, null);
}
Which means that the call will fault when there is no such
soapAction header. It will not fault (and be further processed),
if your soapAction header is (and that is what the
generated wsdl is saying, if you ask me).
--
Comment By: Marius Kotsbak (mkotsbak)
Date: 2002-09-11 10:30
Message:
Logged In: YES
user_id=366650
Here is the error when using the wsdl-file directly with
empty soapAction from MS Soap toolkit:
SOAP-ENV:Envelope
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/;
SOAP-ENV:Body
SOAP-ENV:Fault
faultcode
xmlns:ns1=http://xml.apache.org/axis/;ns1:Client.NoSOAPAction/faultcode
faultstringno SOAPAction header!/faultstring
detail
ns2:stackTrace
xmlns:ns2=http://xml.apache.org/axis/;no SOAPAction header!
at
org.apache.axis.transport.http.AxisServlet.doPost(AxisServlet.java:509)
at
javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at
javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:344)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:313)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:554)
at
org.mortbay.jetty.servlet.WebApplicationHandler.handle(WebApplicationHandler.java:199)
at
org.mortbay.http.HttpContext.handle(HttpContext.java:1572)
at
org.mortbay.http.HttpContext.handle(HttpContext.java:1522)
at
org.mortbay.http.HttpServer.service(HttpServer.java:795)
at org.jboss.jetty.Jetty.service(Jetty.java:531)
at
org.mortbay.http.HttpConnection.service(HttpConnection.java:784)
at
org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:941)
at
org.mortbay.http.HttpConnection.handle(HttpConnection.java:799)
at
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:186)
at
org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:322)
at
org.mortbay.util.ThreadPool$JobRunner.run(ThreadPool.java:713)
at java.lang.Thread.run(Thread.java:536)
/ns2:stackTrace
/detail
/SOAP-ENV:Fault
/SOAP-ENV:Body
/SOAP-ENV:Envelope)
I will send a question about this to the axis-list with
reference to this bug
--
Comment By: Dr. Christoph Georg Jung (cgjung)
Date: 2002-09-09 12:25
Message:
Logged In: YES
user_id=175199
I looked again at the Axis Emitter code and there is the
following line in writeBindingOperation:
// If the soapAction option is OPERATION, force
// soapAction to the name of the operation. If NONE,
// force soapAction to .
// Otherwise use the information in the operationDesc.
String soapAction = ;
if (getSoapAction().equals(OPERATION)) {
soapAction = oper.getName();
} else if (getSoapAction().equals(NONE)) {
soapAction = ;
} else {
soapAction = desc.getSoapAction();
if (soapAction == null) {
soapAction = ;
}
}
I guess it should not be up to
[JBoss-dev] [ jboss-Bugs-607721 ] Incomplete JMS Message Serialization
Bugs item #607721, was opened at 2002-09-11 11:33
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=607721group_id=22866
Category: JBossMQ
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Ulf Schroeter (schrouf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incomplete JMS Message Serialization
Initial Comment:
Object serialization of class org.jboss.mq.SpyMessage
does not serialize attribute
SpyMessage.header.durableSubscriberID in
read/writeExternal().
Proposed code fixed:
writeExternal(...)
{
...
...
if( header.durableSubscriberID != null )
{
out.writeBoolean( true );
writeString( out, header.durableSubscriberID.clientID );
writeString( out,
header.durableSubscriberID.subscriptionName );
writeString( out, header.durableSubscriberID.selector );
}
else
{
out.writeBoolean( false );
}
...
}
readExternal(...)
{
...
...
boolean durable = in.readBoolean();
if( durable )
{
String clientID = readString( in );
String subscriptionName = readString( in );
String selector = readString( in );
header.durableSubscriberID = new DurableSubscriberID(
clientID, subscriptionName, selector );
}
else
{
header.durableSubscriberID = null;
}
...
}
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=607721group_id=22866
---
In remembrance
www.osdn.com/911/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-604085 ] Jetty is not deploying packedwars
Jules Gosnell wrote: This is most likely the same as the spaces within paths issue. Because the war is packed, it is unpacked to a temporary dir, which has spaces in it. Greg is looking at it. No I'm not! I've had a total windows failure and after spending hours rebuilding that damn thing - applying service pack 3 rendered the thing unbootable again. I've had one user send me some detailed trace on it, and I'm currently suspecting something about classloading can't handle %20 in file URLs. But without a system I can't test. Jan has tried to reproduce the problem on her, but spaces in filenames are working without problem on straight jetty. So I need verbose debug traces from users with failures -- PLEASE. I'm trying to put a windows dev system back together today... cheers Jules [EMAIL PROTECTED] wrote: Bugs item #604085, was opened at 2002-09-03 10:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=604085group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Scott M Stark (starksm) Assigned to: Nobody/Anonymous (nobody) Summary: Jetty is not deploying packed wars Initial Comment: I am seeing a problem with Jetty not deploying wars from the deploy directory in the current 3.0 and 3.2 branches. If you take the default/deploy/jmx-console.war and repack this: deploy 414ls -l jmx-console.war -rw-r--r--1 starksm None58165 Sep 3 13:17 jmx-console.war deploy 415jar -tf jmx-console.war META-INF/ META-INF/MANIFEST.MF WEB-INF/ WEB-INF/classes/ WEB-INF/classes/org/ WEB-INF/classes/org/jboss/ WEB-INF/classes/org/jboss/jmx/ WEB-INF/classes/org/jboss/jmx/adaptor/ WEB-INF/classes/org/jboss/jmx/adaptor/control/ WEB- INF/classes/org/jboss/jmx/adaptor/control/AttrResultInfo. class WEB- INF/classes/org/jboss/jmx/adaptor/control/OpResultInfo. class WEB- INF/classes/org/jboss/jmx/adaptor/control/Server.class WEB-INF/classes/org/jboss/jmx/adaptor/html/ WEB- INF/classes/org/jboss/jmx/adaptor/html/HtmlAdaptorServ let.class WEB-INF/classes/org/jboss/jmx/adaptor/model/ WEB- INF/classes/org/jboss/jmx/adaptor/model/DomainData.cl ass WEB- INF/classes/org/jboss/jmx/adaptor/model/MBeanData.cl ass WEB-INF/classes/roles.properties WEB-INF/classes/users.properties WEB-INF/web.xml displayMBeans.jsp displayOpResult.jsp images/ images/head_blue.gif index.jsp inspectMBean.jsp style_master.css Startup the default config and although Jetty says the war was deployed: 13:18:20,769 INFO [MainDeployer] Starting deployment of package: file:/C:/usr/J Boss3.2/jboss-all/build/output/jboss- 3.2.0RC1/server/default/deploy/jmx-console. war 13:18:21,340 INFO [jbossweb] Registered jboss.web:Jetty=0,JBossWebApplicationCo ntext=0,context=/jmx-console 13:18:21,390 INFO [jbossweb] Checking Resource aliases 13:18:21,490 INFO [jbossweb] Extract jar:file:/C:/usr/JBoss3.2/jboss-all/build/ output/jboss- 3.2.0RC1/server/default/tmp/deploy/server/default/deploy/ jmx-consol e.war/61.jmx-console.war!/ to C:\DOCUME~1 \starksm\LOCALS~1\Temp\Jetty_0_0_0_0_80 80__jmx-console\webapp 13:18:22,312 INFO [jbossweb] Started WebApplicationContext[/jmx-console,jar:fil e:/C:/usr/JBoss3.2/jboss-all/build/output/jboss- 3.2.0RC1/server/default/tmp/depl oy/server/default/deploy/jmx-console.war/61.jmx- console.war!/] 13:18:22,392 INFO [jbossweb] successfully deployed file:/C:/usr/JBoss3.2/jboss- all/build/output/jboss- 3.2.0RC1/server/default/tmp/deploy/server/default/deploy/ jmx-console.war/61.jmx-console.war to /jmx-console 13:18:22,392 INFO [MainDeployer] Deployed package: file:/C:/usr/JBoss3.2/jboss- all/build/output/jboss-3.2.0RC1/server/default/deploy/jmx- console.war 13:18:22,402 INFO [URLDeploymentScanner] Started It is in fact not accessible: security 409wget http://localhost:8080/jmx-console --13:21:08-- http://localhost:8080/jmx-console = `jmx-console' Resolving localhost... done. Connecting to localhost[127.0.0.1]:8080... connected. HTTP request sent, awaiting response... 302 Moved Temporarily Location: http://localhost:8080/jmx-console/ [following] --13:21:08-- http://localhost:8080/jmx-console/ = `index.html' Connecting to localhost[127.0.0.1]:8080... connected. HTTP request sent, awaiting response... 404 /jmx- console/ Not Found 13:21:08 ERROR 404: /jmx-console/ Not Found. If the jmx-console.war is unpacked then the content is accessible: security 410wget http://localhost:8080/jmx-console --13:25:25-- http://localhost:8080/jmx-console = `jmx-console' Resolving localhost... done. Connecting to localhost[127.0.0.1]:8080... connected. HTTP request sent, awaiting response... 302 Moved Temporarily Location: http://localhost:8080/jmx-console/ [following] --13:25:25-- http://localhost:8080/jmx-console/ = `index.html' Connecting to
[JBoss-dev] [ jboss-Bugs-594137 ] SOAPAction not set
Bugs item #594137, was opened at 2002-08-12 19:13
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=594137group_id=22866
Category: JBossSOAP
Group: v3.0 Rabbit Hole
Status: Open
Resolution: Remind
Priority: 5
Submitted By: Marius Kotsbak (mkotsbak)
Assigned to: Dr. Christoph Georg Jung (cgjung)
Summary: SOAPAction not set
Initial Comment:
The auto-generated wsdl-file is missing soapAction,
whch should be th e same as wsdl:operation name.
This is neccesary for M$ Soap toolkit to work, and
maybe other SOAP implementations like for perl.
wsdl:operation name=insertPerson HERE - V
***HERE-*** wsdlsoap:operation soapAction=/
wsdl:input
wsdlsoap:body use=encoded
encodingStyle=http://schemas.xmlsoap.org/soap/encoding/;
namespace=xxx/
/wsdl:input
wsdl:output
wsdlsoap:body use=encoded
encodingStyle=http://schemas.xmlsoap.org/soap/encoding/;
namespace=xxx/
/wsdl:output
/wsdl:operation
--
Comment By: Marius Kotsbak (mkotsbak)
Date: 2002-09-11 12:03
Message:
Logged In: YES
user_id=366650
OK. I can try with the new version 3.0 of the soap toolkit
first.
--
Comment By: Dr. Christoph Georg Jung (cgjung)
Date: 2002-09-11 10:46
Message:
Logged In: YES
user_id=175199
Now, here we are. That´s a bug in the MS-SOap Toolkit, if
you ask me:
From AxisServlet:
private String getSoapAction(HttpServletRequest req)
throws AxisFault
{
String soapAction =(String)req.getHeader
(HTTPConstants.HEADER_SOAP_ACTION);
if (soapAction == null) {
AxisFault af = new AxisFault(Client.NoSOAPAction,
JavaUtils.getMessage
(noHeader00,
SOAPAction),
null, null);
}
Which means that the call will fault when there is no such
soapAction header. It will not fault (and be further processed),
if your soapAction header is (and that is what the
generated wsdl is saying, if you ask me).
--
Comment By: Marius Kotsbak (mkotsbak)
Date: 2002-09-11 10:30
Message:
Logged In: YES
user_id=366650
Here is the error when using the wsdl-file directly with
empty soapAction from MS Soap toolkit:
SOAP-ENV:Envelope
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/;
SOAP-ENV:Body
SOAP-ENV:Fault
faultcode
xmlns:ns1=http://xml.apache.org/axis/;ns1:Client.NoSOAPAction/faultcode
faultstringno SOAPAction header!/faultstring
detail
ns2:stackTrace
xmlns:ns2=http://xml.apache.org/axis/;no SOAPAction header!
at
org.apache.axis.transport.http.AxisServlet.doPost(AxisServlet.java:509)
at
javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at
javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:344)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:313)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:554)
at
org.mortbay.jetty.servlet.WebApplicationHandler.handle(WebApplicationHandler.java:199)
at
org.mortbay.http.HttpContext.handle(HttpContext.java:1572)
at
org.mortbay.http.HttpContext.handle(HttpContext.java:1522)
at
org.mortbay.http.HttpServer.service(HttpServer.java:795)
at org.jboss.jetty.Jetty.service(Jetty.java:531)
at
org.mortbay.http.HttpConnection.service(HttpConnection.java:784)
at
org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:941)
at
org.mortbay.http.HttpConnection.handle(HttpConnection.java:799)
at
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:186)
at
org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:322)
at
org.mortbay.util.ThreadPool$JobRunner.run(ThreadPool.java:713)
at java.lang.Thread.run(Thread.java:536)
/ns2:stackTrace
/detail
/SOAP-ENV:Fault
/SOAP-ENV:Body
/SOAP-ENV:Envelope)
I will send a question about this to the axis-list with
reference to this bug
--
Comment By: Dr. Christoph Georg Jung (cgjung)
Date: 2002-09-09 12:25
Message:
Logged In: YES
user_id=175199
I looked again at the Axis Emitter code and there is the
following line in writeBindingOperation:
// If the soapAction option is OPERATION, force
// soapAction to the name of the operation. If NONE,
// force soapAction to .
// Otherwise use the information in the operationDesc.
String soapAction = ;
if (getSoapAction().equals(OPERATION)) {
soapAction = oper.getName();
} else if
[JBoss-dev] [ jboss-Feature Requests-607761 ] On-line availability of DTDs
Feature Requests item #607761, was opened at 2002-09-11 13:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376688aid=607761group_id=22866 Category: JBossCMP Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Randahl Fink Isaksen (randahl) Assigned to: Nobody/Anonymous (nobody) Summary: On-line availability of DTDs Initial Comment: I would like the HTTP address in the following doctype to be the actual on-line address of the downloadable DTD: !DOCTYPE jbosscmp-jdbc PUBLIC -//JBoss//DTD JBOSSCMP-JDBC 3.0//EN http://www.jboss.org/j2ee/dtd/jbosscmp- jdbc_3_0.dtd At the time of this writing the address did not work, and because of this XML validation using the HTTP address of the DOCTYPE was not possible. I recommend you make the DTD available at the mentioned HTTP address so developers wont have to change the doctype to something like the following in order to make validation possible: !DOCTYPE jbosscmp-jdbc PUBLIC '-//JBoss//DTD JBOSSCMP-JDBC 3.0//EN' 'file://C:/jboss- 3.0.2/docs/dtd/jbosscmp-jdbc_3_0.dtd' IDEs like NetBeans are capable of using the HTTP address for validation. Randahl -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376688aid=607761group_id=22866 --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [ jboss-Bugs-604085 ] Jetty is not deploying packed wars
I'm more then happy to help in whatever way I can. I sent Jules the server logs from JBoss, but I suspect those weren't helpful being that from JBoss's perspective, there didn't appear to be any deployment errors generated. Let me know what else I can do to help you get what information you need to fix the problem. Dustin Barlow -Original Message- From: Greg Wilkins [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 11, 2002 5:43 AM To: Jules Gosnell Cc: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] [ jboss-Bugs-604085 ] Jetty is not deploying packed wars Jules Gosnell wrote: This is most likely the same as the spaces within paths issue. Because the war is packed, it is unpacked to a temporary dir, which has spaces in it. Greg is looking at it. No I'm not! I've had a total windows failure and after spending hours rebuilding that damn thing - applying service pack 3 rendered the thing unbootable again. I've had one user send me some detailed trace on it, and I'm currently suspecting something about classloading can't handle %20 in file URLs. But without a system I can't test. Jan has tried to reproduce the problem on her, but spaces in filenames are working without problem on straight jetty. So I need verbose debug traces from users with failures -- PLEASE. I'm trying to put a windows dev system back together today... cheers Jules [EMAIL PROTECTED] wrote: Bugs item #604085, was opened at 2002-09-03 10:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=604085group_id =22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Scott M Stark (starksm) Assigned to: Nobody/Anonymous (nobody) Summary: Jetty is not deploying packed wars Initial Comment: I am seeing a problem with Jetty not deploying wars from the deploy directory in the current 3.0 and 3.2 branches. If you take the default/deploy/jmx-console.war and repack this: deploy 414ls -l jmx-console.war -rw-r--r--1 starksm None58165 Sep 3 13:17 jmx-console.war deploy 415jar -tf jmx-console.war META-INF/ META-INF/MANIFEST.MF WEB-INF/ WEB-INF/classes/ WEB-INF/classes/org/ WEB-INF/classes/org/jboss/ WEB-INF/classes/org/jboss/jmx/ WEB-INF/classes/org/jboss/jmx/adaptor/ WEB-INF/classes/org/jboss/jmx/adaptor/control/ WEB- INF/classes/org/jboss/jmx/adaptor/control/AttrResultInfo. class WEB- INF/classes/org/jboss/jmx/adaptor/control/OpResultInfo. class WEB- INF/classes/org/jboss/jmx/adaptor/control/Server.class WEB-INF/classes/org/jboss/jmx/adaptor/html/ WEB- INF/classes/org/jboss/jmx/adaptor/html/HtmlAdaptorServ let.class WEB-INF/classes/org/jboss/jmx/adaptor/model/ WEB- INF/classes/org/jboss/jmx/adaptor/model/DomainData.cl ass WEB- INF/classes/org/jboss/jmx/adaptor/model/MBeanData.cl ass WEB-INF/classes/roles.properties WEB-INF/classes/users.properties WEB-INF/web.xml displayMBeans.jsp displayOpResult.jsp images/ images/head_blue.gif index.jsp inspectMBean.jsp style_master.css Startup the default config and although Jetty says the war was deployed: 13:18:20,769 INFO [MainDeployer] Starting deployment of package: file:/C:/usr/J Boss3.2/jboss-all/build/output/jboss- 3.2.0RC1/server/default/deploy/jmx-console. war 13:18:21,340 INFO [jbossweb] Registered jboss.web:Jetty=0,JBossWebApplicationCo ntext=0,context=/jmx-console 13:18:21,390 INFO [jbossweb] Checking Resource aliases 13:18:21,490 INFO [jbossweb] Extract jar:file:/C:/usr/JBoss3.2/jboss-all/build/ output/jboss- 3.2.0RC1/server/default/tmp/deploy/server/default/deploy/ jmx-consol e.war/61.jmx-console.war!/ to C:\DOCUME~1 \starksm\LOCALS~1\Temp\Jetty_0_0_0_0_80 80__jmx-console\webapp 13:18:22,312 INFO [jbossweb] Started WebApplicationContext[/jmx-console,jar:fil e:/C:/usr/JBoss3.2/jboss-all/build/output/jboss- 3.2.0RC1/server/default/tmp/depl oy/server/default/deploy/jmx-console.war/61.jmx- console.war!/] 13:18:22,392 INFO [jbossweb] successfully deployed file:/C:/usr/JBoss3.2/jboss- all/build/output/jboss- 3.2.0RC1/server/default/tmp/deploy/server/default/deploy/ jmx-console.war/61.jmx-console.war to /jmx-console 13:18:22,392 INFO [MainDeployer] Deployed package: file:/C:/usr/JBoss3.2/jboss- all/build/output/jboss-3.2.0RC1/server/default/deploy/jmx- console.war 13:18:22,402 INFO [URLDeploymentScanner] Started It is in fact not accessible: security 409wget http://localhost:8080/jmx-console --13:21:08-- http://localhost:8080/jmx-console = `jmx-console' Resolving localhost... done. Connecting to localhost[127.0.0.1]:8080... connected. HTTP request sent, awaiting response... 302 Moved Temporarily Location: http://localhost:8080/jmx-console/ [following] --13:21:08-- http://localhost:8080/jmx-console/ = `index.html' Connecting to localhost[127.0.0.1]:8080... connected. HTTP request sent, awaiting response... 404 /jmx-
Re: [JBoss-dev] AW: jboss 4 build system changes, possible jboss.net and catalina impact.
Yes, jboss.net's build.xml points to an xdoclet version based on the official xdoclet 1.1.2 with the addition of the web-service.xml generation. The source's modification is checked in under thirdparty. The global xdoclet version is the modified version that I believe David or someone else created. If I remember correctly, they indicated that it was a version between 1.1.2 and the current XDoclet, but before their large refactoring effort. It is my intention since Ara informed me that a couple of bugs were fixed that had prevented messaging (nested classes) from building, and memory issues, to test building our latest with their latest. Fred. At 02:33 AM 9/11/2002, Jung , Dr. Christoph wrote: David, Thanks for the notice. Unfortunately, I have no exact idea about the differences of the jboss-xdoclet and the version that Frederick was getting by the xdoclet guys (must have been something between 1.1 and 1.2 with some bugs fixed?). Frederick, could you please synchronize with David on the global xdoclet version? AFAIK, xdoclet only affects the flash sample and not the testsuite (which did run fine with Jetty on Monday, so I´ll test it again). I guess that we won´t backport the build changes to 3.2? I´m going to migrate the latest jboss.net status into 3.2 this week, so I´d have to be a bit careful about what to sync and what not ... Do you have any cvs tricks for back-integration? I´m very used to the comfortable perforce integration feature, but I guess that I need to compare the absolute branches with diff here, right? CGJ -Ursprüngliche Nachricht- Von: David Jencks [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 11. September 2002 00:15 An: Jung Christoph; jboss-dev Cc: Bruce Scharlau Betreff: jboss 4 build system changes, possible jboss.net and catalina impact. I replaced many of the repetitive elements in the build.xml files with parameter entities, including the definition of xdoclet tasks. As far as I can tell this hasn't affected anything according to the testsuite. However, one effect is that xdoclet is now always the global xdoclet in thirdparty. Previously it looks like a local version was being used in jboss.net. I don't know if there are any tests of jboss.net: the module appears to compile fine. If this has broken something let me know. I'd prefer to fix it in xdoclet if possible since the xdoclet 1.2 release is imminent. I also don't know if the catalina module still works and don't know how to test it. I only partially converted that build.xml, leaving the previous definitions commented out. Again, info appreciated. thanks david jencks ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-604085 ] Jetty is not deploying packed wars
Dustin, thanks for your offer of help... My windows is still patching booting patching booting and looks to be hours or days away from being usable! So can you turn on verbose debugging in Jetty (simplest via the JMX interface). You want to set debug = true verbosity = 99 loglabels = true I think you also need to turn on JBoss debugging, as the jetty debug messages are just passed to the JBoss mechanism. then deploy a simple web app that is failing. Collect the logs and send them to me with the webapp. thanks Barlow, Dustin wrote: I'm more then happy to help in whatever way I can. I sent Jules the server logs from JBoss, but I suspect those weren't helpful being that from JBoss's perspective, there didn't appear to be any deployment errors generated. Let me know what else I can do to help you get what information you need to fix the problem. Dustin Barlow -Original Message- From: Greg Wilkins [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 11, 2002 5:43 AM To: Jules Gosnell Cc: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] [ jboss-Bugs-604085 ] Jetty is not deploying packed wars Jules Gosnell wrote: This is most likely the same as the spaces within paths issue. Because the war is packed, it is unpacked to a temporary dir, which has spaces in it. Greg is looking at it. No I'm not! I've had a total windows failure and after spending hours rebuilding that damn thing - applying service pack 3 rendered the thing unbootable again. I've had one user send me some detailed trace on it, and I'm currently suspecting something about classloading can't handle %20 in file URLs. But without a system I can't test. Jan has tried to reproduce the problem on her, but spaces in filenames are working without problem on straight jetty. So I need verbose debug traces from users with failures -- PLEASE. I'm trying to put a windows dev system back together today... cheers Jules [EMAIL PROTECTED] wrote: Bugs item #604085, was opened at 2002-09-03 10:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=604085group_id =22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Scott M Stark (starksm) Assigned to: Nobody/Anonymous (nobody) Summary: Jetty is not deploying packed wars Initial Comment: I am seeing a problem with Jetty not deploying wars from the deploy directory in the current 3.0 and 3.2 branches. If you take the default/deploy/jmx-console.war and repack this: deploy 414ls -l jmx-console.war -rw-r--r--1 starksm None58165 Sep 3 13:17 jmx-console.war deploy 415jar -tf jmx-console.war META-INF/ META-INF/MANIFEST.MF WEB-INF/ WEB-INF/classes/ WEB-INF/classes/org/ WEB-INF/classes/org/jboss/ WEB-INF/classes/org/jboss/jmx/ WEB-INF/classes/org/jboss/jmx/adaptor/ WEB-INF/classes/org/jboss/jmx/adaptor/control/ WEB- INF/classes/org/jboss/jmx/adaptor/control/AttrResultInfo. class WEB- INF/classes/org/jboss/jmx/adaptor/control/OpResultInfo. class WEB- INF/classes/org/jboss/jmx/adaptor/control/Server.class WEB-INF/classes/org/jboss/jmx/adaptor/html/ WEB- INF/classes/org/jboss/jmx/adaptor/html/HtmlAdaptorServ let.class WEB-INF/classes/org/jboss/jmx/adaptor/model/ WEB- INF/classes/org/jboss/jmx/adaptor/model/DomainData.cl ass WEB- INF/classes/org/jboss/jmx/adaptor/model/MBeanData.cl ass WEB-INF/classes/roles.properties WEB-INF/classes/users.properties WEB-INF/web.xml displayMBeans.jsp displayOpResult.jsp images/ images/head_blue.gif index.jsp inspectMBean.jsp style_master.css Startup the default config and although Jetty says the war was deployed: 13:18:20,769 INFO [MainDeployer] Starting deployment of package: file:/C:/usr/J Boss3.2/jboss-all/build/output/jboss- 3.2.0RC1/server/default/deploy/jmx-console. war 13:18:21,340 INFO [jbossweb] Registered jboss.web:Jetty=0,JBossWebApplicationCo ntext=0,context=/jmx-console 13:18:21,390 INFO [jbossweb] Checking Resource aliases 13:18:21,490 INFO [jbossweb] Extract jar:file:/C:/usr/JBoss3.2/jboss-all/build/ output/jboss- 3.2.0RC1/server/default/tmp/deploy/server/default/deploy/ jmx-consol e.war/61.jmx-console.war!/ to C:\DOCUME~1 \starksm\LOCALS~1\Temp\Jetty_0_0_0_0_80 80__jmx-console\webapp 13:18:22,312 INFO [jbossweb] Started WebApplicationContext[/jmx-console,jar:fil e:/C:/usr/JBoss3.2/jboss-all/build/output/jboss- 3.2.0RC1/server/default/tmp/depl oy/server/default/deploy/jmx-console.war/61.jmx- console.war!/] 13:18:22,392 INFO [jbossweb] successfully deployed file:/C:/usr/JBoss3.2/jboss- all/build/output/jboss- 3.2.0RC1/server/default/tmp/deploy/server/default/deploy/ jmx-console.war/61.jmx-console.war to /jmx-console 13:18:22,392 INFO [MainDeployer] Deployed package: file:/C:/usr/JBoss3.2/jboss- all/build/output/jboss-3.2.0RC1/server/default/deploy/jmx- console.war 13:18:22,402 INFO [URLDeploymentScanner] Started It is in fact not accessible:
[JBoss-dev] [ jboss-Bugs-607805 ] invalid ejbspec 12.2.11 warning
Bugs item #607805, was opened at 2002-09-11 16:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=607805group_id=22866 Category: JBossServer Group: CVS HEAD Status: Open Resolution: None Priority: 5 Submitted By: Oskari Kettunen (aok) Assigned to: Nobody/Anonymous (nobody) Summary: invalid ejbspec 12.2.11 warning Initial Comment: Method verifyEntityLocalHome(...) in org.jboss.verifier.strategy.EJBVerifier20 uses method throwsRemoteException(...) in org.jboss.verifier.strategy.AbstractVerifier to enforce EJB Spec 12.2.11. This causes misfired SpecViolationEvents. Because of Bug #434739, the assignability is in the direction e.isAssignableFrom (java.rmi.RemoteException.class) however, for this purpose it should be the original java.rmi.RemoteException.class.isAssignableFrom(e). For, example, throwing an IOException from an entity's local home is not prohibited by the spec: -- The throws clause of any method on the entity beans local home interface must not include the java.rmi.RemoteException. -- but java.io.IOException.class.isAssignableFrom (java.rmi.RemoteException.class) returns true, an the bean gets rejected... Apparently the verifiation should use two separate throwsRemoteException(...) methods, one or each direction... Oskari Kettunen, Finland -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=607805group_id=22866 --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] is pooling useless?
he he he
it seems the garbage collection and object generation is real :)
marc f
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On
Behalf Of Bill Burke
Sent: Wednesday, September 11, 2002 12:00 AM
To: Jboss-Dev
Subject: [JBoss-dev] is pooling useless?
I was looking into pooling Invocation objects so I thought
I'd test to see if it is actually better. With this test
case, its about 4% faster to pool on JDK 1.3.1 Win2k.
With JDK 1.4.0 on Win2k, Non-pooling is actually 7% faster!
import java.util.*;
public class testpool
{
HashMap trans;
HashMap as;
HashMap pay;
public testpool()
{
trans = new HashMap();
as = new HashMap();
pay = new HashMap();
}
public void clear()
{
trans.clear();
as.clear();
pay.clear();
}
public void addStuff()
{
for (int i = 0; i 5; i++)
{
trans.put(new Integer(i), new Integer(i));
as.put(new Integer(i), new Integer(i));
pay.put(new Integer(i), new Integer(i));
}
}
public static LinkedList pool = new LinkedList();
public static void main(String[] args)
{
long start;
long end;
System.out.println(testing non pool);
start = System.currentTimeMillis();
for (int i = 0; i 100; i++)
{
testpool p = new testpool();
p.addStuff();
}
end = System.currentTimeMillis() - start;
System.out.println(time: + end);
System.out.println(testing pool);
start = System.currentTimeMillis();
for (int i = 0; i 100; i++)
{
testpool p = null;
if (pool.isEmpty()) p = new testpool();
else
{
synchronized(pool)
{
p = (testpool)pool.removeFirst();
}
}
if (p == null) p = new testpool();
p.addStuff();
p.clear();
synchronized(pool)
{
pool.add(p);
}
}
end = System.currentTimeMillis() - start;
System.out.println(time: + end);
}
}}
---
In remembrance
www.osdn.com/911/ ___
Jboss-development mailing list [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
In remembrance
www.osdn.com/911/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] AW: jboss 4 build system changes, possible jboss.net and catalina impact.
FYI, We are talking with David, Dain and Michael about maintaining a stable version of XDoclet in our tree and doing bulk updates when the XDoclet core classes version. We will support our tags and versioning, rebuild everytime and avoid this kind of mess in the future. marc f -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Frederick N. Brier Sent: Wednesday, September 11, 2002 9:07 AM To: [EMAIL PROTECTED]; 'David Jencks'; jboss-dev Subject: Re: [JBoss-dev] AW: jboss 4 build system changes, possible jboss.net and catalina impact. Yes, jboss.net's build.xml points to an xdoclet version based on the official xdoclet 1.1.2 with the addition of the web-service.xml generation. The source's modification is checked in under thirdparty. The global xdoclet version is the modified version that I believe David or someone else created. If I remember correctly, they indicated that it was a version between 1.1.2 and the current XDoclet, but before their large refactoring effort. It is my intention since Ara informed me that a couple of bugs were fixed that had prevented messaging (nested classes) from building, and memory issues, to test building our latest with their latest. Fred. At 02:33 AM 9/11/2002, Jung , Dr. Christoph wrote: David, Thanks for the notice. Unfortunately, I have no exact idea about the differences of the jboss-xdoclet and the version that Frederick was getting by the xdoclet guys (must have been something between 1.1 and 1.2 with some bugs fixed?). Frederick, could you please synchronize with David on the global xdoclet version? AFAIK, xdoclet only affects the flash sample and not the testsuite (which did run fine with Jetty on Monday, so I´ll test it again). I guess that we won´t backport the build changes to 3.2? I´m going to migrate the latest jboss.net status into 3.2 this week, so I´d have to be a bit careful about what to sync and what not ... Do you have any cvs tricks for back-integration? I´m very used to the comfortable perforce integration feature, but I guess that I need to compare the absolute branches with diff here, right? CGJ -Ursprüngliche Nachricht- Von: David Jencks [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 11. September 2002 00:15 An: Jung Christoph; jboss-dev Cc: Bruce Scharlau Betreff: jboss 4 build system changes, possible jboss.net and catalina impact. I replaced many of the repetitive elements in the build.xml files with parameter entities, including the definition of xdoclet tasks. As far as I can tell this hasn't affected anything according to the testsuite. However, one effect is that xdoclet is now always the global xdoclet in thirdparty. Previously it looks like a local version was being used in jboss.net. I don't know if there are any tests of jboss.net: the module appears to compile fine. If this has broken something let me know. I'd prefer to fix it in xdoclet if possible since the xdoclet 1.2 release is imminent. I also don't know if the catalina module still works and don't know how to test it. I only partially converted that build.xml, leaving the previous definitions commented out. Again, info appreciated. thanks david jencks ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS connection parameters
Hi all, I'm trying to connect to the RW server (to check in my XMBean Persistence patch) and am having some difficulty (output below). Any suggestions? Commandline and/or Eclipse (IDE) connection info would be appreciated. - Matt D:\Matt\apelon\temporarycvs -d :ext:[EMAIL PROTECTED]:/cvsroot/jboss co CVSROOT ssh: connect to address 216.136.171.202 port 22: Connection timed out cvs [checkout aborted]: end of file from server (consult above messages if any) D:\Matt\apelon\temporarycvs -z3 -d :ext:[EMAIL PROTECTED]:/cvsroot/jboss co CVSROOT ssh: connect to address 216.136.171.202 port 22: Connection timed out cvs [checkout aborted]: end of file from server (consult above messages if any) D:\Matt\apelon\temporarycvs -d :ext:[EMAIL PROTECTED]:/cvsroot/jboss co CVSROOT ssh: connect to address 216.136.171.202 port 22: Connection timed out cvs [checkout aborted]: end of file from server (consult above messages if any) D:\Matt\apelon\temporaryssh -V OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090605f D:\Matt\apelon\temporaryssh cvs.jboss.sourceforge.net -l mattmunz ssh: connect to address 216.136.171.202 port 22: Connection timed out --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-607805 ] invalid ejbspec 12.2.11 warning
Bugs item #607805, was opened at 2002-09-11 15:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=607805group_id=22866 Category: JBossServer Group: CVS HEAD Status: Open Resolution: Accepted Priority: 5 Submitted By: Oskari Kettunen (aok) Assigned to: Christian Riege (lqd) Summary: invalid ejbspec 12.2.11 warning Initial Comment: Method verifyEntityLocalHome(...) in org.jboss.verifier.strategy.EJBVerifier20 uses method throwsRemoteException(...) in org.jboss.verifier.strategy.AbstractVerifier to enforce EJB Spec 12.2.11. This causes misfired SpecViolationEvents. Because of Bug #434739, the assignability is in the direction e.isAssignableFrom (java.rmi.RemoteException.class) however, for this purpose it should be the original java.rmi.RemoteException.class.isAssignableFrom(e). For, example, throwing an IOException from an entity's local home is not prohibited by the spec: -- The throws clause of any method on the entity beans local home interface must not include the java.rmi.RemoteException. -- but java.io.IOException.class.isAssignableFrom (java.rmi.RemoteException.class) returns true, an the bean gets rejected... Apparently the verifiation should use two separate throwsRemoteException(...) methods, one or each direction... Oskari Kettunen, Finland -- Comment By: Christian Riege (lqd) Date: 2002-09-11 16:01 Message: Logged In: YES user_id=176671 I'll look into this. Setting the StrictVerifier attribute to 'false' in jboss-service.xml will allow you to deploy your beans despite of the verification failing; you might want to try this as a workaround in the meantime. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=607805group_id=22866 --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-607805 ] invalid ejbspec 12.2.11 warning
Bugs item #607805, was opened at 2002-09-11 15:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=607805group_id=22866 Category: JBossServer Group: CVS HEAD Status: Open Resolution: Accepted Priority: 5 Submitted By: Oskari Kettunen (aok) Assigned to: Christian Riege (lqd) Summary: invalid ejbspec 12.2.11 warning Initial Comment: Method verifyEntityLocalHome(...) in org.jboss.verifier.strategy.EJBVerifier20 uses method throwsRemoteException(...) in org.jboss.verifier.strategy.AbstractVerifier to enforce EJB Spec 12.2.11. This causes misfired SpecViolationEvents. Because of Bug #434739, the assignability is in the direction e.isAssignableFrom (java.rmi.RemoteException.class) however, for this purpose it should be the original java.rmi.RemoteException.class.isAssignableFrom(e). For, example, throwing an IOException from an entity's local home is not prohibited by the spec: -- The throws clause of any method on the entity beans local home interface must not include the java.rmi.RemoteException. -- but java.io.IOException.class.isAssignableFrom (java.rmi.RemoteException.class) returns true, an the bean gets rejected... Apparently the verifiation should use two separate throwsRemoteException(...) methods, one or each direction... Oskari Kettunen, Finland -- Comment By: Christian Riege (lqd) Date: 2002-09-11 16:09 Message: Logged In: YES user_id=176671 ... this must be fixed not only for 12.2.11 (EntityLocalHome) but also for SessionLocalHome, EntityLocal and SessionLocal. -- Comment By: Christian Riege (lqd) Date: 2002-09-11 16:01 Message: Logged In: YES user_id=176671 I'll look into this. Setting the StrictVerifier attribute to 'false' in jboss-service.xml will allow you to deploy your beans despite of the verification failing; you might want to try this as a workaround in the meantime. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=607805group_id=22866 --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-607853 ] global_alloc: out of space
Bugs item #607853, was opened at 2002-09-11 14:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=607853group_id=22866 Category: JBossServer Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andy Wagg (andywagg) Assigned to: Nobody/Anonymous (nobody) Summary: global_alloc: out of space Initial Comment: I'm running jboss-3.0.1_tomcat-4.0.4, the server had been up for 2 days with lots of repeated hot deployments of an application. jboss crashed with the following error: global_alloc: out of space, file: /runtime/globals.c line 29 Tru64 4.0F JDK 1.3 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=607853group_id=22866 --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-607805 ] invalid ejbspec 12.2.11 warning
Bugs item #607805, was opened at 2002-09-11 15:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=607805group_id=22866 Category: JBossServer Group: CVS HEAD Status: Open Resolution: Accepted Priority: 5 Submitted By: Oskari Kettunen (aok) Assigned to: Christian Riege (lqd) Summary: invalid ejbspec 12.2.11 warning Initial Comment: Method verifyEntityLocalHome(...) in org.jboss.verifier.strategy.EJBVerifier20 uses method throwsRemoteException(...) in org.jboss.verifier.strategy.AbstractVerifier to enforce EJB Spec 12.2.11. This causes misfired SpecViolationEvents. Because of Bug #434739, the assignability is in the direction e.isAssignableFrom (java.rmi.RemoteException.class) however, for this purpose it should be the original java.rmi.RemoteException.class.isAssignableFrom(e). For, example, throwing an IOException from an entity's local home is not prohibited by the spec: -- The throws clause of any method on the entity beans local home interface must not include the java.rmi.RemoteException. -- but java.io.IOException.class.isAssignableFrom (java.rmi.RemoteException.class) returns true, an the bean gets rejected... Apparently the verifiation should use two separate throwsRemoteException(...) methods, one or each direction... Oskari Kettunen, Finland -- Comment By: Christian Riege (lqd) Date: 2002-09-11 16:40 Message: Logged In: YES user_id=176671 the fix is simpler than including a second method for specifically checking local interfaces: we now explicitly ignore exceptions of type java.io.IOException checked into HEAD, 3.2 and 3.0. thanks for the detailed report and analysis, this helped a lot! -- Comment By: Christian Riege (lqd) Date: 2002-09-11 16:09 Message: Logged In: YES user_id=176671 ... this must be fixed not only for 12.2.11 (EntityLocalHome) but also for SessionLocalHome, EntityLocal and SessionLocal. -- Comment By: Christian Riege (lqd) Date: 2002-09-11 16:01 Message: Logged In: YES user_id=176671 I'll look into this. Setting the StrictVerifier attribute to 'false' in jboss-service.xml will allow you to deploy your beans despite of the verification failing; you might want to try this as a workaround in the meantime. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=607805group_id=22866 --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-607805 ] invalid ejbspec 12.2.11 warning
Bugs item #607805, was opened at 2002-09-11 15:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=607805group_id=22866 Category: JBossServer Group: CVS HEAD Status: Closed Resolution: Fixed Priority: 5 Submitted By: Oskari Kettunen (aok) Assigned to: Christian Riege (lqd) Summary: invalid ejbspec 12.2.11 warning Initial Comment: Method verifyEntityLocalHome(...) in org.jboss.verifier.strategy.EJBVerifier20 uses method throwsRemoteException(...) in org.jboss.verifier.strategy.AbstractVerifier to enforce EJB Spec 12.2.11. This causes misfired SpecViolationEvents. Because of Bug #434739, the assignability is in the direction e.isAssignableFrom (java.rmi.RemoteException.class) however, for this purpose it should be the original java.rmi.RemoteException.class.isAssignableFrom(e). For, example, throwing an IOException from an entity's local home is not prohibited by the spec: -- The throws clause of any method on the entity beans local home interface must not include the java.rmi.RemoteException. -- but java.io.IOException.class.isAssignableFrom (java.rmi.RemoteException.class) returns true, an the bean gets rejected... Apparently the verifiation should use two separate throwsRemoteException(...) methods, one or each direction... Oskari Kettunen, Finland -- Comment By: Christian Riege (lqd) Date: 2002-09-11 16:40 Message: Logged In: YES user_id=176671 the fix is simpler than including a second method for specifically checking local interfaces: we now explicitly ignore exceptions of type java.io.IOException checked into HEAD, 3.2 and 3.0. thanks for the detailed report and analysis, this helped a lot! -- Comment By: Christian Riege (lqd) Date: 2002-09-11 16:09 Message: Logged In: YES user_id=176671 ... this must be fixed not only for 12.2.11 (EntityLocalHome) but also for SessionLocalHome, EntityLocal and SessionLocal. -- Comment By: Christian Riege (lqd) Date: 2002-09-11 16:01 Message: Logged In: YES user_id=176671 I'll look into this. Setting the StrictVerifier attribute to 'false' in jboss-service.xml will allow you to deploy your beans despite of the verification failing; you might want to try this as a workaround in the meantime. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=607805group_id=22866 --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS connection parameters
This has been occuring lately. I just checked in some code so try it again. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Matt Munz [EMAIL PROTECTED] To: JBoss Developers Group [EMAIL PROTECTED] Sent: Wednesday, September 11, 2002 6:22 AM Subject: [JBoss-dev] CVS connection parameters Hi all, I'm trying to connect to the RW server (to check in my XMBean Persistence patch) and am having some difficulty (output below). Any suggestions? Commandline and/or Eclipse (IDE) connection info would be appreciated. - Matt D:\Matt\apelon\temporarycvs -d :ext:[EMAIL PROTECTED]:/cvsroot/jboss co CVSROOT ssh: connect to address 216.136.171.202 port 22: Connection timed out cvs [checkout aborted]: end of file from server (consult above messages if any) D:\Matt\apelon\temporarycvs -z3 -d :ext:[EMAIL PROTECTED]:/cvsroot/jboss co CVSROOT ssh: connect to address 216.136.171.202 port 22: Connection timed out cvs [checkout aborted]: end of file from server (consult above messages if any) D:\Matt\apelon\temporarycvs -d :ext:[EMAIL PROTECTED]:/cvsroot/jboss co CVSROOT ssh: connect to address 216.136.171.202 port 22: Connection timed out cvs [checkout aborted]: end of file from server (consult above messages if any) D:\Matt\apelon\temporaryssh -V OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090605f D:\Matt\apelon\temporaryssh cvs.jboss.sourceforge.net -l mattmunz ssh: connect to address 216.136.171.202 port 22: Connection timed out --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-607895 ] Deployment fails / multiple inheritance
Bugs item #607895, was opened at 2002-09-11 17:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=607895group_id=22866 Category: JBossServer Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Randahl Fink Isaksen (randahl) Assigned to: Nobody/Anonymous (nobody) Summary: Deployment fails / multiple inheritance Initial Comment: I found out that the JBoss deployment mechanism fails when you use multiple interface inheritance in your EJBs, causing errors similar to the one shown at the end of this post. The error only occurs when you create a situation similar to what is often refered to as the deadly diamond of death meaning you inherit the same method twice (which is legal in java when using multiple interface inheritance). I have been able to recreate the bug with a setup like the following: I have two classes C1 and C2. C2 extends C1 The class C1 implements an interface called I1. The class C2 implements an interface called I2. Because I want to make sure that any class which implements I2 also implements I1 my I2 interface extends I1. As a result C2 implements I1 in the two following ways: C2 - I2 - I1 C2 - C1 - I1 - And this makes the deployment fail on JBoss causing the ClassFormatError shown below. This must be a JBoss bug since java permits multiple interface inheritance and it is stated in the EJB specification that EJBs are allowed to use inheritance. If you happen to be the person who knows how to fix this bug, I would be very grateful if you would e-mail me at [EMAIL PROTECTED] when you know the ETA of the fix - I have a truck load of EJBs which use multiple interface inheritance and so far they simply cannot deploy on JBoss. Randahl Caused by: java.lang.ClassFormatError: dk/rockit/ArchiveBean $Proxy (Repetitive method name/signature) at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass (ClassLoader.java:509) at java.lang.ClassLoader.defineClass (ClassLoader.java:438) at org.jboss.proxy.compiler.Runtime.makeProxyType (Runtime.java:68) at org.jboss.proxy.compiler.ProxyCompiler.init (ProxyCompiler.java:76) at org.jboss.proxy.compiler.Proxies$Impl.newTarget (Proxies.java:580) at org.jboss.proxy.compiler.Proxies.newTarget (Proxies.java:77) at org.jboss.proxy.compiler.Proxy.newProxyInstance (Proxy.java:49) at org.jboss.ejb.plugins.cmp.jdbc.JDBCCreateBeanClassIn stanceCommand.in it(JDBCCreateBeanClassInstanceCommand.java:52) at org.jboss.ejb.plugins.cmp.jdbc.JDBCCommandFactory.c reateCreateBeanCla ssInstanceCommand(JDBCCommandFactory.java:97) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.start StoreManager(JDB CStoreManager.java:436) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.start (JDBCStoreManage r.java:369) at org.jboss.ejb.plugins.CMPPersistenceManager.start (CMPPersistenceManag er.java:198) at org.jboss.ejb.EntityContainer.start (EntityContainer.java:376) at org.jboss.ejb.Container.invoke (Container.java:764) at org.jboss.ejb.EntityContainer.invoke (EntityContainer.java:1055) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:517) at org.jboss.system.ServiceController$ServiceProxy.invoke (ServiceControl ler.java:967) at $Proxy5.start(Unknown Source) at org.jboss.system.ServiceController.start (ServiceController.java:396) at sun.reflect.GeneratedMethodAccessor6.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invok e(ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:517) at org.jboss.util.jmx.MBeanProxy.invoke (MBeanProxy.java:174) at $Proxy357.start(Unknown Source) at org.jboss.ejb.EjbModule.startService (EjbModule.java:430) at org.jboss.system.ServiceMBeanSupport.start (ServiceMBeanSupport.java:1 64) at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invok e(ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:517) at org.jboss.system.ServiceController$ServiceProxy.invoke (ServiceControl ler.java:967) at $Proxy5.start(Unknown Source) at org.jboss.system.ServiceController.start (ServiceController.java:396) at sun.reflect.GeneratedMethodAccessor6.invoke
Re: [JBoss-dev] jboss 4 build system changes, possible jboss.net and catalina impact.
Hello David,
jboss-all/server/build.xml needs ${build.parsers} and ${build.beans}
properties. These are missed in locations.ent.
Should they be added to jboss-all/server/build.xml or locations.ent?
Thank you.
alex
Wednesday, September 11, 2002, 1:15:11 AM, you wrote:
DJ I replaced many of the repetitive elements in the build.xml files with
DJ parameter entities, including the definition of xdoclet tasks. As far as I
DJ can tell this hasn't affected anything according to the testsuite.
DJ However, one effect is that xdoclet is now always the global xdoclet in
DJ thirdparty. Previously it looks like a local version was being used in
DJ jboss.net. I don't know if there are any tests of jboss.net: the module
DJ appears to compile fine.
DJ If this has broken something let me know. I'd prefer to fix it in xdoclet
DJ if possible since the xdoclet 1.2 release is imminent.
DJ
DJ I also don't know if the catalina module still works and don't know how to
DJ test it. I only partially converted that build.xml, leaving the previous
DJ definitions commented out. Again, info appreciated.
DJ thanks
DJ david jencks
--
Best regards,
Alex Loubyansky
---
In remembrance
www.osdn.com/911/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-604085 ] Jetty is not deploying pack ed wars
There is no reason to setup a win32 system as the problem occurs on linux if the java.io.tmpdir property is set to a directory path with a space in it. Using the current 3.0 branch with a -Djava.io.tmpdir=/tmp/space\ here 11:52:39,222 INFO [Server] JBoss Release: JBoss-3.0.3RC1 CVSTag=Branch_3_0 11:52:39,357 INFO [Server] Home Dir: /home/starksm/JBoss/jboss-all/build/output/jboss-3.0.3RC1 11:52:39,358 INFO [Server] Home URL: file:/home/starksm/JBoss/jboss-all/build/output/jboss-3.0.3RC1/ 11:52:39,358 INFO [Server] Library URL: file:/home/starksm/JBoss/jboss-all/build/output/jboss-3.0.3RC1/lib/ 11:52:39,378 INFO [Server] Patch URL: null 11:52:39,379 INFO [Server] Server Name: default 11:52:39,379 INFO [Server] Server Home Dir: /home/starksm/JBoss/jboss-all/build/output/jboss-3.0.3RC1/server/default 11:52:39,380 INFO [Server] Server Home URL: file:/home/starksm/JBoss/jboss-all/build/output/jboss-3.0.3RC1/server/default/ 11:52:39,381 INFO [Server] Server Data Dir: /home/starksm/JBoss/jboss-all/build/output/jboss-3.0.3RC1/server/default/db 11:52:39,381 INFO [Server] Server Temp Dir: /home/starksm/JBoss/jboss-all/build/output/jboss-3.0.3RC1/server/default/tmp 11:52:39,382 INFO [Server] Server Config URL: file:/home/starksm/JBoss/jboss-all/build/output/jboss-3.0.3RC1/server/default/conf/ 11:52:39,382 INFO [Server] Server Library URL: file:/home/starksm/JBoss/jboss-all/build/output/jboss-3.0.3RC1/server/default/lib/ 11:52:39,383 INFO [Server] Root Deployemnt Filename: jboss-service.xml 11:52:39,389 INFO [Server] Starting General Purpose Architecture (GPA)... 11:52:39,801 INFO [ServerInfo] Java version: 1.3.1_04,Sun Microsystems Inc. 11:52:39,802 INFO [ServerInfo] Java VM: Java HotSpot(TM) Server VM 1.3.1_04-b02,Sun Microsystems Inc. 11:52:39,802 INFO [ServerInfo] OS-System: Linux 2.4.18-3,i386 11:52:39,894 INFO [ServiceController] Controller MBean online ... 11:53:04,716 INFO [jbossweb] Extract jar:file:/home/starksm/JBoss/jboss-all/build/output/jboss-3.0.3RC1/server/default/tmp/deploy/server/default/deploy/test.war/61 .test.war!/ to /tmp/space here/Jetty_0_0_0_0_8080__test/webapp 11:53:04,823 INFO [jbossweb] Started WebApplicationContext[/test,jar:file:/home/starksm/JBoss/jboss-all/build/output/jboss-3.0.3RC1/server/default/tmp/deploy/serve r/default/deploy/test.war/61.test.war!/] 11:53:04,828 INFO [jbossweb] Internal Error: File /WEB-INF/web.xml not found 11:53:04,830 INFO [jbossweb] successfully deployed file:/home/starksm/JBoss/jboss-all/build/output/jboss-3.0.3RC1/server/default/tmp/deploy/server/default/deploy/test.war/61.tes t.war to /test 11:53:04,831 INFO [MainDeployer] Deployed package: file:/home/starksm/JBoss/jboss-all/build/output/jboss-3.0.3RC1/server/default/deploy/test.war [starksm@banshee space here]$ ls /tmp/space\ here/Jetty_0_0_0_0_8080__test/webapp/ index.html WEB-INF/ [starksm@banshee space here]$ ls /tmp/space\ here/Jetty_0_0_0_0_8080__test/webapp/WEB-INF/ web.xml [starksm@banshee space here]$ wget http://localhost:8080/test/ --11:55:26-- http://localhost:8080/test/ = `index.html' Resolving localhost... done. Connecting to localhost[127.0.0.1]:8080... connected. HTTP request sent, awaiting response... 404 /test/ Not Found 11:55:27 ERROR 404: /test/ Not Found. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Greg Wilkins [EMAIL PROTECTED] To: Barlow, Dustin [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; Jules Gosnell [EMAIL PROTECTED] Sent: Wednesday, September 11, 2002 6:06 AM Subject: Re: [JBoss-dev] [ jboss-Bugs-604085 ] Jetty is not deploying pack ed wars Dustin, thanks for your offer of help... My windows is still patching booting patching booting and looks to be hours or days away from being usable! So can you turn on verbose debugging in Jetty (simplest via the JMX interface). You want to set debug = true verbosity = 99 loglabels = true I think you also need to turn on JBoss debugging, as the jetty debug messages are just passed to the JBoss mechanism. then deploy a simple web app that is failing. Collect the logs and send them to me with the webapp. thanks --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-604085 ] Jetty is not deploying packed wars
Bugs item #604085, was opened at 2002-09-03 10:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=604085group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Scott M Stark (starksm) Assigned to: Nobody/Anonymous (nobody) Summary: Jetty is not deploying packed wars Initial Comment: I am seeing a problem with Jetty not deploying wars from the deploy directory in the current 3.0 and 3.2 branches. If you take the default/deploy/jmx-console.war and repack this: deploy 414ls -l jmx-console.war -rw-r--r--1 starksm None58165 Sep 3 13:17 jmx-console.war deploy 415jar -tf jmx-console.war META-INF/ META-INF/MANIFEST.MF WEB-INF/ WEB-INF/classes/ WEB-INF/classes/org/ WEB-INF/classes/org/jboss/ WEB-INF/classes/org/jboss/jmx/ WEB-INF/classes/org/jboss/jmx/adaptor/ WEB-INF/classes/org/jboss/jmx/adaptor/control/ WEB- INF/classes/org/jboss/jmx/adaptor/control/AttrResultInfo. class WEB- INF/classes/org/jboss/jmx/adaptor/control/OpResultInfo. class WEB- INF/classes/org/jboss/jmx/adaptor/control/Server.class WEB-INF/classes/org/jboss/jmx/adaptor/html/ WEB- INF/classes/org/jboss/jmx/adaptor/html/HtmlAdaptorServ let.class WEB-INF/classes/org/jboss/jmx/adaptor/model/ WEB- INF/classes/org/jboss/jmx/adaptor/model/DomainData.cl ass WEB- INF/classes/org/jboss/jmx/adaptor/model/MBeanData.cl ass WEB-INF/classes/roles.properties WEB-INF/classes/users.properties WEB-INF/web.xml displayMBeans.jsp displayOpResult.jsp images/ images/head_blue.gif index.jsp inspectMBean.jsp style_master.css Startup the default config and although Jetty says the war was deployed: 13:18:20,769 INFO [MainDeployer] Starting deployment of package: file:/C:/usr/J Boss3.2/jboss-all/build/output/jboss- 3.2.0RC1/server/default/deploy/jmx-console. war 13:18:21,340 INFO [jbossweb] Registered jboss.web:Jetty=0,JBossWebApplicationCo ntext=0,context=/jmx-console 13:18:21,390 INFO [jbossweb] Checking Resource aliases 13:18:21,490 INFO [jbossweb] Extract jar:file:/C:/usr/JBoss3.2/jboss-all/build/ output/jboss- 3.2.0RC1/server/default/tmp/deploy/server/default/deploy/ jmx-consol e.war/61.jmx-console.war!/ to C:\DOCUME~1 \starksm\LOCALS~1\Temp\Jetty_0_0_0_0_80 80__jmx-console\webapp 13:18:22,312 INFO [jbossweb] Started WebApplicationContext[/jmx-console,jar:fil e:/C:/usr/JBoss3.2/jboss-all/build/output/jboss- 3.2.0RC1/server/default/tmp/depl oy/server/default/deploy/jmx-console.war/61.jmx- console.war!/] 13:18:22,392 INFO [jbossweb] successfully deployed file:/C:/usr/JBoss3.2/jboss- all/build/output/jboss- 3.2.0RC1/server/default/tmp/deploy/server/default/deploy/ jmx-console.war/61.jmx-console.war to /jmx-console 13:18:22,392 INFO [MainDeployer] Deployed package: file:/C:/usr/JBoss3.2/jboss- all/build/output/jboss-3.2.0RC1/server/default/deploy/jmx- console.war 13:18:22,402 INFO [URLDeploymentScanner] Started It is in fact not accessible: security 409wget http://localhost:8080/jmx-console --13:21:08-- http://localhost:8080/jmx-console = `jmx-console' Resolving localhost... done. Connecting to localhost[127.0.0.1]:8080... connected. HTTP request sent, awaiting response... 302 Moved Temporarily Location: http://localhost:8080/jmx-console/ [following] --13:21:08-- http://localhost:8080/jmx-console/ = `index.html' Connecting to localhost[127.0.0.1]:8080... connected. HTTP request sent, awaiting response... 404 /jmx- console/ Not Found 13:21:08 ERROR 404: /jmx-console/ Not Found. If the jmx-console.war is unpacked then the content is accessible: security 410wget http://localhost:8080/jmx-console --13:25:25-- http://localhost:8080/jmx-console = `jmx-console' Resolving localhost... done. Connecting to localhost[127.0.0.1]:8080... connected. HTTP request sent, awaiting response... 302 Moved Temporarily Location: http://localhost:8080/jmx-console/ [following] --13:25:25-- http://localhost:8080/jmx-console/ = `index.html' Connecting to localhost[127.0.0.1]:8080... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] [ = ] 46,675 735.18K/s 13:25:30 (735.18 KB/s) - `index.html' saved [46675] These messages are for the current 3.2 build. The 3.0 build actually displays an info message with a Internal Error... msg during deployment of the war: 12:57:23,161 INFO [MainDeployer] Starting deployment of package: file:/C:/usr/S akonnet/jboss-3.0.3RC1/server/default/deploy/jmx- console.war 12:57:23,442 INFO [jbossweb] Registered jboss.web:Jetty=0,JBossWebApplicationCo ntext=1,context=/jmx-console 12:57:23,472 INFO [jbossweb] Extract jar:file:/C:/usr/Sakonnet/jboss-3.0.3RC1/s erver/default/tmp/deploy/server/default/deploy/jmx- console.war/61.jmx-console.wa r!/ to C:\DOCUME~1\starksm\LOCALS~1 \Temp\Jetty_0_0_0_0_8080__jmx-console\webapp 12:57:23,942 INFO [jbossweb] Started
[JBoss-dev] error when buiding
why do i get this error when building jboss-all?? ./build.sh Searching for build.xml ... Buildfile: /home/emersonc/eclipse/workspace/jboss/build.xml BUILD FAILED Error reading project file: unknown protocol: resource -- Emerson Cargnin SICREDI - Tel : 3358-4860 --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jboss 4 build system changes, possible jboss.net and catalina impact.
I noticed that a few minutes ago. I'm going to see if I can eliminate the
need for them, I think they both contain generated source code so should go
into build.gen-src.
thanks
david jencks
On 2002.09.11 11:55:50 -0400 Alex Loubyansky wrote:
Hello David,
jboss-all/server/build.xml needs ${build.parsers} and ${build.beans}
properties. These are missed in locations.ent.
Should they be added to jboss-all/server/build.xml or locations.ent?
Thank you.
alex
Wednesday, September 11, 2002, 1:15:11 AM, you wrote:
DJ I replaced many of the repetitive elements in the build.xml files
with
DJ parameter entities, including the definition of xdoclet tasks. As
far as I
DJ can tell this hasn't affected anything according to the testsuite.
DJ However, one effect is that xdoclet is now always the global
xdoclet in
DJ thirdparty. Previously it looks like a local version was being used
in
DJ jboss.net. I don't know if there are any tests of jboss.net: the
module
DJ appears to compile fine.
DJ If this has broken something let me know. I'd prefer to fix it in
xdoclet
DJ if possible since the xdoclet 1.2 release is imminent.
DJ
DJ I also don't know if the catalina module still works and don't know
how to
DJ test it. I only partially converted that build.xml, leaving the
previous
DJ definitions commented out. Again, info appreciated.
DJ thanks
DJ david jencks
--
Best regards,
Alex Loubyansky
---
In remembrance
www.osdn.com/911/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
In remembrance
www.osdn.com/911/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jboss 4 build system changes, possible jboss.net and catalina impact.
Another problem, David. When cleaning up I get the following exception. The file exists and can deleted manually w/o problems. Or is it just my own problem? Thank you. alex _buildmagic:clean: [delete] Deleting directory C:\CVSROOT\jboss-all\j2ee\output BUILD FAILED jar:file:/C:/CVSROOT/jboss-all/tools/lib/buildmagic-tasks.jar!/org/jboss/tools/buildmagic/common.xml:124: Unable to delete file C:\CVSROOT\jboss-all\j2ee\output\lib\jboss-j2ee.jar at org.apache.tools.ant.taskdefs.Delete.removeDir(Delete.java:388) at org.apache.tools.ant.taskdefs.Delete.removeDir(Delete.java:381) at org.apache.tools.ant.taskdefs.Delete.execute(Delete.java:327) at org.apache.tools.ant.Task.perform(Task.java:317) at org.apache.tools.ant.Target.execute(Target.java:309) at org.apache.tools.ant.Target.performTasks(Target.java:334) at org.apache.tools.ant.Project.executeTarget(Project.java:1306) at org.jboss.tools.buildmagic.task.Ant.execute(Ant.java:261) at org.jboss.tools.buildmagic.task.module.ExecuteModules.executeModule(ExecuteModules.java:292) at org.jboss.tools.buildmagic.task.module.ExecuteModules.execute(ExecuteModules.java:194) at org.apache.tools.ant.Task.perform(Task.java:317) at org.apache.tools.ant.Target.execute(Target.java:309) at org.apache.tools.ant.Target.performTasks(Target.java:334) at org.apache.tools.ant.Project.executeTarget(Project.java:1306) at org.apache.tools.ant.Project.executeTargets(Project.java:1250) at org.apache.tools.ant.Main.runBuild(Main.java:610) at org.apache.tools.ant.Main.start(Main.java:196) at org.apache.tools.ant.Main.main(Main.java:235) Wednesday, September 11, 2002, 1:15:11 AM, you wrote: DJ I replaced many of the repetitive elements in the build.xml files with DJ parameter entities, including the definition of xdoclet tasks. As far as I DJ can tell this hasn't affected anything according to the testsuite. DJ However, one effect is that xdoclet is now always the global xdoclet in DJ thirdparty. Previously it looks like a local version was being used in DJ jboss.net. I don't know if there are any tests of jboss.net: the module DJ appears to compile fine. DJ If this has broken something let me know. I'd prefer to fix it in xdoclet DJ if possible since the xdoclet 1.2 release is imminent. DJ DJ I also don't know if the catalina module still works and don't know how to DJ test it. I only partially converted that build.xml, leaving the previous DJ definitions commented out. Again, info appreciated. DJ thanks DJ david jencks -- Best regards, Alex Loubyansky --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jboss 4 build system changes, possible jboss.net and catalina impact.
Maybe this is a windows only problem? I didn't have a problem cleaning on linux. BTW I didn't modify the build.bat files to increase the memory, which was required on my linux system to do build.sh all. Could you try build.bat all and add the -X. stuff if necessary? thanks david On 2002.09.11 12:45:30 -0400 Alex Loubyansky wrote: Another problem, David. When cleaning up I get the following exception. The file exists and can deleted manually w/o problems. Or is it just my own problem? Thank you. alex _buildmagic:clean: [delete] Deleting directory C:\CVSROOT\jboss-all\j2ee\output BUILD FAILED jar:file:/C:/CVSROOT/jboss-all/tools/lib/buildmagic-tasks.jar!/org/jboss/tools/buildmagic/common.xml:124: Unable to delete file C:\CVSROOT\jboss-all\j2ee\output\lib\jboss-j2ee.jar at org.apache.tools.ant.taskdefs.Delete.removeDir(Delete.java:388) at org.apache.tools.ant.taskdefs.Delete.removeDir(Delete.java:381) at org.apache.tools.ant.taskdefs.Delete.execute(Delete.java:327) at org.apache.tools.ant.Task.perform(Task.java:317) at org.apache.tools.ant.Target.execute(Target.java:309) at org.apache.tools.ant.Target.performTasks(Target.java:334) at org.apache.tools.ant.Project.executeTarget(Project.java:1306) at org.jboss.tools.buildmagic.task.Ant.execute(Ant.java:261) at org.jboss.tools.buildmagic.task.module.ExecuteModules.executeModule(ExecuteModules.java:292) at org.jboss.tools.buildmagic.task.module.ExecuteModules.execute(ExecuteModules.java:194) at org.apache.tools.ant.Task.perform(Task.java:317) at org.apache.tools.ant.Target.execute(Target.java:309) at org.apache.tools.ant.Target.performTasks(Target.java:334) at org.apache.tools.ant.Project.executeTarget(Project.java:1306) at org.apache.tools.ant.Project.executeTargets(Project.java:1250) at org.apache.tools.ant.Main.runBuild(Main.java:610) at org.apache.tools.ant.Main.start(Main.java:196) at org.apache.tools.ant.Main.main(Main.java:235) Wednesday, September 11, 2002, 1:15:11 AM, you wrote: DJ I replaced many of the repetitive elements in the build.xml files with DJ parameter entities, including the definition of xdoclet tasks. As far as I DJ can tell this hasn't affected anything according to the testsuite. DJ However, one effect is that xdoclet is now always the global xdoclet in DJ thirdparty. Previously it looks like a local version was being used in DJ jboss.net. I don't know if there are any tests of jboss.net: the module DJ appears to compile fine. DJ If this has broken something let me know. I'd prefer to fix it in xdoclet DJ if possible since the xdoclet 1.2 release is imminent. DJ DJ I also don't know if the catalina module still works and don't know how to DJ test it. I only partially converted that build.xml, leaving the previous DJ definitions commented out. Again, info appreciated. DJ thanks DJ david jencks -- Best regards, Alex Loubyansky --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re[2]: [JBoss-dev] jboss 4 build system changes, possible jboss.net and catalina impact.
Hello David, Wednesday, September 11, 2002, 8:00:25 PM, you wrote: DJ Maybe this is a windows only problem? I didn't have a problem cleaning on DJ linux. Maybe.. I have it permanently. Am I along here? DJ BTW I didn't modify the build.bat files to increase the memory, which was DJ required on my linux system to do build.sh all. Could you try build.bat DJ all and add the -X. stuff if necessary? set ANT_OPTS=%ANT_OPTS% -Xmx640m As in build.sh but it doesn't help. Thank you. alex DJ On 2002.09.11 12:45:30 -0400 Alex Loubyansky wrote: Another problem, David. When cleaning up I get the following exception. The file exists and can deleted manually w/o problems. Or is it just my own problem? Thank you. alex _buildmagic:clean: [delete] Deleting directory C:\CVSROOT\jboss-all\j2ee\output BUILD FAILED jar:file:/C:/CVSROOT/jboss-all/tools/lib/buildmagic-tasks.jar!/org/jboss/tools/buildmagic/common.xml:124: Unable to delete file C:\CVSROOT\jboss-all\j2ee\output\lib\jboss-j2ee.jar at org.apache.tools.ant.taskdefs.Delete.removeDir(Delete.java:388) at org.apache.tools.ant.taskdefs.Delete.removeDir(Delete.java:381) at org.apache.tools.ant.taskdefs.Delete.execute(Delete.java:327) at org.apache.tools.ant.Task.perform(Task.java:317) at org.apache.tools.ant.Target.execute(Target.java:309) at org.apache.tools.ant.Target.performTasks(Target.java:334) at org.apache.tools.ant.Project.executeTarget(Project.java:1306) at org.jboss.tools.buildmagic.task.Ant.execute(Ant.java:261) at org.jboss.tools.buildmagic.task.module.ExecuteModules.executeModule(ExecuteModules.java:292) at org.jboss.tools.buildmagic.task.module.ExecuteModules.execute(ExecuteModules.java:194) at org.apache.tools.ant.Task.perform(Task.java:317) at org.apache.tools.ant.Target.execute(Target.java:309) at org.apache.tools.ant.Target.performTasks(Target.java:334) at org.apache.tools.ant.Project.executeTarget(Project.java:1306) at org.apache.tools.ant.Project.executeTargets(Project.java:1250) at org.apache.tools.ant.Main.runBuild(Main.java:610) at org.apache.tools.ant.Main.start(Main.java:196) at org.apache.tools.ant.Main.main(Main.java:235) --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Unwrapping exceptions in client proxy
While fixing a bug I had to unwrap another ServerException in
JRMPInvokerProxy. I'm not really an expert on the exception handling here,
but shouldn't we be unwrapping a lot more exceptions, at least any
ServerException that wraps a RemoteException?
Here's the code:
try {
return ((MarshalledObject) remoteInvoker.invoke(mi)).get();
}
catch (ServerException ex) {
// Suns RMI implementation wraps NoSuchObjectException in
// a ServerException. We cannot have that if we want
// to comply with the spec, so we unwrap here.
if (ex.detail instanceof NoSuchObjectException)
{
throw (NoSuchObjectException) ex.detail;
}
//likewise
if (ex.detail instanceof TransactionRolledbackException)
{
throw (TransactionRolledbackException) ex.detail;
}
/* Shouldn't we unwrap _all_ remote exceptions with this code?
if (ex.detail instanceof RemoteException)
{
throw (RemoteException) ex.detail;
}
*/
throw ex;
}
Thanks
david jencks
---
In remembrance
www.osdn.com/911/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Unwrapping exceptions in client proxy
You should never get a ServerException that wraps a RemoteException
unless the application code did it. My major rewrite to the exception
code assures this. Actually, we should not need any of this unwrapping,
but it looks like the Sun RMI code is broken. When we get rid of the
Sun RMI code in 4.0 (moving to JBoss HTTP invoker) we should be able to
remove this unwrapping code.
-dain
David Jencks wrote:
While fixing a bug I had to unwrap another ServerException in
JRMPInvokerProxy. I'm not really an expert on the exception handling here,
but shouldn't we be unwrapping a lot more exceptions, at least any
ServerException that wraps a RemoteException?
Here's the code:
try {
return ((MarshalledObject) remoteInvoker.invoke(mi)).get();
}
catch (ServerException ex) {
// Suns RMI implementation wraps NoSuchObjectException in
// a ServerException. We cannot have that if we want
// to comply with the spec, so we unwrap here.
if (ex.detail instanceof NoSuchObjectException)
{
throw (NoSuchObjectException) ex.detail;
}
//likewise
if (ex.detail instanceof TransactionRolledbackException)
{
throw (TransactionRolledbackException) ex.detail;
}
/* Shouldn't we unwrap _all_ remote exceptions with this code?
if (ex.detail instanceof RemoteException)
{
throw (RemoteException) ex.detail;
}
*/
throw ex;
}
Thanks
david jencks
---
In remembrance
www.osdn.com/911/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
--
Dain Sundstrom
Chief Architect JBossCMP
JBoss Group, LLC
---
In remembrance
www.osdn.com/911/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Unwrapping exceptions in client proxy
AFAIK the sun rmi code wraps all RemoteExceptions into ServerExceptions: it
certainly does so for the TransactionRolledbackException. Is there any
chance that the jboss server code or an application would throw a
ServerException? If not I think this unwrapping should unwrap any
RemoteException inside a ServerException.
This is part of the fix for bug 606942 so something needs to change in at
least 3.2 as well as head. If the more general fix is appropriate I'd like
to use that.
thanks
david jencks
On 2002.09.11 13:42:24 -0400 Dain Sundstrom wrote:
You should never get a ServerException that wraps a RemoteException
unless the application code did it. My major rewrite to the exception
code assures this. Actually, we should not need any of this unwrapping,
but it looks like the Sun RMI code is broken. When we get rid of the
Sun RMI code in 4.0 (moving to JBoss HTTP invoker) we should be able to
remove this unwrapping code.
-dain
David Jencks wrote:
While fixing a bug I had to unwrap another ServerException in
JRMPInvokerProxy. I'm not really an expert on the exception handling
here,
but shouldn't we be unwrapping a lot more exceptions, at least any
ServerException that wraps a RemoteException?
Here's the code:
try {
return ((MarshalledObject) remoteInvoker.invoke(mi)).get();
}
catch (ServerException ex) {
// Suns RMI implementation wraps NoSuchObjectException in
// a ServerException. We cannot have that if we want
// to comply with the spec, so we unwrap here.
if (ex.detail instanceof NoSuchObjectException)
{
throw (NoSuchObjectException) ex.detail;
}
//likewise
if (ex.detail instanceof TransactionRolledbackException)
{
throw (TransactionRolledbackException) ex.detail;
}
/* Shouldn't we unwrap _all_ remote exceptions with this code?
if (ex.detail instanceof RemoteException)
{
throw (RemoteException) ex.detail;
}
*/
throw ex;
}
Thanks
david jencks
---
In remembrance
www.osdn.com/911/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
--
Dain Sundstrom
Chief Architect JBossCMP
JBoss Group, LLC
---
In remembrance
www.osdn.com/911/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
In remembrance
www.osdn.com/911/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Unwrapping exceptions in client proxy
A ServerException is a just RemoteException, so anything can throw one.
This is just another reason to get rid of the lame Sun RMI
implementation (JBoss 4.0). In the meantime, I agree that we (you) will
need to make patched to the unwrapping code.
-dain
David Jencks wrote:
AFAIK the sun rmi code wraps all RemoteExceptions into ServerExceptions: it
certainly does so for the TransactionRolledbackException. Is there any
chance that the jboss server code or an application would throw a
ServerException? If not I think this unwrapping should unwrap any
RemoteException inside a ServerException.
This is part of the fix for bug 606942 so something needs to change in at
least 3.2 as well as head. If the more general fix is appropriate I'd like
to use that.
thanks
david jencks
On 2002.09.11 13:42:24 -0400 Dain Sundstrom wrote:
You should never get a ServerException that wraps a RemoteException
unless the application code did it. My major rewrite to the exception
code assures this. Actually, we should not need any of this unwrapping,
but it looks like the Sun RMI code is broken. When we get rid of the
Sun RMI code in 4.0 (moving to JBoss HTTP invoker) we should be able to
remove this unwrapping code.
-dain
David Jencks wrote:
While fixing a bug I had to unwrap another ServerException in
JRMPInvokerProxy. I'm not really an expert on the exception handling
here,
but shouldn't we be unwrapping a lot more exceptions, at least any
ServerException that wraps a RemoteException?
Here's the code:
try {
return ((MarshalledObject) remoteInvoker.invoke(mi)).get();
}
catch (ServerException ex) {
// Suns RMI implementation wraps NoSuchObjectException in
// a ServerException. We cannot have that if we want
// to comply with the spec, so we unwrap here.
if (ex.detail instanceof NoSuchObjectException)
{
throw (NoSuchObjectException) ex.detail;
}
//likewise
if (ex.detail instanceof TransactionRolledbackException)
{
throw (TransactionRolledbackException) ex.detail;
}
/* Shouldn't we unwrap _all_ remote exceptions with this code?
if (ex.detail instanceof RemoteException)
{
throw (RemoteException) ex.detail;
}
*/
throw ex;
}
Thanks
david jencks
---
In remembrance
www.osdn.com/911/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Unwrapping exceptions in client proxy
This is just another reason to get rid of the lame Sun RMI implementation (JBoss 4.0). In the meantime, I agree that we we are not there yet, (you) will need to make patched to the unwrapping code. let's do the workaround marc f --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] error when buiding
You need to set the url search path to include org.jboss.net.protocol. Look at one of the build.sh or build.bat scripts for details. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of Emerson Cargnin - SICREDI Serviços Sent: Wednesday, September 11, 2002 9:11 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] error when buiding why do i get this error when building jboss-all?? ./build.sh Searching for build.xml ... Buildfile: /home/emersonc/eclipse/workspace/jboss/build.xml BUILD FAILED Error reading project file: unknown protocol: resource -- Emerson Cargnin SICREDI - Tel : 3358-4860 --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] Bug: EJB Handle not deserializable
Scott, thanks for your help. I tried to serialize the handle on the client after RMI transported it. That works fine. The problem is that my client is a servlet which runs in the same JVM and then it does not work and I have the same problems. I need to get the handle from one webapp context transfered to another webapp context which all runs under Jetty in the same VM. I guess the way you mentioned in the Bug is the correct way which involves something on your side. In the Bugtracker you said someting about V3.1. Is that coming soon and will you be able to this fixed? Thanks a lot --Marcus -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]Im Auftrag von Scott M Stark Gesendet: Montag, 9. September 2002 22:58 An: [EMAIL PROTECTED] Betreff: Re: [JBoss-dev] Bug: EJB Handle not deserializable The problem is that you are serializing the handle and then transporting that back to the client rather than letting the transport layer do the serialization. This fails because the JRMPInvoker is not being replaced by its remote stub. Either pass the handle back to the client and let the rmi transport layer handle the marshalling of the RMI object or handle replacement of RMI objects as is done in org.jboss.ejb.plugins.SessionObjectOutputStream Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Marcus Redeker [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 09, 2002 11:22 AM Subject: AW: Re: [JBoss-dev] Bug: EJB Handle not deserializable Is there any news on this? We would really like to move to JBoss3 but this is a showstopper. Maybe the problem is just the Base64 encoder we use to serialize the EJB handle into a String. But I do not know where to look. Maybe somebody can give me a hint. Thanks, --Marcus --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-606942 ] No TransRolledbackEx upon commit failure
Bugs item #606942, was opened at 2002-09-09 20:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=606942group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 5 Submitted By: Bob Cotton (bcotton969) Assigned to: David Jencks (d_jencks) Summary: No TransRolledbackEx upon commit failure Initial Comment: Summary: TxInterceptorCMT.runWithTransactions() in a transaction context of REQUIRED, will not throw a TransactionRolledbackException upon transaction commit failure. I have a JCA adaptor participating in a two-phase transaction. This JCA resource, upon commit, is failing due to a write-write conflict. This JCA resource is throwing a XAException, which is caught and handled by TxCapsule, who throws a RollbackException. My calling client is expecting to receive a TransactionRolledbackException, but this is not happening. Why is the client not recieving the proper exception? Here are the stacks: 2002-09-06 22:12:05,519 WARN [org.jboss.tm.TxCapsule] (RMI TCP Connection(4)-192.168.3.57) XAException: tx=XidImpl [F ormatId=257, GlobalId=malt//21, BranchQual=] errorCode=XA_RBROLLBACK javax.transaction.xa.XAException at com.gemstone.persistence.connection.internal.ContainerXAResource.prepare(ContainerXAResource.java:343) at org.jboss.tm.TxCapsule.prepareResources(TxCapsule.java:1587) at org.jboss.tm.TxCapsule.commit(TxCapsule.java:370) at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:73) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:201) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:60) at org.jboss.ejb.plugins.CleanShutdownInterceptor.invoke(CleanShutdownInterceptor.java:164) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:203) at org.jboss.ejb.StatefulSessionContainer.invoke(StatefulSessionContainer.java:380) at org.jboss.ejb.Container.invoke(Container.java:720) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:98) at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:102) at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:73) at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:76) at org.jboss.proxy.ejb.StatefulSessionInterceptor.invoke(StatefulSessionInterceptor.java:117) at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:76) at $Proxy103.processSell(Unknown Source) one more: Exception: Unable to commit, tx=XidImpl [FormatId=257, GlobalId=malt//21, BranchQual=] status=STATUS_ ROLLEDBACK 2002-09-06 22:12:05,553 ERROR [STDERR] (RMI TCP Connection(4)-192.168.3.57) at org.jboss.tm.TxCapsule.commit(TxCapsule.java:393) 2002-09-06 22:12:05,553 ERROR [STDERR] (RMI TCP Connection(4)-192.168.3.57) at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:73) 2002-09-06 22:12:05,554 ERROR [STDERR] (RMI TCP Connection(4)-192.168.3.57) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:201) 2002-09-06 22:12:05,554 ERROR [STDERR] (RMI TCP Connection(4)-192.168.3.57) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:60) 2002-09-06 22:12:05,554 ERROR [STDERR] (RMI TCP Connection(4)-192.168.3.57) at org.jboss.ejb.plugins.CleanShutdownInterceptor.invoke(CleanShutdownInterceptor.java:164) 2002-09-06 22:12:05,555 ERROR [STDERR] (RMI TCP Connection(4)-192.168.3.57) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:203) 2002-09-06 22:12:05,555 ERROR [STDERR] (RMI TCP Connection(4)-192.168.3.57) at org.jboss.ejb.StatefulSessionContainer.invoke(StatefulSessionContainer.java:380) 2002-09-06 22:12:05,556 ERROR [STDERR] (RMI TCP Connection(4)-192.168.3.57) at org.jboss.ejb.Container.invoke(Container.java:720) 2002-09-06 22:12:05,556 ERROR [STDERR] (RMI TCP Connection(4)-192.168.3.57) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) 2002-09-06 22:12:05,556 ERROR [STDERR] (RMI TCP Connection(4)-192.168.3.57) at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:98) 2002-09-06 22:12:05,557 ERROR [STDERR] (RMI TCP Connection(4)-192.168.3.57) at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:102) 2002-09-06 22:12:05,557 ERROR [STDERR] (RMI TCP Connection(4)-192.168.3.57) at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:73) 2002-09-06 22:12:05,557 ERROR [STDERR] (RMI TCP Connection(4)-192.168.3.57) at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:76) 2002-09-06 22:12:05,558 ERROR [STDERR] (RMI TCP Connection(4)-192.168.3.57) at
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 11-September-2002
Number of tests run: 934
Successful tests: 924
Errors:4
Failures: 6
[time of test: 11 September 2002 12:45 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
[java.vm.version: 1.3.1_03-69]
[java.vm.name: Java HotSpot(TM) Client VM]
[java.vm.info: mixed mode]
[os.name: Mac OS X]
[os.arch: ppc]
[os.version: 10.2]
See http://lubega.com/testarchive/${build.uid} for details of this test.
See http://lubega.com for general test information.
NOTE: If there are any errors shown above - this mail is only highlighting
them - it is NOT indicating that they are being looked at by anyone.
Remember - if a test becomes broken after your changes - fix it or fix the test!
Oh dear - still got some errors!
Thanks for all your effort - we really do love you!
---
In remembrance
www.osdn.com/911/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Deadlock retry interceptor
Hi deadlock lovers, I just did a deadlock-retry-interceptor, which was more easy than I thought. There is a serverside variant and a client interceptor. The interesting (i.e. non-perfect) points are: - how to configure retry strategy (quite simple now) - where to place the serverside thing in the chain (should be _outside_ of the transaction which just rolled back due to the deadlock; this probably implies that it could have to be done inside the TxInterceptor when entering a new tx. When _not_ doing RequiresNew the interceptor works fine between the SecutiyInterceptor and the TxInterceptor (I tried this with SLSB). - what to do with MDB (they are supposed to catch everything, so nothing gets through to the interceptor. My best guess is to use a UserTX inside the MDB, do the retry manually (w/o interceptor) and put all this in an AbstractDeadlockRetryMDB (I did this, it worked fine). Is there any interest to put this into Branch_3_2? Enjoy, Michael --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-606942 ] No TransRolledbackEx upon commit failure
Bugs item #606942, was opened at 2002-09-09 20:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=606942group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 5 Submitted By: Bob Cotton (bcotton969) Assigned to: David Jencks (d_jencks) Summary: No TransRolledbackEx upon commit failure Initial Comment: Summary: TxInterceptorCMT.runWithTransactions() in a transaction context of REQUIRED, will not throw a TransactionRolledbackException upon transaction commit failure. I have a JCA adaptor participating in a two-phase transaction. This JCA resource, upon commit, is failing due to a write-write conflict. This JCA resource is throwing a XAException, which is caught and handled by TxCapsule, who throws a RollbackException. My calling client is expecting to receive a TransactionRolledbackException, but this is not happening. Why is the client not recieving the proper exception? Here are the stacks: 2002-09-06 22:12:05,519 WARN [org.jboss.tm.TxCapsule] (RMI TCP Connection(4)-192.168.3.57) XAException: tx=XidImpl [F ormatId=257, GlobalId=malt//21, BranchQual=] errorCode=XA_RBROLLBACK javax.transaction.xa.XAException at com.gemstone.persistence.connection.internal.ContainerXAResource.prepare(ContainerXAResource.java:343) at org.jboss.tm.TxCapsule.prepareResources(TxCapsule.java:1587) at org.jboss.tm.TxCapsule.commit(TxCapsule.java:370) at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:73) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:201) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:60) at org.jboss.ejb.plugins.CleanShutdownInterceptor.invoke(CleanShutdownInterceptor.java:164) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:203) at org.jboss.ejb.StatefulSessionContainer.invoke(StatefulSessionContainer.java:380) at org.jboss.ejb.Container.invoke(Container.java:720) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:98) at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:102) at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:73) at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:76) at org.jboss.proxy.ejb.StatefulSessionInterceptor.invoke(StatefulSessionInterceptor.java:117) at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:76) at $Proxy103.processSell(Unknown Source) one more: Exception: Unable to commit, tx=XidImpl [FormatId=257, GlobalId=malt//21, BranchQual=] status=STATUS_ ROLLEDBACK 2002-09-06 22:12:05,553 ERROR [STDERR] (RMI TCP Connection(4)-192.168.3.57) at org.jboss.tm.TxCapsule.commit(TxCapsule.java:393) 2002-09-06 22:12:05,553 ERROR [STDERR] (RMI TCP Connection(4)-192.168.3.57) at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:73) 2002-09-06 22:12:05,554 ERROR [STDERR] (RMI TCP Connection(4)-192.168.3.57) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:201) 2002-09-06 22:12:05,554 ERROR [STDERR] (RMI TCP Connection(4)-192.168.3.57) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:60) 2002-09-06 22:12:05,554 ERROR [STDERR] (RMI TCP Connection(4)-192.168.3.57) at org.jboss.ejb.plugins.CleanShutdownInterceptor.invoke(CleanShutdownInterceptor.java:164) 2002-09-06 22:12:05,555 ERROR [STDERR] (RMI TCP Connection(4)-192.168.3.57) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:203) 2002-09-06 22:12:05,555 ERROR [STDERR] (RMI TCP Connection(4)-192.168.3.57) at org.jboss.ejb.StatefulSessionContainer.invoke(StatefulSessionContainer.java:380) 2002-09-06 22:12:05,556 ERROR [STDERR] (RMI TCP Connection(4)-192.168.3.57) at org.jboss.ejb.Container.invoke(Container.java:720) 2002-09-06 22:12:05,556 ERROR [STDERR] (RMI TCP Connection(4)-192.168.3.57) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) 2002-09-06 22:12:05,556 ERROR [STDERR] (RMI TCP Connection(4)-192.168.3.57) at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:98) 2002-09-06 22:12:05,557 ERROR [STDERR] (RMI TCP Connection(4)-192.168.3.57) at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:102) 2002-09-06 22:12:05,557 ERROR [STDERR] (RMI TCP Connection(4)-192.168.3.57) at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:73) 2002-09-06 22:12:05,557 ERROR [STDERR] (RMI TCP Connection(4)-192.168.3.57) at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:76) 2002-09-06 22:12:05,558 ERROR [STDERR] (RMI TCP Connection(4)-192.168.3.57) at
RE: [JBoss-dev] Deadlock retry interceptor
Great fucking idea! I shoulda thought of that. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Michael Bartmann Sent: Wednesday, September 11, 2002 4:07 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Deadlock retry interceptor Hi deadlock lovers, I just did a deadlock-retry-interceptor, which was more easy than I thought. There is a serverside variant and a client interceptor. I don't think you need a client interceptor. Only serverside. The reason? You need to do the retry outside the transaction. The transaction must be able to rollback before you can retry it. The interesting (i.e. non-perfect) points are: - how to configure retry strategy (quite simple now) - where to place the serverside thing in the chain (should be _outside_ of the transaction which just rolled back due to the deadlock; this probably implies that it could have to be done inside the TxInterceptor when entering a new tx. When _not_ doing RequiresNew the interceptor works fine between the SecutiyInterceptor and the TxInterceptor (I tried this with SLSB). You can only do a retry if the Beans starts a transaction. Required(if tx started) or RequiresNew. I think this stuff should be in the TxInterceptor, and maybe only the Container Managed one. - what to do with MDB (they are supposed to catch everything, so nothing gets through to the interceptor. My best guess is to use a UserTX inside the MDB, do the retry manually (w/o interceptor) and put all this in an AbstractDeadlockRetryMDB (I did this, it worked fine). Can't you put it in the TxInterceptor for MDB? Is there any interest to put this into Branch_3_2? Send it to me. I'll get it in. Its definately worth it. Bill --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Deadlock retry interceptor
On 2002.09.11 18:02:52 -0400 Bill Burke wrote: Great fucking idea! I shoulda thought of that. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Michael Bartmann Sent: Wednesday, September 11, 2002 4:07 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Deadlock retry interceptor Hi deadlock lovers, I just did a deadlock-retry-interceptor, which was more easy than I thought. There is a serverside variant and a client interceptor. I don't think you need a client interceptor. Only serverside. The reason? You need to do the retry outside the transaction. The transaction must be able to rollback before you can retry it. The interesting (i.e. non-perfect) points are: - how to configure retry strategy (quite simple now) - where to place the serverside thing in the chain (should be _outside_ of the transaction which just rolled back due to the deadlock; this probably implies that it could have to be done inside the TxInterceptor when entering a new tx. When _not_ doing RequiresNew the interceptor works fine between the SecutiyInterceptor and the TxInterceptor (I tried this with SLSB). You can only do a retry if the Beans starts a transaction. Required(if tx started) or RequiresNew. I think this stuff should be in the TxInterceptor, and maybe only the Container Managed one. - what to do with MDB (they are supposed to catch everything, so nothing gets through to the interceptor. My best guess is to use a UserTX inside the MDB, do the retry manually (w/o interceptor) and put all this in an AbstractDeadlockRetryMDB (I did this, it worked fine). Can't you put it in the TxInterceptor for MDB? Probably not. With the jca 1.5 message import, the transaction gets started by the adapter a little more explicitly than it does today. If the tx is rolled back, the adapter has to be the one to try to redeliver the message in a new tx. You'd have to really mutilate the jta stuff to make it so it looked to the container that you were trying again in a new transaction but looked to the adapter that the work was completed in the original tx it thinks it started. Maybe theres a way to do it, I sure don't see what it might be. Basically you need a savepoint in a jta tx. (accept message, mark savepoint, continue other work, roll back to savepoint on deadlock) thanks david jencks Is there any interest to put this into Branch_3_2? Send it to me. I'll get it in. Its definately worth it. Bill --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Deadlock retry interceptor
Hi Bill,
I'm glad you like the idea. It's very attractive for me to get code integrated
the right way, which I cannot do on my own (at least not on the first try).
Bill Burke wrote:
Great fucking idea! I shoulda thought of that.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
Michael Bartmann
Sent: Wednesday, September 11, 2002 4:07 PM
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] Deadlock retry interceptor
Hi deadlock lovers,
I just did a deadlock-retry-interceptor, which was more easy than
I thought.
There is a serverside variant and a client interceptor.
I don't think you need a client interceptor. Only serverside. The reason?
You need to do the retry outside the transaction. The transaction must be
able to rollback before you can retry it.
You are right, if the thing lives inside the TxInterceptor you don't need
it on the client side.
But i did not dare to touch that, and the client side is the best guess to
be outside of the tx to retry.
The interesting (i.e. non-perfect) points are:
- how to configure retry strategy (quite simple now)
- where to place the serverside thing in the chain (should be _outside_
of the transaction which just rolled back due to the deadlock; this
probably implies that it could have to be done inside the TxInterceptor
when entering a new tx.
When _not_ doing RequiresNew the interceptor works fine between the
SecutiyInterceptor and the TxInterceptor (I tried this with SLSB).
You can only do a retry if the Beans starts a transaction. Required(if tx
started) or RequiresNew. I think this stuff should be in the TxInterceptor,
and maybe only the Container Managed one.
- what to do with MDB (they are supposed to catch everything, so nothing
gets through to the interceptor. My best guess is to use a
UserTX inside
the MDB, do the retry manually (w/o interceptor) and put all this in
an AbstractDeadlockRetryMDB (I did this, it worked fine).
Can't you put it in the TxInterceptor for MDB?
I think you probably can. In my case there were some interactions with the
XAQueueSession. I didn't want to roll back the message consumption, which
was enlisted in the same context.
But this might be due to the fact that I used my own JMS Provider for which
I did a JBoss integration. The exact semantics of JBossMQ XARessource may vary...
Is there any interest to put this into Branch_3_2?
Send it to me. I'll get it in. Its definately worth it.
I've attached everything. It's quite simple.
Bill
Michael
/*
* JBoss, the OpenSource J2EE webOS
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jboss.ejb.plugins;
import java.rmi.*;
import javax.ejb.*;
import org.jboss.ejb.*;
import org.jboss.ejb.plugins.lock.*;
import org.jboss.invocation.*;
import org.jboss.logging.*;
/**
* This interceptor retries when hitting an ApplicationDeadlockException.
*
* @author Michael Bartmann
* @version $Revision:$
*/
public class ADERetryInterceptor extends AbstractInterceptor
{
private static Logger log = Logger.getLogger(ADERetryInterceptor.class);
// we could replace this with a more sophisticated strategy...
private long retryMillis[] = new long[]{0,0,1,1,10,10,100,100,1000,1000,3000,3000,3000,3000,3000,3000};
/**
* Detects if a Throwable is or contains an ApplicationDeadlockException.
* The basic pattern is borrowed from the JBoss documentation and extended
* to support TransactionRolledbackLocalException.
* @param t the Throwable to test
* @return true if the argument is or contains an ApplicationDeadlockException
*/
public static boolean isOrContainsADE(Throwable t)
{
while (t!=null)
{
if (t instanceof ApplicationDeadlockException)
{
return true;
}
else if (t instanceof RemoteException)
{
t = ((RemoteException)t).detail;
}
else if (t instanceof TransactionRolledbackLocalException)
{
t = ((TransactionRolledbackLocalException)t).getCausedByException();
}
else
{
return false;
}
}
return false;
}
private Container container;
public void setContainer(Container container)
{
this.container = container;
}
public Container getContainer()
{
return container;
}
public Object invoke(Invocation invocation) throws Exception
{
int count = 0;
do
{
try
{
return getNext().invoke(invocation);
}
catch (Exception ex)
{
if ((isOrContainsADE(ex))&&(count
[JBoss-dev] [ jboss-Bugs-606942 ] No TransRolledbackEx upon commit failure
Bugs item #606942, was opened at 2002-09-09 20:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=606942group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 5 Submitted By: Bob Cotton (bcotton969) Assigned to: David Jencks (d_jencks) Summary: No TransRolledbackEx upon commit failure Initial Comment: Summary: TxInterceptorCMT.runWithTransactions() in a transaction context of REQUIRED, will not throw a TransactionRolledbackException upon transaction commit failure. I have a JCA adaptor participating in a two-phase transaction. This JCA resource, upon commit, is failing due to a write-write conflict. This JCA resource is throwing a XAException, which is caught and handled by TxCapsule, who throws a RollbackException. My calling client is expecting to receive a TransactionRolledbackException, but this is not happening. Why is the client not recieving the proper exception? Here are the stacks: 2002-09-06 22:12:05,519 WARN [org.jboss.tm.TxCapsule] (RMI TCP Connection(4)-192.168.3.57) XAException: tx=XidImpl [F ormatId=257, GlobalId=malt//21, BranchQual=] errorCode=XA_RBROLLBACK javax.transaction.xa.XAException at com.gemstone.persistence.connection.internal.ContainerXAResource.prepare(ContainerXAResource.java:343) at org.jboss.tm.TxCapsule.prepareResources(TxCapsule.java:1587) at org.jboss.tm.TxCapsule.commit(TxCapsule.java:370) at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:73) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:201) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:60) at org.jboss.ejb.plugins.CleanShutdownInterceptor.invoke(CleanShutdownInterceptor.java:164) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:203) at org.jboss.ejb.StatefulSessionContainer.invoke(StatefulSessionContainer.java:380) at org.jboss.ejb.Container.invoke(Container.java:720) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:98) at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:102) at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:73) at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:76) at org.jboss.proxy.ejb.StatefulSessionInterceptor.invoke(StatefulSessionInterceptor.java:117) at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:76) at $Proxy103.processSell(Unknown Source) one more: Exception: Unable to commit, tx=XidImpl [FormatId=257, GlobalId=malt//21, BranchQual=] status=STATUS_ ROLLEDBACK 2002-09-06 22:12:05,553 ERROR [STDERR] (RMI TCP Connection(4)-192.168.3.57) at org.jboss.tm.TxCapsule.commit(TxCapsule.java:393) 2002-09-06 22:12:05,553 ERROR [STDERR] (RMI TCP Connection(4)-192.168.3.57) at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:73) 2002-09-06 22:12:05,554 ERROR [STDERR] (RMI TCP Connection(4)-192.168.3.57) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:201) 2002-09-06 22:12:05,554 ERROR [STDERR] (RMI TCP Connection(4)-192.168.3.57) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:60) 2002-09-06 22:12:05,554 ERROR [STDERR] (RMI TCP Connection(4)-192.168.3.57) at org.jboss.ejb.plugins.CleanShutdownInterceptor.invoke(CleanShutdownInterceptor.java:164) 2002-09-06 22:12:05,555 ERROR [STDERR] (RMI TCP Connection(4)-192.168.3.57) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:203) 2002-09-06 22:12:05,555 ERROR [STDERR] (RMI TCP Connection(4)-192.168.3.57) at org.jboss.ejb.StatefulSessionContainer.invoke(StatefulSessionContainer.java:380) 2002-09-06 22:12:05,556 ERROR [STDERR] (RMI TCP Connection(4)-192.168.3.57) at org.jboss.ejb.Container.invoke(Container.java:720) 2002-09-06 22:12:05,556 ERROR [STDERR] (RMI TCP Connection(4)-192.168.3.57) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) 2002-09-06 22:12:05,556 ERROR [STDERR] (RMI TCP Connection(4)-192.168.3.57) at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:98) 2002-09-06 22:12:05,557 ERROR [STDERR] (RMI TCP Connection(4)-192.168.3.57) at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:102) 2002-09-06 22:12:05,557 ERROR [STDERR] (RMI TCP Connection(4)-192.168.3.57) at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:73) 2002-09-06 22:12:05,557 ERROR [STDERR] (RMI TCP Connection(4)-192.168.3.57) at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:76) 2002-09-06 22:12:05,558 ERROR [STDERR] (RMI TCP Connection(4)-192.168.3.57) at
RE: [JBoss-dev] Unwrapping exceptions in client proxy
This is just another reason to get rid of the lame Sun RMI implementation (JBoss 4.0). In the meantime, I agree that we we are not there yet, You guys talking about replacing RMI for the remote EJB invocations?? Isn't that what we have the JBoss.IIOP and JBoss.Net projects?? Regards, Hiram (you) will need to make patched to the unwrapping code. let's do the workaround marc f --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Deadlock retry interceptor
I think so too, because it's a real pain to do retrying from client code We spent a great deal of time eliminating deadlocks in our application. For what it's worth, my fix for bug #601097 eliminated many of them. On Thursday, September 12, 2002, at 08:02 AM, Bill Burke wrote: Great fucking idea! I shoulda thought of that. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Michael Bartmann Sent: Wednesday, September 11, 2002 4:07 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Deadlock retry interceptor Hi deadlock lovers, I just did a deadlock-retry-interceptor, which was more easy than I thought. There is a serverside variant and a client interceptor. I don't think you need a client interceptor. Only serverside. The reason? You need to do the retry outside the transaction. The transaction must be able to rollback before you can retry it. The interesting (i.e. non-perfect) points are: - how to configure retry strategy (quite simple now) - where to place the serverside thing in the chain (should be _outside_ of the transaction which just rolled back due to the deadlock; this probably implies that it could have to be done inside the TxInterceptor when entering a new tx. When _not_ doing RequiresNew the interceptor works fine between the SecutiyInterceptor and the TxInterceptor (I tried this with SLSB). You can only do a retry if the Beans starts a transaction. Required(if tx started) or RequiresNew. I think this stuff should be in the TxInterceptor, and maybe only the Container Managed one. - what to do with MDB (they are supposed to catch everything, so nothing gets through to the interceptor. My best guess is to use a UserTX inside the MDB, do the retry manually (w/o interceptor) and put all this in an AbstractDeadlockRetryMDB (I did this, it worked fine). Can't you put it in the TxInterceptor for MDB? Is there any interest to put this into Branch_3_2? Send it to me. I'll get it in. Its definately worth it. Bill --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Unwrapping exceptions in client proxy
these are invokers yes, but they are not RMI re-implementations. marc f -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Hiram Chirino Sent: Wednesday, September 11, 2002 8:33 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Unwrapping exceptions in client proxy This is just another reason to get rid of the lame Sun RMI implementation (JBoss 4.0). In the meantime, I agree that we we are not there yet, You guys talking about replacing RMI for the remote EJB invocations?? Isn't that what we have the JBoss.IIOP and JBoss.Net projects?? Regards, Hiram (you) will need to make patched to the unwrapping code. let's do the workaround marc f --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(HEAD Matrix2) Testsuite Results: 12-September-2002
Number of tests run: 905 Successful tests: 881 Errors:19 Failures: 5 [time of test: 12 September 2002 2:6 GMT] [java.version: 1.3.1_03] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1_03-b03] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-34] Useful resources: - http://lubega.com/testarchive/sun_jdk131_03 for the junit report of this test. - http://lubega.com/testarchive/sun_jdk131_03/logs/ for the logs for this test. - http://lubega.com for general test information. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-595258 ] CM hands out connections alreay in use
Bugs item #595258, was opened at 2002-08-14 21:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=595258group_id=22866 Category: JBossCX Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 5 Submitted By: Bruce Schuchardt (bruceschuchardt) Assigned to: David Jencks (d_jencks) Summary: CM hands out connections alreay in use Initial Comment: Our JCA connector is for a resource that has a tight coupling between the JCA connection and a transaction. A connection cannot be simultaneously used in two transactions, regardless of any start/end operations sent to the associated XAResource. The JBoss connection manager doesn't seem to support this kind of resource. It blithely hands out the same connection two concurrently executing threads and expects the connector to force its resource into a model that allows this. With our resource this just isn't possible. The resource is for an object database. Beans using a connection to this resource will access persistent objects with the connection, and those objects are intimately tied to both the connection and to the connection's transaction (not the JTA transaction, but the native object-database transaction). Handing out the same connection to another thread allows that thread to access objects in the same object- database transaction. I've had exchanges on this subject in the JBoss CX forum that boil down to JBoss doesn't support that kind of resource yet. I'm entering this bug report so the issue can be tracked for development. We are currently using a workaround that causes our ManagedConnectionFactory to notice if a connection handed to it is in a transaction and, if so, stall until the connection is out of the transaction before returning it to the connection manager. The best solution for us would be for the connection manager to not pass matchManagedConnections a connection that is currently being used by a bean. Another satisfactory solution would be to have the connection manager pass all pooled connections to matchManagedConnections so that we could make our own selection of an appropriate connection. The local-transaction connection manager does not have this problem, but we support XA voting and need to be able to participate in a two-phase commit with a relational database. Some of our customers would be satisfied with local-transaction processing, but not all of them. -- Comment By: David Jencks (d_jencks) Date: 2002-09-12 01:26 Message: Logged In: YES user_id=60525 This is now ported to jboss 3.2. Bruce reports that it works with the gemstone adapter so I am closing this. -- Comment By: David Jencks (d_jencks) Date: 2002-09-09 04:21 Message: Logged In: YES user_id=60525 I've refactored the connection managers in cvs head (jboss 4) to modularize the localTransaction and matchConnectionToTx functionalities. I think your adapter should work now if you replace mbean code=org.jboss.resource.connectionmanager.XaTxConnectionManager name=jboss.jca:service=XaTxCM,name=FirebirdDS mbean code=org.jboss.resource.connectionmanager.TxConnectionManager name=jboss.jca:service=XaTxCM,name=FirebirdDS attribute name=TrackConnectionByTxtrue/attribute Please test this. If this works I'll consider backporting it to 3.2. -- Comment By: David Jencks (d_jencks) Date: 2002-09-04 17:58 Message: Logged In: YES user_id=60525 In order to support the scenario you layed out, the XAResource would have to switch the physical connection held by the connection handle to a different physical connection, BUT it can't do this because XAResources aren't told what connection handle the container has handed out to the app. IMO this is one of the gaps between XA and JCA that make it difficult to adhere strictly to the XA standard when implementing a connection manager. I think the jca spec assumes that you are starting with an EIS that supports the full xa spec, including multiple open tx on one physical connection (see my previous quote). If you don't have that, you may have to bend the spec a little. It's really unfortunate that xa, jta, and jca don't have actual complete requirements or a usable test suite to find out what should be supported. If you stop thinking of the managed connection as being tied permanently to a physical connection, and have one XAResource for each ManagedConnection, you can easily associate the ManagedConnection with an appropriate physical connection when the XAResource gets a start request. There are also pragmatic consequences to switching the physical connection associated with a handle. For instance, it will be very easy for a programmer to make a mistake like this in a bean-managed transaction sequence: c =
[JBoss-dev] [ jboss-Change Notes-608163 ] ConnectionManager can tie cx to tx
Change Notes item #608163, was opened at 2002-09-12 02:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=381174aid=608163group_id=22866 Category: JBossCX Group: v4.0 Status: Open Priority: 5 Submitted By: David Jencks (d_jencks) Assigned to: David Jencks (d_jencks) Summary: ConnectionManager can tie cx to tx Initial Comment: Prompted by several adapters and jms systems that provide (what I regard as) only partial xa support, I've refactored the ConnectionManagers for jboss 3.2 and 4 to support additional capabilites. These may often be useful and result in faster speeds with completely compliant adapters also. The new capability is to have a xa connection manager keep a ManagedConnection/XAResource associated with a transaction from the time it first knows about the tx to commit/rollback. Advantages: repeated end(suspend) start(resume) call pairs are avoided, presumably reducing traffic to the EIS and speeding up your work. This also allows the use of adapters that require all work in a transaction to go over the same connection, or that do not allow end(xid1) start(xid2) calls on the same ManagedConnection. Disadvantages: This can result in the same kind of resource starvation/deadlock as local tx adapters are susceptible to. If your typical unit of work involves a transaction in which a requires new operation is executed, it is entirely possible for all connections to be used in the outer transaction thus leaving none available for the requires new operation. In some circumstances it may result in much less efficient use of connections, for instance if a transaction does work on EIS A, then lengthy work on EIS B, then more work on EIS A. If connections to EIS A are released through end(suspend) calls, they may do work in other transactions while the work on EIS B completes. Using the new capability, they will be unavailable until the entire transaction completes. How to use: set matchConnectionToTransaction true in the XATxConnectionManager configuration. Note that both LocalTxConnectionManager and XATxConnectionmanager are now legacy wrappers solely for backward compatibility. All functionality is in the new TxConnectionManager, which may be set up to use local or xa tx, and to match or not match connections to tx. I anticipate changing the xslt script soon to use just the TxConnectionManager with the appropriate flags. Change in 3.2 functionality: In order to work around limitations of a jms implementation, the xa delist operation resulting from a connection handle close was previously changed to use end(success) in branch 3.2. It has been changed back to the more spec compliant end(suspend). Adapters that cannot accept this call should tie the connection to the tx so suspend/resume will never be called. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=381174aid=608163group_id=22866 --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] is pooling useless?
Well, if you are pooling fine grained objects you should not
use java.util.LinkedList to implement the pool. Whenever you
add an element to a LinkedList you are creating an auxiliary
Entry object, with fields `element', `next', and `previous'.
To do pooling of fine grained objects you should add a `next'
field to the objects you are pooling and use your own linked
list implementation. Otherwise you are trading the creation of
pooled objects by the creation of Entry objects plus the
sychronization cost. Not a good deal.
Some time ago I had to optimize critical-path code and a pool
of fine-grained objects (linked together by a `next' field within
each object) was very useful.
Cheers,
Francisco
On Wed, 11 Sep 2002, David Jencks wrote:
Pooling is mostly useful if the object holds an expensive resource such as
a database connection. For just plain data I think the synchronization
costs of pooling things tend to outweigh the construction costs of making
new ones pretty quickly. Ole recently removed the (pooled) TxCapsule in
favor of new-each-time TransactionImpl for this reason.
Your results are fun to contemplate, though.
david jencks
On 2002.09.10 23:59:40 -0400 Bill Burke wrote:
I was looking into pooling Invocation objects so I thought I'd test to
see
if it is actually better. With this test case, its about 4% faster to
pool
on JDK 1.3.1 Win2k.
With JDK 1.4.0 on Win2k, Non-pooling is actually 7% faster!
import java.util.*;
public class testpool
{
HashMap trans;
HashMap as;
HashMap pay;
public testpool()
{
trans = new HashMap();
as = new HashMap();
pay = new HashMap();
}
public void clear()
{
trans.clear();
as.clear();
pay.clear();
}
public void addStuff()
{
for (int i = 0; i 5; i++)
{
trans.put(new Integer(i), new Integer(i));
as.put(new Integer(i), new Integer(i));
pay.put(new Integer(i), new Integer(i));
}
}
public static LinkedList pool = new LinkedList();
public static void main(String[] args)
{
long start;
long end;
System.out.println(testing non pool);
start = System.currentTimeMillis();
for (int i = 0; i 100; i++)
{
testpool p = new testpool();
p.addStuff();
}
end = System.currentTimeMillis() - start;
System.out.println(time: + end);
System.out.println(testing pool);
start = System.currentTimeMillis();
for (int i = 0; i 100; i++)
{
testpool p = null;
if (pool.isEmpty()) p = new testpool();
else
{
synchronized(pool)
{
p = (testpool)pool.removeFirst();
}
}
if (p == null) p = new testpool();
p.addStuff();
p.clear();
synchronized(pool)
{
pool.add(p);
}
}
end = System.currentTimeMillis() - start;
System.out.println(time: + end);
}
}}
---
In remembrance
www.osdn.com/911/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
In remembrance
www.osdn.com/911/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
In remembrance
www.osdn.com/911/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Deadlock retry interceptor
Great catch! I'll commit this ASAP. Thanks for finding this. You may have actually solved one of my problems. :) Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Stephen Coy Sent: Wednesday, September 11, 2002 8:37 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Deadlock retry interceptor I think so too, because it's a real pain to do retrying from client code We spent a great deal of time eliminating deadlocks in our application. For what it's worth, my fix for bug #601097 eliminated many of them. On Thursday, September 12, 2002, at 08:02 AM, Bill Burke wrote: Great fucking idea! I shoulda thought of that. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Michael Bartmann Sent: Wednesday, September 11, 2002 4:07 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Deadlock retry interceptor Hi deadlock lovers, I just did a deadlock-retry-interceptor, which was more easy than I thought. There is a serverside variant and a client interceptor. I don't think you need a client interceptor. Only serverside. The reason? You need to do the retry outside the transaction. The transaction must be able to rollback before you can retry it. The interesting (i.e. non-perfect) points are: - how to configure retry strategy (quite simple now) - where to place the serverside thing in the chain (should be _outside_ of the transaction which just rolled back due to the deadlock; this probably implies that it could have to be done inside the TxInterceptor when entering a new tx. When _not_ doing RequiresNew the interceptor works fine between the SecutiyInterceptor and the TxInterceptor (I tried this with SLSB). You can only do a retry if the Beans starts a transaction. Required(if tx started) or RequiresNew. I think this stuff should be in the TxInterceptor, and maybe only the Container Managed one. - what to do with MDB (they are supposed to catch everything, so nothing gets through to the interceptor. My best guess is to use a UserTX inside the MDB, do the retry manually (w/o interceptor) and put all this in an AbstractDeadlockRetryMDB (I did this, it worked fine). Can't you put it in the TxInterceptor for MDB? Is there any interest to put this into Branch_3_2? Send it to me. I'll get it in. Its definately worth it. Bill --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-601097 ] Race cond in QueuedPessimisticEJBLock
Bugs item #601097, was opened at 2002-08-27 21:45
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=601097group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Stephen Coy (scoy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Race cond in QueuedPessimisticEJBLock
Initial Comment:
I believe that I have uncovered a race condition in
QueuedPessimisticEJBLock that
causes the deadlock detector to misfire.
We have an entity bean with interface:
public interface Designation
extends javax.ejb.EJBObject
{
public java.lang.String getCode( ) throws
java.rmi.RemoteException;
public java.lang.String getDisplay( ) throws
java.rmi.RemoteException;
}
The bean is configured with commit option A and the get*
methods are read-only.
Two threads A and B each begin a new trx and begin iterating over
a collection of
these beans, calling getCode and getDisplay on each one. Thread
A is running
slightly ahead of thread B. (we are building a popup menu in a
JSP).
At some point, thread A is delayed slightly while it loads data
during its invoke
of getCode and thread B catches up with it. Thread B blocks in
QueuedPessimisticEJBLock.waitForTx because thread A has the
lock. Prior to
blocking it adds an entry to the BeanLockSupport.waiting
HashMap.
Thread A completes its invokation of getCode and the following
methods of
QueuedPessimisticEJBLock get called:
1. endInvocation
2. endTransaction
3. nextTransaction
Amongst other things, nextTransaction sets the lock's tx to that of
thread B
and wakes up thread B.
This is where the race begins.
Thread A subsequently calls getDisplay on the same bean and
enters waitForTx.
It's mi tx is now different to the lock's tx, so it enters the wait loop
and adds an entry to the BeanLockSupport.waiting HashMap.
Thread B has not yet run to the end of waitForTx, so it's entry is
still
sitting in the BeanLockSupport.waiting HashMap.
Thread A runs BeanLockSupport.deadlockDetection and it finds
thread B's
entry that says it's waiting on thread A's lock, because thread B
has not
got around to removing it yet.
BeanLockSupport.deadlockDetection throws
ApplicationDeadlockException, even
though there is no real deadlock present.
I'm going to try and fix it, but I know this is a sensitive area and
you guys
will probably have your own ideas on the best way.
I'm running MacOS 10.1.5 and the corresponding Apple 1.3.1
JRE, for what it's worth.
--
Comment By: Stephen Coy (scoy)
Date: 2002-08-28 02:55
Message:
Logged In: YES
user_id=463096
This little patch seems to fix it for us.
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/lock/
QueuedPessimisticEJBLock.java,v
retrieving revision 1.9.2.2
diff -r1.9.2.2 QueuedPessimisticEJBLock.java
417c417,421
this.tx = thelock.tx;
---
synchronized (waiting)
{
waiting.remove(thelock.tx);
this.tx = thelock.tx;
}
It goes into the nextTransaction method, but it should be reviewed by
the person who added the comment:
// The new transaction is the next one, important to set it up to avoid
race with
// new incoming calls
I could previously generate the problem at will, but it no longer seems to
happen with this change.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=601097group_id=22866
---
In remembrance
www.osdn.com/911/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Change Notes-608189 ] Entity Lock Monitor added
Change Notes item #608189, was opened at 2002-09-11 23:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=381174aid=608189group_id=22866 Category: None Group: v3.2 Status: Open Priority: 5 Submitted By: Bill Burke (patriot1burke) Assigned to: Nobody/Anonymous (nobody) Summary: Entity Lock Monitor added Initial Comment: look in jboss-service.xml and uncomment it. Allows you to find out num lock contentions, time for lock contentions and other shit. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=381174aid=608189group_id=22866 --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-608202 ] EJBQL fails to compile
Bugs item #608202, was opened at 2002-09-12 15:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=608202group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Cory Prowse (cosmic) Assigned to: Nobody/Anonymous (nobody) Summary: EJBQL fails to compile Initial Comment: OS: Linux (2.4 kernel) JDK: java version 1.4.0_01 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_01-b03) Java HotSpot(TM) Client VM (build 1.4.0_01-b03, mixed mode) JBoss Release: JBoss-3.0.2 CVSTag=JBoss_3_0_2 NOTE: I will try and cut out a test case but it may take a few days (deadline). A workaround is to use OBJECT() and get the field that way. When I attempt the following EJBQL: query query-method method-nameejbSelectCargoValue/method-name method-params method-parampacket.interfaces.PacketEntityLocal/method-param method-paramjava.lang.String/method-param /method-params /query-method ejb-ql[CDATA[SELECT c.value FROM PacketEntity p, IN (p.cargoes) AS c WHERE p = ?1 AND c.name = ?2]]/ejb-ql /query I get the following exception: org.jboss.deployment.DeploymentException: Error compiling ejbql; - nested throwable: (java.lang.IllegalStateException: Can not visit multi-column path node. Should have been handled at a higher level.) at org.jboss.ejb.plugins.cmp.jdbc.JDBCEJBQLQuery.init(JDBCEJBQLQuery.java:46) at org.jboss.ejb.plugins.cmp.jdbc.JDBCCommandFactory.createEJBQLQuery(JDBCCommandFactory.java:44) at org.jboss.ejb.plugins.cmp.jdbc.JDBCQueryManager.start(JDBCQueryManager.java:214) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.startStoreManager(JDBCStoreManager.java:463) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.start(JDBCStoreManager.java:369) at org.jboss.ejb.plugins.CMPPersistenceManager.start(CMPPersistenceManager.java:198) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=608202group_id=22866 --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
