I didn't know that you could do that for parallel deployment!
A quick follow-up set of questions:
Up until now I was counting on manager and tomcat's unpackWAR handling the
nuts and bolts of the deploy process. Even though the warfile is named
yourWar-00002.war, if I allow tomcat to unpack the war, it will unpack it
as yourWar##00002 in webapps (taking its cue from the .xml file name).
I can specify an already unpacked war outside of the standard deployment
path for docBase and it indeed does work.
I understand the close relationship of context name, context path, context
version and the base file name (the name minus any .war or .xml extension)
of the xml file. It was fine up until now.
But now, if I have to break convention and manage getting the war uploaded
and unpacked along with the per-app-version xml file all by myself without
any help from tomcat, what are some best practices or pitfalls to avoid? It
seems too easy and that's always when, in the movies, the trap gets sprung.
On Thu, Oct 1, 2015 at 3:38 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Chris,
>
> On 10/1/15 11:51 AM, Chris Gamache wrote:
> > Hi all,
> >
> > I'm stuck using axis2-1.5.4.
> >
> > Here's what I think is happening:
> >
> > Axis2 does this sort of container-in-a-container thing. It creates
> > its own classloader and pulls in all of its jar libraries
> > dynamically. The problem is that it uses a java.net.URL to target
> > the files. This would be fine except for the problem that the
> > folder name, when using parallel deployment, is
> >
> > /path/to/yourWar##12345
> >
> > So (from org.apache.axis2.deployment.util.Utils)
> >
> > public static URL[] getURLsForAllJars(URL url, File tmpDir) {
> > FileInputStream fin = null; InputStream in = null; ZipInputStream
> > zin = null; try { ArrayList array = new ArrayList(); in =
> > url.openStream();
> >
> > The problem is that URL was constructed from a File object in the
> > org.apache.axis2.deployment.repository.util.DeploymentFileData.setClas
> sLoader(boolean,
> >
> >
> ClassLoader, File) method using the toURL() method. The toURL() method i
> s
> > deprecated because it doesn't escape special characters, namely the
> > "##" in the path.
> >
> > When it hits url.openStream() it is discarding everything after the
> > ##nnnnn part of the path (think hash value in a web URL). It throws
> > a "java.io.FileNotFoundException: /path/to/yourWar (No such file
> > or directory)"
> >
> > Getting in there and patching axis2-1.5.4 is less-than-desirable.
> > So many things to go wrong.
> >
> > Is there a way to alter the way tomcat unpacks the warfile? Is
> > there a way to configure the version delimiters from ## to perhaps
> > ~~ or $$ ?
>
> What about using version-1.2.3.war and placing a version##1.2.3.xml
> file into CATALINA_BASE/[engine]/[host]/? I think that'll get you
> better-looking file paths.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJWDYu6AAoJEBzwKT+lPKRYYSoQAIbX2A5X591X7FQP5qTD4GOj
> A0O2sXoJAsssz9Gq81o69lh07oFkKb+MivROuI4rP4fGiBbcKiHVJCpA5xqqn3HL
> inJK61675n2fr+II5ww7+X39zwX1fpBzYCYTIMtslG4fmO3whpPh3xbx00lwodrX
> 9AIp6V47WQQR9hjGLZaJkixN/wMwVEHOwy6XaPN1qiBfVvEedaGEXrUC8zVrUZ6B
> RieZWCru8NCkA8V4M8jbIZS3MkOovJi1Mg3s9d/Njm1fX9BjLTrwK484bBtAOOR1
> pxGeBeqkFCNe1/Fkjd/6YOgP1Y6ezYCu395a1CTMnGXcI13FCLIOEiOind6u8+Oi
> rjGL8DsrcIlpKpqiIJ9JcY5gNCTksRs8IPRXMNAMinvZtlKnyCuSA9yBjyxs+v60
> ge8glvXaUfrBTUnLFg2g8F8QbIww0UJvzpNAjMdtY1KO5RKYxwxDFigWVQFQrV13
> 0RwcbDSnnlJJHABI7ajO6UC5nMVrzMak2bN9hTYA6nipAUuXavI1ozLPorHszg5f
> GF+a/ww+/dGaqHVbvRGxGePDKeesPo3U+Dg+5M+Bl3aCOORfGEt96tzKVMpuveCp
> VLRJ5owC2LNWAil9AndkFKPF9nwps/3tRwl5G/LuvfHn7cNFg1nASQyrbua/asxM
> D3eGZK/W4NjolBgbIUk4
> =E4sU
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
