-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
File path handling fixes #2280
File path handling fixes #2280
Conversation
- gracefully handle grammars without source fileNames
I don't understand the CI failure, any insight would be appreciated. |
- Changes necessary to support classpath resources in a variety of different deployment scenarios See Antlr4 PR: antlr/antlr4#2280
- absolute file paths not reliable way to find resources on classpath - requires changes to ST4 in this PR: antlr/stringtemplate4#199
@solussd looks like we have some build errors |
@solussd looks like build errors in the Target.java file you changed:
|
@parrt This PR depends on changes here: antlr/stringtemplate4#199 That PR was closed as "fixed" in another PR, but the other PR didn't implement a constructor for STGroupFile that takes a URL. |
Ah. Can i just add |
That could be sufficient. I can test tomorrow morning w/ my AWS Lambda use case if you add that constructor. |
I had rewritten the constructors so they all bottom out in loadGroupURL instead of loadGroupFile. |
While moving the constructors would mean it uses a different style so we should move those back. I'm trying to build but am being unsuccessful now with later versions of Java. tools.jar apparently no longer exists. damn them! any idea what happened to the Java compiler objects? are they in a public API somewhere now? |
@parrt I'm not sure, sorry. W.r.t. the constructors, I didn't change the interface to the existing ones, I just consolidated the implementation under the URL one. |
@parrt I've got a change to fix the tools.jar issue, I'll post that in a little while. |
This is in different locations on JDK 9 and up. maven-jdk-tools-wrapper does the right thing on all JDK releases. This was mentioned in a side comment on PR antlr#2280.
Actually, it's no problem. I forgot we require java 1.7 so it's gotta be there. |
Hi @solussd i have added the ctor to ST4: antlr/stringtemplate4@b5a82e0 I hope to release ST4 this weekend so please let me know :) thanks! |
This is in different locations on JDK 9 and up. maven-jdk-tools-wrapper does the right thing on all JDK releases. This was mentioned in a side comment on PR antlr#2280.
@parrt works with updated ST4. Thanks! |
@solussd cool. ok, so you still want this merged though right? Can you tell me more about the issue you're solving? Also, shouldn't that ST4 maven ref be 4.1 to get the release version? |
@parrt yes, this PR. I’ve updated it. Yes, it looks like 4.1 has what I need. Will update in a moment. The issue was executing on AWS lambda- file paths were being constructed such that some resources were not locateable when the deployment jar was unpacked in the directory AWS Lambda unpacks it. |
Ok. also i'm not sure you can add others to contrib list. they need to add commits for their own name. |
@parrt I did that to fix a merge conflict, technically, they were already there (though git might show it as being added in the diff of this PR). |
ah. thanks |
STGroup result = null; | ||
try { | ||
result = new STGroupFile(groupFileName); | ||
result = new STGroupFile(url); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks to me as though STGroupFile's ctor calls getURL()
which does exactly that getResource thing. What additional functionality are you providing? i.e., where does ST4 go wrong? Maybe we shoulda fixed that in ST4 :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe is related to when it is called. I’d have to dig into it again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's also possible the PR you merged into ST4 instead of mine (199) makes this unnecessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah. cool. if you have time, could you find the minimal changeset that works? I'm terrified of changing this stuff in the tool!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested without the classloader in ANTLR (instead letting ST4 + getURL do the context class loader lookup) and it works. PR updated to what I believe is a minimal changeset.
- URL constructor unnecessary
@@ -397,7 +397,7 @@ public void processNonCombinedGrammar(Grammar g, boolean gencode) { | |||
|
|||
if ( generate_ATN_dot ) generateATNs(g); | |||
|
|||
if ( g.tool.getNumErrors()==0 ) generateInterpreterData(g); | |||
if (gencode && g.tool.getNumErrors()==0 ) generateInterpreterData(g); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, looking good but do we need this tweak for gencode? I'm worried someone might rely on it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems like a safe change to me– code is still generated when executed from the cli, but won't generate code when executed programmatically. I think there was an issue with it writing files in a readonly environment (e.g., deployed as a Lambda).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, sounds good. thanks for your perseverance and hard work on this!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for looking at it!
This is in different locations on JDK 9 and up. maven-jdk-tools-wrapper does the right thing on all JDK releases. This was mentioned in a side comment on PR antlr#2280.
This is in different locations on JDK 9 and up. maven-jdk-tools-wrapper does the right thing on all JDK releases. This was mentioned in a side comment on PR antlr#2280.
Fixes file/path open problem on AWS lambda, see: antlr/antlr4#2280 antlr/antlr4@11d6013 Needed by an open Lacinia issue: walmartlabs/lacinia#175 (comment)
Ensure file paths passed to STGroup[File] are absolute
See: walmartlabs/lacinia#175