jsdsi-devel — JSDSI Developers

Re: [Jsdsi-devel] JSDSI and Exceptions

[Sean R. <sra...@ae...>]

Sorry Sameer,


I did realise about your use of ProofFoundException, and your javadoc is
clear - I missed the 'No' in my little 'diagram'. However, that was also
a mistake as there is not a NoProofFoundException class!!!!! I was
getting mixed up with my distributed Prover class stuff!!! (which I am
still working towards getting into jsdsi!)

I'll create jsdsi.JsdsiRuntimeException and then we can all start to use
it and retrofit it into the existing code as soon as.

Thanks,

Sean


On Mon, 2004-04-05 at 16:52, Sameer Ajmani wrote:
> Arrrgghhh.  You're the second person to misread "ProofFoundException" as
> "NoProofFoundException".  ProofFoundException is for internal use only:
> it's a deliberate misuse of the exception mechanism to make reporting the
> discovery of a proof easier.  Since a proof may be found deep within a
> recursive call, it's easier to return the proof by throwing an exception
> than by returning it as a value and checking it on every return.  The
> javadoc for that exception makes this very clear.
> 
> That said, I agree throwing Error is ugly.  For now, we can change each of
> these to throw JsdsiRuntimeException.  Eventually we will want to refine
> this with subclasses for specific kinds of errors.  We will need to search
> for any places where this exception might accidentally be caught (catches
> for RuntimeException, Exception, or Throwable).
> 
> Sameer
> 
> > Guys,
> >
> > Been thinking about exceptions and JSDSI. Basically I think it is a
> > little wrong that in lots of places Error is thrown wrapping the cause
> > of the exception.
> >
> > I feel that we should have a base JSDSI exception class (that allows
> > nesting) and which may or may not have sub-classes. I think that in most
> > cases where exceptions occur in JSDSI, any calling application has no
> > real chance of recovery ans so it makes sense to extend from
> > RuntimeException. I'm not sure about NoProofFoundException, I could be
> > persuaded either way that it should or should not be a
> > RuntimeException...
> >
> > So I guess we could have:
> >
> > java.lang.RuntimeException
> > |
> > +jsdsi.JsdsiRuntimeException
> > |
> > +jsdsi.Prover.ProverException
> >
> >
> > or
> >
> > java.lang.RuntimeException
> > |
> > +jsdsi.JsdsiRuntimeException
> >
> > and
> >
> > java.lang.Exception
> > |
> > +jsdsi.JsdsiException
> > |
> > +jsdsi.Prover.ProverException
> >
> >
> > What do you all think? Am I the only one who thinks that what we
> > currently have needs improving?
> >
> > Sean
> >
> >
> > --
> > Dr. Sean Radford, MBBS, MSc
> > sra...@ae...
> > http://www.aegeus-technology.com
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IBM Linux Tutorials
> > Free Linux tutorial presented by Daniel Robbins, President and CEO of
> > GenToo technologies. Learn everything from fundamentals to system
> > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> > _______________________________________________
> > Jsdsi-devel mailing list
> > Jsd...@li...
> > https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
> 
> 
> http://ajmani.net
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Jsdsi-devel mailing list
> Jsd...@li...
> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

Re: [Jsdsi-devel] JSDSI and Exceptions

[Michael A. J. <mj...@iv...>]

Hi Sean,

I agree with you -- I had the same probs when writing my master's thesis last 
year.

I would prefer the second proposal with the ProverException being a 
JsdsiException as in my opinion a ProverException is not a RuntimeException 
in its original meaning.

Bye,
Michael.

P.S.:  I'm very happy that there is so much traffic on the list after that 
many months of silence!

On Monday 05 April 2004 17:34, Sean Radford wrote:
> Guys,
>
> Been thinking about exceptions and JSDSI. Basically I think it is a
> little wrong that in lots of places Error is thrown wrapping the cause
> of the exception.
>
> I feel that we should have a base JSDSI exception class (that allows
> nesting) and which may or may not have sub-classes. I think that in most
> cases where exceptions occur in JSDSI, any calling application has no
> real chance of recovery ans so it makes sense to extend from
> RuntimeException. I'm not sure about NoProofFoundException, I could be
> persuaded either way that it should or should not be a
> RuntimeException...
>
> So I guess we could have:
>
> java.lang.RuntimeException
>
> +jsdsi.JsdsiRuntimeException
>
> +jsdsi.Prover.ProverException
>
>
> or
>
> java.lang.RuntimeException
>
> +jsdsi.JsdsiRuntimeException
>
> and
>
> java.lang.Exception
>
> +jsdsi.JsdsiException
>
> +jsdsi.Prover.ProverException
>
>
> What do you all think? Am I the only one who thinks that what we
> currently have needs improving?
>
> Sean

-- 
+ Michael A. Jaeger, University of Technology Berlin
+ Intelligent Networks and Management of Distributed Systems
+ http://ivs.tu-berlin.de/mjaeger

[Jsdsi-devel] Principal.getURIs()

[Sean R. <sra...@ae...>]

Guys...


How do we feel about making sdsi.Principal declare the method:

public URI[] getURIs();

?

jsdsi.PublicKey supports this method anyway, and jsdsi.PublicKeyHash can
easily delegate to its enclosed jsdsi.Hash object.

Doing so means that if one has a jsdsi.Principal, it is extremely easy
to get the list of locator URI's for where Certificates might be found
empowering the Principal.

Thoughts,


Sean


-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

Re: [Jsdsi-devel] JSDSI and Exceptions

[Sameer A. <aj...@cs...>]

Arrrgghhh.  You're the second person to misread "ProofFoundException" as
"NoProofFoundException".  ProofFoundException is for internal use only:
it's a deliberate misuse of the exception mechanism to make reporting the
discovery of a proof easier.  Since a proof may be found deep within a
recursive call, it's easier to return the proof by throwing an exception
than by returning it as a value and checking it on every return.  The
javadoc for that exception makes this very clear.

That said, I agree throwing Error is ugly.  For now, we can change each of
these to throw JsdsiRuntimeException.  Eventually we will want to refine
this with subclasses for specific kinds of errors.  We will need to search
for any places where this exception might accidentally be caught (catches
for RuntimeException, Exception, or Throwable).

Sameer

> Guys,
>
> Been thinking about exceptions and JSDSI. Basically I think it is a
> little wrong that in lots of places Error is thrown wrapping the cause
> of the exception.
>
> I feel that we should have a base JSDSI exception class (that allows
> nesting) and which may or may not have sub-classes. I think that in most
> cases where exceptions occur in JSDSI, any calling application has no
> real chance of recovery ans so it makes sense to extend from
> RuntimeException. I'm not sure about NoProofFoundException, I could be
> persuaded either way that it should or should not be a
> RuntimeException...
>
> So I guess we could have:
>
> java.lang.RuntimeException
> |
> +jsdsi.JsdsiRuntimeException
> |
> +jsdsi.Prover.ProverException
>
>
> or
>
> java.lang.RuntimeException
> |
> +jsdsi.JsdsiRuntimeException
>
> and
>
> java.lang.Exception
> |
> +jsdsi.JsdsiException
> |
> +jsdsi.Prover.ProverException
>
>
> What do you all think? Am I the only one who thinks that what we
> currently have needs improving?
>
> Sean
>
>
> --
> Dr. Sean Radford, MBBS, MSc
> sra...@ae...
> http://www.aegeus-technology.com
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Jsdsi-devel mailing list
> Jsd...@li...
> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel


http://ajmani.net

[Jsdsi-devel] JSDSI and Exceptions

[Sean R. <sra...@ae...>]

Guys,

Been thinking about exceptions and JSDSI. Basically I think it is a
little wrong that in lots of places Error is thrown wrapping the cause
of the exception.

I feel that we should have a base JSDSI exception class (that allows
nesting) and which may or may not have sub-classes. I think that in most
cases where exceptions occur in JSDSI, any calling application has no
real chance of recovery ans so it makes sense to extend from
RuntimeException. I'm not sure about NoProofFoundException, I could be
persuaded either way that it should or should not be a
RuntimeException...

So I guess we could have:

java.lang.RuntimeException
|
+jsdsi.JsdsiRuntimeException
|
+jsdsi.Prover.ProverException


or

java.lang.RuntimeException
|
+jsdsi.JsdsiRuntimeException

and

java.lang.Exception
|
+jsdsi.JsdsiException
|
+jsdsi.Prover.ProverException


What do you all think? Am I the only one who thinks that what we
currently have needs improving?

Sean


-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

Re: [Jsdsi-devel] transient fields

[Sean R. <sra...@ae...>]

On Thu, 2004-04-01 at 17:15, Sameer Ajmani wrote:
> Hmm... I forgot about the JCE serializables.
> 
> So I guess we're back to choosing between making all fields transient (for
> Serialzable) or adding empty constructors and making fields non-final (for
> Externalizable).  I guess transient is the better solution.  But I don't
> have to like it :)
> 
I know... the lesser of 2 evils. As I'm the one who initiated all this,
I'll do the necessary...


Sean


> Sameer
> 
> > On Thu, 2004-04-01 at 07:27, Sameer Ajmani wrote:
> >> I think changing the whole Obj hierarchy (either to use transient
> >> fields or to support Externalizable) is a bad idea.
> > In an ideal (and not so ideal) world I agree.
> >
> >>   I believe the cleanest and
> >> most maintainable solution is this:
> >>
> >> 1) Keep Sexp Serializable, and make its fields transient
> >> 2) Remove Serializable from Obj altogether
> >> 3) Serialize Objs by explicitly converting them to and from Sexps
> >> (using Obj.toSexp and obj.parseObj)
> >>
> > Not sure we can do that as:
> >
> > 1. jsdsi.Certificate extends java.security.cert.Certificate which
> > implements java.io.Serializable.
> >
> > 2. Similarly jsdsi.PublicKey implements java.security.PublicKey which
> > extends java.security.Key which in turn extends java.io.Serializable.
> >
> > 3. And jsdsi.RSAPublicKey implements
> > java.security.interfaces.RSAPublicKey which extends
> > java.security.PublicKey and java.security.interfaces.RSAKey, both of
> > which extend from java.io.Serializable.
> >
> > I also feel that forcing developers to explicitly pass Sexpressions for
> > remotable calls would be labour intensive and prone to errors as you
> > loose compile-time checking. For me in particular (as I use aspects for
> > many things) my business classes don't even know that they will be
> > remotable, so I would need to insert another class layer to manage this.
> > (I also see object persitence and caching (distributed) as 2 other areas
> > where this holds).
> >
> >>From points 1-3, I can't see how, if jsdsi is to conform to the JCE
> > architecture, we can get away from implementing serialization for many
> > of the classes. And if we need to do so for some, we should really do so
> > for all.
> >
> > Further thoughts?
> >
> >
> > Sean
> >
> >> An even better solution would be to make nothing Serializable and just
> >> use SexpInput and SexpOutput streams, but I realize some apps might
> >> want to use Object streams to carry both Objs and non-JSDSI objects
> >> (of course, one could wrap the Object stream in a Sexp stream to do
> >> this, too!).  I think using Sexps as the Serializable form is a
> >> reasonable compromise (and is more maintainable, since we don't expect
> >> to change the Sexp hierarchy).
> >>
> >> Sameer
> >>
> >> > We should also be thinking of Sexp in this discussion as that
> >> currently implements Serializable too...
> >> >
> >> >
> >> > Sean
> >> >
> >> > On Wed, 2004-03-31 at 20:58, Sean Radford wrote:
> >> >> Yes, could do that, and as Externalizable is meant to super-seed
> >> Serializable it would be nice / pererable to do so.
> >> >>
> >> >> However, we would then need default constructors on our jsdsi.Obj
> >> classes and all fields that are currently declared as 'final' (for
> >> good reasons) will no longer be allowed to be. To me, that seems
> >> the less peferable option.
> >> >>
> >> >> Thoughts?
> >> >>
> >> >> Sean
> >> >>
> >> >>
> >> >>
> >> >> On Wed, 2004-03-31 at 18:54, Sameer Ajmani wrote:
> >> >> > Seems ok, but tedious.  I'm a little surprised that the fields
> >> get
> >> >> serialized since you've overriden read/writeObject.  Should you
> >> override read/writeExternal instead?  Perhaps doing so would
> >> supress the automatic serialization.
> >> >> >
> >> >> > Sameer
> >> >> >
> >> >> >
> >> >> > > Guys,
> >> >> > >
> >> >> > > Been looking at the byte[] (bytestream) produced when one
> >> >> Serializes jsdsi.Obj's...
> >> >> > >
> >> >> > > As expected (with writeObject, readObject and readResolve
> >> >> implemented) it contains the Class hierarchy of the object and its
> >> canonical format Sexpression. However, in addition it contains
> >> class declarations for all the fields that the classes have (with
> >> no data as that is contained within the Sexpression).
> >> >> > >
> >> >> > > Therefore, I think that all classes that descend from jsdsi.Obj
> >> >> should have all their fields set to transient (I have tried it and
> >> it works fine). Any criticisms for doing this?
> >> >> > >
> >> >> > >
> >> >> > > Sean
> >> >> > >
> >> >> > >
> >> >> > > --
> >> >> > > Dr. Sean Radford, MBBS, MSc
> >> >> > > sra...@ae...
> >> >> > > http://www.aegeus-technology.com
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > > -------------------------------------------------------
> >> >> > > This SF.Net email is sponsored by: IBM Linux Tutorials
> >> >> > > Free Linux tutorial presented by Daniel Robbins, President and
> >> CEO
> >> >> of GenToo technologies. Learn everything from fundamentals to
> >> system
> >> >> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> >> _______________________________________________
> >> >> > > Jsdsi-devel mailing list
> >> >> > > Jsd...@li...
> >> >> > > https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
> >> >> >
> >> >> >
> >> >> > http://ajmani.net
> >> >> >
> >> > --
> >> > Dr. Sean Radford, MBBS, MSc
> >> > sra...@ae...
> >> > http://www.aegeus-technology.com
> >>
> >>
> >> http://ajmani.net
> >>
> > --
> > Dr. Sean Radford, MBBS, MSc
> > sra...@ae...
> > http://www.aegeus-technology.com
> 
> 
> http://ajmani.net
> 
-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

