[
https://issues.apache.org/jira/browse/LOG4J2-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15891636#comment-15891636
]
Matt Sicker commented on LOG4J2-1820:
-------------------------------------
There are two main ways to properly merge a PR from GitHub without using the UI
(which is related to this method of patch file attachments; bear with me for a
sec):
* Use the {{git pull}} command provided in the original GitHub notification
email. It fetches and merges from a different remote than what you normally
use, and when you push it to your normal remote (usually named "origin"; that's
the default at least) on apache.org, that marks the PR as merged on GitHub.
* Download the patch file by adding .patch to the URL. I just checked earlier
and adding .diff to the URL provides just the output of diff while the .patch
URL provides the output of {{git format-patch}} which is the same format that
was used in the patch file attached to this ticket. Apply this patch with the
command {{git apply foo.patch}}. You could also shorten it a bit by doing
{{curl http://whatever/foo.patch | git apply}}, but I don't know how that works
in Windows. In general, you should just be able to use {{git apply}} (or
{{git-apply}}; I don't know how git is bundled for Windows) and that will apply
the committer/author info and other metadata included in the patch so that it's
applied like a pull request.
* The third bonus way is via {{git am}}, but that's more so for people like
Linus Torvalds who use a command line mail client and still have mbox/maildir
emails which contain the patch file attachments. Considering our mailing list
software rarely propagates attachments, that's not really relevant here.
> Log4j 2.8 can lose exceptions when a security manager is present
> ----------------------------------------------------------------
>
> Key: LOG4J2-1820
> URL: https://issues.apache.org/jira/browse/LOG4J2-1820
> Project: Log4j 2
> Issue Type: Bug
> Affects Versions: 2.8
> Reporter: Jason Tedor
> Assignee: Gary Gregory
> Fix For: 2.8.2
>
> Attachments:
> 0001-Handle-security-exception-on-getting-class-loader.patch,
> 0002-Handle-security-exception-on-getting-class-loader.patch
>
>
> When Log4j is rendering an exception, it can attempt to access a class loader
> that it does not have permissions to access when a security manager is
> present.
> I have a patch and a failing test case for this; I will submit it shortly.
> This is similar to LOG4J2-1560.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
