Hihi, good point, I actually never have. What phenomena are to be
expected? Just like you have compiled something with say 1.4 and let
it run on a 1.3 platform?
Anyway, I was thinking of this with respect to class loading issues...
Oliver
On Wed, 22 Dec 2004 13:37:44 +1300, Sharples, Colin
<[E
> I do not think you can compare JDK APIs to commons APIs as you hardly
> have more than one version of JDK API in your classpath ;)
You mean you've never written an RMI app where the client and server were
running different JVM levels? ;-)
Colin Sharples
IBM Advisory IT Specialist
Email: [EMAIL
On Wed, 22 Dec 2004 08:58:13 +1300, Sharples, Colin
<[EMAIL PROTECTED]> wrote:
> > And, in my experience watching work done with tools like
> > Gump, any time
> > people do weird trickery with package names, like Sun
> > renaming some packages
> > from x.y.z to com.sun.x.y.z, this inevitably seems
On Tue, 21 Dec 2004 21:51:56 +0100, Daniel Florey <[EMAIL PROTECTED]> wrote:
> Thanks for the links. Do you know if there is a maven task to automatically
> generate this manifest entries based on the project.xml?
> If not this might be a first step in order to allow easy adoption for the
> upcomin
[EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> Im Auftrag von Craig McClanahan
> Gesendet: Dienstag, 21. Dezember 2004 21:28
> An: Jakarta Commons Developers List
> Betreff: Re: AW: AW: AW: AW: [proposal] avoiding jar version nightmares
>
> Don't forget to do a little light rea
> >>With regards to problems caused by components that aren't using this new
> >>package, I'm thinking that as long as the component does not make any
> >>Class.forName calls, we should be OK. If there are Class.forName calls,
> >>the component may still be able to work, but w
> And, in my experience watching work done with tools like
> Gump, any time
> people do weird trickery with package names, like Sun
> renaming some packages
> from x.y.z to com.sun.x.y.z, this inevitably seems to cause
> lots of problems
> somewhere down the line.
Exactly. Remember the howls of
ECTED]
[mailto:commons-dev-return-64857-
[EMAIL PROTECTED]
Im Auftrag von Matt Sgarlata
Gesendet: Dienstag, 21. Dezember 2004 13:04
An: commons-dev@jakarta.apache.org
Betreff: Re: AW: AW: [proposal] avoiding jar version nightmares
Chris Lambrou wrote:
Matt Sgarlata wrote:
Does this mean .NET doesn&
Craig McClanahan wrote:
Don't you get to this same result by creating your own URLClassLoader
for each "assembly", with its own set of JARs and/or directories
making up its "class path"?
Haha, yes you probably do get the same result! I for one just didn't
understand what this type of a solution w
d ensue if
> java.util.Vector were to change its semantics!)
>
> > Regards,
> > Daniel
>
> Matt
>
> >>-Ursprüngliche Nachricht-
> >>Von: [EMAIL PROTECTED]
> >>[mailto:commons-dev-return-64857-
> [EMAIL PROTECTED]
> >>Im Au
Don't you get to this same result by creating your own URLClassLoader
for each "assembly", with its own set of JARs and/or directories
making up its "class path"?
Craig
On Tue, 21 Dec 2004 07:03:50 -0500, Matt Sgarlata
<[EMAIL PROTECTED]> wrote:
> Chris Lambrou wrote:
> > Matt Sgarlata wrote:
> >
Daniel Florey wrote:
In order to find an appropriate solution to this issue, I'd like to identify
the different problems that we need to address.
Version: What does a version number mean?
I'll make a proposal for how to use minor/major version number to have a
basis on which we can identify the iss
December 19, 2004 5:28 PM
> To: Jakarta Commons Developers List; [EMAIL PROTECTED]
> Subject: Re: AW: AW: AW: [proposal] avoiding jar version nightmares
>
>
> On Sun, 19 Dec 2004 23:25:30 +0100, Oliver Zeigermann
> <[EMAIL PROTECTED]> wrote:
> > On Sun, 19 Dec 20
On Tue, 21 Dec 2004 09:11:55 -0500, Matt Sgarlata
<[EMAIL PROTECTED]> wrote:
> Daniel Florey wrote:
> > I'd prefer to keep the "jar" naming as introducing "assembly" would cause
> > some confusion.
> > If anyone would be interested I could put a simple proposal to the sandbox.
>
> Good point, JAR
--- Matt Sgarlata <[EMAIL PROTECTED]> wrote:
> David Graham wrote:
> > --- Daniel Florey <[EMAIL PROTECTED]> wrote:
> >
> >>BTW: Another advantage of this approach would be that imports would
> >>indicate
> >>which version of the component is in use. I had a lot of trouble to
> find
> >>out, whi
Sgarlata
Gesendet: Dienstag, 21. Dezember 2004 13:04
An: commons-dev@jakarta.apache.org
Betreff: Re: AW: AW: [proposal] avoiding jar version nightmares
Chris Lambrou wrote:
Matt Sgarlata wrote:
Does this mean .NET doesn't have reflection? That's such a killer
feature of Java; I can'
very big problems
concerning incompatible jars in the same classloader.
Regards,
Daniel
> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> Im Auftrag von Matt Sgarlata
> Gesendet: Dienstag, 21. Dezember 2004 13:04
> An: commons-dev@jakarta.
Chris Lambrou wrote:
Matt Sgarlata wrote:
Does this mean .NET doesn't have reflection? That's such a killer
feature of Java; I can't believe they wouldn't have ported it to .NET.
Any .NET developers out there that can tell us how .NET deals with
reflection when you have multiple versions of the
Matt Sgarlata wrote:
Does this mean .NET doesn't have reflection? That's such a killer
feature of Java; I can't believe they wouldn't have ported it to .NET.
Any .NET developers out there that can tell us how .NET deals with
reflection when you have multiple versions of the same class?
Since th
.Net does have reflection. Some even say it's somewhat more elegant
than Java... I ain't goin' there :)
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
Matt Sgarlata wrote:
Daniel Florey wrote:
I think handling different versions of classes/j
Daniel Florey wrote:
I think handling different versions of classes/jars at VM level would be a nice feature, but it would be very hard to implement nd to understand when it comes to reflection.
Does this mean .NET doesn't have reflection? That's such a killer
feature of Java; I can't believe the
David Graham wrote:
--- Daniel Florey <[EMAIL PROTECTED]> wrote:
BTW: Another advantage of this approach would be that imports would
indicate
which version of the component is in use. I had a lot of trouble to find
out, which version of jdom was in use by some libraries as this was not
indicated by
I think handling different versions of classes/jars at VM level would be a nice
feature, but it would be very hard to implement nd to understand when it comes
to reflection.
Another proposal would be to do it the j2se-way:
When introducing new features to a package (e.g. java.io) don't include th
--- Daniel Florey <[EMAIL PROTECTED]> wrote:
> BTW: Another advantage of this approach would be that imports would
> indicate
> which version of the component is in use. I had a lot of trouble to find
> out, which version of jdom was in use by some libraries as this was not
> indicated by the name
The ability to declare your own versioning information, and that of
your dependencies, in a MANIFEST.MF file already exists:
http://java.sun.com/j2se/1.4.2/docs/guide/extensions/versioning.html
Two existing use cases for this information are applets and servlet
containers, where the container s
Craig McClanahan wrote:
On Fri, 17 Dec 2004 19:10:32 -0500, Matt Sgarlata
<[EMAIL PROTECTED]> wrote:
How do we go about petitioning Sun for something like this?
A while back now (while the details for Tiger were being planned), I
happened to be in a meeting with Graham Hamilton (who basically owns
From: "Daniel Florey" <[EMAIL PROTECTED]>
So the collections way to handle this issue if to move all classes to a
new
subpackage and leave the old ones where they've been before.
To be honest: Is this not very close to my proposal?
Certainly, there is some similarity. Were I to change the semantic
On Sun, 19 Dec 2004 23:17:55 -, Stephen Colebourne
<[EMAIL PROTECTED]> wrote:
> The incompatabilities that usually hurt the most are the unplanned ones,
> like with collections. Your proposal is to change package with each
> incompatible new release. Well, applying that 'rule' to collections, I
You might be irritated, but I think this is the cost to pay for working
around this obvious java lack of managing versioned libraries.
I think it's just a matter of getting used to this package naming
convention.
But it doesn't solve the problem.
The incompatabilities that usually hurt the most are
On Sun, 19 Dec 2004 23:51:06 +0100, Daniel Florey <[EMAIL PROTECTED]> wrote:
>
> Simple example:
> If you have two libraries:
> Library A using component-1.x
> Library B using component-2.x
> Both libraries provide some servlets that need to live in the same webapp
> and get initialized at startup
ermann
> Gesendet: Sonntag, 19. Dezember 2004 23:51
> An: Stephen Colebourne
> Cc: Jakarta Commons Developers List
> Betreff: Re: AW: AW: AW: [proposal] avoiding jar version nightmares
>
> On Sun, 19 Dec 2004 22:46:26 -, Stephen Colebourne
> <[EMAIL PROTECTED]> wrote:
>
et: Sonntag, 19. Dezember 2004 23:46
> An: Jakarta Commons Developers List; [EMAIL PROTECTED]
> Betreff: Re: AW: AW: AW: [proposal] avoiding jar version nightmares
>
> > Major releases, i.e. e.g. from 1.x to 2.x are there not to be backward
> > compatible. Especially, I would even cons
> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> Im Auftrag von Craig McClanahan
> Gesendet: Sonntag, 19. Dezember 2004 23:34
> An: [EMAIL PROTECTED]
> Cc: Jakarta Commons Developers List
> Betreff: Re: AW: AW: AW: [propos
On Sun, 19 Dec 2004 22:46:26 -, Stephen Colebourne
<[EMAIL PROTECTED]> wrote:
> > Major releases, i.e. e.g. from 1.x to 2.x are there not to be backward
> > compatible. Especially, I would even consider it dangerous to replace
> > a 1.x version with 2.x without checks just to have a newer versi
> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> Im Auftrag von Craig McClanahan
> Gesendet: Sonntag, 19. Dezember 2004 23:28
> An: Jakarta Commons Developers List; [EMAIL PROTECTED]
> Betreff: Re: AW: AW: AW: [proposal] avoiding j
Major releases, i.e. e.g. from 1.x to 2.x are there not to be backward
compatible. Especially, I would even consider it dangerous to replace
a 1.x version with 2.x without checks just to have a newer version.
Semantics could have chages. Consider collections from 2. to 3. What
was done there was pe
On Sun, 19 Dec 2004 23:24:52 +0100, Oliver Zeigermann
<[EMAIL PROTECTED]> wrote:
>
> Major releases, i.e. e.g. from 1.x to 2.x are there not to be backward
> compatible. Especially, I would even consider it dangerous to replace
> a 1.x version with 2.x without checks just to have a newer version.
On Sun, 19 Dec 2004 23:25:30 +0100, Oliver Zeigermann
<[EMAIL PROTECTED]> wrote:
> On Sun, 19 Dec 2004 22:17:10 -, Stephen Colebourne
> <[EMAIL PROTECTED]> wrote:
> > I would also -1. Versioned packages is not an acceptable solution.
>
> What is an acceptable solution then?
Do what I said alr
On Sun, 19 Dec 2004 22:17:10 -, Stephen Colebourne
<[EMAIL PROTECTED]> wrote:
> I would also -1. Versioned packages is not an acceptable solution.
What is an acceptable solution then?
Oliver
-
To unsubscribe, e-mail: [EMAIL
On Sun, 19 Dec 2004 14:06:40 -0800, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> On Sun, 19 Dec 2004 22:52:48 +0100, Daniel Florey <[EMAIL PROTECTED]> wrote:
> > The solution you proposed will not solve the issue as you cannot replace the
> > classloader of the application server.
>
> That's not
Finally I think that my proposal is not that bad. If it's not possible to
address this issue in future versions of the java language, this seems to
be
the only solution.
So my vote is +1 to add at least the major version number to the
components
package name.
That would have unacceptable impacts
On Sun, 19 Dec 2004 22:52:48 +0100, Daniel Florey <[EMAIL PROTECTED]> wrote:
> The solution you proposed will not solve the issue as you cannot replace the
> classloader of the application server.
That's not what I proposed. If you're inside a webapp, what I
proposed is that you create your own c
Commons Developers List
> Betreff: Re: AW: AW: [proposal] avoiding jar version nightmares
>
> On Fri, 17 Dec 2004 19:10:32 -0500, Matt Sgarlata
> <[EMAIL PROTECTED]> wrote:
> > This may work, but does BCEL require the use of its own custom
> > classloader also?
> &g
On Fri, 17 Dec 2004 19:10:32 -0500, Matt Sgarlata
<[EMAIL PROTECTED]> wrote:
> This may work, but does BCEL require the use of its own custom
> classloader also?
>
> This seems to me that this isn't just a problem with commons; it is a
> problem with Java itself that .NET already has a very nice s
On Fri, 17 Dec 2004 22:16:49 +0100, Daniel Florey <[EMAIL PROTECTED]> wrote:
> This would be really a funny thing, but how could we replace the classloader
> of a given application with a custom one?
> But what about a tool that decompiles all the product jars, changes the
> package structure and
On Sat, 18 Dec 2004 00:15:28 +0100, Oliver Zeigermann
<[EMAIL PROTECTED]> wrote:
> On Fri, 17 Dec 2004 22:16:49 +0100, Daniel Florey <[EMAIL PROTECTED]> wrote:
> > This would be really a funny thing, but how could we replace the classloader
> > of a given application with a custom one?
>
> Right.
This may work, but does BCEL require the use of its own custom
classloader also?
This seems to me that this isn't just a problem with commons; it is a
problem with Java itself that .NET already has a very nice solution for.
I'm wondering if this isn't something that should be taken care of at
Sounds pretty good. However, I guess the problem is you can not change
the class loader implementation of WebSphere or other commercial stuff
:(
Oliver
On Fri, 17 Dec 2004 23:16:42 +, Chris Lambrou <[EMAIL PROTECTED]> wrote:
>
> > Correct me if I'm wrong, but didn't Microsoft come up with s
Correct me if I'm wrong, but didn't Microsoft come up with some type
of solution to DLL hell in Windows 2000 or XP? I seem to recall
reading that a long time ago, but I'm not a Windows programmer, so I
have no idea. Does anyone else know?
The .NET equivalent of a jar file is called an assemb
On Fri, 17 Dec 2004 22:16:49 +0100, Daniel Florey <[EMAIL PROTECTED]> wrote:
> This would be really a funny thing, but how could we replace the classloader
> of a given application with a custom one?
Right. Impossible :(
> But what about a tool that decompiles all the product jars, changes the
>
PROTECTED]
> > Im Auftrag von David Graham
> > Gesendet: Freitag, 17. Dezember 2004 21:33
> > An: Jakarta Commons Developers List
> > Betreff: Re: AW: [proposal] avoiding jar version nightmares
> >
> > What happens if you merge the jars for each product? For examp
...
Daniel
> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> Im Auftrag von Oliver Zeigermann
> Gesendet: Donnerstag, 16. Dezember 2004 22:44
> An: Jakarta Commons Developers List
> Betreff: Re: AW: [proposal] avoiding jar version nightmare
[mailto:[EMAIL PROTECTED]
> Im Auftrag von David Graham
> Gesendet: Freitag, 17. Dezember 2004 21:33
> An: Jakarta Commons Developers List
> Betreff: Re: AW: [proposal] avoiding jar version nightmares
>
> What happens if you merge the jars for each product? For example, put
>
What happens if you merge the jars for each product? For example, put
commons 1.x files into productA.jar and commons 2.x files into
productB.jar.
David
--- Daniel Florey <[EMAIL PROTECTED]> wrote:
> So how should we handle situations where two versions of the same
> component
> need to coexist
Daniel Florey wrote:
> Any proposals how to solve this issue in another way?
Correct me if I'm wrong, but didn't Microsoft come up with some type of
solution to DLL hell in Windows 2000 or XP? I seem to recall reading
that a long time ago, but I'm not a Windows programmer, so I have no
idea. D
So how should we handle situations where two versions of the same component
need to coexist?
If I have to integrate two commercial projects where each one uses a
different major version of the same component, how can I achieve this? There
is no chance to force them to up- or downgrade to the versio
Packages look like
com.some_domain.org.apache.xerces...
gg
-Original Message-
From: Oliver Zeigermann [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 16, 2004 1:44 PM
To: Jakarta Commons Developers List
Subject: Re: AW: [proposal] avoiding jar version nightmares
On Thu, 16 Dec 2004
On Thu, 16 Dec 2004 19:09:54 +0100, Daniel Florey <[EMAIL PROTECTED]> wrote:
> So I think we need a solution for this problem. My proposal would be to
> allow different major versions of commons components to coexist. If the
> class and package names are equal, this is not possible. My package-vers
In the project that I've been working on, I had to put together some
subprojects into the same ear. As these subprojects interact directly, they
needed to share the same classloader.
They used different versions of httpclient, collections and jdom (this one
caused the most trouble...) and it was ha
59 matches
Mail list logo