Technically you are considered modularized just by adding a manifest entry providing the module name. But all the packages are exported. You cannot do more than that until all your dependencies do at least that much.
Ralph > On May 9, 2017, at 12:27 AM, Gary Gregory <garydgreg...@gmail.com> wrote: > >> On Tue, May 9, 2017 at 12:24 AM, Apache <ralph.go...@dslextreme.com> wrote: >> >> 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. >> > > Am I reading that we should not modularize Log4j 2 until all of its > dependencies are themselves modularized? > > Gary > >> >>> 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 >> >> >> > > > -- > 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
