Login | Register
My pages Projects Community openCollabNet

Discussions > dev > Inserting $Id$ into files

Project highlights: Architectural Overview

joist
Discussion topic

Hide all messages in topic

All messages in topic

Re: Inserting $Id$ into files

Author edk
Full name Ed Korthof
Date 2000-10-05 01:21:41 PDT
Message On Wed, 4 Oct 2000, Daniel L. Rall wrote:

> Josh Lucas wrote:
> > The reality is that classes in those jars are going to get overlayed as
> > that is our current instantiation scheme.
>
> This needs to be changed into a class loading scenario as soon as
> possible. The current schem makes sense for templates, but certainly
> not for Java classes.

joist's current scheme allows templates to to be overriden through a
property. the way this is implemented currently would make it difficult
to override the template through configuration alone -- but that would be
*easy* to change. (just put the template in init args, and make sure we
have a way to override that value in the servlets file.)

changing classes to allow swapping them in or out is a little more work,
but it would be manageable -- imo it'd be comparable to the work which has
gone into the current system. (then again, perhaps i'm biased.)

cheers --

ed, throughly convinced that subject prefixes make crossposting to
multiple mailing lists worse than it already was.
--
   +=-=+=-=+=-=+=-=+=-=​+=-=+=-=+=-=+=-=+=-=​+=-=+=-=+=-=+=-=
   | Ed Korthof | edk at collab dot net | 415-247-1690 |
   +=-=+=-=+=-=+=-=+=-=​+=-=+=-=+=-=+=-=+=-=​+=-=+=-=+=-=+=-=

Re: [helm-dev] Re: [joist-dev] Inserting $Id$ into files

Author dlr
Full name Daniel Rall
Date 2000-10-04 21:57:32 PDT
Message Josh Lucas wrote:
>
> On Wed, 4 Oct 2000, Manoj Kasichainula wrote:
>
> > On Wed, Oct 04, 2000 at 02:42:02PM -0700, Jon Stevens wrote:
> > > Maybe a better idea for solving the problem you describe above would be to
> > > add a class to the .jar file with a Main in it that allows you to execute
> > > the .jar file and return the version information.
> > >
> > > java -jar anzu.jar Version
> >
> > I think I'm with Jon on this one. The only reason we'd need to
> > identify individual classes is if jars can go internally out of sync
> > or classes in those jars can get overlayed. Both of those scenarios
> > should be avoided, not specially coded for.
>
> The reality is that classes in those jars are going to get overlayed as
> that is our current instantiation scheme.

This needs to be changed into a class loading scenario as soon as
possible. The current schem makes sense for templates, but certainly
not for Java classes.
--

Daniel Rall <dlr at finemaltcoding dot com>

Re: [joist-dev] Inserting $Id$ into files

Author dlr
Full name Daniel Rall
Date 2000-10-04 21:39:08 PDT
Message Jon Stevens wrote:
>
> on 10/4/2000 3:18 PM, "Josh Lucas" <lucas at collab dot net> wrote:
>
> > It isn't an issue of which version of a jar we are using but which version
> > of a particular class.
> >
> > josh
>
> why would that be a question?
>
> if you know your classpath...which you do...then you know which .jars are in
> it and thus exactly which classes are in it.

Currently, we do not know which version of a class is actually in the
JAR.

> also, the version information can be stored in the META-INF directory within
> the .jar file. we should take advantage of that as well.

This looks like the idiomatic place to store the JAR/CVS tag info. This
would remove RT penalty, correct?
--

Daniel Rall <dlr at finemaltcoding dot com>

Re: [joist-dev] Inserting $Id$ into files

Author dlr
Full name Daniel Rall
Date 2000-10-04 21:37:40 PDT
Message Josh Lucas wrote:
>
> It isn't an issue of which version of a jar we are using but which version
> of a particular class.

Deployed JARs should correspond to version control tags. Once this is
in place, it will be an issue of which version of a JAR you have.
--

Daniel Rall <dlr at finemaltcoding dot com>

Re: [helm-dev] Re: [joist-dev] Re: [helm-dev] Re: [joist-dev] Inserting $Id$ into files

Author Manoj Kasichainula <manoj at collab dot net>
Full name Manoj Kasichainula <manoj at collab dot net>
Date 2000-10-04 16:57:25 PDT
Message On Wed, Oct 04, 2000 at 04:24:20PM -0700, Ed Korthof wrote:
> On Wed, 4 Oct 2000, Jon Stevens wrote:
>
> > I don't get *why* this is error prone and difficult though...
> >
> > #1. You know what class is the problem (you said "given class" above).
> >
> > #2. You know it must exist in one of two .jar's for which you know which one
> > it is.
> >
> > #3. You look at which .jar comes first in the classpath.
> >
> > Problem solved in 3 easy steps.
>
> #1 : This requires a shell login on the live machine. This is something
> to be avoided (in the long term, right now it's still needed)

Anything you do to fix the problem has to be done on a seperate
staging server anyway. So set up the staging environment in the first
place to look like the production envionment. Just like shell logins
for developers on production sites should be avoided, so should class
reordering and debugging.

Besides I really don't see where the massive confusion is. For any
given application, you have one jar with the base classes, and
potentially one other jar with overlay classes. The second jar always
comes first in the classpath. Where's the potential for massive
confusion?

> #2 : I've no reason to believe that instanciations and applications will
> always have only one jar file.

Huh? Jon never claimed that everything was in a single jar file,
AFAICT

> #3 : Hitting a servlet w/ authentication to get this information is faster
> and simpler, and still less error-prone.

Adding extra things to code always makes it more error-prone, and code
to query things is code that can fail. All code is error-prone code,
and reducing the amount of code reduces the potential for errors. If
the manual task is error-prone, then maybe I see your point, but it
sure doesn't seem so to me.

> We're really not talking about that much additional time to do what lucas
> is talking about; at this point, we've probably spent more time arguing
> than it'd have taken.

We've also spent more time arguing then it would have taken to just
leave things the way they are. :)

Re: Inserting $Id$ into files

Author edk
Full name Ed Korthof
Date 2000-10-04 16:34:56 PDT
Message oh, i've one thing to add. if it wasn't clear : i don't like the
overriding classes concept, and ultimately that's the strongest argument
for this. without that argument, this would be a toss up for me (not
necessarily good or bad).

if doing this makes the class overriding concept live longer, then i'd
just as soon drop the idea. i'm willing to live with a little pain now if
it'll make things better in the long run -- and putting class overrides in
configuration (rather than the classpath) would definitely be an
improvement.

anyway, i'm going to shut up now & get back to other stuff.

cheers --

ed
--
   +=-=+=-=+=-=+=-=+=-=​+=-=+=-=+=-=+=-=+=-=​+=-=+=-=+=-=+=-=
   | Ed Korthof | edk at collab dot net | 415-247-1690 |
   +=-=+=-=+=-=+=-=+=-=​+=-=+=-=+=-=+=-=+=-=​+=-=+=-=+=-=+=-=

Re: Inserting $Id$ into files

Author Jon Stevens <jon at latchkey dot com>
Full name Jon Stevens <jon at latchkey dot com>
Date 2000-10-04 16:33:12 PDT
Message on 10/4/2000 4:24 PM, "Ed Korthof" <edk at collab dot net> wrote:

> #1 : This requires a shell login on the live machine. This is something
> to be avoided (in the long term, right now it's still needed)

You will need one to fix the problem anyway.

> #2 : I've no reason to believe that instanciations and applications will
> always have only one jar file.

Huh? What does that have to do with this problem?

> #3 : Hitting a servlet w/ authentication to get this information is faster
> and simpler, and still less error-prone.

That doesn't resolve the fact that this is a hack on top of a hack.

> Umm ... the code is simple, and it's not a complext task; and afterwards
> my life will be just slightly easier. I'm willing to make investments in
> advance to make my life easier later.

Why not solve the larger issue instead of making a hack to make your life
eaiser?

> In the scenario which I presented, the problem wasn't that the wrong
> version was getting loaded, but that the version getting loaded had a bug.
> What is important is to figure out where that version lives, fix the code
> base containing it, and upgrade.

Just look at the classpath. BTW, let me point out you will need shell access
to do the upgrade.

> I agree with you on this wholeheartedly -- configuration is the right
> place for this kind of customization, not code.

so, then lets fix it! :-)

> OTOH -- there are some
> complexities involved, as we'd also need to add interfaces for the
> classes & so on. But I've argued for this (I just gave up 'cause it's not
> my area, and I've enough to worry about already).

This stuff isn't black magic. :-)

> We're really not talking about that much additional time to do what lucas
> is talking about; at this point, we've probably spent more time arguing
> than it'd have taken.

Only because the solution causes us to produce more frankensoftware.

> OTOH -- using interfaces & Class.forName() [or the Java 1.1 equivalent,
> which is ugly as sin] would take some time. I don't have time to do that
> right now ...

Think of all the time saved trying to debug the problem caused by doing it
incorrectly in the first place. :-) This is a problem that is only going to
make itself worse and worse...you might as well nip it in the bud now.

