Am I correct in assuming that Axis client implementations won't have to
connect via JNDI for any reason? Since these may not be Java anyway...
This will add to the complexity of implementing Axis and potentially
eliminate some platforms that could support it...
"Steve Loughran" <[EMAIL PROTECTED]> on 10/23/2002 08:49:25 PM
Please respond to [EMAIL PROTECTED]
To: <[EMAIL PROTECTED]>
cc: (bcc: Kevin Bedell/Systems/USHO/SunLife)
Subject: Re: Axis as a JNDI Resource
Do all the servlet engines we want to support have JNDI? If not, what to
do?
Also, J2ee says no thread stuff inside the context of an EJB, not elsewhere
in the system.
One option is we make is a JMX managed object and go through JMX to find
it.
----- Original Message -----
From: "James M Snell" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, October 23, 2002 5:10 PM
Subject: Axis as a JNDI Resource
> Another issue relating to the Async stuff....
>
> The Axis async implementation is going to require us to do some thread
> management. Within J2EE environments, doing such thread management from
> within J2EE containers is not allowed. As far as I know, once the async
> stuff is done, the current method of creating and using the Axis engine
> directly within the Servlet will go against the J2EE rules. The solution
> is to do the thread management outside of the Web/J2EE container.
> Basically this means running Axis as an application server service, much
> like one would run a JMS or JDBC implementation. The Axis engine would
be
> exposed as a JNDI Resource just like a JDBC connection, a JMS Queue, etc
> etc.
>
> InitialContext ctx = new InitialContext();
> AxisEngine engine = (AxisEngine)ctx.lookup("AxisEngine");
>
> Doing this would have a significant impact on how the Axis Engine is
> configured (there would potentially be one config.wsdd per application
> server rather than one config.wsdd per web application. It would also
> impact how services are deployed, as classes would have to be visible on
> an application server level rather than just on a web application level.
> Lots of issues to work out, but I think that overall, it would be helpful
> to at least have this as a deployment option.
>
> So... my question is: is this something we want to discuss now? Or wait
> until after the async stuff is done?
>
> - James Snell
> IBM Emerging Technologies
> [EMAIL PROTECTED]
> (559) 587-1233 (office)
> (700) 544-9035 (t/l)
> Programming Web Services With SOAP
> O'Reilly & Associates, ISBN 0596000952
>
> Have I not commanded you? Be strong and courageous.
> Do not be terrified, do not be discouraged, for the Lord your
> God will be with you whereever you go. - Joshua 1:9
>
---------------------------------------------------------------------------
This e-mail message (including attachments, if any) is intended for the use
of the individual or entity to which it is addressed and may contain
information that is privileged, proprietary , confidential and exempt from
disclosure. If you are not the intended recipient, you are notified that
any dissemination, distribution or copying of this communication is
strictly prohibited. If you have received this communication in error,
please notify the sender and erase this e-mail message immediately.
---------------------------------------------------------------------------
