12:46 p.m.
On Mar 15, 2011, at 12:22, Jason Greene wrote:
How do you define running? Do you mean what classes are visible to
the application when it does a load class call or do you also include what makes up the
appserver?
The former is all EE Apis plus the vendor Apis we choose to expose. That will have to be
documented.
Okey - any way to get the locations of those jars programmatically somehow and not just
from a html page ?
What do you want to use the module dep info for, other than debugging?
I got three usecases (and they don't all map to same kind of info they need to know):
1) For debugging - thats where I want to know all the dirty details to understand what is
being loaded (and preferably what is being ignored/filtered)
2) For junit test runs (i.e. not on/nor in server) - being able to have the exact same
jars on the classpath would be a big plus - this would work by either having the jar list
available or
by using some simple jboss embedded/arquillian(?) boostrap once available for AS7
3) For the classpath of projects that doesn't use maven and would rather use the
*actual* jars being made available from the runtime - these can just be the API's
/max
Sent from my iPhone
On Mar 14, 2011, at 5:37 AM, Max Rydahl Andersen <max.andersen(a)redhat.com> wrote:
> Scott, you read my mind ;)
>
> Was asking Emanuel M. about the same thing on friday - how do I know what libraries
my app is *actually* running with ?
>
> As far as I could see not only is harder to see compared to previous versions
because...
>
> ..there is no longer a few "somewhat-well-known" locations to look for jars
(I know it was actually even more tricky in previous versions, but at least majority of
jars exposed to users were in one or two lib folders)
> ..filtering rules now can cause that the bundled jars are used instead of the server
jars
> ..filtering rules now can cause that the bundled jars are *not* used and the server
jars overload them
>
> ...and asking around you get currently different answers about the rules ;)
>
> /max
>
> On Mar 12, 2011, at 21:08, Ales Justin wrote:
>
>> Hey,
>>
>> not a bad idea, and I would gladly do it.
>>
>> I'm already hacking on Modules for some other project, so I'm quite
familiar with them.
>>
>> I'll try to implement something for Beta1,
>> to ease user experience with the new modularized cl layer.
>>
>> It will probably be similar to what I did for MC deps, a simple .war app,
>> and I'll check with HeikoB what can/should be done to integrate it with the
new console.
>>
>> -Ales
>>
>> On Mar 12, 2011, at 4:35 PM, Scott Marlow wrote:
>>
>>> Hi Ales,
>>>
>>> You weren't on IRC chat in the AS7 room but I volunteered you to do a
visualization tool for AS7 classloaders. :-) I was kidding of course, about volunteering
you but thought I would mention the idea, in case you like it. The awesome visualization
tool that you did for MC dependencies made me think of you for this idea. I'm not
sure if it is even possible or wanted. But, how do our users figure out, what is going on
in classloader land, with regard to what classes/jars are accessible to each module or
deployment (maybe both?).
>>>
>>> Maybe this is a possible google summer of code idea?
>>>
>>> ;-)
>>>
>>> Scott
>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> /max
> http://about.me/maxandersen
>
>
>
>
> _______________________________________________
> 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
/max
http://about.me/maxandersen