FYI, you keep mentioning this 1.1 equivalent and that isn't true. Turbine
has used Class.forName() in this exact manner since day one and doesn't
require special treatment.

-jon

Re: [helm-dev] Re: [joist-dev] Re: [helm-dev] Re: [joist-dev] Inserting $Id$ into files

Author edk
Full name Ed Korthof
Date 2000-10-04 16:24:20 PDT
Message On Wed, 4 Oct 2000, Jon Stevens wrote:

> on 10/4/2000 3:52 PM, "Ed Korthof" <edk at collab dot net> wrote:
>
> > where it's from. If I've got to look through the classpath, then I have
> > to reconstruct that and look through a bunch of .jar files -- painful &
> > somewhat more error prone. It also requires me to use a shell account to
> > poke around the live system.
>
> I don't get *why* this is error prone and difficult though...
>
> #1. You know what class is the problem (you said "given class" above).
>
> #2. You know it must exist in one of two .jar's for which you know which one
> it is.
>
> #3. You look at which .jar comes first in the classpath.
>
> Problem solved in 3 easy steps.

#1 : This requires a shell login on the live machine. This is something
to be avoided (in the long term, right now it's still needed)

#2 : I've no reason to believe that instanciations and applications will
always have only one jar file.

#3 : Hitting a servlet w/ authentication to get this information is faster
and simpler, and still less error-prone.

> > OTOH -- if I can use the JVM to figure out where a given class is from,
> > then my debugging of this hypothetical problem is much easier.
>
> Ok, so you are going to spend time writing code to give you the solution.
> Sorry, but that sounds a lot more painful than simply looking at the
> classpath.

Umm ... the code is simple, and it's not a complext task; and afterwards
my life will be just slightly easier. I'm willing to make investments in
advance to make my life easier later.

> Now, that also only tells you which class is being used...not even
> necessarily *why* and either way, you are going to have to come back and fix
> the classpath issue so you are back at square one.

In the scenario which I presented, the problem wasn't that the wrong
version was getting loaded, but that the version getting loaded had a bug.
What is important is to figure out where that version lives, fix the code
base containing it, and upgrade.

> > I'm with Manoj in believing that this scenario is one we should avoid in
> > the first place, by not overriding classes. However, that is *not* the
> > current plan: the current *design* for how to do instanciations includes
> > overriding some but *not* all files in joist/helm/etc. Because of that, I
> > think this offers a compelling advantage.
> >
> > Unless you want to try to convince people to avoid overriding classes,
> > ever. I'd be with you, but I've no time left to fight that fight. <sad
> > smile>
>
> Right...that is also a really bad aspect of this whole thing...Why aren't
> these classes defined in property files instead so that they can be easily
> swapped out?

I agree with you on this wholeheartedly -- configuration is the right
place for this kind of customization, not code. OTOH -- there are some
complexities involved, as we'd also need to add interfaces for the
classes & so on. But I've argued for this (I just gave up 'cause it's not
my area, and I've enough to worry about already).

> If you are going to spend all the time added $Id: $ to the files and writing
> code to figure out which class is loaded, you might as well spend the time
> going through the code base and use
> Class.forName(props.​getString("class.i.r​eally.want.to.instan​tiate")).newInst
> ance() as a real solution instead. In fact, you can probably do regex
> replacements in the code to get the above effect.

We're really not talking about that much additional time to do what lucas
is talking about; at this point, we've probably spent more time arguing
than it'd have taken.

OTOH -- using interfaces & Class.forName() [or the Java 1.1 equivalent,
which is ugly as sin] would take some time. I don't have time to do that
right now ...

thanks --

Ed
--
   +=-=+=-=+=-=+=-=+=-=​+=-=+=-=+=-=+=-=+=-=​+=-=+=-=+=-=+=-=
   | Ed Korthof | edk at collab dot net | 415-247-1690 |
   +=-=+=-=+=-=+=-=+=-=​+=-=+=-=+=-=+=-=+=-=​+=-=+=-=+=-=+=-=

Re: [helm-dev] Re: [joist-dev] Inserting $Id$ into files

Author dlr
Full name Daniel Rall
Date 2000-10-04 16:11:57 PDT
Message Manoj Kasichainula wrote:
>
> On Wed, Oct 04, 2000 at 02:42:02PM -0700, Jon Stevens wrote:
> > Maybe a better idea for solving the problem you describe above would be to
> > add a class to the .jar file with a Main in it that allows you to execute
> > the .jar file and return the version information.
> >
> > java -jar anzu.jar Version
>
> I think I'm with Jon on this one. The only reason we'd need to
> identify individual classes is if jars can go internally out of sync
> or classes in those jars can get overlayed. Both of those scenarios
> should be avoided, not specially coded for.

+1, nicely said Manoj. Class file versioning was a good hack, but not
the Right Way for us in the long term.
--

Daniel Rall <dlr at finemaltcoding dot com>

Re: [joist-dev] Inserting $Id$ into files

Author dlr
Full name Daniel Rall
Date 2000-10-04 16:10:25 PDT
Message Jon Stevens wrote:
>
> on 10/4/2000 2:23 PM, "Ed Korthof" <edk at collab dot net> wrote:
> [snip]
> You didn't address my query about how you are going to query each object in
> memory for its version information. You are going down to the granularity of
> the individual object level when you really only need the .jar level.

This is what I mean by larger release management issues. Currently, we
*do* in fact need class-level versioning granularity because we are not
versioning JAR files (i.e. sure, we build JAR files, but we have no way
of knowing what the hell is *in* the JAR files). I know that Josh is
buliding solutions for this problem, and can't wait to see them replace
this versioning hack.

> Maybe a better idea for solving the problem you describe above would be to
> add a class to the .jar file with a Main in it that allows you to execute
> the .jar file and return the version information.
>
> java -jar anzu.jar Version

This would provide some nice RT build info. We still have to version
the JAR files in the first place, though.
--

Daniel Rall <dlr at finemaltcoding dot com>

Re: [joist-dev] Inserting $Id$ into files

Author dlr
Full name Daniel Rall
Date 2000-10-04 16:05:45 PDT
Message Ed Korthof wrote:
>
> On Wed, 4 Oct 2000, Jon Stevens wrote:
>
> > Wouldn't it be better to use something like this:
> >
> > /**
> >
> > @version $Id: $
> > */
> > public class Foo
> > {
> > }
> >
> > That is what we do in all of our Java code on java.apache.org/jakarta
> > projects. Putting a static String into each and every single file seems like
> > object/memory overkill to me given that you will never query each and every
> > single file for its version information and you can simply build the javadoc
> > and look at it that way instead.
>
> Let's keep it in perspective. The $Id$ strings are generally less than 80
> bytes; and Java's overhead per String object is probably less than 50
> bytes. (I did do some simple tests to verify this.) But lets be generous
> and say that each String requires 200 bytes. (A fair overestimate.)
>
> If we had 10,000 such classes, it'd still take only 2MB (far more than
> we'll use anytime soon -- and if/when we do, I doubt 2MB will be
> significant). That's quite worthwhile, if it provides even a minor
> advantage -- which it does.
>
> We can find javadocs on disk, and even the release ID in the jar file
> (which I intend to include in the jar file name for anzu, at least). But
> that doesn't ensure that you're loading the same version that you think
> you are. Putting the IDs in the file gives that as an advantage -- you
> can find the actual version loaded, not the one you think should be.

To me, this sounds like a work around for larger release management
issues. I'm fine with it for the short term, but would like to see it
replaced by better processes in the long term.
--

Daniel Rall <dlr at finemaltcoding dot com>

Re: [joist-dev] Re: [helm-dev] Re: [joist-dev] Inserting $Id$ into files

Author Jon Stevens <jon at latchkey dot com>
Full name Jon Stevens <jon at latchkey dot com>
Date 2000-10-04 16:04:32 PDT
Message on 10/4/2000 3:52 PM, "Ed Korthof" <edk at collab dot net> wrote:

> Here's the basic issue: otnxchange overrides some classes in joist. It
> doesn't override all of them, just some. Now -- say a given class is
> misbehaving; the first thing I should do in this case is to figure out
> where it's from. If I've got to look through the classpath, then I have
> to reconstruct that and look through a bunch of .jar files -- painful &
> somewhat more error prone. It also requires me to use a shell account to
> poke around the live system.

I don't get *why* this is error prone and difficult though...

#1. You know what class is the problem (you said "given class" above).

#2. You know it must exist in one of two .jar's for which you know which one
it is.

#3. You look at which .jar comes first in the classpath.

Problem solved in 3 easy steps.

> OTOH -- if I can use the JVM to figure out where a given class is from,
> then my debugging of this hypothetical problem is much easier.

