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