Re: [Jsdsi-devel] transient fields

[Sameer A. <aj...@cs...>]

Hmm... I forgot about the JCE serializables.

So I guess we're back to choosing between making all fields transient (for
Serialzable) or adding empty constructors and making fields non-final (for
Externalizable).  I guess transient is the better solution.  But I don't
have to like it :)

Sameer

> On Thu, 2004-04-01 at 07:27, Sameer Ajmani wrote:
>> I think changing the whole Obj hierarchy (either to use transient
>> fields or to support Externalizable) is a bad idea.
> In an ideal (and not so ideal) world I agree.
>
>>   I believe the cleanest and
>> most maintainable solution is this:
>>
>> 1) Keep Sexp Serializable, and make its fields transient
>> 2) Remove Serializable from Obj altogether
>> 3) Serialize Objs by explicitly converting them to and from Sexps
>> (using Obj.toSexp and obj.parseObj)
>>
> Not sure we can do that as:
>
> 1. jsdsi.Certificate extends java.security.cert.Certificate which
> implements java.io.Serializable.
>
> 2. Similarly jsdsi.PublicKey implements java.security.PublicKey which
> extends java.security.Key which in turn extends java.io.Serializable.
>
> 3. And jsdsi.RSAPublicKey implements
> java.security.interfaces.RSAPublicKey which extends
> java.security.PublicKey and java.security.interfaces.RSAKey, both of
> which extend from java.io.Serializable.
>
> I also feel that forcing developers to explicitly pass Sexpressions for
> remotable calls would be labour intensive and prone to errors as you
> loose compile-time checking. For me in particular (as I use aspects for
> many things) my business classes don't even know that they will be
> remotable, so I would need to insert another class layer to manage this.
> (I also see object persitence and caching (distributed) as 2 other areas
> where this holds).
>
>>From points 1-3, I can't see how, if jsdsi is to conform to the JCE
> architecture, we can get away from implementing serialization for many
> of the classes. And if we need to do so for some, we should really do so
> for all.
>
> Further thoughts?
>
>
> Sean
>
>> An even better solution would be to make nothing Serializable and just
>> use SexpInput and SexpOutput streams, but I realize some apps might
>> want to use Object streams to carry both Objs and non-JSDSI objects
>> (of course, one could wrap the Object stream in a Sexp stream to do
>> this, too!).  I think using Sexps as the Serializable form is a
>> reasonable compromise (and is more maintainable, since we don't expect
>> to change the Sexp hierarchy).
>>
>> Sameer
>>
>> > We should also be thinking of Sexp in this discussion as that
>> currently implements Serializable too...
>> >
>> >
>> > Sean
>> >
>> > On Wed, 2004-03-31 at 20:58, Sean Radford wrote:
>> >> Yes, could do that, and as Externalizable is meant to super-seed
>> Serializable it would be nice / pererable to do so.
>> >>
>> >> However, we would then need default constructors on our jsdsi.Obj
>> classes and all fields that are currently declared as 'final' (for
>> good reasons) will no longer be allowed to be. To me, that seems
>> the less peferable option.
>> >>
>> >> Thoughts?
>> >>
>> >> Sean
>> >>
>> >>
>> >>
>> >> On Wed, 2004-03-31 at 18:54, Sameer Ajmani wrote:
>> >> > Seems ok, but tedious.  I'm a little surprised that the fields
>> get
>> >> serialized since you've overriden read/writeObject.  Should you
>> override read/writeExternal instead?  Perhaps doing so would
>> supress the automatic serialization.
>> >> >
>> >> > Sameer
>> >> >
>> >> >
>> >> > > Guys,
>> >> > >
>> >> > > Been looking at the byte[] (bytestream) produced when one
>> >> Serializes jsdsi.Obj's...
>> >> > >
>> >> > > As expected (with writeObject, readObject and readResolve
>> >> implemented) it contains the Class hierarchy of the object and its
>> canonical format Sexpression. However, in addition it contains
>> class declarations for all the fields that the classes have (with
>> no data as that is contained within the Sexpression).
>> >> > >
>> >> > > Therefore, I think that all classes that descend from jsdsi.Obj
>> >> should have all their fields set to transient (I have tried it and
>> it works fine). Any criticisms for doing this?
>> >> > >
>> >> > >
>> >> > > Sean
>> >> > >
>> >> > >
>> >> > > --
>> >> > > Dr. Sean Radford, MBBS, MSc
>> >> > > sra...@ae...
>> >> > > http://www.aegeus-technology.com
>> >> > >
>> >> > >
>> >> > >
>> >> > > -------------------------------------------------------
>> >> > > This SF.Net email is sponsored by: IBM Linux Tutorials
>> >> > > Free Linux tutorial presented by Daniel Robbins, President and
>> CEO
>> >> of GenToo technologies. Learn everything from fundamentals to
>> system
>> >> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>> _______________________________________________
>> >> > > Jsdsi-devel mailing list
>> >> > > Jsd...@li...
>> >> > > https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
>> >> >
>> >> >
>> >> > http://ajmani.net
>> >> >
>> > --
>> > Dr. Sean Radford, MBBS, MSc
>> > sra...@ae...
>> > http://www.aegeus-technology.com
>>
>>
>> http://ajmani.net
>>
> --
> Dr. Sean Radford, MBBS, MSc
> sra...@ae...
> http://www.aegeus-technology.com


http://ajmani.net

Re: [Jsdsi-devel] transient fields

[Sean R. <sra...@ae...>]

On Thu, 2004-04-01 at 07:27, Sameer Ajmani wrote:
> I think changing the whole Obj hierarchy (either to use transient fields
> or to support Externalizable) is a bad idea.
In an ideal (and not so ideal) world I agree.

>   I believe the cleanest and
> most maintainable solution is this:
> 
> 1) Keep Sexp Serializable, and make its fields transient
> 2) Remove Serializable from Obj altogether
> 3) Serialize Objs by explicitly converting them to and from Sexps (using
> Obj.toSexp and obj.parseObj)
> 
Not sure we can do that as:

1. jsdsi.Certificate extends java.security.cert.Certificate which
implements java.io.Serializable.

2. Similarly jsdsi.PublicKey implements java.security.PublicKey which
extends java.security.Key which in turn extends java.io.Serializable.

3. And jsdsi.RSAPublicKey implements
java.security.interfaces.RSAPublicKey which extends
java.security.PublicKey and java.security.interfaces.RSAKey, both of
which extend from java.io.Serializable.

I also feel that forcing developers to explicitly pass Sexpressions for
remotable calls would be labour intensive and prone to errors as you
loose compile-time checking. For me in particular (as I use aspects for
many things) my business classes don't even know that they will be
remotable, so I would need to insert another class layer to manage this.
(I also see object persitence and caching (distributed) as 2 other areas
where this holds).

>From points 1-3, I can't see how, if jsdsi is to conform to the JCE
architecture, we can get away from implementing serialization for many
of the classes. And if we need to do so for some, we should really do so
for all.

Further thoughts?


Sean

> An even better solution would be to make nothing Serializable and just use
> SexpInput and SexpOutput streams, but I realize some apps might want to
> use Object streams to carry both Objs and non-JSDSI objects (of course,
> one could wrap the Object stream in a Sexp stream to do this, too!).  I
> think using Sexps as the Serializable form is a reasonable compromise (and
> is more maintainable, since we don't expect to change the Sexp hierarchy).
> 
> Sameer
> 
> > We should also be thinking of Sexp in this discussion as that currently
> > implements Serializable too...
> >
> >
> > Sean
> >
> > On Wed, 2004-03-31 at 20:58, Sean Radford wrote:
> >> Yes, could do that, and as Externalizable is meant to super-seed
> >> Serializable it would be nice / pererable to do so.
> >>
> >> However, we would then need default constructors on our jsdsi.Obj
> >> classes and all fields that are currently declared as 'final' (for
> >> good reasons) will no longer be allowed to be. To me, that seems the
> >> less peferable option.
> >>
> >> Thoughts?
> >>
> >> Sean
> >>
> >>
> >>
> >> On Wed, 2004-03-31 at 18:54, Sameer Ajmani wrote:
> >> > Seems ok, but tedious.  I'm a little surprised that the fields get
> >> serialized since you've overriden read/writeObject.  Should you
> >> override read/writeExternal instead?  Perhaps doing so would supress
> >> the automatic serialization.
> >> >
> >> > Sameer
> >> >
> >> >
> >> > > Guys,
> >> > >
> >> > > Been looking at the byte[] (bytestream) produced when one
> >> Serializes jsdsi.Obj's...
> >> > >
> >> > > As expected (with writeObject, readObject and readResolve
> >> implemented) it contains the Class hierarchy of the object and its
> >> canonical format Sexpression. However, in addition it contains
> >> class declarations for all the fields that the classes have (with
> >> no data as that is contained within the Sexpression).
> >> > >
> >> > > Therefore, I think that all classes that descend from jsdsi.Obj
> >> should have all their fields set to transient (I have tried it and
> >> it works fine). Any criticisms for doing this?
> >> > >
> >> > >
> >> > > Sean
> >> > >
> >> > >
> >> > > --
> >> > > Dr. Sean Radford, MBBS, MSc
> >> > > sra...@ae...
> >> > > http://www.aegeus-technology.com
> >> > >
> >> > >
> >> > >
> >> > > -------------------------------------------------------
> >> > > This SF.Net email is sponsored by: IBM Linux Tutorials
> >> > > Free Linux tutorial presented by Daniel Robbins, President and CEO
> >> of GenToo technologies. Learn everything from fundamentals to
> >> system
> >> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> >> _______________________________________________
> >> > > Jsdsi-devel mailing list
> >> > > Jsd...@li...
> >> > > https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
> >> >
> >> >
> >> > http://ajmani.net
> >> >
> > --
> > Dr. Sean Radford, MBBS, MSc
> > sra...@ae...
> > http://www.aegeus-technology.com
> 
> 
> http://ajmani.net
> 
-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

Re: [Jsdsi-devel] transient fields

[Sameer A. <aj...@cs...>]

I think changing the whole Obj hierarchy (either to use transient fields
or to support Externalizable) is a bad idea.  I believe the cleanest and
most maintainable solution is this:

1) Keep Sexp Serializable, and make its fields transient
2) Remove Serializable from Obj altogether
3) Serialize Objs by explicitly converting them to and from Sexps (using
Obj.toSexp and obj.parseObj)

