AliasSelector Runtime Properties Not Passed In

[metro-3]

Good to know it is working now. The fix will make to Metro 2.0 slated Sept i believe. And there is durable RM support in 2.0, i will forward your message to Marek the RM lead who can asnwer your queries.
[Message sent by forum member 'kumarjayanti' (kumarjayanti)]

http://forums.java.net/jive/thread.jspa?messageID=358559

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Marek Potociar]

On 31.7.2009, at 19:51, metro@... wrote:

> Will this fix make it to Metro 2.0 final release? If so do you have  
> a timeframe when it maybe released?

Yes. It will also be part of next GFv3 milestone build. Metro 2.0 FCS  
is planned to be released in September.

> I remember awhile back somewhere someone mentioned that Reliable  
> Messaging was going to have some kind of persistence or recovery  
> capability in Metro 2.0 if the container went down. Is this feature  
> in 2.0? If not is there some work around?

The feature is already in the current Metro nightly builds. It will be  
shipped as part of Metro 2.0 release.

Regards,
Marek

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[metro-3]

Great Marek thanks!

Will we as end users have some configuration options? We are very much interested in durable reliability. Any configuration tips/instructions/documentation/examples would be of great help.

Thanks again for the cool work you *guys*(gals) are doing!
[Message sent by forum member 'kellerbb' (kellerbb)]

http://forums.java.net/jive/thread.jspa?messageID=358599

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[metro-3]

Hi Kumar,

Thanks for all your help...Now that the client is straight using alias selectors and cert selectors we need to do the same on the server implementation but I wanted to get one side working first.

Since the webservice context is not available to the alias selector/cert selector for the service implementation how does Metro determine which certificate to sign or encrypt with? If the alias selector is used for this purpose how do we bind a parameter to the context so it is passed to the runtime properties of the aliasselector and certselectors?

Thanks again,

Barb
[Message sent by forum member 'kellerbb' (kellerbb)]

http://forums.java.net/jive/thread.jspa?messageID=358672

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[metro-3]

On the server side there is no way for you bind something into the context such that it could be passed in as RuntimeProperties for the alias selector.  

The algorithm that we use for server side response encryption is described in :
http://weblogs.java.net/blog/kumarjayanti/archive/2009/07/security_token.html
For signatures it is the Keystore assertion that is looked at

(things are a little different if you have configured a JMACCallbackHandler or an XWSSCallbackHandler, in those cases we directly invoke the configured callbackhandler).


But we do pass in the WSDLPort reference to the runtime properties. And i believe that should be sufficient for you to decide what should be the Server Certificate/PrivateKey.

If you need to access the Client Subject i already mentioned that you could try accessing a property named AUTH_SUBJECT.
[Message sent by forum member 'kumarjayanti' (kumarjayanti)]

http://forums.java.net/jive/thread.jspa?messageID=358723

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Marek Potociar]

On 3.8.2009, at 15:00, metro@... wrote:

> Great Marek thanks!
>
> Will we as end users have some configuration options?

Right now, it does not provide many configuration options. But this is  
something that may/will change yet, based on the input from users -  
what are the things you would like to be able to configure?

> We are very much interested in durable reliability. Any  
> configuration tips/instructions/documentation/examples would be of  
> great help.

I am sorry, but I don't have any free cycles to spend on writing a  
documentation for the feature right now. I do have it on my task list  
though. The documentation will be available later (end of August/
September) before the Metro 2.0 release.

Regrads,
Marek

>
> Thanks again for the cool work you *guys*(gals) are doing!
> [Message sent by forum member 'kellerbb' (kellerbb)]
>
> http://forums.java.net/jive/thread.jspa?messageID=358599
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[metro-3]

Hi Marek,

Understand the documentation issue (we all save the fun stuff for last!)

Regarding configurations of RM:

Not fully understanding how the durability portion works it sounds like transactions could be persisted to a database so configuration of a database would be nice.

Since it seems like RM would have its own internal JMS (like) functionality is there an API to tap into to monitor traffic or possibly change the state of a "stuck" message?

Some threshold settings to control message flow to services. More of an optimization/performance setting.  Maybe RM is not the right place to do this.

That's all I can think of for now...until I read up on all of it's capabilities I may have more....

Thanks again,

Barb
[Message sent by forum member 'kellerbb' (kellerbb)]

http://forums.java.net/jive/thread.jspa?messageID=359116

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...