[jboss-as7-dev] [JBoss AS7 Development] - Beta1 MUST HAVE List

[Max Rydahl Andersen]

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 at 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 at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> 
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

/max
http://about.me/maxandersen