An even better solution would be to make nothing Serializable and just use
SexpInput and SexpOutput streams, but I realize some apps might want to
use Object streams to carry both Objs and non-JSDSI objects (of course,
one could wrap the Object stream in a Sexp stream to do this, too!).  I
think using Sexps as the Serializable form is a reasonable compromise (and
is more maintainable, since we don't expect to change the Sexp hierarchy).

Sameer

> We should also be thinking of Sexp in this discussion as that currently
> implements Serializable too...
>
>
> Sean
>
> On Wed, 2004-03-31 at 20:58, Sean Radford wrote:
>> Yes, could do that, and as Externalizable is meant to super-seed
>> Serializable it would be nice / pererable to do so.
>>
>> However, we would then need default constructors on our jsdsi.Obj
>> classes and all fields that are currently declared as 'final' (for
>> good reasons) will no longer be allowed to be. To me, that seems the
>> less peferable option.
>>
>> Thoughts?
>>
>> Sean
>>
>>
>>
>> On Wed, 2004-03-31 at 18:54, Sameer Ajmani wrote:
>> > Seems ok, but tedious.  I'm a little surprised that the fields get
>> serialized since you've overriden read/writeObject.  Should you
>> override read/writeExternal instead?  Perhaps doing so would supress
>> the automatic serialization.
>> >
>> > Sameer
>> >
>> >
>> > > Guys,
>> > >
>> > > Been looking at the byte[] (bytestream) produced when one
>> Serializes jsdsi.Obj's...
>> > >
>> > > As expected (with writeObject, readObject and readResolve
>> implemented) it contains the Class hierarchy of the object and its
>> canonical format Sexpression. However, in addition it contains
>> class declarations for all the fields that the classes have (with
>> no data as that is contained within the Sexpression).
>> > >
>> > > Therefore, I think that all classes that descend from jsdsi.Obj
>> should have all their fields set to transient (I have tried it and
>> it works fine). Any criticisms for doing this?
>> > >
>> > >
>> > > Sean
>> > >
>> > >
>> > > --
>> > > Dr. Sean Radford, MBBS, MSc
>> > > sra...@ae...
>> > > http://www.aegeus-technology.com
>> > >
>> > >
>> > >
>> > > -------------------------------------------------------
>> > > This SF.Net email is sponsored by: IBM Linux Tutorials
>> > > Free Linux tutorial presented by Daniel Robbins, President and CEO
>> of GenToo technologies. Learn everything from fundamentals to
>> system
>> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>> _______________________________________________
>> > > Jsdsi-devel mailing list
>> > > Jsd...@li...
>> > > https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
>> >
>> >
>> > http://ajmani.net
>> >
> --
> Dr. Sean Radford, MBBS, MSc
> sra...@ae...
> http://www.aegeus-technology.com


http://ajmani.net

Re: [Jsdsi-devel] transient fields

[Sean R. <sra...@ae...>]

We should also be thinking of Sexp in this discussion as that currently
implements Serializable too...


Sean

On Wed, 2004-03-31 at 20:58, Sean Radford wrote:
> Yes, could do that, and as Externalizable is meant to super-seed
> Serializable it would be nice / pererable to do so.
> 
> However, we would then need default constructors on our jsdsi.Obj
> classes and all fields that are currently declared as 'final' (for good
> reasons) will no longer be allowed to be. To me, that seems the less
> peferable option.
> 
> Thoughts?
> 
> Sean
> 
> 
> 
> On Wed, 2004-03-31 at 18:54, Sameer Ajmani wrote:
> > Seems ok, but tedious.  I'm a little surprised that the fields get
> > serialized since you've overriden read/writeObject.  Should you override
> > read/writeExternal instead?  Perhaps doing so would supress the automatic
> > serialization.
> > 
> > Sameer
> > 
> > 
> > > Guys,
> > >
> > > Been looking at the byte[] (bytestream) produced when one Serializes
> > > jsdsi.Obj's...
> > >
> > > As expected (with writeObject, readObject and readResolve implemented)
> > > it contains the Class hierarchy of the object and its canonical format
> > > Sexpression. However, in addition it contains class declarations for all
> > > the fields that the classes have (with no data as that is contained
> > > within the Sexpression).
> > >
> > > Therefore, I think that all classes that descend from jsdsi.Obj should
> > > have all their fields set to transient (I have tried it and it works
> > > fine). Any criticisms for doing this?
> > >
> > >
> > > Sean
> > >
> > >
> > > --
> > > Dr. Sean Radford, MBBS, MSc
> > > sra...@ae...
> > > http://www.aegeus-technology.com
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by: IBM Linux Tutorials
> > > Free Linux tutorial presented by Daniel Robbins, President and CEO of
> > > GenToo technologies. Learn everything from fundamentals to system
> > > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> > > _______________________________________________
> > > Jsdsi-devel mailing list
> > > Jsd...@li...
> > > https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
> > 
> > 
> > http://ajmani.net
> > 
-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

Re: [Jsdsi-devel] transient fields

[Sean R. <sra...@ae...>]

Yes, could do that, and as Externalizable is meant to super-seed
Serializable it would be nice / pererable to do so.

However, we would then need default constructors on our jsdsi.Obj
classes and all fields that are currently declared as 'final' (for good
reasons) will no longer be allowed to be. To me, that seems the less
peferable option.

Thoughts?

Sean



On Wed, 2004-03-31 at 18:54, Sameer Ajmani wrote:
> Seems ok, but tedious.  I'm a little surprised that the fields get
> serialized since you've overriden read/writeObject.  Should you override
> read/writeExternal instead?  Perhaps doing so would supress the automatic
> serialization.
> 
> Sameer
> 
> 
> > Guys,
> >
> > Been looking at the byte[] (bytestream) produced when one Serializes
> > jsdsi.Obj's...
> >
> > As expected (with writeObject, readObject and readResolve implemented)
> > it contains the Class hierarchy of the object and its canonical format
> > Sexpression. However, in addition it contains class declarations for all
> > the fields that the classes have (with no data as that is contained
> > within the Sexpression).
> >
> > Therefore, I think that all classes that descend from jsdsi.Obj should
> > have all their fields set to transient (I have tried it and it works
> > fine). Any criticisms for doing this?
> >
> >
> > Sean
> >
> >
> > --
> > Dr. Sean Radford, MBBS, MSc
> > sra...@ae...
> > http://www.aegeus-technology.com
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IBM Linux Tutorials
> > Free Linux tutorial presented by Daniel Robbins, President and CEO of
> > GenToo technologies. Learn everything from fundamentals to system
> > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> > _______________________________________________
> > Jsdsi-devel mailing list
> > Jsd...@li...
> > https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
> 
> 
> http://ajmani.net
> 
-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

[Jsdsi-devel] transient fields

[Sean R. <sra...@ae...>]

Guys,

Been looking at the byte[] (bytestream) produced when one Serializes
jsdsi.Obj's...

As expected (with writeObject, readObject and readResolve implemented)
it contains the Class hierarchy of the object and its canonical format
Sexpression. However, in addition it contains class declarations for all
the fields that the classes have (with no data as that is contained
within the Sexpression).

Therefore, I think that all classes that descend from jsdsi.Obj should
have all their fields set to transient (I have tried it and it works
fine). Any criticisms for doing this?


Sean


-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

Re: [Jsdsi-devel] Proposal to replace cryptix jar

[Sean R. <sra...@ae...>]

At present the only cryptix class being used is the Base64InputStream in
SexpInputStream.

Sean

On Mon, 2004-03-29 at 23:08, Sameer Ajmani wrote:
> I'll have to track down what features of Cryptix JSDSI uses.  It would be
> even better to be able to omit a crypto JAR entirely (i.e., just use the
> Sun provider for everything).
> 
> Sameer
> 
> > All,
> >
> > How about replacing cryptix jar (which seems to have lost development)
> > with the jakarta commons-codec
> > (http://jakarta.apache.org/commons/codec/)?
> >
> > It seems to have lots of nice utility classes for Hex, Base64, Binary,
> > and lots more.
> >
> > Regards,
> >
> >
> > Sean
> >
> >
> > --
> > Dr. Sean Radford, MBBS, MSc
> > sra...@ae...
> > http://www.aegeus-technology.com
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IBM Linux Tutorials
> > Free Linux tutorial presented by Daniel Robbins, President and CEO of
> > GenToo technologies. Learn everything from fundamentals to system
> > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> > _______________________________________________
> > Jsdsi-devel mailing list
> > Jsd...@li...
> > https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
> 
> 
> http://ajmani.net
> 
-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

Re: [Jsdsi-devel] Proposal to replace cryptix jar

[Sameer A. <aj...@cs...>]

I'll have to track down what features of Cryptix JSDSI uses.  It would be
even better to be able to omit a crypto JAR entirely (i.e., just use the
Sun provider for everything).

Sameer

> All,
>
> How about replacing cryptix jar (which seems to have lost development)
> with the jakarta commons-codec
> (http://jakarta.apache.org/commons/codec/)?
>
> It seems to have lots of nice utility classes for Hex, Base64, Binary,
> and lots more.
>
> Regards,
>
>
> Sean
>
>
> --
> Dr. Sean Radford, MBBS, MSc
> sra...@ae...
> http://www.aegeus-technology.com
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Jsdsi-devel mailing list
> Jsd...@li...
> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel


http://ajmani.net

[Jsdsi-devel] Proposal to replace cryptix jar

[Sean R. <sra...@ae...>]

All,

How about replacing cryptix jar (which seems to have lost development)
with the jakarta commons-codec
(http://jakarta.apache.org/commons/codec/)?

It seems to have lots of nice utility classes for Hex, Base64, Binary,
and lots more.

Regards,


Sean


-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

[Jsdsi-devel] New website snapshot

[Sean R. <sra...@ae...>]

Guys,

Just done a new website (and jar) snapshot.

Can I just remind (inform, in case I haven't mentioned it yet) people to
update xdocs/changes.xml with new code / fixes as they put them into
CVS. This file/report is a good way of us all keeping track of what has
gone / is going into a version.

Regards,

Sean

-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

Re: [Jsdsi-devel] need javadoc audit

[Sean R. <sra...@ae...>]

On Fri, 2004-03-26 at 21:40, Sameer Ajmani wrote:
> In refatcoring Signature I noticed that soem of the javadoc is severely
> incorrect (e.g., it states that the byte[] parameter of the Signature
> constructor is the data to sign, when in fact it is the value of the
> signatrue itself!).  I'm a hunting around for other errors like this, but
> please keep your eyes out for them (and correct them if you know what they
> should be).  These are extremely dangerous and misleading mistakes.
> 
Agreed

> Sameer
> 
> > I can add create() and verify() for byte arrays and change the Obj ones
> > to delegate to those methods.  Would this be useful?
> >
> > Sameer
> >
> >> Just an off thought,
> >>
> >> Any reason why jsdsi.Signature is limited to working with jsdsi.Obj.
> >> Couldn't we allow it to be created with a byte[] which is the data to
> >> sign, and have corresponding verify methods?
> >>
> >> Sean
> >>
> >> --
> >> Dr. Sean Radford, MBBS, MSc
> >> sra...@ae...
> >> http://www.aegeus-technology.com
> >>
> >>
> >>
> >> -------------------------------------------------------
> >> This SF.Net email is sponsored by: IBM Linux Tutorials
> >> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> >> GenToo technologies. Learn everything from fundamentals to system
> >> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> >> _______________________________________________
> >> Jsdsi-devel mailing list
> >> Jsd...@li...
> >> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
> >
> >
> > http://ajmani.net
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IBM Linux Tutorials
> > Free Linux tutorial presented by Daniel Robbins, President and CEO of
> > GenToo technologies. Learn everything from fundamentals to system
> > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> > _______________________________________________
> > Jsdsi-devel mailing list
> > Jsd...@li...
> > https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
> 
> 
> http://ajmani.net
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Jsdsi-devel mailing list
> Jsd...@li...
> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

Re: [Jsdsi-devel] jsdsi.Signature

[Sean R. <sra...@ae...>]

On Fri, 2004-03-26 at 21:14, Sameer Ajmani wrote:
> I can add create() and verify() for byte arrays and change the Obj ones to
> delegate to those methods.  Would this be useful?
> 
To me it would...

And I notice that you have already done it
:-)


> Sameer
> 
> > Just an off thought,
> >
> > Any reason why jsdsi.Signature is limited to working with jsdsi.Obj.
> > Couldn't we allow it to be created with a byte[] which is the data to
> > sign, and have corresponding verify methods?
> >
> > Sean
> >
> > --
> > Dr. Sean Radford, MBBS, MSc
> > sra...@ae...
> > http://www.aegeus-technology.com
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IBM Linux Tutorials
> > Free Linux tutorial presented by Daniel Robbins, President and CEO of
> > GenToo technologies. Learn everything from fundamentals to system
> > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> > _______________________________________________
> > Jsdsi-devel mailing list
> > Jsd...@li...
> > https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
> 
> 
> http://ajmani.net
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Jsdsi-devel mailing list
> Jsd...@li...
> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

[Jsdsi-devel] RE: [Jsdsi-users] LDAP test

[Sean R. <sra...@ae...>]

Luis,


On Fri, 2004-03-26 at 22:03, Luis Pedro wrote:
> Sean,
>=20
> I didn't received any attach!
>=20
I made the usual silly mistake of not attaching the files! So here they
are: 'old.ldif' was the first one I tried, and 'new.ldif' is my current
one. I added them via 'ldapadd'. And, yes I used 'jsdsi.schema', adding
it to my 'slapd.conf'


> I'll take a look yet today. But i think that deleteAllCerts is not the
> problem(wild guess), i've never that problem but i've an ideia where ca=
n be.
>=20
Cool

> About the 'ldif', i' m hopping that u are using jsdsi.schema and not
> jsdsi.ldif. Please use OpenLdap versions from openldap.org are more sta=
ble i
> know it from experience(bad, by the way :))), u i'll maybe have problem=
s
> building the openldap but i'll give a help because it has some tricks.
>=20
I did try and build the latest from source (downloaded from
openldap.org) but had problems so resorted to the latest rpm I could
find. I'll try again later and let you know where I get stuck - I'm sure
I'll need a little help (not had a great deal of experience with
compiling linux stuff and often get stuck with some dependency or
another).



> The 'top' is the top of the structure, for example:
> 	sdsiCertificate is top because is a structure and there isn't no
> other structure that sdsiCertificate depends of.
Do you mean that 'top' means that the object has no parent? If that is th=
e
case then does that mean that my 'new.ldif' is invalid as I have=20
'dn: cn=3DManager,dc=3Daegeus,dc=3Dcom' declared as top?


> If the schema add two object classes, for example:
> 	sdsi and certificate. Sdsi should be the top structure and
> certifcate would depend of sdsi and then can't be top because has
> dependencies.
>=20
> In conclusion, any objectclass that depends from another can not be top=
 and
> any objectclass that hasn't dependencies is top.
>=20
> 	-- Luis Pedro=20
>=20
> =BB     -----Original Message-----
> =BB     From: Sean Radford [mailto:sra...@ae...]=20
> =BB     Sent: sexta-feira, 26 de Mar=E7o de 2004 20:17
> =BB     To: Luis Pedro
> =BB     Cc: devel jsdsi
> =BB     Subject: RE: [Jsdsi-users] LDAP test
> =BB    =20
> =BB     Luis,
> =BB    =20
> =BB     I get noo message. The test just hangs.
> =BB    =20
> =BB     I'm afraid I can't remember the exact details (bad of=20
> =BB     me), but from
> =BB     memory...
> =BB    =20
> =BB     In eclipse I 'paused' the Thread and it stopped in some=20
> =BB     monitor method
> =BB     in Ojbect I think. The stacktrace seemed to suggest it=20
> =BB     had come from
> =BB     Vector and I think from the deleteAllCertificates part of=20
> =BB     the code.
> =BB    =20
> =BB     Typically, I can't at present reproduce it!
> =BB    =20
> =BB     The only thing I have changed since I did get the problem=20
> =BB     is my 'test
> =BB     data structure'. My old and new ldiff are attached for=20
> =BB     you to see if you
> =BB     can spot anything that could cause it. I changed my test=20
> =BB     structure as my
> =BB     'jsdsi' ou was dissappearing after some deletes... Not=20
> =BB     that I changed
> =BB     much - just added 'top' - what does 'top' mean exactly?
> =BB    =20
> =BB     I'm using openldap-2.0.27-5.3mdk - so presumably a=20
> =BB     Mandrake build of
> =BB     2.0.27
> =BB    =20
> =BB     I'll try to investigate more tomorrow.
> =BB    =20
> =BB     Regards,
> =BB    =20
> =BB     Sean
> =BB    =20
> =BB    =20
> =BB     On Fri, 2004-03-26 at 11:37, Luis Pedro wrote:
> =BB     > Sean,
> =BB     >=20
> =BB     > The deadlock happens when u use LDAPTest?=20
> =BB     >=20
> =BB     > Ldap login and password can be " ", maybe i should=20
> =BB     change this for other
> =BB     > thing, also about login and password i think i i'll=20
> =BB     make changes i don't
> =BB     > like it in clear text and not protected.
> =BB     >=20
> =BB     > But i'm very much interested on the deadlock, because=20
> =BB     it didn't happen to me
> =BB     > and i suspected where that can happen! Which ldap=20
> =BB     server are u using?
> =BB     >=20
> =BB     >    -- Luis Pedro
> =BB     > =20
> =BB     >=20
> =BB     > =BB   -----Original Message-----
> =BB     > =BB   From: jsd...@li...=20
> =BB     > =BB   [mailto:jsd...@li...] On Beh=
alf=20
> =BB     > =BB   Of Sean Radford
> =BB     > =BB   Sent: sexta-feira, 26 de Mar=E7o de 2004 9:58
> =BB     > =BB   To: devel jsdsi
> =BB     > =BB   Cc: users jsdsi
> =BB     > =BB   Subject: [Jsdsi-users] LDAP test
> =BB     > =BB  =20
> =BB     > =BB   Hi,
> =BB     > =BB  =20
> =BB     > =BB   I've committed my changes to the LDAP test class. It no=
w=20
> =BB     > =BB   reads its configurable options from JVM properties:
> =BB     > =BB  =20
> =BB     > =BB   1. When running the test via Maven, you specifiy the=20
> =BB     > =BB   properties via your personal project 'build.properties'=
=20
> =BB     > =BB   file (create this in the project root and don't commit =
it=20
> =BB     > =BB   to CVS - there is an entry for it in cvsignore). Look a=
t=20
> =BB     > =BB   project.properties for what the property names are.
> =BB     > =BB  =20
> =BB     > =BB   2. When running from Eclipse set the JVM properties fro=
m=20
> =BB     > =BB   the Run Configuration's, Arguments, VM Arguments text a=
rea.
> =BB     > =BB  =20
> =BB     > =BB   The LDAP test (which doesn't actually test anything in =
the=20
> =BB     > =BB   true sense of
> =BB     > =BB   JUnit) works, but there seems to be a thread deadlock=20
> =BB     > =BB   ocurring sometimes. I don't know enough about using JLD=
AP=20
> =BB     > =BB   (yet) to say if it is a problem with the test, JLDAP, o=
r=20
> =BB     > =BB   maybe even openldap server setup...
> =BB     > =BB  =20
> =BB     > =BB   Regards,
> =BB     > =BB  =20
> =BB     > =BB   Sean
> =BB     > =BB  =20
> =BB     > =BB   --
> =BB     > =BB   Dr. Sean Radford, MBBS, MSc
> =BB     > =BB   sra...@ae...
> =BB     > =BB   http://www.aegeus-technology.com
> =BB     > =BB  =20
> =BB     > =BB  =20
> =BB     > =BB  =20
> =BB     > =BB   -------------------------------------------------------
> =BB     > =BB   This SF.Net email is sponsored by: IBM Linux Tutorials
> =BB     > =BB   Free Linux tutorial presented by Daniel Robbins, Presid=
ent=20
> =BB     > =BB   and CEO of
> =BB     > =BB   GenToo technologies. Learn everything from=20
> =BB     fundamentals to system
> =BB     > =BB   administration.http://ads.osdn.com/?ad_id=3D1470&alloc_=
id=3D3638
> =BB     > =BB   &op=3Dclick
> =BB     > =BB   _______________________________________________
> =BB     > =BB   Jsdsi-users mailing list
> =BB     > =BB   Jsd...@li...
> =BB     > =BB   https://lists.sourceforge.net/lists/listinfo/jsdsi-user=
s
> =BB     > =BB  =20
> =BB     --=20
> =BB     Dr. Sean Radford, MBBS, MSc
> =BB     sra...@ae...
> =BB     http://www.aegeus-technology.com
> =BB    =20
--=20
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

Re: [Jsdsi-devel] disable ldap test?

[Sean R. <sra...@ae...>]

On Fri, 2004-03-26 at 22:34, Sameer Ajmani wrote:
> Can we add a Maven property that disables the LDAP test?  I can't build
> the JAR because I don't have an LDAP server, and I don't feel like setting
> one up right now :)

There is one.

Look in project.properties and it explains things.

Basically, create a build.properties file in the root of jsdsi (if you
haven't already) and create an entry test.ldap.skiptests and set it to
true. My build.properties has the following entries:


#test.ldap.skiptests=true
#test.ldap.servername=localhost
test.ldap.baseDN=ou=jsdsi,ou=test,dc=aegeus,dc=com
test.ldap.login=cn=Manager,dc=aegeus,dc=com
test.ldap.password=secret
test.ldap.selector=CompatibleCertSelector
#test.ldap.selector=AuthCertSelector
#test.ldap.selector=SubjectCertSelector
#test.ldap.selector=NameCertSelector


Hope this helps,

Sean


> Sameer
> 
> http://ajmani.net
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Jsdsi-devel mailing list
> Jsd...@li...
> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

[Jsdsi-devel] disable ldap test?

[Sameer A. <aj...@cs...>]

Can we add a Maven property that disables the LDAP test?  I can't build
the JAR because I don't have an LDAP server, and I don't feel like setting
one up right now :)

Sameer

http://ajmani.net

[Jsdsi-devel] need javadoc audit

[Sameer A. <aj...@cs...>]

In refatcoring Signature I noticed that soem of the javadoc is severely
incorrect (e.g., it states that the byte[] parameter of the Signature
constructor is the data to sign, when in fact it is the value of the
signatrue itself!).  I'm a hunting around for other errors like this, but
please keep your eyes out for them (and correct them if you know what they
should be).  These are extremely dangerous and misleading mistakes.

