Greetings!
Enabling and disabling other arbitrary handlers is the hard option.
Implement a handler that can enable/disable itself is considerably
easier :-D
CU & Good luck!
Jansen Werner wrote:
Hi again :)
My handlers are working. But I gave up the initial idea. This is how it works:
- The handler is included in client-config.wsdd ("hardcoded")
- The handler checks for itself if it should do anything. So I can activate and
deactivate handlers "on the fly". (or, better, activate and deactivate
functionality provided by those handlers)
But there's still an open issue: BeanSerializers and Namespaces. But I will
post that in another mail to this list, so the subject doesn't get confused.
Have a nice day! :)
CU
Werner
-----Original Message-----
From: Rodrigo Ruiz [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 04, 2006 3:02 PM
To: [email protected]
Subject: Re: Adding own handler in Java Code?
Ok, what I described you allows you to configure your chain in a
per-call basis. If you just need it per-execution, it becomes
simpler :-)
But... why do you want to do this programmatically? Is it for
usability
reasons?
If you want to select the set of handlers to use before starting your
application, you can implement a standalone tool that could allow you
to "visually" edit your client-config.wsdd, and show a
simplified GUI to
select among the available handlers. I would like a copy of
such a tool :-D
If you know which handlers you will need before starting to use Axis,
you can generate your client-config.wsdd from within your
application,
and use the generated WSDD as the configuration for your Axis engine.
If you want to go through the Axis API and modify the
configuration once
all has started, the quick answer is "you can't". Axis is not
prepared
to let you add and remove handlers as you like. There are several
conditions that will change what you need to call/do in order to make
things work.
First, you cannot remove handlers from chains. They have no
methods for
this.
Second, handlers (and chains) can optionally be deployed as
singletons.
When in singleton mode, changes to the WSDD deployment
descriptor will
not affect an existing instance, and you will have to directly modify
the instance itself. When not in this mode, Axis will create a new
instance each time the "get" method is called, and so, any change you
make to an instance will not have effect on the actual flow.
Third, you can only add handlers to the end of a chain, but usually
handlers must be deployed in different order depending on
which flow you
are adding them to. The response flow uses a reversed order
with respect
to the request one. This means that you must add all
necessary handlers
at once. Adding them incrementally will not work.
And fourth, the things you need to do require using several internal
classes that are not considered part of the Axis stable API.
This means
that you may have severe problems whenever you want to
upgrade the Axis
version.
Although it may seem too complex, I still think that the approach I
proposed you before is the best one. You can make
DynamicChain get the
list of active handlers from a Singleton class of your own,
and use that
class to specify which handlers you add or remove. This way your
application code is kept simple.
Hope this helps,
Rodrigo Ruiz
Jansen Werner wrote:
Hi Rodrigo,
is it really that complicated to include a handler? Within
server-config.wsdd, it's just a single line to include the
(example) LogHandler, why is it so complicated to inject it via API?
As a resumee, this is what I want to do:
- add a Handler to Message Processing. Nothing complicated.
Complexity similar to the org.apache.axis.handlers.LogHandler
provided by Axis.
- do this in client and server
- within the server, this is easy using <handler>-Tags in
server-config.wsdd, because the handler is needed always.
This works already.
- within the client, client-config.wsdd is inappropriate,
because the handler isn't used on every run of the client.
- How is it possible to inject a (simple) Handler via Java
Calls the way it would be in client-config.wsdd or
server-config.wsdd. As an example, I'm still trying to use
the LogHandler provided by Axis (which extends
org.apache.axis.handlers.BaseHandler, which itself implements
org.apache.axis.Handler (which does only extend Serializable,
and no javax.rpc-Interface).
I thought this must be a very simple thing to do. What you
wrote sounds profound but is very complicated for a (in my
eyes) simple thing: adding a Handler to message Processing.
... hoping for an answer ... :)
CU
Werner
-----Original Message-----
From: Rodrigo Ruiz [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 04, 2006 11:06 AM
To: [email protected]
Subject: Re: Adding own handler in Java Code?
Hi Jansen,
Ideally you should be able to create a custom chain and
deploy it in
your client-config.wsdd as an actual chain. Unfortunately,
Axis WSDD
syntax does not allow to deploy custom chains. When you
put a <chain>
tag, it always creates a SimpleChain instance.
I would create a JIRA report to ask for the ability to specify a
different class name for the Chain implementation. Something
similar to
the type attribute for handlers.
In the meantime, you could try to write your own custom chain
and deploy
it as any other regular handler. Your chain would allow you
to configure
the list of handlers to be included, *before* performing the call,
through the MessageContext, or any other appropriate
channel. If I am
not wrong, setting a property on the service client stub makes it
available from the MessageContext during handlers invocation.
Configuring the handlers within your custom chain should
be straight
forward once the WSDD syntax is extended. With the current
syntax you
have two options:
1. Use a secondary WSDD file with the contained handler
configurations
and parse it from your chain init() method.
2. Define all your handlers in your wsdd configuration file
with unique
names, set a property for your chain containing a list of
handler names,
and obtain the handler instances from the init() method.
Instead of adding/removing handlers, it is easier to
enable/disable
them. This way, you can initialise all the handlers once,
and specify
its ordering at configuration time. At runtime you will
just have to
supply a list(or set) of the handlers that must be enabled
for a call.
I attach a simple template class that may be of help. It
implements the
second option mentioned above.
Regards,
Rodrigo Ruiz
Jansen Werner wrote:
Thanks for you reply!
-----Original Message-----
From: Rodrigo Ruiz [mailto:[EMAIL PROTECTED]
Sent: Monday, July 03, 2006 3:57 PM
To: [email protected]
Subject: Re: Adding own handler in Java Code?
Hi Jansen,
The answer depends on what you mean be "add dynamically". :-)
If you mean "add a jar at runtime and have it automatically
recognized",
the answer is that it is very hard. You will need Axis 2
to have this
feature built in, or implement yourself a dynamic
class-loader like the
one used by Axis 2, and a handler with the ability to detect
the changes
at runtime, and call these "dynamic" handlers when appropriate.
No, I'm lucky, this is not what I meant :)
If you mean "selecting a subset among an already
well-known set of
available handlers", the answer is that it is easier :-)
You will have to create a handler that could act as a
"handler chain",
and put into it the logic to take the decision about what
handlers to
actually call when invoked. Depending on what you need,
this handler
will have the information needed to find out the handlers to
call (for
example, by parsing a policy), or you may have to include the
mechanisms
to communicate with it from the service implementations or
other points,
and configure it at runtime.
OK, this sounds like my problem.
For an example, let's take the LogHandler packaged with
axis. How can I
add this (simple, easy) Handler to Axis at runtime? (And
remove it later
...).
I have found a way to access the HandlerRegistry
(Service.getHandlerRegistry()). But - without deeper
knowledge of the
HandlerChains available - how do I add my Handler (or the
LogHandler
mentioned above)?
Just keep in mind that you need to respect the handlers
interface, and
call their methods in the appropriate order. That is, to
initialise them
before invoking them, and the like.
This is something I will concentrate on when I managed to add the
LogHandler provided by Axis :)
Ah, before I forget it again, our Axis version is 1.3 :)
Thanks in advance :)
CU
Werner
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
-------------------------------------------------------------------
GRIDSYSTEMS Rodrigo Ruiz Aguayo
Parc Bit - Son Espanyol
07120 Palma de Mallorca mailto:[EMAIL PROTECTED]
Baleares - España Tel:+34-971435085 Fax:+34-971435082
http://www.gridsystems.com
-------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
-------------------------------------------------------------------
GRIDSYSTEMS Rodrigo Ruiz Aguayo
Parc Bit - Son Espanyol
07120 Palma de Mallorca mailto:[EMAIL PROTECTED]
Baleares - España Tel:+34-971435085 Fax:+34-971435082
http://www.gridsystems.com
-------------------------------------------------------------------
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.9.8/381 - Release
Date: 03/07/2006
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
-------------------------------------------------------------------
GRIDSYSTEMS Rodrigo Ruiz Aguayo
Parc Bit - Son Espanyol
07120 Palma de Mallorca mailto:[EMAIL PROTECTED]
Baleares - España Tel:+34-971435085 Fax:+34-971435082
http://www.gridsystems.com
-------------------------------------------------------------------
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.9.9/382 - Release Date: 04/07/2006
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
