1 |
Jose Gonzalez Gomez wrote: |
2 |
> ---------- Forwarded message ---------- |
3 |
> From: *Jose Gonzalez Gomez* <jgonzalez.openinput@×××××.com |
4 |
> <mailto:jgonzalez.openinput@×××××.com>> |
5 |
> Date: 27-ene-2006 12:54 |
6 |
> Subject: Re: [gentoo-java] webapp-config & Java |
7 |
> To: Andrew Cowie <andrew@×××××××××××××××××××.com |
8 |
> <mailto:andrew@×××××××××××××××××××.com>> |
9 |
> |
10 |
> 2006/1/27, Andrew Cowie < andrew@×××××××××××××××××××.com |
11 |
> <mailto:andrew@×××××××××××××××××××.com>>: |
12 |
> |
13 |
> On Thu, 2006-26-01 at 16:56 -0500, Joshua Nichols wrote: |
14 |
> |
15 |
> > Following the spirit of not using bundled jars for building, this |
16 |
> leads |
17 |
> > me to think that it would be better to explode the wars, and |
18 |
> replace the |
19 |
> > jars contained within with symlinks to the jars on the system. |
20 |
> |
21 |
> Note that some app-servers can't/won't deal with an exploded war/ear. |
22 |
> |
23 |
> |
24 |
> I think this issue has more to do with solving the issues with java |
25 |
> builds based in ant or maven than finding bundled jars... currently |
26 |
> almost every Java package out there is built using either ant or maven |
27 |
> (please, some Java Gentoo developer correct me if I'm wrong). In the |
28 |
> case of maven, jar dependencies are not bundled with source files, |
29 |
> they are specified as dependencies in the project descriptors. In the |
30 |
> case of web applications, those dependencies are downloaded from |
31 |
> binary repositories, and bundled in the WEB-INF/lib directory of the |
32 |
> war file at build time. The obvious solution (don't know if easy to |
33 |
> implement, I remember some discussion here regarding this) is to |
34 |
> intercept in some way the maven dependency resolution mechanism and |
35 |
> instead of downloading binary jars, take jars from the java packages |
36 |
> already installed by Gentoo. |
37 |
You are right that most things build using maven and/or ant. We don't |
38 |
currently build packages using maven due to the downloading-random-jars |
39 |
bit. But the solution to that isn't really relevant to this particular |
40 |
discussion, although feel free to revive the previous thread on that matter. |
41 |
> In case you still want to go the explode/replace way, as Andrew tells, |
42 |
> you won't be able to use symlinks, as some app-servers can't deal with |
43 |
> exploded archives. You should replace those jars with jars present on |
44 |
> the system, and then repackage and deploy the archive. I see this more |
45 |
> unnatural than the previous solution, although maybe easier to do. |
46 |
Perhaps we should first figure out which, if any, web containers / app |
47 |
servers don't support explodedness, before discounting this method. |
48 |
|
49 |
There is a very good reason for going the |
50 |
exploded-war-with-symlinked-jars path: you'd always be using the most up |
51 |
to date versions of the jars that have been installed on your system. |
52 |
Case in point, I recall a security vulnerability recently with struts. |
53 |
Now, if you were deploying an unexploded webapp with a vulnerable |
54 |
version of struts, then you'd still have the vulnerability in your |
55 |
webapp even after updating to a non-vulnerable version of struts. This |
56 |
wouldn't happen if we went the exploded-war-with-symlinked-jars, and at |
57 |
most you may have to restart the webapp and / or web container. |
58 |
|
59 |
- Josh |
60 |
-- |
61 |
gentoo-java@g.o mailing list |