You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Eric Dobbs <er...@dobbse.net> on 2002/02/08 02:55:37 UTC

Re: Security Changes (1 of 3) - Repository, Empty Interfaces

Hi All.

First off, I think the original misunderstanding is
mine.  But, this thread has cleared up a bit of my
confusion.

Because it seems like my contributions are holding up
the merge for RunData, I've moved my stuff into
proposals/eric/security folder.  I have also moved
Gonzalo's stuff back inside o.a.t.security.turbine.
The only thing in o.a.t.security is the empty
SecurityManager interface.

This might go without saying, but just in case ...
Although I've moved my stuff into proposals and left
Gonzalo's in the src tree, I have not given up on
evangelizing some aspects of the JAAS design.  8^)
It seems I'm outnumbered in this conversation, but I
haven't given up yet. 8^)

Kurt, hopefully moving my stuff into proposals
addresses your concern about littering the package
namespace -- it's only in the proposals directory and
not among the src tree.

Jason, will that let you proceed with your RunData
work?


About the interfaces in o.a.t.security:

I originally pushed the interfaces into this package in
an effort to follow the model Jason set in o.a.turbine:
put the public interfaces at the base of the package
tree where developers can easily identify the public
interface.  I think I see now why that's not what you
had in mind for the security stuff (more on that
below).


Empty interfaces:

I was confused about the idea of empty interfaces.  But
if I understand the thinking now, the idea is to have
ONE empty interface for the SecurityManager.  Everthing
else would be hidden behind implementations of
SecurityManager.  That makes much more sense than the
whole mess of empty interfaces I had created.  Also,
with this in mind, I agree that SecurityManager is
better than Policy because it follows the naming
conventions in Turbine.  I can keep using Policy in my
proposed implementation but hide it behind
SecurityManager.  8^)


Would it make sense to put the empty SecurityManager
interface into o.a.turbine, and put the specific
implementations inside o.a.t.security?  Another way to
ask this question: First, am I correct about the goal
of putting the public api in o.a.turbine?  Second,
should the empty SecurityManager interface go there
too?

-Eric

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Security Changes (1 of 3) - Repository, Empty Interfaces

Posted by Jason van Zyl <jv...@zenplex.com>.
On 2/7/02 9:24 PM, "Eric Dobbs" <er...@dobbse.net> wrote:

> On Thursday, February 7, 2002, at 07:04  PM, Jason van Zyl wrote:
> 
>> I've still been working on it, you're not interfering with anything I'm
>> doing I just wanted the branch to compile.
> 
> I think I cleaned up all the compile errors from o.a.t.security
> yesterday or the day before.  I just tried compiling the branch
> at my home computer -- ton of compile errors, but none in
> security.

I'm usually the culprit :-) I try a fresh checkout and see what's going on.

> 
> -Eric
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>

-- 

jvz.

Jason van Zyl

http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: Security Changes (1 of 3) - Repository, Empty Interfaces

Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
> I just checked in a bunch of changes, and checked out a fresh tree and
> everything compiles in the rundata_security_changes branch.

I just did an update and update-jars, and recompiled everything; got
the following compilation errors:


    [javac]
D:\gonzo\head\turbine-sec\src\java\org\apache\turbine\services\pull\
TurbinePullService.java:314: incompatible types
    [javac] found   : org.apache.commons.collections.ExtendedProperties
    [javac] required: org.apache.stratum.configuration.Configuration
    [javac]             getConfiguration().subset(keyPrefix);
    [javac]                                      ^
    [javac]
D:\gonzo\head\turbine-sec\src\java\org\apache\turbine\Turbine.java:6
30: setConfiguration(org.apache.commons.collections.ExtendedProperties) in
org.a
pache.fulcrum.ServiceManager cannot be applied to
(org.apache.stratum.configurat
ion.Configuration)
    [javac]         serviceManager.setConfiguration(configuration);
    [javac]                       ^
    [javac] Note: Some input files use or override a deprecated API.
    [javac] Note: Recompile with -deprecation for details.
    [javac] 2 errors



--
Gonzalo A. Diethelm
gonzalo.diethelm@aditiva.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Security Changes (1 of 3) - Repository, Empty Interfaces

Posted by Jason van Zyl <jv...@zenplex.com>.
On 2/7/02 9:24 PM, "Eric Dobbs" <er...@dobbse.net> wrote:

