A service provider mechanism is aimed to provide an access to some
service implementation. A service can be implemented by different
vendors in quite different ways (different features, favorite bugs :-),
backward compatibility and so on). We can consider Kerberos as some type
of security service
Hello,
[snip]
Kerberos is used in java in the JAAS framework and GSS-API
(org.ietf.jgss package).
[snip]
What about moving all Kerberos functionality to provider layer?
[snip]
I suggest the following: all public API are just wrappers that calls
corresponding Kerberos service provider
Dalibor Topic wrote:
Tim Ellison wrote:
Dalibor Topic wrote
Finally, we'd need to have our own, ASLv2 licensed OSGi implementation.
I am not sure if there is one, but I hope Geir knows more.
We are in luck:
http://incubator.apache.org/projects/felix.html
Yay!
and
Dalibor Topic wrote:
In terms of using a minimal OSGi environment for partitioning and
management of class library parts, what differences would be relevant
between R2/R3/R4?
Between R2 and R3, not much...you can pretty much consider those two
equivalent.
R4 adds some considerable
Tim Ellison wrote:
Dalibor Topic wrote:
Just to be clear, the kernel classes are VM-dependent types that are not
typically reusable since the VM typically will 'know' the shape of the
class/instances. I think it is useful to minimize that set.
Yeah, I think we were talking past each
Please ignore
--- Dalibor Topic [EMAIL PROTECTED] wrote:
[SNIP]
The wonderful part of that story is that noone needs
to share any code
of any component: how VMs implement the bootstrap
set of classes, which
OSGi implementation they chose, if they use JNI or
avian carrier
pidgeons :) fails to matter, and
