After fighting with Axis 1.4 for almost a month to get a stable level
2.0 DOM and saaj (that works with WSS4J etc) its very refreshing to not
have to fight software to extend it.  The worst I've had to do with Muse
is copy and paste one class to get rid of the statics.

The explanation makes sense.  In our case I'm integrating muse as a
management layer into our inhouse ESB.  We need to be able to
restart/reload the services at runtime without loss of service, the
SoapClient/Environment in particular is tied to an instance of the ESB
(allowing sending to MQ etc instead of just http).  The statics then
showed up as exceptions when trying to use the first initial
environment.

Given the background I think its fine to just use non-statics.

Regarding:

> First question: in the PullPoint accept method I just return true, 
> based on the assumption that the router will only send Notify to this 
> resource instance if it was the target of a subscription (from the WSA

> header to and resource param).  Is this assumption correct?

Is this ok to assume?  The pullpoint is a new resource so I think it
must be but I wanted to check.  If so I'd raise a jira to have the
default PullPoint implementation changed to this model (or at least
provide the alternatives :-).

cheers,
Chris

-----Original Message-----
From: Daniel Jemiolo [mailto:[EMAIL PROTECTED] 
Sent: Friday, August 10, 2007 6:53 PM
To: [email protected]
Subject: Re: PullPoint subscriptions - PublishAllMessagesFilter and
statics in AbstractIsolationLayer



"Bug free" is a stretch, but thanks anyway.  ;)

As I recall, AbstractIsolationLayer started out as a normal class and
was changed to be static because of problems we had setting the class
loading scope on various SOAP engines. Long ago, when we just ran on
Axis 1.x, we used its service scope (request|application|...) to make it
so the service stayed loaded for as long as the server was up; for
whatever reason, expanding to Axis2, the mini SOAP engine, WebSphere,
etc., led to some inconsistency and making things static was the only
way to ensure we got the proper behavior. Otherwise, the Muse engine
would reload for each request, which is obviously a bad thing.

It's odd that you're seeing the static class behavior even after
shutting down the app and restarting - I thought that this would cause
the app server to unload the app's local classloader. Are all of your
Muse JARs in the web app's /WEB-INF/lib, or have you added them to one
of the server's common library directories?

Dan



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to