Re: [jetty-dev] Patch to SpnegoLoginService; want feedback on best solut

[Jesse McConnell <jesse@xxxxxxxxxxx>]

Eirik,

thanks for the note to the list, first I want to give you a heads up
that to accept a patch on this it will have to come in through
bugzilla

I am the one that added this functionality a while back, based on some
work in jetty6 I had done prior.  At the moment I don't have a strong
preference one way or other with what your proposing, I am more
interested in what it will look like with your other values your
looking to add, if they are general additions then I am all for
accepting them into the login service itself, otherwise I would be
open to the idea of an extension mechanism of some sort.

either way, just submit the patch to bugzilla with what your thoughts
are and I'll review in short order.

http://wiki.eclipse.org/Jetty/Contributor/Contributing_Patches

cheers!
jesse

--
jesse mcconnell
jesse@xxxxxxxxxxx

http://webtide.com / http://intalio.com
(the folks behind jetty and cometd)



On Thu, Oct 13, 2011 at 12:13, Eirik Lygre <eirik.lygre@xxxxxxxxx> wrote:
> We're going to use SpnegoLoginService in an embedded application, and will
> want to submit a patch to it. This email is a question asking if anybody has
> preferences to which path to follow. (The current code is at
> http://download.eclipse.org/jetty/stable-8/xref/org/eclipse/jetty/security/SpnegoLoginService.html).
> 1) Currently, SpnegoLoginService  is initialized with a "config" variable,
> which is a resource name used during doStart() to look up a property file
> (through
> orc.eclipse.jetty.util.resource.Resource.newResource()). SpnegoLoginService
> will load a single property "targetName" from that property.
> public class SpnegoLoginService extends AbstractLifeCycle implements
> LoginService
> {
>     public SpnegoLoginService( String name, String config )
>     {
>         setName(name);
>         setConfig(config);
>     }
>     ...
> }
>
> 2) We want to enhance this, to retrieve the property from an already
> existing configuration setup that we have, and are looking at one of two
> other configuration options:
> a) In one scenarion, we add a new constructor for sending in an actual
> java.util.Properties object. This "scales" also with new properties, should
> they ever be needed. doStart() will need to decide to load properties or
> not.
> public class SpnegoLoginService extends AbstractLifeCycle implements
> LoginService
> {
>     public SpnegoLoginService( String name, Properties configProperties)
>     {
>         setName(name);
>         setConfig(configProperties);    // Does not exist; will also be
> implemented
>     }
>     ...
> }
> b) In another scenario, we "only" add a setter for the actual propertyValue.
> Same functionality, but different API.
> public class SpnegoLoginService extends AbstractLifeCycle implements
> LoginService
> {
>     public void  setTargetName  ( String  targetName )
>     {
>         if (isRunning())
>         {
>             throw new IllegalStateException("Running");
>         }
>
>          _targetName =  targetName ;
>     }
>     ...
> }
>
> I ask this question only because I want to submit the patch back into the
> mainline code, and want that submission to be as smooth as possible :-)
> --
> Eirik
>
> There is no high like a tango high
> There is no low like a tango low
>
> _______________________________________________
> jetty-dev mailing list
> jetty-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>
>