I read that previously but if Log4J implements modules I don't see how the nodal appenders or flume appender can work.
I also got a reply to my query about referencing dependencies that are not yet modularized and the recommendation is to only use the manifest entry and not have a module-info.java until all dependencies are modularized. > On May 9, 2017, at 12:18 AM, Remko Popma <remko.po...@gmail.com> wrote: > > > > > > (Shameless plug) Every java main() method deserves http://picocli.info >> On May 9, 2017, at 15:35, Gary Gregory <garydgreg...@gmail.com> wrote: >> >> Hi All, >> >> On Mon, May 8, 2017 at 10:46 PM, Ralph Goers <ralph.go...@dslextreme.com> >> wrote: >> >>> So I keep reading up on Java modules and the more I do the more confused I >>> get about how this can ever work properly. >>> >>> 1. I am confused about how we are supposed to create a module and >>> reference something that is not yet a module. As I understand it, it will >>> either be an automatic module on the module path or just be in the >>> “unnamed” module on the class path. Well, a jar that has made no attempt to >>> be modularized will be known by the wrong name - essentially the jar file >>> name without the version so I don’t see how that can just be dropped on the >>> module path. Also, as I understand it in order for it to be accessed on the >>> class path we can’t declare a requirement on it (which makes sense I guess >>> since it isn’t a module), but it means our module declaration is incomplete. >>> >> >> For this one, this could be a case where module users will have to wrap >> jars in a module like some people do in OSGi: wrapping a jar to create a >> bundle. Eclipse ended up with a whole repository of these. Yikes. >> >> >>> >>> 2. This one scares me. The module system doesn’t allow circularities. So >>> picture a case where HttpClient is a module and it uses the Log4j 2 or >>> SLF4J API (it doesn’t really matter which). Then Log4j has an Appender that >>> uses HttpClient. Now you have Log4j that has an Appender that uses >>> HttpClient (so an optional dependency is declared) and then HttpClient uses >>> Log4j (and so declares that as a dependency) you now have a system that >>> won’t run. Even if HttpClient uses SLF4J instead you will still have a >>> problem if that then gets routed to Log4j. >>> >> >> Nothing to do about that which is what one of the items the JBoss folks >> where dismayed about... :-( > > Mark Reinhold's reasoning in his response > (http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-May/000695.html) > makes sense to me. > > Also not sure if there really is a problem: > "Cycles are not allowed when modules are resolved but it is possible to > create them post-resolution via the API, if needed [4][5]. Cycles are also > set up amongst all automatic modules, after resolution, to make it easier to > treat existing JAR files as modules without change [6]." > > >> >> It's good that we are finding this out early but it sure seems worse and >> worse :-( >> >> Gary >> >> >>> I’ve written to a couple of folks off list but at the moment I’m not clear >>> on how this can work for libraries like Log4j. >>> >>> Ralph >>> >>>> On Apr 24, 2017, at 7:58 AM, Matt Sicker <boa...@gmail.com> wrote: >>>> >>>> Support Java 9 modules sounds a lot stricter than OSGi modules. >>> Essentially >>>> what is best practices in OSGi is required in JPMS. >>>> >>>> Anyways, the ServiceLoader for log4j-api sounds reasonable. The current >>>> solution is basically a custom version of that with additional metadata >>>> (the required API version), but we can probably support that differently. >>>> From what I recall, it's basically two service loaders combined into one. >>>> >>>> On 24 April 2017 at 09:22, Mikael Ståldal <mikael.stal...@magine.com> >>> wrote: >>>> >>>>> Doing things for Java 9 modules that are beneficial also in Java 7/8 is >>>>> good. >>>>> >>>>> Using Java ServiceLoader seems like a good idea, and we should >>> definitely >>>>> do it if required to support latest SLF4J. >>>>> >>>>> I am not so sure about refactoring package the structure though. >>> Especially >>>>> not if doing so will break BC. >>>>> >>>>> On Mon, Apr 24, 2017 at 4:00 PM, Ralph Goers < >>> ralph.go...@dslextreme.com> >>>>> wrote: >>>>> >>>>>> It is and it isn’t. I’ve been working on module support all weekend. >>>>>> There are a couple of changes that must be made before modules can be >>>>>> effectively implemented and IMO it is worth doing them whether we >>> support >>>>>> modules or not. Note that none of these changes require Java 9. >>>>>> >>>>>> 1. Modify the API provider mechanism to use Java ServiceLoader. Modules >>>>>> require that the kind of mechanism we are using be implemented with >>>>>> ServiceLoader. However, our current implementation makes this easy and >>>>>> creating a binding for for an implementation is dirt simple. I will be >>>>>> checking something in for this in the next few days. >>>>>> 2. Refactor our existing package structures. Modules essentially make >>>>>> everything in a package public. We currently have a mixture of public >>> and >>>>>> private classes in both our API and in core. We need to go through all >>>>>> these classes and determine which are really public and move the >>> private >>>>>> ones to a different package. This isn’t trivial. I think there is >>>>> benefit >>>>>> in doing this whether we support modules or not. Right now many methods >>>>>> have “consider this private” in the header. But some classes in API >>> that >>>>>> are marked this way are used by Core, which means they are required to >>> be >>>>>> public to an implementation. These kinds of classes should be in the >>> spi >>>>>> package. >>>>>> >>>>>> I should also note that SLF4J now supports Java modules in the 1.8.0 >>>>> alpha >>>>>> releases. I tried integrating with that, and was somewhat successful, >>> but >>>>>> since Logback isn’t modularized our build fails in the various points >>>>> where >>>>>> we have tests that use it. SLF4J also changed its binding mechanism to >>>>> use >>>>>> SeviceLoader and it will ignore implementations that use the current >>>>>> binding mechanism. I have implemented support for that and will be >>>>>> committing that in the next few days as well. >>>>>> >>>>>> Ralph >>>>>> >>>>>>> On Apr 24, 2017, at 3:15 AM, Mikael Ståldal < >>> mikael.stal...@magine.com >>>>>> >>>>>> wrote: >>>>>>> >>>>>>> I think that it might be a bit early for us to do too much work for >>>>>>> supporting Java 9 modules. >>>>>>> >>>>>>> On Mon, Apr 24, 2017 at 12:03 PM, Mikael Ståldal < >>>>>> mikael.stal...@magine.com> >>>>>>> wrote: >>>>>>> >>>>>>>> This option will only be supported in JDK 9. >>>>>>>> It will be removed in JDK 10. >>>>>>>> >>>>>>>> >>>>>>>> On Sun, Apr 23, 2017 at 6:51 PM, Gary Gregory < >>> garydgreg...@gmail.com >>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> The "big kill switch" straight from the source: >>>>>>>>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017- >>>>>> March/011763.html >>>>>>>>> >>>>>>>>> --permit-illegal-access >>>>>>>>> >>>>>>>>> Gary >>>>>>>>> >>>>>>>>>> On Apr 23, 2017 9:44 AM, "Matt Sicker" <boa...@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>> “I have too often seen APIs that seemed like a good idea at the >>> time >>>>>> but >>>>>>>>>> were, in fact, woefully deficient, baked into the Java Platform >>>>> where >>>>>>>>> they >>>>>>>>>> fester for ages, cause pain to all who use it, and torment those >>> who >>>>>>>>>> maintain it. I will not let that happen >>>>>>>>>> Here“ - Mark Reinhold >>>>>>>>>> >>>>>>>>>> That sounds like JPMS in general to be honest, but I'm just being >>>>>>>>> cynical. >>>>>>>>>> ;) >>>>>>>>>> >>>>>>>>>> On 23 April 2017 at 11:34, Gary Gregory <garydgreg...@gmail.com> >>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> On Apr 23, 2017 9:19 AM, "Matt Sicker" <boa...@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>> One potential scenario I see is that many users may just end up >>>>>>>>> disabling >>>>>>>>>>> JPMS in all their applications to the point that it's >>> significantly >>>>>>>>>> revised >>>>>>>>>>> or scaled back for Java 10 or later. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> That's my plan the first time I see an IllegalAccessError :-( what >>>>> is >>>>>>>>> the >>>>>>>>>>> command line kill switch called? >>>>>>>>>>> >>>>>>>>>>> Gary >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 23 April 2017 at 11:04, Gary Gregory <garydgreg...@gmail.com> >>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Worse: Are Java 9 modules its Titanic? >>>>>>>>>>>> https://developer.jboss.org/blogs/scott.stark/2017/04/14/ >>>>>>>>>>>> critical-deficiencies-in-jigsawjsr-376-java-platform- >>>>>>>>>>>> module-system-ec-member-concerns >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Gary >>>>>>>>>>>> >>>>>>>>>>>> On Apr 22, 2017 5:02 PM, "Ralph Goers" < >>>>> ralph.go...@dslextreme.com> >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> This is an interesting look at the problems faced in getting >>>>>>>>>> Hibernate >>>>>>>>>>> to >>>>>>>>>>>>> work. http://stackoverflow.com/questions/43258796/hibernate- >>>>>>>>>>>>> support-for-java-9 <http://stackoverflow.com/ >>>>>>>>>>>> questions/43258796/hibernate- >>>>>>>>>>>>> support-for-java-9>. >>>>>>>>>>>>> >>>>>>>>>>>>> The issue with the compile problem with javax.xml are familiar >>> to >>>>>>>>> me >>>>>>>>>> - >>>>>>>>>>> I >>>>>>>>>>>>> had to modify some Log4j code to not use the DataType converter >>>>>>>>> as it >>>>>>>>>>>> isn’t >>>>>>>>>>>>> present in the java.base module. >>>>>>>>>>>>> >>>>>>>>>>>>> Ralph >>>>>>>>>>>>> >>>>>>>>>>>>>> On Apr 22, 2017, at 4:40 PM, Ralph Goers < >>>>>>>>>> ralph.go...@dslextreme.com >>>>>>>>>>>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Oh - I just reread this. S far as I know Java 9 has a scheduled >>>>>>>>>>> release >>>>>>>>>>>>> date. It is July 27. >>>>>>>>>>>>>> >>>>>>>>>>>>>> BTW - here is the complete set of features - >>>>>>>>>>> https://docs.oracle.com/ >>>>>>>>>>>>> javase/9/whatsnew/toc.htm#JSNEW-GUID-BA9D8AF6-E706-4327- >>>>>>>>>>>> 8909-F6747B8F35C5 >>>>>>>>>>>>> <https://docs.oracle.com/javase/9/whatsnew/toc.htm# >>>>>>>>>>>>> JSNEW-GUID-BA9D8AF6-E706-4327-8909-F6747B8F35C5>. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Ralph >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Apr 22, 2017, at 10:45 AM, Gary Gregory < >>>>>>>>>> garydgreg...@gmail.com> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Let me play devil's advocate here for a sec... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Java 9 modules and this auto naming business sounds painful. >>> Is >>>>>>>>>>> there >>>>>>>>>>>>> any >>>>>>>>>>>>>>> chance that this feature will be ignored like >>>>>>>>> java.util.logging is >>>>>>>>>>> or >>>>>>>>>>>>>>> should be? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Can we stop tying ourselves into unreleased pretzels over a >>>>>>>>> moving >>>>>>>>>>>>> target >>>>>>>>>>>>>>> since we do not know when Java 9 will be out. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Can't we refocus this energy on getting the best out of Java >>> 8? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Ducking from incoming tomatoes, >>>>>>>>>>>>>>> Gary >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Fri, Apr 21, 2017 at 8:48 PM, Matt Sicker < >>> boa...@gmail.com >>>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'm a fan of splitting packages up better due to OSGi support >>>>>>>>> in >>>>>>>>>>> the >>>>>>>>>>>>> first >>>>>>>>>>>>>>>> place. Hierarchical packaging is definitely something new >>>>>>>>> (OSGi >>>>>>>>>>>> doesn't >>>>>>>>>>>>>>>> care about that; each package is considered separately), and >>>>>>>>> it >>>>>>>>>>> could >>>>>>>>>>>>> help >>>>>>>>>>>>>>>> in making some classes more organized. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 21 April 2017 at 14:55, Stefan Bodewig < >>> bode...@apache.org >>>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 2017-04-21, Ralph Goers wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I have not started work on this yet, but from looking at >>>>>>>>>>>>>>>>>> http://blog.joda.org/2017/04/j >>>>>>>>> ava-9-modules-jpms-basics.html >>>>>>>>>>>>>>>>>> <http://blog.joda.org/2017/04/ >>>>>>>>> java-9-modules-jpms-basics.html> >>>>>>>>>>> it >>>>>>>>>>>>>>>>>> seems we are going to have problems with a) plugins that >>>>>>>>> are in >>>>>>>>>>>>>>>>>> different jars (modules) that use the same namespace and b) >>>>>>>>>>>>> log4j-core >>>>>>>>>>>>>>>>>> as it currently exists. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Item b is a problem because the module-info for log4j-core >>>>>>>>>> should >>>>>>>>>>>>> have >>>>>>>>>>>>>>>>>> a requires ONLY for log4j-api. For example, I’m not sure >>>>>>>>> how we >>>>>>>>>>> can >>>>>>>>>>>>>>>>>> have an optional dependency on Jackson. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> requires static module-name-of-jackson; >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html >>>>>>>>> section >>>>>>>>>>>> 1.1.1 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The requires keyword may be followed by the modifier >>>>>>>>> static. >>>>>>>>>>> This >>>>>>>>>>>>>>>>> specifies that the dependence, while mandatory at compile >>>>>>>>>> time, >>>>>>>>>>> is >>>>>>>>>>>>>>>>> optional at run time. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Of course "requires static" captures this way more clearly >>>>>>>>> than >>>>>>>>>>>>> "require >>>>>>>>>>>>>>>>> optional" which was proposed intially >>>>>>>>>>>>>>>>> http://openjdk.java.net/projects/jigsaw/doc/topics/ >>>>>>>>>> optional.html >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> :-) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Without knowing the structure of log4j too well I agree the >>>>>>>>>> strict >>>>>>>>>>>>>>>>> package hierarchies mandated by JPMS will be a problem. >>>>>>>>> Probably >>>>>>>>>>> for >>>>>>>>>>>>>>>>> many other projects with more than one artifact as well. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Stefan >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> Matt Sicker <boa...@gmail.com> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>>>>>>>>>>>>>> Java Persistence with Hibernate, Second Edition >>>>>>>>>>>>>>> <https://www.amazon.com/gp/product/1617290459/ref=as_li_ >>>>>>>>>>>>> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459& >>>>>>>>>>>>> linkCode=as2&tag=garygregory-20&linkId= >>>>>>>>>> cadb800f39946ec62ea2b1af9fe6a2 >>>>>>>>>>> b8> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <http:////ir-na.amazon-adsystem.com/e/ir?t= >>>>>>>>>>>> garygregory-20&l=am2&o=1&a= >>>>>>>>>>>>> 1617290459> >>>>>>>>>>>>>>> JUnit in Action, Second Edition >>>>>>>>>>>>>>> <https://www.amazon.com/gp/product/1935182021/ref=as_li_ >>>>>>>>>>>>> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021& >>>>>>>>>>>>> linkCode=as2&tag=garygregory-20&linkId= >>>>>>>>>> 31ecd1f6b6d1eaf8886ac902a24de4 >>>>>>>>>>>> 18%22 >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <http:////ir-na.amazon-adsystem.com/e/ir?t= >>>>>>>>>>>> garygregory-20&l=am2&o=1&a= >>>>>>>>>>>>> 1935182021> >>>>>>>>>>>>>>> Spring Batch in Action >>>>>>>>>>>>>>> <https://www.amazon.com/gp/product/1935182951/ref=as_li_ >>>>>>>>>>>>> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951& >>>>>>>>>>>>> linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B% >>>>>>>>>>>>> 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> >>>>>>>>>>>>>>> <http:////ir-na.amazon-adsystem.com/e/ir?t= >>>>>>>>>>>> garygregory-20&l=am2&o=1&a= >>>>>>>>>>>>> 1935182951> >>>>>>>>>>>>>>> Blog: http://garygregory.wordpress.com >>>>>>>>>>>>>>> Home: http://garygregory.com/ >>>>>>>>>>>>>>> Tweet! http://twitter.com/GaryGregory >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Matt Sicker <boa...@gmail.com> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Matt Sicker <boa...@gmail.com> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> [image: MagineTV] >>>>>>>> >>>>>>>> *Mikael Ståldal* >>>>>>>> Senior software developer >>>>>>>> >>>>>>>> *Magine TV* >>>>>>>> mikael.stal...@magine.com >>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com >>>>>>>> >>>>>>>> Privileged and/or Confidential Information may be contained in this >>>>>>>> message. If you are not the addressee indicated in this message >>>>>>>> (or responsible for delivery of the message to such a person), you >>> may >>>>>> not >>>>>>>> copy or deliver this message to anyone. In such case, >>>>>>>> you should destroy this message and kindly notify the sender by reply >>>>>>>> email. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> [image: MagineTV] >>>>>>> >>>>>>> *Mikael Ståldal* >>>>>>> Senior software developer >>>>>>> >>>>>>> *Magine TV* >>>>>>> mikael.stal...@magine.com >>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com >>>>>>> >>>>>>> Privileged and/or Confidential Information may be contained in this >>>>>>> message. If you are not the addressee indicated in this message >>>>>>> (or responsible for delivery of the message to such a person), you may >>>>>> not >>>>>>> copy or deliver this message to anyone. In such case, >>>>>>> you should destroy this message and kindly notify the sender by reply >>>>>>> email. >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> [image: MagineTV] >>>>> >>>>> *Mikael Ståldal* >>>>> Senior software developer >>>>> >>>>> *Magine TV* >>>>> mikael.stal...@magine.com >>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com >>>>> >>>>> Privileged and/or Confidential Information may be contained in this >>>>> message. If you are not the addressee indicated in this message >>>>> (or responsible for delivery of the message to such a person), you may >>> not >>>>> copy or deliver this message to anyone. In such case, >>>>> you should destroy this message and kindly notify the sender by reply >>>>> email. >>>>> >>>> >>>> >>>> >>>> -- >>>> Matt Sicker <boa...@gmail.com> >>> >>> >>> >> >> >> -- >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >> Java Persistence with Hibernate, Second Edition >> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> >> >> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459> >> JUnit in Action, Second Edition >> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22> >> >> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021> >> Spring Batch in Action >> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> >> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951> >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory
