/me points at stuff worth saving...
On Wed, Feb 15, 2006 at 10:23:53AM +, Tim Ellison wrote:
Mikhail Loenko wrote:
> Sounds reasonable.
>
> Sure, I can make 'getInstance' functionality visible as an internal API.
>
> So we put classes that has many internal dependencies into the same component,
> but not only that. For example java.lang.Error and java.lang.Ecxeption do not
> have intern
Sounds reasonable.
Sure, I can make 'getInstance' functionality visible as an internal API.
So we put classes that has many internal dependencies into the same component,
but not only that. For example java.lang.Error and java.lang.Ecxeption do not
have internal dependencies but we put them into
Mikhail Loenko wrote:
> There is coupling.
> BTW... Could you give an example of "close" and "weak" coupling?
Sure. The goal is to define modules that represent functional units
whose implementation can be contained within the module as much as
possible. The measure of coupling is the number of
There is coupling.
BTW... Could you give an example of "close" and "weak" coupling?
The following two groups of classes use the same internal stuff:
GROUP1 (use/provide inernal implementation of 'getInstance' ):
java.security.AlgorithmParameterGenerator
java.security.AlgorithmParameters
java.secur
Mikhail Loenko wrote:
> Tim
>
> On 2/13/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
>> Mikhail Loenko wrote:
>>> It looks good but it is not clear where would you put certification stuff.
>>> According to SUN's guide it is splitted between JSSE and general security.
>>> (According to SUN general se
Tim
On 2/13/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
> Mikhail Loenko wrote:
> > It looks good but it is not clear where would you put certification stuff.
> > According to SUN's guide it is splitted between JSSE and general security.
> > (According to SUN general security includes also crypto a
Mikhail Loenko wrote:
> It looks good but it is not clear where would you put certification stuff.
> According to SUN's guide it is splitted between JSSE and general security.
> (According to SUN general security includes also crypto architecture)
I wouldn't get too hung up about where Sun put it.
It looks good but it is not clear where would you put certification stuff.
According to SUN's guide it is splitted between JSSE and general security.
(According to SUN general security includes also crypto architecture)
I'd rather put it into crypto (or maybe into x-net) - all of them use
service
javax.crypto is an "exportable" package: it's defined as an extension
(JCE) that has key and parameters' export restrictions defined in
JAVA_HOME/lib/security/local_policy.jar and
JAVA_HOME/lib/security/US_export_policy.jar
If you don't define such restrictions its make sense to merge JCE with JCA
Mikhail Loenko wrote:
> What I'd like to propose is:
>
> 1. separate Authentication and Authorization stuff (javax.security
> package) from general security
Ok, so I can see this.
> 2. unite crypto (java.security) and crypto extension (javax.crypto)
but this makes no sense to me. Why would you
x-net is a separate module according to both original and proposed
componentization.
What I'd like to propose is:
1. separate Authentication and Authorization stuff (javax.security
package) from general security
2. unite crypto (java.security) and crypto extension (javax.crypto)
It would make co
I don't understand. I did the breakout of x-net...
Mikhail Loenko wrote:
Geir
Sounds like no one objects to the proposal itself, the discussion is about the
naming. Could you please approve/decline new componentization?
Thanks,
Mikhail
On 1/27/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
Tim,
The goal is to unite JCA and JCE (crypto and crypto extension).
JCA is a part of general security...
Another goal is to separate Authentication and Authorization stuff from
general security.
Thanks,
Mikhail
Why would you put JCE and general security together?
Regards,
Tim
Mikhail Loenko wrote:
> Geir
>
> Sounds like no one objects to the proposal itself, the discussion is about the
> naming. Could you please approve/decline new componentization?
>
> Thanks,
> Mikhail
>
> On 1/27/06, Geir Magnusso
Geir
Sounds like no one objects to the proposal itself, the discussion is about the
naming. Could you please approve/decline new componentization?
Thanks,
Mikhail
On 1/27/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
>
>
> Stepan Mishura wrote:
> >> Sounds dirty. How about security-x?
> >>
>
Stepan Mishura wrote:
Sounds dirty. How about security-x?
Ok. I named it by analogy with x-net. Your variant works for me.
x-net has the same issue for me. I figure that net-x is better too
because it will sit next to net in a directory/IDE package tree, etc...
(just like security-x ne
>
>Sounds dirty. How about security-x?
>
Ok. I named it by analogy with x-net. Your variant works for me.
Thanks,
Stepan
On 1/27/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
>
> Sounds dirty. How about security-x?
>
> Stepan Mishura wrote:
> > I agree with the proposal and I'm ready to st
Sounds dirty. How about security-x?
Stepan Mishura wrote:
I agree with the proposal and I'm ready to start working on a patch for
splitting 'security2' into suggested components and integrating them with
the current build.
Also I'd like to suggest a name for a new component: 'x-security'.
Tha
I agree with the proposal and I'm ready to start working on a patch for
splitting 'security2' into suggested components and integrating them with
the current build.
Also I'd like to suggest a name for a new component: 'x-security'.
Thanks,
Stepan Mishura
Intel Middleware Products Division
On 1
Hello
Let's start a different thread for that.
I suggest revisiting current componentization for security related parts.
Now we have for example crypto architecture in security module but
crypto extension in the crypto module.
See natural components in the UserGuide
http://java.sun.com/j2se/1.5.
21 matches
Mail list logo