Sameer

> I can add create() and verify() for byte arrays and change the Obj ones
> to delegate to those methods.  Would this be useful?
>
> Sameer
>
>> Just an off thought,
>>
>> Any reason why jsdsi.Signature is limited to working with jsdsi.Obj.
>> Couldn't we allow it to be created with a byte[] which is the data to
>> sign, and have corresponding verify methods?
>>
>> Sean
>>
>> --
>> Dr. Sean Radford, MBBS, MSc
>> sra...@ae...
>> http://www.aegeus-technology.com
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: IBM Linux Tutorials
>> Free Linux tutorial presented by Daniel Robbins, President and CEO of
>> GenToo technologies. Learn everything from fundamentals to system
>> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>> _______________________________________________
>> Jsdsi-devel mailing list
>> Jsd...@li...
>> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
>
>
> http://ajmani.net
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Jsdsi-devel mailing list
> Jsd...@li...
> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel


http://ajmani.net

Re: [Jsdsi-devel] jsdsi.Signature

[Sameer A. <aj...@cs...>]

I can add create() and verify() for byte arrays and change the Obj ones to
delegate to those methods.  Would this be useful?

Sameer

> Just an off thought,
>
> Any reason why jsdsi.Signature is limited to working with jsdsi.Obj.
> Couldn't we allow it to be created with a byte[] which is the data to
> sign, and have corresponding verify methods?
>
> Sean
>
> --
> Dr. Sean Radford, MBBS, MSc
> sra...@ae...
> http://www.aegeus-technology.com
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Jsdsi-devel mailing list
> Jsd...@li...
> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel


http://ajmani.net

[Jsdsi-devel] jsdsi.Signature

[Sean R. <sra...@ae...>]

Just an off thought,

Any reason why jsdsi.Signature is limited to working with jsdsi.Obj.
Couldn't we allow it to be created with a byte[] which is the data to
sign, and have corresponding verify methods?

Sean

-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

[Jsdsi-devel] RE: [Jsdsi-users] LDAP test

[Sean R. <sra...@ae...>]

Luis,

I get noo message. The test just hangs.

I'm afraid I can't remember the exact details (bad of me), but from
memory...

In eclipse I 'paused' the Thread and it stopped in some monitor method
in Ojbect I think. The stacktrace seemed to suggest it had come from
Vector and I think from the deleteAllCertificates part of the code.

Typically, I can't at present reproduce it!

The only thing I have changed since I did get the problem is my 'test
data structure'. My old and new ldiff are attached for you to see if you
can spot anything that could cause it. I changed my test structure as my
'jsdsi' ou was dissappearing after some deletes... Not that I changed
much - just added 'top' - what does 'top' mean exactly?

I'm using openldap-2.0.27-5.3mdk - so presumably a Mandrake build of
2.0.27

I'll try to investigate more tomorrow.

Regards,

Sean


On Fri, 2004-03-26 at 11:37, Luis Pedro wrote:
> Sean,
>=20
> The deadlock happens when u use LDAPTest?=20
>=20
> Ldap login and password can be " ", maybe i should change this for othe=
r
> thing, also about login and password i think i i'll make changes i don'=
t
> like it in clear text and not protected.
>=20
> But i'm very much interested on the deadlock, because it didn't happen =
to me
> and i suspected where that can happen! Which ldap server are u using?
>=20
>    -- Luis Pedro
> =20
>=20
> =BB   -----Original Message-----
> =BB   From: jsd...@li...=20
> =BB   [mailto:jsd...@li...] On Behalf=20
> =BB   Of Sean Radford
> =BB   Sent: sexta-feira, 26 de Mar=E7o de 2004 9:58
> =BB   To: devel jsdsi
> =BB   Cc: users jsdsi
> =BB   Subject: [Jsdsi-users] LDAP test
> =BB  =20
> =BB   Hi,
> =BB  =20
> =BB   I've committed my changes to the LDAP test class. It now=20
> =BB   reads its configurable options from JVM properties:
> =BB  =20
> =BB   1. When running the test via Maven, you specifiy the=20
> =BB   properties via your personal project 'build.properties'=20
> =BB   file (create this in the project root and don't commit it=20
> =BB   to CVS - there is an entry for it in cvsignore). Look at=20
> =BB   project.properties for what the property names are.
> =BB  =20
> =BB   2. When running from Eclipse set the JVM properties from=20
> =BB   the Run Configuration's, Arguments, VM Arguments text area.
> =BB  =20
> =BB   The LDAP test (which doesn't actually test anything in the=20
> =BB   true sense of
> =BB   JUnit) works, but there seems to be a thread deadlock=20
> =BB   ocurring sometimes. I don't know enough about using JLDAP=20
> =BB   (yet) to say if it is a problem with the test, JLDAP, or=20
> =BB   maybe even openldap server setup...
> =BB  =20
> =BB   Regards,
> =BB  =20
> =BB   Sean
> =BB  =20
> =BB   --
> =BB   Dr. Sean Radford, MBBS, MSc
> =BB   sra...@ae...
> =BB   http://www.aegeus-technology.com
> =BB  =20
> =BB  =20
> =BB  =20
> =BB   -------------------------------------------------------
> =BB   This SF.Net email is sponsored by: IBM Linux Tutorials
> =BB   Free Linux tutorial presented by Daniel Robbins, President=20
> =BB   and CEO of
> =BB   GenToo technologies. Learn everything from fundamentals to system
> =BB   administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638
> =BB   &op=3Dclick
> =BB   _______________________________________________
> =BB   Jsdsi-users mailing list
> =BB   Jsd...@li...
> =BB   https://lists.sourceforge.net/lists/listinfo/jsdsi-users
> =BB  =20
--=20
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com