Ok, so you are going to spend time writing code to give you the solution.
Sorry, but that sounds a lot more painful than simply looking at the
classpath.

Now, that also only tells you which class is being used...not even
necessarily *why* and either way, you are going to have to come back and fix
the classpath issue so you are back at square one.

> I'm with Manoj in believing that this scenario is one we should avoid in
> the first place, by not overriding classes. However, that is *not* the
> current plan: the current *design* for how to do instanciations includes
> overriding some but *not* all files in joist/helm/etc. Because of that, I
> think this offers a compelling advantage.
>
> Unless you want to try to convince people to avoid overriding classes,
> ever. I'd be with you, but I've no time left to fight that fight. <sad
> smile>

Right...that is also a really bad aspect of this whole thing...Why aren't
these classes defined in property files instead so that they can be easily
swapped out?

If you are going to spend all the time added $Id: $ to the files and writing
code to figure out which class is loaded, you might as well spend the time
going through the code base and use
Class.forName(props.​getString("class.i.r​eally.want.to.instan​tiate")).newInst
ance() as a real solution instead. In fact, you can probably do regex
replacements in the code to get the above effect.

s/new
Foo()/Class.forName(​props.getString("cla​ss.i.really.want.to.​instantiate")).n
ewInstance()/

$0.00

-jon

