Support for running under mvn jetty:run

[danhaywood]

Hi Luke,

Sadly I've reverted our (Apache Isis') dependency on your library, because if I run our webapp using mvn jetty:run then the classpath system property will not be populated. Since that's a use case we need to support, it's a bit of a showstopper.

I did a bit of playing around to see if there was another way to determine the directories/JARs to search through (eg ClassLoader.getSystemClassLoader()) but without success. In any case, getting into the whole classloader thing w.r.t. servlet containers is not something I want to get into without a bit of care.

So this ticket is a request to see if FCS can be made to run under mvn jetty:run (and also mvn antrun:run that we use to run our app via a standalone main() bootstrap method).

Thx
Dan

[lukehutch]

Hmm, I didn't know there was any other mechanism for setting up the
classpath. How does Jetty even find its classes in that environment? Does
it manage its own classpath, and dynamically load classes?

I'm more than happy to add an API call to add custom paths to search,
and/or to read the classpath using some other mechanism.. Maybe you can
raise the question on the Maven/Jetty mailing lists to figure out how to
determine the path, and then let me know?
On Aug 2, 2015 4:18 AM, "Dan Haywood" notifications@github.com wrote:

Hi Luke,

Sadly I've reverted our (Apache Isis') dependency on your library, because
if I run our webapp using mvn jetty:run then the classpath system property
will not be populated. Since that's a use case we need to support, it's a
bit of a showstopper.

I did a bit of playing around to see if there was another way to determine
the directories/JARs to search through (eg
ClassLoader.getSystemClassLoader()) but without success. In any case,
getting into the whole classloader thing w.r.t. servlet containers is not
something I want to get into without a bit of care.

So this ticket is a request to see if FCS can be made to run under mvn
jetty:run (and also mvn antrun:run that we use to run our app via a
standalone main() bootstrap method).

Thx
Dan

—
Reply to this email directly or view it on GitHub
#18.

[danhaywood]

It may not be servlet containers per se (though the classpath loading for
servlet containers is non trivial, see eg [1]).

I think with mvn jetty:run etc the problem is with mvn, which evaluates the
classpath from the pom and then must set up the classpath dynamically.
This stack overflow [2] offers some clues

I shall let you explore some more... afraid I can't get too sidetracked
with this myself right now.

Thx
Dan

[1] https://www.mulesoft.com/tcat/tomcat-classpath
[2]
http://stackoverflow.com/questions/773855/setting-the-a-property-to-what-maven-compile-classpath-contains-without-ant

On 2 August 2015 at 22:18, Luke Hutchison notifications@github.com wrote:

Hmm, I didn't know there was any other mechanism for setting up the
classpath. How does Jetty even find its classes in that environment? Does
it manage its own classpath, and dynamically load classes?

I'm more than happy to add an API call to add custom paths to search,
and/or to read the classpath using some other mechanism.. Maybe you can
raise the question on the Maven/Jetty mailing lists to figure out how to
determine the path, and then let me know?
On Aug 2, 2015 4:18 AM, "Dan Haywood" notifications@github.com wrote:

Hi Luke,

Sadly I've reverted our (Apache Isis') dependency on your library,
because
if I run our webapp using mvn jetty:run then the classpath system
property
will not be populated. Since that's a use case we need to support, it's a
bit of a showstopper.

I did a bit of playing around to see if there was another way to
determine
the directories/JARs to search through (eg
ClassLoader.getSystemClassLoader()) but without success. In any case,
getting into the whole classloader thing w.r.t. servlet containers is not
something I want to get into without a bit of care.

So this ticket is a request to see if FCS can be made to run under mvn
jetty:run (and also mvn antrun:run that we use to run our app via a
standalone main() bootstrap method).

Thx
Dan

—
Reply to this email directly or view it on GitHub
#18.

—
Reply to this email directly or view it on GitHub
#18 (comment)
.

[lukehutch]

Thanks, I took a look at this, and it looks complicated. Tomcat's use case might be a bit too niche to support, but Maven probably needs supporting. For my own reference, it looks like I'll need to use the plexus-classworlds API to get at Maven's classpath: https://github.com/sonatype/plexus-classworlds

I don't know if I'll be able to get to this for a while, but meanwhile, I added the method .overrideClasspath(customClasspath) so that you can at least pass in your own path when running under Maven. I don't know if this will solve your problem, since it requires an additional configuration step, but it's a start.

[danhaywood]

OK, thanks.

On 3 August 2015 at 11:19, Luke Hutchison notifications@github.com wrote:

Thanks, I took a look at this, and it looks complicated. Tomcat's use case
might be a bit too niche to support, but Maven probably needs supporting.
For my own reference, it looks like I'll need to use the plexus-classworlds
API to get at Maven's classpath:
https://github.com/sonatype/plexus-classworlds

I don't know if I'll be able to get to this for a while, but meanwhile, I
added the method .overrideClasspath(customClasspath) so that you can at
least pass in your own path when running under Maven. I don't know if this
will solve your problem, since it requires an additional configuration
step, but it's a start.

—
Reply to this email directly or view it on GitHub
#18 (comment)
.

[lukehutch]

OK, I may have been able to solve this in the last commit (see the code in parseSystemClasspath()). I basically walk up the call stack and pick up any classloaders at any level of the stack. This, I think, will solve the classloader issue for Maven at least -- not sure about Tomcat apps though. Would appreciate if you could please test and let me know.

[danhaywood]

ok, will do. thanks.

On 3 August 2015 at 12:18, Luke Hutchison notifications@github.com wrote:

OK, I may have been able to solve this in the last commit (see the code
in parseSystemClasspath()). I basically walk up the call stack and pick up
any classloaders at any level of the stack. This, I think, will solve the
classloader issue for Maven at least -- not sure about Tomcat apps though.
Would appreciate if you could please test and let me know.

—
Reply to this email directly or view it on GitHub
#18 (comment)
.

[lukehutch]

Did the new changes to classloader detection work for your situtation? If not, would it be helpful to be able to manually specify a path to scan?

[danhaywood]

I didn't get the chance to try them out... getting close to a release so
decided best to revert for now. Will look again when start work on next dev
phase.

Thx, Dan.
On 19 Aug 2015 09:08, "Luke Hutchison" notifications@github.com wrote:

Did the new changes to classloader detection work for your situtation? If
not, would it be helpful to be able to manually specify a path to scan?

—
Reply to this email directly or view it on GitHub
#18 (comment)
.

[lukehutch]

Hi Dan, I just pushed some fixes that make classpath scanning work much better in the case of jar files that specify their own classpaths. (1) I support ".war" as a jarfile extension, and (2) I support "Class-Path:" entries in a jar's manifest file. This may fix the issue you raised with Jetty (not sure about Maven). When you get done with your release, it would be great if you could please test the HEAD version again. N.B. I also added a new .verbose() method that you can call before calling .scan(), it should help with debugging. Thanks!

[lukehutch]

Hi Dan, I fixed one more issue with Maven classpath support: Maven sometimes uses "file:" URIs for classpath entries. With this and the other fixes described previously, I'm pretty sure Maven support is fixed, although I don't know how to properly test Jetty or Tomcat.

I'll close this bug for now, feel free to reopen or open a new bug if you find something is still broken. Thanks for the report.