Re your latest check in request

[Michael Merz <mm...@bea.com>]

Hi Wolfgang,

I got your latest sources for security support in Beehive/WSM. It looks
pretty cool -- thanks much.

It looks like a bunch of source files has been borrowed from other
Apache projects (which is fine, of course). Can we refer to those files
in their respective jars (in binary format) rather than bringing the
sources into Beehive. This would be beneficial in terms of code
maintenance and protability. In order to do that, the code base might
have to be structured further.
More specifically, I think a bunch of files have been borrowed from
Tomcat, for instance, others contain some glue code for those files. I
think the Tomcat files should not go into Beehive, the Tomcat-specific
glue code should go into a package like ...beehive/wsm/tomcat/security,
for instance. Thus, the dependencies on Tomcat would be clear from the
package name. I would like to discuss that in more detail.

What do you think?

Cheers,

-michael

Re: Re your latest check in request

[wo...@yahoo.co.jp]

Hi Michael,

I've finished implementing the user-role management functionality from a
scratch.

I got a question.
I'm using XMLBeans for creating Role, User object from an XML config (
user, role info ) file.
Which one should I include in wsm ?
- xml schema ( which I made )
- generated jar file ( by XMLBeans ).
- generated src files ( by XMLBeans ).



Thanks in advance.

Wolfgang.

Re: Re your latest check in request

[wo...@yahoo.co.jp]

Hi

> As I said before, the best way is to implement the mechanism from a
> scratch

And one more,
Once I make one, it can be no longer container specific.

Anyways, the fact what Darly, Michael, Eddie mentioned (e.g. beehive commons, 
Tomcat specific code out of the tree) exists so we gotta shoot it.

Thanks in advance.

Wolfgang

Re: Re your latest check in request

[wo...@yahoo.co.jp]

Hi Eddie,

Thanks a lot for explaining me the details.  :)

Please let me explain my situation.
I had been implementing Axis handlers which allows users only listed in
@SecurityRoles.rolesAllowed annotation in jws to access.

Servlet containers and Axis have thier own security model but they both
have disadvantages when used with Beehive.
Please take a look at section 1.1 and 1.2 in
http://wiki.apache.org/beehive/WsmSecurityModel 

(If Axis's security model was role-based auth, I wouldn't implement the
new security model for Beehive.) But since it's user-based auth, 
I thought it's good to have new one (role-based) for Beehive.
Thus, I was gonna make the role-based security model from a scratch.
But wait, the security framework ( read role info from a config file )
 is already implemented in Tomcat. Why don't I borrow it then ?
So I tried to import the classes ( not source files ) and extends them or
something to work, but it was impossible because of a bunch of private,
protected signatures...
Finally, I borrowed the source files of that part.

Daryl recommended me to use ServerAdapter ( Thank you, Daryl ), 
but my problem is not that difficult problem and it doesn't work 
even though I use the Adapter pattern.
I just wanted to use the framework which already exists. 
It actually didn't have to be Tomcat's one.

As I said before, the best way is to implement the mechanism from a
scratch. It's not difficult, just read an XML file and construct Role 
objects.  

Sorry for confusing you all.

Thanks in advance.

Wolfgang

Re: Re your latest check in request

[Eddie O'Neil <ek...@bea.com>]

Wolfgang--

   Definitely, the issue of container specific build dependencies from 
the source tree is something that we'll need to address in the long run.

   Today, NetUI has three source modules that are Tomcat specific -- see 
netui/src/tomcat-* and each of these has a sub-directory that is version 
specific.  The build-time dependencies are satisfied through JARs 
checked into netui/external/5x and include catalina.jar and 
tomcat-coyote.jar.

   So, as we support different versions of Tomcat APIs, we'll need to 
add new sub-directories for source and build-time dependencies.

   As we add new containers (Jetty, Tomcat 6, etc), this set of source 
and build artifacts will grow, and we'll need to address how to manage 
this in the builds and on disk.  But, it seems reasonable to integrate 
into the functionality of a container, which can require taking some 
dependencies like this.

   What do you think?

Eddie



wolfgang127us@yahoo.co.jp wrote:
> Hi Michael, Daryl, Eddie
> 
> Are there source codes in Beehive that requires catalina.jar to build right
> now ?
> If so, How catalina.jar is managed/will be managed ?
> I'm worrying to manage the version of catalina.jar for future...
> 
> Thanks in advance.
> 
> Wolfgang.
> 
> 
> 
> 
> 
> 

Re: Re your latest check in request

[wo...@yahoo.co.jp]

Hi Michael, Daryl, Eddie

Are there source codes in Beehive that requires catalina.jar to build right
now ?
If so, How catalina.jar is managed/will be managed ?
I'm worrying to manage the version of catalina.jar for future...

Thanks in advance.

Wolfgang.

Re: Re your latest check in request

[wo...@yahoo.co.jp]

Hi Daryl,

Yes, that's a good way, but it requires catalina.jar to build Beehive
then.
If the implementation of security stuff is changed in the future version
of Tomcat, we gotta keep track on catalina_6.jar, catalina_7.jar and so
on...
Anyways, I really don't want Beehive stick to catalina.jar.

Okay, I'm happy to re-invent the wheel. ( Not sarcastic & No offend )
That's gonna be flexible anyway.  :)

Thanks in advance.

Wolfgang.

Re: Re your latest check in request

[Daryl Olander <do...@gmail.com>]

So, it doesn't seem like we should move this code out of Catalina. 
NetUI has a thing called a ServerAdaptor that abstracts some container
provided features.  Security is one of the things that is hidden
behind that API.  Then we can pluggin container provided
implementations of the ServerAdaptor.  This seems like it should be
pluggable instead of duplicating the code Catalina provides  I would
guess that each container implements this in their own way..

Rich Feit owns this in NetUI.  I think he should review the
role/user/group auth and see if it should be moved behind either the
current ServerAdaptor or some type of similar interface.


On Thu, 25 Nov 2004 01:06:59 +0900, wolfgang127us@yahoo.co.jp
<wo...@yahoo.co.jp> wrote:
> Hi Daryl,
> 
> > What are the features that you copied from Catalina?
> 
> They're as follows.
> 
> org/apache/catalina/Group.java
> org/apache/catalina/Role.java
> org/apache/catalina/User.java
> org/apache/catalina/UserDatabase.java
> 
> org/apache/catalina/users/AbstractGroup.java
> org/apache/catalina/users/AbstractRole.java
> org/apache/catalina/users/AbstractUser.java
> org/apache/catalina/users/MemoryGroup.java
> org/apache/catalina/users/MemoryRole.java
> org/apache/catalina/users/MemoryUser.java
> org/apache/catalina/users/MemoryUserDatabase.java
> 
> org/apache/catalina/util/StringManager.java
> 
> Axis implements classes that handle the user based auth (not role based)
> by itself, but it's really simple. If Axis can reuse those classes
> listed above, its auth mechanism can be empowered as well.
> (If so, Beehive doesn't have to implement those stuff though as long as
> Beehive runs on Axis.)
> 
> I believe that they all should go into commons.
> 
> Thanks in advance.
> 
> Wolfgang
> 
>

Re: Re your latest check in request

[wo...@yahoo.co.jp]

Hi Daryl,

> What are the features that you copied from Catalina?

They're as follows.

org/apache/catalina/Group.java
org/apache/catalina/Role.java
org/apache/catalina/User.java
org/apache/catalina/UserDatabase.java

org/apache/catalina/users/AbstractGroup.java
org/apache/catalina/users/AbstractRole.java
org/apache/catalina/users/AbstractUser.java
org/apache/catalina/users/MemoryGroup.java
org/apache/catalina/users/MemoryRole.java
org/apache/catalina/users/MemoryUser.java
org/apache/catalina/users/MemoryUserDatabase.java

org/apache/catalina/util/StringManager.java

Axis implements classes that handle the user based auth (not role based)
by itself, but it's really simple. If Axis can reuse those classes
listed above, its auth mechanism can be empowered as well. 
(If so, Beehive doesn't have to implement those stuff though as long as 
Beehive runs on Axis.)

I believe that they all should go into commons.

Thanks in advance.

Wolfgang

Re: Re your latest check in request

[Daryl Olander <do...@gmail.com>]

What are the features that you copied from Catalina?

I think if we take these classes, we should repackage them so we avoid
conflicts with Tomcat.  I do agree that taking a hard dependency on
catalina.jar is not a good idea because the goal is to run on all
servlet containers.  Who knows what trouble we may have is
catalina.jar starts to show up on the class path for other servlet
containers.

There are many features that are duplicated in projects (I believe
there are three Base64 encoding classes in the core NetUI project at
the moment, JSF reference implementation, XMLBeans and Catalina).  I
think if these features are generic enough, we can push to move them
from catalina.jar into commons.


On Wed, 24 Nov 2004 12:23:24 +0900, wolfgang127us@yahoo.co.jp
<wo...@yahoo.co.jp> wrote:
> Hi Michael,
> 
> I was gonna take the way you said, but there were some considerations.
> 
> The classes borrowed are only from Tomcat and they reside in catalina.jar.
> 
> The catalina.jar file is really huge.
> That's a subtle problem but can be one reason.
> And there's another reason which is critical I guess.
> If the catalina.jar is required for Beehive and
> one deploys a web service app with catalina.jar
> (WEB-INF/lib/catalina.jar) in Axis running on Tomcat,
> it might (obviously?) cause classloading problems.
> The one must be careful catalina.jar will be go into
> the directory.
> 
> On the other hand, if one deploy a web service in Axis running on the
> servlet container other than Tomcat, catalina.jar must be copied
> into WEB-INF/lib directory.
> 
> I thought that would confuse developers...so I borrowed
> the source files and commented "copied from Tomcat" in the all files.
> 
> There's a way we can avoid this.
> Implement all classes from a scratch by myself.
> ( I just didn't want re-invent the wheel. )
> 
> Thanks in advance.
> 
> Wolfgang.
> 
>

Re: Re your latest check in request

[wo...@yahoo.co.jp]

Hi Michael,

I was gonna take the way you said, but there were some considerations.

The classes borrowed are only from Tomcat and they reside in catalina.jar.

The catalina.jar file is really huge.
That's a subtle problem but can be one reason. 
And there's another reason which is critical I guess.
If the catalina.jar is required for Beehive and 
one deploys a web service app with catalina.jar
(WEB-INF/lib/catalina.jar) in Axis running on Tomcat, 
it might (obviously?) cause classloading problems.
The one must be careful catalina.jar will be go into 
the directory.

On the other hand, if one deploy a web service in Axis running on the 
servlet container other than Tomcat, catalina.jar must be copied 
into WEB-INF/lib directory.

I thought that would confuse developers...so I borrowed 
the source files and commented "copied from Tomcat" in the all files.

There's a way we can avoid this.
Implement all classes from a scratch by myself.
( I just didn't want re-invent the wheel. )

Thanks in advance.

Wolfgang.

Re: Re your latest check in request

[Daryl Olander <do...@gmail.com>]

I wouldn't duplicate code from Tomcat unless the code is repackaged. 
NetUI runs against multiple versions of Tomcat and if there are
changes in the duplicated code, it will cause errors that are pretty
hard to figure out....


On Tue, 23 Nov 2004 12:03:33 -0800, Michael Merz <mm...@bea.com> wrote:
> Hi Wolfgang,
> 
> I got your latest sources for security support in Beehive/WSM. It looks
> pretty cool -- thanks much.
> 
> It looks like a bunch of source files has been borrowed from other
> Apache projects (which is fine, of course). Can we refer to those files
> in their respective jars (in binary format) rather than bringing the
> sources into Beehive. This would be beneficial in terms of code
> maintenance and protability. In order to do that, the code base might
> have to be structured further.
> More specifically, I think a bunch of files have been borrowed from
> Tomcat, for instance, others contain some glue code for those files. I
> think the Tomcat files should not go into Beehive, the Tomcat-specific
> glue code should go into a package like ...beehive/wsm/tomcat/security,
> for instance. Thus, the dependencies on Tomcat would be clear from the
> package name. I would like to discuss that in more detail.
> 
> What do you think?
> 
> Cheers,
> 
> -michael
>