As far as I am aware there is no other way apart from trial and error. It would be great if Tattletale would be made to be aware of jboss-modules (I am assuming that it is not, so apologies if it already is), so it could look at your jar and say -these classes were not found in any modules -these are the modules that your jar uses. On 17 Feb 2011, at 11:05, Jaikiran Pai wrote: > I have been quite frequently running into classloading problems while working with AS7. It's mainly a result of not having the correct dependencies setup in my module.xml. For example, if I have class which imports some classes from jboss-common-core module (let's assume that's the name) and some other classes from jboss-transaction-integration module then the build completes successfully and it's only during runtime that I start running into CNFE and/or NCDFE issues. I then I have to individually track down these dependencies *one at a time* and then go back to add it as a dependency in my module.xml. > > Is there any better way to manage this? I am aware that just adding anything and everything in the module.xml isn't a right approach, but atleast for classes which are directly imported into other classes of a module, it would be better to somehow automate (or better manage) the process of setting up the module.xml. That would atleast minimize the time spent in fixing the module.xml by trial and error method. Thoughts? > > -Jaikiran > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

For reference, there was an earlier discussion around this general problem: http://lists.jboss.org/pipermail/jboss-as7-dev/2010-December/000139.html On 2/17/11 5:33 AM, Darran Lofthouse wrote: > Depending on how classes are actually loaded this may not be possible > but it would be really nice if some form of report similar to 'mvn > depencency:analyze' could be output to also identify dependencies that > are no longer used. > > Regards, > Darran Lofthouse. > > > On 02/17/2011 11:24 AM, Kabir Khan wrote: >> As far as I am aware there is no other way apart from trial and error. It would be great if Tattletale would be made to be aware of jboss-modules (I am assuming that it is not, so apologies if it already is), so it could look at your jar and say >> -these classes were not found in any modules >> -these are the modules that your jar uses. >> >> On 17 Feb 2011, at 11:05, Jaikiran Pai wrote: >> >>> I have been quite frequently running into classloading problems while working with AS7. It's mainly a result of not having the correct dependencies setup in my module.xml. For example, if I have class which imports some classes from jboss-common-core module (let's assume that's the name) and some other classes from jboss-transaction-integration module then the build completes successfully and it's only during runtime that I start running into CNFE and/or NCDFE issues. I then I have to individually track down these dependencies *one at a time* and then go back to add it as a dependency in my module.xml. >>> >>> Is there any better way to manage this? I am aware that just adding anything and everything in the module.xml isn't a right approach, but atleast for classes which are directly imported into other classes of a module, it would be better to somehow automate (or better manage) the process of setting up the module.xml. That would atleast minimize the time spent in fixing the module.xml by trial and error method. Thoughts? >>> >>> -Jaikiran >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> >> >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

Pointers welcome...

Tooling will need to be able to get the relevant classpath for users; if someone could tell us how to read the information/definition without too many binary dependencies to AS7 this would be something we (JBoss Tools) would need to do anyway. Pointers welcome...(not saying I can do the base implementation but I can at least utilize/expose it to users deploying to the server ;) /max On Feb 17, 2011, at 15:39, Jason T. Greene wrote: > As an update to this topic, jboss-modules (not sure if its been released > yet) now logs all fatal errors in defineClass (source of NCDFE) at WARN > level. So it should be way easier to spot these issues. > > At some point I think we need a compile-time analysis tool (perhaps > tattletale) that can verify our module definitions for at least the > static components. We just need someone with the time to work on it. > > On 2/17/11 8:34 AM, Brian Stansberry wrote: >> For reference, there was an earlier discussion around this general problem: >> >> http://lists.jboss.org/pipermail/jboss-as7-dev/2010-December/000139.html >> >> On 2/17/11 5:33 AM, Darran Lofthouse wrote: >>> Depending on how classes are actually loaded this may not be possible >>> but it would be really nice if some form of report similar to 'mvn >>> depencency:analyze' could be output to also identify dependencies that >>> are no longer used. >>> >>> Regards, >>> Darran Lofthouse. >>> >>> >>> On 02/17/2011 11:24 AM, Kabir Khan wrote: >>>> As far as I am aware there is no other way apart from trial and error. It would be great if Tattletale would be made to be aware of jboss-modules (I am assuming that it is not, so apologies if it already is), so it could look at your jar and say >>>> -these classes were not found in any modules >>>> -these are the modules that your jar uses. >>>> >>>> On 17 Feb 2011, at 11:05, Jaikiran Pai wrote: >>>> >>>>> I have been quite frequently running into classloading problems while working with AS7. It's mainly a result of not having the correct dependencies setup in my module.xml. For example, if I have class which imports some classes from jboss-common-core module (let's assume that's the name) and some other classes from jboss-transaction-integration module then the build completes successfully and it's only during runtime that I start running into CNFE and/or NCDFE issues. I then I have to individually track down these dependencies *one at a time* and then go back to add it as a dependency in my module.xml. >>>>> >>>>> Is there any better way to manage this? I am aware that just adding anything and everything in the module.xml isn't a right approach, but atleast for classes which are directly imported into other classes of a module, it would be better to somehow automate (or better manage) the process of setting up the module.xml. That would atleast minimize the time spent in fixing the module.xml by trial and error method. Thoughts? >>>>> >>>>> -Jaikiran >>>>> _______________________________________________ >>>>> jboss-as7-dev mailing list >>>>> jboss-as7-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>> >>>> >>>> _______________________________________________ >>>> jboss-as7-dev mailing list >>>> jboss-as7-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>> >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> >> > > > -- > Jason T. Greene > JBoss, a division of Red Hat > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev