You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-dev@xml.apache.org by Saint-Martin Cécile <cs...@symetrx.com> on 2001/04/26 12:05:15 UTC
Re: [SOAP] BUG in StatelessEJBProvider!!
I succeeded in correcting the bug but now the problem is that the called
method must have this parameters :
Envelope env,
SOAPContext reqCtx
SOAPContext resCtx
and in EJB spec, parameters of EJB methods must have serializable
parameters.
Envelope and SOAPContext are not serializable.
----- Original Message -----
From: "Saint-Martin Cécile" <cs...@SYMETRX.COM>
To: <SO...@DISCUSS.DEVELOP.COM>
Sent: Thursday, April 26, 2001 11:20 AM
Subject: [SOAP] BUG in StatelessEJBProvider!!
Excuse me for repeating but i have no reponse to my problem :
We try to deploy an EJB as a SOAP MESSAGE service and we have a
java.lang.NullPointerException
I think there is a bug in the apache code because MessageRouterServlet pass
to StatelessEJBProvider.locate a null call object.
Cécile Saint-Martin
csaintmartin@symetrx.com
You can read messages from the SOAP archive, unsubscribe from SOAP, or
subscribe to other
DevelopMentor lists at http://discuss.develop.com.
Re: [SOAP] BUG in StatelessEJBProvider!!
Posted by Olivier Brand <ol...@intraware.com>.
Saint-Martin Cécile wrote:
> > Why not just creating your own EJB provider ? The one shipped with SOAP is
> RPC oriented (makes use
> > of Call).
> It's exactly what i am doing.
>
> > You have 2 methods: invoke and locate. I don't see why you want to pass
> SOAP objects to the EJB....
> I dont' want to!!! But i need to deploy EJB object as MESSAGE service, and,
> if u watch messaging sample, u'll see that method called by xml message must
> have SOAP parameters
> (Envelope & SOAPContext).
>
Can you give an example ? What source code do you see those parameters being
passed ?
>
> Cécile Saint-Martin
> csaintmartin@symetrx.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
> For additional commands, email: soap-user-help@xml.apache.org
Re: [SOAP] BUG in StatelessEJBProvider!!
Posted by Olivier Brand <ol...@intraware.com>.
Saint-Martin Cécile wrote:
> > Why not just creating your own EJB provider ? The one shipped with SOAP is
> RPC oriented (makes use
> > of Call).
> It's exactly what i am doing.
>
> > You have 2 methods: invoke and locate. I don't see why you want to pass
> SOAP objects to the EJB....
> I dont' want to!!! But i need to deploy EJB object as MESSAGE service, and,
> if u watch messaging sample, u'll see that method called by xml message must
> have SOAP parameters
> (Envelope & SOAPContext).
>
Can you give an example ? What source code do you see those parameters being
passed ?
>
> Cécile Saint-Martin
> csaintmartin@symetrx.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
> For additional commands, email: soap-user-help@xml.apache.org
Re: [SOAP] BUG in StatelessEJBProvider!!
Posted by Saint-Martin Cécile <cs...@symetrx.com>.
> Why not just creating your own EJB provider ? The one shipped with SOAP is
RPC oriented (makes use
> of Call).
It's exactly what i am doing.
> You have 2 methods: invoke and locate. I don't see why you want to pass
SOAP objects to the EJB....
I dont' want to!!! But i need to deploy EJB object as MESSAGE service, and,
if u watch messaging sample, u'll see that method called by xml message must
have SOAP parameters
(Envelope & SOAPContext).
Cécile Saint-Martin
csaintmartin@symetrx.com
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
Re: [SOAP] BUG in StatelessEJBProvider!!
Posted by Saint-Martin Cécile <cs...@symetrx.com>.
> Why not just creating your own EJB provider ? The one shipped with SOAP is
RPC oriented (makes use
> of Call).
It's exactly what i am doing.
> You have 2 methods: invoke and locate. I don't see why you want to pass
SOAP objects to the EJB....
I dont' want to!!! But i need to deploy EJB object as MESSAGE service, and,
if u watch messaging sample, u'll see that method called by xml message must
have SOAP parameters
(Envelope & SOAPContext).
Cécile Saint-Martin
csaintmartin@symetrx.com
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
Re: [SOAP] BUG in StatelessEJBProvider!!
Posted by Olivier Brand <ol...@intraware.com>.
Why not just creating your own EJB provider ? The one shipped with SOAP is RPC oriented (makes use
of Call).
You have 2 methods: invoke and locate. I don't see why you want to pass SOAP objects to the EJB....
Olivier
Rich Johns wrote:
> Oh, I see.
> I use the RPC approach and am not familiar with the MESSAGE approach.. The service class, in my
> case, prepares input
> to the EJB's just like they'd use it from a java client doing straight RMI.
>
> Is there any way you could put a class in between the Provider and the EJB that would
> take care of some of these details?
>
> Saint-Martin Cécile wrote:
>
> > Because i want to deploy my EJB as a MESSAGE service. If u watch messaging
> > sample, u'll see that called method must have these parameters.
> >
> > > Why pass these to EJBs? Why not have a service class
> > > ferret out what is needed by the EJB and pass that instead
> > > of the SOAPContext?
> > >
> > > Saint-Martin Cécile wrote:
> > >
> > > > I succeeded in correcting the bug but now the problem is that the called
> > > > method must have this parameters :
> > > > Envelope env,
> > > > SOAPContext reqCtx
> > > > SOAPContext resCtx
> > > >
> > > > and in EJB spec, parameters of EJB methods must have serializable
> > > > parameters.
> > > > Envelope and SOAPContext are not serializable.
> > >
> > Cécile Saint-Martin
> > csaintmartin@symetrx.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
> > For additional commands, email: soap-user-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
> For additional commands, email: soap-user-help@xml.apache.org
Re: [SOAP] BUG in StatelessEJBProvider!!
Posted by Olivier Brand <ol...@intraware.com>.
Why not just creating your own EJB provider ? The one shipped with SOAP is RPC oriented (makes use
of Call).
You have 2 methods: invoke and locate. I don't see why you want to pass SOAP objects to the EJB....
Olivier
Rich Johns wrote:
> Oh, I see.
> I use the RPC approach and am not familiar with the MESSAGE approach.. The service class, in my
> case, prepares input
> to the EJB's just like they'd use it from a java client doing straight RMI.
>
> Is there any way you could put a class in between the Provider and the EJB that would
> take care of some of these details?
>
> Saint-Martin Cécile wrote:
>
> > Because i want to deploy my EJB as a MESSAGE service. If u watch messaging
> > sample, u'll see that called method must have these parameters.
> >
> > > Why pass these to EJBs? Why not have a service class
> > > ferret out what is needed by the EJB and pass that instead
> > > of the SOAPContext?
> > >
> > > Saint-Martin Cécile wrote:
> > >
> > > > I succeeded in correcting the bug but now the problem is that the called
> > > > method must have this parameters :
> > > > Envelope env,
> > > > SOAPContext reqCtx
> > > > SOAPContext resCtx
> > > >
> > > > and in EJB spec, parameters of EJB methods must have serializable
> > > > parameters.
> > > > Envelope and SOAPContext are not serializable.
> > >
> > Cécile Saint-Martin
> > csaintmartin@symetrx.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
> > For additional commands, email: soap-user-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
> For additional commands, email: soap-user-help@xml.apache.org
Re: [SOAP] BUG in StatelessEJBProvider!!
Posted by Rich Johns <rj...@vignette.com>.
Oh, I see.
I use the RPC approach and am not familiar with the MESSAGE approach.. The service class, in my
case, prepares input
to the EJB's just like they'd use it from a java client doing straight RMI.
Is there any way you could put a class in between the Provider and the EJB that would
take care of some of these details?
Saint-Martin Cécile wrote:
> Because i want to deploy my EJB as a MESSAGE service. If u watch messaging
> sample, u'll see that called method must have these parameters.
>
> > Why pass these to EJBs? Why not have a service class
> > ferret out what is needed by the EJB and pass that instead
> > of the SOAPContext?
> >
> > Saint-Martin Cécile wrote:
> >
> > > I succeeded in correcting the bug but now the problem is that the called
> > > method must have this parameters :
> > > Envelope env,
> > > SOAPContext reqCtx
> > > SOAPContext resCtx
> > >
> > > and in EJB spec, parameters of EJB methods must have serializable
> > > parameters.
> > > Envelope and SOAPContext are not serializable.
> >
> Cécile Saint-Martin
> csaintmartin@symetrx.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
> For additional commands, email: soap-user-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
Re: [SOAP] BUG in StatelessEJBProvider!!
Posted by Rich Johns <rj...@vignette.com>.
Oh, I see.
I use the RPC approach and am not familiar with the MESSAGE approach.. The service class, in my
case, prepares input
to the EJB's just like they'd use it from a java client doing straight RMI.
Is there any way you could put a class in between the Provider and the EJB that would
take care of some of these details?
Saint-Martin Cécile wrote:
> Because i want to deploy my EJB as a MESSAGE service. If u watch messaging
> sample, u'll see that called method must have these parameters.
>
> > Why pass these to EJBs? Why not have a service class
> > ferret out what is needed by the EJB and pass that instead
> > of the SOAPContext?
> >
> > Saint-Martin Cécile wrote:
> >
> > > I succeeded in correcting the bug but now the problem is that the called
> > > method must have this parameters :
> > > Envelope env,
> > > SOAPContext reqCtx
> > > SOAPContext resCtx
> > >
> > > and in EJB spec, parameters of EJB methods must have serializable
> > > parameters.
> > > Envelope and SOAPContext are not serializable.
> >
> Cécile Saint-Martin
> csaintmartin@symetrx.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
> For additional commands, email: soap-user-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
Re: [SOAP] BUG in StatelessEJBProvider!!
Posted by Saint-Martin Cécile <cs...@symetrx.com>.
Because i want to deploy my EJB as a MESSAGE service. If u watch messaging
sample, u'll see that called method must have these parameters.
> Why pass these to EJBs? Why not have a service class
> ferret out what is needed by the EJB and pass that instead
> of the SOAPContext?
>
> Saint-Martin Cécile wrote:
>
> > I succeeded in correcting the bug but now the problem is that the called
> > method must have this parameters :
> > Envelope env,
> > SOAPContext reqCtx
> > SOAPContext resCtx
> >
> > and in EJB spec, parameters of EJB methods must have serializable
> > parameters.
> > Envelope and SOAPContext are not serializable.
>
Cécile Saint-Martin
csaintmartin@symetrx.com
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
Re: [SOAP] BUG in StatelessEJBProvider!!
Posted by Saint-Martin Cécile <cs...@symetrx.com>.
Because i want to deploy my EJB as a MESSAGE service. If u watch messaging
sample, u'll see that called method must have these parameters.
> Why pass these to EJBs? Why not have a service class
> ferret out what is needed by the EJB and pass that instead
> of the SOAPContext?
>
> Saint-Martin Cécile wrote:
>
> > I succeeded in correcting the bug but now the problem is that the called
> > method must have this parameters :
> > Envelope env,
> > SOAPContext reqCtx
> > SOAPContext resCtx
> >
> > and in EJB spec, parameters of EJB methods must have serializable
> > parameters.
> > Envelope and SOAPContext are not serializable.
>
Cécile Saint-Martin
csaintmartin@symetrx.com
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
RE: Plain old XML POSTed via HTTP(S)
Posted by Silvio Fiorito <si...@ntr.net>.
I think most of the problems seem to be with ApacheSOAP interop with .NET
Web Services (separate from MSSOAP 2.0). I've been using ApacheSOAP 2.1
clients with MSSOAP 2.0 servers for over a month now without a problem. I
haven't tried an MSSOAP client against an ApacheSOAP server yet, so I don't
know if there are any problems with that. Same thing with .NET: haven't used
it so I don't know what problems there are. I think the biggest problem is
with documentation on both sides. Also, IdooXOAP worked right out of the box
for me when I first tried it a month ago, but there were some speed issues.
I haven't gotten around to check it out again. MSSOAP as of today is now a
supported product (no longer beta) so maybe they'll focus more on interop
now that it's feature complete and out of beta.
Silvio
-----Original Message-----
From: David Wall [mailto:dwall@Yozons.com]
Sent: Thursday, April 26, 2001 1:01 PM
To: soap-user@xml.apache.org
Subject: Plain old XML POSTed via HTTP(S)
I'm still in the early stages of testing out SOAP, but my scouring of
various lists and such seems to show that SOAP seems to be working about as
well as CORBA at interoperability. Of course, SOAP is much newer than
CORBA, but is it fair to say that the state of interoperability across
toolkits/languages/OSes is poor?
There are a lot of posts about problems getting MSFT (beta1 and beta2
causing additional compatibility problems) and Apache (seen problems with
changes from 2.0 to 2.1) to interoperate, and surely working with MSFT has
to be a goal, even if it means supporting "standards broken" formats, since
MSFT and their .NET world will likely be a large player in any SOAP service
(either as the client or the service).
Does anybody know if there's a good source of specific information about
what to do to make MSFT and Apache interoperate (in my case, I'm interested
in MSFT being the client, but I know others have interest where Apache is
the client)?
Are there any nasty issues just having a DOM create and XML string, and then
POSTing that via HTTP(S)? Would that likely be any more interoperable, or
will I just find that the XML string created by the different DOMs (MSFTs
verses Xerces) will have its own set of interoperability problems? I
suspect it wouldn't be too hard to "upgrade to SOAP" later if this approach
works.
Thanks,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
RE: Plain old XML POSTed via HTTP(S)
Posted by Silvio Fiorito <si...@ntr.net>.
I think most of the problems seem to be with ApacheSOAP interop with .NET
Web Services (separate from MSSOAP 2.0). I've been using ApacheSOAP 2.1
clients with MSSOAP 2.0 servers for over a month now without a problem. I
haven't tried an MSSOAP client against an ApacheSOAP server yet, so I don't
know if there are any problems with that. Same thing with .NET: haven't used
it so I don't know what problems there are. I think the biggest problem is
with documentation on both sides. Also, IdooXOAP worked right out of the box
for me when I first tried it a month ago, but there were some speed issues.
I haven't gotten around to check it out again. MSSOAP as of today is now a
supported product (no longer beta) so maybe they'll focus more on interop
now that it's feature complete and out of beta.
Silvio
-----Original Message-----
From: David Wall [mailto:dwall@Yozons.com]
Sent: Thursday, April 26, 2001 1:01 PM
To: soap-user@xml.apache.org
Subject: Plain old XML POSTed via HTTP(S)
I'm still in the early stages of testing out SOAP, but my scouring of
various lists and such seems to show that SOAP seems to be working about as
well as CORBA at interoperability. Of course, SOAP is much newer than
CORBA, but is it fair to say that the state of interoperability across
toolkits/languages/OSes is poor?
There are a lot of posts about problems getting MSFT (beta1 and beta2
causing additional compatibility problems) and Apache (seen problems with
changes from 2.0 to 2.1) to interoperate, and surely working with MSFT has
to be a goal, even if it means supporting "standards broken" formats, since
MSFT and their .NET world will likely be a large player in any SOAP service
(either as the client or the service).
Does anybody know if there's a good source of specific information about
what to do to make MSFT and Apache interoperate (in my case, I'm interested
in MSFT being the client, but I know others have interest where Apache is
the client)?
Are there any nasty issues just having a DOM create and XML string, and then
POSTing that via HTTP(S)? Would that likely be any more interoperable, or
will I just find that the XML string created by the different DOMs (MSFTs
verses Xerces) will have its own set of interoperability problems? I
suspect it wouldn't be too hard to "upgrade to SOAP" later if this approach
works.
Thanks,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
Plain old XML POSTed via HTTP(S)
Posted by David Wall <dw...@Yozons.com>.
I'm still in the early stages of testing out SOAP, but my scouring of
various lists and such seems to show that SOAP seems to be working about as
well as CORBA at interoperability. Of course, SOAP is much newer than
CORBA, but is it fair to say that the state of interoperability across
toolkits/languages/OSes is poor?
There are a lot of posts about problems getting MSFT (beta1 and beta2
causing additional compatibility problems) and Apache (seen problems with
changes from 2.0 to 2.1) to interoperate, and surely working with MSFT has
to be a goal, even if it means supporting "standards broken" formats, since
MSFT and their .NET world will likely be a large player in any SOAP service
(either as the client or the service).
Does anybody know if there's a good source of specific information about
what to do to make MSFT and Apache interoperate (in my case, I'm interested
in MSFT being the client, but I know others have interest where Apache is
the client)?
Are there any nasty issues just having a DOM create and XML string, and then
POSTing that via HTTP(S)? Would that likely be any more interoperable, or
will I just find that the XML string created by the different DOMs (MSFTs
verses Xerces) will have its own set of interoperability problems? I
suspect it wouldn't be too hard to "upgrade to SOAP" later if this approach
works.
Thanks,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
Plain old XML POSTed via HTTP(S)
Posted by David Wall <dw...@Yozons.com>.
I'm still in the early stages of testing out SOAP, but my scouring of
various lists and such seems to show that SOAP seems to be working about as
well as CORBA at interoperability. Of course, SOAP is much newer than
CORBA, but is it fair to say that the state of interoperability across
toolkits/languages/OSes is poor?
There are a lot of posts about problems getting MSFT (beta1 and beta2
causing additional compatibility problems) and Apache (seen problems with
changes from 2.0 to 2.1) to interoperate, and surely working with MSFT has
to be a goal, even if it means supporting "standards broken" formats, since
MSFT and their .NET world will likely be a large player in any SOAP service
(either as the client or the service).
Does anybody know if there's a good source of specific information about
what to do to make MSFT and Apache interoperate (in my case, I'm interested
in MSFT being the client, but I know others have interest where Apache is
the client)?
Are there any nasty issues just having a DOM create and XML string, and then
POSTing that via HTTP(S)? Would that likely be any more interoperable, or
will I just find that the XML string created by the different DOMs (MSFTs
verses Xerces) will have its own set of interoperability problems? I
suspect it wouldn't be too hard to "upgrade to SOAP" later if this approach
works.
Thanks,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
Re: [SOAP] BUG in StatelessEJBProvider!!
Posted by Rich Johns <rj...@vignette.com>.
Why pass these to EJBs? Why not have a service class
ferret out what is needed by the EJB and pass that instead
of the SOAPContext?
Saint-Martin Cécile wrote:
> I succeeded in correcting the bug but now the problem is that the called
> method must have this parameters :
> Envelope env,
> SOAPContext reqCtx
> SOAPContext resCtx
>
> and in EJB spec, parameters of EJB methods must have serializable
> parameters.
> Envelope and SOAPContext are not serializable.
>
> ----- Original Message -----
> From: "Saint-Martin Cécile" <cs...@SYMETRX.COM>
> To: <SO...@DISCUSS.DEVELOP.COM>
> Sent: Thursday, April 26, 2001 11:20 AM
> Subject: [SOAP] BUG in StatelessEJBProvider!!
>
> Excuse me for repeating but i have no reponse to my problem :
> We try to deploy an EJB as a SOAP MESSAGE service and we have a
> java.lang.NullPointerException
>
> I think there is a bug in the apache code because MessageRouterServlet pass
> to StatelessEJBProvider.locate a null call object.
>
> Cécile Saint-Martin
> csaintmartin@symetrx.com
>
> You can read messages from the SOAP archive, unsubscribe from SOAP, or
> subscribe to other
> DevelopMentor lists at http://discuss.develop.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
> For additional commands, email: soap-user-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
Re: [SOAP] BUG in StatelessEJBProvider!!
Posted by Wouter Cloetens <wo...@mind.be>.
On Fri, Apr 27, 2001 at 10:29:48AM +0200, Saint-Martin C?cile wrote:
> > I don't know if there's a good or easy solution to this. The best strategy
> > might be to re-serialise the request in some Serializable object structure
> > before sending it off. Messaging doesn't offer transparency anyway; the
> > target service needs to be fully aware of the SOAP objects it is passed.
> > Might just as well make up another object interface.
> I'm re-writing EJB provider in order to extract xml document from request
> and call EJB metho with it.
>
> > It's not a very typical application though. Generally, you only want to
> > put a SOAP interface in front of an existing EJB service, so you'd only
> > use RPCRouterServlet...
> The problem is that the treatment realized by EJB object can be very long..
> so the socket connection with the client may be lost.
> I need "asynchronous " RPC ==> message service
Countrary to what the name 'messaging'servlet may suggest, it is not an
asynchronous service. Is behaves exactly like RPCRouterServlet, except for the
way it invokes the target service and treats the response.
What you want is perhaps a provider that invokes the EJB method without
waiting for the response, and then returns a void response to the client?
bfn, Wouter
Re: [SOAP] BUG in StatelessEJBProvider!!
Posted by Saint-Martin Cécile <cs...@symetrx.com>.
> I wouldn't call that a bug, I'd call that "the sample EJB providers
> don't support messaging"...
Ok, i agree....
> I don't know if there's a good or easy solution to this. The best strategy
> might be to re-serialise the request in some Serializable object structure
> before sending it off. Messaging doesn't offer transparency anyway; the
> target service needs to be fully aware of the SOAP objects it is passed.
> Might just as well make up another object interface.
I'm re-writing EJB provider in order to extract xml document from request
and call EJB metho with it.
> It's not a very typical application though. Generally, you only want to
> put a SOAP interface in front of an existing EJB service, so you'd only
> use RPCRouterServlet...
The problem is that the treatment realized by EJB object can be very long..
so the socket connection with the client may be lost.
I need "asynchronous " RPC ==> message service
Cécile Saint-Martin
csaintmartin@symetrx.com
Re: [SOAP] BUG in StatelessEJBProvider!!
Posted by Wouter Cloetens <wo...@mind.be>.
I wouldn't call that a bug, I'd call that "the sample EJB providers
don't support messaging"...
I don't know if there's a good or easy solution to this. The best strategy
might be to re-serialise the request in some Serializable object structure
before sending it off. Messaging doesn't offer transparency anyway; the
target service needs to be fully aware of the SOAP objects it is passed.
Might just as well make up another object interface.
It's not a very typical application though. Generally, you only want to
put a SOAP interface in front of an existing EJB service, so you'd only
use RPCRouterServlet...
bfn, Wouter
On Thu, Apr 26, 2001 at 12:05:15PM +0200, Saint-Martin C?cile wrote:
> I succeeded in correcting the bug but now the problem is that the called
> method must have this parameters :
> Envelope env,
> SOAPContext reqCtx
> SOAPContext resCtx
>
> and in EJB spec, parameters of EJB methods must have serializable
> parameters.
> Envelope and SOAPContext are not serializable.
>
>
> ----- Original Message -----
> From: "Saint-Martin Cécile" <cs...@SYMETRX.COM>
> To: <SO...@DISCUSS.DEVELOP.COM>
> Sent: Thursday, April 26, 2001 11:20 AM
> Subject: [SOAP] BUG in StatelessEJBProvider!!
>
>
> Excuse me for repeating but i have no reponse to my problem :
> We try to deploy an EJB as a SOAP MESSAGE service and we have a
> java.lang.NullPointerException
>
> I think there is a bug in the apache code because MessageRouterServlet pass
> to StatelessEJBProvider.locate a null call object.
>
>
> Cécile Saint-Martin
> csaintmartin@symetrx.com
>
> You can read messages from the SOAP archive, unsubscribe from SOAP, or
> subscribe to other
> DevelopMentor lists at http://discuss.develop.com.
>
---end quoted text---
Re: [SOAP] BUG in StatelessEJBProvider!!
Posted by Rich Johns <rj...@vignette.com>.
Why pass these to EJBs? Why not have a service class
ferret out what is needed by the EJB and pass that instead
of the SOAPContext?
Saint-Martin Cécile wrote:
> I succeeded in correcting the bug but now the problem is that the called
> method must have this parameters :
> Envelope env,
> SOAPContext reqCtx
> SOAPContext resCtx
>
> and in EJB spec, parameters of EJB methods must have serializable
> parameters.
> Envelope and SOAPContext are not serializable.
>
> ----- Original Message -----
> From: "Saint-Martin Cécile" <cs...@SYMETRX.COM>
> To: <SO...@DISCUSS.DEVELOP.COM>
> Sent: Thursday, April 26, 2001 11:20 AM
> Subject: [SOAP] BUG in StatelessEJBProvider!!
>
> Excuse me for repeating but i have no reponse to my problem :
> We try to deploy an EJB as a SOAP MESSAGE service and we have a
> java.lang.NullPointerException
>
> I think there is a bug in the apache code because MessageRouterServlet pass
> to StatelessEJBProvider.locate a null call object.
>
> Cécile Saint-Martin
> csaintmartin@symetrx.com
>
> You can read messages from the SOAP archive, unsubscribe from SOAP, or
> subscribe to other
> DevelopMentor lists at http://discuss.develop.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
> For additional commands, email: soap-user-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org