Hi Stepan, 

> >>com.openintel.drl.security.provider.cert
> It is a certificate provider package. It is not intended to be exported 
and
> used by other modules.

Agreed. Thanks for spotting. At one point I had been working to see if the 

accompanying unit test code could be placed in a separate bundle and had 
to 
add this export from "security" to "security.tests". I eventually gave up 
on
trying to make that work but had left this export in by mistake. 
 

> By the way, we need to decide where this (and others) provider should be
> placed. For example, in the same module: crypto providers in 'crypto
> module', security providers in 'security module' and so on. Or does it 
make
> sense to separate them into a standalone module?

Just received your other mail about this while typing out this note. Will
respond in that thread. 


> >>com.ibm.oti.util,
> I'm little bit confused. Where did you get it? Security bundle should 
not
> require it.

Yes, including this was an error on my part. Sorry. 


> >>com.openintel.drl.security.test,
> Neither crypto nor x-net modules require it. This package is used for 
unit
> tests only.

Another bit of debris from my experimentation on having separate bundles 
for
the unit test code.


> com.openintel.drl.security.utils should be added to list of exported
> packages.

OK, understood. Didn't pick up on this one as I was focussed on how 
security, crypto and x_net related to one
another after the experimental split. 


Many thanks for clarifying my understanding of the split. It is greatly 
appreciated.

Best regards, 
George
________________________________________
George C. Harley




Stepan Mishura <[EMAIL PROTECTED]> 
17/01/2006 10:53
Please respond to
harmony-dev@incubator.apache.org


To
harmony-dev@incubator.apache.org
cc

Subject
Re: Splitting security2 and classlib architecture






Hi, George

Thanks for splitting. It looks realistic.
Here are some comments and suggestions.

>>com.openintel.drl.security.provider.cert
It is a certificate provider package. It is not intended to be exported 
and
used by other modules.

By the way, we need to decide where this (and others) provider should be
placed. For example, in the same module: crypto providers in 'crypto
module', security providers in 'security module' and so on. Or does it 
make
sense to separate them into a standalone module?

>>com.ibm.oti.util,
I'm little bit confused. Where did you get it? Security bundle should not
require it.

>>com.openintel.drl.security.test,
Neither crypto nor x-net modules require it. This package is used for unit
tests only.

com.openintel.drl.security.utils should be added to list of exported
packages.

Thanks,
Stepan Mishura
Intel Middleware Products Division


On 1/17/06, George Harley1 <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I've spent a little bit of time looking at how the contents of security2
> can be split into the proposed security, crypto and x_net component
> bundles and how this will work at runtime. Below is a first 
approximation
> at what I *think* each of the resulting bundles will export to and 
import
> from other bundles at runtime. Does this look realistic to the
> contributors ? Thanks in advance for any comments or corrections.
>
>
> * Bundle : Security
> ================
>
> * contains packages ...
>
> com.openintel.drl.misc
> com.openintel.drl.security
> com.openintel.drl.security.asn1
> com.openintel.drl.security.pkcs7
> com.openintel.drl.security.provider.cert
> com.openintel.drl.security.utils
> com.openintel.drl.security.x501
> com.openintel.drl.security.x509
> com.openintel.drlx.security.auth
> com.openintel.drlx.security.auth.login
> com.openintel.fortress.drl.security
> java.security
> java.security.acl
> java.security.cert
> java.security.interfaces
> java.security.spec
> javax.security.auth
> javax.security.auth.callback
> javax.security.auth.kerberos
> javax.security.auth.login
> javax.security.auth.spi
> javax.security.auth.x500
> javax.security.cert
> javax.security.sasl
> org.ietf.jgss
>
>
> * bundle exports the following packages to other bundles ...
>
> com.openintel.drl.misc,
> com.openintel.drl.security,
> com.openintel.drl.security.asn1,
> com.openintel.drl.security.pkcs7,
> com.openintel.drl.security.provider.cert,
> com.openintel.drl.security.x501,
> com.openintel.drl.security.x509,
> com.openintel.fortress.drl.security,
> java.security,
> java.security.acl,
> java.security.cert,
> java.security.interfaces,
> java.security.spec,
> javax.security.auth,
> javax.security.auth.callback,
> javax.security.auth.kerberos,
> javax.security.auth.login,
> javax.security.auth.spi,
> javax.security.auth.x500,
> javax.security.cert,
> javax.security.sasl,
> org.ietf.jgss
>
>
> * bundle requires the following packages from other bundles ...
>
> com.ibm.oti.util,
> com.openintel.drlx.crypto.utils,
> java.io,
> java.lang,
> java.lang.reflect,
> java.math,
> java.net,
> java.nio,
> java.text,
> java.util,
> java.util.zip,
> javax.crypto
>
>
> ================
> ================
>
>
>
> * Bundle : Crypto
> ================
>
> * contains packages ...
>
> com.openintel.drlx.crypto
> com.openintel.drlx.crypto.utils
> javax.crypto
> javax.crypto.interfaces
> javax.crypto.spec
>
>
> * bundle exports the following packages to other bundles ...
>
> com.openintel.drlx.crypto.utils,
> javax.crypto,
> javax.crypto.interfaces,
> javax.crypto.spec
>
>
> * bundle requires the following packages from other bundles ...
>
> com.openintel.drl.security,
> com.openintel.drl.security.asn1,
> com.openintel.drl.security.test,
> com.openintel.drl.security.x509,
> com.openintel.fortress.drl.security,
> java.io,
> java.lang,
> java.math,
> java.nio,
> java.security,
> java.security.cert,
> java.security.spec,
> java.util
>
>
>
> ================
> ================
>
>
>
> * Bundle : X_Net
> ================
>
>
> * contains packages ...
>
> javax.net
> javax.net.ssl
>
>
> * bundle exports the following packages to other bundles ...
>
> javax.net,
> javax.net.ssl
>
>
> * bundle requires the following packages from other bundles ...
>
> com.openintel.drl.security.test,
> com.openintel.fortress.drl.security,
> java.io,
> java.lang,
> java.net,
> java.nio,
> java.security,
> java.security.cert,
> java.util,
> javax.security.cert
>
>
>
> ================
> ================
>
>
> Best regards,
> George
> ________________________________________
> George C. Harley
>
>
>


Reply via email to