September 2006 - jboss-dev-forums

[Design of Security on JBoss] - Re: new LDAP Login Module

by rsoika

Hi scott, I did not seen the org.jboss.security.auth.spi.LdapExtLoginModule before - so I did a lot of work twice ;-) but ok. I updated my code a little bit so it uses now the smarter search filter param like used in the org.jboss.security.auth.spi.LdapExtLoginModule. I think the main different is now the method searchDistinguishedName() and the fact that the distinguished name found will replace the CallerPrincipal. Also the Distinguished name is translated into a composite name. So for example: users login with "x007" -> DN of the UserObeject is "James Bond,OU=Secret Service" -> Composite name is "James Bond/OU=Secret Service". Maybe this is an insignificant detail but in our workflow project (www.imixs.org) we are constrained to work with composite names. I tried now also the org.jboss.security.auth.spi.LdapExtLoginModule to configure my Lotus Domino Server - but have no success. I think it is not a recommendable way to overload the org.jboss.security.auth.spi.LdapExtLoginModule or org.jboss.security.auth.spi.LdapLoginModule with more params so things like the replacement of the caller pricipal or the translation into a composite DN will be configurable. This modules did work ok. Maybe JBoss will offer more specialized LDAP Login Modules for different servers like my one for Lotus Domino? kind regards ralph View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972099#3972099 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972099

19 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-541 - Multiple connections on a single threa

by ovidiu.feodorov＠jboss.com

There's a lot to talk about Remoting, but how about leaving this thread alone, it was orginally created for a very specific problem and now we're diverging. As far as I know, we can use for http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971508 that. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972094#3972094 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972094

19 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-541 - Multiple connections on a single threa

by timfox

"ovidiu.feodorov(a)jboss.com" wrote : | | HTTP is Ron's entry point in Messaging | | So yes there is value in doing this from the point of view of getting acquainted with the code base. And, well... yes maybe we can keep the old http transport, but personally I don't think this is the way to go. I am sure we will debate this a lot in the future weeks/months :) I am all for a clean new approach where we don't have to mess around with callback servers and other unnecessary baggage. My POV would be, until we have come up with a definite plan w.r.t. remoting and how we're going to implement each transport then we shouldn't waste time working on something which has a good chance of being chucked. Just my 2c View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972093#3972093 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972093

19 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-541 - Multiple connections on a single threa

by ovidiu.feodorov＠jboss.com

Tim wrote : So let's not waste too much time on remoting related issues (this includes the http or multiplex transports) HTTP is Ron's entry point in Messaging, he's already advanced in getting it working, and one of the possible approaches to the Remoting issue is to extend it with asynch support, but still use things as HTTP as they are. Multiplex is a different issue, it will definitely NOT be Ron's next task after he is done with HTTP. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972092#3972092 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972092

19 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-541 - Multiple connections on a single threa

by timfox

"ovidiu.feodorov(a)jboss.com" wrote : | However, the fix for the current issue should be trivial, so I see no reason not to do it. | That's why I said we should do a quick fix for now in my previous post. :) anonymous wrote : | It think it would be a good tactical decision NOT to attack the AMQP/Remoting issue now, but wait until after the 1.2 Alpha release. I'm not suggesting we do this now, just making the point we're going to have do this over the next few months. So let's not waste too much time on remoting related issues (this includes the http or multiplex transports) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972090#3972090 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972090

19 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-541 - Multiple connections on a single threa

by ovidiu.feodorov＠jboss.com

Tim wrote : So we're probably going to have to throw the socket transport away anyway. Maybe. However, the fix for the current issue should be trivial, so I see no reason not to do it. It think it would be a good tactical decision NOT to attack the AMQP/Remoting issue now, but wait until after the 1.2 Alpha release. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972089#3972089 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972089

19 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-541 - Multiple connections on a single threa

by timfox

"ovidiu.feodorov(a)jboss.com" wrote : | I would rather fix Remoting. | | I would suspect fixing it is as simple as NOT disabling lease pinging unless ClientInvokerHolder.counter for the client being disconnected is 1. Any value higher than 1 means that the client is still in use by somebody else. However, this is just a superficial attempt to come with a solution and needs to be validated by the Remoting team. | | As soon as the Remoting team produces a fix, we can release CR5 based on a remoting snapshot. I agree which should do a quick fix for now. All this is moot over the next few months, since remoting is incompatible with an AMQP style model, which we're going to have to implement if we're going to support AMQP. So we're probably going to have to throw the socket transport away anyway. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972088#3972088 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972088

19 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-541 - Multiple connections on a single threa

by ovidiu.feodorov＠jboss.com

At first, I was tempted to say that since a JMS Connection is a heavy-weight object anyway, it does not matter too much if each JMS Connection instance creates and maintains its own separate TCP/IP connection (which it will do if we explicitly and distinctly "name" remoting clients, as you suggested). However, the physical TCP/IP connection pooling offered by remoting may prove beneficial in some use cases. Imagine 100 co-located JMS clients opening connections to a server, but sending messages at a relatively low rate. If we disable remoting TCP/IP connection pooling, we'll have 100 distinct physical TCP/IP connection, each of them firing from time to time, and sitting idle the rest of the time. If we use TCP/IP connection pooling, it is very likely to actually start a very low number of physical TCP/IP connections, the actual number depending on the send rate, as each TCP/IP connection is allocated on an invocation basis. I would rather fix Remoting. I would suspect fixing it is as simple as NOT disabling lease pinging unless ClientInvokerHolder.counter for the client being disconnected is 1. Any value higher than 1 means that the client is still in use by somebody else. However, this is just a superficial attempt to come with a solution and needs to be validated by the Remoting team. As soon as the Remoting team produces a fix, we can release CR5 based on a remoting snapshot. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972082#3972082 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972082

19 years, 6 months

1
0
0 / 0

[Design of JBoss Portal] - Re: WANTED: Input from administrators & developers

by roy.russo＠jboss.com

One more point: XML Export of the portal config, and even a versionable snapshot that I can rollback if need be. Also helps enterprise customers move their staging env to production without having to synch DBs. Thomas, do you know how much of this will be made available through ON, exclusively? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972079#3972079 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972079

19 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - JBMESSAGING-432 - Connection Leaking on Factory (1 connectio

by clebert.suconic＠jboss.com

In regard to JBMESSAGING-432, is this in regard to the Client created inside ClientConnectionFactoryDelegate::invoke? Also, what was the intent of having a separate client here. I mean, why we didn't use a single client for this here? Clebert View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972047#3972047 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972047

19 years, 6 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums September 2006