Re: [helm-dev] Re: [joist-dev] Inserting $Id$ into files

Author Manoj Kasichainula <manoj at collab dot net>
Full name Manoj Kasichainula <manoj at collab dot net>
Date 2000-10-04 15:55:47 PDT
Message On Wed, Oct 04, 2000 at 03:31:58PM -0700, Josh Lucas wrote:
> On Wed, 4 Oct 2000, Manoj Kasichainula wrote:
> > I think I'm with Jon on this one. The only reason we'd need to
> > identify individual classes is if jars can go internally out of sync
> > or classes in those jars can get overlayed. Both of those scenarios
> > should be avoided, not specially coded for.
>
> The reality is that classes in those jars are going to get overlayed as
> that is our current instantiation scheme.

Well, then the question is how much CollabNet's instantation scheme
going to affect the Tigris open source code.

The true solution would be to fix the instantiation scheme, or, if it
*has* to be maintained, then do as Jon suggests, just look at the
classpath and figure out what class you're looking at. I have no
reason to believe it would be that hard.

Re: [joist-dev] Re: [helm-dev] Re: [joist-dev] Inserting $Id$ into files

Author edk
Full name Ed Korthof
Date 2000-10-04 15:52:50 PDT
Message On Wed, 4 Oct 2000, Jon Stevens wrote:

> on 10/4/2000 3:31 PM, "Josh Lucas" <lucas at collab dot net> wrote:
>
> > The reality is that classes in those jars are going to get overlayed as
> > that is our current instantiation scheme.
>
> Again, what do you mean by this?
>
> Are you saying that you are going to have classes in foo.jar and bar.jar
> that are identical (other than by version number) and you are going to use
> the classpath to determine which ones should be used?
>
> Again, that is something that is easily solved by looking at the classpath.

Here's the basic issue: otnxchange overrides some classes in joist. It
doesn't override all of them, just some. Now -- say a given class is
misbehaving; the first thing I should do in this case is to figure out
where it's from. If I've got to look through the classpath, then I have
to reconstruct that and look through a bunch of .jar files -- painful &
somewhat more error prone. It also requires me to use a shell account to
poke around the live system.

OTOH -- if I can use the JVM to figure out where a given class is from,
then my debugging of this hypothetical problem is much easier.

I'm with Manoj in believing that this scenario is one we should avoid in
the first place, by not overriding classes. However, that is *not* the
current plan: the current *design* for how to do instanciations includes
overriding some but *not* all files in joist/helm/etc. Because of that, I
think this offers a compelling advantage.

Unless you want to try to convince people to avoid overriding classes,
ever. I'd be with you, but I've no time left to fight that fight. <sad
smile>

cheers --