> On Thursday, February 7, 2002, at 07:04  PM, Jason van Zyl wrote:
> 
>> I've still been working on it, you're not interfering with anything I'm
>> doing I just wanted the branch to compile.
> 
> I think I cleaned up all the compile errors from o.a.t.security
> yesterday or the day before.  I just tried compiling the branch
> at my home computer -- ton of compile errors, but none in
> security.

I just checked in a bunch of changes, and checked out a fresh tree and
everything compiles in the rundata_security_changes branch.

It only compiles, it won't pass the testbed. I just wanted to get my changes
in.

> 
> -Eric
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>

-- 

jvz.

Jason van Zyl

http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Security Changes (1 of 3) - Repository, Empty Interfaces

Posted by Eric Dobbs <er...@dobbse.net>.
On Thursday, February 7, 2002, at 07:04  PM, Jason van Zyl wrote:

> I've still been working on it, you're not interfering with anything I'm
> doing I just wanted the branch to compile.

I think I cleaned up all the compile errors from o.a.t.security
yesterday or the day before.  I just tried compiling the branch
at my home computer -- ton of compile errors, but none in
security.

-Eric


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Security Changes (1 of 3) - Repository, Empty Interfaces

Posted by Jason van Zyl <jv...@zenplex.com>.
On 2/7/02 8:55 PM, "Eric Dobbs" <er...@dobbse.net> wrote:

> Hi All.
> 
> First off, I think the original misunderstanding is
> mine.  But, this thread has cleared up a bit of my
> confusion.
> 
> Because it seems like my contributions are holding up
> the merge for RunData, I've moved my stuff into
> proposals/eric/security folder.

You're not holding up anything, I'm still futzing around and I can work
around anything. No worries.

> I have also moved
> Gonzalo's stuff back inside o.a.t.security.turbine.
> The only thing in o.a.t.security is the empty
> SecurityManager interface.
> 
> This might go without saying, but just in case ...
> Although I've moved my stuff into proposals and left
> Gonzalo's in the src tree, I have not given up on
> evangelizing some aspects of the JAAS design.  8^)
> It seems I'm outnumbered in this conversation, but I
> haven't given up yet. 8^)
> 
> Kurt, hopefully moving my stuff into proposals
> addresses your concern about littering the package
> namespace -- it's only in the proposals directory and
> not among the src tree.
> 
> Jason, will that let you proceed with your RunData
> work?

I've still been working on it, you're not interfering with anything I'm
doing I just wanted the branch to compile.
 
> 
> About the interfaces in o.a.t.security:
> 
> I originally pushed the interfaces into this package in
> an effort to follow the model Jason set in o.a.turbine:
> put the public interfaces at the base of the package
> tree where developers can easily identify the public
> interface.  I think I see now why that's not what you
> had in mind for the security stuff (more on that
> below).
> 
> 
> Empty interfaces:
> 
> I was confused about the idea of empty interfaces.  But
> if I understand the thinking now, the idea is to have
> ONE empty interface for the SecurityManager.

This interface may extend some of the basic lifecycle interfaces but that's
about it.

>  Everthing
> else would be hidden behind implementations of
> SecurityManager.  That makes much more sense than the
> whole mess of empty interfaces I had created.  Also,
> with this in mind, I agree that SecurityManager is
> better than Policy because it follows the naming
> conventions in Turbine.  I can keep using Policy in my
> proposed implementation but hide it behind
> SecurityManager.  8^)
> 
> 
> Would it make sense to put the empty SecurityManager
> interface into o.a.turbine, and put the specific
> implementations inside o.a.t.security?  Another way to
> ask this question: First, am I correct about the goal
> of putting the public api in o.a.turbine?  Second,
> should the empty SecurityManager interface go there
> too?

I'd like to think about that one before merging the branch into the trunk. I
was toying with the idea of putting the security stuff in a separate
src/security directory but I'm not sure yet just to keep the core source
small and comprehensible. Not sure about the packaging yet either.
 
> -Eric
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>

-- 

jvz.

Jason van Zyl

http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: Security Changes (1 of 3) - Repository, Empty Interfaces

Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
> I have also moved
> Gonzalo's stuff back inside o.a.t.security.turbine.
> The only thing in o.a.t.security is the empty
> SecurityManager interface.

My code is a proposal, just as yours is...

> Although I've moved my stuff into proposals and left
> Gonzalo's in the src tree, I have not given up on
> evangelizing some aspects of the JAAS design.  8^)
> It seems I'm outnumbered in this conversation, but I
> haven't given up yet. 8^)

Good. You might end up convincing me.

> -Eric


-- 
Gonzalo A. Diethelm
gonzalo.diethelm@aditiva.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>