Skip to content

Tweak PropertiesLauncher to locate classes as well as nested jars #8486

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

dsyer
Copy link
Member

@dsyer dsyer commented Mar 3, 2017

Before this change application classes only work in BOOT-INF/classes.
With this change you can use a subdirectory, or the root directory
of an external jar (but not the parent archive to avoid issues
with agents and awkward delegation models).

Fixes gh-8480

@dsyer dsyer force-pushed the relocate-classes branch from 2030fe0 to 730c091 Compare March 3, 2017 16:47
@philwebb philwebb requested a review from wilkinsona March 3, 2017 19:03
@philwebb philwebb added this to the 1.5.3 milestone Mar 3, 2017
@dsyer dsyer changed the title All PropertiesLauncher to locate classes as well as nested jars Tweak PropertiesLauncher to locate classes as well as nested jars Mar 3, 2017
@dsyer
Copy link
Member Author

dsyer commented Mar 6, 2017

That last commit adds flags that user can set to launch an app with classes in the root of the archive. Some agents may break (anecdotally at least), but the app seems to work (I added a test), and AspectJ weaving also works (tested manually).

@dsyer dsyer force-pushed the relocate-classes branch from 243f43e to d35a9d6 Compare March 7, 2017 12:19
Copy link
Member

@wilkinsona wilkinsona left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the changes seem reasonable, but it's rather hard to tell as there aren't any new tests. As noted there are at least two new pieces of logic that aren't tested. Can you please flesh out the tests to cover the new capabilities?

@@ -489,7 +499,7 @@ private Archive getArchive(File file) throws IOException {
}

private List<Archive> getNestedArchives(String root) throws Exception {
if (root.startsWith("/")
if (!root.equals("/") && root.startsWith("/")
|| this.parent.getUrl().equals(this.home.toURI().toURL())) {
// If home dir is same as parent archive, no need to add it twice.
return null;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This appears to be untested

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's hard to write unit tests for this stuff, so I had already added new integration tests instead. However, I rebased and pushed an extra commit (2ae6a14) with some more unit tests, plus bug fixes for corner cases I found when writing those, and 2 new integration tests. None of the unit tests can get at this code path unfortunately because there is no way to change the "parent" archive for the test. I think the integration tests would fail without this line though.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now those changes are in d9d84b6

Copy link
Member

@wilkinsona wilkinsona Apr 10, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, Dave. We agreed on Slack not to merge 0e8f055 so I've been ignoring those integration tests. The new ones are better, but I don't like them being part of spring-boot-gradle-tests because they're not really anything to do with Gradle. Also, that module doesn't exist any more in 2.0 so they'll be a pain to merge in their current form. Is it not possible to integration tests this in the spring-boot-loader module by creating a jar or two with the required layout in code?

if (("/".equals(root) || ".".equals(root)) && parent != this.parent) {
// You can't find the root with an entry filter so it has to be added
// explicitly. But don't add the root of the parent archive.
archives.add(parent);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This appears to be untested

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above (it's the same method I think).

@dsyer dsyer force-pushed the relocate-classes branch from d35a9d6 to 2ae6a14 Compare April 9, 2017 17:06
i.e. conventional (defaults to `true`)

|`loader.parent.boot`
|Boolean flag to indicate that the parent class laoder should be the "boot" loader, not the

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo: laoder - loader

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch, thanks. Fixed in 0e8f05.

@dsyer dsyer force-pushed the relocate-classes branch 2 times, most recently from d9d84b6 to 80e0752 Compare April 11, 2017 07:55
Before this change application classes only work in BOOT-INF/classes.
With this change you can use a subdirectory, or the root directory
of an external jar (but not the parent archive to avoid issues
with agents and awkward delegation models).

Fixes spring-projectsgh-8480
@dsyer dsyer force-pushed the relocate-classes branch from 80e0752 to 6687e24 Compare April 11, 2017 08:26
@dsyer
Copy link
Member Author

dsyer commented Apr 11, 2017

Another rebase (onto 1.5.x), removed the integration tests, added more unit tests, and some slightly enhanced logic for jar paths (e.g. testing that relative paths work, which we always supported but hadn't tested): 6687e24.

I also removed the class loader hierarchy options. Still have that code on a branch if anyone is interested.

@philwebb philwebb closed this in 14638e6 Apr 20, 2017
codefromthecrypt pushed a commit to openzipkin/zipkin that referenced this pull request Apr 22, 2017
This includes better support for properties launcher, which we will use
in zipkin-aws and zipkin-azure

spring-projects/spring-boot#8486
codefromthecrypt pushed a commit to openzipkin/zipkin that referenced this pull request Apr 22, 2017
This includes better support for properties launcher, which we will use
in zipkin-aws and zipkin-azure

spring-projects/spring-boot#8486
codefromthecrypt pushed a commit to openzipkin/zipkin that referenced this pull request Apr 22, 2017
This includes better support for properties launcher, which we will use
in zipkin-aws and zipkin-azure

spring-projects/spring-boot#8486
codefromthecrypt pushed a commit to openzipkin-attic/docker-zipkin-azure that referenced this pull request Apr 22, 2017
codefromthecrypt pushed a commit to openzipkin-attic/docker-zipkin-azure that referenced this pull request Apr 22, 2017
codefromthecrypt pushed a commit to openzipkin-attic/docker-zipkin-aws that referenced this pull request Apr 22, 2017
codefromthecrypt pushed a commit to openzipkin-attic/docker-zipkin-aws that referenced this pull request Apr 22, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement A general enhancement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants