[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=detail&atid=376685&aid=594137&group_id=22866 Category: JBossSOAP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Marius Kotsbak (mkotsbak) Assigned to: Nobody/Anonymous (nobody) Summary: SOAPAction not set Initial Comment: The auto-generated wsdl-file is missing soapAction, whch should be th e same as " HERE -> V ***HERE->*** http://schemas.xmlsoap.org/soap/encoding/"; namespace="xxx"/> http://schemas.xmlsoap.org/soap/encoding/"; namespace="xxx"/> -- >Comment By: Dr. Christoph Georg Jung (cgjung) Date: 2002-09-09 09:36 Message: Logged In: YES user_id=175199 Which provider do you refer to? If this is a bug, then it would be an Axis bug, because we fully rely on, e.g., the EJBProvider and the embedded wsdl- Emitter. IMHO, they do not use setSoapAction(Operation) simply because in the usual transport chain, the soap action is not necessarily evaluated (most of the time you use a urlmapper and encode the target service via a url-suffix). Furthermore, I have no problems with the .NET wsdl.exe even when soapAction is not defined (which is reasonable, because it is not needed in this case). What do you want me to do about this issue. Include an (IMHO wrong) default into complete jboss.net that behaves different from Axis? CGJ -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=594137&group_id=22866 --- 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=sourceforge1&refcode1=vs3390 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] JBoss.net now supports Axis RC1
I just sent a reply to your bug-report that it is IMHO not a jboss.net bug. CGJ -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Gesendet: Samstag, 7. September 2002 10:21 An: [EMAIL PROTECTED] Betreff: Re: [JBoss-dev] JBoss.net now supports Axis RC1 Is the problem with empty soapaction fixed (see buglist under jboss.net-category). On Fri, Sep 06, 2002 at 06:49:35PM +0200, Jung , Dr. Christoph wrote: > One of the most requested features is now in "head" (along with some > bugfixes and some nice deployment structure changes that remove the > dependency of AxisService to the WebContainer). > > Axis will go 1.0 in a week or so which should be trivial to > incorporate then. > > Are there any special backport requirements? Otherwise, I would go > reintegrating it into 3.2, then. > > Best, > CGJ > > ### > > This message has been scanned by F-Secure Anti-Virus for Microsoft > Exchange. For more information, connect to http://www.F-Secure.com/ -- MVH Marius Kotsbak Boost communications AS --- 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=sourceforge1&refcode1=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/ --- 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=sourceforge1&refcode1=vs3390 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[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=detail&atid=376685&aid=594137&group_id=22866 Category: JBossSOAP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Marius Kotsbak (mkotsbak) Assigned to: Nobody/Anonymous (nobody) Summary: SOAPAction not set Initial Comment: The auto-generated wsdl-file is missing soapAction, whch should be th e same as " HERE -> V ***HERE->*** http://schemas.xmlsoap.org/soap/encoding/"; namespace="xxx"/> http://schemas.xmlsoap.org/soap/encoding/"; namespace="xxx"/> -- >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 the embedded wsdl- >Emitter. OK. I wasn't sure, so I posted it here first. Could you post this on the axis bug list? >IMHO, they do not use setSoapAction(Operation) simply >because in the usual transport chain, the soap action is not >necessarily evaluated (most of the time you use a urlmapper >and encode the target service via a url-suffix). >Furthermore, I have no problems with the .NET wsdl.exe even >when soapAction is not defined (which is reasonable, >because it is not needed in this case). The problem is that MS toolkit (at least in 2.0, haven't tried 3.0 yet) relies on only soapAction, and fails when it's empty, maybe because it uses soap, and net .net or webservice. And if the field is supposed to be empty, couldn't it just have been removed? >What do you want me to do about this issue. Include an >(IMHO wrong) default into complete jboss.net that behaves >different from Axis? If this field is missing in the newest jboss (newest cvs with the newest axis integrated), can you post a bug report like this on the axis list? --Marius -- Comment By: Dr. Christoph Georg Jung (cgjung) Date: 2002-09-09 09:36 Message: Logged In: YES user_id=175199 Which provider do you refer to? If this is a bug, then it would be an Axis bug, because we fully rely on, e.g., the EJBProvider and the embedded wsdl- Emitter. IMHO, they do not use setSoapAction(Operation) simply because in the usual transport chain, the soap action is not necessarily evaluated (most of the time you use a urlmapper and encode the target service via a url-suffix). Furthermore, I have no problems with the .NET wsdl.exe even when soapAction is not defined (which is reasonable, because it is not needed in this case). What do you want me to do about this issue. Include an (IMHO wrong) default into complete jboss.net that behaves different from Axis? CGJ -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=594137&group_id=22866 --- 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=sourceforge1&refcode1=vs3390 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss.net now supports Axis RC1
On Mon, Sep 09, 2002 at 09:38:21AM +0200, Jung , Dr. Christoph wrote: > I just sent a reply to your bug-report that it is IMHO not a jboss.net bug. Reponded to it right now. > > CGJ > > -Ursprüngliche Nachricht- > Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Gesendet: Samstag, 7. September 2002 10:21 > An: [EMAIL PROTECTED] > Betreff: Re: [JBoss-dev] JBoss.net now supports Axis RC1 > > > Is the problem with empty soapaction fixed (see buglist under > jboss.net-category). > > > On Fri, Sep 06, 2002 at 06:49:35PM +0200, Jung , Dr. Christoph wrote: > > One of the most requested features is now in "head" (along with some > > bugfixes and some nice deployment structure changes that remove the > > dependency of AxisService to the WebContainer). > > > > Axis will go 1.0 in a week or so which should be trivial to > > incorporate then. > > > > Are there any special backport requirements? Otherwise, I would go > > reintegrating it into 3.2, then. > > > > Best, > > CGJ > > > > ### > > > > This message has been scanned by F-Secure Anti-Virus for Microsoft > > Exchange. For more information, connect to http://www.F-Secure.com/ > > -- > MVH > Marius Kotsbak > Boost communications AS > > > --- > 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=sourceforge1&refcode1=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/ > > > --- > 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___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development -- MVH Marius Kotsbak Boost communications AS --- 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=sourceforge1&refcode1=vs3390 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[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=detail&atid=376685&aid=594137&group_id=22866
Category: JBossSOAP
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Marius Kotsbak (mkotsbak)
Assigned to: Nobody/Anonymous (nobody)
Summary: SOAPAction not set
Initial Comment:
The auto-generated wsdl-file is missing soapAction,
whch should be th e same as " HERE -> V
***HERE->***
http://schemas.xmlsoap.org/soap/encoding/";
namespace="xxx"/>
http://schemas.xmlsoap.org/soap/encoding/";
namespace="xxx"/>
--
>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 the embedded wsdl-
>Emitter.
OK. I wasn't sure, so I posted it here first. Could you post
this on the axis bug list?
>IMHO, they do not use setSoapAction(Operation) simply
>because in the usual transport chain, the soap action is not
>necessarily evaluated (most of the time you use a urlmapper
>and encode the target service via a url-suffix).
>Furthermore, I have no problems with the .NET wsdl.exe even
>when soapAction is not defined (which is reasonable,
>because it is not needed in this case).
The problem is that MS toolkit (at least in 2.0, haven't
tried 3.0 yet) relies on only soapAction, and fails when
it's empty, maybe because it uses soap, and net .net or
webservice. And if the field is supposed to be empty,
couldn't it just have been removed?
>What do you want me to do about this issue. Include an
>(IMHO wrong) default into complete jboss.net that behaves
>different from Axis?
If this field is missing in the newest jboss (newest cvs
with the newest axis integrated), can you post a bug report
like this on the axis list?
--Marius
--
Comment By: Dr. Christoph Georg Jung (cgjung)
Date: 2002-09-09 09:36
Message:
Logged In: YES
user_id=175199
Which provider do you refer to?
If this is a bug, then it would be an Axis bug, because we
fully rely on, e.g., the EJBProvider and the embedded wsdl-
Emitter.
IMHO, they do not use setSoapAction(Operation) simply
because in the usual transport chain, the soap action is not
necessarily evaluated (most of the time you use a urlmapper
and encode the target service via a url-suffix).
Furthermore, I have no problems with the .NET wsdl.exe even
when soapAction is not defined (which is reasonable,
because it is not needed in this case).
What do you want me to do about this issue. Include an
(IMHO wrong) default into complete jboss.net that behaves
different from Axis?
CGJ
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=594137&group_id=22866
---
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=sourceforge1&refcode1=vs3390
___
Jboss-development mailing list
[EMAI
[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=detail&atid=376685&aid=594137&group_id=22866
Category: JBossSOAP
Group: v3.0 Rabbit Hole
Status: Open
>Resolution: Remind
Priority: 5
Submitted By: Marius Kotsbak (mkotsbak)
>Assigned to: Ceki Gulcu (cgu)
Summary: SOAPAction not set
Initial Comment:
The auto-generated wsdl-file is missing soapAction,
whch should be th e same as " HERE -> V
***HERE->***
http://schemas.xmlsoap.org/soap/encoding/";
namespace="xxx"/>
http://schemas.xmlsoap.org/soap/encoding/";
namespace="xxx"/>
--
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 the embedded wsdl-
>Emitter.
OK. I wasn't sure, so I posted it here first. Could you post
this on the axis bug list?
>IMHO, they do not use setSoapAction(Operation) simply
>because in the usual transport chain, the soap action is not
>necessarily evaluated (most of the time you use a urlmapper
>and encode the target service via a url-suffix).
>Furthermore, I have no problems with the .NET wsdl.exe even
>when soapAction is not defined (which is reasonable,
>because it is not needed in this case).
The problem is that MS toolkit (at least in 2.0, haven't
tried 3.0 yet) relies on only soapAction, and fails when
it's empty, maybe because it uses soap, and net .net or
webservice. And if the field is supposed to be empty,
couldn't it just have been removed?
>What do you want me to do about this issue. Include an
>(IMHO wrong) default into complete jboss.net that behaves
>different from Axis?
If this field is missing in the newest jboss (newest cvs
with the newest axis integrated), can you post a bug report
like this on the axis list?
--Marius
--
Comment By: Dr. Christoph Georg Jung (cgjung)
Date: 2002-09-09 09:36
Message:
Logged In: YES
user_id=175199
Which provider do you refer to?
If this is a bug, then it would be an Axis bug, because we
fully rely on, e.g., the EJBProvider and the embedded wsdl-
Emitter.
IMHO, they do not use setSoapAction(Operation) simply
because in the usual transport chain, the soap action is not
necessarily evaluated (most of the time you use a urlmapper
and encode the target service via a url-suffix).
Furthermore, I have no problems with the .NET wsdl.exe even
when soapAction is not defined (which is reasonable,
because it is not needed in this case).
What do you want me to do about this issue. Include an
(IMHO wrong) default into complete jboss.net that behaves
different from Axis?
CGJ
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=594137&group_id=22866
---
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=sourceforge1&refcode1=vs3390
___
Jboss-development mailing list
[EMAIL PROT
[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=detail&atid=376685&aid=594137&group_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 " HERE -> V
***HERE->***
http://schemas.xmlsoap.org/soap/encoding/";
namespace="xxx"/>
http://schemas.xmlsoap.org/soap/encoding/";
namespace="xxx"/>
--
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 the embedded wsdl-
>Emitter.
OK. I wasn't sure, so I posted it here first. Could you post
this on the axis bug list?
>IMHO, they do not use setSoapAction(Operation) simply
>because in the usual transport chain, the soap action is not
>necessarily evaluated (most of the time you use a urlmapper
>and encode the target service via a url-suffix).
>Furthermore, I have no problems with the .NET wsdl.exe even
>when soapAction is not defined (which is reasonable,
>because it is not needed in this case).
The problem is that MS toolkit (at least in 2.0, haven't
tried 3.0 yet) relies on only soapAction, and fails when
it's empty, maybe because it uses soap, and net .net or
webservice. And if the field is supposed to be empty,
couldn't it just have been removed?
>What do you want me to do about this issue. Include an
>(IMHO wrong) default into complete jboss.net that behaves
>different from Axis?
If this field is missing in the newest jboss (newest cvs
with the newest axis integrated), can you post a bug report
like this on the axis list?
--Marius
--
Comment By: Dr. Christoph Georg Jung (cgjung)
Date: 2002-09-09 09:36
Message:
Logged In: YES
user_id=175199
Which provider do you refer to?
If this is a bug, then it would be an Axis bug, because we
fully rely on, e.g., the EJBProvider and the embedded wsdl-
Emitter.
IMHO, they do not use setSoapAction(Operation) simply
because in the usual transport chain, the soap action is not
necessarily evaluated (most of the time you use a urlmapper
and encode the target service via a url-suffix).
Furthermore, I have no problems with the .NET wsdl.exe even
when soapAction is not defined (which is reasonable,
because it is not needed in this case).
What do you want me to do about this issue. Include an
(IMHO wrong) default into complete jboss.net that behaves
different from Axis?
CGJ
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=594137&group_id=22866
---
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=sourceforge1&refcode1=vs3390
___
Jboss-development mailing
[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=detail&atid=376685&aid=594137&group_id=22866
Category: JBossSOAP
Group: v3.0 Rabbit Hole
Status: Open
Resolution: Remind
Priority: 5
Submitted By: Marius Kotsbak (mkotsbak)
>Assigned to: Dan Christopherson (danch)
Summary: SOAPAction not set
Initial Comment:
The auto-generated wsdl-file is missing soapAction,
whch should be th e same as " HERE -> V
***HERE->***
http://schemas.xmlsoap.org/soap/encoding/";
namespace="xxx"/>
http://schemas.xmlsoap.org/soap/encoding/";
namespace="xxx"/>
--
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 the embedded wsdl-
>Emitter.
OK. I wasn't sure, so I posted it here first. Could you post
this on the axis bug list?
>IMHO, they do not use setSoapAction(Operation) simply
>because in the usual transport chain, the soap action is not
>necessarily evaluated (most of the time you use a urlmapper
>and encode the target service via a url-suffix).
>Furthermore, I have no problems with the .NET wsdl.exe even
>when soapAction is not defined (which is reasonable,
>because it is not needed in this case).
The problem is that MS toolkit (at least in 2.0, haven't
tried 3.0 yet) relies on only soapAction, and fails when
it's empty, maybe because it uses soap, and net .net or
webservice. And if the field is supposed to be empty,
couldn't it just have been removed?
>What do you want me to do about this issue. Include an
>(IMHO wrong) default into complete jboss.net that behaves
>different from Axis?
If this field is missing in the newest jboss (newest cvs
with the newest axis integrated), can you post a bug report
like this on the axis list?
--Marius
--
Comment By: Dr. Christoph Georg Jung (cgjung)
Date: 2002-09-09 09:36
Message:
Logged In: YES
user_id=175199
Which provider do you refer to?
If this is a bug, then it would be an Axis bug, because we
fully rely on, e.g., the EJBProvider and the embedded wsdl-
Emitter.
IMHO, they do not use setSoapAction(Operation) simply
because in the usual transport chain, the soap action is not
necessarily evaluated (most of the time you use a urlmapper
and encode the target service via a url-suffix).
Furthermore, I have no problems with the .NET wsdl.exe even
when soapAction is not defined (which is reasonable,
because it is not needed in this case).
What do you want me to do about this issue. Include an
(IMHO wrong) default into complete jboss.net that behaves
different from Axis?
CGJ
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=594137&group_id=22866
---
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=sourceforge1&refcode1=vs3390
___
Jboss-development mailing list
[E
[JBoss-dev] [ jboss-Bugs-606704 ] Log bean when checking method permission
Bugs item #606704, was opened at 2002-09-09 15:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=606704&group_id=22866 Category: JBossSX Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mathias Bogaert (pathoss) Assigned to: Nobody/Anonymous (nobody) Summary: Log bean when checking method permission Initial Comment: When no method permission is assigned to a remote method you get the following exception: 2002-09-09 15:02:19,851 ERROR [org.jboss.ejb.plugins.LogInterceptor] EJBException, causedBy: java.lang.SecurityException: No method permissions assigned to method=retrieve, interface=REMOTE at org.jboss.ejb.plugins.SecurityInterceptor.checkSecurityAssociation(SecurityInterceptor.java:190) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:119) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:203) at org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionContainer.java:313) at org.jboss.ejb.Container.invoke(Container.java:720) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:370) at java.lang.reflect.Method.invoke(Native Method) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:236) at sun.rmi.transport.Transport$1.run(Transport.java:147) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:143) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) at java.lang.Thread.run(Thread.java:479) 2002-09-09 15:02:20,226 ERROR [org.jboss.ejb.plugins.SecurityInterceptor] No method permissions assigned to method=retrieve, interface=REMOTE 2002-09-09 15:02:20,226 ERROR [org.jboss.ejb.plugins.LogInterceptor] EJBException, causedBy: java.lang.SecurityException: No method permissions assigned to method=retrieve, interface=REMOTE at org.jboss.ejb.plugins.SecurityInterceptor.checkSecurityAssociation(SecurityInterceptor.java:190) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:119) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:203) at org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionContainer.java:313) at org.jboss.ejb.Container.invoke(Container.java:720) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:370) at java.lang.reflect.Method.invoke(Native Method) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:236) at sun.rmi.transport.Transport$1.run(Transport.java:147) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:143) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) at java.lang.Thread.run(Thread.java:479) But this doesn't show what bean the problem is in!! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=606704&group_id=22866 --- 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=sourceforge1&refcode1=vs3390 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Another CVS tagging question
The cvs tagging convetions are here: http://www.jboss.org/developers/guides/cvs-admin.jsp Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Frederick N. Brier" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, September 07, 2002 10:59 AM Subject: [JBoss-dev] Another CVS tagging question > I had made some changes to the 3.1 Alpha code base. I was about to check > them in, but had for another reason, checked out a fresh version of head to > another location. It was 4.0 alpha. > > Now it was my understanding that 4.0 was going to be another leap in > design, and 3.2 hasn't been released yet. So if I want to check my changes > in, but would also like them placed against the latest 3.2 branch (are we > calling that 3.0 even if it is post 3.1?), what tags do I use? What is the > process for creating a patch and which direction is best to go? I've not > done this before and would appreciate any hand holding. Thank you. > > > Frederick N. Brier > Sr. Software Engineer > Multideck Corporation > --- 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=sourceforge1&refcode1=vs3390 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss.net now supports Axis RC1
At 18:49 06/09/2002 +0200, you wrote: >One of the most requested features is now in "head" (along with some >bugfixes and some nice deployment structure changes that remove the >dependency of >AxisService to the WebContainer). > >Axis will go 1.0 in a week or so which should be trivial to incorporate then. > >Are there any special backport requirements? Otherwise, I would go >reintegrating it into 3.2, then. > >Best, >CGJ > > >### Christoph and Friederich, thanks for getting this out guys! I tried it in jetty, and it looked nice. I tried it in tomcat and it crashed here: 2002-09-09 15:33:55,674 INFO [org.jboss.web.catalina.EmbeddedCatalinaServiceSX] deploy, ctxPath=/jboss-net, warUrl=file:/D:/jboss-src/jboss-all/build/output/jboss-4.0.0alpha/server/default/deploy/jboss-net.sar/jboss-net.war/ 2002-09-09 15:33:55,684 ERROR [org.jboss.web.catalina.EmbeddedCatalinaServiceSX] Error during deploy java.lang.NullPointerException at org.jboss.web.catalina.EmbeddedCatalinaServiceSX.createWebContext(EmbeddedCatalinaServiceSX.java:389) at org.jboss.web.catalina.EmbeddedCatalinaServiceSX.performDeploy(EmbeddedCatalinaServiceSX.java:331) at org.jboss.web.AbstractWebContainer.start(AbstractWebContainer.java:468) I don't have time to look at this any more today, but wanted any initial thoughts you might have, and I can hopefully get it sorted 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=sourceforge1&refcode1=vs3390 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-606359 ] jboss-3.0.2 classloader bug
Bugs item #606359, was opened at 2002-09-08 18:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=606359&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None >Priority: 7 Submitted By: Michael Lipp (mlipp) Assigned to: Nobody/Anonymous (nobody) Summary: jboss-3.0.2 classloader bug Initial Comment: We are using jdom. jdom includes a class org.jdom.outputXMLOutputter which has a nested class org.jdom.output.XMLOutputter.NamespaceStack that is derived from org.jdom.output.NamespaceStack. jdom is made available to the ejbs with an entry "Class-Path: lib/jdom-B8.jar" in the ejb's manifest. The application is deployed as ear with jdom-B8.jar in the lib/ subsection of the ear. This works. Now we use jdom in a webapp as well. jdom is made available as WEB-INF/lib/jdom-B8.jar (though this does not matter, we use the default Java2 delegation). We now use org.jdom.output.SAXOutputter in the web tier (which has a nested class SAXOutputter.NamespaceStack derived from org.jdom.outputNamespaceStack). Now using XMLOutputter in the EJB results in an "java.lang.IllegalAccessError: class org.jdom.output.XMLOutputter$NamespaceStack cannot access its superclass org.jdom.output.NamespaceStack". This is a strong indication that the two classes use different classloaders. So we have inserted three classloader dump statements (see appended file) and yes, if SAXOutputter is used in the web layer first, we have the following situation: EJBclass -> UnifiedClassLoader url=ejb.jar org.jdom.output.XMLOutputter -> UnifiedClassLoader url=ejb.jar org.jdom.output.NamespaceStack -> UnifiedClassLoader url=jdom-B8.jar I didn't track things further down (I stopped when I found that figure 2-3 - which should be part of the key - in the (bought) docu is missing). But obviously resolving NamespaceStack (as required by SAXOutputter) in the web layer loads it through the jdom-B8.jar loader and this association remains. Loading XMLOutputter later in the ejb layer loads XMLOutputter through the ejb's class loader but finds the already loaded NamespaceStack with the associated jdom-B8.jar loader. >From the user perspective, I don't think we have done anything wrong. Its a bug in the classloader implementation (or even architecture). -- >Comment By: Michael Lipp (mlipp) Date: 2002-09-09 17:06 Message: Logged In: YES user_id=77125 I have verified things (I needed a workaround) by making sure that whereever XMLOutputter is need, SAXOutputter is loaded as well. Now things work (OK I could have added jdom-B8.jar to the jboss classpath with -L but that would have been too easy). Maybe all this is just a duplicate to bug #602828. But while the description there remains rather theoretical, it has struck me as a real world problem. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=606359&group_id=22866 --- 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=sourceforge1&refcode1=vs3390 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-606812 ] Table not removed from db on undeploy
Bugs item #606812, was opened at 2002-09-09 16:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=606812&group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Da C (dacu) Assigned to: Nobody/Anonymous (nobody) Summary: Table not removed from db on undeploy Initial Comment: Hi, I think there is a bug when undeploying a CMP entity bean that has relations. JBoss v3.0.2 Windows 2000 Pro JDK 1.3 Xdoclet for code generation On a test project, I have two CMP entity beans: Product and Order. I have defined a relation 1 to many between Order and Product. I used @jboss:relation tag with xdoclet, and the relation has also a constraint (fk_constraint=true). My Database is MS SQL Server 2000. Everything is generated correcty, but on undeploy, the Order table is not removed from Db. for ProductBean, the relation is defined as * @ejb:interface-method view-type="local" * @ejb:relation * name="product-order" * role-name="many-products-in-one-order" * * @jboss:relation * related-pk-field="id" * fk-column="OrderId" * fk-constraint="true" * */ public abstract inventory.interfaces.OrderEntityLocal getOrder(); for OrderBean, the relation is defined as * @ejb:interface-method view-type="local" * @ejb:relation * name="product-order" * role-name="one-order-has-many-products" * */ public abstract Set getOrderProducts(); This bug doesn't happen when I don't have a relation. Dan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=606812&group_id=22866 --- 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=sourceforge1&refcode1=vs3390 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
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 -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]Im Auftrag von Marcus Redeker Gesendet: Freitag, 30. August 2002 11:31 An: [EMAIL PROTECTED] Betreff: Re: Re: [JBoss-dev] Bug: EJB Handle not deserializable Scott, all Others, attached please find a test szenario for the described problem. This contains two EJBs and a client. The client is called 'test.EJBClient'. The it works is that the client first creates a ApplicationStarter EJB and calls startApplication() on that bean. The ApplicationStarter EJB then creates the Application EJB and returns an info object back to the client. This info object contains the EJB handle of the just created Application EJB and also a String representation of that handle which was created with the includes Base64 class. The same EJB.jar works fine with JBoss2.4.4 but not with JBoss3.0.x anymore. Thanks, --Marcus [EMAIL PROTECTED] schrieb am 30.08.02 01:07:48: > Yes, we need a testcase and the steps to reproduce. > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > - Original Message - > From: "Marcus Redeker" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, August 29, 2002 3:39 PM > Subject: [JBoss-dev] Bug: EJB Handle not deserializable > > > > All, > > > > I recently posted a bug to sourceforge regarding EJB handle serialization. > > It looks > > like some other guys have the same problem since there are similar bugs > > posted and > > also something about it on the forum. > > > > We would really like to move to JBoss3 but so far this still does not work > > (3.0.2) > > > > If you need any source snippets please let me know. > > > > Thanks, > > > > --Marcus > > > > > > Bug-URL: > > http://sourceforge.net/tracker/?func=detail&aid=600474&group_id=22866&atid=3 > > 76685 > > > > > > > > --- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development __ WEB.DE MyPage - Ultimatives Kommunikationstool! Ihre Message sofort online! Domain aenderbar! http://www.das.ist.aber.ne.lustige.sache.ms/ --- 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=sourceforge1&refcode1=vs3390 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Another CVS tagging question
> "Scott" == Scott M Stark writes: Scott> The cvs tagging convetions are here: Scott> http://www.jboss.org/developers/guides/cvs-admin.jsp There's a picture in the middle of that page who's link is broken. FYI - Bob -- SynXis Corporation | [EMAIL PROTECTED]| no .sig today. 1610 Wynkoop, Suite 400 | Ph: (303)595-2511 | Denver, CO 80202 | Fax:(303)534-4257 | --- 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=sourceforge1&refcode1=vs3390 ___ 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=detail&atid=376685&aid=606942&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Bob Cotton (bcotton969) Assigned to: Nobody/Anonymous (nobody) 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 org.jboss.proxy.ejb.StatefulSessionInterceptor.invoke(StatefulSessionInterceptor
[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=detail&atid=376685&aid=606942&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None 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 org.jboss.proxy.ejb.StatefulSessionInterceptor.invoke(StatefulSessionInterceptor.
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=sourceforge1&refcode1=vs3390 ___ 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=detail&atid=376685&aid=604085&group_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 414>ls -l jmx-console.war -rw-r--r--1 starksm None58165 Sep 3 13:17 jmx-console.war deploy 415>jar -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 409>wget 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 410>wget 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 WebApplicationContext[/j
[JBoss-dev] [ jboss-Bugs-600474 ] EJB Handles in jboss3.0 not Serializable
Bugs item #600474, was opened at 2002-08-26 14:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=600474&group_id=22866 Category: JBossServer >Group: v3.0 Rabbit Hole Status: Open >Resolution: Later Priority: 5 Submitted By: Marcus Redeker (mredeker) >Assigned to: Scott M Stark (starksm) Summary: EJB Handles in jboss3.0 not Serializable Initial Comment: Hi, I am sending an EJBHandle as serialized object from one webcontext to another. The deserialization does not work and I get an exception. This worked in Jboss2.4.x and not in JBoss3 (3.0.1) anymore. We have a really big application with more then 1 logins a day and would really like to put this on a clustered environment. URGENT!!! This is a snippet from the error: 11:32:08,379 ERROR [Engine] StandardManager[] IOException while loading persisted sessions: java.io.EOFException java.io.EOFException at java.io.DataInputStream.readUnsignedShort (DataInputStream.java:347) at java.io.ObjectInputStream$BlockDataInputStream.readUn signedShort(ObjectInputStream.java:2633) at java.io.ObjectInputStream$BlockDataInputStream.readUT F(ObjectInputStream.java:2689) at java.io.ObjectInputStream.readUTF (ObjectInputStream.java:989) at java.rmi.server.RemoteObject.readObject (RemoteObject.java:394) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) -- >Comment By: Scott M Stark (starksm) Date: 2002-09-09 14:36 Message: Logged In: YES user_id=175228 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. The immeadiate workaround is to pass the handle back to the client and let the rmi transport layer handle the marshalling of the RMI object. I'll look at changing the marshalling of the JRMPInvokerProxy to handle this automatically. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=600474&group_id=22866 --- 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=sourceforge1&refcode1=vs3390 ___ 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 17:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=604085&group_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 414>ls -l jmx-console.war -rw-r--r--1 starksm None58165 Sep 3 13:17 jmx-console.war deploy 415>jar -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 409>wget 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 410>wget 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 WebApplicationContext[/j
[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=detail&atid=376685&aid=604085&group_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 414>ls -l jmx-console.war -rw-r--r--1 starksm None58165 Sep 3 13:17 jmx-console.war deploy 415>jar -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 409>wget 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 410>wget 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 WebApplicationContext[/j
[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=detail&atid=376685&aid=604085&group_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 414>ls -l jmx-console.war -rw-r--r--1 starksm None58165 Sep 3 13:17 jmx-console.war deploy 415>jar -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 409>wget 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 410>wget 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 WebApplicationContext[/j
[JBoss-dev] stale cvs locks
If you are as tired as me of having your jboss cvs access disrupted by stale cvs locks you might consider adding a comment to this request for a web interface to remove such locks, or make your own request. https://sourceforge.net/tracker/index.php?func=detail&aid=574879&group_id=1&atid=350001 Thanks david jencks --- 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=sourceforge1&refcode1=vs3390 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