Ed
--
   +=-=+=-=+=-=+=-=+=-=​+=-=+=-=+=-=+=-=+=-=​+=-=+=-=+=-=+=-=
   | Ed Korthof | edk at collab dot net | 415-247-1690 |
   +=-=+=-=+=-=+=-=+=-=​+=-=+=-=+=-=+=-=+=-=​+=-=+=-=+=-=+=-=

Re: [joist-dev] Re: [helm-dev] Re: [joist-dev] Inserting $Id$ into files

Author Jon Stevens <jon at latchkey dot com>
Full name Jon Stevens <jon at latchkey dot com>
Date 2000-10-04 15:44:12 PDT
Message on 10/4/2000 3:31 PM, "Josh Lucas" <lucas at collab dot net> wrote:

> The reality is that classes in those jars are going to get overlayed as
> that is our current instantiation scheme.

Again, what do you mean by this?

Are you saying that you are going to have classes in foo.jar and bar.jar
that are identical (other than by version number) and you are going to use
the classpath to determine which ones should be used?

Again, that is something that is easily solved by looking at the classpath.

-jon

--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apach​e.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/

Re: [helm-dev] Re: [joist-dev] Inserting $Id$ into files

Author deploy
Full name Deployment Pseudo-user
Date 2000-10-04 15:31:58 PDT
Message On Wed, 4 Oct 2000, Manoj Kasichainula wrote:

> On Wed, Oct 04, 2000 at 02:42:02PM -0700, Jon Stevens wrote:
> > Maybe a better idea for solving the problem you describe above would be to
> > add a class to the .jar file with a Main in it that allows you to execute
> > the .jar file and return the version information.
> >
> > java -jar anzu.jar Version
>
> I think I'm with Jon on this one. The only reason we'd need to
> identify individual classes is if jars can go internally out of sync
> or classes in those jars can get overlayed. Both of those scenarios
> should be avoided, not specially coded for.

The reality is that classes in those jars are going to get overlayed as
that is our current instantiation scheme.

Re: [joist-dev] Inserting $Id$ into files

Author Manoj Kasichainula <manoj at collab dot net>
Full name Manoj Kasichainula <manoj at collab dot net>
Date 2000-10-04 15:29:24 PDT
Message On Wed, Oct 04, 2000 at 02:42:02PM -0700, Jon Stevens wrote:
> Maybe a better idea for solving the problem you describe above would be to
> add a class to the .jar file with a Main in it that allows you to execute
> the .jar file and return the version information.
>
> java -jar anzu.jar Version

I think I'm with Jon on this one. The only reason we'd need to
identify individual classes is if jars can go internally out of sync
or classes in those jars can get overlayed. Both of those scenarios
should be avoided, not specially coded for.

Re: [joist-dev] Inserting $Id$ into files

Author Jon Stevens <jon at latchkey dot com>
Full name Jon Stevens <jon at latchkey dot com>
Date 2000-10-04 15:28:46 PDT
Message on 10/4/2000 3:18 PM, "Josh Lucas" <lucas at collab dot net> wrote:

> It isn't an issue of which version of a jar we are using but which version
> of a particular class.
>
> josh

why would that be a question?

if you know your classpath...which you do...then you know which .jars are in
it and thus exactly which classes are in it.

also, the version information can be stored in the META-INF directory within
the .jar file. we should take advantage of that as well.

-jon

Re: [joist-dev] Inserting $Id$ into files

Author deploy
Full name Deployment Pseudo-user
Date 2000-10-04 15:18:39 PDT
Message On Wed, 4 Oct 2000, Jon Stevens wrote:

[snip]

> > OTOH -- in situations where we may have some of the classes for joist
> > overridden by an instanciation -- it may be important to know the IDs for
> > each class. The current design for instanciations involves overriding
> > classes in joist / helm / etc. to change the behavior. (Yes, this scares
> > me.)
>
> ?? I don't understand. You have a group of .jar files. You want to know
> which version of the .jar file you are using. What does the above have to do
> with that?
>

It isn't an issue of which version of a jar we are using but which version
of a particular class.


josh

Re: [joist-dev] Inserting $Id$ into files

Author Jon Stevens <jon at latchkey dot com>
Full name Jon Stevens <jon at latchkey dot com>
Date 2000-10-04 15:01:48 PDT
Message on 10/4/2000 2:48 PM, "Ed Korthof" <edk at collab dot net> wrote:

> My point is that it's not much worse than the overhead we already have
> from 10,000 classes (which I'm not suggesting ;-).

10,000 classes + 10,000 static Strings + + + ...

> Well, I wouldn't mind using that approach as well. But finding the
> version ID for a class is relatively easy. Inside a non-static method (or
> with an actual object), it's something along the lines of:
>
> Class name = this.getClass().getC​lassLoader().loadCla​ss("name");
>
> then you use reflection on the Class object to retrieve the value of the
> field (we're using a consistent name, so that's not a problem).
>
> The good & bad of this approach is that you don't really get release tags,
> you get the IDs of the individual files. You'd have to map those to
> release tags by hand.

Yep. That and you also have to know the name of the file that you are
looking for. In other words, you need to first build up a list of all the
classes and then query over them all.

Seems like it isn't doing anything to solve the problem which is essentially
all you need to know is the version of the .jar file is in use. Right?

> OTOH -- in situations where we may have some of the classes for joist
> overridden by an instanciation -- it may be important to know the IDs for
> each class. The current design for instanciations involves overriding
> classes in joist / helm / etc. to change the behavior. (Yes, this scares
> me.)

?? I don't understand. You have a group of .jar files. You want to know
which version of the .jar file you are using. What does the above have to do
with that?

Anyway, I just thought that the solution didn't really match up to what the
problem is.

Take my comments for their $0.00 worth.

-jon

Re: [joist-dev] Inserting $Id$ into files

Author edk
Full name Ed Korthof
Date 2000-10-04 14:48:13 PDT
Message On Wed, 4 Oct 2000, Jon Stevens wrote:

> Right...10,000 classes are now 10,000 more objects in memory as well. Ed,
> you are Mr. Optimization Man...I don't see how you think this is good.

My point is that it's not much worse than the overhead we already have
from 10,000 classes (which I'm not suggesting ;-).

> You didn't address my query about how you are going to query each object in
> memory for its version information. You are going down to the granularity of
> the individual object level when you really only need the .jar level.
>
> My guestimate is that figuring out what files are in a classpath will be a
> _hell_ of a lot easier than trying to query each and every object in memory
> for its VERSION string.
>
> Maybe a better idea for solving the problem you describe above would be to
> add a class to the .jar file with a Main in it that allows you to execute
> the .jar file and return the version information.
>
> java -jar anzu.jar Version

Well, I wouldn't mind using that approach as well. But finding the
version ID for a class is relatively easy. Inside a non-static method (or
with an actual object), it's something along the lines of:

    Class name = this.getClass().getC​lassLoader().loadCla​ss("name");

then you use reflection on the Class object to retrieve the value of the
field (we're using a consistent name, so that's not a problem).

The good & bad of this approach is that you don't really get release tags,
you get the IDs of the individual files. You'd have to map those to
release tags by hand.

OTOH -- in situations where we may have some of the classes for joist
overridden by an instanciation -- it may be important to know the IDs for
each class. The current design for instanciations involves overriding
classes in joist / helm / etc. to change the behavior. (Yes, this scares
me.)

cheers --

Ed
--
   +=-=+=-=+=-=+=-=+=-=​+=-=+=-=+=-=+=-=+=-=​+=-=+=-=+=-=+=-=
   | Ed Korthof | edk at collab dot net | 415-247-1690 |
   +=-=+=-=+=-=+=-=+=-=​+=-=+=-=+=-=+=-=+=-=​+=-=+=-=+=-=+=-=

Re: [joist-dev] Inserting $Id$ into files

Author Jon Stevens <jon at latchkey dot com>
Full name Jon Stevens <jon at latchkey dot com>
Date 2000-10-04 14:42:02 PDT
Message on 10/4/2000 2:23 PM, "Ed Korthof" <edk at collab dot net> wrote:

> Let's keep it in perspective. The $Id$ strings are generally less than 80
> bytes; and Java's overhead per String object is probably less than 50
> bytes. (I did do some simple tests to verify this.) But lets be generous
> and say that each String requires 200 bytes. (A fair overestimate.)
>
> If we had 10,000 such classes, it'd still take only 2MB (far more than
> we'll use anytime soon -- and if/when we do, I doubt 2MB will be
> significant). That's quite worthwhile, if it provides even a minor
> advantage -- which it does.

Right...10,000 classes are now 10,000 more objects in memory as well. Ed,
you are Mr. Optimization Man...I don't see how you think this is good.

> We can find javadocs on disk, and even the release ID in the jar file
> (which I intend to include in the jar file name for anzu, at least). But
> that doesn't ensure that you're loading the same version that you think
> you are. Putting the IDs in the file gives that as an advantage -- you
> can find the actual version loaded, not the one you think should be.

You didn't address my query about how you are going to query each object in
memory for its version information. You are going down to the granularity of
the individual object level when you really only need the .jar level.

My guestimate is that figuring out what files are in a classpath will be a
_hell_ of a lot easier than trying to query each and every object in memory
for its VERSION string.

Maybe a better idea for solving the problem you describe above would be to
add a class to the .jar file with a Main in it that allows you to execute
the .jar file and return the version information.

java -jar anzu.jar Version

-jon

Re: [joist-dev] Inserting $Id$ into files

Author edk
Full name Ed Korthof
Date 2000-10-04 14:23:04 PDT
Message On Wed, 4 Oct 2000, Jon Stevens wrote:

> Wouldn't it be better to use something like this:
>
> /**
>
> @version $Id: $
> */
> public class Foo
> {
> }
>
> That is what we do in all of our Java code on java.apache.org/jakarta
> projects. Putting a static String into each and every single file seems like
> object/memory overkill to me given that you will never query each and every
> single file for its version information and you can simply build the javadoc
> and look at it that way instead.

Let's keep it in perspective. The $Id$ strings are generally less than 80
bytes; and Java's overhead per String object is probably less than 50
bytes. (I did do some simple tests to verify this.) But lets be generous
and say that each String requires 200 bytes. (A fair overestimate.)

If we had 10,000 such classes, it'd still take only 2MB (far more than
we'll use anytime soon -- and if/when we do, I doubt 2MB will be
significant). That's quite worthwhile, if it provides even a minor
advantage -- which it does.

We can find javadocs on disk, and even the release ID in the jar file
(which I intend to include in the jar file name for anzu, at least). But
that doesn't ensure that you're loading the same version that you think
you are. Putting the IDs in the file gives that as an advantage -- you
can find the actual version loaded, not the one you think should be.

cheers --

Ed
--
   +=-=+=-=+=-=+=-=+=-=​+=-=+=-=+=-=+=-=+=-=​+=-=+=-=+=-=+=-=
   | Ed Korthof | edk at collab dot net | 415-247-1690 |
   +=-=+=-=+=-=+=-=+=-=​+=-=+=-=+=-=+=-=+=-=​+=-=+=-=+=-=+=-=

Re: [joist-dev] Inserting $Id$ into files

Author Jon Stevens <jon at latchkey dot com>
Full name Jon Stevens <jon at latchkey dot com>
Date 2000-10-04 11:37:59 PDT
Message on 10/3/2000 11:14 PM, "Josh Lucas" <lucas at collab dot net> wrote:

> Tomorrow I am going to checkout a clean copy of the module(s) and insert a
> public final static String versionID = "$Id$"; into all of the java files.
> This will be used in the future for a way of tracking the correct version.
>
> I wanted to give a heads up before doing this. I will email the list(s)
> before I start the process and then again when I am done.
>
> Let me know if you have any questions.
>
>
> josh

Wouldn't it be better to use something like this:

/**

    @version $Id: $
*/
public class Foo
{
}

That is what we do in all of our Java code on java.apache.org/jakarta
projects. Putting a static String into each and every single file seems like
object/memory overkill to me given that you will never query each and every
single file for its version information and you can simply build the javadoc
and look at it that way instead.

-jon

--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apach​e.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/

Re: [joist-dev] Inserting $Id$ into files

Author dlr
Full name Daniel Rall
Date 2000-10-03 23:19:18 PDT
Message Josh Lucas wrote:
>
> Tomorrow I am going to checkout a clean copy of the module(s) and insert a
> public final static String versionID = "$Id$"; into all of the java files.
> This will be used in the future for a way of tracking the correct version.
>
> I wanted to give a heads up before doing this. I will email the list(s)
> before I start the process and then again when I am done.
>
> Let me know if you have any questions.

Leonard and I are working on what is basically a branch of the helm
module. Are code is getting to be pretty drasitically different from
what is checked into CVS. We currently do not have our fork CVS'd
anywhere. What's a good way to handle this--can we run the script
against our code as well? Thanks.
--

Daniel Rall <dlr at finemaltcoding dot com>
Page: of 2 « Previous | Next »
Messages per page: