From ozizka at redhat.com  Mon Dec  2 07:12:44 2013
From: ozizka at redhat.com (Ondrej Zizka)
Date: Mon, 02 Dec 2013 13:12:44 +0100
Subject: [wildfly-dev] PR-5551/5552 - version-base.txt
Message-ID: <529C793C.5060201@redhat.com>

Hi all,

there's a request for something for static identification of the server 
in a directory. This comes from JBDS and prehaps other tools (installer, 
upgrader, ...)
The jira is https://issues.jboss.org/browse/WFLY-2426

The discussion on that jira staled, so I created these
https://github.com/wildfly/wildfly/pull/5551
https://github.com/wildfly/wildfly/pull/5552
(It's the same thing done in 2 ways.)

I suggest to keep the discussion in that jira WFLY-2426 .
Is this solution (as described there) acceptable? Even for layered 
stuff? Max + Rob in the CC.

Thanks,
Ondra



From alexey.loubyansky at redhat.com  Mon Dec  2 09:09:59 2013
From: alexey.loubyansky at redhat.com (Alexey Loubyansky)
Date: Mon, 02 Dec 2013 15:09:59 +0100
Subject: [wildfly-dev] cli variables
Message-ID: <529C94B7.1020802@redhat.com>

There is this issue to provide CLI preferences
https://issues.jboss.org/browse/WFLY-1063. Here I'd like to address
mainly this part

"prod-db = /subsystem=jadada/database=jadada/
so you could call prod-db:read-resource"

I'd like to get some opinion on the way it's gonna be implemented (and
what I've done so far on a local branch).

So, to address that I introduced variables. A variable starts with a $,
e.g. $prod_db. (Using simply prod_db is not a good idea since it might
conflict with actual parts of the paths, names, etc)

Variables can be introduced with

[disconnected /] set prod_db=/subsystem=datasources/data-source=ExampleDS

Read with

[standalone at localhost:9990 /] echo prod_db
/subsystem=datasources/data-source=ExampleDS

And unset with

[standalone at localhost:9990 /] unset prod_db

'echo' without parameters will list all the variables and their values,
'set prod_db=' will have the same effect as 'unset prod_db',
set/echo/unset will work with and w/o '$' prefix, tab-completion works
everywhere.

The variables may appear in:

- operation request addresses, e.g. $prod_db/statistics=jdbc:read-resource;
- operation names, e.g. $prod_db:$op(include-runtime=true);
- operation parameter names and values, e.g.
$prod_db:$op($param=$param_value);
- the same for commands.

Tab-completion helps complete the names as long as you type in '$' and
then the rest of the line after the variable as usual.

Variables added during the session are not persisted anywhere. But I've
added .jbossclirc file. This file can be located in the current
directory, wildfly home bin directory or specified with a system
property. The content of the file is usual CLI commands and/or
operations. So, the variables could be initialized there. This file, if
located, will be executed before the CLI session (interactive or not)
starts (but also after the system properties specified with --properties
are set).

As a side effect, '$' is now a special character and will have to be
escaped. Otherwise the CLI might complain about an unresolved variable.
So, this could potentially cause problems for existing scripts using $.

Note, most of this replacement stuff can already be done with system
properties using ${xxx} format (and btw scripts using '$' as in '${xxx}'
won't be affected, of course).

And for now I've made variable names follow the rules for Java identifiers.

Any remarks, objections or suggestions?

Thanks,
Alexey

From kabir.khan at jboss.com  Mon Dec  2 09:44:33 2013
From: kabir.khan at jboss.com (Kabir Khan)
Date: Mon, 2 Dec 2013 14:44:33 +0000
Subject: [wildfly-dev] [jboss-as7-dev] cli variables
In-Reply-To: <20131202143206.GH7980@beistet>
References: <529C93FC.5050407@redhat.com>
	<1478660.jOllsIsUWy@logrus.brq.redhat.com>
	<20131202143206.GH7980@beistet>
Message-ID: <8F948B14-2654-40D7-9931-CB6186B97BCE@jboss.com>

Just routing this back to the proper wildfly-dev list rather than jboss-as7-dev
On 2 Dec 2013, at 14:32, St?le W. Pedersen <spederse at redhat.com> wrote:

> hi, just wanted to let you know that both echo and export is being 
> worked on in ?sh atm. - but we need to rewrite jboss-cli to use the 
> latest api.
> ill make an effort into putting some time to do this.
> 
> regards, st?le
> 
> On 02.12.13 15:26, Hynek Mlnarik wrote:
>> Hi,
>> 
>> thanks for the effort, this feature will be very helpful indeed!
>> 
>> Overall I like your approach, yet in case of "echo" command I'd prefer mandatory use of $ character before variable name, i.e. to use:
>>   [standalone at localhost:9990 /] echo $prod_db
>> instead of proposed:
>>   [standalone at localhost:9990 /] echo prod_db
>> 
>> In other words, to apply the same substitution rules to "echo" parameters as to the rest of use cases where variable value is read. This would also be more consistent with shell standards, hence will be easily grabbed by administrators.
>> 
>> 
>> Further, do you plan recursive substitution evaluation? E.g. something like this:
>> [standalone at localhost:9990 /] set prod_db_pgsqlDS=/subsystem=datasources/data-source=ExampleDSPgSQL
>> [standalone at localhost:9990 /] set prod_db_mysqlDS=/subsystem=datasources/data-source=ExampleDSMySQL
>> [standalone at localhost:9990 /] set ds=pgsqlDS
>> [standalone at localhost:9990 /] echo ${prod_db_$ds}
>> /subsystem=datasources/data-source=ExampleDSPgSQL
>> 
>> 
>> --Hynek
>> 
>> On Mon December 2 2013 15:06:52 Alexey Loubyansky wrote:
>>> There is this issue to provide CLI preferences
>>> https://issues.jboss.org/browse/WFLY-1063. Here I'd like to address
>>> mainly this part
>>> 
>>> "prod-db = /subsystem=jadada/database=jadada/
>>> so you could call prod-db:read-resource"
>>> 
>>> I'd like to get some opinion on the way it's gonna be implemented (and
>>> what I've done so far on a local branch).
>>> 
>>> So, to address that I introduced variables. A variable starts with a $,
>>> e.g. $prod_db. (Using simply prod_db is not a good idea since it might
>>> conflict with actual parts of the paths, names, etc)
>>> 
>>> Variables can be introduced with
>>> 
>>> [disconnected /] set prod_db=/subsystem=datasources/data-source=ExampleDS
>>> 
>>> Read with
>>> 
>>> [standalone at localhost:9990 /] echo prod_db
>>> /subsystem=datasources/data-source=ExampleDS
>>> 
>>> And unset with
>>> 
>>> [standalone at localhost:9990 /] unset prod_db
>>> 
>>> 'echo' without parameters will list all the variables and their values,
>>> 'set prod_db=' will have the same effect as 'unset prod_db',
>>> set/echo/unset will work with and w/o '$' prefix, tab-completion works
>>> everywhere.
>>> 
>>> The variables may appear in:
>>> 
>>> - operation request addresses, e.g. $prod_db/statistics=jdbc:read-resource;
>>> - operation names, e.g. $prod_db:$op(include-runtime=true);
>>> - operation parameter names and values, e.g.
>>> $prod_db:$op($param=$param_value);
>>> - the same for commands.
>>> 
>>> Tab-completion helps complete the names as long as you type in '$' and
>>> then the rest of the line after the variable as usual.
>>> 
>>> Variables added during the session are not persisted anywhere. But I've
>>> added .jbossclirc file. This file can be located in the current
>>> directory, wildfly home bin directory or specified with a system
>>> property. The content of the file is usual CLI commands and/or
>>> operations. So, the variables could be initialized there. This file, if
>>> located, will be executed before the CLI session (interactive or not)
>>> starts (but also after the system properties specified with --properties
>>> are set).
>>> 
>>> As a side effect, '$' is now a special character and will have to be
>>> escaped. Otherwise the CLI might complain about an unresolved variable.
>>> So, this could potentially cause problems for existing scripts using $.
>>> 
>>> Note, most of this replacement stuff can already be done with system
>>> properties using ${xxx} format (and btw scripts using '$' as in '${xxx}'
>>> won't be affected, of course).
>>> 
>>> And for now I've made variable names follow the rules for Java identifiers.
>>> 
>>> Any remarks, objections or suggestions?
>>> 
>>> Thanks,
>>> Alexey
>>> _______________________________________________
>>> 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
> 
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev



From alexey.loubyansky at redhat.com  Mon Dec  2 10:04:56 2013
From: alexey.loubyansky at redhat.com (Alexey Loubyansky)
Date: Mon, 02 Dec 2013 16:04:56 +0100
Subject: [wildfly-dev] [jboss-as7-dev] cli variables
In-Reply-To: <8F948B14-2654-40D7-9931-CB6186B97BCE@jboss.com>
References: <529C93FC.5050407@redhat.com>	<1478660.jOllsIsUWy@logrus.brq.redhat.com>	<20131202143206.GH7980@beistet>
	<8F948B14-2654-40D7-9931-CB6186B97BCE@jboss.com>
Message-ID: <529CA198.6070509@redhat.com>

>> On 02.12.13 15:26, Hynek Mlnarik wrote:
>>> Hi,
>>>
>>> thanks for the effort, this feature will be very helpful indeed!
>>>
>>> Overall I like your approach, yet in case of "echo" command I'd prefer mandatory use of $ character before variable name, i.e. to use:
>>>    [standalone at localhost:9990 /] echo $prod_db

Sure, I don't mind.

>>> instead of proposed:
>>>    [standalone at localhost:9990 /] echo prod_db
>>>
>>> In other words, to apply the same substitution rules to "echo" parameters as to the rest of use cases where variable value is read. This would also be more consistent with shell standards, hence will be easily grabbed by administrators.
>>>
>>>
>>> Further, do you plan recursive substitution evaluation? E.g. something like this:
>>> [standalone at localhost:9990 /] set prod_db_pgsqlDS=/subsystem=datasources/data-source=ExampleDSPgSQL
>>> [standalone at localhost:9990 /] set prod_db_mysqlDS=/subsystem=datasources/data-source=ExampleDSMySQL
>>> [standalone at localhost:9990 /] set ds=pgsqlDS
>>> [standalone at localhost:9990 /] echo ${prod_db_$ds}
>>> /subsystem=datasources/data-source=ExampleDSPgSQL

Haven't planned yet but this could be done. Especially if there is 
explicit demand :) Possible conflict is this format ${xxx} is currently 
used for system properties.

Thanks for the feedback!

Alexey

>>>
>>>
>>> --Hynek
>>>
>>> On Mon December 2 2013 15:06:52 Alexey Loubyansky wrote:
>>>> There is this issue to provide CLI preferences
>>>> https://issues.jboss.org/browse/WFLY-1063. Here I'd like to address
>>>> mainly this part
>>>>
>>>> "prod-db = /subsystem=jadada/database=jadada/
>>>> so you could call prod-db:read-resource"
>>>>
>>>> I'd like to get some opinion on the way it's gonna be implemented (and
>>>> what I've done so far on a local branch).
>>>>
>>>> So, to address that I introduced variables. A variable starts with a $,
>>>> e.g. $prod_db. (Using simply prod_db is not a good idea since it might
>>>> conflict with actual parts of the paths, names, etc)
>>>>
>>>> Variables can be introduced with
>>>>
>>>> [disconnected /] set prod_db=/subsystem=datasources/data-source=ExampleDS
>>>>
>>>> Read with
>>>>
>>>> [standalone at localhost:9990 /] echo prod_db
>>>> /subsystem=datasources/data-source=ExampleDS
>>>>
>>>> And unset with
>>>>
>>>> [standalone at localhost:9990 /] unset prod_db
>>>>
>>>> 'echo' without parameters will list all the variables and their values,
>>>> 'set prod_db=' will have the same effect as 'unset prod_db',
>>>> set/echo/unset will work with and w/o '$' prefix, tab-completion works
>>>> everywhere.
>>>>
>>>> The variables may appear in:
>>>>
>>>> - operation request addresses, e.g. $prod_db/statistics=jdbc:read-resource;
>>>> - operation names, e.g. $prod_db:$op(include-runtime=true);
>>>> - operation parameter names and values, e.g.
>>>> $prod_db:$op($param=$param_value);
>>>> - the same for commands.
>>>>
>>>> Tab-completion helps complete the names as long as you type in '$' and
>>>> then the rest of the line after the variable as usual.
>>>>
>>>> Variables added during the session are not persisted anywhere. But I've
>>>> added .jbossclirc file. This file can be located in the current
>>>> directory, wildfly home bin directory or specified with a system
>>>> property. The content of the file is usual CLI commands and/or
>>>> operations. So, the variables could be initialized there. This file, if
>>>> located, will be executed before the CLI session (interactive or not)
>>>> starts (but also after the system properties specified with --properties
>>>> are set).
>>>>
>>>> As a side effect, '$' is now a special character and will have to be
>>>> escaped. Otherwise the CLI might complain about an unresolved variable.
>>>> So, this could potentially cause problems for existing scripts using $.
>>>>
>>>> Note, most of this replacement stuff can already be done with system
>>>> properties using ${xxx} format (and btw scripts using '$' as in '${xxx}'
>>>> won't be affected, of course).
>>>>
>>>> And for now I've made variable names follow the rules for Java identifiers.
>>>>
>>>> Any remarks, objections or suggestions?
>>>>
>>>> Thanks,
>>>> Alexey
>>>> _______________________________________________
>>>> 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
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From arun.gupta at gmail.com  Mon Dec  2 19:15:42 2013
From: arun.gupta at gmail.com (Arun Gupta)
Date: Mon, 2 Dec 2013 16:15:42 -0800
Subject: [wildfly-dev] Servlet Samples on Beta2 snapshot
In-Reply-To: <52740622.9060409@jboss.com>
References: <CAGBoHQX0j70tXpAobde_mrsgQCiaz_VMDR5uHQFvLpK+5BJsog@mail.gmail.com>
	<CAAoo=c41JyN4NA_tqagRfF+p27N-Rq=tqMgKHQHywrJYnH6v6w@mail.gmail.com>
	<CAGBoHQUzvegHAuuOhSHwP7dYFtojj_7FhOUN0NnJa5htPff+mw@mail.gmail.com>
	<CAAoo=c7NHdX9KWXJR+-gOuVN=NiAHOQx2k7Bo49wLLpjcOSaVw@mail.gmail.com>
	<5273FE13.6020107@gmail.com>
	<CAGBoHQVTwgkhjXQR7iPPs+sBK=6A2c5d_bxHeu3YQLu8bwk8_Q@mail.gmail.com>
	<52740441.6030308@jboss.com> <52740622.9060409@jboss.com>
Message-ID: <CAGBoHQWUfbXLsPPBT4aE8huVMkSKPb1pUBoYqLDBAyt3iPvE0w@mail.gmail.com>

If I invoke this command on a local instance of WildFly then it works.
Giving this command on a CI test build gives the error:

Exception in thread "main" java.lang.IllegalStateException:
JBAS015232: No java.io.Console available to interact with user.
at org.jboss.as.domain.management.security.adduser.AddUser.<init>(AddUser.java:104)
at org.jboss.as.domain.management.security.adduser.AddUser.<init>(AddUser.java:131)
at org.jboss.as.domain.management.security.adduser.AddUser.main(AddUser.java:230)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.jboss.modules.Module.run(Module.java:292)
at org.jboss.modules.Main.main(Main.java:455)

What would be the equivalent jboss-cli command for it ?

In general, how do guide our users to convert these command to jboss-cli ?

Arun

On Fri, Nov 1, 2013 at 12:50 PM, Darran Lofthouse
<darran.lofthouse at jboss.com> wrote:
> To add an application user to the default properties file (with groups) the
> following command should be all that is required: -
>
> ./add-user.sh -a -u u1 -p p1! -g a,b,c
>
> Regards,
> Darran Lofthouse.
>
>
> On 01/11/13 19:42, Darran Lofthouse wrote:
>>
>> On 01/11/13 19:37, Arun Gupta wrote:
>>>
>>> Stuart,
>>>
>>> I was not saying this is a bug, just trying to understand better. Each
>>> realm can use different property file but does that information needs
>>> to be exposed to the user ?
>>
>>
>>
>> It should not need to be, the -ug and -gp arguments were added for users
>> using non standard property file names so with a default installation
>> these should not be required.
>>
>> Instead the '-a' argument should be used to specify the an application
>> user is being added instead of the default mode which is to add a
>> management user.
>>
>> Also specifying the realm name should not be required, all users in a
>> single properties file must share the same realm so that is now
>> automatically discovered from the default files.
>>
>>>
>>> Nick,
>>>
>>> Default behavior is good but a non-interactive mode is more likely to
>>> be used IMHO.
>>>
>>> Arun
>>>
>>> On Fri, Nov 1, 2013 at 12:16 PM, Nikolaos Ballas <mpallas at gmail.com>
>>> wrote:
>>>>
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA256
>>>>
>>>> On that I agree with Stuart,
>>>>
>>>> you can use the script without arguments and it will guide you through
>>>> also by checking other stuff and informs you about the security you
>>>> want to apply. It will put you to select the realm and do the
>>>> configuration accordingly.
>>>>
>>>> regards
>>>> Nick
>>>> On 01/11/2013 19:08, Stuart Douglas wrote:
>>>>>>
>>>>>>
>>>>>> Thanks for the complete command, that worked!
>>>>>>
>>>>>> Just wondering what other values can be taken by the last two
>>>>>> arguments ? And why would they need a different value ?
>>>>>>
>>>>>
>>>>> because each realm uses a different property file. TBH I am not
>>>>> sure if this is a bug or not. if you use the tool without any
>>>>> arguments it automatically does the right thing. Perhaps someone
>>>>> who is more familiar with the tool could comment.
>>>>>
>>>>> Stuart
>>>>>
>>>>>
>>>>>>
>>>>>> Arun
>>>>>>
>>>>>> http://blog.arungupta.me http://twitter.com/arungupta
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________ wildfly-dev mailing
>>>>> list wildfly-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>
>>>> -----BEGIN PGP SIGNATURE-----
>>>> Version: GnuPG v1.4.12 (GNU/Linux)
>>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>>>
>>>> iF4EAREIAAYFAlJz/hMACgkQM4d5SPwi8EusKwEAg+/nDApRkExcQ3Bqh4u7L4zA
>>>> t/40dNNQIN+GdPpkS4AA/1pgrbBRo6R2f46qMlv/y/6ljQiVbhiYNEjguoEwbzg5
>>>> =n46e
>>>> -----END PGP SIGNATURE-----
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>>>
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>



-- 
http://blog.arungupta.me
http://twitter.com/arungupta


From darran.lofthouse at jboss.com  Tue Dec  3 04:28:35 2013
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Tue, 03 Dec 2013 09:28:35 +0000
Subject: [wildfly-dev] Servlet Samples on Beta2 snapshot
In-Reply-To: <CAGBoHQWUfbXLsPPBT4aE8huVMkSKPb1pUBoYqLDBAyt3iPvE0w@mail.gmail.com>
References: <CAGBoHQX0j70tXpAobde_mrsgQCiaz_VMDR5uHQFvLpK+5BJsog@mail.gmail.com>	<CAAoo=c41JyN4NA_tqagRfF+p27N-Rq=tqMgKHQHywrJYnH6v6w@mail.gmail.com>	<CAGBoHQUzvegHAuuOhSHwP7dYFtojj_7FhOUN0NnJa5htPff+mw@mail.gmail.com>	<CAAoo=c7NHdX9KWXJR+-gOuVN=NiAHOQx2k7Bo49wLLpjcOSaVw@mail.gmail.com>	<5273FE13.6020107@gmail.com>	<CAGBoHQVTwgkhjXQR7iPPs+sBK=6A2c5d_bxHeu3YQLu8bwk8_Q@mail.gmail.com>	<52740441.6030308@jboss.com>	<52740622.9060409@jboss.com>
	<CAGBoHQWUfbXLsPPBT4aE8huVMkSKPb1pUBoYqLDBAyt3iPvE0w@mail.gmail.com>
Message-ID: <529DA443.7090805@jboss.com>

I do have a task to look at better handling scripted mode, for the 
moment adding the following argument should prevent the need to use the 
console: -

   --silent

Regards,
Darran Lofthouse.


On 03/12/13 00:15, Arun Gupta wrote:
> If I invoke this command on a local instance of WildFly then it works.
> Giving this command on a CI test build gives the error:
>
> Exception in thread "main" java.lang.IllegalStateException:
> JBAS015232: No java.io.Console available to interact with user.
> at org.jboss.as.domain.management.security.adduser.AddUser.<init>(AddUser.java:104)
> at org.jboss.as.domain.management.security.adduser.AddUser.<init>(AddUser.java:131)
> at org.jboss.as.domain.management.security.adduser.AddUser.main(AddUser.java:230)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.modules.Module.run(Module.java:292)
> at org.jboss.modules.Main.main(Main.java:455)
>
> What would be the equivalent jboss-cli command for it ?
>
> In general, how do guide our users to convert these command to jboss-cli ?
>
> Arun
>
> On Fri, Nov 1, 2013 at 12:50 PM, Darran Lofthouse
> <darran.lofthouse at jboss.com> wrote:
>> To add an application user to the default properties file (with groups) the
>> following command should be all that is required: -
>>
>> ./add-user.sh -a -u u1 -p p1! -g a,b,c
>>
>> Regards,
>> Darran Lofthouse.
>>
>>
>> On 01/11/13 19:42, Darran Lofthouse wrote:
>>>
>>> On 01/11/13 19:37, Arun Gupta wrote:
>>>>
>>>> Stuart,
>>>>
>>>> I was not saying this is a bug, just trying to understand better. Each
>>>> realm can use different property file but does that information needs
>>>> to be exposed to the user ?
>>>
>>>
>>>
>>> It should not need to be, the -ug and -gp arguments were added for users
>>> using non standard property file names so with a default installation
>>> these should not be required.
>>>
>>> Instead the '-a' argument should be used to specify the an application
>>> user is being added instead of the default mode which is to add a
>>> management user.
>>>
>>> Also specifying the realm name should not be required, all users in a
>>> single properties file must share the same realm so that is now
>>> automatically discovered from the default files.
>>>
>>>>
>>>> Nick,
>>>>
>>>> Default behavior is good but a non-interactive mode is more likely to
>>>> be used IMHO.
>>>>
>>>> Arun
>>>>
>>>> On Fri, Nov 1, 2013 at 12:16 PM, Nikolaos Ballas <mpallas at gmail.com>
>>>> wrote:
>>>>>
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA256
>>>>>
>>>>> On that I agree with Stuart,
>>>>>
>>>>> you can use the script without arguments and it will guide you through
>>>>> also by checking other stuff and informs you about the security you
>>>>> want to apply. It will put you to select the realm and do the
>>>>> configuration accordingly.
>>>>>
>>>>> regards
>>>>> Nick
>>>>> On 01/11/2013 19:08, Stuart Douglas wrote:
>>>>>>>
>>>>>>>
>>>>>>> Thanks for the complete command, that worked!
>>>>>>>
>>>>>>> Just wondering what other values can be taken by the last two
>>>>>>> arguments ? And why would they need a different value ?
>>>>>>>
>>>>>>
>>>>>> because each realm uses a different property file. TBH I am not
>>>>>> sure if this is a bug or not. if you use the tool without any
>>>>>> arguments it automatically does the right thing. Perhaps someone
>>>>>> who is more familiar with the tool could comment.
>>>>>>
>>>>>> Stuart
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Arun
>>>>>>>
>>>>>>> http://blog.arungupta.me http://twitter.com/arungupta
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________ wildfly-dev mailing
>>>>>> list wildfly-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>
>>>>>
>>>>> -----BEGIN PGP SIGNATURE-----
>>>>> Version: GnuPG v1.4.12 (GNU/Linux)
>>>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>>>>
>>>>> iF4EAREIAAYFAlJz/hMACgkQM4d5SPwi8EusKwEAg+/nDApRkExcQ3Bqh4u7L4zA
>>>>> t/40dNNQIN+GdPpkS4AA/1pgrbBRo6R2f46qMlv/y/6ljQiVbhiYNEjguoEwbzg5
>>>>> =n46e
>>>>> -----END PGP SIGNATURE-----
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>
>
>

From arun.gupta at gmail.com  Tue Dec  3 07:57:02 2013
From: arun.gupta at gmail.com (Arun Gupta)
Date: Tue, 3 Dec 2013 04:57:02 -0800
Subject: [wildfly-dev] Servlet Samples on Beta2 snapshot
In-Reply-To: <529DA443.7090805@jboss.com>
References: <CAGBoHQX0j70tXpAobde_mrsgQCiaz_VMDR5uHQFvLpK+5BJsog@mail.gmail.com>
	<CAAoo=c41JyN4NA_tqagRfF+p27N-Rq=tqMgKHQHywrJYnH6v6w@mail.gmail.com>
	<CAGBoHQUzvegHAuuOhSHwP7dYFtojj_7FhOUN0NnJa5htPff+mw@mail.gmail.com>
	<CAAoo=c7NHdX9KWXJR+-gOuVN=NiAHOQx2k7Bo49wLLpjcOSaVw@mail.gmail.com>
	<5273FE13.6020107@gmail.com>
	<CAGBoHQVTwgkhjXQR7iPPs+sBK=6A2c5d_bxHeu3YQLu8bwk8_Q@mail.gmail.com>
	<52740441.6030308@jboss.com> <52740622.9060409@jboss.com>
	<CAGBoHQWUfbXLsPPBT4aE8huVMkSKPb1pUBoYqLDBAyt3iPvE0w@mail.gmail.com>
	<529DA443.7090805@jboss.com>
Message-ID: <CAGBoHQUsn7b4PmSPWn4DaiQHL9n=BnEBK2fykv7cKs-mzGKfvA@mail.gmail.com>

Yep, that's what I used to get it working.

The number of tests have steadily grown to 174, and all are passing:

https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20WildFly-cb/lastCompletedBuild/testReport/

Arun

On Tue, Dec 3, 2013 at 1:28 AM, Darran Lofthouse
<darran.lofthouse at jboss.com> wrote:
> I do have a task to look at better handling scripted mode, for the moment
> adding the following argument should prevent the need to use the console: -
>
>   --silent
>
> Regards,
> Darran Lofthouse.
>
>
>
> On 03/12/13 00:15, Arun Gupta wrote:
>>
>> If I invoke this command on a local instance of WildFly then it works.
>> Giving this command on a CI test build gives the error:
>>
>>  [0mException in thread "main" java.lang.IllegalStateException:
>> JBAS015232: No java.io.Console available to interact with user.
>> at
>> org.jboss.as.domain.management.security.adduser.AddUser.<init>(AddUser.java:104)
>> at
>> org.jboss.as.domain.management.security.adduser.AddUser.<init>(AddUser.java:131)
>> at
>> org.jboss.as.domain.management.security.adduser.AddUser.main(AddUser.java:230)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:606)
>> at org.jboss.modules.Module.run(Module.java:292)
>> at org.jboss.modules.Main.main(Main.java:455)
>>
>> What would be the equivalent jboss-cli command for it ?
>>
>> In general, how do guide our users to convert these command to jboss-cli ?
>>
>> Arun
>>
>> On Fri, Nov 1, 2013 at 12:50 PM, Darran Lofthouse
>> <darran.lofthouse at jboss.com> wrote:
>>>
>>> To add an application user to the default properties file (with groups)
>>> the
>>> following command should be all that is required: -
>>>
>>> ./add-user.sh -a -u u1 -p p1! -g a,b,c
>>>
>>> Regards,
>>> Darran Lofthouse.
>>>
>>>
>>> On 01/11/13 19:42, Darran Lofthouse wrote:
>>>>
>>>>
>>>> On 01/11/13 19:37, Arun Gupta wrote:
>>>>>
>>>>>
>>>>> Stuart,
>>>>>
>>>>> I was not saying this is a bug, just trying to understand better. Each
>>>>> realm can use different property file but does that information needs
>>>>> to be exposed to the user ?
>>>>
>>>>
>>>>
>>>>
>>>> It should not need to be, the -ug and -gp arguments were added for users
>>>> using non standard property file names so with a default installation
>>>> these should not be required.
>>>>
>>>> Instead the '-a' argument should be used to specify the an application
>>>> user is being added instead of the default mode which is to add a
>>>> management user.
>>>>
>>>> Also specifying the realm name should not be required, all users in a
>>>> single properties file must share the same realm so that is now
>>>> automatically discovered from the default files.
>>>>
>>>>>
>>>>> Nick,
>>>>>
>>>>> Default behavior is good but a non-interactive mode is more likely to
>>>>> be used IMHO.
>>>>>
>>>>> Arun
>>>>>
>>>>> On Fri, Nov 1, 2013 at 12:16 PM, Nikolaos Ballas <mpallas at gmail.com>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>> Hash: SHA256
>>>>>>
>>>>>> On that I agree with Stuart,
>>>>>>
>>>>>> you can use the script without arguments and it will guide you through
>>>>>> also by checking other stuff and informs you about the security you
>>>>>> want to apply. It will put you to select the realm and do the
>>>>>> configuration accordingly.
>>>>>>
>>>>>> regards
>>>>>> Nick
>>>>>> On 01/11/2013 19:08, Stuart Douglas wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks for the complete command, that worked!
>>>>>>>>
>>>>>>>> Just wondering what other values can be taken by the last two
>>>>>>>> arguments ? And why would they need a different value ?
>>>>>>>>
>>>>>>>
>>>>>>> because each realm uses a different property file. TBH I am not
>>>>>>> sure if this is a bug or not. if you use the tool without any
>>>>>>> arguments it automatically does the right thing. Perhaps someone
>>>>>>> who is more familiar with the tool could comment.
>>>>>>>
>>>>>>> Stuart
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Arun
>>>>>>>>
>>>>>>>> http://blog.arungupta.me http://twitter.com/arungupta
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________ wildfly-dev mailing
>>>>>>> list wildfly-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>
>>>>>>
>>>>>> -----BEGIN PGP SIGNATURE-----
>>>>>> Version: GnuPG v1.4.12 (GNU/Linux)
>>>>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>>>>>
>>>>>> iF4EAREIAAYFAlJz/hMACgkQM4d5SPwi8EusKwEAg+/nDApRkExcQ3Bqh4u7L4zA
>>>>>> t/40dNNQIN+GdPpkS4AA/1pgrbBRo6R2f46qMlv/y/6ljQiVbhiYNEjguoEwbzg5
>>>>>> =n46e
>>>>>> -----END PGP SIGNATURE-----
>>>>>> _______________________________________________
>>>>>> wildfly-dev mailing list
>>>>>> wildfly-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>
>>
>>
>>
>



-- 
http://blog.arungupta.me
http://twitter.com/arungupta

From ssilvert at redhat.com  Tue Dec  3 09:27:44 2013
From: ssilvert at redhat.com (ssilvert at redhat.com)
Date: Tue, 03 Dec 2013 09:27:44 -0500
Subject: [wildfly-dev] cli variables
In-Reply-To: <529C94B7.1020802@redhat.com>
References: <529C94B7.1020802@redhat.com>
Message-ID: <529DEA60.1010202@redhat.com>

This is really nice.

I think the next step would be to define an enterprise scope for
variables.  You would store the variables and values in the management
model so that they could be shared by any user, script, or process.  I
think that would be really useful.

On 12/2/2013 9:09 AM, Alexey Loubyansky wrote:
> There is this issue to provide CLI preferences
> https://issues.jboss.org/browse/WFLY-1063. Here I'd like to address
> mainly this part
>
> "prod-db = /subsystem=jadada/database=jadada/
> so you could call prod-db:read-resource"
>
> I'd like to get some opinion on the way it's gonna be implemented (and
> what I've done so far on a local branch).
>
> So, to address that I introduced variables. A variable starts with a $,
> e.g. $prod_db. (Using simply prod_db is not a good idea since it might
> conflict with actual parts of the paths, names, etc)
>
> Variables can be introduced with
>
> [disconnected /] set prod_db=/subsystem=datasources/data-source=ExampleDS
>
> Read with
>
> [standalone at localhost:9990 /] echo prod_db
> /subsystem=datasources/data-source=ExampleDS
>
> And unset with
>
> [standalone at localhost:9990 /] unset prod_db
>
> 'echo' without parameters will list all the variables and their values,
> 'set prod_db=' will have the same effect as 'unset prod_db',
> set/echo/unset will work with and w/o '$' prefix, tab-completion works
> everywhere.
>
> The variables may appear in:
>
> - operation request addresses, e.g. $prod_db/statistics=jdbc:read-resource;
> - operation names, e.g. $prod_db:$op(include-runtime=true);
> - operation parameter names and values, e.g.
> $prod_db:$op($param=$param_value);
> - the same for commands.
>
> Tab-completion helps complete the names as long as you type in '$' and
> then the rest of the line after the variable as usual.
>
> Variables added during the session are not persisted anywhere. But I've
> added .jbossclirc file. This file can be located in the current
> directory, wildfly home bin directory or specified with a system
> property. The content of the file is usual CLI commands and/or
> operations. So, the variables could be initialized there. This file, if
> located, will be executed before the CLI session (interactive or not)
> starts (but also after the system properties specified with --properties
> are set).
>
> As a side effect, '$' is now a special character and will have to be
> escaped. Otherwise the CLI might complain about an unresolved variable.
> So, this could potentially cause problems for existing scripts using $.
>
> Note, most of this replacement stuff can already be done with system
> properties using ${xxx} format (and btw scripts using '$' as in '${xxx}'
> won't be affected, of course).
>
> And for now I've made variable names follow the rules for Java identifiers.
>
> Any remarks, objections or suggestions?
>
> Thanks,
> Alexey
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From brian.stansberry at redhat.com  Tue Dec  3 12:05:15 2013
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 03 Dec 2013 11:05:15 -0600
Subject: [wildfly-dev] cli variables
In-Reply-To: <529C94B7.1020802@redhat.com>
References: <529C94B7.1020802@redhat.com>
Message-ID: <529E0F4B.9020104@redhat.com>

The basics of this sound good. I'm not sure about the .jbossclirc part. 
How would this file differ from the jboss-cli.xml file? Emulating 
something like .bashrc could be really cool, but if doesn't end up being 
a pretty close analogue, it could be confusing.

So what kind of things could be done with this file?

1) Simple association of variable names with simple strings. Makes 
sense, but could also be in the xml file.

2) Execution of commands?

Connect commands could make sense; eliminate boilerplate from the CLI 
launch command.

Other commands, I'm not sure what that could be.

3) Definition of functions; e.g. take what would be a separate CLI 
script with multiple commands, in-line it and name it.

4) Others?

On 12/2/13 8:09 AM, Alexey Loubyansky wrote:
> There is this issue to provide CLI preferences
> https://issues.jboss.org/browse/WFLY-1063. Here I'd like to address
> mainly this part
>
> "prod-db = /subsystem=jadada/database=jadada/
> so you could call prod-db:read-resource"
>
> I'd like to get some opinion on the way it's gonna be implemented (and
> what I've done so far on a local branch).
>
> So, to address that I introduced variables. A variable starts with a $,
> e.g. $prod_db. (Using simply prod_db is not a good idea since it might
> conflict with actual parts of the paths, names, etc)
>
> Variables can be introduced with
>
> [disconnected /] set prod_db=/subsystem=datasources/data-source=ExampleDS
>
> Read with
>
> [standalone at localhost:9990 /] echo prod_db
> /subsystem=datasources/data-source=ExampleDS
>
> And unset with
>
> [standalone at localhost:9990 /] unset prod_db
>
> 'echo' without parameters will list all the variables and their values,
> 'set prod_db=' will have the same effect as 'unset prod_db',
> set/echo/unset will work with and w/o '$' prefix, tab-completion works
> everywhere.
>
> The variables may appear in:
>
> - operation request addresses, e.g. $prod_db/statistics=jdbc:read-resource;
> - operation names, e.g. $prod_db:$op(include-runtime=true);
> - operation parameter names and values, e.g.
> $prod_db:$op($param=$param_value);
> - the same for commands.
>
> Tab-completion helps complete the names as long as you type in '$' and
> then the rest of the line after the variable as usual.
>
> Variables added during the session are not persisted anywhere. But I've
> added .jbossclirc file. This file can be located in the current
> directory, wildfly home bin directory or specified with a system
> property. The content of the file is usual CLI commands and/or
> operations. So, the variables could be initialized there. This file, if
> located, will be executed before the CLI session (interactive or not)
> starts (but also after the system properties specified with --properties
> are set).
>
> As a side effect, '$' is now a special character and will have to be
> escaped. Otherwise the CLI might complain about an unresolved variable.
> So, this could potentially cause problems for existing scripts using $.
>
> Note, most of this replacement stuff can already be done with system
> properties using ${xxx} format (and btw scripts using '$' as in '${xxx}'
> won't be affected, of course).
>
> And for now I've made variable names follow the rules for Java identifiers.
>
> Any remarks, objections or suggestions?
>
> Thanks,
> Alexey
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat

From alexey.loubyansky at redhat.com  Tue Dec  3 14:10:10 2013
From: alexey.loubyansky at redhat.com (Alexey Loubyansky)
Date: Tue, 03 Dec 2013 20:10:10 +0100
Subject: [wildfly-dev] cli variables
In-Reply-To: <529E0F4B.9020104@redhat.com>
References: <529C94B7.1020802@redhat.com> <529E0F4B.9020104@redhat.com>
Message-ID: <529E2C92.1020100@redhat.com>

I thought about adding the variables to the xml config. I think the xml 
config is more, kind of, a static and general config. While the 
variables seem to be more user-specific (user environment and perhaps 
task specific). So, I thought I'd separate them. And, yes, the idea was 
emulating .bashrc.

The content - yes, originally driven by variables. There could be custom 
command definitions and batches. All this could be put into the xml 
though but it felt like it'd be better to separate.

On 12/03/2013 06:05 PM, Brian Stansberry wrote:
> The basics of this sound good. I'm not sure about the .jbossclirc part.
> How would this file differ from the jboss-cli.xml file? Emulating
> something like .bashrc could be really cool, but if doesn't end up being
> a pretty close analogue, it could be confusing.
>
> So what kind of things could be done with this file?
>
> 1) Simple association of variable names with simple strings. Makes
> sense, but could also be in the xml file.
>
> 2) Execution of commands?
>
> Connect commands could make sense; eliminate boilerplate from the CLI
> launch command.
>
> Other commands, I'm not sure what that could be.
>
> 3) Definition of functions; e.g. take what would be a separate CLI
> script with multiple commands, in-line it and name it.
>
> 4) Others?
>
> On 12/2/13 8:09 AM, Alexey Loubyansky wrote:
>> There is this issue to provide CLI preferences
>> https://issues.jboss.org/browse/WFLY-1063. Here I'd like to address
>> mainly this part
>>
>> "prod-db = /subsystem=jadada/database=jadada/
>> so you could call prod-db:read-resource"
>>
>> I'd like to get some opinion on the way it's gonna be implemented (and
>> what I've done so far on a local branch).
>>
>> So, to address that I introduced variables. A variable starts with a $,
>> e.g. $prod_db. (Using simply prod_db is not a good idea since it might
>> conflict with actual parts of the paths, names, etc)
>>
>> Variables can be introduced with
>>
>> [disconnected /] set prod_db=/subsystem=datasources/data-source=ExampleDS
>>
>> Read with
>>
>> [standalone at localhost:9990 /] echo prod_db
>> /subsystem=datasources/data-source=ExampleDS
>>
>> And unset with
>>
>> [standalone at localhost:9990 /] unset prod_db
>>
>> 'echo' without parameters will list all the variables and their values,
>> 'set prod_db=' will have the same effect as 'unset prod_db',
>> set/echo/unset will work with and w/o '$' prefix, tab-completion works
>> everywhere.
>>
>> The variables may appear in:
>>
>> - operation request addresses, e.g. $prod_db/statistics=jdbc:read-resource;
>> - operation names, e.g. $prod_db:$op(include-runtime=true);
>> - operation parameter names and values, e.g.
>> $prod_db:$op($param=$param_value);
>> - the same for commands.
>>
>> Tab-completion helps complete the names as long as you type in '$' and
>> then the rest of the line after the variable as usual.
>>
>> Variables added during the session are not persisted anywhere. But I've
>> added .jbossclirc file. This file can be located in the current
>> directory, wildfly home bin directory or specified with a system
>> property. The content of the file is usual CLI commands and/or
>> operations. So, the variables could be initialized there. This file, if
>> located, will be executed before the CLI session (interactive or not)
>> starts (but also after the system properties specified with --properties
>> are set).
>>
>> As a side effect, '$' is now a special character and will have to be
>> escaped. Otherwise the CLI might complain about an unresolved variable.
>> So, this could potentially cause problems for existing scripts using $.
>>
>> Note, most of this replacement stuff can already be done with system
>> properties using ${xxx} format (and btw scripts using '$' as in '${xxx}'
>> won't be affected, of course).
>>
>> And for now I've made variable names follow the rules for Java identifiers.
>>
>> Any remarks, objections or suggestions?
>>
>> Thanks,
>> Alexey
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>

From frank.langelage at osnanet.de  Tue Dec  3 18:12:22 2013
From: frank.langelage at osnanet.de (Frank Langelage)
Date: Wed, 04 Dec 2013 00:12:22 +0100
Subject: [wildfly-dev] Netty 4.0.12 messages
Message-ID: <529E6556.30908@osnanet.de>

After today's upgrade of HornetQ and Netty to V4 I see this in my logs:
03.12. 20:10:09,207 FINE 
[io.netty.util.internal.logging.InternalLoggerFactory#<clinit>] Using 
java.util.logging as the default logging framework
03.12. 20:10:10,032 FINE 
[io.netty.util.internal.PlatformDependent#isRoot0] Could not determine 
the current UID using /usr/bin/id; attempting to bind at privileged ports.
03.12. 20:10:10,038 FINE 
[io.netty.util.internal.PlatformDependent#isRoot0] UID: non-root (failed 
to bind at any privileged ports)
03.12. 20:10:10,263 FINE 
[io.netty.util.internal.PlatformDependent#javaVersion0] Java version: 7
03.12. 20:10:10,265 FINE 
[io.netty.util.internal.PlatformDependent#hasUnsafe0] 
-Dio.netty.noUnsafe: false
03.12. 20:10:10,273 FINE 
[io.netty.util.internal.PlatformDependent0#<clinit>] 
java.nio.ByteBuffer.cleaner: unavailable
03.12. 20:10:10,493 FINE 
[io.netty.util.internal.PlatformDependent0#<clinit>] 
java.nio.Buffer.address: unavailable
03.12. 20:10:10,495 FINE 
[io.netty.util.internal.PlatformDependent#hasUnsafe0] sun.misc.Unsafe: 
unavailable
03.12. 20:10:10,502 FINE 
[io.netty.util.internal.PlatformDependent#hasJavassist0] 
-Dio.netty.noJavassist: false
03.12. 20:10:10,505 FINE 
[io.netty.util.internal.PlatformDependent#hasJavassist0] Javassist: 
unavailable
03.12. 20:10:10,506 FINE 
[io.netty.util.internal.PlatformDependent#hasJavassist0] You don't have 
Javassist in your class path or you don't have enough permission to load 
dynamically generated classes.  Please check the configuration for 
better performance.
03.12. 20:10:10,508 FINE 
[io.netty.util.internal.PlatformDependent#<clinit>] 
-Dio.netty.noPreferDirect: true
03.12. 20:10:10,509 INFO 
[io.netty.util.internal.PlatformDependent#<clinit>] Your platform does 
not provide complete low-level API for accessing direct buffers 
reliably. Unless explicitly requested, heap buffer will always be 
preferred to avoid potential system unstability.
03.12. 20:10:10,532 FINE [io.netty.util.ResourceLeakDetector#<clinit>] 
-Dio.netty.noResourceLeakDetection: false
03.12. 20:10:14,125 FINE 
[io.netty.channel.MultithreadEventLoopGroup#<clinit>] 
-Dio.netty.eventLoopThreads: 4
03.12. 20:10:14,208 FINE [io.netty.channel.nio.NioEventLoop#<clinit>] 
-Dio.netty.noKeySetOptimization: false
03.12. 20:10:14,209 FINE [io.netty.channel.nio.NioEventLoop#<clinit>] 
-Dio.netty.selectorAutoRebuildThreshold: 512
03.12. 20:10:14,249 FINE 
[io.netty.buffer.PooledByteBufAllocator#<clinit>] 
-Dio.netty.allocator.numHeapArenas: 2
03.12. 20:10:14,250 FINE 
[io.netty.buffer.PooledByteBufAllocator#<clinit>] 
-Dio.netty.allocator.numDirectArenas: 2
03.12. 20:10:14,252 FINE 
[io.netty.buffer.PooledByteBufAllocator#<clinit>] 
-Dio.netty.allocator.pageSize: 8192
03.12. 20:10:14,253 FINE 
[io.netty.buffer.PooledByteBufAllocator#<clinit>] 
-Dio.netty.allocator.maxOrder: 11
03.12. 20:10:14,254 FINE 
[io.netty.buffer.PooledByteBufAllocator#<clinit>] 
-Dio.netty.allocator.chunkSize: 16777216
03.12. 20:10:14,300 FINE 
[io.netty.util.internal.ThreadLocalRandom#newSeed] 
-Dio.netty.initialSeedUniquifier: 0xe6abbdc3bd390fb7
03.12. 20:10:14,360 FINE  [io.netty.util.NetUtil#<clinit>] Loopback 
interface: lo0
03.12. 20:10:14,362 FINE  [io.netty.util.NetUtil#<clinit>] Loopback 
address: /127.0.0.1 (primary)

Okay, /usr/bin/id -u or /bin/id -u etc. are not working on Solaris. 
Therefore /usr/xpg4/bin/id -u would have to be added.
But running without root access only binding to 127.0.0.1 should be 
sufficient, or?

But why is javassist is not found?

Or should I simply reduce log level for io.netty to simply hide these 
messages?


From hbraun at redhat.com  Wed Dec  4 03:19:12 2013
From: hbraun at redhat.com (Heiko Braun)
Date: Wed, 4 Dec 2013 09:19:12 +0100
Subject: [wildfly-dev] cli variables
In-Reply-To: <529DEA60.1010202@redhat.com>
References: <529C94B7.1020802@redhat.com> <529DEA60.1010202@redhat.com>
Message-ID: <AB8DDBD4-568E-48B2-AAC6-55F0AC81658F@redhat.com>


+1 on sharing them.




On 03 Dec 2013, at 15:27, ssilvert at redhat.com wrote:

> You would store the variables and values in the management
> model so that they could be shared by any user, script, or process.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131204/a03483da/attachment.html 

From ales.justin at gmail.com  Wed Dec  4 07:27:37 2013
From: ales.justin at gmail.com (Ales Justin)
Date: Wed, 4 Dec 2013 13:27:37 +0100
Subject: [wildfly-dev] MSC stability wait
Message-ID: <3FF6F77C-D3E8-4D22-A018-DE2B24E9F751@gmail.com>

I get this when running our CapeDwarf Testsuite -- which freezes our test run:

* https://gist.github.com/alesj/7786677

* https://gist.github.com/alesj/7786537

Any way to see on which service (or what / why) is StabilityMonitor waiting?

I'm running latest WF upstream, with some Ispn and Logging fixes.

-Ales

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131204/a8ea1c53/attachment.html 

From alexey.loubyansky at redhat.com  Wed Dec  4 07:41:47 2013
From: alexey.loubyansky at redhat.com (Alexey Loubyansky)
Date: Wed, 04 Dec 2013 13:41:47 +0100
Subject: [wildfly-dev] cli variables
In-Reply-To: <AB8DDBD4-568E-48B2-AAC6-55F0AC81658F@redhat.com>
References: <529C94B7.1020802@redhat.com> <529DEA60.1010202@redhat.com>
	<AB8DDBD4-568E-48B2-AAC6-55F0AC81658F@redhat.com>
Message-ID: <529F230B.50302@redhat.com>

I haven't thought about that scope. But anyway, if it proves useful it's 
doable.

On 12/04/2013 09:19 AM, Heiko Braun wrote:
>
> +1 on sharing them.
>
>
>
>
> On 03 Dec 2013, at 15:27, ssilvert at redhat.com
> <mailto:ssilvert at redhat.com> wrote:
>
>> You would store the variables and values in the management
>> model so that they could be shared by any user, script, or process.
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From brian.stansberry at redhat.com  Wed Dec  4 07:52:34 2013
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 04 Dec 2013 06:52:34 -0600
Subject: [wildfly-dev] MSC stability wait
In-Reply-To: <3FF6F77C-D3E8-4D22-A018-DE2B24E9F751@gmail.com>
References: <3FF6F77C-D3E8-4D22-A018-DE2B24E9F751@gmail.com>
Message-ID: <529F2592.1040805@redhat.com>

 From the CLI run:

/core-service=service-container:dump-services

It will show you the service state data; from there you can track down 
what services are in an odd state.

You can do the same thing via jconsole accessing the jboss.msc mbeans.

On 12/4/13 6:27 AM, Ales Justin wrote:
> I get this when running our CapeDwarf Testsuite -- which freezes our
> test run:
>
> * https://gist.github.com/alesj/7786677
>
> * https://gist.github.com/alesj/7786537
>
> Any way to see on which service (or what / why) is StabilityMonitor waiting?
>
> I'm running latest WF upstream, with some Ispn and Logging fixes.
>
> -Ales
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat

From ssilvert at redhat.com  Wed Dec  4 09:15:37 2013
From: ssilvert at redhat.com (ssilvert at redhat.com)
Date: Wed, 04 Dec 2013 09:15:37 -0500
Subject: [wildfly-dev] cli variables
In-Reply-To: <529F230B.50302@redhat.com>
References: <529C94B7.1020802@redhat.com> <529DEA60.1010202@redhat.com>
	<AB8DDBD4-568E-48B2-AAC6-55F0AC81658F@redhat.com>
	<529F230B.50302@redhat.com>
Message-ID: <529F3909.8000009@redhat.com>

On 12/4/2013 7:41 AM, Alexey Loubyansky wrote:
> I haven't thought about that scope. But anyway, if it proves useful
> it's doable.
The use case I had in mind was for if I want to share a script that runs
against servers or domain controllers on the network.  As it is, I would
have to tell the other person how to set all their variables.  Giving
the other person my .jbossclirc file is not a good idea because it also
contains variable values that only pertain to my local environment.

It's the same concept as Maven's settings.xml file for local properties
vs. the "shared" properties set in pom.xml.

It might be that all you need is to simply allow a variable to refer to
system properties on the server.  That would be your shared variable.

The $prod_db example you gave earlier would be a good candidate for a
shared variable.  So someone sets the property with:
/system-property=prod_db/:add(value=mydatabase)

Then anyone could use the $prod_db variable against that server no
matter where the command runs from.

Stan

>
> On 12/04/2013 09:19 AM, Heiko Braun wrote:
>>
>> +1 on sharing them.
>>
>>
>>
>>
>> On 03 Dec 2013, at 15:27, ssilvert at redhat.com
>> <mailto:ssilvert at redhat.com> wrote:
>>
>>> You would store the variables and values in the management
>>> model so that they could be shared by any user, script, or process.
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>


From alexey.loubyansky at redhat.com  Wed Dec  4 09:26:28 2013
From: alexey.loubyansky at redhat.com (Alexey Loubyansky)
Date: Wed, 04 Dec 2013 15:26:28 +0100
Subject: [wildfly-dev] cli variables
In-Reply-To: <529F3909.8000009@redhat.com>
References: <529C94B7.1020802@redhat.com> <529DEA60.1010202@redhat.com>
	<AB8DDBD4-568E-48B2-AAC6-55F0AC81658F@redhat.com>
	<529F230B.50302@redhat.com> <529F3909.8000009@redhat.com>
Message-ID: <529F3B94.6000301@redhat.com>


On 12/04/2013 03:15 PM, ssilvert at redhat.com wrote:
> On 12/4/2013 7:41 AM, Alexey Loubyansky wrote:
>> I haven't thought about that scope. But anyway, if it proves useful
>> it's doable.
> The use case I had in mind was for if I want to share a script that runs
> against servers or domain controllers on the network.  As it is, I would
> have to tell the other person how to set all their variables.  Giving
> the other person my .jbossclirc file is not a good idea because it also
> contains variable values that only pertain to my local environment.

Variables can also be set in the beginning of a script. Although, I can 
see advantages of keeping them out and simply relying on certain 
variables in a script.

> It's the same concept as Maven's settings.xml file for local properties
> vs. the "shared" properties set in pom.xml.
>
> It might be that all you need is to simply allow a variable to refer to
> system properties on the server.  That would be your shared variable.
>
> The $prod_db example you gave earlier would be a good candidate for a
> shared variable.  So someone sets the property with:
> /system-property=prod_db/:add(value=mydatabase)
>
> Then anyone could use the $prod_db variable against that server no
> matter where the command runs from.

That is indeed useful. BTW, don't we have aliases in the management 
model that could also be used for this?

Alexey

From brian.stansberry at redhat.com  Wed Dec  4 09:43:46 2013
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 04 Dec 2013 08:43:46 -0600
Subject: [wildfly-dev] cli variables
In-Reply-To: <529F3B94.6000301@redhat.com>
References: <529C94B7.1020802@redhat.com>
	<529DEA60.1010202@redhat.com>	<AB8DDBD4-568E-48B2-AAC6-55F0AC81658F@redhat.com>	<529F230B.50302@redhat.com>
	<529F3909.8000009@redhat.com> <529F3B94.6000301@redhat.com>
Message-ID: <529F3FA2.5090004@redhat.com>

This all sounds like variations of the kinds of things we talked a bit 
about when we created the management-client-content branch of the 
management resource tree. Where we currently store rollout plans. That 
stuff doesn't get persisted to the xml config (because it isn't part of 
the server side configuration) but it does get stored in the content repo.

OTOH I think using server-side *system properties* to store client side 
values has a really bad smell.

A bit more below...

On 12/4/13 8:26 AM, Alexey Loubyansky wrote:
>
> On 12/04/2013 03:15 PM, ssilvert at redhat.com wrote:
>> On 12/4/2013 7:41 AM, Alexey Loubyansky wrote:
>>> I haven't thought about that scope. But anyway, if it proves useful
>>> it's doable.
>> The use case I had in mind was for if I want to share a script that runs
>> against servers or domain controllers on the network.  As it is, I would
>> have to tell the other person how to set all their variables.  Giving
>> the other person my .jbossclirc file is not a good idea because it also
>> contains variable values that only pertain to my local environment.
>
> Variables can also be set in the beginning of a script. Although, I can
> see advantages of keeping them out and simply relying on certain
> variables in a script.
>
>> It's the same concept as Maven's settings.xml file for local properties
>> vs. the "shared" properties set in pom.xml.
>>
>> It might be that all you need is to simply allow a variable to refer to
>> system properties on the server.  That would be your shared variable.
>>
>> The $prod_db example you gave earlier would be a good candidate for a
>> shared variable.  So someone sets the property with:
>> /system-property=prod_db/:add(value=mydatabase)
>>
>> Then anyone could use the $prod_db variable against that server no
>> matter where the command runs from.
>
> That is indeed useful. BTW, don't we have aliases in the management
> model that could also be used for this?
>

Management model aliases are static. They are used to provide backwards 
compatibility when we rename a resource or attribute.

> Alexey
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat

From ssilvert at redhat.com  Wed Dec  4 10:03:43 2013
From: ssilvert at redhat.com (ssilvert at redhat.com)
Date: Wed, 04 Dec 2013 10:03:43 -0500
Subject: [wildfly-dev] cli variables
In-Reply-To: <529F3B94.6000301@redhat.com>
References: <529C94B7.1020802@redhat.com> <529DEA60.1010202@redhat.com>
	<AB8DDBD4-568E-48B2-AAC6-55F0AC81658F@redhat.com>
	<529F230B.50302@redhat.com> <529F3909.8000009@redhat.com>
	<529F3B94.6000301@redhat.com>
Message-ID: <529F444F.5060607@redhat.com>

On 12/4/2013 9:26 AM, Alexey Loubyansky wrote:
>
> On 12/04/2013 03:15 PM, ssilvert at redhat.com wrote:
>> On 12/4/2013 7:41 AM, Alexey Loubyansky wrote:
>>> I haven't thought about that scope. But anyway, if it proves useful
>>> it's doable.
>> The use case I had in mind was for if I want to share a script that runs
>> against servers or domain controllers on the network.  As it is, I would
>> have to tell the other person how to set all their variables.  Giving
>> the other person my .jbossclirc file is not a good idea because it also
>> contains variable values that only pertain to my local environment.
>
> Variables can also be set in the beginning of a script.
But then you can't reuse the same script against multiple servers.  Each
server might need a different value for the variable.

> Although, I can see advantages of keeping them out and simply relying
> on certain variables in a script.
>
>> It's the same concept as Maven's settings.xml file for local properties
>> vs. the "shared" properties set in pom.xml.
>>
>> It might be that all you need is to simply allow a variable to refer to
>> system properties on the server.  That would be your shared variable.
>>
>> The $prod_db example you gave earlier would be a good candidate for a
>> shared variable.  So someone sets the property with:
>> /system-property=prod_db/:add(value=mydatabase)
>>
>> Then anyone could use the $prod_db variable against that server no
>> matter where the command runs from.
>
> That is indeed useful. BTW, don't we have aliases in the management
> model that could also be used for this?
>
> Alexey


From ssilvert at redhat.com  Wed Dec  4 10:05:08 2013
From: ssilvert at redhat.com (ssilvert at redhat.com)
Date: Wed, 04 Dec 2013 10:05:08 -0500
Subject: [wildfly-dev] cli variables
In-Reply-To: <529F3FA2.5090004@redhat.com>
References: <529C94B7.1020802@redhat.com>
	<529DEA60.1010202@redhat.com>	<AB8DDBD4-568E-48B2-AAC6-55F0AC81658F@redhat.com>	<529F230B.50302@redhat.com>
	<529F3909.8000009@redhat.com> <529F3B94.6000301@redhat.com>
	<529F3FA2.5090004@redhat.com>
Message-ID: <529F44A4.9050007@redhat.com>

On 12/4/2013 9:43 AM, Brian Stansberry wrote:
> OTOH I think using server-side *system properties* to store client side 
> values has a really bad smell.
I agree it seems to smell but I can't figure out exactly why.  The
alternative would be to create a second group of properties called
"client properties" or "cli properties".
>
> A bit more below...
>
> On 12/4/13 8:26 AM, Alexey Loubyansky wrote:
>> On 12/04/2013 03:15 PM, ssilvert at redhat.com wrote:
>>> On 12/4/2013 7:41 AM, Alexey Loubyansky wrote:
>>>> I haven't thought about that scope. But anyway, if it proves useful
>>>> it's doable.
>>> The use case I had in mind was for if I want to share a script that runs
>>> against servers or domain controllers on the network.  As it is, I would
>>> have to tell the other person how to set all their variables.  Giving
>>> the other person my .jbossclirc file is not a good idea because it also
>>> contains variable values that only pertain to my local environment.
>> Variables can also be set in the beginning of a script. Although, I can
>> see advantages of keeping them out and simply relying on certain
>> variables in a script.
>>
>>> It's the same concept as Maven's settings.xml file for local properties
>>> vs. the "shared" properties set in pom.xml.
>>>
>>> It might be that all you need is to simply allow a variable to refer to
>>> system properties on the server.  That would be your shared variable.
>>>
>>> The $prod_db example you gave earlier would be a good candidate for a
>>> shared variable.  So someone sets the property with:
>>> /system-property=prod_db/:add(value=mydatabase)
>>>
>>> Then anyone could use the $prod_db variable against that server no
>>> matter where the command runs from.
>> That is indeed useful. BTW, don't we have aliases in the management
>> model that could also be used for this?
>>
> Management model aliases are static. They are used to provide backwards 
> compatibility when we rename a resource or attribute.
>
>> Alexey
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>


From ssilvert at redhat.com  Wed Dec  4 10:18:45 2013
From: ssilvert at redhat.com (ssilvert at redhat.com)
Date: Wed, 04 Dec 2013 10:18:45 -0500
Subject: [wildfly-dev] cli variables
In-Reply-To: <529F44A4.9050007@redhat.com>
References: <529C94B7.1020802@redhat.com>
	<529DEA60.1010202@redhat.com>	<AB8DDBD4-568E-48B2-AAC6-55F0AC81658F@redhat.com>	<529F230B.50302@redhat.com>
	<529F3909.8000009@redhat.com> <529F3B94.6000301@redhat.com>
	<529F3FA2.5090004@redhat.com> <529F44A4.9050007@redhat.com>
Message-ID: <529F47D5.9010208@redhat.com>

Or how about a new command that sets a variable based on a
read-attribute operation?  I think this would satisfy the use case.

[standalone at localhost:9990 /] set_from_read $prod_db=/some/path/:read-attribute(name=mydbvalue)


On 12/4/2013 10:05 AM, ssilvert at redhat.com wrote:
> On 12/4/2013 9:43 AM, Brian Stansberry wrote:
>> OTOH I think using server-side *system properties* to store client side 
>> values has a really bad smell.
> I agree it seems to smell but I can't figure out exactly why.  The
> alternative would be to create a second group of properties called
> "client properties" or "cli properties".
>> A bit more below...
>>
>> On 12/4/13 8:26 AM, Alexey Loubyansky wrote:
>>> On 12/04/2013 03:15 PM, ssilvert at redhat.com wrote:
>>>> On 12/4/2013 7:41 AM, Alexey Loubyansky wrote:
>>>>> I haven't thought about that scope. But anyway, if it proves useful
>>>>> it's doable.
>>>> The use case I had in mind was for if I want to share a script that runs
>>>> against servers or domain controllers on the network.  As it is, I would
>>>> have to tell the other person how to set all their variables.  Giving
>>>> the other person my .jbossclirc file is not a good idea because it also
>>>> contains variable values that only pertain to my local environment.
>>> Variables can also be set in the beginning of a script. Although, I can
>>> see advantages of keeping them out and simply relying on certain
>>> variables in a script.
>>>
>>>> It's the same concept as Maven's settings.xml file for local properties
>>>> vs. the "shared" properties set in pom.xml.
>>>>
>>>> It might be that all you need is to simply allow a variable to refer to
>>>> system properties on the server.  That would be your shared variable.
>>>>
>>>> The $prod_db example you gave earlier would be a good candidate for a
>>>> shared variable.  So someone sets the property with:
>>>> /system-property=prod_db/:add(value=mydatabase)
>>>>
>>>> Then anyone could use the $prod_db variable against that server no
>>>> matter where the command runs from.
>>> That is indeed useful. BTW, don't we have aliases in the management
>>> model that could also be used for this?
>>>
>> Management model aliases are static. They are used to provide backwards 
>> compatibility when we rename a resource or attribute.
>>
>>> Alexey
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From alexey.loubyansky at redhat.com  Wed Dec  4 10:35:59 2013
From: alexey.loubyansky at redhat.com (Alexey Loubyansky)
Date: Wed, 04 Dec 2013 16:35:59 +0100
Subject: [wildfly-dev] cli variables
In-Reply-To: <529F47D5.9010208@redhat.com>
References: <529C94B7.1020802@redhat.com>	<529DEA60.1010202@redhat.com>	<AB8DDBD4-568E-48B2-AAC6-55F0AC81658F@redhat.com>	<529F230B.50302@redhat.com>	<529F3909.8000009@redhat.com>
	<529F3B94.6000301@redhat.com>	<529F3FA2.5090004@redhat.com>
	<529F44A4.9050007@redhat.com> <529F47D5.9010208@redhat.com>
Message-ID: <529F4BDF.9020903@redhat.com>

That's an interesting idea. I'm gonna think about implementing it.

Then there could also be a (standard path) resource that could be read 
by the management tools to initialize the environment variables from its 
attributes.

On 12/04/2013 04:18 PM, ssilvert at redhat.com wrote:
> Or how about a new command that sets a variable based on a
> read-attribute operation?  I think this would satisfy the use case.
>
> [standalone at localhost:9990 /] set_from_read $prod_db=/some/path/:read-attribute(name=mydbvalue)
>
>
> On 12/4/2013 10:05 AM, ssilvert at redhat.com wrote:
>> On 12/4/2013 9:43 AM, Brian Stansberry wrote:
>>> OTOH I think using server-side *system properties* to store client side
>>> values has a really bad smell.
>> I agree it seems to smell but I can't figure out exactly why.  The
>> alternative would be to create a second group of properties called
>> "client properties" or "cli properties".
>>> A bit more below...
>>>
>>> On 12/4/13 8:26 AM, Alexey Loubyansky wrote:
>>>> On 12/04/2013 03:15 PM, ssilvert at redhat.com wrote:
>>>>> On 12/4/2013 7:41 AM, Alexey Loubyansky wrote:
>>>>>> I haven't thought about that scope. But anyway, if it proves useful
>>>>>> it's doable.
>>>>> The use case I had in mind was for if I want to share a script that runs
>>>>> against servers or domain controllers on the network.  As it is, I would
>>>>> have to tell the other person how to set all their variables.  Giving
>>>>> the other person my .jbossclirc file is not a good idea because it also
>>>>> contains variable values that only pertain to my local environment.
>>>> Variables can also be set in the beginning of a script. Although, I can
>>>> see advantages of keeping them out and simply relying on certain
>>>> variables in a script.
>>>>
>>>>> It's the same concept as Maven's settings.xml file for local properties
>>>>> vs. the "shared" properties set in pom.xml.
>>>>>
>>>>> It might be that all you need is to simply allow a variable to refer to
>>>>> system properties on the server.  That would be your shared variable.
>>>>>
>>>>> The $prod_db example you gave earlier would be a good candidate for a
>>>>> shared variable.  So someone sets the property with:
>>>>> /system-property=prod_db/:add(value=mydatabase)
>>>>>
>>>>> Then anyone could use the $prod_db variable against that server no
>>>>> matter where the command runs from.
>>>> That is indeed useful. BTW, don't we have aliases in the management
>>>> model that could also be used for this?
>>>>
>>> Management model aliases are static. They are used to provide backwards
>>> compatibility when we rename a resource or attribute.
>>>
>>>> Alexey
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From alexey.loubyansky at redhat.com  Thu Dec  5 06:37:09 2013
From: alexey.loubyansky at redhat.com (Alexey Loubyansky)
Date: Thu, 05 Dec 2013 12:37:09 +0100
Subject: [wildfly-dev] [jboss-as7-dev] cli variables
In-Reply-To: <52A036F4.6090303@redhat.com>
References: <529C93FC.5050407@redhat.com>	<1478660.jOllsIsUWy@logrus.brq.redhat.com>
	<52A036F4.6090303@redhat.com>
Message-ID: <52A06565.3070008@redhat.com>

On 12/05/2013 09:19 AM, Dimitris Andreadis wrote:
> +1 on Hynek's comments, especially the echo $var

I've changed echo to assume $.

> I'm not sure also if those should be equivalent:
>
> set var=
> unset var
>
> to cover the case where you need var to be an empty string, rather than completely unset. I
> think it works as you propose on Windoze shells, but not on Unix shells?

I was not sure about it myself actually, which is why I mentioned it. It 
might make sense make the difference.

Alexey

>
> On 02/12/2013 15:26, Hynek Mlnarik wrote:
>> Hi,
>>
>> thanks for the effort, this feature will be very helpful indeed!
>>
>> Overall I like your approach, yet in case of "echo" command I'd prefer mandatory use of $
>> character before variable name, i.e. to use:
>>
>> [standalone at localhost:9990 /] echo $prod_db
>>
>> instead of proposed:
>>
>> [standalone at localhost:9990 /] echo prod_db
>>
>> In other words, to apply the same substitution rules to "echo" parameters as to the rest of
>> use cases where variable value is read. This would also be more consistent with shell
>> standards, hence will be easily grabbed by administrators.
>>
>> Further, do you plan recursive substitution evaluation? E.g. something like this:
>>
>> [standalone at localhost:9990 /] set
>> prod_db_pgsqlDS=/subsystem=datasources/data-source=ExampleDSPgSQL
>>
>> [standalone at localhost:9990 /] set
>> prod_db_mysqlDS=/subsystem=datasources/data-source=ExampleDSMySQL
>>
>> [standalone at localhost:9990 /] set ds=pgsqlDS
>>
>> [standalone at localhost:9990 /] echo ${prod_db_$ds}
>>
>> /subsystem=datasources/data-source=ExampleDSPgSQL
>>
>> --Hynek
>>
>> On Mon December 2 2013 15:06:52 Alexey Loubyansky wrote:
>>
>>   > There is this issue to provide CLI preferences
>>
>>   > https://issues.jboss.org/browse/WFLY-1063. Here I'd like to address
>>
>>   > mainly this part
>>
>>   >
>>
>>   > "prod-db = /subsystem=jadada/database=jadada/
>>
>>   > so you could call prod-db:read-resource"
>>
>>   >
>>
>>   > I'd like to get some opinion on the way it's gonna be implemented (and
>>
>>   > what I've done so far on a local branch).
>>
>>   >
>>
>>   > So, to address that I introduced variables. A variable starts with a $,
>>
>>   > e.g. $prod_db. (Using simply prod_db is not a good idea since it might
>>
>>   > conflict with actual parts of the paths, names, etc)
>>
>>   >
>>
>>   > Variables can be introduced with
>>
>>   >
>>
>>   > [disconnected /] set prod_db=/subsystem=datasources/data-source=ExampleDS
>>
>>   >
>>
>>   > Read with
>>
>>   >
>>
>>   > [standalone at localhost:9990 /] echo prod_db
>>
>>   > /subsystem=datasources/data-source=ExampleDS
>>
>>   >
>>
>>   > And unset with
>>
>>   >
>>
>>   > [standalone at localhost:9990 /] unset prod_db
>>
>>   >
>>
>>   > 'echo' without parameters will list all the variables and their values,
>>
>>   > 'set prod_db=' will have the same effect as 'unset prod_db',
>>
>>   > set/echo/unset will work with and w/o '$' prefix, tab-completion works
>>
>>   > everywhere.
>>
>>   >
>>
>>   > The variables may appear in:
>>
>>   >
>>
>>   > - operation request addresses, e.g. $prod_db/statistics=jdbc:read-resource;
>>
>>   > - operation names, e.g. $prod_db:$op(include-runtime=true);
>>
>>   > - operation parameter names and values, e.g.
>>
>>   > $prod_db:$op($param=$param_value);
>>
>>   > - the same for commands.
>>
>>   >
>>
>>   > Tab-completion helps complete the names as long as you type in '$' and
>>
>>   > then the rest of the line after the variable as usual.
>>
>>   >
>>
>>   > Variables added during the session are not persisted anywhere. But I've
>>
>>   > added .jbossclirc file. This file can be located in the current
>>
>>   > directory, wildfly home bin directory or specified with a system
>>
>>   > property. The content of the file is usual CLI commands and/or
>>
>>   > operations. So, the variables could be initialized there. This file, if
>>
>>   > located, will be executed before the CLI session (interactive or not)
>>
>>   > starts (but also after the system properties specified with --properties
>>
>>   > are set).
>>
>>   >
>>
>>   > As a side effect, '$' is now a special character and will have to be
>>
>>   > escaped. Otherwise the CLI might complain about an unresolved variable.
>>
>>   > So, this could potentially cause problems for existing scripts using $.
>>
>>   >
>>
>>   > Note, most of this replacement stuff can already be done with system
>>
>>   > properties using ${xxx} format (and btw scripts using '$' as in '${xxx}'
>>
>>   > won't be affected, of course).
>>
>>   >
>>
>>   > And for now I've made variable names follow the rules for Java identifiers.
>>
>>   >
>>
>>   > Any remarks, objections or suggestions?
>>
>>   >
>>
>>   > Thanks,
>>
>>   > Alexey
>>
>>   > _______________________________________________
>>
>>   > 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
>>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>

From ozizka at redhat.com  Thu Dec  5 18:48:45 2013
From: ozizka at redhat.com (Ondrej Zizka)
Date: Fri, 06 Dec 2013 00:48:45 +0100
Subject: [wildfly-dev] PR-5551/5552 - version-base.txt
In-Reply-To: <529C793C.5060201@redhat.com>
References: <529C793C.5060201@redhat.com>
Message-ID: <52A110DD.2010809@redhat.com>

Added Paul Gier and Aslak to CC - could you guys please share your opinions.
Let's discuss this before we get to some code freeze and it's late / no 
time to solve this.

Is the arrangement (described in the jira comments) a viable way to 
statically identify (without launching) a server / product / layers added?

Thanks,
Ondra


On 2.12.2013 13:12, Ondrej Zizka wrote:
> Hi all,
>
> there's a request for something for static identification of the server
> in a directory. This comes from JBDS and prehaps other tools (installer,
> upgrader, ...)
> The jira is https://issues.jboss.org/browse/WFLY-2426
>
> The discussion on that jira staled, so I created these
> https://github.com/wildfly/wildfly/pull/5551
> https://github.com/wildfly/wildfly/pull/5552
> (It's the same thing done in 2 ways.)
>
> I suggest to keep the discussion in that jira WFLY-2426 .
> Is this solution (as described there) acceptable? Even for layered
> stuff? Max + Rob in the CC.
>
> Thanks,
> Ondra
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From arun.gupta at gmail.com  Thu Dec  5 20:34:33 2013
From: arun.gupta at gmail.com (Arun Gupta)
Date: Thu, 5 Dec 2013 17:34:33 -0800
Subject: [wildfly-dev] WebSocket sendObject vs sendText
Message-ID: <CAGBoHQVs2tbPX54_HJiWTprX2cLh27Egd9hcp9z-+qsu1ZGQmQ@mail.gmail.com>

The WebSocket Chat sample was not working on WildFly, until now.

I figured out that getBasicRemote().sendObject(...) was used to send a
String to all the connected clients. The code in @OnMessage looked
like:

        for (Session peer : client.getOpenSessions()) {
            peer.getBasicRemote().sendText(message);
        }


I changed sendObject to sendText(...) and now its working. What is
causing this to break ?

Arun

-- 
http://blog.arungupta.me
http://twitter.com/arungupta

From ozizka at redhat.com  Fri Dec  6 13:35:30 2013
From: ozizka at redhat.com (Ondrej Zizka)
Date: Fri, 06 Dec 2013 19:35:30 +0100
Subject: [wildfly-dev] WFLY-2426 Easily accessible static information
 describing the release /// Fwd: Re: PR-5551/5552 - version-base.txt
In-Reply-To: <52A110DD.2010809@redhat.com>
References: <52A110DD.2010809@redhat.com>
Message-ID: <52A218F2.6080109@redhat.com>

Hi Max, Rob,

few questions for the requirements.

  * Does the underlying software need to be identified? I.e. if it's
    SOA, should the file also say it's EAP for the tools which do not
    know SOA? E.g.
      o software.base = EAP
      o software.layer = SOA
      o software.name = JBoss SOA-Platform
  * Should a timestamp be included? E.g. to differentiate between
    release candidates which all have ".GA"
  * Do you care about the format - as long it's well-known documented
    standard? I'm considering either .properties or .xml. ISO/IEC
    19770-2 was suggested but that seems to be overkill and doesn't even
    match our needs.
  * What everything do you expect to be in the file? SW identification
    and version but:
      o ID vs. name - do you want just "eap" or do you expect to have
        something to present to the user directly, i.e. some "JBoss
        Enterprise Application Platform" ?
      o AS vs. EAP - do you need the boolean info whether it is a
        supported product?

That's all for now,
looking forward to getting your reply.
Ondra



-------- Original Message --------
Subject: 	Re: [wildfly-dev] PR-5551/5552 - version-base.txt
Date: 	Fri, 06 Dec 2013 00:48:45 +0100
From: 	Ondrej Zizka <ozizka at redhat.com>
To: 	wildfly-dev at lists.jboss.org <wildfly-dev at lists.jboss.org>, Max 
Rydahl Andersen <manderse at redhat.com>, Rob Stryker 
<rstryker at redhat.com>, Paul Gier <pgier at redhat.com>, Knutsen, Aslak 
<aknutsen at redhat.com>



Added Paul Gier and Aslak to CC - could you guys please share your opinions.
Let's discuss this before we get to some code freeze and it's late / no
time to solve this.

Is the arrangement (described in the jira comments) a viable way to
statically identify (without launching) a server / product / layers added?

Thanks,
Ondra


On 2.12.2013 13:12, Ondrej Zizka wrote:
> Hi all,
>
> there's a request for something for static identification of the server
> in a directory. This comes from JBDS and prehaps other tools (installer,
> upgrader, ...)
> The jira is https://issues.jboss.org/browse/WFLY-2426
>
> The discussion on that jira staled, so I created these
> https://github.com/wildfly/wildfly/pull/5551
> https://github.com/wildfly/wildfly/pull/5552
> (It's the same thing done in 2 ways.)
>
> I suggest to keep the discussion in that jira WFLY-2426 .
> Is this solution (as described there) acceptable? Even for layered
> stuff? Max + Rob in the CC.
>
> Thanks,
> Ondra
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
wildfly-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131206/a5d0201f/attachment.html 

From rachmato at redhat.com  Mon Dec  9 14:45:50 2013
From: rachmato at redhat.com (Richard Achmatowicz)
Date: Mon, 09 Dec 2013 14:45:50 -0500
Subject: [wildfly-dev] Establishing deployment processor service dependencies
Message-ID: <52A61DEE.8020200@redhat.com>

Hi

Quick question on establishing service dependencies for deployment unit 
processors:

I have a deployment unit processor DUP1 for a subsystem, which runs in 
the INSTALL phase and depends on a service X. Although X is installed 
elsewhere, I want to make sure that X is started before the DUP ever 
executes as it requires that service for correct operation.

Is it the case that the only way to establish this dependency is to:
- create a new deployment unit processor DUP2 which runs in the phase 
immediately preceding INSTALL ( which is POST_MODULE)
- use DUP2 to add the dependency to the DeploymentPhaseContext via

phaseContext.addToAttachmentList(Attachments.NEXT_PHASE_DEPS, X);

Just want to confirm that this is the only way to establish this dependency.

Richard

From arun.gupta at gmail.com  Mon Dec  9 17:33:31 2013
From: arun.gupta at gmail.com (Arun Gupta)
Date: Mon, 9 Dec 2013 14:33:31 -0800
Subject: [wildfly-dev] h:fileUpload is not invoking setter
Message-ID: <CAGBoHQWDAWMbb+OLhzuZK3bZWHwmtci_rd02d+tMoyODw+Z+5g@mail.gmail.com>

https://github.com/javaee-samples/javaee7-samples/tree/master/jsf/file-upload
is a simple sample that demonstrate the usage of newly added
h:fileUpload component. The usage is pretty straightforward:

<h:form enctype="multipart/form-data">
            <h:inputFile value="#{fileUploadBean.file}"/><br/>

            <h:commandButton value="Upload"/><p/>

            <h2>File Contents:</h2>
            <h:outputText value="#{fileUploadBean.text}"/>
        </h:form>


However clicking on the button does not invoke the setFile method on
the corresponding bean:

public void setFile(Part file) {
....
}

Any suggestions ?

Arun

-- 
http://blog.arungupta.me
http://twitter.com/arungupta

From arun.gupta at gmail.com  Mon Dec  9 18:11:53 2013
From: arun.gupta at gmail.com (Arun Gupta)
Date: Mon, 9 Dec 2013 15:11:53 -0800
Subject: [wildfly-dev] h:fileUpload is not invoking setter
In-Reply-To: <CAGBoHQWDAWMbb+OLhzuZK3bZWHwmtci_rd02d+tMoyODw+Z+5g@mail.gmail.com>
References: <CAGBoHQWDAWMbb+OLhzuZK3bZWHwmtci_rd02d+tMoyODw+Z+5g@mail.gmail.com>
Message-ID: <CAGBoHQURXzq5yRx-m3gzS+JXX80-ONfvRv8H6mT4bNXxjbR2ew@mail.gmail.com>

Seems like a known issue: https://issues.jboss.org/browse/WFLY-2329

Arun

On Mon, Dec 9, 2013 at 2:33 PM, Arun Gupta <arun.gupta at gmail.com> wrote:
> https://github.com/javaee-samples/javaee7-samples/tree/master/jsf/file-upload
> is a simple sample that demonstrate the usage of newly added
> h:fileUpload component. The usage is pretty straightforward:
>
> <h:form enctype="multipart/form-data">
>             <h:inputFile value="#{fileUploadBean.file}"/><br/>
>
>             <h:commandButton value="Upload"/><p/>
>
>             <h2>File Contents:</h2>
>             <h:outputText value="#{fileUploadBean.text}"/>
>         </h:form>
>
>
> However clicking on the button does not invoke the setFile method on
> the corresponding bean:
>
> public void setFile(Part file) {
> ....
> }
>
> Any suggestions ?
>
> Arun
>
> --
> http://blog.arungupta.me
> http://twitter.com/arungupta



-- 
http://blog.arungupta.me
http://twitter.com/arungupta

From ozizka at redhat.com  Tue Dec 10 01:17:30 2013
From: ozizka at redhat.com (Ondrej Zizka)
Date: Tue, 10 Dec 2013 07:17:30 +0100
Subject: [wildfly-dev] Wildfly dir structure - to which extent is it
 guaranteed to stay as is now?
Message-ID: <52A6B1FA.5090406@redhat.com>

Hi,

WRT WFLY-2426 again:

Will modules dir structure stay as is for a long term? Talking about 
major versions of EAP?

Recently I asked what's guaranteed to stay, and the reply was, "the 
management API and the scripts in bin/"
Which implicitely tells me that modules/ is not a thing to rely on.

Could someone please verify that?

Thanks,
Ondra

PS: We could simply put file-per-layer right into the root dir but 
releng and others will frown...


From ssilvert at redhat.com  Tue Dec 10 08:17:00 2013
From: ssilvert at redhat.com (ssilvert at redhat.com)
Date: Tue, 10 Dec 2013 08:17:00 -0500
Subject: [wildfly-dev] Push for CORS in WildFly 8
Message-ID: <52A7144C.4050501@redhat.com>

Re: https://issues.jboss.org/browse/WFLY-1014

I'd like to request that we take a harder look at getting WFLY-1014
done.  This feature allows CORS requests into the HTTP management endpoint.

This would solve two problems:
1) The web console must ship with WildFly and must be downloaded from
the WildFly instance it is talking to.
2) No other console is allowed to use the HTTP management endpoint.  So,
a layered product's console can not control its own subsystem.

Herald gives a nice overview of what this would mean for the Web Console:
http://hpehl.info/independent-jboss-admin-console.html

It would be very beneficial for other products as well.  Can we get this
done?

Stan

From hpehl at redhat.com  Tue Dec 10 08:20:36 2013
From: hpehl at redhat.com (Harald Pehl)
Date: Tue, 10 Dec 2013 14:20:36 +0100
Subject: [wildfly-dev] Push for CORS in WildFly 8
In-Reply-To: <52A7144C.4050501@redhat.com>
References: <52A7144C.4050501@redhat.com>
Message-ID: <2287FC58-2378-42D0-A4DB-802998351E44@redhat.com>

+1 for getting this done. 

.: Harald


Am 10.12.2013 um 14:17 schrieb ssilvert at redhat.com:

> Re: https://issues.jboss.org/browse/WFLY-1014
> 
> I'd like to request that we take a harder look at getting WFLY-1014
> done.  This feature allows CORS requests into the HTTP management endpoint.
> 
> This would solve two problems:
> 1) The web console must ship with WildFly and must be downloaded from
> the WildFly instance it is talking to.
> 2) No other console is allowed to use the HTTP management endpoint.  So,
> a layered product's console can not control its own subsystem.
> 
> Herald gives a nice overview of what this would mean for the Web Console:
> http://hpehl.info/independent-jboss-admin-console.html
> 
> It would be very beneficial for other products as well.  Can we get this
> done?
> 
> Stan

---
Harald Pehl
JBoss by Red Hat
http://hpehl.info

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131210/b002d649/attachment-0001.bin 

From david.lloyd at redhat.com  Tue Dec 10 09:14:35 2013
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Tue, 10 Dec 2013 08:14:35 -0600
Subject: [wildfly-dev] Wildfly dir structure - to which extent is it
 guaranteed to stay as is now?
In-Reply-To: <52A6B1FA.5090406@redhat.com>
References: <52A6B1FA.5090406@redhat.com>
Message-ID: <52A721CB.6040808@redhat.com>

On 12/10/2013 12:17 AM, Ondrej Zizka wrote:
> Hi,
>
> WRT WFLY-2426 again:
>
> Will modules dir structure stay as is for a long term? Talking about
> major versions of EAP?
>
> Recently I asked what's guaranteed to stay, and the reply was, "the
> management API and the scripts in bin/"
> Which implicitely tells me that modules/ is not a thing to rely on.
>
> Could someone please verify that?
>
> Thanks,
> Ondra
>
> PS: We could simply put file-per-layer right into the root dir but
> releng and others will frown...

The modules directory structure may change (or go away) in any major 
release of WildFly.

-- 
- DML

From darran.lofthouse at jboss.com  Tue Dec 10 09:35:20 2013
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Tue, 10 Dec 2013 14:35:20 +0000
Subject: [wildfly-dev] Push for CORS in WildFly 8
In-Reply-To: <52A7144C.4050501@redhat.com>
References: <52A7144C.4050501@redhat.com>
Message-ID: <52A726A8.3010300@jboss.com>

To get this implemented the first thing we need is some detailed 
analysis of how the Host and Origin headers will be used by different 
browsers for the different distribution approaches we will take for the 
different consoles.

We will need to take into account how this could be affected by proxies 
/ firewalls etc...

Considering the different distribution approaches we will need to 
consider implications for malicious consoles / web pages etc possibly 
from the same source and any options to mitigate this.

But then overall it should be a case of configuration to allow a 
relaxation of the Host / Origin match with acceptable values.

Regards,
Darran Lofthouse.


On 10/12/13 13:17, ssilvert at redhat.com wrote:
> Re: https://issues.jboss.org/browse/WFLY-1014
>
> I'd like to request that we take a harder look at getting WFLY-1014
> done.  This feature allows CORS requests into the HTTP management endpoint.
>
> This would solve two problems:
> 1) The web console must ship with WildFly and must be downloaded from
> the WildFly instance it is talking to.
> 2) No other console is allowed to use the HTTP management endpoint.  So,
> a layered product's console can not control its own subsystem.
>
> Herald gives a nice overview of what this would mean for the Web Console:
> http://hpehl.info/independent-jboss-admin-console.html
>
> It would be very beneficial for other products as well.  Can we get this
> done?
>
> Stan
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From ssilvert at redhat.com  Tue Dec 10 10:58:24 2013
From: ssilvert at redhat.com (ssilvert at redhat.com)
Date: Tue, 10 Dec 2013 10:58:24 -0500
Subject: [wildfly-dev] Push for CORS in WildFly 8
In-Reply-To: <52A726A8.3010300@jboss.com>
References: <52A7144C.4050501@redhat.com> <52A726A8.3010300@jboss.com>
Message-ID: <52A73A20.3020906@redhat.com>

On 12/10/2013 9:35 AM, Darran Lofthouse wrote:
> To get this implemented the first thing we need is some detailed
> analysis of how the Host and Origin headers will be used by different
> browsers for the different distribution approaches we will take for
> the different consoles.
>
> We will need to take into account how this could be affected by
> proxies / firewalls etc...
>
> Considering the different distribution approaches we will need to
> consider implications for malicious consoles / web pages etc possibly
> from the same source and any options to mitigate this.
>
> But then overall it should be a case of configuration to allow a
> relaxation of the Host / Origin match with acceptable values.
Let's do this last part first.  It's not much effort to enable CORS. 
Here is Herald's commit:
https://github.com/hpehl/wildfly/commit/89af5ba711502005275411820b8198f69e36269b

If we put this into WildFly 8 (disabled by default), it would allow us
to start working with it and better perform the analysis suggested by
Darran.

I propose that Herald update his commit to work with the latest code and
we go ahead and get that in.  Any objections?

>
> Regards,
> Darran Lofthouse.
>
>
> On 10/12/13 13:17, ssilvert at redhat.com wrote:
>> Re: https://issues.jboss.org/browse/WFLY-1014
>>
>> I'd like to request that we take a harder look at getting WFLY-1014
>> done.  This feature allows CORS requests into the HTTP management
>> endpoint.
>>
>> This would solve two problems:
>> 1) The web console must ship with WildFly and must be downloaded from
>> the WildFly instance it is talking to.
>> 2) No other console is allowed to use the HTTP management endpoint.  So,
>> a layered product's console can not control its own subsystem.
>>
>> Herald gives a nice overview of what this would mean for the Web
>> Console:
>> http://hpehl.info/independent-jboss-admin-console.html
>>
>> It would be very beneficial for other products as well.  Can we get this
>> done?
>>
>> Stan
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>


From ssilvert at redhat.com  Tue Dec 10 11:53:55 2013
From: ssilvert at redhat.com (ssilvert at redhat.com)
Date: Tue, 10 Dec 2013 11:53:55 -0500
Subject: [wildfly-dev] Push for CORS in WildFly 8
In-Reply-To: <52A740A3.6040009@jboss.com>
References: <52A7144C.4050501@redhat.com> <52A726A8.3010300@jboss.com>
	<52A73A20.3020906@redhat.com> <52A740A3.6040009@jboss.com>
Message-ID: <52A74723.4040905@redhat.com>

On 12/10/2013 11:26 AM, Darran Lofthouse wrote:
> I am not sure if I am missing something, are you proposing that we
> stop the rejection of requests that have a different origin?
Not by default.  Just as an option so that we can start working with
CORS on the front end.
>
> On 10/12/13 15:58, ssilvert at redhat.com wrote:
>> On 12/10/2013 9:35 AM, Darran Lofthouse wrote:
>>> To get this implemented the first thing we need is some detailed
>>> analysis of how the Host and Origin headers will be used by different
>>> browsers for the different distribution approaches we will take for
>>> the different consoles.
>>>
>>> We will need to take into account how this could be affected by
>>> proxies / firewalls etc...
>>>
>>> Considering the different distribution approaches we will need to
>>> consider implications for malicious consoles / web pages etc possibly
>>> from the same source and any options to mitigate this.
>>>
>>> But then overall it should be a case of configuration to allow a
>>> relaxation of the Host / Origin match with acceptable values.
>> Let's do this last part first.  It's not much effort to enable CORS.
>> Here is Herald's commit:
>> https://github.com/hpehl/wildfly/commit/89af5ba711502005275411820b8198f69e36269b
>>
>>
>> If we put this into WildFly 8 (disabled by default), it would allow us
>> to start working with it and better perform the analysis suggested by
>> Darran.
>>
>> I propose that Herald update his commit to work with the latest code and
>> we go ahead and get that in.  Any objections?
>>
>>>
>>> Regards,
>>> Darran Lofthouse.
>>>
>>>
>>> On 10/12/13 13:17, ssilvert at redhat.com wrote:
>>>> Re: https://issues.jboss.org/browse/WFLY-1014
>>>>
>>>> I'd like to request that we take a harder look at getting WFLY-1014
>>>> done.  This feature allows CORS requests into the HTTP management
>>>> endpoint.
>>>>
>>>> This would solve two problems:
>>>> 1) The web console must ship with WildFly and must be downloaded from
>>>> the WildFly instance it is talking to.
>>>> 2) No other console is allowed to use the HTTP management
>>>> endpoint.  So,
>>>> a layered product's console can not control its own subsystem.
>>>>
>>>> Herald gives a nice overview of what this would mean for the Web
>>>> Console:
>>>> http://hpehl.info/independent-jboss-admin-console.html
>>>>
>>>> It would be very beneficial for other products as well.  Can we get
>>>> this
>>>> done?
>>>>
>>>> Stan
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>


From darran.lofthouse at jboss.com  Tue Dec 10 11:26:11 2013
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Tue, 10 Dec 2013 16:26:11 +0000
Subject: [wildfly-dev] Push for CORS in WildFly 8
In-Reply-To: <52A73A20.3020906@redhat.com>
References: <52A7144C.4050501@redhat.com> <52A726A8.3010300@jboss.com>
	<52A73A20.3020906@redhat.com>
Message-ID: <52A740A3.6040009@jboss.com>

I am not sure if I am missing something, are you proposing that we stop 
the rejection of requests that have a different origin?

On 10/12/13 15:58, ssilvert at redhat.com wrote:
> On 12/10/2013 9:35 AM, Darran Lofthouse wrote:
>> To get this implemented the first thing we need is some detailed
>> analysis of how the Host and Origin headers will be used by different
>> browsers for the different distribution approaches we will take for
>> the different consoles.
>>
>> We will need to take into account how this could be affected by
>> proxies / firewalls etc...
>>
>> Considering the different distribution approaches we will need to
>> consider implications for malicious consoles / web pages etc possibly
>> from the same source and any options to mitigate this.
>>
>> But then overall it should be a case of configuration to allow a
>> relaxation of the Host / Origin match with acceptable values.
> Let's do this last part first.  It's not much effort to enable CORS.
> Here is Herald's commit:
> https://github.com/hpehl/wildfly/commit/89af5ba711502005275411820b8198f69e36269b
>
> If we put this into WildFly 8 (disabled by default), it would allow us
> to start working with it and better perform the analysis suggested by
> Darran.
>
> I propose that Herald update his commit to work with the latest code and
> we go ahead and get that in.  Any objections?
>
>>
>> Regards,
>> Darran Lofthouse.
>>
>>
>> On 10/12/13 13:17, ssilvert at redhat.com wrote:
>>> Re: https://issues.jboss.org/browse/WFLY-1014
>>>
>>> I'd like to request that we take a harder look at getting WFLY-1014
>>> done.  This feature allows CORS requests into the HTTP management
>>> endpoint.
>>>
>>> This would solve two problems:
>>> 1) The web console must ship with WildFly and must be downloaded from
>>> the WildFly instance it is talking to.
>>> 2) No other console is allowed to use the HTTP management endpoint.  So,
>>> a layered product's console can not control its own subsystem.
>>>
>>> Herald gives a nice overview of what this would mean for the Web
>>> Console:
>>> http://hpehl.info/independent-jboss-admin-console.html
>>>
>>> It would be very beneficial for other products as well.  Can we get this
>>> done?
>>>
>>> Stan
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>

From hbraun at redhat.com  Tue Dec 10 12:35:59 2013
From: hbraun at redhat.com (Heiko Braun)
Date: Tue, 10 Dec 2013 18:35:59 +0100
Subject: [wildfly-dev] Push for CORS in WildFly 8
In-Reply-To: <52A7144C.4050501@redhat.com>
References: <52A7144C.4050501@redhat.com>
Message-ID: <0AD5D753-E5AD-4B86-A5E1-1DA317FD3ED5@redhat.com>

I dont understand your second point, but +1 for enabling cors. It would enable arbitrary use cases that rely on the http endpoint. 

But cors is onky one part if the story. The authentication mechanism would need to change as well, to allow for better integration.

Has anyone evaluated keycloak as an alternative for securing the http management endpoint? 

At a first glance it seems to solve many of the problems we've outlined before.




> Am 10.12.2013 um 14:17 schrieb ssilvert at redhat.com:
> 
> No other console is allowed to use the HTTP management endpoint.  So,
> a layered product's console can not control its own subsystem.


From darran.lofthouse at jboss.com  Tue Dec 10 12:33:09 2013
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Tue, 10 Dec 2013 17:33:09 +0000
Subject: [wildfly-dev] Push for CORS in WildFly 8
In-Reply-To: <52A74723.4040905@redhat.com>
References: <52A7144C.4050501@redhat.com> <52A726A8.3010300@jboss.com>
	<52A73A20.3020906@redhat.com> <52A740A3.6040009@jboss.com>
	<52A74723.4040905@redhat.com>
Message-ID: <52A75055.10408@jboss.com>

If we are going to support cross origin requests we need to do it 
properly, the current behaviour is there to solve a specific problem of 
the server being vulnerable to cross site scripting attacks - relaxing 
it without a complete solution is just going to re-introduce that 
vulnerability.

Based on the current commit there are two things we would really need to 
do: -
  1 - Instead of faking authentication move Options handling to it's own 
handler before authentication.
  2 - Proper support for configured alternative origins.

Maybe we can just get away with a configured list of alternative origins 
to allow through but without exploring the origins for the alternative 
distribution approaches we can not be sure that would not leave an 
alternative option for malicious calls.

At the moment I have not seen anything to suggest we need anything more 
dynamic but at this point I don't know if we have all the distribution 
approaches defined.

I will have a look at what we can do for the static config approach.

Regards,
Darran Lofthouse.

On 10/12/13 16:53, ssilvert at redhat.com wrote:
> On 12/10/2013 11:26 AM, Darran Lofthouse wrote:
>> I am not sure if I am missing something, are you proposing that we
>> stop the rejection of requests that have a different origin?
> Not by default.  Just as an option so that we can start working with
> CORS on the front end.
>>
>> On 10/12/13 15:58, ssilvert at redhat.com wrote:
>>> On 12/10/2013 9:35 AM, Darran Lofthouse wrote:
>>>> To get this implemented the first thing we need is some detailed
>>>> analysis of how the Host and Origin headers will be used by different
>>>> browsers for the different distribution approaches we will take for
>>>> the different consoles.
>>>>
>>>> We will need to take into account how this could be affected by
>>>> proxies / firewalls etc...
>>>>
>>>> Considering the different distribution approaches we will need to
>>>> consider implications for malicious consoles / web pages etc possibly
>>>> from the same source and any options to mitigate this.
>>>>
>>>> But then overall it should be a case of configuration to allow a
>>>> relaxation of the Host / Origin match with acceptable values.
>>> Let's do this last part first.  It's not much effort to enable CORS.
>>> Here is Herald's commit:
>>> https://github.com/hpehl/wildfly/commit/89af5ba711502005275411820b8198f69e36269b
>>>
>>>
>>> If we put this into WildFly 8 (disabled by default), it would allow us
>>> to start working with it and better perform the analysis suggested by
>>> Darran.
>>>
>>> I propose that Herald update his commit to work with the latest code and
>>> we go ahead and get that in.  Any objections?
>>>
>>>>
>>>> Regards,
>>>> Darran Lofthouse.
>>>>
>>>>
>>>> On 10/12/13 13:17, ssilvert at redhat.com wrote:
>>>>> Re: https://issues.jboss.org/browse/WFLY-1014
>>>>>
>>>>> I'd like to request that we take a harder look at getting WFLY-1014
>>>>> done.  This feature allows CORS requests into the HTTP management
>>>>> endpoint.
>>>>>
>>>>> This would solve two problems:
>>>>> 1) The web console must ship with WildFly and must be downloaded from
>>>>> the WildFly instance it is talking to.
>>>>> 2) No other console is allowed to use the HTTP management
>>>>> endpoint.  So,
>>>>> a layered product's console can not control its own subsystem.
>>>>>
>>>>> Herald gives a nice overview of what this would mean for the Web
>>>>> Console:
>>>>> http://hpehl.info/independent-jboss-admin-console.html
>>>>>
>>>>> It would be very beneficial for other products as well.  Can we get
>>>>> this
>>>>> done?
>>>>>
>>>>> Stan
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>
>

From ssilvert at redhat.com  Tue Dec 10 12:39:35 2013
From: ssilvert at redhat.com (ssilvert at redhat.com)
Date: Tue, 10 Dec 2013 12:39:35 -0500
Subject: [wildfly-dev] Push for CORS in WildFly 8
In-Reply-To: <52A75055.10408@jboss.com>
References: <52A7144C.4050501@redhat.com> <52A726A8.3010300@jboss.com>
	<52A73A20.3020906@redhat.com> <52A740A3.6040009@jboss.com>
	<52A74723.4040905@redhat.com> <52A75055.10408@jboss.com>
Message-ID: <52A751D7.90506@redhat.com>

On 12/10/2013 12:33 PM, Darran Lofthouse wrote:
> If we are going to support cross origin requests we need to do it
> properly, the current behaviour is there to solve a specific problem
> of the server being vulnerable to cross site scripting attacks -
> relaxing it without a complete solution is just going to re-introduce
> that vulnerability.
>
> Based on the current commit there are two things we would really need
> to do: -
>  1 - Instead of faking authentication move Options handling to it's
> own handler before authentication.
>  2 - Proper support for configured alternative origins.
>
> Maybe we can just get away with a configured list of alternative
> origins to allow through but without exploring the origins for the
> alternative distribution approaches we can not be sure that would not
> leave an alternative option for malicious calls.
>
> At the moment I have not seen anything to suggest we need anything
> more dynamic but at this point I don't know if we have all the
> distribution approaches defined.
>
> I will have a look at what we can do for the static config approach.
+1 Static config would be great for now.
>
> Regards,
> Darran Lofthouse.
>
> On 10/12/13 16:53, ssilvert at redhat.com wrote:
>> On 12/10/2013 11:26 AM, Darran Lofthouse wrote:
>>> I am not sure if I am missing something, are you proposing that we
>>> stop the rejection of requests that have a different origin?
>> Not by default.  Just as an option so that we can start working with
>> CORS on the front end.
>>>
>>> On 10/12/13 15:58, ssilvert at redhat.com wrote:
>>>> On 12/10/2013 9:35 AM, Darran Lofthouse wrote:
>>>>> To get this implemented the first thing we need is some detailed
>>>>> analysis of how the Host and Origin headers will be used by different
>>>>> browsers for the different distribution approaches we will take for
>>>>> the different consoles.
>>>>>
>>>>> We will need to take into account how this could be affected by
>>>>> proxies / firewalls etc...
>>>>>
>>>>> Considering the different distribution approaches we will need to
>>>>> consider implications for malicious consoles / web pages etc possibly
>>>>> from the same source and any options to mitigate this.
>>>>>
>>>>> But then overall it should be a case of configuration to allow a
>>>>> relaxation of the Host / Origin match with acceptable values.
>>>> Let's do this last part first.  It's not much effort to enable CORS.
>>>> Here is Herald's commit:
>>>> https://github.com/hpehl/wildfly/commit/89af5ba711502005275411820b8198f69e36269b
>>>>
>>>>
>>>>
>>>> If we put this into WildFly 8 (disabled by default), it would allow us
>>>> to start working with it and better perform the analysis suggested by
>>>> Darran.
>>>>
>>>> I propose that Herald update his commit to work with the latest
>>>> code and
>>>> we go ahead and get that in.  Any objections?
>>>>
>>>>>
>>>>> Regards,
>>>>> Darran Lofthouse.
>>>>>
>>>>>
>>>>> On 10/12/13 13:17, ssilvert at redhat.com wrote:
>>>>>> Re: https://issues.jboss.org/browse/WFLY-1014
>>>>>>
>>>>>> I'd like to request that we take a harder look at getting WFLY-1014
>>>>>> done.  This feature allows CORS requests into the HTTP management
>>>>>> endpoint.
>>>>>>
>>>>>> This would solve two problems:
>>>>>> 1) The web console must ship with WildFly and must be downloaded
>>>>>> from
>>>>>> the WildFly instance it is talking to.
>>>>>> 2) No other console is allowed to use the HTTP management
>>>>>> endpoint.  So,
>>>>>> a layered product's console can not control its own subsystem.
>>>>>>
>>>>>> Herald gives a nice overview of what this would mean for the Web
>>>>>> Console:
>>>>>> http://hpehl.info/independent-jboss-admin-console.html
>>>>>>
>>>>>> It would be very beneficial for other products as well.  Can we get
>>>>>> this
>>>>>> done?
>>>>>>
>>>>>> Stan
>>>>>> _______________________________________________
>>>>>> wildfly-dev mailing list
>>>>>> wildfly-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>
>>>>
>>


From ssilvert at redhat.com  Tue Dec 10 12:48:59 2013
From: ssilvert at redhat.com (ssilvert at redhat.com)
Date: Tue, 10 Dec 2013 12:48:59 -0500
Subject: [wildfly-dev] Push for CORS in WildFly 8
In-Reply-To: <0AD5D753-E5AD-4B86-A5E1-1DA317FD3ED5@redhat.com>
References: <52A7144C.4050501@redhat.com>
	<0AD5D753-E5AD-4B86-A5E1-1DA317FD3ED5@redhat.com>
Message-ID: <52A7540B.6070807@redhat.com>

On 12/10/2013 12:35 PM, Heiko Braun wrote:
> I dont understand your second point, but +1 for enabling cors. It would enable arbitrary use cases that rely on the http endpoint. 
>
> But cors is onky one part if the story. The authentication mechanism would need to change as well, to allow for better integration.
>
> Has anyone evaluated keycloak as an alternative for securing the http management endpoint? 
That's where I think we're headed and I intend to get there
eventually.   It's key to doing SSO between the web console and all our
other consoles.
>
> At a first glance it seems to solve many of the problems we've outlined before.
>
>
>
>
>> Am 10.12.2013 um 14:17 schrieb ssilvert at redhat.com:
>>
>> No other console is allowed to use the HTTP management endpoint.  So,
>> a layered product's console can not control its own subsystem.


From darran.lofthouse at jboss.com  Tue Dec 10 13:00:16 2013
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Tue, 10 Dec 2013 18:00:16 +0000
Subject: [wildfly-dev] Push for CORS in WildFly 8
In-Reply-To: <0AD5D753-E5AD-4B86-A5E1-1DA317FD3ED5@redhat.com>
References: <52A7144C.4050501@redhat.com>
	<0AD5D753-E5AD-4B86-A5E1-1DA317FD3ED5@redhat.com>
Message-ID: <52A756B0.1060708@jboss.com>

The main problem we have with these solutions is they quickly introduce 
the requirement for the transport to be confidential to prevent 
interception of packets for replays.

Being confidential out of the box is never really an option, any 
solution there is flawed - the best I can think of at the moment is 
adding a set of management ops for key / certificate management and 
updating the console to strongly push the administrator towards enabling 
SSL.

The next issue is that by using standard HTTP authentication mechanisms 
standard APIs can be used in many programming languages to actually call 
the management interface without needing to know about alternative 
authentication schemes.  But having said that supporting it in addition 
to the current mechanisms should not be a problem - best case the 
authentication mechanisms co-exist - worst case we have a second context 
exposed that the console communicates with leaving the existing 
management context as-is.

Regards,
Darran Lofthouse.



On 10/12/13 17:35, Heiko Braun wrote:
> I dont understand your second point, but +1 for enabling cors. It would enable arbitrary use cases that rely on the http endpoint.
>
> But cors is onky one part if the story. The authentication mechanism would need to change as well, to allow for better integration.
>
> Has anyone evaluated keycloak as an alternative for securing the http management endpoint?
>
> At a first glance it seems to solve many of the problems we've outlined before.
>
>
>
>
>> Am 10.12.2013 um 14:17 schrieb ssilvert at redhat.com:
>>
>> No other console is allowed to use the HTTP management endpoint.  So,
>> a layered product's console can not control its own subsystem.
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From arun.gupta at gmail.com  Tue Dec 10 19:16:50 2013
From: arun.gupta at gmail.com (Arun Gupta)
Date: Tue, 10 Dec 2013 16:16:50 -0800
Subject: [wildfly-dev] 13 JASPIC tests failing on WildFly
Message-ID: <CAGBoHQWGaSQZ596ZTPN93OrCgNJFKiQYVvmHibqc4+Xw=PHzJg@mail.gmail.com>

Arjan Tims has added 22 new JASPIC tests to Java EE 7 test suite at:

https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic

13 of them are failing with WildFly as shown at:

https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20WildFly-cb/98/testReport/

21 of these tests are passing on GlassFish as shown at:

https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20GlassFish-cb/47/testReport/

JASPIC support in WildFly is reported "broken" as mentioned at:

https://github.com/arjantijms/jaspic-capabilities-test/commit/7f78a8267b453d7dde985debc08d80b09efcf724

Adding a new <security-domain> as mentioned in the above commit
message only marginally improves the results.

Do you see any basic configuration issue with OOTB WildFly for running
these tests ?

Arun
-- 
http://blog.arungupta.me
http://twitter.com/arungupta

From cfang at redhat.com  Tue Dec 10 23:08:32 2013
From: cfang at redhat.com (Cheng Fang)
Date: Tue, 10 Dec 2013 23:08:32 -0500
Subject: [wildfly-dev] Per-application batch job repository
Message-ID: <52A7E540.6090203@redhat.com>

WildFly batch implementation currently supports a global batch job 
repository, with the plan to support per-application job repository.  
James and I have been tossing around a few ideas, and would like to get 
input on some implementation approaches.  Here are some options:

1, introduce wildfly-batch.xml.  Applications can package in 
wildfly-batch.xml to override batch subsystem configurations for this 
app.  This gives applications maximum flexibility to customize any 
batch-related configurations that can be reasonably modified by 
application, including batch job repository datasource, thead pool, 
etc.  But the downside is there is one more wildfly-specific deployment 
descriptors to deal with.

2, define various batch profile that applications can choose from. The 
CLI path would be something like subsystem=batch/profile=A where A would 
be the name of the profile and would have the same settings as a root 
(subsystem=batch). If something, e.g. a thread-pool, isn't defined on 
the profile it falls back to the default.  The user would define the 
profile by adding a MANIFEST.MF entry with something like Batch-Profile: A.

This approach avoids the need for wildfly-batch.xml, but including 
application config inside MANIFEST.MF may not be that obvious to app 
developers.

3, use a relative jndi-name (a loose term) for job repository datasource 
in batch subsystem configuration, and this relative jndi-name may be 
bound to a datasouce declared in application scope.  For example,

3.1) admin wants to enforce a global job repository (no per-app job 
repository), so he can configure jndi-name attribute in the batch 
subsystem xml snippet:
jndi-name = "java:jboss/datasources/ExampleDS"

3.2) admin wants to allow either global or per-app job repository by 
using relative jndi-name:
jndi-name = "datasources/batch-job-repository"

3.2.1) app Foo wants to use global job repository as configured in 
WildFly server, then do nothing.  jberet will just expand the configured 
jndi-name and use java:jboss/datasources/batch-job-repository as the 
effective job repository jndi-name.

3.2.2) app Bar wants to use per-application job repository, so Bar can 
add a resource-ref to its web.xml or application.xml or ejb.xml
<resource-ref>
<res-ref-name>java:app/env/datasources/batch-job-repository<res-ref-name>
<mapped-name>java:jboss/datasources/orderDB</mapped-name>

When both app Foo and Bar are running inside WildFly server, Foo uses 
the global job repository while Bar uses its own job repository 
(orderDB) without any interference.

Any other ideas and suggestions are also welcome.  James, feel free to 
add or correct anything I've missed.

Cheng

From jperkins at redhat.com  Wed Dec 11 00:10:29 2013
From: jperkins at redhat.com (James R. Perkins)
Date: Tue, 10 Dec 2013 21:10:29 -0800
Subject: [wildfly-dev] Per-application batch job repository
In-Reply-To: <52A7E540.6090203@redhat.com>
References: <52A7E540.6090203@redhat.com>
Message-ID: <52A7F3C5.6020208@redhat.com>

These options seem right to me Cheng. I tend to lean towards one as it's 
more consistent with what we do elsewhere. I do however agree it's some 
what of a PITA to have yet another descriptor file.

On 12/10/2013 08:08 PM, Cheng Fang wrote:
> WildFly batch implementation currently supports a global batch job
> repository, with the plan to support per-application job repository.
> James and I have been tossing around a few ideas, and would like to get
> input on some implementation approaches.  Here are some options:
>
> 1, introduce wildfly-batch.xml.  Applications can package in
> wildfly-batch.xml to override batch subsystem configurations for this
> app.  This gives applications maximum flexibility to customize any
> batch-related configurations that can be reasonably modified by
> application, including batch job repository datasource, thead pool,
> etc.  But the downside is there is one more wildfly-specific deployment
> descriptors to deal with.
>
> 2, define various batch profile that applications can choose from. The
> CLI path would be something like subsystem=batch/profile=A where A would
> be the name of the profile and would have the same settings as a root
> (subsystem=batch). If something, e.g. a thread-pool, isn't defined on
> the profile it falls back to the default.  The user would define the
> profile by adding a MANIFEST.MF entry with something like Batch-Profile: A.
>
> This approach avoids the need for wildfly-batch.xml, but including
> application config inside MANIFEST.MF may not be that obvious to app
> developers.
>
> 3, use a relative jndi-name (a loose term) for job repository datasource
> in batch subsystem configuration, and this relative jndi-name may be
> bound to a datasouce declared in application scope.  For example,
>
> 3.1) admin wants to enforce a global job repository (no per-app job
> repository), so he can configure jndi-name attribute in the batch
> subsystem xml snippet:
> jndi-name = "java:jboss/datasources/ExampleDS"
>
> 3.2) admin wants to allow either global or per-app job repository by
> using relative jndi-name:
> jndi-name = "datasources/batch-job-repository"
>
> 3.2.1) app Foo wants to use global job repository as configured in
> WildFly server, then do nothing.  jberet will just expand the configured
> jndi-name and use java:jboss/datasources/batch-job-repository as the
> effective job repository jndi-name.
>
> 3.2.2) app Bar wants to use per-application job repository, so Bar can
> add a resource-ref to its web.xml or application.xml or ejb.xml
> <resource-ref>
> <res-ref-name>java:app/env/datasources/batch-job-repository<res-ref-name>
> <mapped-name>java:jboss/datasources/orderDB</mapped-name>
>
> When both app Foo and Bar are running inside WildFly server, Foo uses
> the global job repository while Bar uses its own job repository
> (orderDB) without any interference.
>
> Any other ideas and suggestions are also welcome.  James, feel free to
> add or correct anything I've missed.
>
> Cheng
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-- 
James R. Perkins
Red Hat JBoss Middleware


From rory.odonnell at oracle.com  Wed Dec 11 05:33:55 2013
From: rory.odonnell at oracle.com (Rory O'Donnell Oracle, Dublin Ireland)
Date: Wed, 11 Dec 2013 10:33:55 +0000
Subject: [wildfly-dev] JDK 8 build 119 is available on java.net
Message-ID: <52A83F93.5000001@oracle.com>

Hi All,

JDK 8 B119 EA Build is now available for download 
<http://jdk8.java.net/download.html> & test.

We are now very late in the release cycle, issues found late may be 
postponed to
JDK 9 time frame. Please log all show stopper issues as soon as possible.

Thanks for your support, Rory

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131211/19f6333b/attachment.html 

From hbraun at redhat.com  Wed Dec 11 05:53:49 2013
From: hbraun at redhat.com (Heiko Braun)
Date: Wed, 11 Dec 2013 11:53:49 +0100
Subject: [wildfly-dev] Push for CORS in WildFly 8
In-Reply-To: <52A756B0.1060708@jboss.com>
References: <52A7144C.4050501@redhat.com>
	<0AD5D753-E5AD-4B86-A5E1-1DA317FD3ED5@redhat.com>
	<52A756B0.1060708@jboss.com>
Message-ID: <0DA22369-A06C-4BCC-BE24-FBEB18611CCE@redhat.com>




yes, but this is not true for digest auth. there are actually very few client environments that fully support digest 	out of the box.

so i would say, this argument doesn't count as digest is  not any less complicated to use then any other more sophisticated auth mechanism.

I agree to the TLS argument: for most other auth mechanisms i looked at it seems to be  requirement indeed. 
But can you elaborate why we cannot ship certificates (out of the box) that need to be replaced in production environments?

this would give us TLS and push the need to custom certificate creation beyond the out-of-the-box scenario.




On 10 Dec 2013, at 19:00, Darran Lofthouse <darran.lofthouse at jboss.com> wrote:

> The next issue is that by using standard HTTP authentication mechanisms standard APIs can be used in many programming languages to actually call the management interface without needing to know about alternative authentication schemes.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131211/3e89eb84/attachment.html 

From hbraun at redhat.com  Wed Dec 11 06:00:27 2013
From: hbraun at redhat.com (Heiko Braun)
Date: Wed, 11 Dec 2013 12:00:27 +0100
Subject: [wildfly-dev] Push for CORS in WildFly 8
In-Reply-To: <52A756B0.1060708@jboss.com>
References: <52A7144C.4050501@redhat.com>
	<0AD5D753-E5AD-4B86-A5E1-1DA317FD3ED5@redhat.com>
	<52A756B0.1060708@jboss.com>
Message-ID: <7AC9584B-F12C-4C6A-9B58-8BC9DBDBB4AB@redhat.com>




yes, but this is not true for digest auth. there are actually very few client environments that fully support digest 	out of the box.

so i would say, this argument doesn't count as digest is  not any less complicated to use then any other more sophisticated auth mechanism.

I agree to the TLS argument: for most other auth mechanisms i looked at it seems to be  requirement indeed. 
But can you elaborate why we cannot ship certificates (out of the box) that need to be replaced in production environments?

this would give us TLS and push the need to custom certificate creation beyond the out-of-the-box scenario.




On 10 Dec 2013, at 19:00, Darran Lofthouse <darran.lofthouse at jboss.com> wrote:

> The next issue is that by using standard HTTP authentication mechanisms standard APIs can be used in many programming languages to actually call the management interface without needing to know about alternative authentication schemes.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131211/e1f98eb1/attachment-0001.html 

From darran.lofthouse at jboss.com  Wed Dec 11 07:26:39 2013
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Wed, 11 Dec 2013 12:26:39 +0000
Subject: [wildfly-dev] Push for CORS in WildFly 8
In-Reply-To: <0DA22369-A06C-4BCC-BE24-FBEB18611CCE@redhat.com>
References: <52A7144C.4050501@redhat.com>
	<0AD5D753-E5AD-4B86-A5E1-1DA317FD3ED5@redhat.com>
	<52A756B0.1060708@jboss.com>
	<0DA22369-A06C-4BCC-BE24-FBEB18611CCE@redhat.com>
Message-ID: <52A859FF.90507@jboss.com>

On 11/12/13 10:53, Heiko Braun wrote:
> yes, but this is not true for digest auth. there are actually very few
> client environments that fully support digest out of the box.
>
> so i would say, this argument doesn't count as digest is  not any less
> complicated to use then any other more sophisticated auth mechanism.
>
> I agree to the TLS argument: for most other auth mechanisms i looked at
> it seems to be  requirement indeed.
> But can you elaborate why we cannot ship certificates (out of the box)

What you are talking about here is encrypting traffic with a key which 
is public knowledge.

 > that need to be replaced in production environments?

We know that will not happen in many installations - guaranteed!

> this would give us TLS and push the need to custom certificate creation
> beyond the out-of-the-box scenario.
>
>
>
>
> On 10 Dec 2013, at 19:00, Darran Lofthouse <darran.lofthouse at jboss.com
> <mailto:darran.lofthouse at jboss.com>> wrote:
>
>> The next issue is that by using standard HTTP authentication
>> mechanisms standard APIs can be used in many programming languages to
>> actually call the management interface without needing to know about
>> alternative authentication schemes.
>

From sguilhen at redhat.com  Wed Dec 11 07:52:58 2013
From: sguilhen at redhat.com (Stefan Guilhen)
Date: Wed, 11 Dec 2013 10:52:58 -0200
Subject: [wildfly-dev] 13 JASPIC tests failing on WildFly
In-Reply-To: <CAGBoHQWGaSQZ596ZTPN93OrCgNJFKiQYVvmHibqc4+Xw=PHzJg@mail.gmail.com>
References: <CAGBoHQWGaSQZ596ZTPN93OrCgNJFKiQYVvmHibqc4+Xw=PHzJg@mail.gmail.com>
Message-ID: <52A8602A.8070206@redhat.com>

If you are using the security domain as mentioned in the commit any 
authentication will fail because there is no "dummy" auth-module. I 
couldn't find the WildFly log but there must be exceptions there 
indicating it was not possible to load the auth-module class.

Try setting the auth module in the security domain to

<auth-module 
code="org.wildfly.extension.undertow.security.jaspi.modules.HTTPSchemeServerAuthModule" 
flag="required"/>

And see how it goes.

Stefan

On 12/10/2013 10:16 PM, Arun Gupta wrote:
> Arjan Tims has added 22 new JASPIC tests to Java EE 7 test suite at:
>
> https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic
>
> 13 of them are failing with WildFly as shown at:
>
> https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20WildFly-cb/98/testReport/
>
> 21 of these tests are passing on GlassFish as shown at:
>
> https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20GlassFish-cb/47/testReport/
>
> JASPIC support in WildFly is reported "broken" as mentioned at:
>
> https://github.com/arjantijms/jaspic-capabilities-test/commit/7f78a8267b453d7dde985debc08d80b09efcf724
>
> Adding a new <security-domain> as mentioned in the above commit
> message only marginally improves the results.
>
> Do you see any basic configuration issue with OOTB WildFly for running
> these tests ?
>
> Arun


From sguilhen at redhat.com  Wed Dec 11 09:07:05 2013
From: sguilhen at redhat.com (Stefan Guilhen)
Date: Wed, 11 Dec 2013 12:07:05 -0200
Subject: [wildfly-dev] 13 JASPIC tests failing on WildFly
In-Reply-To: <52A8602A.8070206@redhat.com>
References: <CAGBoHQWGaSQZ596ZTPN93OrCgNJFKiQYVvmHibqc4+Xw=PHzJg@mail.gmail.com>
	<52A8602A.8070206@redhat.com>
Message-ID: <52A87189.7000502@redhat.com>

Actually they seem to be registering their own AuthConfigProvider, in 
which case the dummy domain setup is fine (configuring our auth-module 
impl won't do anything as their provider will register their own test 
module), so disregard my previous e-mail.

Note that there is a pending pull request 
(https://github.com/wildfly/wildfly/pull/5558/) that seems to fix a few 
of the issues seen in the tests. Lets run the tests again once the PR is 
merged to and see where we stand.

Stefan

On 12/11/2013 10:52 AM, Stefan Guilhen wrote:
> If you are using the security domain as mentioned in the commit any
> authentication will fail because there is no "dummy" auth-module. I
> couldn't find the WildFly log but there must be exceptions there
> indicating it was not possible to load the auth-module class.
>
> Try setting the auth module in the security domain to
>
> <auth-module
> code="org.wildfly.extension.undertow.security.jaspi.modules.HTTPSchemeServerAuthModule"
> flag="required"/>
>
> And see how it goes.
>
> Stefan
>
> On 12/10/2013 10:16 PM, Arun Gupta wrote:
>> Arjan Tims has added 22 new JASPIC tests to Java EE 7 test suite at:
>>
>> https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic
>>
>> 13 of them are failing with WildFly as shown at:
>>
>> https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20WildFly-cb/98/testReport/
>>
>> 21 of these tests are passing on GlassFish as shown at:
>>
>> https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20GlassFish-cb/47/testReport/
>>
>> JASPIC support in WildFly is reported "broken" as mentioned at:
>>
>> https://github.com/arjantijms/jaspic-capabilities-test/commit/7f78a8267b453d7dde985debc08d80b09efcf724
>>
>> Adding a new <security-domain> as mentioned in the above commit
>> message only marginally improves the results.
>>
>> Do you see any basic configuration issue with OOTB WildFly for running
>> these tests ?
>>
>> Arun
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From arun.gupta at gmail.com  Wed Dec 11 09:12:45 2013
From: arun.gupta at gmail.com (Arun Gupta)
Date: Wed, 11 Dec 2013 06:12:45 -0800
Subject: [wildfly-dev] 13 JASPIC tests failing on WildFly
In-Reply-To: <52A87189.7000502@redhat.com>
References: <CAGBoHQWGaSQZ596ZTPN93OrCgNJFKiQYVvmHibqc4+Xw=PHzJg@mail.gmail.com>
	<52A8602A.8070206@redhat.com> <52A87189.7000502@redhat.com>
Message-ID: <CAGBoHQXV2wSy0+vc7vgQ0WZHtDBNHnpFGWXq=u8+aXGrjFhByA@mail.gmail.com>

I changed the <security-domain> to:

<security-domain name="jaspitest" cache-type="default">
                    <authentication-jaspi>
                        <login-module-stack name="dummy">
                            <login-module code="Dummy" flag="optional"/>
                        </login-module-stack>
                        <auth-module
code="org.wildfly.extension.undertow.security.jaspi.modules.HTTPSchemeServerAuthModule"
flag="required"/>
                    </authentication-jaspi>
                </security-domain>

and getting more failures. Will wait for the PR to be merged.

Arun

On Wed, Dec 11, 2013 at 6:07 AM, Stefan Guilhen <sguilhen at redhat.com> wrote:
> Actually they seem to be registering their own AuthConfigProvider, in
> which case the dummy domain setup is fine (configuring our auth-module
> impl won't do anything as their provider will register their own test
> module), so disregard my previous e-mail.
>
> Note that there is a pending pull request
> (https://github.com/wildfly/wildfly/pull/5558/) that seems to fix a few
> of the issues seen in the tests. Lets run the tests again once the PR is
> merged to and see where we stand.
>
> Stefan
>
> On 12/11/2013 10:52 AM, Stefan Guilhen wrote:
>> If you are using the security domain as mentioned in the commit any
>> authentication will fail because there is no "dummy" auth-module. I
>> couldn't find the WildFly log but there must be exceptions there
>> indicating it was not possible to load the auth-module class.
>>
>> Try setting the auth module in the security domain to
>>
>> <auth-module
>> code="org.wildfly.extension.undertow.security.jaspi.modules.HTTPSchemeServerAuthModule"
>> flag="required"/>
>>
>> And see how it goes.
>>
>> Stefan
>>
>> On 12/10/2013 10:16 PM, Arun Gupta wrote:
>>> Arjan Tims has added 22 new JASPIC tests to Java EE 7 test suite at:
>>>
>>> https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic
>>>
>>> 13 of them are failing with WildFly as shown at:
>>>
>>> https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20WildFly-cb/98/testReport/
>>>
>>> 21 of these tests are passing on GlassFish as shown at:
>>>
>>> https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20GlassFish-cb/47/testReport/
>>>
>>> JASPIC support in WildFly is reported "broken" as mentioned at:
>>>
>>> https://github.com/arjantijms/jaspic-capabilities-test/commit/7f78a8267b453d7dde985debc08d80b09efcf724
>>>
>>> Adding a new <security-domain> as mentioned in the above commit
>>> message only marginally improves the results.
>>>
>>> Do you see any basic configuration issue with OOTB WildFly for running
>>> these tests ?
>>>
>>> Arun
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



-- 
http://blog.arungupta.me
http://twitter.com/arungupta

From bburke at redhat.com  Wed Dec 11 09:25:02 2013
From: bburke at redhat.com (Bill Burke)
Date: Wed, 11 Dec 2013 09:25:02 -0500
Subject: [wildfly-dev] Push for CORS in WildFly 8
In-Reply-To: <52A859FF.90507@jboss.com>
References: <52A7144C.4050501@redhat.com>	<0AD5D753-E5AD-4B86-A5E1-1DA317FD3ED5@redhat.com>	<52A756B0.1060708@jboss.com>	<0DA22369-A06C-4BCC-BE24-FBEB18611CCE@redhat.com>
	<52A859FF.90507@jboss.com>
Message-ID: <52A875BE.5060205@redhat.com>



On 12/11/2013 7:26 AM, Darran Lofthouse wrote:
> On 11/12/13 10:53, Heiko Braun wrote:
>> yes, but this is not true for digest auth. there are actually very few
>> client environments that fully support digest out of the box.
>>
>> so i would say, this argument doesn't count as digest is  not any less
>> complicated to use then any other more sophisticated auth mechanism.
>>
>> I agree to the TLS argument: for most other auth mechanisms i looked at
>> it seems to be  requirement indeed.
>> But can you elaborate why we cannot ship certificates (out of the box)
>
> What you are talking about here is encrypting traffic with a key which
> is public knowledge.
>
>   > that need to be replaced in production environments?
>
> We know that will not happen in many installations - guaranteed!
>

This is why I've argued before on the TAG that wildfly should generate 
SSL keys/certs on initial boot by default.  Just generate a key 
pair/cert that will only work for "localhost".

For development, the user has something that works out of the box that 
they can test HTTPS/SSL with, instead of figuring out the lengthy and 
often confusing SSL setup steps.  (Our own docs have been really really 
crappy in this area, btw).

For production, since the generated cert would only work for 
"localhost", the admin would be pretty much forced to install SSL 
correctly (or figure out how to turn it off) if they want to run 
anywhere outside of development.

Bill

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From jgreene at redhat.com  Wed Dec 11 09:52:49 2013
From: jgreene at redhat.com (Jason Greene)
Date: Wed, 11 Dec 2013 09:52:49 -0500 (EST)
Subject: [wildfly-dev] Push for CORS in WildFly 8
In-Reply-To: <0DA22369-A06C-4BCC-BE24-FBEB18611CCE@redhat.com>
References: <52A7144C.4050501@redhat.com>
	<0AD5D753-E5AD-4B86-A5E1-1DA317FD3ED5@redhat.com>
	<52A756B0.1060708@jboss.com>
	<0DA22369-A06C-4BCC-BE24-FBEB18611CCE@redhat.com>
Message-ID: <89F6C849-6B56-42F2-950E-801F3D0938B6@redhat.com>



Sent from my iPhone

> On Dec 11, 2013, at 5:00 AM, Heiko Braun <hbraun at redhat.com> wrote:
> 
> yes, but this is not true for digest auth. there are actually very few client environments that fully support digest    out of the box.

Everything I know of supports Digest,  all mainstream scripting languages.

We don't need to mix use cases though. We can start with digest and have a config process for SSO that requires switching to TLS.






From darran.lofthouse at jboss.com  Wed Dec 11 09:57:59 2013
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Wed, 11 Dec 2013 14:57:59 +0000
Subject: [wildfly-dev] Push for CORS in WildFly 8
In-Reply-To: <89F6C849-6B56-42F2-950E-801F3D0938B6@redhat.com>
References: <52A7144C.4050501@redhat.com>
	<0AD5D753-E5AD-4B86-A5E1-1DA317FD3ED5@redhat.com>
	<52A756B0.1060708@jboss.com>
	<0DA22369-A06C-4BCC-BE24-FBEB18611CCE@redhat.com>
	<89F6C849-6B56-42F2-950E-801F3D0938B6@redhat.com>
Message-ID: <52A87D77.2010001@jboss.com>



On 11/12/13 14:52, Jason Greene wrote:
>
>
> Sent from my iPhone
>
>> On Dec 11, 2013, at 5:00 AM, Heiko Braun <hbraun at redhat.com> wrote:
>>
>> yes, but this is not true for digest auth. there are actually very few client environments that fully support digest    out of the box.
>
> Everything I know of supports Digest,  all mainstream scripting languages.
>
> We don't need to mix use cases though. We can start with digest and have a config process for SSO that requires switching to TLS.

And if we can provide the operations and appropriate guidance through 
the admin console enabling TLS should not be too complicated.

>
>
>
>

From Anil.Saldhana at redhat.com  Wed Dec 11 10:15:19 2013
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Wed, 11 Dec 2013 09:15:19 -0600
Subject: [wildfly-dev] 13 JASPIC tests failing on WildFly
In-Reply-To: <CAGBoHQXV2wSy0+vc7vgQ0WZHtDBNHnpFGWXq=u8+aXGrjFhByA@mail.gmail.com>
References: <CAGBoHQWGaSQZ596ZTPN93OrCgNJFKiQYVvmHibqc4+Xw=PHzJg@mail.gmail.com>
	<52A8602A.8070206@redhat.com> <52A87189.7000502@redhat.com>
	<CAGBoHQXV2wSy0+vc7vgQ0WZHtDBNHnpFGWXq=u8+aXGrjFhByA@mail.gmail.com>
Message-ID: <52A88187.6070701@redhat.com>

I had stressed for standardization of the JASPI configuration.  The spec 
lead wanted
to keep it open. This was early days of the JSR.

I seriously doubt you can have auth modules written once and deploy on 
any app server.
That was the goal of the spec but I don't think it really has reached 
that potential.

As Stefan said, let us wait for all the JASPI related PRs to be merged 
before looking into
the failures.

On 12/11/2013 08:12 AM, Arun Gupta wrote:
> I changed the <security-domain> to:
>
> <security-domain name="jaspitest" cache-type="default">
>                      <authentication-jaspi>
>                          <login-module-stack name="dummy">
>                              <login-module code="Dummy" flag="optional"/>
>                          </login-module-stack>
>                          <auth-module
> code="org.wildfly.extension.undertow.security.jaspi.modules.HTTPSchemeServerAuthModule"
> flag="required"/>
>                      </authentication-jaspi>
>                  </security-domain>
>
> and getting more failures. Will wait for the PR to be merged.
>
> Arun
>
> On Wed, Dec 11, 2013 at 6:07 AM, Stefan Guilhen <sguilhen at redhat.com> wrote:
>> Actually they seem to be registering their own AuthConfigProvider, in
>> which case the dummy domain setup is fine (configuring our auth-module
>> impl won't do anything as their provider will register their own test
>> module), so disregard my previous e-mail.
>>
>> Note that there is a pending pull request
>> (https://github.com/wildfly/wildfly/pull/5558/) that seems to fix a few
>> of the issues seen in the tests. Lets run the tests again once the PR is
>> merged to and see where we stand.
>>
>> Stefan
>>
>> On 12/11/2013 10:52 AM, Stefan Guilhen wrote:
>>> If you are using the security domain as mentioned in the commit any
>>> authentication will fail because there is no "dummy" auth-module. I
>>> couldn't find the WildFly log but there must be exceptions there
>>> indicating it was not possible to load the auth-module class.
>>>
>>> Try setting the auth module in the security domain to
>>>
>>> <auth-module
>>> code="org.wildfly.extension.undertow.security.jaspi.modules.HTTPSchemeServerAuthModule"
>>> flag="required"/>
>>>
>>> And see how it goes.
>>>
>>> Stefan
>>>
>>> On 12/10/2013 10:16 PM, Arun Gupta wrote:
>>>> Arjan Tims has added 22 new JASPIC tests to Java EE 7 test suite at:
>>>>
>>>> https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic
>>>>
>>>> 13 of them are failing with WildFly as shown at:
>>>>
>>>> https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20WildFly-cb/98/testReport/
>>>>
>>>> 21 of these tests are passing on GlassFish as shown at:
>>>>
>>>> https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20GlassFish-cb/47/testReport/
>>>>
>>>> JASPIC support in WildFly is reported "broken" as mentioned at:
>>>>
>>>> https://github.com/arjantijms/jaspic-capabilities-test/commit/7f78a8267b453d7dde985debc08d80b09efcf724
>>>>
>>>> Adding a new <security-domain> as mentioned in the above commit
>>>> message only marginally improves the results.
>>>>
>>>> Do you see any basic configuration issue with OOTB WildFly for running
>>>> these tests ?
>>>>
>>>> Arun
>>>

From smarlow at redhat.com  Wed Dec 11 14:03:17 2013
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 11 Dec 2013 14:03:17 -0500
Subject: [wildfly-dev] WFLY-2601 and upgrading Hibernate Validator to
 5.0.2.Final (not available yet) ...
Message-ID: <52A8B6F5.8070809@redhat.com>

Hibernate Validator 5.0.2.Final isn't released yet but when it is, I 
would like to upgrade WF 8 to it.  I'd like to see 
https://hibernate.atlassian.net/browse/HV-838 (deployment class leak) 
fixed.

I am mentioning this here so others aren't surprised if/when a WFLY-2601 
pull request is merged.

Also see 
http://lists.jboss.org/pipermail/hibernate-dev/2013-December/010691.html 
discussion about an ArrayIndexOutOfBoundsException (HV-818) which is 
still being discussed.

Scott

From arjan.tijms at gmail.com  Wed Dec 11 15:51:54 2013
From: arjan.tijms at gmail.com (arjan tijms)
Date: Wed, 11 Dec 2013 21:51:54 +0100
Subject: [wildfly-dev] 13 JASPIC tests failing on WildFly
Message-ID: <CAE=-AhD=MJEz_TEX6E34h-wVA3wa2yHPKt-Za7KhQ91vPFS7dw@mail.gmail.com>

Hi,

I had stressed for standardization of the JASPI configuration.  The spec
> lead wanted to keep it open. This was early days of the JSR.
> I seriously doubt you can have auth modules written once and deploy on
> any app server.
>

Actually it doesn't seem to be that bad. Using the programmatic
registration method (which is the only standardized method) pretty
much every app server installs the SAM just fine (Geronimo is the sole
exception).

Yes, the first time it's a hassle that you have to code the wrapper
AuthConfigProvider, ServerAuthConfig etc types, but once you hide that
away inside a utility method it's a one liner to install a SAM from a
ServletContextListener. This is exactly what the tests that I
committed do:

@WebListener
public class SamAutoRegistrationListener extends BaseServletContextListener {

    @Override
    public void contextInitialized(ServletContextEvent sce) {
        JaspicUtils.registerSAM(sce.getServletContext(), new
TestServerAuthModule());
    }
}

It's perhaps a shame there's no declarative alternative, but this
method itself is IMHO not wrong per se. The Servlet spec defines
similar APIs for registering Servlets and Filters programmatically.

After working with JASPIC rather intensively for well over a year now
I can say that it does work in a portable way. The main issue is the
multitude of bugs in the various implementations and/or
implementations just not doing what's in the spec.

For instance, secureResponse should be called AFTER the resource (e.g.
a Servlet or JSP page) is invoked, but some implementations
erroneously call it before the resource is invoked. This makes it
impossible to use this method for a SAM that has to be portable. The
spec is clear on this topic, but the app servers just don't always do
the right thing.

Some aspects of the spec are just ignored by pretty much all servers,
like the ability of a SAM to wrap the request and response objects
(just like a Servlet Filter can do). For the open source servers it
can be seen that this functionality is not even attempted. Ironically,
GlassFish does attempt it, but due to a rather complicated bug it
eventually fails to deliver the wrapped request to the resource, while
it does deliver the wrapped response correctly.

So IMHO 90% of the non-portability of a SAM is just due to
implementation bugs. Many of them are rather trivial to fix. Hopefully
having a series of tests can help remedy this issue ;)

Kind regards,
Arjan Tijms




> That was the goal of the spec but I don't think it really has reached
> that potential.
> As Stefan said, let us wait for all the JASPI related PRs to be merged
> before looking into
> the failures.


On 12/11/2013 08:12 AM, Arun Gupta wrote:
>* I changed the <security-domain> to:
*>>* <security-domain name="jaspitest" cache-type="default">
*>*                      <authentication-jaspi>
*>*                          <login-module-stack name="dummy">
*>*                              <login-module code="Dummy" flag="optional"/>
*>*                          </login-module-stack>
*>*                          <auth-module
*>* code="org.wildfly.extension.undertow.security.jaspi.modules.HTTPSchemeServerAuthModule"
*>* flag="required"/>
*>*                      </authentication-jaspi>
*>*                  </security-domain>
*>>* and getting more failures. Will wait for the PR to be merged.
*>>* Arun
*>>* On Wed, Dec 11, 2013 at 6:07 AM, Stefan Guilhen <sguilhen at
redhat.com <https://lists.jboss.org/mailman/listinfo/wildfly-dev>>
wrote:
*>>* Actually they seem to be registering their own AuthConfigProvider, in
*>>* which case the dummy domain setup is fine (configuring our auth-module
*>>* impl won't do anything as their provider will register their own test
*>>* module), so disregard my previous e-mail.
*>>>>* Note that there is a pending pull request
*>>* (https://github.com/wildfly/wildfly/pull/5558/
<https://github.com/wildfly/wildfly/pull/5558/>) that seems to fix a
few
*>>* of the issues seen in the tests. Lets run the tests again once the PR is
*>>* merged to and see where we stand.
*>>>>* Stefan
*>>>>* On 12/11/2013 10:52 AM, Stefan Guilhen wrote:
*>>>* If you are using the security domain as mentioned in the commit any
*>>>* authentication will fail because there is no "dummy" auth-module. I
*>>>* couldn't find the WildFly log but there must be exceptions there
*>>>* indicating it was not possible to load the auth-module class.
*>>>>>>* Try setting the auth module in the security domain to
*>>>>>>* <auth-module
*>>>* code="org.wildfly.extension.undertow.security.jaspi.modules.HTTPSchemeServerAuthModule"
*>>>* flag="required"/>
*>>>>>>* And see how it goes.
*>>>>>>* Stefan
*>>>>>>* On 12/10/2013 10:16 PM, Arun Gupta wrote:
*>>>>* Arjan Tims has added 22 new JASPIC tests to Java EE 7 test suite at:
*>>>>>>>>* https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic
<https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic>
*>>>>>>>>* 13 of them are failing with WildFly as shown at:
*>>>>>>>>* https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20WildFly-cb/98/testReport/
<https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20WildFly-cb/98/testReport/>
*>>>>>>>>* 21 of these tests are passing on GlassFish as shown at:
*>>>>>>>>* https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20GlassFish-cb/47/testReport/
<https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20GlassFish-cb/47/testReport/>
*>>>>>>>>* JASPIC support in WildFly is reported "broken" as mentioned at:
*>>>>>>>>* https://github.com/arjantijms/jaspic-capabilities-test/commit/7f78a8267b453d7dde985debc08d80b09efcf724
<https://github.com/arjantijms/jaspic-capabilities-test/commit/7f78a8267b453d7dde985debc08d80b09efcf724>
*>>>>>>>>* Adding a new <security-domain> as mentioned in the above commit
*>>>>* message only marginally improves the results.
*>>>>>>>>* Do you see any basic configuration issue with OOTB WildFly
for running
*>>>>* these tests ?
*>>>>>>>>* Arun
*>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131211/67b5c392/attachment.html 

From sguilhen at redhat.com  Wed Dec 11 20:26:24 2013
From: sguilhen at redhat.com (Stefan Guilhen)
Date: Wed, 11 Dec 2013 23:26:24 -0200
Subject: [wildfly-dev] 13 JASPIC tests failing on WildFly
In-Reply-To: <CAE=-AhD=MJEz_TEX6E34h-wVA3wa2yHPKt-Za7KhQ91vPFS7dw@mail.gmail.com>
References: <CAE=-AhD=MJEz_TEX6E34h-wVA3wa2yHPKt-Za7KhQ91vPFS7dw@mail.gmail.com>
Message-ID: <52A910C0.7080308@redhat.com>

Indeed, I've taken a look at your tests and the solution is pretty clean 
although I have to agree with Anil that having a standard for the config 
would help a lot.

As a side note, the results are not as bad as they seem. The 
javaee7-samples project is missing a few jboss-web.xml descriptors and 
there's also an issue with HttpUnit throwing an exception that prevents 
certain tests from completing. I'm taking a look into these issues and 
will send a PR for the javaee7-samples project with a few fixes. I 
believe we will see much better numbers after that.

Stefan

On 12/11/2013 06:51 PM, arjan tijms wrote:
> Hi,
>
>     I had stressed for standardization of the JASPI configuration. The
>     spec lead wanted to keep it open. This was early days of the JSR.
>     I seriously doubt you can have auth modules written once and
>     deploy on any app server. 
>
> Actually it doesn't seem to be that bad. Using the programmatic 
> registration method (which is the only standardized method) pretty 
> much every app server installs the SAM just fine (Geronimo is the sole 
> exception).
>
> Yes, the first time it's a hassle that you have to code the wrapper 
> AuthConfigProvider, ServerAuthConfig etc types, but once you hide that 
> away inside a utility method it's a one liner to install a SAM from a 
> ServletContextListener. This is exactly what the tests that I 
> committed do:
>
> @WebListener public class SamAutoRegistrationListener extends 
> BaseServletContextListener { @Override public void 
> contextInitialized(ServletContextEvent sce) { 
> JaspicUtils.registerSAM(sce.getServletContext(), new 
> TestServerAuthModule()); } }
> It's perhaps a shame there's no declarative alternative, but this 
> method itself is IMHO not wrong per se. The Servlet spec defines 
> similar APIs for registering Servlets and Filters programmatically.
>
> After working with JASPIC rather intensively for well over a year now 
> I can say that it does work in a portable way. The main issue is the 
> multitude of bugs in the various implementations and/or 
> implementations just not doing what's in the spec.
>
> For instance, secureResponse should be called AFTER the resource (e.g. 
> a Servlet or JSP page) is invoked, but some implementations 
> erroneously call it before the resource is invoked. This makes it 
> impossible to use this method for a SAM that has to be portable. The 
> spec is clear on this topic, but the app servers just don't always do 
> the right thing.
>
> Some aspects of the spec are just ignored by pretty much all servers, 
> like the ability of a SAM to wrap the request and response objects 
> (just like a Servlet Filter can do). For the open source servers it 
> can be seen that this functionality is not even attempted. Ironically, 
> GlassFish does attempt it, but due to a rather complicated bug it 
> eventually fails to deliver the wrapped request to the resource, while 
> it does deliver the wrapped response correctly.
>
> So IMHO 90% of the non-portability of a SAM is just due to 
> implementation bugs. Many of them are rather trivial to fix. Hopefully 
> having a series of tests can help remedy this issue ;)
>
> Kind regards,
> Arjan Tijms
>
>     That was the goal of the spec but I don't think it really has
>     reached that potential. As Stefan said, let us wait for all the
>     JASPI related PRs to be merged before looking into the failures.
>
>
> On 12/11/2013 08:12 AM, Arun Gupta wrote:
> >/  I changed the <security-domain> to:
> />/
> />/  <security-domain name="jaspitest" cache-type="default">
> />/                       <authentication-jaspi>
> />/                           <login-module-stack name="dummy">
> />/                               <login-module code="Dummy" flag="optional"/>
> />/                           </login-module-stack>
> />/                           <auth-module
> />/  code="org.wildfly.extension.undertow.security.jaspi.modules.HTTPSchemeServerAuthModule"
> />/  flag="required"/>
> />/                       </authentication-jaspi>
> />/                   </security-domain>
> />/
> />/  and getting more failures. Will wait for the PR to be merged.
> />/
> />/  Arun
> />/
> />/  On Wed, Dec 11, 2013 at 6:07 AM, Stefan Guilhen <sguilhen at redhat.com  <https://lists.jboss.org/mailman/listinfo/wildfly-dev>> wrote:
> />>/  Actually they seem to be registering their own AuthConfigProvider, in
> />>/  which case the dummy domain setup is fine (configuring our auth-module
> />>/  impl won't do anything as their provider will register their own test
> />>/  module), so disregard my previous e-mail.
> />>/
> />>/  Note that there is a pending pull request
> />>/  (https://github.com/wildfly/wildfly/pull/5558/) that seems to fix a few
> />>/  of the issues seen in the tests. Lets run the tests again once the PR is
> />>/  merged to and see where we stand.
> />>/
> />>/  Stefan
> />>/
> />>/  On 12/11/2013 10:52 AM, Stefan Guilhen wrote:
> />>>/  If you are using the security domain as mentioned in the commit any
> />>>/  authentication will fail because there is no "dummy" auth-module. I
> />>>/  couldn't find the WildFly log but there must be exceptions there
> />>>/  indicating it was not possible to load the auth-module class.
> />>>/
> />>>/  Try setting the auth module in the security domain to
> />>>/
> />>>/  <auth-module
> />>>/  code="org.wildfly.extension.undertow.security.jaspi.modules.HTTPSchemeServerAuthModule"
> />>>/  flag="required"/>
> />>>/
> />>>/  And see how it goes.
> />>>/
> />>>/  Stefan
> />>>/
> />>>/  On 12/10/2013 10:16 PM, Arun Gupta wrote:
> />>>>/  Arjan Tims has added 22 new JASPIC tests to Java EE 7 test suite at:
> />>>>/
> />>>>/  https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic
> />>>>/
> />>>>/  13 of them are failing with WildFly as shown at:
> />>>>/
> />>>>/  https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20WildFly-cb/98/testReport/
> />>>>/
> />>>>/  21 of these tests are passing on GlassFish as shown at:
> />>>>/
> />>>>/  https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20GlassFish-cb/47/testReport/
> />>>>/
> />>>>/  JASPIC support in WildFly is reported "broken" as mentioned at:
> />>>>/
> />>>>/  https://github.com/arjantijms/jaspic-capabilities-test/commit/7f78a8267b453d7dde985debc08d80b09efcf724
> />>>>/
> />>>>/  Adding a new <security-domain> as mentioned in the above commit
> />>>>/  message only marginally improves the results.
> />>>>/
> />>>>/  Do you see any basic configuration issue with OOTB WildFly for running
> />>>>/  these tests ?
> />>>>/
> />>>>/  Arun
> />>>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131211/037bc949/attachment-0001.html 

From arun.gupta at gmail.com  Wed Dec 11 20:50:34 2013
From: arun.gupta at gmail.com (Arun Gupta)
Date: Wed, 11 Dec 2013 17:50:34 -0800
Subject: [wildfly-dev] 13 JASPIC tests failing on WildFly
In-Reply-To: <52A910C0.7080308@redhat.com>
References: <CAE=-AhD=MJEz_TEX6E34h-wVA3wa2yHPKt-Za7KhQ91vPFS7dw@mail.gmail.com>
	<52A910C0.7080308@redhat.com>
Message-ID: <CAGBoHQXoVoy71_nW8AUQhTTD4UU_+vC2EPj7Ga05=KrLwG3AwQ@mail.gmail.com>

Stefan,

Thanks, waiting for the PR!

Are these JBoss-specific deployment descriptors required because the
spec is under specified ?

Arun

On Wed, Dec 11, 2013 at 5:26 PM, Stefan Guilhen <sguilhen at redhat.com> wrote:
> Indeed, I've taken a look at your tests and the solution is pretty clean
> although I have to agree with Anil that having a standard for the config
> would help a lot.
>
> As a side note, the results are not as bad as they seem. The javaee7-samples
> project is missing a few jboss-web.xml descriptors and there's also an issue
> with HttpUnit throwing an exception that prevents certain tests from
> completing. I'm taking a look into these issues and will send a PR for the
> javaee7-samples project with a few fixes. I believe we will see much better
> numbers after that.
>
> Stefan
>
> On 12/11/2013 06:51 PM, arjan tijms wrote:
>
> Hi,
>>
>> I had stressed for standardization of the JASPI configuration.  The spec
>> lead wanted to keep it open. This was early days of the JSR.
>> I seriously doubt you can have auth modules written once and deploy on
>> any app server.
>
> Actually it doesn't seem to be that bad. Using the programmatic registration
> method (which is the only standardized method) pretty much every app server
> installs the SAM just fine (Geronimo is the sole exception).
>
> Yes, the first time it's a hassle that you have to code the wrapper
> AuthConfigProvider, ServerAuthConfig etc types, but once you hide that away
> inside a utility method it's a one liner to install a SAM from a
> ServletContextListener. This is exactly what the tests that I committed do:
>
> @WebListener
> public class SamAutoRegistrationListener extends BaseServletContextListener
> {
>
>     @Override
>     public void contextInitialized(ServletContextEvent sce) {
>         JaspicUtils.registerSAM(sce.getServletContext(), new
> TestServerAuthModule());
>     }
> }
>
> It's perhaps a shame there's no declarative alternative, but this method
> itself is IMHO not wrong per se. The Servlet spec defines similar APIs for
> registering Servlets and Filters programmatically.
>
> After working with JASPIC rather intensively for well over a year now I can
> say that it does work in a portable way. The main issue is the multitude of
> bugs in the various implementations and/or implementations just not doing
> what's in the spec.
>
> For instance, secureResponse should be called AFTER the resource (e.g. a
> Servlet or JSP page) is invoked, but some implementations erroneously call
> it before the resource is invoked. This makes it impossible to use this
> method for a SAM that has to be portable. The spec is clear on this topic,
> but the app servers just don't always do the right thing.
>
> Some aspects of the spec are just ignored by pretty much all servers, like
> the ability of a SAM to wrap the request and response objects (just like a
> Servlet Filter can do). For the open source servers it can be seen that this
> functionality is not even attempted. Ironically, GlassFish does attempt it,
> but due to a rather complicated bug it eventually fails to deliver the
> wrapped request to the resource, while it does deliver the wrapped response
> correctly.
>
> So IMHO 90% of the non-portability of a SAM is just due to implementation
> bugs. Many of them are rather trivial to fix. Hopefully having a series of
> tests can help remedy this issue ;)
>
> Kind regards,
> Arjan Tijms
>
>
>
>>
>> That was the goal of the spec but I don't think it really has reached
>> that potential.
>> As Stefan said, let us wait for all the JASPI related PRs to be merged
>> before looking into
>> the failures.
>
> On 12/11/2013 08:12 AM, Arun Gupta wrote:
>> I changed the <security-domain> to:
>>
>> <security-domain name="jaspitest" cache-type="default">
>>                      <authentication-jaspi>
>>                          <login-module-stack name="dummy">
>>                              <login-module code="Dummy" flag="optional"/>
>>                          </login-module-stack>
>>                          <auth-module
>>
>> code="org.wildfly.extension.undertow.security.jaspi.modules.HTTPSchemeServerAuthModule"
>> flag="required"/>
>>                      </authentication-jaspi>
>>                  </security-domain>
>>
>> and getting more failures. Will wait for the PR to be merged.
>>
>> Arun
>>
>> On Wed, Dec 11, 2013 at 6:07 AM, Stefan Guilhen <sguilhen at redhat.com>
>> wrote:
>>> Actually they seem to be registering their own AuthConfigProvider, in
>>> which case the dummy domain setup is fine (configuring our auth-module
>>> impl won't do anything as their provider will register their own test
>>> module), so disregard my previous e-mail.
>>>
>>> Note that there is a pending pull request
>>> (https://github.com/wildfly/wildfly/pull/5558/) that seems to fix a few
>>> of the issues seen in the tests. Lets run the tests again once the PR is
>>> merged to and see where we stand.
>>>
>>> Stefan
>>>
>>> On 12/11/2013 10:52 AM, Stefan Guilhen wrote:
>>>> If you are using the security domain as mentioned in the commit any
>>>> authentication will fail because there is no "dummy" auth-module. I
>>>> couldn't find the WildFly log but there must be exceptions there
>>>> indicating it was not possible to load the auth-module class.
>>>>
>>>> Try setting the auth module in the security domain to
>>>>
>>>> <auth-module
>>>>
>>>> code="org.wildfly.extension.undertow.security.jaspi.modules.HTTPSchemeServerAuthModule"
>>>> flag="required"/>
>>>>
>>>> And see how it goes.
>>>>
>>>> Stefan
>>>>
>>>> On 12/10/2013 10:16 PM, Arun Gupta wrote:
>>>>> Arjan Tims has added 22 new JASPIC tests to Java EE 7 test suite at:
>>>>>
>>>>> https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic
>>>>>
>>>>> 13 of them are failing with WildFly as shown at:
>>>>>
>>>>>
>>>>> https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20WildFly-cb/98/testReport/
>>>>>
>>>>> 21 of these tests are passing on GlassFish as shown at:
>>>>>
>>>>>
>>>>> https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20GlassFish-cb/47/testReport/
>>>>>
>>>>> JASPIC support in WildFly is reported "broken" as mentioned at:
>>>>>
>>>>>
>>>>> https://github.com/arjantijms/jaspic-capabilities-test/commit/7f78a8267b453d7dde985debc08d80b09efcf724
>>>>>
>>>>> Adding a new <security-domain> as mentioned in the above commit
>>>>> message only marginally improves the results.
>>>>>
>>>>> Do you see any basic configuration issue with OOTB WildFly for running
>>>>> these tests ?
>>>>>
>>>>> Arun
>>>>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



-- 
http://blog.arungupta.me
http://twitter.com/arungupta

From sguilhen at redhat.com  Wed Dec 11 21:20:57 2013
From: sguilhen at redhat.com (Stefan Guilhen)
Date: Thu, 12 Dec 2013 00:20:57 -0200
Subject: [wildfly-dev] 13 JASPIC tests failing on WildFly
In-Reply-To: <CAGBoHQXoVoy71_nW8AUQhTTD4UU_+vC2EPj7Ga05=KrLwG3AwQ@mail.gmail.com>
References: <CAE=-AhD=MJEz_TEX6E34h-wVA3wa2yHPKt-Za7KhQ91vPFS7dw@mail.gmail.com>
	<52A910C0.7080308@redhat.com>
	<CAGBoHQXoVoy71_nW8AUQhTTD4UU_+vC2EPj7Ga05=KrLwG3AwQ@mail.gmail.com>
Message-ID: <52A91D89.1050409@redhat.com>

Hi Arun,

As there is no standard for the configuration of JASPI modules we have 
historically used the security domain for that. The descriptor is needed 
to link the web application to the security domain that contains the 
JASPI configuration and the container uses the security domain config to 
determine if JAAS or JASPI will be used to authenticate users.

Also note that in WF (and all previous JBoss AS versions) JASPI is not 
enabled by default as the specs don't require us to do that, so we rely 
on this security domain config to enable it. I've had a discussion with 
Pedro - dev who implemented the JASPI mechanism for WildFly - a couple 
of months ago and we thought the configuration needed to be revisited 
but we have never had the time to do that.

Cheers,
Stefan

On 12/11/2013 11:50 PM, Arun Gupta wrote:
> Stefan,
>
> Thanks, waiting for the PR!
>
> Are these JBoss-specific deployment descriptors required because the
> spec is under specified ?
>
> Arun
>
> On Wed, Dec 11, 2013 at 5:26 PM, Stefan Guilhen <sguilhen at redhat.com> wrote:
>> Indeed, I've taken a look at your tests and the solution is pretty clean
>> although I have to agree with Anil that having a standard for the config
>> would help a lot.
>>
>> As a side note, the results are not as bad as they seem. The javaee7-samples
>> project is missing a few jboss-web.xml descriptors and there's also an issue
>> with HttpUnit throwing an exception that prevents certain tests from
>> completing. I'm taking a look into these issues and will send a PR for the
>> javaee7-samples project with a few fixes. I believe we will see much better
>> numbers after that.
>>
>> Stefan
>>
>> On 12/11/2013 06:51 PM, arjan tijms wrote:
>>
>> Hi,
>>> I had stressed for standardization of the JASPI configuration.  The spec
>>> lead wanted to keep it open. This was early days of the JSR.
>>> I seriously doubt you can have auth modules written once and deploy on
>>> any app server.
>> Actually it doesn't seem to be that bad. Using the programmatic registration
>> method (which is the only standardized method) pretty much every app server
>> installs the SAM just fine (Geronimo is the sole exception).
>>
>> Yes, the first time it's a hassle that you have to code the wrapper
>> AuthConfigProvider, ServerAuthConfig etc types, but once you hide that away
>> inside a utility method it's a one liner to install a SAM from a
>> ServletContextListener. This is exactly what the tests that I committed do:
>>
>> @WebListener
>> public class SamAutoRegistrationListener extends BaseServletContextListener
>> {
>>
>>      @Override
>>      public void contextInitialized(ServletContextEvent sce) {
>>          JaspicUtils.registerSAM(sce.getServletContext(), new
>> TestServerAuthModule());
>>      }
>> }
>>
>> It's perhaps a shame there's no declarative alternative, but this method
>> itself is IMHO not wrong per se. The Servlet spec defines similar APIs for
>> registering Servlets and Filters programmatically.
>>
>> After working with JASPIC rather intensively for well over a year now I can
>> say that it does work in a portable way. The main issue is the multitude of
>> bugs in the various implementations and/or implementations just not doing
>> what's in the spec.
>>
>> For instance, secureResponse should be called AFTER the resource (e.g. a
>> Servlet or JSP page) is invoked, but some implementations erroneously call
>> it before the resource is invoked. This makes it impossible to use this
>> method for a SAM that has to be portable. The spec is clear on this topic,
>> but the app servers just don't always do the right thing.
>>
>> Some aspects of the spec are just ignored by pretty much all servers, like
>> the ability of a SAM to wrap the request and response objects (just like a
>> Servlet Filter can do). For the open source servers it can be seen that this
>> functionality is not even attempted. Ironically, GlassFish does attempt it,
>> but due to a rather complicated bug it eventually fails to deliver the
>> wrapped request to the resource, while it does deliver the wrapped response
>> correctly.
>>
>> So IMHO 90% of the non-portability of a SAM is just due to implementation
>> bugs. Many of them are rather trivial to fix. Hopefully having a series of
>> tests can help remedy this issue ;)
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>> That was the goal of the spec but I don't think it really has reached
>>> that potential.
>>> As Stefan said, let us wait for all the JASPI related PRs to be merged
>>> before looking into
>>> the failures.
>> On 12/11/2013 08:12 AM, Arun Gupta wrote:
>>> I changed the <security-domain> to:
>>>
>>> <security-domain name="jaspitest" cache-type="default">
>>>                       <authentication-jaspi>
>>>                           <login-module-stack name="dummy">
>>>                               <login-module code="Dummy" flag="optional"/>
>>>                           </login-module-stack>
>>>                           <auth-module
>>>
>>> code="org.wildfly.extension.undertow.security.jaspi.modules.HTTPSchemeServerAuthModule"
>>> flag="required"/>
>>>                       </authentication-jaspi>
>>>                   </security-domain>
>>>
>>> and getting more failures. Will wait for the PR to be merged.
>>>
>>> Arun
>>>
>>> On Wed, Dec 11, 2013 at 6:07 AM, Stefan Guilhen <sguilhen at redhat.com>
>>> wrote:
>>>> Actually they seem to be registering their own AuthConfigProvider, in
>>>> which case the dummy domain setup is fine (configuring our auth-module
>>>> impl won't do anything as their provider will register their own test
>>>> module), so disregard my previous e-mail.
>>>>
>>>> Note that there is a pending pull request
>>>> (https://github.com/wildfly/wildfly/pull/5558/) that seems to fix a few
>>>> of the issues seen in the tests. Lets run the tests again once the PR is
>>>> merged to and see where we stand.
>>>>
>>>> Stefan
>>>>
>>>> On 12/11/2013 10:52 AM, Stefan Guilhen wrote:
>>>>> If you are using the security domain as mentioned in the commit any
>>>>> authentication will fail because there is no "dummy" auth-module. I
>>>>> couldn't find the WildFly log but there must be exceptions there
>>>>> indicating it was not possible to load the auth-module class.
>>>>>
>>>>> Try setting the auth module in the security domain to
>>>>>
>>>>> <auth-module
>>>>>
>>>>> code="org.wildfly.extension.undertow.security.jaspi.modules.HTTPSchemeServerAuthModule"
>>>>> flag="required"/>
>>>>>
>>>>> And see how it goes.
>>>>>
>>>>> Stefan
>>>>>
>>>>> On 12/10/2013 10:16 PM, Arun Gupta wrote:
>>>>>> Arjan Tims has added 22 new JASPIC tests to Java EE 7 test suite at:
>>>>>>
>>>>>> https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic
>>>>>>
>>>>>> 13 of them are failing with WildFly as shown at:
>>>>>>
>>>>>>
>>>>>> https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20WildFly-cb/98/testReport/
>>>>>>
>>>>>> 21 of these tests are passing on GlassFish as shown at:
>>>>>>
>>>>>>
>>>>>> https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20GlassFish-cb/47/testReport/
>>>>>>
>>>>>> JASPIC support in WildFly is reported "broken" as mentioned at:
>>>>>>
>>>>>>
>>>>>> https://github.com/arjantijms/jaspic-capabilities-test/commit/7f78a8267b453d7dde985debc08d80b09efcf724
>>>>>>
>>>>>> Adding a new <security-domain> as mentioned in the above commit
>>>>>> message only marginally improves the results.
>>>>>>
>>>>>> Do you see any basic configuration issue with OOTB WildFly for running
>>>>>> these tests ?
>>>>>>
>>>>>> Arun
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>


From arjan.tijms at gmail.com  Thu Dec 12 06:31:16 2013
From: arjan.tijms at gmail.com (arjan tijms)
Date: Thu, 12 Dec 2013 12:31:16 +0100
Subject: [wildfly-dev] 13 JASPIC tests failing on WildFly
In-Reply-To: <52A91D89.1050409@redhat.com>
References: <CAE=-AhD=MJEz_TEX6E34h-wVA3wa2yHPKt-Za7KhQ91vPFS7dw@mail.gmail.com>
	<52A910C0.7080308@redhat.com>
	<CAGBoHQXoVoy71_nW8AUQhTTD4UU_+vC2EPj7Ga05=KrLwG3AwQ@mail.gmail.com>
	<52A91D89.1050409@redhat.com>
Message-ID: <CAE=-AhDGAeEVY7drXjTDAHsWYMhYyoMhFWRELGh_P7b7OOy7TQ@mail.gmail.com>

Hi Stefan,

On Thursday, December 12, 2013, Stefan Guilhen wrote:

> Hi Arun,
>
> As there is no standard for the configuration of JASPI modules we have
> historically used the security domain for that.


Indeed, if one wants to configure a SAM (or possibly other JASPIC module)
for the entire application server outside of any deployed application in a
declarative way, then a concept like the JBoss security domain is
appropriate.

However, when the application registers its own local SAM (with wrappers)
then such a security domain is not needed. None of the other application
servers require something like it. The logic seems to be:

1. Check if there is a local SAM (matching app context id)
2. Check if there is a global SAM (using null as app context id)
3. Check if there is any proprietary mechanism in place (typically called
realm, domain, zone, etc).

Because of 2. you can also more or less portably register/configure a SAM
for the entire server by deploying a single .war with just a SAM and the
aforementioned context listener and then just passing in null for the app
context id. The spec defines that all contexts (all apps) on that server
should then use that module.


> The descriptor is needed
> to link the web application to the security domain that contains the
> JASPI configuration and the container uses the security domain config to
> determine if JAAS or JASPI will be used to authenticate users.
>
> Also note that in WF (and all previous JBoss AS versions) JASPI is not
> enabled by default as the specs don't require us to do that,


Would you happen to know which section of the spec exactly states this?
I've read the spec a couple of times over, but couldn't really find
anything. As the spec prose in case of the JASPIC spec is a bit difficult
to digest I might have missed it.

I do know that in every other server there is no need at all to explicitly
enable JASPIC. Just the mere act of using the standard factory to register
the (wrapped) SAM is enough for those other servers.



> so we rely
> on this security domain config to enable it. I've had a discussion with
> Pedro - dev who implemented the JASPI mechanism for WildFly - a couple
> of months ago and we thought the configuration needed to be revisited
> but we have never had the time to do that.


It would be absolutely great if WildFly could make the security domain
thing optional for JASPIC.

I interviewed a couple of developers about Java EE security and by far the
biggest pain point seems to be with the (to them) awkward vendor specific
xml files that are needed to get security going. (Note that while the other
servers don't have the required valve like in JBoss EAP 6 or the security
domain, they do have required vendor specific group to role mapping files
which are just as painful).

The concept of a security domain also causes another issue in JBoss. The
EJB spec does mention something about this for secured EJB beans (with a
security interceptor via @RolesAllowed) but reasonably I think the spec
intends this section to apply only for remote connections to a bean.

But JBoss always consults this security domain, even for local calls and
when the caller has already been authenticated (via JASPIC or otherwise).

The problem is that the EJB security interceptor only knows how to deal
with a JAAS login module, it doesn't know how to deal with JASPIC. Since
JASPIC has no profile for an EJB "message exchange" this wouldn't work in a
portable way no matter what.

All other servers seem to just propagate the existing authenticated
identity and thus the case of a JASPIC login in the web layer followed by a
call to an EJB with an @RolesAllowed works. In JBoss this always fails.

Also note that only the security interceptor tries to re-authenticate. The
implementation of the isCallerInRole method on the EJBContext does not
attempt this in JBoss and can thus theoretically work (but it too doesn't
work in JBoss EAP 6.x due to a bug, which is again rather trivial to fix).

Kind regards,
Arjan Tijms




>
> Cheers,
> Stefan
>
> On 12/11/2013 11:50 PM, Arun Gupta wrote:
> > Stefan,
> >
> > Thanks, waiting for the PR!
> >
> > Are these JBoss-specific deployment descriptors required because the
> > spec is under specified ?
> >
> > Arun
> >
> > On Wed, Dec 11, 2013 at 5:26 PM, Stefan Guilhen <sguilhen at redhat.com>
> wrote:
> >> Indeed, I've taken a look at your tests and the solution is pretty clean
> >> although I have to agree with Anil that having a standard for the config
> >> would help a lot.
> >>
> >> As a side note, the results are not as bad as they seem. The
> javaee7-samples
> >> project is missing a few jboss-web.xml descriptors and there's also an
> issue
> >> with HttpUnit throwing an exception that prevents certain tests from
> >> completing. I'm taking a look into these issues and will send a PR for
> the
> >> javaee7-samples project with a few fixes. I believe we will see much
> better
> >> numbers after that.
> >>
> >> Stefan
> >>
> >> On 12/11/2013 06:51 PM, arjan tijms wrote:
> >>
> >> Hi,
> >>> I had stressed for standardization of the JASPI configuration.  The
> spec
> >>> lead wanted to keep it open. This was early days of the JSR.
> >>> I seriously doubt you can have auth modules written once and deploy on
> >>> any app server.
> >> Actually it doesn't seem to be that bad. Using the programmatic
> registration
> >> method (which is the only standardized method) pretty much every app
> server
> >> installs the SAM just fine (Geronimo is the sole exception).
> >>
> >> Yes, the first time it's a hassle that you have to code the wrapper
> >> AuthConfigProvider, ServerAuthConfig etc types, but once you hide that
> away
> >> inside a utility method it's a one liner to install a SAM from a
> >> ServletContextListener. This is exactly what the tests that I committed
> do:
> >>
> >> @WebListener
> >> public class SamAutoRegistrationListener extends
> BaseServletContextListener
> >> {
> >>
> >>      @Override
> >>      public void contextInitialized(ServletContextEvent sce) {
> >>          JaspicUtils.registerSAM(sce.getServletContext(), new
> >> TestServerAuthModule());
> >>      }
> >> }
> >>
> >> It's perhaps a shame there's no declarative alternative, but this method
> >> itself is IMHO not wrong per se. The Servlet spec defines similar APIs
> for
> >> registering Servlets and Filters programmatically.
> >>
> >> After working with JASPIC rather intensively for well over a year now I
> can
> >> say that it does work in a portable way. The main issue is the
> multitude of
> >> bugs in the various implementations and/or implementations just not
> doing
> >> what's in the spec.
> >>
> >> For instance, secureResponse should be called AFTER the resource (e.g. a
> >> Servlet or JSP page) is invoked, but some implementations erroneously
> call
> >> it before the resource is invoked. This makes it impossible to use this
> >> method for a SAM that has to be portable. The spec is clear on this
> topic,
> >> but the app servers just don't always do the right thing.
> >>
> >> Some aspects of the spec are just ignored by pretty much all servers,
> like
> >> the ability of a SAM to wrap the request and response objects (just
> like a
> >> Servlet Filter can do). For the open source servers it can be seen that
> this
> >> functionality is not even attempted. Ironically, GlassFish does attempt
> it,
> >> but due to a rather complicated bug it eventually fails to deliver the
> >> wrapped request to the resource, while it does deliver the wrapped
> response
> >> correctly.
> >>
> >> So IMHO 90% of the non-portability of a SAM is just due to
> implementation
> >> bugs. Many of them are rather trivial to fix. Hopefully having a series
> of
> >> tests can help remedy this issue ;)
> >>
> >> Kind regards,
> >> Arjan Tijms
> >>
> >>
> >>
> >>> That was the goal of the spec but I don't think it really has reached
> >>> that potential.
> >>> As Stefan said, let us wait for all the JASPI related PRs to be merged
> >>> before looking into
> >>> the failures.
> >> On 12/11/2013 08:12 AM, Arun Gupta wrote:
> >>> I changed the <security-domain> to:
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131212/e9601d81/attachment-0001.html 

From brian.stansberry at redhat.com  Thu Dec 12 12:38:17 2013
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 12 Dec 2013 11:38:17 -0600
Subject: [wildfly-dev] Configuration of statistics gathering
In-Reply-To: <527A6DB3.6010407@redhat.com>
References: <527A6DB3.6010407@redhat.com>
Message-ID: <52A9F489.102@redhat.com>

Thanks, everyone, for the input on this.

I'd like to do the following about getting configuration of these 
consistent for WF 8.0:

1) For all resources that currently expose an attribute to 
enable/disable statistics, I'll add an attribute that will be named 
"statistics-enabled". Why that?

a) it's an attribute, so it's name should reflect a state, not an action 
like, for example, "enable-statistics"
b) simply using "statistics" is shorter, but in some places that key is 
used as a child type (e.g. statistics=pool) and a resource can't have a 
child type and an attribute with the same name.

2) For compatibility, the existing attribute will be retained as an 
alias to the new one. I'll add deprecation metadata. I'll also set up 
the appropriate transformation stuff for mixed domain usage.

3) Any new stuff people do (e.g. [1], [2]), please use "statistics-enabled".

4) My intent is to make the default values for these attributes be 
"false". I won't change any default though unless the relative compoent 
lead has indicated agreement in this thread or elsewhere.

But, if you disagree with "false" as the default, please let's use this 
thread to sort that out, get input from the performance team, etc, so we 
can have at least a clear understanding of why some uses have 'true'.

Jesper, ^^^. ;-)


That's for WF 8. For the next release I recommend that we also create 
subsystem-level attributes to hold the default value for the several 
cases where this setting is only configurable on a per-deployment level. 
An example would be the jpa subsystem could have a statistics-enabled 
attribute that drives the setting for all persistence units unless the 
PU descriptor overrides or the admin overrides using the existing 
per-deployment attribute. Besides being an aid to usability, having an 
attribute that ends up in the persistent configuration will also help 
deal with issues where, for example, the desired default for WildFly is 
different than the desired default for some future EAP release. The 
standard configs for the EAP release can just use a different value.


[1] https://issues.jboss.org/browse/JBWS-3733
[2] https://issues.jboss.org/browse/WFLY-2453

On 11/6/13 10:26 AM, Brian Stansberry wrote:
> I'd like to get some info from the component leads responsible for WF
> subsystems.
>
> 1) What statistical data does your subsystem capture (including the
> underlying libraries it integrates).
>
> 2) What configuration options do you support for enabling/disabling
> statistics gathering. What's the resource address and attribute name of
> the config option?
>
> 3) Is the statistic gathering enabled by default?
>
> Paul Ferraro's pull request [1] fixing JIRA [2] prompts this question,
> although it's long overdue. WF should be consistent about how we handle
> configuration of statistics gathering, so I'd like to take the
> opportunity of Paul's PR to move in that direction.
>
> Thanks for your help.
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat

From sguilhen at redhat.com  Thu Dec 12 12:57:44 2013
From: sguilhen at redhat.com (Stefan Guilhen)
Date: Thu, 12 Dec 2013 15:57:44 -0200
Subject: [wildfly-dev] 13 JASPIC tests failing on WildFly
In-Reply-To: <CAE=-AhDGAeEVY7drXjTDAHsWYMhYyoMhFWRELGh_P7b7OOy7TQ@mail.gmail.com>
References: <CAE=-AhD=MJEz_TEX6E34h-wVA3wa2yHPKt-Za7KhQ91vPFS7dw@mail.gmail.com>
	<52A910C0.7080308@redhat.com>
	<CAGBoHQXoVoy71_nW8AUQhTTD4UU_+vC2EPj7Ga05=KrLwG3AwQ@mail.gmail.com>
	<52A91D89.1050409@redhat.com>
	<CAE=-AhDGAeEVY7drXjTDAHsWYMhYyoMhFWRELGh_P7b7OOy7TQ@mail.gmail.com>
Message-ID: <52A9F918.6080200@redhat.com>

Hi Arjan,

These are all valid points and I agree that our implementation could use 
some improvements. I'll create a document with the points that need to 
be addressed and I propose we discuss them further next week when Pedro 
returns from his vacations.

Cheers,
Stefan

On 12/12/2013 09:31 AM, arjan tijms wrote:
> Hi Stefan,
>
> On Thursday, December 12, 2013, Stefan Guilhen wrote:
>
>     Hi Arun,
>
>     As there is no standard for the configuration of JASPI modules we have
>     historically used the security domain for that.
>
>
> Indeed, if one wants to configure a SAM (or possibly other 
> JASPIC module) for the entire application server outside of any 
> deployed application in a declarative way, then a concept like the 
> JBoss security domain is appropriate.
>
> However, when the application registers its own local SAM (with 
> wrappers) then such a security domain is not needed. None of the other 
> application servers require something like it. The logic seems to be:
>
> 1. Check if there is a local SAM (matching app context id)
> 2. Check if there is a global SAM (using null as app context id)
> 3. Check if there is any proprietary mechanism in place (typically 
> called realm, domain, zone, etc).
>
> Because of 2. you can also more or less portably register/configure a 
> SAM for the entire server by deploying a single .war with just a SAM 
> and the aforementioned context listener and then just passing in null 
> for the app context id. The spec defines that all contexts (all apps) 
> on that server should then use that module.
>
>     The descriptor is needed
>     to link the web application to the security domain that contains the
>     JASPI configuration and the container uses the security domain
>     config to
>     determine if JAAS or JASPI will be used to authenticate users.
>
>     Also note that in WF (and all previous JBoss AS versions) JASPI is not
>     enabled by default as the specs don't require us to do that,
>
>
> Would you happen to know which section of the spec exactly states 
> this? I've read the spec a couple of times over, but couldn't really 
> find anything. As the spec prose in case of the JASPIC spec is a bit 
> difficult to digest I might have missed it.
>
> I do know that in every other server there is no need at all to 
> explicitly enable JASPIC. Just the mere act of using the standard 
> factory to register the (wrapped) SAM is enough for those other servers.
>
>     so we rely
>     on this security domain config to enable it. I've had a discussion
>     with
>     Pedro - dev who implemented the JASPI mechanism for WildFly - a couple
>     of months ago and we thought the configuration needed to be revisited
>     but we have never had the time to do that.
>
>
> It would be absolutely great if WildFly could make the security domain 
> thing optional for JASPIC.
>
> I interviewed a couple of developers about Java EE security and by far 
> the biggest pain point seems to be with the (to them) awkward vendor 
> specific xml files that are needed to get security going. (Note that 
> while the other servers don't have the required valve like in JBoss 
> EAP 6 or the security domain, they do have required vendor 
> specific group to role mapping files which are just as painful).
>
> The concept of a security domain also causes another issue in JBoss. 
> The EJB spec does mention something about this for secured EJB beans 
> (with a security interceptor via @RolesAllowed) but reasonably I think 
> the spec intends this section to apply only for remote connections to 
> a bean.
>
> But JBoss always consults this security domain, even for local calls 
> and when the caller has already been authenticated (via JASPIC or 
> otherwise).
>
> The problem is that the EJB security interceptor only knows how to 
> deal with a JAAS login module, it doesn't know how to deal with 
> JASPIC. Since JASPIC has no profile for an EJB "message exchange" this 
> wouldn't work in a portable way no matter what.
>
> All other servers seem to just propagate the existing authenticated 
> identity and thus the case of a JASPIC login in the web layer followed 
> by a call to an EJB with an @RolesAllowed works. In JBoss this always 
> fails.
>
> Also note that only the security interceptor tries to re-authenticate. 
> The implementation of the isCallerInRole method on the EJBContext does 
> not attempt this in JBoss and can thus theoretically work (but it too 
> doesn't work in JBoss EAP 6.x due to a bug, which is again rather 
> trivial to fix).
>
> Kind regards,
> Arjan Tijms
>
>
>
>     Cheers,
>     Stefan
>
>     On 12/11/2013 11:50 PM, Arun Gupta wrote:
>     > Stefan,
>     >
>     > Thanks, waiting for the PR!
>     >
>     > Are these JBoss-specific deployment descriptors required because the
>     > spec is under specified ?
>     >
>     > Arun
>     >
>     > On Wed, Dec 11, 2013 at 5:26 PM, Stefan Guilhen
>     <sguilhen at redhat.com> wrote:
>     >> Indeed, I've taken a look at your tests and the solution is
>     pretty clean
>     >> although I have to agree with Anil that having a standard for
>     the config
>     >> would help a lot.
>     >>
>     >> As a side note, the results are not as bad as they seem. The
>     javaee7-samples
>     >> project is missing a few jboss-web.xml descriptors and there's
>     also an issue
>     >> with HttpUnit throwing an exception that prevents certain tests
>     from
>     >> completing. I'm taking a look into these issues and will send a
>     PR for the
>     >> javaee7-samples project with a few fixes. I believe we will see
>     much better
>     >> numbers after that.
>     >>
>     >> Stefan
>     >>
>     >> On 12/11/2013 06:51 PM, arjan tijms wrote:
>     >>
>     >> Hi,
>     >>> I had stressed for standardization of the JASPI configuration.
>      The spec
>     >>> lead wanted to keep it open. This was early days of the JSR.
>     >>> I seriously doubt you can have auth modules written once and
>     deploy on
>     >>> any app server.
>     >> Actually it doesn't seem to be that bad. Using the programmatic
>     registration
>     >> method (which is the only standardized method) pretty much
>     every app server
>     >> installs the SAM just fine (Geronimo is the sole exception).
>     >>
>     >> Yes, the first time it's a hassle that you have to code the wrapper
>     >> AuthConfigProvider, ServerAuthConfig etc types, but once you
>     hide that away
>     >> inside a utility method it's a one liner to install a SAM from a
>     >> ServletContextListener. This is exactly what the tests that I
>     committed do:
>     >>
>     >> @WebListener
>     >> public class SamAutoRegistrationListener extends
>     BaseServletContextListener
>     >> {
>     >>
>     >>      @Override
>     >>      public void contextInitialized(ServletContextEvent sce) {
>     >>  JaspicUtils.registerSAM(sce.getServletContext(), new
>     >> TestServerAuthModule());
>     >>      }
>     >> }
>     >>
>     >> It's perhaps a shame there's no declarative alternative, but
>     this method
>     >> itself is IMHO not wrong per se. The Servlet spec defines
>     similar APIs for
>     >> registering Servlets and Filters programmatically.
>     >>
>     >> After working with JASPIC rather intensively for well over a
>     year now I can
>     >> say that it does work in a portable way. The main issue is the
>     multitude of
>     >> bugs in the various implementations and/or implementations just
>     not doing
>     >> what's in the spec.
>     >>
>     >> For instance, secureResponse should be called AFTER the
>     resource (e.g. a
>     >> Servlet or JSP page) is invoked, but some implementations
>     erroneously call
>     >> it before the resource is invoked. This makes it impossible to
>     use this
>     >> method for a SAM that has to be portable. The spec is clear on
>     this topic,
>     >> but the app servers just don't always do the right thing.
>     >>
>     >> Some aspects of the spec are just ignored by pretty much all
>     servers, like
>     >> the ability of a SAM to wrap the request and response objects
>     (just like a
>     >> Servlet Filter can do). For the open source servers it can be
>     seen that this
>     >> functionality is not even attempted. Ironically, GlassFish does
>     attempt it,
>     >> but due to a rather complicated bug it eventually fails to
>     deliver the
>     >> wrapped request to the resource, while it does deliver the
>     wrapped response
>     >> correctly.
>     >>
>     >> So IMHO 90% of the non-portability of a SAM is just due to
>     implementation
>     >> bugs. Many of them are rather trivial to fix. Hopefully having
>     a series of
>     >> tests can help remedy this issue ;)
>     >>
>     >> Kind regards,
>     >> Arjan Tijms
>     >>
>     >>
>     >>
>     >>> That was the goal of the spec but I don't think it really has
>     reached
>     >>> that potential.
>     >>> As Stefan said, let us wait for all the JASPI related PRs to
>     be merged
>     >>> before looking into
>     >>> the failures.
>     >> On 12/11/2013 08:12 AM, Arun Gupta wrote:
>     >>> I changed the <security-domain> to:
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131212/160d83d0/attachment.html 

From jesper.pedersen at jboss.org  Thu Dec 12 13:03:54 2013
From: jesper.pedersen at jboss.org (Jesper Pedersen)
Date: Thu, 12 Dec 2013 13:03:54 -0500
Subject: [wildfly-dev] Configuration of statistics gathering
In-Reply-To: <52A9F489.102@redhat.com>
References: <527A6DB3.6010407@redhat.com> <52A9F489.102@redhat.com>
Message-ID: <52A9FA8A.30706@jboss.org>

On 12/12/2013 12:38 PM, Brian Stansberry wrote:
> 1) For all resources that currently expose an attribute to
> enable/disable statistics, I'll add an attribute that will be named
> "statistics-enabled". Why that?
>
> a) it's an attribute, so it's name should reflect a state, not an action
> like, for example, "enable-statistics"

Ok with that.

> b) simply using "statistics" is shorter, but in some places that key is
> used as a child type (e.g. statistics=pool) and a resource can't have a
> child type and an attribute with the same name.
>

Yeah, lets not change this.

> 2) For compatibility, the existing attribute will be retained as an
> alias to the new one. I'll add deprecation metadata. I'll also set up
> the appropriate transformation stuff for mixed domain usage.
>

Ok.

> 3) Any new stuff people do (e.g. [1], [2]), please use "statistics-enabled".
>

Agreed.

> 4) My intent is to make the default values for these attributes be
> "false". I won't change any default though unless the relative compoent
> lead has indicated agreement in this thread or elsewhere.
>
> But, if you disagree with "false" as the default, please let's use this
> thread to sort that out, get input from the performance team, etc, so we
> can have at least a clear understanding of why some uses have 'true'.
>

IronJacamar uses statistics internally in order to display run-time 
information of the pools.

IronJacamar 1.1.2+ has a change which will allow to turn-off statistics, 
but that results in nothing is displayed to the users in that case.

If we turn-off statistics by default we will have to be careful on what 
to communicate to the users, since they will expect see basic 
information out of the box. Maybe IronJacamar can display more 
information than the core pool settings, but requires further investigation.

I think in order to turn it off we need proof that there is a huge 
benefit for standard work loads. In the end we are talking about an 
extra section in the guide that explains turning off statistics will 
increase performance. Nothing new there. Or ship a "performance" profile.

Just so we are on the same page, the IronJacamar statistics is done by 2 
x System.currentTimeMillis() + a call to Atomic(Long|Integer|...) - let 
the flame war begin :) As always, patches welcome.

> Jesper, ^^^. ;-)
>

Why do you single me out, dude ;)

>
> That's for WF 8. For the next release I recommend that we also create
> subsystem-level attributes to hold the default value for the several
> cases where this setting is only configurable on a per-deployment level.
> An example would be the jpa subsystem could have a statistics-enabled
> attribute that drives the setting for all persistence units unless the
> PU descriptor overrides or the admin overrides using the existing
> per-deployment attribute. Besides being an aid to usability, having an
> attribute that ends up in the persistent configuration will also help
> deal with issues where, for example, the desired default for WildFly is
> different than the desired default for some future EAP release. The
> standard configs for the EAP release can just use a different value.
>
>

Sounds good, although having it as an option in each deployment 
descriptor for each component type maybe overkill. I think an option in 
wildfly.xml would be enough, and then override through 
statistics-enabled via CLI.

Best regards,
  Jesper


From brian.stansberry at redhat.com  Thu Dec 12 13:26:42 2013
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 12 Dec 2013 12:26:42 -0600
Subject: [wildfly-dev] Configuration of statistics gathering
In-Reply-To: <52A9FA8A.30706@jboss.org>
References: <527A6DB3.6010407@redhat.com> <52A9F489.102@redhat.com>
	<52A9FA8A.30706@jboss.org>
Message-ID: <52A9FFE2.3030803@redhat.com>

On 12/12/13 12:03 PM, Jesper Pedersen wrote:
> On 12/12/2013 12:38 PM, Brian Stansberry wrote:

>> 4) My intent is to make the default values for these attributes be
>> "false". I won't change any default though unless the relative compoent
>> lead has indicated agreement in this thread or elsewhere.
>>
>> But, if you disagree with "false" as the default, please let's use this
>> thread to sort that out, get input from the performance team, etc, so we
>> can have at least a clear understanding of why some uses have 'true'.
>>
>
> IronJacamar uses statistics internally in order to display run-time
> information of the pools.
>
> IronJacamar 1.1.2+ has a change which will allow to turn-off statistics,
> but that results in nothing is displayed to the users in that case.
>
> If we turn-off statistics by default we will have to be careful on what
> to communicate to the users, since they will expect see basic
> information out of the box. Maybe IronJacamar can display more
> information than the core pool settings, but requires further investigation.
>
> I think in order to turn it off we need proof that there is a huge
> benefit for standard work loads. In the end we are talking about an
> extra section in the guide that explains turning off statistics will
> increase performance. Nothing new there. Or ship a "performance" profile.
>
> Just so we are on the same page, the IronJacamar statistics is done by 2
> x System.currentTimeMillis() + a call to Atomic(Long|Integer|...) - let
> the flame war begin :) As always, patches welcome.
>
>> Jesper, ^^^. ;-)
>>
>
> Why do you single me out, dude ;)
>

You're the guy who argued for 'true'!

>>
>> That's for WF 8. For the next release I recommend that we also create
>> subsystem-level attributes to hold the default value for the several
>> cases where this setting is only configurable on a per-deployment level.
>> An example would be the jpa subsystem could have a statistics-enabled
>> attribute that drives the setting for all persistence units unless the
>> PU descriptor overrides or the admin overrides using the existing
>> per-deployment attribute. Besides being an aid to usability, having an
>> attribute that ends up in the persistent configuration will also help
>> deal with issues where, for example, the desired default for WildFly is
>> different than the desired default for some future EAP release. The
>> standard configs for the EAP release can just use a different value.
>>
>>
>
> Sounds good, although having it as an option in each deployment
> descriptor for each component type maybe overkill. I think an option in
> wildfly.xml would be enough, and then override through
> statistics-enabled via CLI.
>

My previous post wasn't meant to propose making this configurable in 
deployment descriptors (although maybe that's a good idea; I haven't 
really thought about it.)  I mentioned the PU descriptor just because I 
was using JPA as an example and IIRC config in the DD is part of that 
particular example. Hibernate lets the user enable/disable statistics 
via a property in persistence.xml.


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat

From jesper.pedersen at jboss.org  Thu Dec 12 13:36:50 2013
From: jesper.pedersen at jboss.org (Jesper Pedersen)
Date: Thu, 12 Dec 2013 13:36:50 -0500
Subject: [wildfly-dev] Configuration of statistics gathering
In-Reply-To: <52A9FFE2.3030803@redhat.com>
References: <527A6DB3.6010407@redhat.com>
	<52A9F489.102@redhat.com>	<52A9FA8A.30706@jboss.org>
	<52A9FFE2.3030803@redhat.com>
Message-ID: <52AA0242.3050106@jboss.org>

On 12/12/2013 01:26 PM, Brian Stansberry wrote:
>> Why do you single me out, dude ;)
>
> You're the guy who argued for 'true'!
>

I know :)

>> Sounds good, although having it as an option in each deployment
>> descriptor for each component type maybe overkill. I think an option in
>> wildfly.xml would be enough, and then override through
>> statistics-enabled via CLI.
>>
>
> My previous post wasn't meant to propose making this configurable in
> deployment descriptors (although maybe that's a good idea; I haven't
> really thought about it.)  I mentioned the PU descriptor just because I
> was using JPA as an example and IIRC config in the DD is part of that
> particular example. Hibernate lets the user enable/disable statistics
> via a property in persistence.xml.
>

Sure, if it can be done in standard deployment descriptors I have no 
problem with that. But doing it in all sub-projects, and related 
subsystems, is a different kettle of fish.

Overall (wildfly.xml) + run-time management commands should cover most 
use-cases. People will enable/disable during the deployment life time 
anyway.

Best regards,
  Jesper


From anmiller at redhat.com  Thu Dec 12 14:52:56 2013
From: anmiller at redhat.com (Andrig Miller)
Date: Thu, 12 Dec 2013 14:52:56 -0500 (EST)
Subject: [wildfly-dev] Configuration of statistics gathering
In-Reply-To: <52A9FA8A.30706@jboss.org>
References: <527A6DB3.6010407@redhat.com> <52A9F489.102@redhat.com>
	<52A9FA8A.30706@jboss.org>
Message-ID: <16207803.567.1386877974198.JavaMail.andrig@worklaptop.miller.org>



----- Original Message -----
> From: "Jesper Pedersen" <jesper.pedersen at jboss.org>
> To: wildfly-dev at lists.jboss.org
> Sent: Thursday, December 12, 2013 11:03:54 AM
> Subject: Re: [wildfly-dev] Configuration of statistics gathering
> 
> On 12/12/2013 12:38 PM, Brian Stansberry wrote:
> > 1) For all resources that currently expose an attribute to
> > enable/disable statistics, I'll add an attribute that will be named
> > "statistics-enabled". Why that?
> >
> > a) it's an attribute, so it's name should reflect a state, not an
> > action
> > like, for example, "enable-statistics"
> 
> Ok with that.
> 
> > b) simply using "statistics" is shorter, but in some places that
> > key is
> > used as a child type (e.g. statistics=pool) and a resource can't
> > have a
> > child type and an attribute with the same name.
> >
> 
> Yeah, lets not change this.
> 
> > 2) For compatibility, the existing attribute will be retained as an
> > alias to the new one. I'll add deprecation metadata. I'll also set
> > up
> > the appropriate transformation stuff for mixed domain usage.
> >
> 
> Ok.
> 
> > 3) Any new stuff people do (e.g. [1], [2]), please use
> > "statistics-enabled".
> >
> 
> Agreed.
> 
> > 4) My intent is to make the default values for these attributes be
> > "false". I won't change any default though unless the relative
> > compoent
> > lead has indicated agreement in this thread or elsewhere.
> >
> > But, if you disagree with "false" as the default, please let's use
> > this
> > thread to sort that out, get input from the performance team, etc,
> > so we
> > can have at least a clear understanding of why some uses have
> > 'true'.
> >
> 
> IronJacamar uses statistics internally in order to display run-time
> information of the pools.
> 
> IronJacamar 1.1.2+ has a change which will allow to turn-off
> statistics,
> but that results in nothing is displayed to the users in that case.
> 
> If we turn-off statistics by default we will have to be careful on
> what
> to communicate to the users, since they will expect see basic
> information out of the box. Maybe IronJacamar can display more
> information than the core pool settings, but requires further
> investigation.
> 
> I think in order to turn it off we need proof that there is a huge
> benefit for standard work loads. In the end we are talking about an
> extra section in the guide that explains turning off statistics will
> increase performance. Nothing new there. Or ship a "performance"
> profile.
> 

There is nothing special about the workload that drove this change, in terms of how its using IJ.  So, the change benefits any application that uses a data source.

I'm not really sure why any additional proof is required.  If somehow the workload was special in some way, then I could see that, but its not.  Its an EE 5 based application using EJB 3 entities with container managed persistence mapped to data sources.

By definition, if that application improves its response times signficantly, which it did, then any application will experience similar results as its scaled.  You probably wouldn't be able to measure it on an application with one user, but as you scale up the user count, and concurrency increases, the larger the impact.

Andy

> Just so we are on the same page, the IronJacamar statistics is done
> by 2
> x System.currentTimeMillis() + a call to Atomic(Long|Integer|...) -
> let
> the flame war begin :) As always, patches welcome.
> 
> > Jesper, ^^^. ;-)
> >
> 
> Why do you single me out, dude ;)
> 
> >
> > That's for WF 8. For the next release I recommend that we also
> > create
> > subsystem-level attributes to hold the default value for the
> > several
> > cases where this setting is only configurable on a per-deployment
> > level.
> > An example would be the jpa subsystem could have a
> > statistics-enabled
> > attribute that drives the setting for all persistence units unless
> > the
> > PU descriptor overrides or the admin overrides using the existing
> > per-deployment attribute. Besides being an aid to usability, having
> > an
> > attribute that ends up in the persistent configuration will also
> > help
> > deal with issues where, for example, the desired default for
> > WildFly is
> > different than the desired default for some future EAP release. The
> > standard configs for the EAP release can just use a different
> > value.
> >
> >
> 
> Sounds good, although having it as an option in each deployment
> descriptor for each component type maybe overkill. I think an option
> in
> wildfly.xml would be enough, and then override through
> statistics-enabled via CLI.
> 
> Best regards,
>   Jesper
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 

From smarlow at redhat.com  Thu Dec 12 16:15:24 2013
From: smarlow at redhat.com (Scott Marlow)
Date: Thu, 12 Dec 2013 16:15:24 -0500
Subject: [wildfly-dev] Configuration of statistics gathering
In-Reply-To: <52A9F489.102@redhat.com>
References: <527A6DB3.6010407@redhat.com> <52A9F489.102@redhat.com>
Message-ID: <52AA276C.3030306@redhat.com>

On 12/12/2013 12:38 PM, Brian Stansberry wrote:
> Thanks, everyone, for the input on this.
>
> I'd like to do the following about getting configuration of these
> consistent for WF 8.0:
>
> 1) For all resources that currently expose an attribute to
> enable/disable statistics, I'll add an attribute that will be named
> "statistics-enabled". Why that?
>
> a) it's an attribute, so it's name should reflect a state, not an action
> like, for example, "enable-statistics"
> b) simply using "statistics" is shorter, but in some places that key is
> used as a child type (e.g. statistics=pool) and a resource can't have a
> child type and an attribute with the same name.
>
> 2) For compatibility, the existing attribute will be retained as an
> alias to the new one. I'll add deprecation metadata. I'll also set up
> the appropriate transformation stuff for mixed domain usage.
>
> 3) Any new stuff people do (e.g. [1], [2]), please use "statistics-enabled".
>
> 4) My intent is to make the default values for these attributes be
> "false". I won't change any default though unless the relative compoent
> lead has indicated agreement in this thread or elsewhere.
>
> But, if you disagree with "false" as the default, please let's use this
> thread to sort that out, get input from the performance team, etc, so we
> can have at least a clear understanding of why some uses have 'true'.
>
> Jesper, ^^^. ;-)
>
>
> That's for WF 8. For the next release I recommend that we also create
> subsystem-level attributes to hold the default value for the several
> cases where this setting is only configurable on a per-deployment level.
> An example would be the jpa subsystem could have a statistics-enabled
> attribute that drives the setting for all persistence units unless the
> PU descriptor overrides or the admin overrides using the existing
> per-deployment attribute. Besides being an aid to usability, having an
> attribute that ends up in the persistent configuration will also help
> deal with issues where, for example, the desired default for WildFly is
> different than the desired default for some future EAP release. The
> standard configs for the EAP release can just use a different value.

Should the deployment level settings always take precedence?  If yes, 
then deployments that specify a statistics setting (e.g. persistence.xml 
includes a hint to set statistics to some state), are not be controlled 
by the subsystem level setting.  Having deployment settings override the 
subsystem settings sounds fine to me but I wanted to point out that we 
could let the subsystem settings override the deployment settings.

I wonder if "statistics-enabled" should have three states, so that the 
subsystem level settings always overrides the deployment level?  For the 
JPA case (with Hibernate):

true - statistics are enabled (even if the persistence.xml includes a 
hint to disable statistics).

false - statistics are disabled (even if the persistence.xml includes a 
hint to enable statistics).

ignore - statistics are determined by property hints in the persistence 
unit (in persistence.xml).

IMO, I like having the deployment settings override the subsystem level 
settings.  I would find it frustrating if setting a deployment level 
setting is ignored (one of the challenges of allowing multiple levels to 
set the same property).

>
>
> [1] https://issues.jboss.org/browse/JBWS-3733
> [2] https://issues.jboss.org/browse/WFLY-2453
>
> On 11/6/13 10:26 AM, Brian Stansberry wrote:
>> I'd like to get some info from the component leads responsible for WF
>> subsystems.
>>
>> 1) What statistical data does your subsystem capture (including the
>> underlying libraries it integrates).
>>
>> 2) What configuration options do you support for enabling/disabling
>> statistics gathering. What's the resource address and attribute name of
>> the config option?
>>
>> 3) Is the statistic gathering enabled by default?
>>
>> Paul Ferraro's pull request [1] fixing JIRA [2] prompts this question,
>> although it's long overdue. WF should be consistent about how we handle
>> configuration of statistics gathering, so I'd like to take the
>> opportunity of Paul's PR to move in that direction.
>>
>> Thanks for your help.
>>
>
>


From brian.stansberry at redhat.com  Thu Dec 12 18:02:59 2013
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 12 Dec 2013 17:02:59 -0600
Subject: [wildfly-dev] Configuration of statistics gathering
In-Reply-To: <52AA276C.3030306@redhat.com>
References: <527A6DB3.6010407@redhat.com> <52A9F489.102@redhat.com>
	<52AA276C.3030306@redhat.com>
Message-ID: <52AA40A3.1030602@redhat.com>

On 12/12/13 3:15 PM, Scott Marlow wrote:
> On 12/12/2013 12:38 PM, Brian Stansberry wrote:
>> Thanks, everyone, for the input on this.
>>
>> I'd like to do the following about getting configuration of these
>> consistent for WF 8.0:
>>
>> 1) For all resources that currently expose an attribute to
>> enable/disable statistics, I'll add an attribute that will be named
>> "statistics-enabled". Why that?
>>
>> a) it's an attribute, so it's name should reflect a state, not an action
>> like, for example, "enable-statistics"
>> b) simply using "statistics" is shorter, but in some places that key is
>> used as a child type (e.g. statistics=pool) and a resource can't have a
>> child type and an attribute with the same name.
>>
>> 2) For compatibility, the existing attribute will be retained as an
>> alias to the new one. I'll add deprecation metadata. I'll also set up
>> the appropriate transformation stuff for mixed domain usage.
>>
>> 3) Any new stuff people do (e.g. [1], [2]), please use
>> "statistics-enabled".
>>
>> 4) My intent is to make the default values for these attributes be
>> "false". I won't change any default though unless the relative compoent
>> lead has indicated agreement in this thread or elsewhere.
>>
>> But, if you disagree with "false" as the default, please let's use this
>> thread to sort that out, get input from the performance team, etc, so we
>> can have at least a clear understanding of why some uses have 'true'.
>>
>> Jesper, ^^^. ;-)
>>
>>
>> That's for WF 8. For the next release I recommend that we also create
>> subsystem-level attributes to hold the default value for the several
>> cases where this setting is only configurable on a per-deployment level.
>> An example would be the jpa subsystem could have a statistics-enabled
>> attribute that drives the setting for all persistence units unless the
>> PU descriptor overrides or the admin overrides using the existing
>> per-deployment attribute. Besides being an aid to usability, having an
>> attribute that ends up in the persistent configuration will also help
>> deal with issues where, for example, the desired default for WildFly is
>> different than the desired default for some future EAP release. The
>> standard configs for the EAP release can just use a different value.
>
> Should the deployment level settings always take precedence?  If yes,
> then deployments that specify a statistics setting (e.g. persistence.xml
> includes a hint to set statistics to some state), are not be controlled
> by the subsystem level setting.  Having deployment settings override the
> subsystem settings sounds fine to me but I wanted to point out that we
> could let the subsystem settings override the deployment settings.
>

True.

> I wonder if "statistics-enabled" should have three states, so that the
> subsystem level settings always overrides the deployment level?  For the
> JPA case (with Hibernate):
>
> true - statistics are enabled (even if the persistence.xml includes a
> hint to disable statistics).
>
> false - statistics are disabled (even if the persistence.xml includes a
> hint to enable statistics).
>
> ignore - statistics are determined by property hints in the persistence
> unit (in persistence.xml).
>

In the end there would have to be a default though. That is, if there is 
no deployment-level setting, "ignore" would have to be statically 
defined as meaning true or false.

> IMO, I like having the deployment settings override the subsystem level
> settings.  I would find it frustrating if setting a deployment level
> setting is ignored (one of the challenges of allowing multiple levels to
> set the same property).
>

I prefer deployments overriding too. I think the opposite would be 
pretty unintiutive, and requires complex stuff like the "ignore" value. 
In general, things work in our management on a 
more-specific-overrides-less-specific basis (e.g. system property 
settings at various levels in the domain/host config) and I think it's 
good to be consistent about that. Also, we have another mechanism for 
allowing admins to override the settings in their deployments: 
deployment overlays.

Do we have other cases where subsystem configs override some aspect of 
deployment config?

Side note on JPA: a subsystem-level setting presumes that the different 
providers have some mechanism for enabling/disabling statistics. If they 
don't a subsystem level setting becomes meaningless. Which isn't the end 
of the world, since our standard provider support this.


>>
>>
>> [1] https://issues.jboss.org/browse/JBWS-3733
>> [2] https://issues.jboss.org/browse/WFLY-2453
>>
>> On 11/6/13 10:26 AM, Brian Stansberry wrote:
>>> I'd like to get some info from the component leads responsible for WF
>>> subsystems.
>>>
>>> 1) What statistical data does your subsystem capture (including the
>>> underlying libraries it integrates).
>>>
>>> 2) What configuration options do you support for enabling/disabling
>>> statistics gathering. What's the resource address and attribute name of
>>> the config option?
>>>
>>> 3) Is the statistic gathering enabled by default?
>>>
>>> Paul Ferraro's pull request [1] fixing JIRA [2] prompts this question,
>>> although it's long overdue. WF should be consistent about how we handle
>>> configuration of statistics gathering, so I'd like to take the
>>> opportunity of Paul's PR to move in that direction.
>>>
>>> Thanks for your help.
>>>
>>
>>
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat

From sanne at hibernate.org  Thu Dec 12 20:20:44 2013
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 13 Dec 2013 01:20:44 +0000
Subject: [wildfly-dev] Configuration of statistics gathering
In-Reply-To: <52A9FA8A.30706@jboss.org>
References: <527A6DB3.6010407@redhat.com> <52A9F489.102@redhat.com>
	<52A9FA8A.30706@jboss.org>
Message-ID: <CAFm4XO3LTQR=P-=H_q7vMzwtQkuZWmcTOvhdsqSkBVxz_FGc6A@mail.gmail.com>

On 12 December 2013 18:03, Jesper Pedersen <jesper.pedersen at jboss.org> wrote:
> On 12/12/2013 12:38 PM, Brian Stansberry wrote:
>> 1) For all resources that currently expose an attribute to
>> enable/disable statistics, I'll add an attribute that will be named
>> "statistics-enabled". Why that?
>>
>> a) it's an attribute, so it's name should reflect a state, not an action
>> like, for example, "enable-statistics"
>
> Ok with that.
>
>> b) simply using "statistics" is shorter, but in some places that key is
>> used as a child type (e.g. statistics=pool) and a resource can't have a
>> child type and an attribute with the same name.
>>
>
> Yeah, lets not change this.
>
>> 2) For compatibility, the existing attribute will be retained as an
>> alias to the new one. I'll add deprecation metadata. I'll also set up
>> the appropriate transformation stuff for mixed domain usage.
>>
>
> Ok.
>
>> 3) Any new stuff people do (e.g. [1], [2]), please use "statistics-enabled".
>>
>
> Agreed.
>
>> 4) My intent is to make the default values for these attributes be
>> "false". I won't change any default though unless the relative compoent
>> lead has indicated agreement in this thread or elsewhere.
>>
>> But, if you disagree with "false" as the default, please let's use this
>> thread to sort that out, get input from the performance team, etc, so we
>> can have at least a clear understanding of why some uses have 'true'.
>>
>
> IronJacamar uses statistics internally in order to display run-time
> information of the pools.
>
> IronJacamar 1.1.2+ has a change which will allow to turn-off statistics,
> but that results in nothing is displayed to the users in that case.
>
> If we turn-off statistics by default we will have to be careful on what
> to communicate to the users, since they will expect see basic
> information out of the box. Maybe IronJacamar can display more
> information than the core pool settings, but requires further investigation.
>
> I think in order to turn it off we need proof that there is a huge
> benefit for standard work loads. In the end we are talking about an
> extra section in the guide that explains turning off statistics will
> increase performance. Nothing new there. Or ship a "performance" profile.
>
> Just so we are on the same page, the IronJacamar statistics is done by 2
> x System.currentTimeMillis() + a call to Atomic(Long|Integer|...) - let
> the flame war begin :) As always, patches welcome.

The following blog post highly recommends using nanoTime() rather than
currentTimeMillis() when it comes to measuring time intervals:

   https://blogs.oracle.com/dholmes/entry/inside_the_hotspot_vm_clocks

In the case of Infinispan, the contention on the AtomicLong(s) was
actually significant, we resorted using a LongAdder, backported from
Java8.

Still I doubt the contention was being caused by an insanely high
throughput: Infinispan might be fast but isn't that fast, so we
suspect the fix is being effective not because of the lower contention
on the CAS operation but more likely it has helped preventing false
sharing, as several statistics where being recorded as different
Atomic fields in the same class.

Best Regards,
Sanne


>
>> Jesper, ^^^. ;-)
>>
>
> Why do you single me out, dude ;)
>
>>
>> That's for WF 8. For the next release I recommend that we also create
>> subsystem-level attributes to hold the default value for the several
>> cases where this setting is only configurable on a per-deployment level.
>> An example would be the jpa subsystem could have a statistics-enabled
>> attribute that drives the setting for all persistence units unless the
>> PU descriptor overrides or the admin overrides using the existing
>> per-deployment attribute. Besides being an aid to usability, having an
>> attribute that ends up in the persistent configuration will also help
>> deal with issues where, for example, the desired default for WildFly is
>> different than the desired default for some future EAP release. The
>> standard configs for the EAP release can just use a different value.
>>
>>
>
> Sounds good, although having it as an option in each deployment
> descriptor for each component type maybe overkill. I think an option in
> wildfly.xml would be enough, and then override through
> statistics-enabled via CLI.
>
> Best regards,
>   Jesper
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

From rory.odonnell at oracle.com  Mon Dec 16 04:59:03 2013
From: rory.odonnell at oracle.com (Rory O'Donnell Oracle, Dublin Ireland)
Date: Mon, 16 Dec 2013 09:59:03 +0000
Subject: [wildfly-dev] JDK 8 build 120 is available on java.net
In-Reply-To: <52AECBF7.3060509@oracle.com>
References: <52AECBF7.3060509@oracle.com>
Message-ID: <52AECEE7.70606@oracle.com>

cc'ing wildfly-dev at lists.jboss.org

Rgds,Rory
On 16/12/2013 09:46, Rory O'Donnell Oracle, Dublin Ireland wrote:
> Hi Guys,
>
> JDK 8 B120 EA Build is now available for download 
> <http://jdk8.java.net/download.html> & test.
>
> We are now very late in the release cycle, issues found late may be 
> postponed to
> JDK 9 time frame. Please log all show stopper issues as soon as possible.
>
> Thanks for your support, Rory
> -- 
> Rgds,Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA , Dublin, Ireland

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131216/51caaa8d/attachment.html 

From emmanuel at hibernate.org  Mon Dec 16 11:15:42 2013
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 16 Dec 2013 17:15:42 +0100
Subject: [wildfly-dev] Hibernate Search as a dependency
Message-ID: <20131216161542.GE23294@hibernate.org>

So recently, Hibernate Search has been added as a dependency of Wildfly.
I think for two reasons:

- Infinispan when using <indexing/> requires it
- CapeDwarf is a customer of Infinispan, its indexing and Hibernate
  Search

I am a bit concerned about that move because Hibernate Search (depending
on the options you choose) can bring a significant dependency graph and
I don't want Wildfly to suffer from that.

As part of Hibernate Search, we do work and offer a Wildfly module to
ease the integration but it seems the work as been duplicated.

So my question to all of you guys is the following. Isn't it enough to
let Hibernate Search keep up with the module definition and let use add
the module when they need either Hibernate Search, Infinispan indexing
or CapeDwarf?

Emmanuel

From cfang at redhat.com  Mon Dec 16 11:24:44 2013
From: cfang at redhat.com (Cheng Fang)
Date: Mon, 16 Dec 2013 11:24:44 -0500
Subject: [wildfly-dev] Per-application batch job repository
In-Reply-To: <52A7F3C5.6020208@redhat.com>
References: <52A7E540.6090203@redhat.com> <52A7F3C5.6020208@redhat.com>
Message-ID: <52AF294C.1040704@redhat.com>

If there is no objections, we will go with option 1, introducing 
wildfly-batch.xml as an optional descriptor to EAR, ejb jar and WAR.

Cheng

On 12/11/13, 12:10 AM, James R. Perkins wrote:
> These options seem right to me Cheng. I tend to lean towards one as it's
> more consistent with what we do elsewhere. I do however agree it's some
> what of a PITA to have yet another descriptor file.
>
> On 12/10/2013 08:08 PM, Cheng Fang wrote:
>> WildFly batch implementation currently supports a global batch job
>> repository, with the plan to support per-application job repository.
>> James and I have been tossing around a few ideas, and would like to get
>> input on some implementation approaches.  Here are some options:
>>
>> 1, introduce wildfly-batch.xml.  Applications can package in
>> wildfly-batch.xml to override batch subsystem configurations for this
>> app.  This gives applications maximum flexibility to customize any
>> batch-related configurations that can be reasonably modified by
>> application, including batch job repository datasource, thead pool,
>> etc.  But the downside is there is one more wildfly-specific deployment
>> descriptors to deal with.
>>
>> 2, define various batch profile that applications can choose from. The
>> CLI path would be something like subsystem=batch/profile=A where A would
>> be the name of the profile and would have the same settings as a root
>> (subsystem=batch). If something, e.g. a thread-pool, isn't defined on
>> the profile it falls back to the default.  The user would define the
>> profile by adding a MANIFEST.MF entry with something like Batch-Profile: A.
>>
>> This approach avoids the need for wildfly-batch.xml, but including
>> application config inside MANIFEST.MF may not be that obvious to app
>> developers.
>>
>> 3, use a relative jndi-name (a loose term) for job repository datasource
>> in batch subsystem configuration, and this relative jndi-name may be
>> bound to a datasouce declared in application scope.  For example,
>>
>> 3.1) admin wants to enforce a global job repository (no per-app job
>> repository), so he can configure jndi-name attribute in the batch
>> subsystem xml snippet:
>> jndi-name = "java:jboss/datasources/ExampleDS"
>>
>> 3.2) admin wants to allow either global or per-app job repository by
>> using relative jndi-name:
>> jndi-name = "datasources/batch-job-repository"
>>
>> 3.2.1) app Foo wants to use global job repository as configured in
>> WildFly server, then do nothing.  jberet will just expand the configured
>> jndi-name and use java:jboss/datasources/batch-job-repository as the
>> effective job repository jndi-name.
>>
>> 3.2.2) app Bar wants to use per-application job repository, so Bar can
>> add a resource-ref to its web.xml or application.xml or ejb.xml
>> <resource-ref>
>> <res-ref-name>java:app/env/datasources/batch-job-repository<res-ref-name>
>> <mapped-name>java:jboss/datasources/orderDB</mapped-name>
>>
>> When both app Foo and Bar are running inside WildFly server, Foo uses
>> the global job repository while Bar uses its own job repository
>> (orderDB) without any interference.
>>
>> Any other ideas and suggestions are also welcome.  James, feel free to
>> add or correct anything I've missed.
>>
>> Cheng
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From tomaz.cerar at gmail.com  Mon Dec 16 11:26:04 2013
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Mon, 16 Dec 2013 17:26:04 +0100
Subject: [wildfly-dev] Hibernate Search as a dependency
In-Reply-To: <20131216161542.GE23294@hibernate.org>
References: <20131216161542.GE23294@hibernate.org>
Message-ID: <CAMquZP5fG1a7TDD1L6EqFP6q1sYv+Y2GH2JCy7HrFZ0hvJXnGw@mail.gmail.com>

This was mostly discussed as part of added bloat debate:

http://lists.jboss.org/pipermail/wildfly-dev/2013-November/001125.html

I personally am not a fan!


On Mon, Dec 16, 2013 at 5:15 PM, Emmanuel Bernard <emmanuel at hibernate.org>wrote:

> So recently, Hibernate Search has been added as a dependency of Wildfly.
> I think for two reasons:
>
> - Infinispan when using <indexing/> requires it
> - CapeDwarf is a customer of Infinispan, its indexing and Hibernate
>   Search
>
> I am a bit concerned about that move because Hibernate Search (depending
> on the options you choose) can bring a significant dependency graph and
> I don't want Wildfly to suffer from that.
>
> As part of Hibernate Search, we do work and offer a Wildfly module to
> ease the integration but it seems the work as been duplicated.
>
> So my question to all of you guys is the following. Isn't it enough to
> let Hibernate Search keep up with the module definition and let use add
> the module when they need either Hibernate Search, Infinispan indexing
> or CapeDwarf?
>
> Emmanuel
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131216/1e4f33c7/attachment.html 

From smarlow at redhat.com  Mon Dec 16 11:46:25 2013
From: smarlow at redhat.com (Scott Marlow)
Date: Mon, 16 Dec 2013 11:46:25 -0500
Subject: [wildfly-dev] Hibernate Search as a dependency
In-Reply-To: <CAMquZP5fG1a7TDD1L6EqFP6q1sYv+Y2GH2JCy7HrFZ0hvJXnGw@mail.gmail.com>
References: <20131216161542.GE23294@hibernate.org>
	<CAMquZP5fG1a7TDD1L6EqFP6q1sYv+Y2GH2JCy7HrFZ0hvJXnGw@mail.gmail.com>
Message-ID: <52AF2E61.5020900@redhat.com>


On 12/16/2013 11:26 AM, Toma? Cerar wrote:
> This was mostly discussed as part of added bloat debate:

There is more to it then adding additional jars.  We also need more than 
zero unit tests and possibly more time in the schedule (WF 8/9).

>
> http://lists.jboss.org/pipermail/wildfly-dev/2013-November/001125.html
>
> I personally am not a fan!
>
>
> On Mon, Dec 16, 2013 at 5:15 PM, Emmanuel Bernard
> <emmanuel at hibernate.org <mailto:emmanuel at hibernate.org>> wrote:
>
>     So recently, Hibernate Search has been added as a dependency of Wildfly.
>     I think for two reasons:
>
>     - Infinispan when using <indexing/> requires it
>     - CapeDwarf is a customer of Infinispan, its indexing and Hibernate
>        Search
>
>     I am a bit concerned about that move because Hibernate Search (depending
>     on the options you choose) can bring a significant dependency graph and
>     I don't want Wildfly to suffer from that.
>
>     As part of Hibernate Search, we do work and offer a Wildfly module to
>     ease the integration but it seems the work as been duplicated.
>
>     So my question to all of you guys is the following. Isn't it enough to
>     let Hibernate Search keep up with the module definition and let use add
>     the module when they need either Hibernate Search, Infinispan indexing
>     or CapeDwarf?
>
>     Emmanuel
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


From adietish at redhat.com  Mon Dec 16 12:08:51 2013
From: adietish at redhat.com (=?ISO-8859-1?Q?Andr=E9_Dietisheim?=)
Date: Mon, 16 Dec 2013 18:08:51 +0100
Subject: [wildfly-dev] WFLY-705: how should access restrictions get
	configured?
Message-ID: <52AF33A3.2060308@redhat.com>

Hi

I'm trying to come up with implementation for 
https://issues.jboss.org/browse/WFLY-705 where a user should be able to 
restrict access to the management service by IP and UserAgent. The 
filters are implemented and now I'm up to come up with the configuration 
options. I'm thus asking for input.

 From a noob (sorry, I'm not very intimate with wildfly/undertow yet) 
perspective <access-control> looks like a compelling tag to be nested 
into <management-interfaces><http-interface>. Even though 
<access-control> is used for RBAC currently, the code for it looks 
abstract enough to get reused.

Any ideas?

Cheers
Andr?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131216/06ed349d/attachment.html 

From jason.greene at redhat.com  Mon Dec 16 12:12:39 2013
From: jason.greene at redhat.com (Jason Greene)
Date: Mon, 16 Dec 2013 11:12:39 -0600
Subject: [wildfly-dev] Hibernate Search as a dependency
In-Reply-To: <20131216161542.GE23294@hibernate.org>
References: <20131216161542.GE23294@hibernate.org>
Message-ID: <F31B5877-0011-4ECC-ACEC-7A0D63B2919F@redhat.com>

Yes I agree that we want to remove it from at least our primary distro. The solution
I would have preferred, but never got sent to the ML (was in my drafts folder - oops)
was that we only pull in hibernate search to test <indexing/> but not ship it by default.

On Dec 16, 2013, at 10:15 AM, Emmanuel Bernard <emmanuel at hibernate.org> wrote:

> So recently, Hibernate Search has been added as a dependency of Wildfly.
> I think for two reasons:
> 
> - Infinispan when using <indexing/> requires it
> - CapeDwarf is a customer of Infinispan, its indexing and Hibernate
>  Search
> 
> I am a bit concerned about that move because Hibernate Search (depending
> on the options you choose) can bring a significant dependency graph and
> I don't want Wildfly to suffer from that.
> 
> As part of Hibernate Search, we do work and offer a Wildfly module to
> ease the integration but it seems the work as been duplicated.
> 
> So my question to all of you guys is the following. Isn't it enough to
> let Hibernate Search keep up with the module definition and let use add
> the module when they need either Hibernate Search, Infinispan indexing
> or CapeDwarf?
> 
> Emmanuel
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat



From jason.greene at redhat.com  Mon Dec 16 12:14:27 2013
From: jason.greene at redhat.com (Jason Greene)
Date: Mon, 16 Dec 2013 11:14:27 -0600
Subject: [wildfly-dev] Hibernate Search as a dependency
In-Reply-To: <F31B5877-0011-4ECC-ACEC-7A0D63B2919F@redhat.com>
References: <20131216161542.GE23294@hibernate.org>
	<F31B5877-0011-4ECC-ACEC-7A0D63B2919F@redhat.com>
Message-ID: <BC12D7B8-C6A4-463C-B49B-1A60DD1D1157@redhat.com>

The reason I merged the relevant PR BTW is just to help get CR out faster. I figured we can fix it before Final.

On Dec 16, 2013, at 11:12 AM, Jason Greene <jason.greene at redhat.com> wrote:

> Yes I agree that we want to remove it from at least our primary distro. The solution
> I would have preferred, but never got sent to the ML (was in my drafts folder - oops)
> was that we only pull in hibernate search to test <indexing/> but not ship it by default.
> 
> On Dec 16, 2013, at 10:15 AM, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> 
>> So recently, Hibernate Search has been added as a dependency of Wildfly.
>> I think for two reasons:
>> 
>> - Infinispan when using <indexing/> requires it
>> - CapeDwarf is a customer of Infinispan, its indexing and Hibernate
>> Search
>> 
>> I am a bit concerned about that move because Hibernate Search (depending
>> on the options you choose) can bring a significant dependency graph and
>> I don't want Wildfly to suffer from that.
>> 
>> As part of Hibernate Search, we do work and offer a Wildfly module to
>> ease the integration but it seems the work as been duplicated.
>> 
>> So my question to all of you guys is the following. Isn't it enough to
>> let Hibernate Search keep up with the module definition and let use add
>> the module when they need either Hibernate Search, Infinispan indexing
>> or CapeDwarf?
>> 
>> Emmanuel
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
> 

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat



From darran.lofthouse at jboss.com  Mon Dec 16 12:28:12 2013
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Mon, 16 Dec 2013 17:28:12 +0000
Subject: [wildfly-dev] WFLY-705: how should access restrictions get
	configured?
In-Reply-To: <52AF33A3.2060308@redhat.com>
References: <52AF33A3.2060308@redhat.com>
Message-ID: <52AF382C.3050000@jboss.com>

Personally I don't believe this is something that belongs under access 
control - this is not about changing what the user can access based on 
their client or address this is about preventing HTTP connections from 
known bad clients or locations.

As we enable cross origin request handling we are placing a certain 
amount of trust in the users browser, one purpose of this change is to 
prevent known buggy broswer versions from being able to connect to the 
HTTP management interface.

Regards,
Darran Lofthouse.


On 16/12/13 17:08, Andr? Dietisheim wrote:
> Hi
>
> I'm trying to come up with implementation for
> https://issues.jboss.org/browse/WFLY-705 where a user should be able to
> restrict access to the management service by IP and UserAgent. The
> filters are implemented and now I'm up to come up with the configuration
> options. I'm thus asking for input.
>
>  From a noob (sorry, I'm not very intimate with wildfly/undertow yet)
> perspective <access-control> looks like a compelling tag to be nested
> into <management-interfaces><http-interface>. Even though
> <access-control> is used for RBAC currently, the code for it looks
> abstract enough to get reused.
>
> Any ideas?
>
> Cheers
> Andr?
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From emmanuel at hibernate.org  Mon Dec 16 12:30:41 2013
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 16 Dec 2013 18:30:41 +0100
Subject: [wildfly-dev] Hibernate Search as a dependency
In-Reply-To: <CAMquZP5fG1a7TDD1L6EqFP6q1sYv+Y2GH2JCy7HrFZ0hvJXnGw@mail.gmail.com>
References: <20131216161542.GE23294@hibernate.org>
	<CAMquZP5fG1a7TDD1L6EqFP6q1sYv+Y2GH2JCy7HrFZ0hvJXnGw@mail.gmail.com>
Message-ID: <20131216173041.GF23294@hibernate.org>

I remember that one and I must have read Brian's mail too fast as I did
not know we were going in that direction.

Note that another problem is that Hibernate Search had dependencies on
Hibernate ORM and Infinispan (optional but at the core of the feature
set).
Infinispan has dependencies on Hibernate Search (though optional).
Wildfly has dependencies on JPA and Hibernate ORM.

So adding Hibernate Search in the distro does remove a degree of
freedom.

Emmanuel


On Mon 2013-12-16 17:26, Toma? Cerar wrote:
> This was mostly discussed as part of added bloat debate:
> 
> http://lists.jboss.org/pipermail/wildfly-dev/2013-November/001125.html
> 
> I personally am not a fan!
> 
> 
> On Mon, Dec 16, 2013 at 5:15 PM, Emmanuel Bernard <emmanuel at hibernate.org>wrote:
> 
> > So recently, Hibernate Search has been added as a dependency of Wildfly.
> > I think for two reasons:
> >
> > - Infinispan when using <indexing/> requires it
> > - CapeDwarf is a customer of Infinispan, its indexing and Hibernate
> >   Search
> >
> > I am a bit concerned about that move because Hibernate Search (depending
> > on the options you choose) can bring a significant dependency graph and
> > I don't want Wildfly to suffer from that.
> >
> > As part of Hibernate Search, we do work and offer a Wildfly module to
> > ease the integration but it seems the work as been duplicated.
> >
> > So my question to all of you guys is the following. Isn't it enough to
> > let Hibernate Search keep up with the module definition and let use add
> > the module when they need either Hibernate Search, Infinispan indexing
> > or CapeDwarf?
> >
> > Emmanuel
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >

From paul.ferraro at redhat.com  Mon Dec 16 14:01:52 2013
From: paul.ferraro at redhat.com (Paul Ferraro)
Date: Mon, 16 Dec 2013 14:01:52 -0500
Subject: [wildfly-dev] Hibernate Search as a dependency
In-Reply-To: <F31B5877-0011-4ECC-ACEC-7A0D63B2919F@redhat.com>
References: <20131216161542.GE23294@hibernate.org>
	<F31B5877-0011-4ECC-ACEC-7A0D63B2919F@redhat.com>
Message-ID: <1387220512.16013.19.camel@T520>

Just to say, the bloat is to the distribution size only, not to the
actual runtime. The infinispan-query module (and its dependencies,
including hibernate-search) is *not* imported by the default
configuration.  To use <indexing/> for an infinispan cache, you must
configure the cache container to load query module via:
<cache-container ... module="org.infinispan.query"/>
Only then are these modules loaded.

It's too bad your response never went out.  Only 2 people responded to
my original thread with an opinion - both of which advocated for adding
the dependencies...

On Mon, 2013-12-16 at 11:12 -0600, Jason Greene wrote:
> Yes I agree that we want to remove it from at least our primary distro. The solution
> I would have preferred, but never got sent to the ML (was in my drafts folder - oops)
> was that we only pull in hibernate search to test <indexing/> but not ship it by default.
> 
> On Dec 16, 2013, at 10:15 AM, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> 
> > So recently, Hibernate Search has been added as a dependency of Wildfly.
> > I think for two reasons:
> > 
> > - Infinispan when using <indexing/> requires it
> > - CapeDwarf is a customer of Infinispan, its indexing and Hibernate
> >  Search
> > 
> > I am a bit concerned about that move because Hibernate Search (depending
> > on the options you choose) can bring a significant dependency graph and
> > I don't want Wildfly to suffer from that.
> > 
> > As part of Hibernate Search, we do work and offer a Wildfly module to
> > ease the integration but it seems the work as been duplicated.
> > 
> > So my question to all of you guys is the following. Isn't it enough to
> > let Hibernate Search keep up with the module definition and let use add
> > the module when they need either Hibernate Search, Infinispan indexing
> > or CapeDwarf?
> > 
> > Emmanuel
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



From jason.greene at redhat.com  Mon Dec 16 14:38:48 2013
From: jason.greene at redhat.com (Jason Greene)
Date: Mon, 16 Dec 2013 13:38:48 -0600
Subject: [wildfly-dev] Hibernate Search as a dependency
In-Reply-To: <1387220512.16013.19.camel@T520>
References: <20131216161542.GE23294@hibernate.org>
	<F31B5877-0011-4ECC-ACEC-7A0D63B2919F@redhat.com>
	<1387220512.16013.19.camel@T520>
Message-ID: <27046974-F798-4C37-861F-456DFBE55050@redhat.com>

Yeah it?s my fault, and when your PR came in, I couldn?t reject it simply because I dropped the ball.

The space usage does look minimal, we are looking at a 129MB zip, which is actually smaller than Beta1 but fatter than Alpha4. Does this include all of the deps that someone who wants to use hibernate search needs? 

On Dec 16, 2013, at 1:01 PM, Paul Ferraro <paul.ferraro at redhat.com> wrote:

> Just to say, the bloat is to the distribution size only, not to the
> actual runtime. The infinispan-query module (and its dependencies,
> including hibernate-search) is *not* imported by the default
> configuration.  To use <indexing/> for an infinispan cache, you must
> configure the cache container to load query module via:
> <cache-container ... module="org.infinispan.query"/>
> Only then are these modules loaded.
> 
> It's too bad your response never went out.  Only 2 people responded to
> my original thread with an opinion - both of which advocated for adding
> the dependencies...
> 
> On Mon, 2013-12-16 at 11:12 -0600, Jason Greene wrote:
>> Yes I agree that we want to remove it from at least our primary distro. The solution
>> I would have preferred, but never got sent to the ML (was in my drafts folder - oops)
>> was that we only pull in hibernate search to test <indexing/> but not ship it by default.
>> 
>> On Dec 16, 2013, at 10:15 AM, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>> 
>>> So recently, Hibernate Search has been added as a dependency of Wildfly.
>>> I think for two reasons:
>>> 
>>> - Infinispan when using <indexing/> requires it
>>> - CapeDwarf is a customer of Infinispan, its indexing and Hibernate
>>> Search
>>> 
>>> I am a bit concerned about that move because Hibernate Search (depending
>>> on the options you choose) can bring a significant dependency graph and
>>> I don't want Wildfly to suffer from that.
>>> 
>>> As part of Hibernate Search, we do work and offer a Wildfly module to
>>> ease the integration but it seems the work as been duplicated.
>>> 
>>> So my question to all of you guys is the following. Isn't it enough to
>>> let Hibernate Search keep up with the module definition and let use add
>>> the module when they need either Hibernate Search, Infinispan indexing
>>> or CapeDwarf?
>>> 
>>> Emmanuel
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> 
>> --
>> Jason T. Greene
>> WildFly Lead / JBoss EAP Platform Architect
>> JBoss, a division of Red Hat
>> 
>> 
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> 

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat



From brian.stansberry at redhat.com  Mon Dec 16 15:12:50 2013
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 16 Dec 2013 14:12:50 -0600
Subject: [wildfly-dev] Configuration of statistics gathering
In-Reply-To: <52A9F489.102@redhat.com>
References: <527A6DB3.6010407@redhat.com> <52A9F489.102@redhat.com>
Message-ID: <52AF5EC2.6090602@redhat.com>

I've sent in a PR [1] that makes the changes I described for the 
messaging, transactions, resource-adapters and infinispan subsystems, 
one commit per subsystems. If the respective leads could have a look I'd 
appreciate it.

Those are the WF subsystems that have a specific attribute for this. JPA 
has an attribute, but it's part of jipijapa, so that will need to be 
corrected there [2]. JGroups has a particular property key for this 
instead of an attribute, and there is already a JIRA for updating that [3].

[1] https://github.com/wildfly/wildfly/pull/5609
[2] https://issues.jboss.org/browse/JIPI-28
[3] https://issues.jboss.org/browse/WFLY-2453

On 12/12/13 11:38 AM, Brian Stansberry wrote:
> Thanks, everyone, for the input on this.
>
> I'd like to do the following about getting configuration of these
> consistent for WF 8.0:
>
> 1) For all resources that currently expose an attribute to
> enable/disable statistics, I'll add an attribute that will be named
> "statistics-enabled". Why that?
>
> a) it's an attribute, so it's name should reflect a state, not an action
> like, for example, "enable-statistics"
> b) simply using "statistics" is shorter, but in some places that key is
> used as a child type (e.g. statistics=pool) and a resource can't have a
> child type and an attribute with the same name.
>
> 2) For compatibility, the existing attribute will be retained as an
> alias to the new one. I'll add deprecation metadata. I'll also set up
> the appropriate transformation stuff for mixed domain usage.
>
> 3) Any new stuff people do (e.g. [1], [2]), please use "statistics-enabled".
>
> 4) My intent is to make the default values for these attributes be
> "false". I won't change any default though unless the relative compoent
> lead has indicated agreement in this thread or elsewhere.
>
> But, if you disagree with "false" as the default, please let's use this
> thread to sort that out, get input from the performance team, etc, so we
> can have at least a clear understanding of why some uses have 'true'.
>
> Jesper, ^^^. ;-)
>
>
> That's for WF 8. For the next release I recommend that we also create
> subsystem-level attributes to hold the default value for the several
> cases where this setting is only configurable on a per-deployment level.
> An example would be the jpa subsystem could have a statistics-enabled
> attribute that drives the setting for all persistence units unless the
> PU descriptor overrides or the admin overrides using the existing
> per-deployment attribute. Besides being an aid to usability, having an
> attribute that ends up in the persistent configuration will also help
> deal with issues where, for example, the desired default for WildFly is
> different than the desired default for some future EAP release. The
> standard configs for the EAP release can just use a different value.
>
>
> [1] https://issues.jboss.org/browse/JBWS-3733
> [2] https://issues.jboss.org/browse/WFLY-2453
>
> On 11/6/13 10:26 AM, Brian Stansberry wrote:
>> I'd like to get some info from the component leads responsible for WF
>> subsystems.
>>
>> 1) What statistical data does your subsystem capture (including the
>> underlying libraries it integrates).
>>
>> 2) What configuration options do you support for enabling/disabling
>> statistics gathering. What's the resource address and attribute name of
>> the config option?
>>
>> 3) Is the statistic gathering enabled by default?
>>
>> Paul Ferraro's pull request [1] fixing JIRA [2] prompts this question,
>> although it's long overdue. WF should be consistent about how we handle
>> configuration of statistics gathering, so I'd like to take the
>> opportunity of Paul's PR to move in that direction.
>>
>> Thanks for your help.
>>
>
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat

From ales.justin at gmail.com  Mon Dec 16 15:32:49 2013
From: ales.justin at gmail.com (Ales Justin)
Date: Mon, 16 Dec 2013 21:32:49 +0100
Subject: [wildfly-dev] Hibernate Search as a dependency
In-Reply-To: <27046974-F798-4C37-861F-456DFBE55050@redhat.com>
References: <20131216161542.GE23294@hibernate.org>
	<F31B5877-0011-4ECC-ACEC-7A0D63B2919F@redhat.com>
	<1387220512.16013.19.camel@T520>
	<27046974-F798-4C37-861F-456DFBE55050@redhat.com>
Message-ID: <2CB78E32-6AFB-4FCB-8D98-97EEA5DA8AA7@gmail.com>

> The space usage does look minimal, we are looking at a 129MB zip, which is actually smaller than Beta1 but fatter than Alpha4. Does this include all of the deps that someone who wants to use hibernate search needs? 

I can speak for CapeDwarf -- yes, current config / deps / ... work perfectly for us.
And, imo, we're the most complex user of these things (or at least I like to image that :-)).
We use the whole stack extensively: Query, Hibernate Search, Lucene, Infinispan-Lucene, JGroups for index updates, etc

-Ales



From smarlow at redhat.com  Mon Dec 16 15:50:10 2013
From: smarlow at redhat.com (Scott Marlow)
Date: Mon, 16 Dec 2013 15:50:10 -0500
Subject: [wildfly-dev] Configuration of statistics gathering
In-Reply-To: <52AF5EC2.6090602@redhat.com>
References: <527A6DB3.6010407@redhat.com> <52A9F489.102@redhat.com>
	<52AF5EC2.6090602@redhat.com>
Message-ID: <52AF6782.9090809@redhat.com>

Should the management console changes also be done as part of this?  Or 
should separate jiras be created for updating the management console to 
use the "statistics-enabled" attribute name?

On 12/16/2013 03:12 PM, Brian Stansberry wrote:
> I've sent in a PR [1] that makes the changes I described for the
> messaging, transactions, resource-adapters and infinispan subsystems,
> one commit per subsystems. If the respective leads could have a look I'd
> appreciate it.
>
> Those are the WF subsystems that have a specific attribute for this. JPA
> has an attribute, but it's part of jipijapa, so that will need to be
> corrected there [2]. JGroups has a particular property key for this
> instead of an attribute, and there is already a JIRA for updating that [3].
>
> [1] https://github.com/wildfly/wildfly/pull/5609
> [2] https://issues.jboss.org/browse/JIPI-28
> [3] https://issues.jboss.org/browse/WFLY-2453
>
> On 12/12/13 11:38 AM, Brian Stansberry wrote:
>> Thanks, everyone, for the input on this.
>>
>> I'd like to do the following about getting configuration of these
>> consistent for WF 8.0:
>>
>> 1) For all resources that currently expose an attribute to
>> enable/disable statistics, I'll add an attribute that will be named
>> "statistics-enabled". Why that?
>>
>> a) it's an attribute, so it's name should reflect a state, not an action
>> like, for example, "enable-statistics"
>> b) simply using "statistics" is shorter, but in some places that key is
>> used as a child type (e.g. statistics=pool) and a resource can't have a
>> child type and an attribute with the same name.
>>
>> 2) For compatibility, the existing attribute will be retained as an
>> alias to the new one. I'll add deprecation metadata. I'll also set up
>> the appropriate transformation stuff for mixed domain usage.
>>
>> 3) Any new stuff people do (e.g. [1], [2]), please use "statistics-enabled".
>>
>> 4) My intent is to make the default values for these attributes be
>> "false". I won't change any default though unless the relative compoent
>> lead has indicated agreement in this thread or elsewhere.
>>
>> But, if you disagree with "false" as the default, please let's use this
>> thread to sort that out, get input from the performance team, etc, so we
>> can have at least a clear understanding of why some uses have 'true'.
>>
>> Jesper, ^^^. ;-)
>>
>>
>> That's for WF 8. For the next release I recommend that we also create
>> subsystem-level attributes to hold the default value for the several
>> cases where this setting is only configurable on a per-deployment level.
>> An example would be the jpa subsystem could have a statistics-enabled
>> attribute that drives the setting for all persistence units unless the
>> PU descriptor overrides or the admin overrides using the existing
>> per-deployment attribute. Besides being an aid to usability, having an
>> attribute that ends up in the persistent configuration will also help
>> deal with issues where, for example, the desired default for WildFly is
>> different than the desired default for some future EAP release. The
>> standard configs for the EAP release can just use a different value.
>>
>>
>> [1] https://issues.jboss.org/browse/JBWS-3733
>> [2] https://issues.jboss.org/browse/WFLY-2453
>>
>> On 11/6/13 10:26 AM, Brian Stansberry wrote:
>>> I'd like to get some info from the component leads responsible for WF
>>> subsystems.
>>>
>>> 1) What statistical data does your subsystem capture (including the
>>> underlying libraries it integrates).
>>>
>>> 2) What configuration options do you support for enabling/disabling
>>> statistics gathering. What's the resource address and attribute name of
>>> the config option?
>>>
>>> 3) Is the statistic gathering enabled by default?
>>>
>>> Paul Ferraro's pull request [1] fixing JIRA [2] prompts this question,
>>> although it's long overdue. WF should be consistent about how we handle
>>> configuration of statistics gathering, so I'd like to take the
>>> opportunity of Paul's PR to move in that direction.
>>>
>>> Thanks for your help.
>>>
>>
>>
>
>


From arjan.tijms at gmail.com  Mon Dec 16 15:54:45 2013
From: arjan.tijms at gmail.com (arjan tijms)
Date: Mon, 16 Dec 2013 21:54:45 +0100
Subject: [wildfly-dev] 13 JASPIC tests failing on WildFly
In-Reply-To: <52A9F918.6080200@redhat.com>
References: <CAE=-AhD=MJEz_TEX6E34h-wVA3wa2yHPKt-Za7KhQ91vPFS7dw@mail.gmail.com>
	<52A910C0.7080308@redhat.com>
	<CAGBoHQXoVoy71_nW8AUQhTTD4UU_+vC2EPj7Ga05=KrLwG3AwQ@mail.gmail.com>
	<52A91D89.1050409@redhat.com>
	<CAE=-AhDGAeEVY7drXjTDAHsWYMhYyoMhFWRELGh_P7b7OOy7TQ@mail.gmail.com>
	<52A9F918.6080200@redhat.com>
Message-ID: <CAE=-AhAhNyykap2Bjjf_eOqiW3FG3JOH74TQPRry3nSjRbmWHQ@mail.gmail.com>

Hi,


On Thu, Dec 12, 2013 at 6:57 PM, Stefan Guilhen <sguilhen at redhat.com> wrote:

>  Hi Arjan,
>
> These are all valid points and I agree that our implementation could use
> some improvements. I'll create a document with the points that need to be
> addressed and I propose we discuss them further next week when Pedro
> returns from his vacations.
>

Okay, sounds great!

I finally came around to add the tests for the new JASPIC 1.1
javax.servlet.http.registerSession feature. You can find it here:
https://github.com/arjantijms/javaee7-samples/tree/master/jaspic/register-session

I explained the feature some time ago on my blog at
arjan-tijms.blogspot.com/2013/04/whats-new-in-java-ee-7s-authentication.html(note
that the text is in part distilled from an email discussion I had
about this feature with Ron Monzillo). The spec issue for this feature is
at https://java.net/jira/browse/JASPIC_SPEC-3 and it's described in the
JASPIC 1.1 spec under section Section 3.8.4.

Unfortunately WildFly fails the tests for this new feature; see
https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20WildFly-cb/119/testReport/

Kind regards,
Arjan Tijms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131216/ea65a60e/attachment.html 

From tomaz.cerar at gmail.com  Mon Dec 16 16:28:00 2013
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Mon, 16 Dec 2013 22:28:00 +0100
Subject: [wildfly-dev] Per-application batch job repository
In-Reply-To: <52AF294C.1040704@redhat.com>
References: <52A7E540.6090203@redhat.com> <52A7F3C5.6020208@redhat.com>
	<52AF294C.1040704@redhat.com>
Message-ID: <CAMquZP6QBheMzH_-+qy-DcGB2cDF1ZvhVr5+aiorFkF4CmSsYg@mail.gmail.com>

On Mon, Dec 16, 2013 at 5:24 PM, Cheng Fang <cfang at redhat.com> wrote:

> introducing
> wildfly-batch.xml as an optional descriptor
>


Please don't as we have too much of deployment descriptors already.
if anything add it to jboss-all.xml as it was made to be reused as one
deployment descriptor to rule them all.

--
tomaz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131216/9d2b9ab7/attachment.html 

From brian.stansberry at redhat.com  Mon Dec 16 16:50:25 2013
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 16 Dec 2013 15:50:25 -0600
Subject: [wildfly-dev] WFLY-705: how should access restrictions get
	configured?
In-Reply-To: <52AF382C.3050000@jboss.com>
References: <52AF33A3.2060308@redhat.com> <52AF382C.3050000@jboss.com>
Message-ID: <52AF75A1.6020207@redhat.com>

Darran,

How does this related to the notion we've chatted about of incorporate 
environmental factors into role mapping?

- Brian

On 12/16/13 11:28 AM, Darran Lofthouse wrote:
> Personally I don't believe this is something that belongs under access
> control - this is not about changing what the user can access based on
> their client or address this is about preventing HTTP connections from
> known bad clients or locations.
>
> As we enable cross origin request handling we are placing a certain
> amount of trust in the users browser, one purpose of this change is to
> prevent known buggy broswer versions from being able to connect to the
> HTTP management interface.
>
> Regards,
> Darran Lofthouse.
>
>
> On 16/12/13 17:08, Andr? Dietisheim wrote:
>> Hi
>>
>> I'm trying to come up with implementation for
>> https://issues.jboss.org/browse/WFLY-705 where a user should be able to
>> restrict access to the management service by IP and UserAgent. The
>> filters are implemented and now I'm up to come up with the configuration
>> options. I'm thus asking for input.
>>
>>   From a noob (sorry, I'm not very intimate with wildfly/undertow yet)
>> perspective <access-control> looks like a compelling tag to be nested
>> into <management-interfaces><http-interface>. Even though
>> <access-control> is used for RBAC currently, the code for it looks
>> abstract enough to get reused.
>>
>> Any ideas?
>>
>> Cheers
>> Andr?
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat

From brian.stansberry at redhat.com  Mon Dec 16 17:00:48 2013
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 16 Dec 2013 16:00:48 -0600
Subject: [wildfly-dev] Configuration of statistics gathering
In-Reply-To: <52AF6782.9090809@redhat.com>
References: <527A6DB3.6010407@redhat.com> <52A9F489.102@redhat.com>
	<52AF5EC2.6090602@redhat.com> <52AF6782.9090809@redhat.com>
Message-ID: <52AF7810.3020604@redhat.com>

Good point. HAL is a separate project, so console updates need their own 
issue. I filed https://issues.jboss.org/browse/HAL-330. I'm not sure how 
Harald/Heiko will want to deal with the fact that this overall change 
will involve separate server-side changes coming in over time. I suggest 
starting with comments on HAL-330.

On 12/16/13 2:50 PM, Scott Marlow wrote:
> Should the management console changes also be done as part of this?  Or
> should separate jiras be created for updating the management console to
> use the "statistics-enabled" attribute name?
>
> On 12/16/2013 03:12 PM, Brian Stansberry wrote:
>> I've sent in a PR [1] that makes the changes I described for the
>> messaging, transactions, resource-adapters and infinispan subsystems,
>> one commit per subsystems. If the respective leads could have a look I'd
>> appreciate it.
>>
>> Those are the WF subsystems that have a specific attribute for this. JPA
>> has an attribute, but it's part of jipijapa, so that will need to be
>> corrected there [2]. JGroups has a particular property key for this
>> instead of an attribute, and there is already a JIRA for updating that
>> [3].
>>
>> [1] https://github.com/wildfly/wildfly/pull/5609
>> [2] https://issues.jboss.org/browse/JIPI-28
>> [3] https://issues.jboss.org/browse/WFLY-2453
>>
>> On 12/12/13 11:38 AM, Brian Stansberry wrote:
>>> Thanks, everyone, for the input on this.
>>>
>>> I'd like to do the following about getting configuration of these
>>> consistent for WF 8.0:
>>>
>>> 1) For all resources that currently expose an attribute to
>>> enable/disable statistics, I'll add an attribute that will be named
>>> "statistics-enabled". Why that?
>>>
>>> a) it's an attribute, so it's name should reflect a state, not an action
>>> like, for example, "enable-statistics"
>>> b) simply using "statistics" is shorter, but in some places that key is
>>> used as a child type (e.g. statistics=pool) and a resource can't have a
>>> child type and an attribute with the same name.
>>>
>>> 2) For compatibility, the existing attribute will be retained as an
>>> alias to the new one. I'll add deprecation metadata. I'll also set up
>>> the appropriate transformation stuff for mixed domain usage.
>>>
>>> 3) Any new stuff people do (e.g. [1], [2]), please use
>>> "statistics-enabled".
>>>
>>> 4) My intent is to make the default values for these attributes be
>>> "false". I won't change any default though unless the relative compoent
>>> lead has indicated agreement in this thread or elsewhere.
>>>
>>> But, if you disagree with "false" as the default, please let's use this
>>> thread to sort that out, get input from the performance team, etc, so we
>>> can have at least a clear understanding of why some uses have 'true'.
>>>
>>> Jesper, ^^^. ;-)
>>>
>>>
>>> That's for WF 8. For the next release I recommend that we also create
>>> subsystem-level attributes to hold the default value for the several
>>> cases where this setting is only configurable on a per-deployment level.
>>> An example would be the jpa subsystem could have a statistics-enabled
>>> attribute that drives the setting for all persistence units unless the
>>> PU descriptor overrides or the admin overrides using the existing
>>> per-deployment attribute. Besides being an aid to usability, having an
>>> attribute that ends up in the persistent configuration will also help
>>> deal with issues where, for example, the desired default for WildFly is
>>> different than the desired default for some future EAP release. The
>>> standard configs for the EAP release can just use a different value.
>>>
>>>
>>> [1] https://issues.jboss.org/browse/JBWS-3733
>>> [2] https://issues.jboss.org/browse/WFLY-2453
>>>
>>> On 11/6/13 10:26 AM, Brian Stansberry wrote:
>>>> I'd like to get some info from the component leads responsible for WF
>>>> subsystems.
>>>>
>>>> 1) What statistical data does your subsystem capture (including the
>>>> underlying libraries it integrates).
>>>>
>>>> 2) What configuration options do you support for enabling/disabling
>>>> statistics gathering. What's the resource address and attribute name of
>>>> the config option?
>>>>
>>>> 3) Is the statistic gathering enabled by default?
>>>>
>>>> Paul Ferraro's pull request [1] fixing JIRA [2] prompts this question,
>>>> although it's long overdue. WF should be consistent about how we handle
>>>> configuration of statistics gathering, so I'd like to take the
>>>> opportunity of Paul's PR to move in that direction.
>>>>
>>>> Thanks for your help.
>>>>
>>>
>>>
>>
>>
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat

From jperkins at redhat.com  Mon Dec 16 17:07:06 2013
From: jperkins at redhat.com (James R. Perkins)
Date: Mon, 16 Dec 2013 14:07:06 -0800
Subject: [wildfly-dev] Per-application batch job repository
In-Reply-To: <CAMquZP6QBheMzH_-+qy-DcGB2cDF1ZvhVr5+aiorFkF4CmSsYg@mail.gmail.com>
References: <52A7E540.6090203@redhat.com>
	<52A7F3C5.6020208@redhat.com>	<52AF294C.1040704@redhat.com>
	<CAMquZP6QBheMzH_-+qy-DcGB2cDF1ZvhVr5+aiorFkF4CmSsYg@mail.gmail.com>
Message-ID: <52AF798A.7030306@redhat.com>

I agree it should probably go into jboss-all. I do however think a 
deployment descriptor is the best solution. Just my opinion and I'd love 
to be swayed.

On 12/16/2013 01:28 PM, Toma? Cerar wrote:
>
> On Mon, Dec 16, 2013 at 5:24 PM, Cheng Fang <cfang at redhat.com 
> <mailto:cfang at redhat.com>> wrote:
>
>     introducing
>     wildfly-batch.xml as an optional descriptor
>
>
>
> Please don't as we have too much of deployment descriptors already.
> if anything add it to jboss-all.xml as it was made to be reused as one 
> deployment descriptor to rule them all.
>
> --
> tomaz
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-- 
James R. Perkins
Red Hat JBoss Middleware

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131216/76635500/attachment.html 

From cfang at redhat.com  Mon Dec 16 19:51:22 2013
From: cfang at redhat.com (Cheng Fang)
Date: Mon, 16 Dec 2013 19:51:22 -0500
Subject: [wildfly-dev] Per-application batch job repository
In-Reply-To: <52AF798A.7030306@redhat.com>
References: <52A7E540.6090203@redhat.com>
	<52A7F3C5.6020208@redhat.com>	<52AF294C.1040704@redhat.com>
	<CAMquZP6QBheMzH_-+qy-DcGB2cDF1ZvhVr5+aiorFkF4CmSsYg@mail.gmail.com>
	<52AF798A.7030306@redhat.com>
Message-ID: <52AFA00A.6020700@redhat.com>

jboss-all.xml sounds good.  Thanks Tomaz for the suggestion.  We just 
need some application descriptor to hold batch-related configuration.

Cheng

On 12/16/13, 5:07 PM, James R. Perkins wrote:
> I agree it should probably go into jboss-all. I do however think a 
> deployment descriptor is the best solution. Just my opinion and I'd 
> love to be swayed.
>
> On 12/16/2013 01:28 PM, Toma? Cerar wrote:
>>
>> On Mon, Dec 16, 2013 at 5:24 PM, Cheng Fang <cfang at redhat.com 
>> <mailto:cfang at redhat.com>> wrote:
>>
>>     introducing
>>     wildfly-batch.xml as an optional descriptor
>>
>>
>>
>> Please don't as we have too much of deployment descriptors already.
>> if anything add it to jboss-all.xml as it was made to be reused as 
>> one deployment descriptor to rule them all.
>>
>> --
>> tomaz
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> -- 
> James R. Perkins
> Red Hat JBoss Middleware

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131216/9b2be97c/attachment-0001.html 

From jesper.pedersen at jboss.org  Tue Dec 17 03:09:54 2013
From: jesper.pedersen at jboss.org (Jesper Pedersen)
Date: Tue, 17 Dec 2013 03:09:54 -0500
Subject: [wildfly-dev] Configuration of statistics gathering
In-Reply-To: <52AF5EC2.6090602@redhat.com>
References: <527A6DB3.6010407@redhat.com> <52A9F489.102@redhat.com>
	<52AF5EC2.6090602@redhat.com>
Message-ID: <52B006D2.4050904@jboss.org>

On 12/16/2013 03:12 PM, Brian Stansberry wrote:
> I've sent in a PR [1] that makes the changes I described for the
> messaging, transactions, resource-adapters and infinispan subsystems,
> one commit per subsystems. If the respective leads could have a look I'd
> appreciate it.
>
> [1] https://github.com/wildfly/wildfly/pull/5609

I'm ok with the code changes. HOWEVER, the default value should be true.

WildFly is a server which aims at ease for developers, so all default 
settings should reflect that. So, using a default value of false in this 
case is wrong.

This change for the IronJacamar controlled resources is in the same 
category as turning off developer mode for the web container.

Should all project leads submit pull requests that optimizes their 
subsystems against production use ?

Consider this my official -1.

Best regards,
  Jesper


From stuart.w.douglas at gmail.com  Tue Dec 17 04:59:37 2013
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Tue, 17 Dec 2013 10:59:37 +0100
Subject: [wildfly-dev] Configuration of statistics gathering
In-Reply-To: <52B006D2.4050904@jboss.org>
References: <527A6DB3.6010407@redhat.com> <52A9F489.102@redhat.com>
	<52AF5EC2.6090602@redhat.com> <52B006D2.4050904@jboss.org>
Message-ID: <CAAoo=c42MyCKmTvvANf+cF3zjy=qaUXfJxUjexeh-aGt5edZbw@mail.gmail.com>

>
> This change for the IronJacamar controlled resources is in the same
> category as turning off developer mode for the web container.
>

Just FYI don't actually have development mode in Undertow any more. Instead
we have basically tried to go for defaults that make sense for both
production and development. For example:

- JSP hot reload by default using the JDK watch service, so there is no
runtime performance penalty
- Cache invalidation using the watch service
- Error reporting by default for non-proxied requests from localhost

Stuart


>
> Should all project leads submit pull requests that optimizes their
> subsystems against production use ?
>
> Consider this my official -1.
>
> Best regards,
>   Jesper
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131217/7d16e23b/attachment.html 

From rory.odonnell at oracle.com  Tue Dec 17 08:11:13 2013
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Tue, 17 Dec 2013 13:11:13 +0000
Subject: [wildfly-dev] New JDK 8 tool: jdeps
Message-ID: <52B04D71.2020405@oracle.com>

Hi All,

Here's a blog from Erik Costlow on a new tool in JDK 8 that lets you 
analyze your code
for dependencies on JDK internal APIs :

https://blogs.oracle.com/java-platform-group/entry/closing_the_closed_apis

Please let me know if you have any feedback - I'd be interested to hear 
if you use any
internal APIs.

Rgds,Rory

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland


From sanne at hibernate.org  Tue Dec 17 08:49:02 2013
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 17 Dec 2013 13:49:02 +0000
Subject: [wildfly-dev] Hibernate Search as a dependency
In-Reply-To: <27046974-F798-4C37-861F-456DFBE55050@redhat.com>
References: <20131216161542.GE23294@hibernate.org>
	<F31B5877-0011-4ECC-ACEC-7A0D63B2919F@redhat.com>
	<1387220512.16013.19.camel@T520>
	<27046974-F798-4C37-861F-456DFBE55050@redhat.com>
Message-ID: <CAFm4XO0qDHK3=9_ef3mVORNEzmS949Vg8q9pwZejz2zasDj7NQ@mail.gmail.com>

On 16 December 2013 19:38, Jason Greene <jason.greene at redhat.com> wrote:
> Yeah it?s my fault, and when your PR came in, I couldn?t reject it simply because I dropped the ball.
>
> The space usage does look minimal, we are looking at a 129MB zip, which is actually smaller than Beta1 but fatter than Alpha4. Does this include all of the deps that someone who wants to use hibernate search needs?

Actually no, it's missing one little jar which makes the integration
with Hibernate ORM possible; in our distribution that's usually living
in a separate module. Since we have all the dependencies already, I'd
rather add the small jar which would provide high value to
Hibernate/JPA users.

Note that the version needs to be adjusted too: the version currently
included in WildFly is not compatible with the Hibernate ORM version
in WildFly: we should use at least 4.5.0.Alpha3, which is also
compatible with Infinispan (Query).

I could send pull requests to get the module in correct shape, but
only if it's going to stay? I don't want Hibernate Search users to get
confused on where the modules are to be found.

Sanne

>
> On Dec 16, 2013, at 1:01 PM, Paul Ferraro <paul.ferraro at redhat.com> wrote:
>
>> Just to say, the bloat is to the distribution size only, not to the
>> actual runtime. The infinispan-query module (and its dependencies,
>> including hibernate-search) is *not* imported by the default
>> configuration.  To use <indexing/> for an infinispan cache, you must
>> configure the cache container to load query module via:
>> <cache-container ... module="org.infinispan.query"/>
>> Only then are these modules loaded.
>>
>> It's too bad your response never went out.  Only 2 people responded to
>> my original thread with an opinion - both of which advocated for adding
>> the dependencies...
>>
>> On Mon, 2013-12-16 at 11:12 -0600, Jason Greene wrote:
>>> Yes I agree that we want to remove it from at least our primary distro. The solution
>>> I would have preferred, but never got sent to the ML (was in my drafts folder - oops)
>>> was that we only pull in hibernate search to test <indexing/> but not ship it by default.
>>>
>>> On Dec 16, 2013, at 10:15 AM, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>>>
>>>> So recently, Hibernate Search has been added as a dependency of Wildfly.
>>>> I think for two reasons:
>>>>
>>>> - Infinispan when using <indexing/> requires it
>>>> - CapeDwarf is a customer of Infinispan, its indexing and Hibernate
>>>> Search
>>>>
>>>> I am a bit concerned about that move because Hibernate Search (depending
>>>> on the options you choose) can bring a significant dependency graph and
>>>> I don't want Wildfly to suffer from that.
>>>>
>>>> As part of Hibernate Search, we do work and offer a Wildfly module to
>>>> ease the integration but it seems the work as been duplicated.
>>>>
>>>> So my question to all of you guys is the following. Isn't it enough to
>>>> let Hibernate Search keep up with the module definition and let use add
>>>> the module when they need either Hibernate Search, Infinispan indexing
>>>> or CapeDwarf?
>>>>
>>>> Emmanuel
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>> --
>>> Jason T. Greene
>>> WildFly Lead / JBoss EAP Platform Architect
>>> JBoss, a division of Red Hat
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From darran.lofthouse at jboss.com  Tue Dec 17 09:48:20 2013
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Tue, 17 Dec 2013 14:48:20 +0000
Subject: [wildfly-dev] WFLY-705: how should access restrictions get
	configured?
In-Reply-To: <52AF75A1.6020207@redhat.com>
References: <52AF33A3.2060308@redhat.com> <52AF382C.3050000@jboss.com>
	<52AF75A1.6020207@redhat.com>
Message-ID: <52B06434.8000700@jboss.com>

The main purpose of the Jira issue is just for a blanked block on known 
bad browsers - it is not intended to take any part of 'If you use 
Internet Explorer you can be a Monitor but if you use Firefox you can be 
SuperUser'.

Regards,
Darran Lofthouse.


On 16/12/13 21:50, Brian Stansberry wrote:
> Darran,
>
> How does this related to the notion we've chatted about of incorporate
> environmental factors into role mapping?
>
> - Brian
>
> On 12/16/13 11:28 AM, Darran Lofthouse wrote:
>> Personally I don't believe this is something that belongs under access
>> control - this is not about changing what the user can access based on
>> their client or address this is about preventing HTTP connections from
>> known bad clients or locations.
>>
>> As we enable cross origin request handling we are placing a certain
>> amount of trust in the users browser, one purpose of this change is to
>> prevent known buggy broswer versions from being able to connect to the
>> HTTP management interface.
>>
>> Regards,
>> Darran Lofthouse.
>>
>>
>> On 16/12/13 17:08, Andr? Dietisheim wrote:
>>> Hi
>>>
>>> I'm trying to come up with implementation for
>>> https://issues.jboss.org/browse/WFLY-705 where a user should be able to
>>> restrict access to the management service by IP and UserAgent. The
>>> filters are implemented and now I'm up to come up with the configuration
>>> options. I'm thus asking for input.
>>>
>>>    From a noob (sorry, I'm not very intimate with wildfly/undertow yet)
>>> perspective <access-control> looks like a compelling tag to be nested
>>> into <management-interfaces><http-interface>. Even though
>>> <access-control> is used for RBAC currently, the code for it looks
>>> abstract enough to get reused.
>>>
>>> Any ideas?
>>>
>>> Cheers
>>> Andr?
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>

From smarlow at redhat.com  Tue Dec 17 09:51:25 2013
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 17 Dec 2013 09:51:25 -0500
Subject: [wildfly-dev] Hibernate Search as a dependency
In-Reply-To: <CAFm4XO0qDHK3=9_ef3mVORNEzmS949Vg8q9pwZejz2zasDj7NQ@mail.gmail.com>
References: <20131216161542.GE23294@hibernate.org>	<F31B5877-0011-4ECC-ACEC-7A0D63B2919F@redhat.com>	<1387220512.16013.19.camel@T520>	<27046974-F798-4C37-861F-456DFBE55050@redhat.com>
	<CAFm4XO0qDHK3=9_ef3mVORNEzmS949Vg8q9pwZejz2zasDj7NQ@mail.gmail.com>
Message-ID: <52B064ED.2000407@redhat.com>

On 12/17/2013 08:49 AM, Sanne Grinovero wrote:
> On 16 December 2013 19:38, Jason Greene <jason.greene at redhat.com> wrote:
>> Yeah it?s my fault, and when your PR came in, I couldn?t reject it simply because I dropped the ball.
>>
>> The space usage does look minimal, we are looking at a 129MB zip, which is actually smaller than Beta1 but fatter than Alpha4. Does this include all of the deps that someone who wants to use hibernate search needs?
>
> Actually no, it's missing one little jar which makes the integration
> with Hibernate ORM possible; in our distribution that's usually living
> in a separate module. Since we have all the dependencies already, I'd
> rather add the small jar which would provide high value to
> Hibernate/JPA users.
>
> Note that the version needs to be adjusted too: the version currently
> included in WildFly is not compatible with the Hibernate ORM version
> in WildFly: we should use at least 4.5.0.Alpha3, which is also
> compatible with Infinispan (Query).
>
> I could send pull requests to get the module in correct shape, but
> only if it's going to stay? I don't want Hibernate Search users to get
> confused on where the modules are to be found.

Sanne,

Do you want Hibernate Search to stay in WildFly?  If yes, do you also 
want Hibernate Search to be in EAP.nextMajorVersion?

Scott

>
> Sanne
>
>>
>> On Dec 16, 2013, at 1:01 PM, Paul Ferraro <paul.ferraro at redhat.com> wrote:
>>
>>> Just to say, the bloat is to the distribution size only, not to the
>>> actual runtime. The infinispan-query module (and its dependencies,
>>> including hibernate-search) is *not* imported by the default
>>> configuration.  To use <indexing/> for an infinispan cache, you must
>>> configure the cache container to load query module via:
>>> <cache-container ... module="org.infinispan.query"/>
>>> Only then are these modules loaded.
>>>
>>> It's too bad your response never went out.  Only 2 people responded to
>>> my original thread with an opinion - both of which advocated for adding
>>> the dependencies...
>>>
>>> On Mon, 2013-12-16 at 11:12 -0600, Jason Greene wrote:
>>>> Yes I agree that we want to remove it from at least our primary distro. The solution
>>>> I would have preferred, but never got sent to the ML (was in my drafts folder - oops)
>>>> was that we only pull in hibernate search to test <indexing/> but not ship it by default.
>>>>
>>>> On Dec 16, 2013, at 10:15 AM, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>>>>
>>>>> So recently, Hibernate Search has been added as a dependency of Wildfly.
>>>>> I think for two reasons:
>>>>>
>>>>> - Infinispan when using <indexing/> requires it
>>>>> - CapeDwarf is a customer of Infinispan, its indexing and Hibernate
>>>>> Search
>>>>>
>>>>> I am a bit concerned about that move because Hibernate Search (depending
>>>>> on the options you choose) can bring a significant dependency graph and
>>>>> I don't want Wildfly to suffer from that.
>>>>>
>>>>> As part of Hibernate Search, we do work and offer a Wildfly module to
>>>>> ease the integration but it seems the work as been duplicated.
>>>>>
>>>>> So my question to all of you guys is the following. Isn't it enough to
>>>>> let Hibernate Search keep up with the module definition and let use add
>>>>> the module when they need either Hibernate Search, Infinispan indexing
>>>>> or CapeDwarf?
>>>>>
>>>>> Emmanuel
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>> --
>>>> Jason T. Greene
>>>> WildFly Lead / JBoss EAP Platform Architect
>>>> JBoss, a division of Red Hat
>>>>
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>>
>> --
>> Jason T. Greene
>> WildFly Lead / JBoss EAP Platform Architect
>> JBoss, a division of Red Hat
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


From brian.stansberry at redhat.com  Tue Dec 17 10:00:36 2013
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 17 Dec 2013 09:00:36 -0600
Subject: [wildfly-dev] Configuration of statistics gathering
In-Reply-To: <52B006D2.4050904@jboss.org>
References: <527A6DB3.6010407@redhat.com>
	<52A9F489.102@redhat.com>	<52AF5EC2.6090602@redhat.com>
	<52B006D2.4050904@jboss.org>
Message-ID: <52B06714.6040600@redhat.com>

On 12/17/13 2:09 AM, Jesper Pedersen wrote:
> On 12/16/2013 03:12 PM, Brian Stansberry wrote:
>> I've sent in a PR [1] that makes the changes I described for the
>> messaging, transactions, resource-adapters and infinispan subsystems,
>> one commit per subsystems. If the respective leads could have a look I'd
>> appreciate it.
>>
>> [1] https://github.com/wildfly/wildfly/pull/5609
>
> I'm ok with the code changes. HOWEVER, the default value should be true.
>

AFAICT, the resource-adapter commit did nothing to change any default. 
So if it was true, it still is true.

Looking at it, I see the existing code doesn't state the default as part 
of the metadata, so the user doesn't know. That should be fixed.

> WildFly is a server which aims at ease for developers, so all default
> settings should reflect that. So, using a default value of false in this
> case is wrong.
>
> This change for the IronJacamar controlled resources is in the same
> category as turning off developer mode for the web container.
>
> Should all project leads submit pull requests that optimizes their
> subsystems against production use ?
>

I'm not asking for that.

Earlier in this thread I threw out a suggestion for a subsystem-level 
attribute that could serve as a default and could easily have a 
different value in our standard configs for EAP vs WF. If anyone has a 
better idea, I'd love hear it. If not, patches would be nice if someone 
wants to do that.

> Consider this my official -1.

Please explain how the resource-adapter commit relates to your concerns.

>
> Best regards,
>    Jesper
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat

From brian.stansberry at redhat.com  Tue Dec 17 10:25:01 2013
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 17 Dec 2013 09:25:01 -0600
Subject: [wildfly-dev] WFLY-705: how should access restrictions get
	configured?
In-Reply-To: <52B06434.8000700@jboss.com>
References: <52AF33A3.2060308@redhat.com>
	<52AF382C.3050000@jboss.com>	<52AF75A1.6020207@redhat.com>
	<52B06434.8000700@jboss.com>
Message-ID: <52B06CCD.2010605@redhat.com>

Agreed that <access-control> isn't the appropriate location. For anyone 
interested, here's a chat Darran and I had:

bstansberry: darranl: read your email
[09:05am] bstansberry: darranl: I'm still not clear on the boundary though
[09:06am] bstansberry: darranl: I can see how using a blacklisted 
browser would mean you can't auth or that you can't map to *any* role
[09:07am] bstansberry: darranl: and I can see how the "any role" part 
could be a config pain if it meant having to repeat some config for 
every role
[09:07am] bstansberry: plus create holes
[09:09am] bstansberry: darranl: I'm not really trying to advocate for 
making this part of role mapping
[09:09am] bstansberry: more that I want to have a clearer conceptual 
line for why something is in one place or another

[09:11am] darranl: Another item of configuration that I will pair with 
this hopefully soon is the enablement of cross origin request handling, 
that is also going to be http specific and will be dependent on this 
banning of bad browsers so that we can ban a browser if we don't believe 
it handles cross origin requests safely. Overall I believe this falls 
under what can connect to HTTP not what can they do once connected and 
that to me is the differentiator between mak
[09:11am] darranl: ing it a http management interface config item or 
general access control item.
[09:13am] darranl: The remote address aspect however is something 
different, that can apply equally to all management interface types and 
I could see the location of an administrator being considered when 
deciding what they can do.

[09:14am] bstansberry: darranl: ok, that's sounding better
[09:14am] bstansberry: darranl: the notion that the connection is 
encrypted can follow that rationale as well
[09:14am] darranl: bstansberry, exactly
[09:15am] bstansberry: darranl: great; that's what I was looking for -- 
if it's protocol specific, it's not <access-control>
[09:16am] bstansberry: better stated -- if it's specific to a particular 
management interface type

On 12/17/13 8:48 AM, Darran Lofthouse wrote:
> The main purpose of the Jira issue is just for a blanked block on known
> bad browsers - it is not intended to take any part of 'If you use
> Internet Explorer you can be a Monitor but if you use Firefox you can be
> SuperUser'.
>
> Regards,
> Darran Lofthouse.
>
>
> On 16/12/13 21:50, Brian Stansberry wrote:
>> Darran,
>>
>> How does this related to the notion we've chatted about of incorporate
>> environmental factors into role mapping?
>>
>> - Brian
>>
>> On 12/16/13 11:28 AM, Darran Lofthouse wrote:
>>> Personally I don't believe this is something that belongs under access
>>> control - this is not about changing what the user can access based on
>>> their client or address this is about preventing HTTP connections from
>>> known bad clients or locations.
>>>
>>> As we enable cross origin request handling we are placing a certain
>>> amount of trust in the users browser, one purpose of this change is to
>>> prevent known buggy broswer versions from being able to connect to the
>>> HTTP management interface.
>>>
>>> Regards,
>>> Darran Lofthouse.
>>>
>>>
>>> On 16/12/13 17:08, Andr? Dietisheim wrote:
>>>> Hi
>>>>
>>>> I'm trying to come up with implementation for
>>>> https://issues.jboss.org/browse/WFLY-705 where a user should be able to
>>>> restrict access to the management service by IP and UserAgent. The
>>>> filters are implemented and now I'm up to come up with the configuration
>>>> options. I'm thus asking for input.
>>>>
>>>>     From a noob (sorry, I'm not very intimate with wildfly/undertow yet)
>>>> perspective <access-control> looks like a compelling tag to be nested
>>>> into <management-interfaces><http-interface>. Even though
>>>> <access-control> is used for RBAC currently, the code for it looks
>>>> abstract enough to get reused.
>>>>
>>>> Any ideas?
>>>>
>>>> Cheers
>>>> Andr?
>>>>
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat

From jesper.pedersen at jboss.org  Tue Dec 17 11:03:49 2013
From: jesper.pedersen at jboss.org (Jesper Pedersen)
Date: Tue, 17 Dec 2013 11:03:49 -0500
Subject: [wildfly-dev] Configuration of statistics gathering
In-Reply-To: <52B06714.6040600@redhat.com>
References: <527A6DB3.6010407@redhat.com>	<52A9F489.102@redhat.com>	<52AF5EC2.6090602@redhat.com>	<52B006D2.4050904@jboss.org>
	<52B06714.6040600@redhat.com>
Message-ID: <52B075E5.6000206@jboss.org>

On 12/17/2013 10:00 AM, Brian Stansberry wrote:
> AFAICT, the resource-adapter commit did nothing to change any default.
> So if it was true, it still is true.
>

Ok, the missing AttributeDefinition's in the write handler threw me off.

> Looking at it, I see the existing code doesn't state the default as part
> of the metadata, so the user doesn't know. That should be fixed.
>

You mean the description of the resource, right ? Not an actual 
deployment attribute exposed in the subsystem.

> Earlier in this thread I threw out a suggestion for a subsystem-level
> attribute that could serve as a default and could easily have a
> different value in our standard configs for EAP vs WF. If anyone has a
> better idea, I'd love hear it. If not, patches would be nice if someone
> wants to do that.
>

Not other than an attribute in a META-INF/wildfly.xml file at EAR level.

> Please explain how the resource-adapter commit relates to your concerns.
>

Actually, DWM has two levels of statistics (local node / entire 
network), but let me comment on the PR instead.

Best regards,
  Jesper


From brian.stansberry at redhat.com  Tue Dec 17 11:14:14 2013
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 17 Dec 2013 10:14:14 -0600
Subject: [wildfly-dev] Configuration of statistics gathering
In-Reply-To: <52B075E5.6000206@jboss.org>
References: <527A6DB3.6010407@redhat.com>	<52A9F489.102@redhat.com>	<52AF5EC2.6090602@redhat.com>	<52B006D2.4050904@jboss.org>	<52B06714.6040600@redhat.com>
	<52B075E5.6000206@jboss.org>
Message-ID: <52B07856.7060404@redhat.com>

On 12/17/13 10:03 AM, Jesper Pedersen wrote:
> On 12/17/2013 10:00 AM, Brian Stansberry wrote:
>> AFAICT, the resource-adapter commit did nothing to change any default.
>> So if it was true, it still is true.
>>
>
> Ok, the missing AttributeDefinition's in the write handler threw me off.
>

Aha! I'll comment on the PR re: that as it could use explanation.

>> Looking at it, I see the existing code doesn't state the default as part
>> of the metadata, so the user doesn't know. That should be fixed.
>>
>
> You mean the description of the resource, right ? Not an actual
> deployment attribute exposed in the subsystem.
>
>> Earlier in this thread I threw out a suggestion for a subsystem-level
>> attribute that could serve as a default and could easily have a
>> different value in our standard configs for EAP vs WF. If anyone has a
>> better idea, I'd love hear it. If not, patches would be nice if someone
>> wants to do that.
>>
>
> Not other than an attribute in a META-INF/wildfly.xml file at EAR level.
>
>> Please explain how the resource-adapter commit relates to your concerns.
>>
>
> Actually, DWM has two levels of statistics (local node / entire
> network), but let me comment on the PR instead.
>
> Best regards,
>    Jesper
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat

From smarlow at redhat.com  Tue Dec 17 14:58:36 2013
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 17 Dec 2013 14:58:36 -0500
Subject: [wildfly-dev] Configuration of statistics gathering
In-Reply-To: <52AF7810.3020604@redhat.com>
References: <527A6DB3.6010407@redhat.com> <52A9F489.102@redhat.com>
	<52AF5EC2.6090602@redhat.com> <52AF6782.9090809@redhat.com>
	<52AF7810.3020604@redhat.com>
Message-ID: <52B0ACEC.5050600@redhat.com>

https://issues.jboss.org/browse/WFLY-2665 covers the JPA 
"statistics-enabled" change (brings in jipijapa 1.0.1.CR1) if we decide 
to merge https://github.com/wildfly/wildfly/pull/5609 into WF8.

On 12/16/2013 05:00 PM, Brian Stansberry wrote:
> Good point. HAL is a separate project, so console updates need their own
> issue. I filed https://issues.jboss.org/browse/HAL-330. I'm not sure how
> Harald/Heiko will want to deal with the fact that this overall change
> will involve separate server-side changes coming in over time. I suggest
> starting with comments on HAL-330.
>
> On 12/16/13 2:50 PM, Scott Marlow wrote:
>> Should the management console changes also be done as part of this?  Or
>> should separate jiras be created for updating the management console to
>> use the "statistics-enabled" attribute name?
>>
>> On 12/16/2013 03:12 PM, Brian Stansberry wrote:
>>> I've sent in a PR [1] that makes the changes I described for the
>>> messaging, transactions, resource-adapters and infinispan subsystems,
>>> one commit per subsystems. If the respective leads could have a look I'd
>>> appreciate it.
>>>
>>> Those are the WF subsystems that have a specific attribute for this. JPA
>>> has an attribute, but it's part of jipijapa, so that will need to be
>>> corrected there [2]. JGroups has a particular property key for this
>>> instead of an attribute, and there is already a JIRA for updating that
>>> [3].
>>>
>>> [1] https://github.com/wildfly/wildfly/pull/5609
>>> [2] https://issues.jboss.org/browse/JIPI-28
>>> [3] https://issues.jboss.org/browse/WFLY-2453
>>>
>>> On 12/12/13 11:38 AM, Brian Stansberry wrote:
>>>> Thanks, everyone, for the input on this.
>>>>
>>>> I'd like to do the following about getting configuration of these
>>>> consistent for WF 8.0:
>>>>
>>>> 1) For all resources that currently expose an attribute to
>>>> enable/disable statistics, I'll add an attribute that will be named
>>>> "statistics-enabled". Why that?
>>>>
>>>> a) it's an attribute, so it's name should reflect a state, not an
>>>> action
>>>> like, for example, "enable-statistics"
>>>> b) simply using "statistics" is shorter, but in some places that key is
>>>> used as a child type (e.g. statistics=pool) and a resource can't have a
>>>> child type and an attribute with the same name.
>>>>
>>>> 2) For compatibility, the existing attribute will be retained as an
>>>> alias to the new one. I'll add deprecation metadata. I'll also set up
>>>> the appropriate transformation stuff for mixed domain usage.
>>>>
>>>> 3) Any new stuff people do (e.g. [1], [2]), please use
>>>> "statistics-enabled".
>>>>
>>>> 4) My intent is to make the default values for these attributes be
>>>> "false". I won't change any default though unless the relative compoent
>>>> lead has indicated agreement in this thread or elsewhere.
>>>>
>>>> But, if you disagree with "false" as the default, please let's use this
>>>> thread to sort that out, get input from the performance team, etc,
>>>> so we
>>>> can have at least a clear understanding of why some uses have 'true'.
>>>>
>>>> Jesper, ^^^. ;-)
>>>>
>>>>
>>>> That's for WF 8. For the next release I recommend that we also create
>>>> subsystem-level attributes to hold the default value for the several
>>>> cases where this setting is only configurable on a per-deployment
>>>> level.
>>>> An example would be the jpa subsystem could have a statistics-enabled
>>>> attribute that drives the setting for all persistence units unless the
>>>> PU descriptor overrides or the admin overrides using the existing
>>>> per-deployment attribute. Besides being an aid to usability, having an
>>>> attribute that ends up in the persistent configuration will also help
>>>> deal with issues where, for example, the desired default for WildFly is
>>>> different than the desired default for some future EAP release. The
>>>> standard configs for the EAP release can just use a different value.
>>>>
>>>>
>>>> [1] https://issues.jboss.org/browse/JBWS-3733
>>>> [2] https://issues.jboss.org/browse/WFLY-2453
>>>>
>>>> On 11/6/13 10:26 AM, Brian Stansberry wrote:
>>>>> I'd like to get some info from the component leads responsible for WF
>>>>> subsystems.
>>>>>
>>>>> 1) What statistical data does your subsystem capture (including the
>>>>> underlying libraries it integrates).
>>>>>
>>>>> 2) What configuration options do you support for enabling/disabling
>>>>> statistics gathering. What's the resource address and attribute
>>>>> name of
>>>>> the config option?
>>>>>
>>>>> 3) Is the statistic gathering enabled by default?
>>>>>
>>>>> Paul Ferraro's pull request [1] fixing JIRA [2] prompts this question,
>>>>> although it's long overdue. WF should be consistent about how we
>>>>> handle
>>>>> configuration of statistics gathering, so I'd like to take the
>>>>> opportunity of Paul's PR to move in that direction.
>>>>>
>>>>> Thanks for your help.
>>>>>
>>>>
>>>>
>>>
>>>
>>
>
>


From jason.greene at redhat.com  Tue Dec 17 15:06:46 2013
From: jason.greene at redhat.com (Jason Greene)
Date: Tue, 17 Dec 2013 14:06:46 -0600
Subject: [wildfly-dev] Configuration of statistics gathering
In-Reply-To: <52B006D2.4050904@jboss.org>
References: <527A6DB3.6010407@redhat.com> <52A9F489.102@redhat.com>
	<52AF5EC2.6090602@redhat.com> <52B006D2.4050904@jboss.org>
Message-ID: <1E5B8B24-A611-4940-9A98-B7C6F5040560@redhat.com>


On Dec 17, 2013, at 2:09 AM, Jesper Pedersen <jesper.pedersen at jboss.org> wrote:

> 
> I'm ok with the code changes. HOWEVER, the default value should be true.
> 
> WildFly is a server which aims at ease for developers, so all default 
> settings should reflect that. So, using a default value of false in this 
> case is wrong.

I disagree that statistics are a developer concern. IMO they are more of a production debugging feature and you only need them if you plan to look at them. Otherwise it?s really just a bottleneck.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat



From jason.greene at redhat.com  Tue Dec 17 15:14:18 2013
From: jason.greene at redhat.com (Jason Greene)
Date: Tue, 17 Dec 2013 14:14:18 -0600
Subject: [wildfly-dev] Configuration of statistics gathering
In-Reply-To: <1E5B8B24-A611-4940-9A98-B7C6F5040560@redhat.com>
References: <527A6DB3.6010407@redhat.com> <52A9F489.102@redhat.com>
	<52AF5EC2.6090602@redhat.com> <52B006D2.4050904@jboss.org>
	<1E5B8B24-A611-4940-9A98-B7C6F5040560@redhat.com>
Message-ID: <9345E81A-89F1-4069-B2D2-EFDF7B854583@redhat.com>


On Dec 17, 2013, at 2:06 PM, Jason Greene <jason.greene at redhat.com> wrote:

> 
> On Dec 17, 2013, at 2:09 AM, Jesper Pedersen <jesper.pedersen at jboss.org> wrote:
> 
>> 
>> I'm ok with the code changes. HOWEVER, the default value should be true.
>> 
>> WildFly is a server which aims at ease for developers, so all default 
>> settings should reflect that. So, using a default value of false in this 
>> case is wrong.
> 
> I disagree that statistics are a developer concern. IMO they are more of a production debugging feature and you only need them if you plan to look at them. Otherwise it?s really just a bottleneck.

Slight tangent. We should test out LongAdder for connection pool stats at some point. It should make a significant perf difference.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat



From anmiller at redhat.com  Tue Dec 17 15:36:30 2013
From: anmiller at redhat.com (Andrig Miller)
Date: Tue, 17 Dec 2013 15:36:30 -0500 (EST)
Subject: [wildfly-dev] Configuration of statistics gathering
In-Reply-To: <1E5B8B24-A611-4940-9A98-B7C6F5040560@redhat.com>
References: <527A6DB3.6010407@redhat.com> <52A9F489.102@redhat.com>
	<52AF5EC2.6090602@redhat.com> <52B006D2.4050904@jboss.org>
	<1E5B8B24-A611-4940-9A98-B7C6F5040560@redhat.com>
Message-ID: <24717317.60.1387312586965.JavaMail.andrig@worklaptop.miller.org>



----- Original Message -----
> From: "Jason Greene" <jason.greene at redhat.com>
> To: "Jesper Pedersen" <jesper.pedersen at jboss.org>
> Cc: wildfly-dev at lists.jboss.org
> Sent: Tuesday, December 17, 2013 1:06:46 PM
> Subject: Re: [wildfly-dev] Configuration of statistics gathering
> 
> 
> On Dec 17, 2013, at 2:09 AM, Jesper Pedersen
> <jesper.pedersen at jboss.org> wrote:
> 
> > 
> > I'm ok with the code changes. HOWEVER, the default value should be
> > true.
> > 
> > WildFly is a server which aims at ease for developers, so all
> > default
> > settings should reflect that. So, using a default value of false in
> > this
> > case is wrong.
> 
> I disagree that statistics are a developer concern. IMO they are more
> of a production debugging feature and you only need them if you plan
> to look at them. Otherwise it?s really just a bottleneck.
> 

+1

The default should be false, not just because its not a developer concern, which I agree with as illustrated by my +1, but because we also want the out-of-the-box performance experience to be as good as it can be.

I would rather not have to explain the 1,000 things you have to change in the configuration to get the best performance.  We should only have to change those things that may have specific benefits to specific application deployments.  General items like this, should already be configured in such a way as to yield the best performance.

Andy

> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 


From anmiller at redhat.com  Tue Dec 17 15:38:00 2013
From: anmiller at redhat.com (Andrig Miller)
Date: Tue, 17 Dec 2013 15:38:00 -0500 (EST)
Subject: [wildfly-dev] Configuration of statistics gathering
In-Reply-To: <9345E81A-89F1-4069-B2D2-EFDF7B854583@redhat.com>
References: <527A6DB3.6010407@redhat.com> <52A9F489.102@redhat.com>
	<52AF5EC2.6090602@redhat.com> <52B006D2.4050904@jboss.org>
	<1E5B8B24-A611-4940-9A98-B7C6F5040560@redhat.com>
	<9345E81A-89F1-4069-B2D2-EFDF7B854583@redhat.com>
Message-ID: <21076995.61.1387312677531.JavaMail.andrig@worklaptop.miller.org>



----- Original Message -----
> From: "Jason Greene" <jason.greene at redhat.com>
> To: "Jesper Pedersen" <jesper.pedersen at jboss.org>
> Cc: wildfly-dev at lists.jboss.org
> Sent: Tuesday, December 17, 2013 1:14:18 PM
> Subject: Re: [wildfly-dev] Configuration of statistics gathering
> 
> 
> On Dec 17, 2013, at 2:06 PM, Jason Greene <jason.greene at redhat.com>
> wrote:
> 
> > 
> > On Dec 17, 2013, at 2:09 AM, Jesper Pedersen
> > <jesper.pedersen at jboss.org> wrote:
> > 
> >> 
> >> I'm ok with the code changes. HOWEVER, the default value should be
> >> true.
> >> 
> >> WildFly is a server which aims at ease for developers, so all
> >> default
> >> settings should reflect that. So, using a default value of false
> >> in this
> >> case is wrong.
> > 
> > I disagree that statistics are a developer concern. IMO they are
> > more of a production debugging feature and you only need them if
> > you plan to look at them. Otherwise it?s really just a bottleneck.
> 
> Slight tangent. We should test out LongAdder for connection pool
> stats at some point. It should make a significant perf difference.
> 

Yes, I would like to bring this in for all the stats, so they have the least amount of impact when they are on.  I understand Infinispan is already using it, but we had to turn off their stats too to get the best second-level cache performance (made a big difference even with LongAdder).

Andy

> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 


From jason.greene at redhat.com  Tue Dec 17 17:48:54 2013
From: jason.greene at redhat.com (Jason Greene)
Date: Tue, 17 Dec 2013 16:48:54 -0600
Subject: [wildfly-dev] Intermittent Yet Frequent Failure in JmsClientTestCase
Message-ID: <25A2E6D3-6467-4214-8AE7-1C34AC55EA3B@redhat.com>

I merged the one-port hq PR (thanks for that!)

Although now I am seeing this:
http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=7156&tab=buildResultsDiv&buildTypeId=WF_MasterLinux

Can you look into it. I might have to revert it tomorrow if there isn?t a simple fix.

Thanks

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat



From jmesnil at redhat.com  Wed Dec 18 02:22:05 2013
From: jmesnil at redhat.com (Jeff Mesnil)
Date: Wed, 18 Dec 2013 08:22:05 +0100
Subject: [wildfly-dev] Intermittent Yet Frequent Failure in
	JmsClientTestCase
In-Reply-To: <25A2E6D3-6467-4214-8AE7-1C34AC55EA3B@redhat.com>
References: <25A2E6D3-6467-4214-8AE7-1C34AC55EA3B@redhat.com>
Message-ID: <4EA14988-4618-43B2-9AB6-91E12B085EF7@redhat.com>


On 17 Dec 2013, at 23:48, Jason Greene <jason.greene at redhat.com> wrote:

> I merged the one-port hq PR (thanks for that!)
> 
> Although now I am seeing this:
> http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=7156&tab=buildResultsDiv&buildTypeId=WF_MasterLinux
> 
> Can you look into it. I might have to revert it tomorrow if there isn?t a simple fix.

I?ll look into it now.

jeff

-- 
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/



From jmesnil at redhat.com  Wed Dec 18 09:21:59 2013
From: jmesnil at redhat.com (Jeff Mesnil)
Date: Wed, 18 Dec 2013 15:21:59 +0100
Subject: [wildfly-dev] Intermittent Yet Frequent Failure in
	JmsClientTestCase
In-Reply-To: <25A2E6D3-6467-4214-8AE7-1C34AC55EA3B@redhat.com>
References: <25A2E6D3-6467-4214-8AE7-1C34AC55EA3B@redhat.com>
Message-ID: <23BA56F0-B55A-4390-97A3-7942227659BE@redhat.com>


On 17 Dec 2013, at 23:48, Jason Greene <jason.greene at redhat.com> wrote:

> I merged the one-port hq PR (thanks for that!)
> 
> Although now I am seeing this:
> http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=7156&tab=buildResultsDiv&buildTypeId=WF_MasterLinux
> 
> Can you look into it. I might have to revert it tomorrow if there isn?t a simple fix.

It was a bug in the netty-xnio bridge that norman promptly fixed.

I?ve opened a PR for it: https://github.com/wildfly/wildfly/pull/5625

jeff

-- 
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/



From kustos at gmx.net  Wed Dec 18 09:53:55 2013
From: kustos at gmx.net (Philippe Marschall)
Date: Wed, 18 Dec 2013 15:53:55 +0100
Subject: [wildfly-dev] New JDK 8 tool: jdeps
In-Reply-To: <52B04D71.2020405@oracle.com>
References: <52B04D71.2020405@oracle.com>
Message-ID: <52B1B703.7000509@gmx.net>



On 17.12.2013 14:11, Rory O'Donnell wrote:
> Hi All,
>
> Here's a blog from Erik Costlow on a new tool in JDK 8 that lets you
> analyze your code
> for dependencies on JDK internal APIs :
>
> https://blogs.oracle.com/java-platform-group/entry/closing_the_closed_apis
>
> Please let me know if you have any feedback - I'd be interested to hear
> if you use any
> internal APIs.

I ran the tool and here's the output:
  - codemodel (a Sun/Oracle project nonetheless) uses sun.nio.cs.Surrogate
  - jaxb-xjc (a Sun/Oracle project nonetheless) uses 
com.sun.org.apache.xml.internal.resolver
  - jacorb uses sun.security.jgss.spi
  - xalan uses org.apache.xpath.domapi (this looks like a false positive)
  - xom uses com.sun.org.apache.xerces.internal
  - xnio-nio uses the following classes through reflection 
(Class.forName) sun.nio.ch.KQueueSelectorProvider, 
sun.nio.ch.EPollSelectorProvider, sun.nio.ch.DevPollSelectorProvider, 
sun.nio.ch.PollsetSelectorProvider, sun.nio.ch.PollSelectorProvider, 
sun.nio.ch.PollSelectorImpl. This looks like a limitation of jdeps that 
it doesn't catch Class.forName.
  - undertow-core tests use com.sun.security.auth.module.Krb5LoginModule
  - wildfly-security uses com.sun.security.auth.module.Krb5LoginModule
  - wildfly-domain-managment uses com.sun.jndi.ldap.LdapCtxFactory
  - wildfly-ts-integ-basic uses sun.security.tools.JarSigner, 
com.sun.jndi.cosnaming.CNCtxFactory, com.sun.jndi.ldap.LdapCtx, 
com.sun.jndi.ldap.LdapCtxFactory and sun.tools.jar.resources.jar
  - wildfly-testsuite-shared uses 
com.sun.security.auth.module.Krb5LoginModule

sun.misc.Signal and sun.misc.SignalHandler are used in several places 
(AFAIK there's still not API for this)
  - aesh
  - jboss-cli-client

sun.reflect.ReflectionFactory and sun.reflect.Reflection are used in 
several places
  - jboss-client
  - jboss-cli-client
  - jboss-rmi-api_1.0_spec
  - jboss-marshalling
  - undertow-servlet
  - wildfly-security-manager

sun.misc.Cleaner is used in several places (AFAIK you're still unwilling 
to provide an API for this)
  - jboss-client
  - netty-all

sun.misc.Unsafe is used all over the place
  - avro
  - guava
  - infinispan-commons
  - jboss-client
  - jboss-modules
  - jboss-rmi-api_1.0_spec
  - netty-all
  - undertow-core
  - wildfly-mod_cluster-undertow

Cheers
Philippe
-------------- next part --------------
activation-1.1.1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
aesh-0.33.11.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
aesh-0.33.11.jar -> jansi-1.9.jar
   org.jboss.aesh.console.helper.InterruptHandler (aesh-0.33.11.jar)
      -> sun.misc.Signal                                    JDK internal API (rt.jar)
      -> sun.misc.SignalHandler                             JDK internal API (rt.jar)
   org.jboss.aesh.console.helper.InterruptHandler$1 (aesh-0.33.11.jar)
      -> sun.misc.Signal                                    JDK internal API (rt.jar)
      -> sun.misc.SignalHandler                             JDK internal API (rt.jar)
antlr-2.7.7.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
apache-mime4j-0.6.jar -> /opt/jdk1.8.0/jre/lib/jce.jar (compact1)
apache-mime4j-0.6.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
apache-mime4j-0.6.jar -> jcl-over-slf4j-1.7.2.jbossorg-1.jar
asm-3.3.1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
async-http-servlet-3.0-3.0.6.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
async-http-servlet-3.0-3.0.6.Final.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
async-http-servlet-3.0-3.0.6.Final.jar -> resteasy-jaxrs-3.0.6.Final.jar
async-http-servlet-3.0-3.0.6.Final.jar -> jaxrs-api-3.0.6.Final.jar
avro-1.7.5.jar -> not found
avro-1.7.5.jar -> jackson-mapper-asl-1.9.12.jar
avro-1.7.5.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
avro-1.7.5.jar -> jackson-core-asl-1.9.12.jar
   org.apache.avro.reflect.FieldAccessUnsafe (avro-1.7.5.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   org.apache.avro.reflect.FieldAccessUnsafe$UnsafeBooleanField (avro-1.7.5.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   org.apache.avro.reflect.FieldAccessUnsafe$UnsafeByteField (avro-1.7.5.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   org.apache.avro.reflect.FieldAccessUnsafe$UnsafeCachedField (avro-1.7.5.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   org.apache.avro.reflect.FieldAccessUnsafe$UnsafeCharField (avro-1.7.5.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   org.apache.avro.reflect.FieldAccessUnsafe$UnsafeCustomEncodedField (avro-1.7.5.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   org.apache.avro.reflect.FieldAccessUnsafe$UnsafeDoubleField (avro-1.7.5.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   org.apache.avro.reflect.FieldAccessUnsafe$UnsafeFloatField (avro-1.7.5.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   org.apache.avro.reflect.FieldAccessUnsafe$UnsafeIntField (avro-1.7.5.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   org.apache.avro.reflect.FieldAccessUnsafe$UnsafeLongField (avro-1.7.5.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   org.apache.avro.reflect.FieldAccessUnsafe$UnsafeObjectField (avro-1.7.5.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   org.apache.avro.reflect.FieldAccessUnsafe$UnsafeShortField (avro-1.7.5.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
bcmail-jdk16-1.46.jar -> /opt/jdk1.8.0/jre/lib/jce.jar (compact1)
bcmail-jdk16-1.46.jar -> javax.mail-1.5.0.jar
bcmail-jdk16-1.46.jar -> bcprov-jdk16-1.46.jar
bcmail-jdk16-1.46.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
bcmail-jdk16-1.46.jar -> activation-1.1.1.jar
bcprov-jdk16-1.46.jar -> not found
bcprov-jdk16-1.46.jar -> /opt/jdk1.8.0/jre/lib/jce.jar (compact1)
bcprov-jdk16-1.46.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
cal10n-api-0.8.1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
cdi-api-1.1.jar -> jboss-interceptors-api_1.2_spec-1.0.0.Final.jar
cdi-api-1.1.jar -> javax.inject-1.jar
cdi-api-1.1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
cdi-api-1.1.jar -> javax.el-3.0-b07.jar
classmate-1.0.0.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
codemodel-2.6.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
   com.sun.codemodel.util.SingleByteEncoder (codemodel-2.6.jar)
      -> sun.nio.cs.Surrogate                               JDK internal API (rt.jar)
      -> sun.nio.cs.Surrogate$Parser                        JDK internal API (rt.jar)
commons-beanutils-1.8.3.jar -> commons-collections-3.2.1.jar
commons-beanutils-1.8.3.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
commons-beanutils-1.8.3.jar -> jcl-over-slf4j-1.7.2.jbossorg-1.jar
commons-cli-1.2.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
commons-codec-1.4.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
commons-collections-3.2.1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
commons-configuration-1.6.jar -> not found
commons-configuration-1.6.jar -> commons-collections-3.2.1.jar
commons-configuration-1.6.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
commons-configuration-1.6.jar -> jcl-over-slf4j-1.7.2.jbossorg-1.jar
commons-configuration-1.6.jar -> commons-beanutils-1.8.3.jar
commons-configuration-1.6.jar -> commons-codec-1.4.jar
commons-configuration-1.6.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
commons-configuration-1.6.jar -> commons-lang-2.6.jar
commons-io-2.1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
commons-lang-2.6.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
commons-pool-1.6.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
cxf-api-2.7.7.jar -> not found
cxf-api-2.7.7.jar -> log4j-jboss-logmanager-1.0.2.Final.jar
cxf-api-2.7.7.jar -> /opt/jdk1.8.0/jre/lib/jce.jar (compact1)
cxf-api-2.7.7.jar -> wsdl4j-1.6.3.jar
cxf-api-2.7.7.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
cxf-api-2.7.7.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
cxf-api-2.7.7.jar -> activation-1.1.1.jar
cxf-api-2.7.7.jar -> jaxen-1.1.3.jar
cxf-api-2.7.7.jar -> xmlschema-core-2.0.2.jar
cxf-api-2.7.7.jar -> stax2-api-3.1.1.jar
cxf-api-2.7.7.jar -> jaxb-impl-2.2.5.jboss-1.jar
cxf-api-2.7.7.jar -> woodstox-core-asl-4.2.0.jar
cxf-api-2.7.7.jar -> asm-3.3.1.jar
cxf-api-2.7.7.jar -> javax.mail-1.5.0.jar
cxf-api-2.7.7.jar -> jboss-annotations-api_1.2_spec-1.0.0.Final.jar
cxf-api-2.7.7.jar -> FastInfoset-1.2.12.jar
cxf-api-2.7.7.jar -> slf4j-api-1.7.2.jbossorg-1.jar
cxf-rt-bindings-coloc-2.7.7.jar -> not found
cxf-rt-bindings-coloc-2.7.7.jar -> cxf-rt-core-2.7.7.jar
cxf-rt-bindings-coloc-2.7.7.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
cxf-rt-bindings-coloc-2.7.7.jar -> cxf-api-2.7.7.jar
cxf-rt-bindings-coloc-2.7.7.jar -> jboss-jaxws-api_2.2_spec-2.0.2.Final.jar
cxf-rt-bindings-object-2.7.7.jar -> not found
cxf-rt-bindings-object-2.7.7.jar -> cxf-rt-transports-local-2.7.7.jar
cxf-rt-bindings-object-2.7.7.jar -> cxf-rt-core-2.7.7.jar
cxf-rt-bindings-object-2.7.7.jar -> jboss-annotations-api_1.2_spec-1.0.0.Final.jar
cxf-rt-bindings-object-2.7.7.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
cxf-rt-bindings-object-2.7.7.jar -> cxf-api-2.7.7.jar
cxf-rt-bindings-soap-2.7.7.jar -> not found
cxf-rt-bindings-soap-2.7.7.jar -> jboss-saaj-api_1.3_spec-1.0.3.Final.jar
cxf-rt-bindings-soap-2.7.7.jar -> jsr181-api-1.0-MR1.jar
cxf-rt-bindings-soap-2.7.7.jar -> cxf-rt-core-2.7.7.jar
cxf-rt-bindings-soap-2.7.7.jar -> wsdl4j-1.6.3.jar
cxf-rt-bindings-soap-2.7.7.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
cxf-rt-bindings-soap-2.7.7.jar -> jboss-annotations-api_1.2_spec-1.0.0.Final.jar
cxf-rt-bindings-soap-2.7.7.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
cxf-rt-bindings-soap-2.7.7.jar -> cxf-api-2.7.7.jar
cxf-rt-bindings-soap-2.7.7.jar -> activation-1.1.1.jar
cxf-rt-bindings-soap-2.7.7.jar -> xmlschema-core-2.0.2.jar
cxf-rt-bindings-xml-2.7.7.jar -> wsdl4j-1.6.3.jar
cxf-rt-bindings-xml-2.7.7.jar -> cxf-tools-validator-2.7.7.jar
cxf-rt-bindings-xml-2.7.7.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
cxf-rt-bindings-xml-2.7.7.jar -> cxf-tools-common-2.7.7.jar
cxf-rt-bindings-xml-2.7.7.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
cxf-rt-bindings-xml-2.7.7.jar -> cxf-api-2.7.7.jar
cxf-rt-core-2.7.7.jar -> not found
cxf-rt-core-2.7.7.jar -> wsdl4j-1.6.3.jar
cxf-rt-core-2.7.7.jar -> xml-resolver-1.2.jar
cxf-rt-core-2.7.7.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
cxf-rt-core-2.7.7.jar -> jboss-annotations-api_1.2_spec-1.0.0.Final.jar
cxf-rt-core-2.7.7.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
cxf-rt-core-2.7.7.jar -> cxf-api-2.7.7.jar
cxf-rt-core-2.7.7.jar -> activation-1.1.1.jar
cxf-rt-core-2.7.7.jar -> FastInfoset-1.2.12.jar
cxf-rt-core-2.7.7.jar -> jaxen-1.1.3.jar
cxf-rt-core-2.7.7.jar -> org.osgi.core-5.0.0.jar
cxf-rt-core-2.7.7.jar -> xmlschema-core-2.0.2.jar
cxf-rt-databinding-aegis-2.7.7.jar -> cxf-rt-core-2.7.7.jar
cxf-rt-databinding-aegis-2.7.7.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
cxf-rt-databinding-aegis-2.7.7.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
cxf-rt-databinding-aegis-2.7.7.jar -> cxf-api-2.7.7.jar
cxf-rt-databinding-aegis-2.7.7.jar -> activation-1.1.1.jar
cxf-rt-databinding-aegis-2.7.7.jar -> cxf-rt-bindings-soap-2.7.7.jar
cxf-rt-databinding-aegis-2.7.7.jar -> xmlschema-core-2.0.2.jar
cxf-rt-databinding-aegis-2.7.7.jar -> jdom-1.1.2.jar
cxf-rt-databinding-jaxb-2.7.7.jar -> cxf-rt-core-2.7.7.jar
cxf-rt-databinding-jaxb-2.7.7.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
cxf-rt-databinding-jaxb-2.7.7.jar -> jaxb-xjc-2.2.5.jboss-1.jar
cxf-rt-databinding-jaxb-2.7.7.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
cxf-rt-databinding-jaxb-2.7.7.jar -> cxf-api-2.7.7.jar
cxf-rt-databinding-jaxb-2.7.7.jar -> activation-1.1.1.jar
cxf-rt-databinding-jaxb-2.7.7.jar -> xmlschema-core-2.0.2.jar
cxf-rt-databinding-jaxb-2.7.7.jar -> commons-lang-2.6.jar
cxf-rt-frontend-jaxws-2.7.7.jar -> jboss-saaj-api_1.3_spec-1.0.3.Final.jar
cxf-rt-frontend-jaxws-2.7.7.jar -> not found
cxf-rt-frontend-jaxws-2.7.7.jar -> jsr181-api-1.0-MR1.jar
cxf-rt-frontend-jaxws-2.7.7.jar -> cxf-rt-core-2.7.7.jar
cxf-rt-frontend-jaxws-2.7.7.jar -> cxf-rt-databinding-jaxb-2.7.7.jar
cxf-rt-frontend-jaxws-2.7.7.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
cxf-rt-frontend-jaxws-2.7.7.jar -> wsdl4j-1.6.3.jar
cxf-rt-frontend-jaxws-2.7.7.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
cxf-rt-frontend-jaxws-2.7.7.jar -> activation-1.1.1.jar
cxf-rt-frontend-jaxws-2.7.7.jar -> jcl-over-slf4j-1.7.2.jbossorg-1.jar
cxf-rt-frontend-jaxws-2.7.7.jar -> cxf-rt-transports-http-2.7.7.jar
cxf-rt-frontend-jaxws-2.7.7.jar -> jboss-jaxws-api_2.2_spec-2.0.2.Final.jar
cxf-rt-frontend-jaxws-2.7.7.jar -> jboss-annotations-api_1.2_spec-1.0.0.Final.jar
cxf-rt-frontend-jaxws-2.7.7.jar -> cxf-api-2.7.7.jar
cxf-rt-frontend-jaxws-2.7.7.jar -> cxf-rt-bindings-soap-2.7.7.jar
cxf-rt-frontend-jaxws-2.7.7.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
cxf-rt-frontend-jaxws-2.7.7.jar -> cxf-rt-bindings-xml-2.7.7.jar
cxf-rt-frontend-jaxws-2.7.7.jar -> cxf-rt-frontend-simple-2.7.7.jar
cxf-rt-frontend-simple-2.7.7.jar -> not found
cxf-rt-frontend-simple-2.7.7.jar -> cxf-rt-core-2.7.7.jar
cxf-rt-frontend-simple-2.7.7.jar -> wsdl4j-1.6.3.jar
cxf-rt-frontend-simple-2.7.7.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
cxf-rt-frontend-simple-2.7.7.jar -> cxf-api-2.7.7.jar
cxf-rt-frontend-simple-2.7.7.jar -> cxf-rt-bindings-soap-2.7.7.jar
cxf-rt-management-2.7.7.jar -> cxf-rt-core-2.7.7.jar
cxf-rt-management-2.7.7.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
cxf-rt-management-2.7.7.jar -> jboss-annotations-api_1.2_spec-1.0.0.Final.jar
cxf-rt-management-2.7.7.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
cxf-rt-management-2.7.7.jar -> cxf-api-2.7.7.jar
cxf-rt-transports-http-2.7.7.jar -> not found
cxf-rt-transports-http-2.7.7.jar -> cxf-rt-ws-policy-2.7.7.jar
cxf-rt-transports-http-2.7.7.jar -> cxf-rt-core-2.7.7.jar
cxf-rt-transports-http-2.7.7.jar -> wsdl4j-1.6.3.jar
cxf-rt-transports-http-2.7.7.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
cxf-rt-transports-http-2.7.7.jar -> neethi-3.0.2.jar
cxf-rt-transports-http-2.7.7.jar -> jboss-annotations-api_1.2_spec-1.0.0.Final.jar
cxf-rt-transports-http-2.7.7.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
cxf-rt-transports-http-2.7.7.jar -> cxf-api-2.7.7.jar
cxf-rt-transports-http-2.7.7.jar -> activation-1.1.1.jar
cxf-rt-transports-http-2.7.7.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
cxf-rt-transports-http-2.7.7.jar -> org.osgi.core-5.0.0.jar
cxf-rt-transports-jms-2.7.7.jar -> jboss-connector-api_1.7_spec-1.0.0.Final.jar
cxf-rt-transports-jms-2.7.7.jar -> not found
cxf-rt-transports-jms-2.7.7.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
cxf-rt-transports-jms-2.7.7.jar -> wsdl4j-1.6.3.jar
cxf-rt-transports-jms-2.7.7.jar -> jboss-annotations-api_1.2_spec-1.0.0.Final.jar
cxf-rt-transports-jms-2.7.7.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
cxf-rt-transports-jms-2.7.7.jar -> cxf-api-2.7.7.jar
cxf-rt-transports-jms-2.7.7.jar -> cxf-rt-bindings-soap-2.7.7.jar
cxf-rt-transports-jms-2.7.7.jar -> jboss-client.jar
cxf-rt-transports-local-2.7.7.jar -> jboss-annotations-api_1.2_spec-1.0.0.Final.jar
cxf-rt-transports-local-2.7.7.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
cxf-rt-transports-local-2.7.7.jar -> cxf-api-2.7.7.jar
cxf-rt-ws-addr-2.7.7.jar -> not found
cxf-rt-ws-addr-2.7.7.jar -> cxf-rt-ws-policy-2.7.7.jar
cxf-rt-ws-addr-2.7.7.jar -> cxf-rt-core-2.7.7.jar
cxf-rt-ws-addr-2.7.7.jar -> cxf-rt-databinding-jaxb-2.7.7.jar
cxf-rt-ws-addr-2.7.7.jar -> wsdl4j-1.6.3.jar
cxf-rt-ws-addr-2.7.7.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
cxf-rt-ws-addr-2.7.7.jar -> neethi-3.0.2.jar
cxf-rt-ws-addr-2.7.7.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
cxf-rt-ws-addr-2.7.7.jar -> cxf-api-2.7.7.jar
cxf-rt-ws-addr-2.7.7.jar -> cxf-rt-bindings-soap-2.7.7.jar
cxf-rt-ws-addr-2.7.7.jar -> jboss-jaxws-api_2.2_spec-2.0.2.Final.jar
cxf-rt-ws-mex-2.7.7.jar -> jsr181-api-1.0-MR1.jar
cxf-rt-ws-mex-2.7.7.jar -> cxf-rt-ws-policy-2.7.7.jar
cxf-rt-ws-mex-2.7.7.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
cxf-rt-ws-mex-2.7.7.jar -> cxf-rt-frontend-jaxws-2.7.7.jar
cxf-rt-ws-mex-2.7.7.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
cxf-rt-ws-mex-2.7.7.jar -> cxf-api-2.7.7.jar
cxf-rt-ws-mex-2.7.7.jar -> cxf-rt-bindings-soap-2.7.7.jar
cxf-rt-ws-mex-2.7.7.jar -> jboss-jaxws-api_2.2_spec-2.0.2.Final.jar
cxf-rt-ws-mex-2.7.7.jar -> cxf-rt-frontend-simple-2.7.7.jar
cxf-rt-ws-policy-2.7.7.jar -> not found
cxf-rt-ws-policy-2.7.7.jar -> cxf-rt-core-2.7.7.jar
cxf-rt-ws-policy-2.7.7.jar -> neethi-3.0.2.jar
cxf-rt-ws-policy-2.7.7.jar -> wsdl4j-1.6.3.jar
cxf-rt-ws-policy-2.7.7.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
cxf-rt-ws-policy-2.7.7.jar -> jboss-annotations-api_1.2_spec-1.0.0.Final.jar
cxf-rt-ws-policy-2.7.7.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
cxf-rt-ws-policy-2.7.7.jar -> cxf-api-2.7.7.jar
cxf-rt-ws-rm-2.7.7.jar -> not found
cxf-rt-ws-rm-2.7.7.jar -> cxf-rt-ws-policy-2.7.7.jar
cxf-rt-ws-rm-2.7.7.jar -> cxf-rt-core-2.7.7.jar
cxf-rt-ws-rm-2.7.7.jar -> cxf-rt-databinding-jaxb-2.7.7.jar
cxf-rt-ws-rm-2.7.7.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
cxf-rt-ws-rm-2.7.7.jar -> wsdl4j-1.6.3.jar
cxf-rt-ws-rm-2.7.7.jar -> neethi-3.0.2.jar
cxf-rt-ws-rm-2.7.7.jar -> jboss-annotations-api_1.2_spec-1.0.0.Final.jar
cxf-rt-ws-rm-2.7.7.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
cxf-rt-ws-rm-2.7.7.jar -> cxf-api-2.7.7.jar
cxf-rt-ws-rm-2.7.7.jar -> cxf-rt-bindings-soap-2.7.7.jar
cxf-rt-ws-rm-2.7.7.jar -> cxf-rt-ws-addr-2.7.7.jar
cxf-rt-ws-security-2.7.7.jar -> not found
cxf-rt-ws-security-2.7.7.jar -> jboss-saaj-api_1.3_spec-1.0.3.Final.jar
cxf-rt-ws-security-2.7.7.jar -> /opt/jdk1.8.0/jre/lib/jce.jar (compact1)
cxf-rt-ws-security-2.7.7.jar -> cxf-rt-ws-policy-2.7.7.jar
cxf-rt-ws-security-2.7.7.jar -> jsr181-api-1.0-MR1.jar
cxf-rt-ws-security-2.7.7.jar -> cxf-rt-core-2.7.7.jar
cxf-rt-ws-security-2.7.7.jar -> neethi-3.0.2.jar
cxf-rt-ws-security-2.7.7.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
cxf-rt-ws-security-2.7.7.jar -> wsdl4j-1.6.3.jar
cxf-rt-ws-security-2.7.7.jar -> xmlsec-1.5.5.jar
cxf-rt-ws-security-2.7.7.jar -> cxf-rt-frontend-jaxws-2.7.7.jar
cxf-rt-ws-security-2.7.7.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
cxf-rt-ws-security-2.7.7.jar -> cxf-rt-transports-http-2.7.7.jar
cxf-rt-ws-security-2.7.7.jar -> cxf-rt-ws-addr-2.7.7.jar
cxf-rt-ws-security-2.7.7.jar -> jboss-jaxws-api_2.2_spec-2.0.2.Final.jar
cxf-rt-ws-security-2.7.7.jar -> opensaml-2.5.3.jar
cxf-rt-ws-security-2.7.7.jar -> xmltooling-1.3.4.jar
cxf-rt-ws-security-2.7.7.jar -> jboss-annotations-api_1.2_spec-1.0.0.Final.jar
cxf-rt-ws-security-2.7.7.jar -> cxf-api-2.7.7.jar
cxf-rt-ws-security-2.7.7.jar -> cxf-rt-ws-mex-2.7.7.jar
cxf-rt-ws-security-2.7.7.jar -> cxf-rt-bindings-soap-2.7.7.jar
cxf-rt-ws-security-2.7.7.jar -> wss4j-1.6.12.jar
cxf-services-sts-core-2.7.7.jar -> not found
cxf-services-sts-core-2.7.7.jar -> log4j-jboss-logmanager-1.0.2.Final.jar
cxf-services-sts-core-2.7.7.jar -> /opt/jdk1.8.0/jre/lib/jce.jar (compact1)
cxf-services-sts-core-2.7.7.jar -> cxf-rt-core-2.7.7.jar
cxf-services-sts-core-2.7.7.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
cxf-services-sts-core-2.7.7.jar -> xmlsec-1.5.5.jar
cxf-services-sts-core-2.7.7.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
cxf-services-sts-core-2.7.7.jar -> cxf-rt-ws-security-2.7.7.jar
cxf-services-sts-core-2.7.7.jar -> cxf-rt-ws-addr-2.7.7.jar
cxf-services-sts-core-2.7.7.jar -> jboss-jaxws-api_2.2_spec-2.0.2.Final.jar
cxf-services-sts-core-2.7.7.jar -> joda-time-1.6.2.jar
cxf-services-sts-core-2.7.7.jar -> opensaml-2.5.3.jar
cxf-services-sts-core-2.7.7.jar -> xmltooling-1.3.4.jar
cxf-services-sts-core-2.7.7.jar -> cxf-api-2.7.7.jar
cxf-services-sts-core-2.7.7.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
cxf-services-sts-core-2.7.7.jar -> cxf-rt-bindings-soap-2.7.7.jar
cxf-services-sts-core-2.7.7.jar -> wss4j-1.6.12.jar
cxf-services-ws-discovery-api-2.7.7.jar -> jsr181-api-1.0-MR1.jar
cxf-services-ws-discovery-api-2.7.7.jar -> cxf-rt-databinding-jaxb-2.7.7.jar
cxf-services-ws-discovery-api-2.7.7.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
cxf-services-ws-discovery-api-2.7.7.jar -> cxf-rt-frontend-jaxws-2.7.7.jar
cxf-services-ws-discovery-api-2.7.7.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
cxf-services-ws-discovery-api-2.7.7.jar -> cxf-api-2.7.7.jar
cxf-services-ws-discovery-api-2.7.7.jar -> cxf-rt-ws-addr-2.7.7.jar
cxf-services-ws-discovery-api-2.7.7.jar -> jboss-jaxws-api_2.2_spec-2.0.2.Final.jar
cxf-tools-common-2.7.7.jar -> not found
cxf-tools-common-2.7.7.jar -> velocity-1.7.jar
cxf-tools-common-2.7.7.jar -> jsr181-api-1.0-MR1.jar
cxf-tools-common-2.7.7.jar -> cxf-rt-core-2.7.7.jar
cxf-tools-common-2.7.7.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
cxf-tools-common-2.7.7.jar -> wsdl4j-1.6.3.jar
cxf-tools-common-2.7.7.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
cxf-tools-common-2.7.7.jar -> cxf-api-2.7.7.jar
cxf-tools-java2ws-2.7.7.jar -> not found
cxf-tools-java2ws-2.7.7.jar -> jsr181-api-1.0-MR1.jar
cxf-tools-java2ws-2.7.7.jar -> cxf-rt-core-2.7.7.jar
cxf-tools-java2ws-2.7.7.jar -> cxf-rt-databinding-jaxb-2.7.7.jar
cxf-tools-java2ws-2.7.7.jar -> cxf-tools-common-2.7.7.jar
cxf-tools-java2ws-2.7.7.jar -> wsdl4j-1.6.3.jar
cxf-tools-java2ws-2.7.7.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
cxf-tools-java2ws-2.7.7.jar -> cxf-rt-frontend-jaxws-2.7.7.jar
cxf-tools-java2ws-2.7.7.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
cxf-tools-java2ws-2.7.7.jar -> xmlschema-core-2.0.2.jar
cxf-tools-java2ws-2.7.7.jar -> jboss-jaxws-api_2.2_spec-2.0.2.Final.jar
cxf-tools-java2ws-2.7.7.jar -> cxf-api-2.7.7.jar
cxf-tools-java2ws-2.7.7.jar -> cxf-tools-wsdlto-core-2.7.7.jar
cxf-tools-java2ws-2.7.7.jar -> cxf-rt-databinding-aegis-2.7.7.jar
cxf-tools-java2ws-2.7.7.jar -> cxf-rt-frontend-simple-2.7.7.jar
cxf-tools-validator-2.7.7.jar -> jsr181-api-1.0-MR1.jar
cxf-tools-validator-2.7.7.jar -> cxf-rt-core-2.7.7.jar
cxf-tools-validator-2.7.7.jar -> wsdl4j-1.6.3.jar
cxf-tools-validator-2.7.7.jar -> cxf-tools-common-2.7.7.jar
cxf-tools-validator-2.7.7.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
cxf-tools-validator-2.7.7.jar -> cxf-api-2.7.7.jar
cxf-tools-validator-2.7.7.jar -> cxf-rt-bindings-soap-2.7.7.jar
cxf-tools-validator-2.7.7.jar -> xmlschema-core-2.0.2.jar
cxf-tools-wsdlto-core-2.7.7.jar -> cxf-rt-core-2.7.7.jar
cxf-tools-wsdlto-core-2.7.7.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
cxf-tools-wsdlto-core-2.7.7.jar -> cxf-tools-common-2.7.7.jar
cxf-tools-wsdlto-core-2.7.7.jar -> wsdl4j-1.6.3.jar
cxf-tools-wsdlto-core-2.7.7.jar -> cxf-tools-validator-2.7.7.jar
cxf-tools-wsdlto-core-2.7.7.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
cxf-tools-wsdlto-core-2.7.7.jar -> cxf-api-2.7.7.jar
cxf-tools-wsdlto-core-2.7.7.jar -> xmlschema-core-2.0.2.jar
cxf-tools-wsdlto-databinding-jaxb-2.7.7.jar -> codemodel-2.6.jar
cxf-tools-wsdlto-databinding-jaxb-2.7.7.jar -> cxf-rt-core-2.7.7.jar
cxf-tools-wsdlto-databinding-jaxb-2.7.7.jar -> jaxb-xjc-2.2.5.jboss-1.jar
cxf-tools-wsdlto-databinding-jaxb-2.7.7.jar -> cxf-tools-common-2.7.7.jar
cxf-tools-wsdlto-databinding-jaxb-2.7.7.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
cxf-tools-wsdlto-databinding-jaxb-2.7.7.jar -> cxf-api-2.7.7.jar
cxf-tools-wsdlto-databinding-jaxb-2.7.7.jar -> cxf-tools-wsdlto-core-2.7.7.jar
cxf-tools-wsdlto-databinding-jaxb-2.7.7.jar -> jaxen-1.1.3.jar
cxf-tools-wsdlto-databinding-jaxb-2.7.7.jar -> xmlschema-core-2.0.2.jar
cxf-tools-wsdlto-frontend-jaxws-2.7.7.jar -> jsr181-api-1.0-MR1.jar
cxf-tools-wsdlto-frontend-jaxws-2.7.7.jar -> cxf-rt-core-2.7.7.jar
cxf-tools-wsdlto-frontend-jaxws-2.7.7.jar -> cxf-tools-common-2.7.7.jar
cxf-tools-wsdlto-frontend-jaxws-2.7.7.jar -> wsdl4j-1.6.3.jar
cxf-tools-wsdlto-frontend-jaxws-2.7.7.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
cxf-tools-wsdlto-frontend-jaxws-2.7.7.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
cxf-tools-wsdlto-frontend-jaxws-2.7.7.jar -> xmlschema-core-2.0.2.jar
cxf-tools-wsdlto-frontend-jaxws-2.7.7.jar -> jboss-jaxws-api_2.2_spec-2.0.2.Final.jar
cxf-tools-wsdlto-frontend-jaxws-2.7.7.jar -> commons-lang-2.6.jar
cxf-tools-wsdlto-frontend-jaxws-2.7.7.jar -> cxf-tools-validator-2.7.7.jar
cxf-tools-wsdlto-frontend-jaxws-2.7.7.jar -> cxf-api-2.7.7.jar
cxf-tools-wsdlto-frontend-jaxws-2.7.7.jar -> cxf-tools-wsdlto-core-2.7.7.jar
cxf-tools-wsdlto-frontend-jaxws-2.7.7.jar -> cxf-rt-bindings-soap-2.7.7.jar
cxf-xjc-boolean-2.6.1.jar -> codemodel-2.6.jar
cxf-xjc-boolean-2.6.1.jar -> jaxb-xjc-2.2.5.jboss-1.jar
cxf-xjc-boolean-2.6.1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
cxf-xjc-dv-2.6.1.jar -> codemodel-2.6.jar
cxf-xjc-dv-2.6.1.jar -> jaxb-xjc-2.2.5.jboss-1.jar
cxf-xjc-dv-2.6.1.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
cxf-xjc-dv-2.6.1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
cxf-xjc-dv-2.6.1.jar -> xsom-20110809.jar
cxf-xjc-ts-2.6.1.jar -> codemodel-2.6.jar
cxf-xjc-ts-2.6.1.jar -> jaxb-xjc-2.2.5.jboss-1.jar
cxf-xjc-ts-2.6.1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
dom4j-1.6.1.jar -> not found
dom4j-1.6.1.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
dom4j-1.6.1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
dom4j-1.6.1.jar -> jaxen-1.1.3.jar
dom4j-1.6.1.jar -> relaxngDatatype-2011.1.jar
FastInfoset-1.2.12.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
generic-jms-ra-jar-1.0.1.Final.jar -> jboss-connector-api_1.7_spec-1.0.0.Final.jar
generic-jms-ra-jar-1.0.1.Final.jar -> jboss-common-core-2.2.22.GA.jar
generic-jms-ra-jar-1.0.1.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
generic-jms-ra-jar-1.0.1.Final.jar -> jboss-cli-client.jar
generic-jms-ra-jar-1.0.1.Final.jar -> jboss-client.jar
guava-15.0.jar -> not found
guava-15.0.jar -> javax.inject-1.jar
guava-15.0.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
   com.google.common.cache.Striped64 (guava-15.0.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   com.google.common.cache.Striped64$1 (guava-15.0.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   com.google.common.cache.Striped64$Cell (guava-15.0.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   com.google.common.primitives.UnsignedBytes$LexicographicalComparatorHolder$UnsafeComparator (guava-15.0.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   com.google.common.primitives.UnsignedBytes$LexicographicalComparatorHolder$UnsafeComparator$1 (guava-15.0.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
h2-1.3.173.jar -> not found
h2-1.3.173.jar -> lucene-core-3.6.2.jar
h2-1.3.173.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
h2-1.3.173.jar -> slf4j-api-1.7.2.jbossorg-1.jar
h2-1.3.173.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
h2-1.3.173.jar -> org.osgi.core-5.0.0.jar
h2-1.3.173.jar -> jboss-client.jar
hibernate-commons-annotations-4.0.4.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
hibernate-commons-annotations-4.0.4.Final.jar -> jboss-cli-client.jar
hibernate-core-4.3.0.Final.jar -> classmate-1.0.0.jar
hibernate-core-4.3.0.Final.jar -> not found
hibernate-core-4.3.0.Final.jar -> jboss-jacc-api_1.5_spec-1.0.0.Beta1.jar
hibernate-core-4.3.0.Final.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
hibernate-core-4.3.0.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
hibernate-core-4.3.0.Final.jar -> hibernate-jpa-2.1-api-1.0.0.Final.jar
hibernate-core-4.3.0.Final.jar -> javassist-3.18.1-GA.jar
hibernate-core-4.3.0.Final.jar -> dom4j-1.6.1.jar
hibernate-core-4.3.0.Final.jar -> hibernate-commons-annotations-4.0.4.Final.jar
hibernate-core-4.3.0.Final.jar -> jandex-1.1.0.Final.jar
hibernate-core-4.3.0.Final.jar -> jboss-cli-client.jar
hibernate-core-4.3.0.Final.jar -> jboss-client.jar
hibernate-core-4.3.0.Final.jar -> antlr-2.7.7.jar
hibernate-core-4.3.0.Final.jar -> validation-api-1.1.0.Final.jar
hibernate-entitymanager-4.3.0.Final.jar -> cdi-api-1.1.jar
hibernate-entitymanager-4.3.0.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
hibernate-entitymanager-4.3.0.Final.jar -> hibernate-jpa-2.1-api-1.0.0.Final.jar
hibernate-entitymanager-4.3.0.Final.jar -> javassist-3.18.1-GA.jar
hibernate-entitymanager-4.3.0.Final.jar -> hibernate-core-4.3.0.Final.jar
hibernate-entitymanager-4.3.0.Final.jar -> hibernate-commons-annotations-4.0.4.Final.jar
hibernate-entitymanager-4.3.0.Final.jar -> jandex-1.1.0.Final.jar
hibernate-entitymanager-4.3.0.Final.jar -> jboss-cli-client.jar
hibernate-entitymanager-4.3.0.Final.jar -> jboss-client.jar
hibernate-envers-4.3.0.Final.jar -> dom4j-1.6.1.jar
hibernate-envers-4.3.0.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
hibernate-envers-4.3.0.Final.jar -> hibernate-jpa-2.1-api-1.0.0.Final.jar
hibernate-envers-4.3.0.Final.jar -> javassist-3.18.1-GA.jar
hibernate-envers-4.3.0.Final.jar -> hibernate-core-4.3.0.Final.jar
hibernate-envers-4.3.0.Final.jar -> hibernate-commons-annotations-4.0.4.Final.jar
hibernate-envers-4.3.0.Final.jar -> jboss-cli-client.jar
hibernate-envers-4.3.0.Final.jar -> jboss-client.jar
hibernate-hql-lucene-1.0.0.Alpha5.jar -> not found
hibernate-hql-lucene-1.0.0.Alpha5.jar -> hibernate-hql-parser-1.0.0.Alpha5.jar
hibernate-hql-lucene-1.0.0.Alpha5.jar -> hibernate-search-engine-4.5.0.Alpha2.jar
hibernate-hql-lucene-1.0.0.Alpha5.jar -> lucene-core-3.6.2.jar
hibernate-hql-lucene-1.0.0.Alpha5.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
hibernate-hql-lucene-1.0.0.Alpha5.jar -> jboss-cli-client.jar
hibernate-hql-parser-1.0.0.Alpha5.jar -> not found
hibernate-hql-parser-1.0.0.Alpha5.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
hibernate-hql-parser-1.0.0.Alpha5.jar -> jboss-cli-client.jar
hibernate-infinispan-4.3.0.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
hibernate-infinispan-4.3.0.Final.jar -> infinispan-commons-6.0.1.Final.jar
hibernate-infinispan-4.3.0.Final.jar -> hibernate-core-4.3.0.Final.jar
hibernate-infinispan-4.3.0.Final.jar -> jboss-client.jar
hibernate-infinispan-4.3.0.Final.jar -> infinispan-core-6.0.1.Final.jar
hibernate-jpa-2.1-api-1.0.0.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
hibernate-search-engine-4.5.0.Alpha2.jar -> not found
hibernate-search-engine-4.5.0.Alpha2.jar -> lucene-core-3.6.2.jar
hibernate-search-engine-4.5.0.Alpha2.jar -> avro-1.7.5.jar
hibernate-search-engine-4.5.0.Alpha2.jar -> lucene-facet-3.6.2.jar
hibernate-search-engine-4.5.0.Alpha2.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
hibernate-search-engine-4.5.0.Alpha2.jar -> hibernate-commons-annotations-4.0.4.Final.jar
hibernate-search-engine-4.5.0.Alpha2.jar -> jboss-cli-client.jar
hibernate-search-engine-4.5.0.Alpha2.jar -> jboss-client.jar
hibernate-search-infinispan-4.5.0.Alpha2.jar -> hibernate-search-engine-4.5.0.Alpha2.jar
hibernate-search-infinispan-4.5.0.Alpha2.jar -> lucene-core-3.6.2.jar
hibernate-search-infinispan-4.5.0.Alpha2.jar -> infinispan-lucene-directory-6.0.1.Final.jar
hibernate-search-infinispan-4.5.0.Alpha2.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
hibernate-search-infinispan-4.5.0.Alpha2.jar -> infinispan-commons-6.0.1.Final.jar
hibernate-search-infinispan-4.5.0.Alpha2.jar -> hibernate-commons-annotations-4.0.4.Final.jar
hibernate-search-infinispan-4.5.0.Alpha2.jar -> jboss-cli-client.jar
hibernate-search-infinispan-4.5.0.Alpha2.jar -> jboss-client.jar
hibernate-search-infinispan-4.5.0.Alpha2.jar -> infinispan-core-6.0.1.Final.jar
hibernate-validator-5.0.2.Final.jar -> classmate-1.0.0.jar
hibernate-validator-5.0.2.Final.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
hibernate-validator-5.0.2.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
hibernate-validator-5.0.2.Final.jar -> jsoup-1.6.1.jar
hibernate-validator-5.0.2.Final.jar -> javax.el-3.0-b07.jar
hibernate-validator-5.0.2.Final.jar -> hibernate-jpa-2.1-api-1.0.0.Final.jar
hibernate-validator-5.0.2.Final.jar -> jboss-cli-client.jar
hibernate-validator-5.0.2.Final.jar -> validation-api-1.1.0.Final.jar
hibernate-validator-5.0.2.Final.jar -> joda-time-1.6.2.jar
hibernate-validator-cdi-5.0.2.Final.jar -> jboss-interceptors-api_1.2_spec-1.0.0.Final.jar
hibernate-validator-cdi-5.0.2.Final.jar -> javax.inject-1.jar
hibernate-validator-cdi-5.0.2.Final.jar -> hibernate-validator-5.0.2.Final.jar
hibernate-validator-cdi-5.0.2.Final.jar -> cdi-api-1.1.jar
hibernate-validator-cdi-5.0.2.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
hibernate-validator-cdi-5.0.2.Final.jar -> validation-api-1.1.0.Final.jar
hibernate-validator-cdi-5.0.2.Final.jar -> jaxrs-api-3.0.6.Final.jar
hornetq-amqp-protocol-2.4.0.Final.jar -> hornetq-commons-2.4.0.Final.jar
hornetq-amqp-protocol-2.4.0.Final.jar -> proton-jms-0.4.jar
hornetq-amqp-protocol-2.4.0.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
hornetq-amqp-protocol-2.4.0.Final.jar -> hornetq-server-2.4.0.Final.jar
hornetq-amqp-protocol-2.4.0.Final.jar -> proton-j-impl-0.4.jar
hornetq-amqp-protocol-2.4.0.Final.jar -> proton-api-0.4.jar
hornetq-amqp-protocol-2.4.0.Final.jar -> jboss-cli-client.jar
hornetq-amqp-protocol-2.4.0.Final.jar -> jboss-client.jar
hornetq-amqp-protocol-2.4.0.Final.jar -> hornetq-journal-2.4.0.Final.jar
hornetq-amqp-protocol-2.4.0.Final.jar -> hornetq-core-client-2.4.0.Final.jar
hornetq-commons-2.4.0.Final.jar -> /opt/jdk1.8.0/jre/lib/jce.jar (compact1)
hornetq-commons-2.4.0.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
hornetq-commons-2.4.0.Final.jar -> jboss-cli-client.jar
hornetq-commons-2.4.0.Final.jar -> jboss-client.jar
hornetq-core-client-2.4.0.Final.jar -> hornetq-commons-2.4.0.Final.jar
hornetq-core-client-2.4.0.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
hornetq-core-client-2.4.0.Final.jar -> jboss-cli-client.jar
hornetq-core-client-2.4.0.Final.jar -> jboss-client.jar
hornetq-jms-client-2.4.0.Final.jar -> hornetq-commons-2.4.0.Final.jar
hornetq-jms-client-2.4.0.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
hornetq-jms-client-2.4.0.Final.jar -> jboss-cli-client.jar
hornetq-jms-client-2.4.0.Final.jar -> jboss-client.jar
hornetq-jms-client-2.4.0.Final.jar -> hornetq-core-client-2.4.0.Final.jar
hornetq-jms-server-2.4.0.Final.jar -> not found
hornetq-jms-server-2.4.0.Final.jar -> hornetq-commons-2.4.0.Final.jar
hornetq-jms-server-2.4.0.Final.jar -> narayana-jts-jacorb-5.0.0.CR2.jar
hornetq-jms-server-2.4.0.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
hornetq-jms-server-2.4.0.Final.jar -> hornetq-jms-client-2.4.0.Final.jar
hornetq-jms-server-2.4.0.Final.jar -> hornetq-server-2.4.0.Final.jar
hornetq-jms-server-2.4.0.Final.jar -> jboss-cli-client.jar
hornetq-jms-server-2.4.0.Final.jar -> jboss-client.jar
hornetq-jms-server-2.4.0.Final.jar -> hornetq-journal-2.4.0.Final.jar
hornetq-jms-server-2.4.0.Final.jar -> jboss-transaction-spi-7.1.0.Final.jar
hornetq-jms-server-2.4.0.Final.jar -> hornetq-core-client-2.4.0.Final.jar
hornetq-journal-2.4.0.Final.jar -> hornetq-commons-2.4.0.Final.jar
hornetq-journal-2.4.0.Final.jar -> hornetq-native-2.4.0.Final.jar
hornetq-journal-2.4.0.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
hornetq-journal-2.4.0.Final.jar -> jboss-cli-client.jar
hornetq-journal-2.4.0.Final.jar -> jboss-client.jar
hornetq-native-2.4.0.Final.jar -> hornetq-commons-2.4.0.Final.jar
hornetq-native-2.4.0.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
hornetq-ra-2.4.0.Final.jar -> jboss-connector-api_1.7_spec-1.0.0.Final.jar
hornetq-ra-2.4.0.Final.jar -> hornetq-commons-2.4.0.Final.jar
hornetq-ra-2.4.0.Final.jar -> hornetq-jms-server-2.4.0.Final.jar
hornetq-ra-2.4.0.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
hornetq-ra-2.4.0.Final.jar -> hornetq-jms-client-2.4.0.Final.jar
hornetq-ra-2.4.0.Final.jar -> jboss-cli-client.jar
hornetq-ra-2.4.0.Final.jar -> jboss-client.jar
hornetq-ra-2.4.0.Final.jar -> hornetq-core-client-2.4.0.Final.jar
hornetq-server-2.4.0.Final.jar -> hornetq-commons-2.4.0.Final.jar
hornetq-server-2.4.0.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
hornetq-server-2.4.0.Final.jar -> jboss-cli-client.jar
hornetq-server-2.4.0.Final.jar -> hornetq-journal-2.4.0.Final.jar
hornetq-server-2.4.0.Final.jar -> jboss-client.jar
hornetq-server-2.4.0.Final.jar -> hornetq-core-client-2.4.0.Final.jar
hornetq-stomp-protocol-2.4.0.Final.jar -> hornetq-commons-2.4.0.Final.jar
hornetq-stomp-protocol-2.4.0.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
hornetq-stomp-protocol-2.4.0.Final.jar -> hornetq-server-2.4.0.Final.jar
hornetq-stomp-protocol-2.4.0.Final.jar -> jboss-cli-client.jar
hornetq-stomp-protocol-2.4.0.Final.jar -> jboss-client.jar
hornetq-stomp-protocol-2.4.0.Final.jar -> hornetq-journal-2.4.0.Final.jar
hornetq-stomp-protocol-2.4.0.Final.jar -> hornetq-core-client-2.4.0.Final.jar
hornetq-tools-2.4.0.Final.jar -> hornetq-commons-2.4.0.Final.jar
hornetq-tools-2.4.0.Final.jar -> hornetq-jms-server-2.4.0.Final.jar
hornetq-tools-2.4.0.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
hornetq-tools-2.4.0.Final.jar -> hornetq-jms-client-2.4.0.Final.jar
hornetq-tools-2.4.0.Final.jar -> hornetq-server-2.4.0.Final.jar
hornetq-tools-2.4.0.Final.jar -> jboss-cli-client.jar
hornetq-tools-2.4.0.Final.jar -> hornetq-journal-2.4.0.Final.jar
hornetq-tools-2.4.0.Final.jar -> hornetq-core-client-2.4.0.Final.jar
httpclient-4.2.1.jar -> /opt/jdk1.8.0/jre/lib/jce.jar (compact1)
httpclient-4.2.1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
httpclient-4.2.1.jar -> jcl-over-slf4j-1.7.2.jbossorg-1.jar
httpclient-4.2.1.jar -> httpcore-4.2.1.jar
httpclient-4.2.1.jar -> commons-codec-1.4.jar
httpcore-4.2.1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
httpmime-4.2.1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
httpmime-4.2.1.jar -> httpcore-4.2.1.jar
httpserver-1.0.1.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
infinispan-cachestore-jdbc-6.0.1.Final.jar -> not found
infinispan-cachestore-jdbc-6.0.1.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
infinispan-cachestore-jdbc-6.0.1.Final.jar -> infinispan-commons-6.0.1.Final.jar
infinispan-cachestore-jdbc-6.0.1.Final.jar -> jboss-cli-client.jar
infinispan-cachestore-jdbc-6.0.1.Final.jar -> jboss-client.jar
infinispan-cachestore-jdbc-6.0.1.Final.jar -> infinispan-core-6.0.1.Final.jar
infinispan-cachestore-remote-6.0.1.Final.jar -> not found
infinispan-cachestore-remote-6.0.1.Final.jar -> jcip-annotations-1.0.jar
infinispan-cachestore-remote-6.0.1.Final.jar -> infinispan-client-hotrod-6.0.1.Final.jar
infinispan-cachestore-remote-6.0.1.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
infinispan-cachestore-remote-6.0.1.Final.jar -> infinispan-commons-6.0.1.Final.jar
infinispan-cachestore-remote-6.0.1.Final.jar -> jboss-cli-client.jar
infinispan-cachestore-remote-6.0.1.Final.jar -> jboss-client.jar
infinispan-cachestore-remote-6.0.1.Final.jar -> infinispan-core-6.0.1.Final.jar
infinispan-client-hotrod-6.0.1.Final.jar -> infinispan-query-6.0.1.Final.jar
infinispan-client-hotrod-6.0.1.Final.jar -> jcip-annotations-1.0.jar
infinispan-client-hotrod-6.0.1.Final.jar -> protostream-1.0.0.CR1.jar
infinispan-client-hotrod-6.0.1.Final.jar -> commons-pool-1.6.jar
infinispan-client-hotrod-6.0.1.Final.jar -> avro-1.7.5.jar
infinispan-client-hotrod-6.0.1.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
infinispan-client-hotrod-6.0.1.Final.jar -> infinispan-commons-6.0.1.Final.jar
infinispan-client-hotrod-6.0.1.Final.jar -> jboss-cli-client.jar
infinispan-client-hotrod-6.0.1.Final.jar -> infinispan-remote-query-client-6.0.1.Final.jar
infinispan-commons-6.0.1.Final.jar -> jcip-annotations-1.0.jar
infinispan-commons-6.0.1.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
infinispan-commons-6.0.1.Final.jar -> org.osgi.core-5.0.0.jar
infinispan-commons-6.0.1.Final.jar -> jboss-cli-client.jar
   org.infinispan.commons.util.concurrent.jdk8backported.CountedCompleter (infinispan-commons-6.0.1.Final.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   org.infinispan.commons.util.concurrent.jdk8backported.CountedCompleter$1 (infinispan-commons-6.0.1.Final.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   org.infinispan.commons.util.concurrent.jdk8backported.EquivalentConcurrentHashMapV8 (infinispan-commons-6.0.1.Final.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   org.infinispan.commons.util.concurrent.jdk8backported.EquivalentConcurrentHashMapV8$1 (infinispan-commons-6.0.1.Final.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   org.infinispan.commons.util.concurrent.jdk8backported.EquivalentConcurrentHashMapV8$TreeBin (infinispan-commons-6.0.1.Final.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   org.infinispan.commons.util.concurrent.jdk8backported.ForkJoinPool (infinispan-commons-6.0.1.Final.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   org.infinispan.commons.util.concurrent.jdk8backported.ForkJoinPool$1 (infinispan-commons-6.0.1.Final.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   org.infinispan.commons.util.concurrent.jdk8backported.ForkJoinPool$WorkQueue (infinispan-commons-6.0.1.Final.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   org.infinispan.commons.util.concurrent.jdk8backported.ForkJoinTask (infinispan-commons-6.0.1.Final.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   org.infinispan.commons.util.concurrent.jdk8backported.ForkJoinTask$1 (infinispan-commons-6.0.1.Final.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   org.infinispan.commons.util.concurrent.jdk8backported.Striped64 (infinispan-commons-6.0.1.Final.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   org.infinispan.commons.util.concurrent.jdk8backported.Striped64$1 (infinispan-commons-6.0.1.Final.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   org.infinispan.commons.util.concurrent.jdk8backported.Striped64$Cell (infinispan-commons-6.0.1.Final.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
infinispan-core-6.0.1.Final.jar -> jcip-annotations-1.0.jar
infinispan-core-6.0.1.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
infinispan-core-6.0.1.Final.jar -> infinispan-commons-6.0.1.Final.jar
infinispan-core-6.0.1.Final.jar -> jboss-cli-client.jar
infinispan-core-6.0.1.Final.jar -> jboss-client.jar
infinispan-lucene-directory-6.0.1.Final.jar -> not found
infinispan-lucene-directory-6.0.1.Final.jar -> lucene-core-3.6.2.jar
infinispan-lucene-directory-6.0.1.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
infinispan-lucene-directory-6.0.1.Final.jar -> infinispan-commons-6.0.1.Final.jar
infinispan-lucene-directory-6.0.1.Final.jar -> jboss-cli-client.jar
infinispan-lucene-directory-6.0.1.Final.jar -> jboss-client.jar
infinispan-lucene-directory-6.0.1.Final.jar -> infinispan-core-6.0.1.Final.jar
infinispan-lucene-v3-6.0.1.Final.jar -> lucene-core-3.6.2.jar
infinispan-lucene-v3-6.0.1.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
infinispan-lucene-v3-6.0.1.Final.jar -> infinispan-commons-6.0.1.Final.jar
infinispan-lucene-v3-6.0.1.Final.jar -> jboss-cli-client.jar
infinispan-lucene-v3-6.0.1.Final.jar -> jboss-client.jar
infinispan-lucene-v3-6.0.1.Final.jar -> infinispan-core-6.0.1.Final.jar
infinispan-query-6.0.1.Final.jar -> hibernate-search-engine-4.5.0.Alpha2.jar
infinispan-query-6.0.1.Final.jar -> hibernate-search-infinispan-4.5.0.Alpha2.jar
infinispan-query-6.0.1.Final.jar -> hibernate-hql-parser-1.0.0.Alpha5.jar
infinispan-query-6.0.1.Final.jar -> jcip-annotations-1.0.jar
infinispan-query-6.0.1.Final.jar -> lucene-core-3.6.2.jar
infinispan-query-6.0.1.Final.jar -> hibernate-hql-lucene-1.0.0.Alpha5.jar
infinispan-query-6.0.1.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
infinispan-query-6.0.1.Final.jar -> infinispan-commons-6.0.1.Final.jar
infinispan-query-6.0.1.Final.jar -> hibernate-commons-annotations-4.0.4.Final.jar
infinispan-query-6.0.1.Final.jar -> jboss-cli-client.jar
infinispan-query-6.0.1.Final.jar -> jboss-client.jar
infinispan-query-6.0.1.Final.jar -> infinispan-core-6.0.1.Final.jar
infinispan-query-dsl-6.0.1.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
infinispan-remote-query-client-6.0.1.Final.jar -> protostream-1.0.0.CR1.jar
infinispan-remote-query-client-6.0.1.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
infinispan-remote-query-client-6.0.1.Final.jar -> infinispan-commons-6.0.1.Final.jar
infinispan-remote-query-client-6.0.1.Final.jar -> protobuf-java-2.5.0.jar
ironjacamar-common-api-1.1.2.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
ironjacamar-common-impl-1.1.2.Final.jar -> jboss-connector-api_1.7_spec-1.0.0.Final.jar
ironjacamar-common-impl-1.1.2.Final.jar -> ironjacamar-common-spi-1.1.2.Final.jar
ironjacamar-common-impl-1.1.2.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
ironjacamar-common-impl-1.1.2.Final.jar -> ironjacamar-common-api-1.1.2.Final.jar
ironjacamar-common-impl-1.1.2.Final.jar -> jandex-1.1.0.Final.jar
ironjacamar-common-impl-1.1.2.Final.jar -> jboss-cli-client.jar
ironjacamar-common-impl-1.1.2.Final.jar -> validation-api-1.1.0.Final.jar
ironjacamar-common-spi-1.1.2.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
ironjacamar-core-api-1.1.2.Final.jar -> jboss-connector-api_1.7_spec-1.0.0.Final.jar
ironjacamar-core-api-1.1.2.Final.jar -> picketbox-4.0.20.Beta2.jar
ironjacamar-core-api-1.1.2.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
ironjacamar-core-api-1.1.2.Final.jar -> ironjacamar-common-api-1.1.2.Final.jar
ironjacamar-core-api-1.1.2.Final.jar -> jboss-cli-client.jar
ironjacamar-core-api-1.1.2.Final.jar -> jboss-client.jar
ironjacamar-core-impl-1.1.2.Final.jar -> jboss-connector-api_1.7_spec-1.0.0.Final.jar
ironjacamar-core-impl-1.1.2.Final.jar -> picketbox-4.0.20.Beta2.jar
ironjacamar-core-impl-1.1.2.Final.jar -> ironjacamar-core-api-1.1.2.Final.jar
ironjacamar-core-impl-1.1.2.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
ironjacamar-core-impl-1.1.2.Final.jar -> ironjacamar-common-api-1.1.2.Final.jar
ironjacamar-core-impl-1.1.2.Final.jar -> jboss-cli-client.jar
ironjacamar-core-impl-1.1.2.Final.jar -> jboss-jaspi-api_1.1_spec-1.0.0.Alpha1.jar
ironjacamar-core-impl-1.1.2.Final.jar -> jboss-client.jar
ironjacamar-core-impl-1.1.2.Final.jar -> jboss-transaction-spi-7.1.0.Final.jar
ironjacamar-core-impl-1.1.2.Final.jar -> validation-api-1.1.0.Final.jar
ironjacamar-deployers-common-1.1.2.Final.jar -> jboss-connector-api_1.7_spec-1.0.0.Final.jar
ironjacamar-deployers-common-1.1.2.Final.jar -> picketbox-4.0.20.Beta2.jar
ironjacamar-deployers-common-1.1.2.Final.jar -> ironjacamar-core-impl-1.1.2.Final.jar
ironjacamar-deployers-common-1.1.2.Final.jar -> ironjacamar-core-api-1.1.2.Final.jar
ironjacamar-deployers-common-1.1.2.Final.jar -> ironjacamar-common-impl-1.1.2.Final.jar
ironjacamar-deployers-common-1.1.2.Final.jar -> ironjacamar-validator-1.1.2.Final.jar
ironjacamar-deployers-common-1.1.2.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
ironjacamar-deployers-common-1.1.2.Final.jar -> ironjacamar-common-api-1.1.2.Final.jar
ironjacamar-deployers-common-1.1.2.Final.jar -> jboss-cli-client.jar
ironjacamar-deployers-common-1.1.2.Final.jar -> jboss-client.jar
ironjacamar-deployers-common-1.1.2.Final.jar -> validation-api-1.1.0.Final.jar
ironjacamar-jdbc-1.1.2.Final.jar -> jboss-connector-api_1.7_spec-1.0.0.Final.jar
ironjacamar-jdbc-1.1.2.Final.jar -> ironjacamar-core-api-1.1.2.Final.jar
ironjacamar-jdbc-1.1.2.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
ironjacamar-jdbc-1.1.2.Final.jar -> jboss-cli-client.jar
ironjacamar-jdbc-1.1.2.Final.jar -> jboss-client.jar
ironjacamar-validator-1.1.2.Final.jar -> jboss-connector-api_1.7_spec-1.0.0.Final.jar
ironjacamar-validator-1.1.2.Final.jar -> ironjacamar-common-spi-1.1.2.Final.jar
ironjacamar-validator-1.1.2.Final.jar -> ironjacamar-common-impl-1.1.2.Final.jar
ironjacamar-validator-1.1.2.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
ironjacamar-validator-1.1.2.Final.jar -> ironjacamar-common-api-1.1.2.Final.jar
istack-commons-runtime-2.6.1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
istack-commons-runtime-2.6.1.jar -> activation-1.1.1.jar
istack-commons-tools-2.6.1.jar -> not found
istack-commons-tools-2.6.1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jackson-annotations-2.2.3.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jackson-core-2.2.3.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jackson-core-asl-1.9.12.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jackson-databind-2.2.3.jar -> jackson-annotations-2.2.3.jar
jackson-databind-2.2.3.jar -> jackson-core-2.2.3.jar
jackson-databind-2.2.3.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
jackson-jaxrs-1.9.12.jar -> jackson-mapper-asl-1.9.12.jar
jackson-jaxrs-1.9.12.jar -> jackson-xc-1.9.12.jar
jackson-jaxrs-1.9.12.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jackson-jaxrs-1.9.12.jar -> jackson-core-asl-1.9.12.jar
jackson-jaxrs-1.9.12.jar -> jaxrs-api-3.0.6.Final.jar
jackson-jaxrs-base-2.2.3.jar -> jackson-annotations-2.2.3.jar
jackson-jaxrs-base-2.2.3.jar -> jackson-core-2.2.3.jar
jackson-jaxrs-base-2.2.3.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jackson-jaxrs-base-2.2.3.jar -> jackson-databind-2.2.3.jar
jackson-jaxrs-base-2.2.3.jar -> jaxrs-api-3.0.6.Final.jar
jackson-jaxrs-json-provider-2.2.3.jar -> jackson-annotations-2.2.3.jar
jackson-jaxrs-json-provider-2.2.3.jar -> jackson-core-2.2.3.jar
jackson-jaxrs-json-provider-2.2.3.jar -> jackson-module-jaxb-annotations-2.2.3.jar
jackson-jaxrs-json-provider-2.2.3.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jackson-jaxrs-json-provider-2.2.3.jar -> jackson-jaxrs-base-2.2.3.jar
jackson-jaxrs-json-provider-2.2.3.jar -> jackson-databind-2.2.3.jar
jackson-jaxrs-json-provider-2.2.3.jar -> jaxrs-api-3.0.6.Final.jar
jackson-mapper-asl-1.9.12.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
jackson-mapper-asl-1.9.12.jar -> jackson-core-asl-1.9.12.jar
jackson-mapper-asl-1.9.12.jar -> joda-time-1.6.2.jar
jackson-module-jaxb-annotations-2.2.3.jar -> jackson-annotations-2.2.3.jar
jackson-module-jaxb-annotations-2.2.3.jar -> jackson-core-2.2.3.jar
jackson-module-jaxb-annotations-2.2.3.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
jackson-module-jaxb-annotations-2.2.3.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
jackson-module-jaxb-annotations-2.2.3.jar -> activation-1.1.1.jar
jackson-module-jaxb-annotations-2.2.3.jar -> jackson-databind-2.2.3.jar
jackson-xc-1.9.12.jar -> jackson-mapper-asl-1.9.12.jar
jackson-xc-1.9.12.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
jackson-xc-1.9.12.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
jackson-xc-1.9.12.jar -> jackson-core-asl-1.9.12.jar
jackson-xc-1.9.12.jar -> activation-1.1.1.jar
jacorb-2.3.2-jbossorg-5.jar -> not found
jacorb-2.3.2-jbossorg-5.jar -> narayana-jts-jacorb-5.0.0.CR2.jar
jacorb-2.3.2-jbossorg-5.jar -> jboss-rmi-api_1.0_spec-1.0.4.Final.jar
jacorb-2.3.2-jbossorg-5.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
jacorb-2.3.2-jbossorg-5.jar -> slf4j-api-1.7.2.jbossorg-1.jar
jacorb-2.3.2-jbossorg-5.jar -> antlr-2.7.7.jar
   org.jacorb.security.sas.GSSUPContextSpi (jacorb-2.3.2-jbossorg-5.jar)
      -> sun.security.jgss.spi.GSSContextSpi                JDK internal API (rt.jar)
      -> sun.security.jgss.spi.GSSCredentialSpi             JDK internal API (rt.jar)
      -> sun.security.jgss.spi.GSSNameSpi                   JDK internal API (rt.jar)
   org.jacorb.security.sas.GSSUPCredentialSpi (jacorb-2.3.2-jbossorg-5.jar)
      -> sun.security.jgss.spi.GSSCredentialSpi             JDK internal API (rt.jar)
      -> sun.security.jgss.spi.GSSNameSpi                   JDK internal API (rt.jar)
   org.jacorb.security.sas.GSSUPMechFactory (jacorb-2.3.2-jbossorg-5.jar)
      -> sun.security.jgss.spi.GSSContextSpi                JDK internal API (rt.jar)
      -> sun.security.jgss.spi.GSSCredentialSpi             JDK internal API (rt.jar)
      -> sun.security.jgss.spi.GSSNameSpi                   JDK internal API (rt.jar)
      -> sun.security.jgss.spi.MechanismFactory             JDK internal API (rt.jar)
   org.jacorb.security.sas.GSSUPNameSpi (jacorb-2.3.2-jbossorg-5.jar)
      -> sun.security.jgss.spi.GSSNameSpi                   JDK internal API (rt.jar)
jandex-1.1.0.Final.jar -> not found
jandex-1.1.0.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jansi-1.9.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jasper-jdt-7.0.3.Final.jar -> not found
jasper-jdt-7.0.3.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jastow-1.0.0.CR1.jar -> undertow-core-1.0.0.Beta28.jar
jastow-1.0.0.CR1.jar -> undertow-servlet-1.0.0.Beta28.jar
jastow-1.0.0.CR1.jar -> jasper-jdt-7.0.3.Final.jar
jastow-1.0.0.CR1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
jastow-1.0.0.CR1.jar -> javax.el-3.0-b07.jar
jastow-1.0.0.CR1.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
jastow-1.0.0.CR1.jar -> jboss-jsp-api_2.3_spec-1.0.0.Beta1.jar
jastow-1.0.0.CR1.jar -> jboss-cli-client.jar
java-getopt-1.0.13.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
javassist-3.18.1-GA.jar -> not found
javassist-3.18.1-GA.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
javax.el-3.0-b07.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
javax.enterprise.concurrent-1.0.jar -> jboss-concurrency-api_1.0_spec-1.0.0.Final.jar
javax.enterprise.concurrent-1.0.jar -> jboss-j2eemgmt-api_1.1_spec-1.0.1.Final.jar
javax.enterprise.concurrent-1.0.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
javax.inject-1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
javax.json-1.0.3.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
javax.mail-1.5.0.jar -> /opt/jdk1.8.0/jre/lib/jce.jar (compact1)
javax.mail-1.5.0.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
javax.mail-1.5.0.jar -> activation-1.1.1.jar
jaxb-impl-2.2.5.jboss-1.jar -> not found
jaxb-impl-2.2.5.jboss-1.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
jaxb-impl-2.2.5.jboss-1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
jaxb-impl-2.2.5.jboss-1.jar -> activation-1.1.1.jar
jaxb-impl-2.2.5.jboss-1.jar -> FastInfoset-1.2.12.jar
jaxb-impl-2.2.5.jboss-1.jar -> istack-commons-runtime-2.6.1.jar
jaxb-impl-2.2.5.jboss-1.jar -> txw2-20110809.jar
jaxb-xjc-2.2.5.jboss-1.jar -> not found
jaxb-xjc-2.2.5.jboss-1.jar -> jaxb-impl-2.2.5.jboss-1.jar
jaxb-xjc-2.2.5.jboss-1.jar -> codemodel-2.6.jar
jaxb-xjc-2.2.5.jboss-1.jar -> istack-commons-tools-2.6.1.jar
jaxb-xjc-2.2.5.jboss-1.jar -> rngom-201103.jboss-1.jar
jaxb-xjc-2.2.5.jboss-1.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
jaxb-xjc-2.2.5.jboss-1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
jaxb-xjc-2.2.5.jboss-1.jar -> activation-1.1.1.jar
jaxb-xjc-2.2.5.jboss-1.jar -> xsom-20110809.jar
jaxb-xjc-2.2.5.jboss-1.jar -> istack-commons-runtime-2.6.1.jar
jaxb-xjc-2.2.5.jboss-1.jar -> txw2-20110809.jar
   com.sun.tools.xjc.Options (jaxb-xjc-2.2.5.jboss-1.jar)
      -> com.sun.org.apache.xml.internal.resolver.Catalog   JDK internal API (rt.jar)
      -> com.sun.org.apache.xml.internal.resolver.CatalogManager JDK internal API (rt.jar)
      -> com.sun.org.apache.xml.internal.resolver.tools.CatalogResolver JDK internal API (rt.jar)
jaxen-1.1.3.jar -> xom-1.2.5.jar
jaxen-1.1.3.jar -> dom4j-1.6.1.jar
jaxen-1.1.3.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
jaxen-1.1.3.jar -> jdom-1.1.2.jar
jaxrs-api-3.0.6.Final.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
jaxrs-api-3.0.6.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
jaxws-jboss-httpserver-httpspi-1.0.1.GA.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jaxws-jboss-httpserver-httpspi-1.0.1.GA.jar -> httpserver-1.0.1.Final.jar
jaxws-jboss-httpserver-httpspi-1.0.1.GA.jar -> jboss-jaxws-api_2.2_spec-2.0.2.Final.jar
jberet-core-1.0.0.CR1.jar -> javax.inject-1.jar
jberet-core-1.0.0.CR1.jar -> jboss-annotations-api_1.2_spec-1.0.0.Final.jar
jberet-core-1.0.0.CR1.jar -> cdi-api-1.1.jar
jberet-core-1.0.0.CR1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
jberet-core-1.0.0.CR1.jar -> guava-15.0.jar
jberet-core-1.0.0.CR1.jar -> jboss-cli-client.jar
jberet-core-1.0.0.CR1.jar -> jboss-batch-api_1.0_spec-1.0.0.Final.jar
jberet-core-1.0.0.CR1.jar -> jboss-client.jar
jboss-annotations-api_1.2_spec-1.0.0.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jboss-as-version-8.0.0.Beta2-SNAPSHOT.jar -> jboss-modules.jar
jboss-as-version-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jboss-as-version-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
jboss-batch-api_1.0_spec-1.0.0.Final.jar -> javax.inject-1.jar
jboss-batch-api_1.0_spec-1.0.0.Final.jar -> cdi-api-1.1.jar
jboss-batch-api_1.0_spec-1.0.0.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jboss-classfilewriter-1.0.4.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jboss-cli-client.jar -> not found
jboss-cli-client.jar -> jboss-logmanager-1.5.0.Final.jar
jboss-cli-client.jar -> log4j-jboss-logmanager-1.0.2.Final.jar
jboss-cli-client.jar -> /opt/jdk1.8.0/jre/lib/jce.jar (compact1)
jboss-cli-client.jar -> jboss-modules.jar
jboss-cli-client.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
jboss-cli-client.jar -> slf4j-api-1.7.2.jbossorg-1.jar
   org.jboss.aesh.console.helper.InterruptHandler (jboss-cli-client.jar)
      -> sun.misc.Signal                                    JDK internal API (rt.jar)
      -> sun.misc.SignalHandler                             JDK internal API (rt.jar)
   org.jboss.aesh.console.helper.InterruptHandler$1 (jboss-cli-client.jar)
      -> sun.misc.Signal                                    JDK internal API (rt.jar)
      -> sun.misc.SignalHandler                             JDK internal API (rt.jar)
   org.jboss.marshalling.reflect.SerializableClass (jboss-cli-client.jar)
      -> sun.reflect.ReflectionFactory                      JDK internal API (rt.jar)
      -> sun.reflect.ReflectionFactory$GetReflectionFactoryAction JDK internal API (rt.jar)
   org.wildfly.security.manager.WildFlySecurityManager (jboss-cli-client.jar)
      -> sun.reflect.Reflection                             JDK internal API (rt.jar)
jboss-client.jar -> not found
jboss-client.jar -> log4j-jboss-logmanager-1.0.2.Final.jar
jboss-client.jar -> /opt/jdk1.8.0/jre/lib/jce.jar (compact1)
jboss-client.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
jboss-client.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
jboss-client.jar -> protobuf-java-2.5.0.jar
jboss-client.jar -> jcl-over-slf4j-1.7.2.jbossorg-1.jar
jboss-client.jar -> javassist-3.18.1-GA.jar
jboss-client.jar -> jboss-interceptors-api_1.2_spec-1.0.0.Final.jar
jboss-client.jar -> jboss-logmanager-1.5.0.Final.jar
jboss-client.jar -> jboss-jaxrpc-api_1.1_spec-1.0.1.Final.jar
jboss-client.jar -> jboss-modules.jar
jboss-client.jar -> cdi-api-1.1.jar
jboss-client.jar -> slf4j-api-1.7.2.jbossorg-1.jar
   io.netty.util.internal.PlatformDependent0 (jboss-client.jar)
      -> sun.misc.Cleaner                                   JDK internal API (rt.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   io.netty.util.internal.chmv8.ConcurrentHashMapV8 (jboss-client.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   io.netty.util.internal.chmv8.ConcurrentHashMapV8$1 (jboss-client.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   io.netty.util.internal.chmv8.ConcurrentHashMapV8$TreeBin (jboss-client.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   io.netty.util.internal.chmv8.CountedCompleter (jboss-client.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   io.netty.util.internal.chmv8.CountedCompleter$1 (jboss-client.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   io.netty.util.internal.chmv8.ForkJoinPool (jboss-client.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   io.netty.util.internal.chmv8.ForkJoinPool$2 (jboss-client.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   io.netty.util.internal.chmv8.ForkJoinPool$WorkQueue (jboss-client.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   io.netty.util.internal.chmv8.ForkJoinTask (jboss-client.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   io.netty.util.internal.chmv8.ForkJoinTask$1 (jboss-client.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   io.netty.util.internal.chmv8.Striped64 (jboss-client.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   io.netty.util.internal.chmv8.Striped64$1 (jboss-client.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   io.netty.util.internal.chmv8.Striped64$Cell (jboss-client.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   org.jboss.marshalling.reflect.SerializableClass (jboss-client.jar)
      -> sun.reflect.ReflectionFactory                      JDK internal API (rt.jar)
      -> sun.reflect.ReflectionFactory$GetReflectionFactoryAction JDK internal API (rt.jar)
jboss-common-beans-1.1.0.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
jboss-common-core-2.2.22.GA.jar -> not found
jboss-common-core-2.2.22.GA.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
jboss-common-core-2.2.22.GA.jar -> jboss-cli-client.jar
jboss-concurrency-api_1.0_spec-1.0.0.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jboss-connector-api_1.7_spec-1.0.0.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
jboss-connector-api_1.7_spec-1.0.0.Final.jar -> jboss-client.jar
jboss-dmr-1.2.0.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jboss-ejb3-ext-api-2.1.0.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jboss-ejb-api_3.2_spec-1.0.0.Final.jar -> jboss-jaxrpc-api_1.1_spec-1.0.1.Final.jar
jboss-ejb-api_3.2_spec-1.0.0.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
jboss-ejb-api_3.2_spec-1.0.0.Final.jar -> jboss-client.jar
jboss-ejb-client-2.0.0.Beta5.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
jboss-ejb-client-2.0.0.Beta5.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
jboss-ejb-client-2.0.0.Beta5.jar -> jboss-cli-client.jar
jboss-ejb-client-2.0.0.Beta5.jar -> jboss-client.jar
jboss-el-api_3.0_spec-1.0.0.Beta1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
jboss-iiop-client-1.0.0.Final.jar -> jacorb-2.3.2-jbossorg-5.jar
jboss-iiop-client-1.0.0.Final.jar -> jboss-rmi-api_1.0_spec-1.0.4.Final.jar
jboss-iiop-client-1.0.0.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
jboss-iiop-client-1.0.0.Final.jar -> jboss-client.jar
jboss-interceptors-api_1.2_spec-1.0.0.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jboss-invocation-1.2.0.Beta4.jar -> jboss-interceptors-api_1.2_spec-1.0.0.Final.jar
jboss-invocation-1.2.0.Beta4.jar -> jboss-classfilewriter-1.0.4.Final.jar
jboss-invocation-1.2.0.Beta4.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jboss-invocation-1.2.0.Beta4.jar -> jboss-cli-client.jar
jboss-j2eemgmt-api_1.1_spec-1.0.1.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
jboss-j2eemgmt-api_1.1_spec-1.0.1.Final.jar -> jboss-client.jar
jboss-jacc-api_1.5_spec-1.0.0.Beta1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jboss-jacc-api_1.5_spec-1.0.0.Beta1.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
jboss-jaspi-api_1.1_spec-1.0.0.Alpha1.jar -> /opt/jdk1.8.0/jre/lib/jce.jar (compact1)
jboss-jaspi-api_1.1_spec-1.0.0.Alpha1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jboss-jaxb-api_2.2_spec-1.0.4.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
jboss-jaxb-api_2.2_spec-1.0.4.Final.jar -> activation-1.1.1.jar
jboss-jaxb-intros-1.0.2.GA.jar -> jaxb-impl-2.2.5.jboss-1.jar
jboss-jaxb-intros-1.0.2.GA.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
jboss-jaxb-intros-1.0.2.GA.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
jboss-jaxb-intros-1.0.2.GA.jar -> jcl-over-slf4j-1.7.2.jbossorg-1.jar
jboss-jaxb-intros-1.0.2.GA.jar -> commons-beanutils-1.8.3.jar
jboss-jaxrpc-api_1.1_spec-1.0.1.Final.jar -> jboss-saaj-api_1.3_spec-1.0.3.Final.jar
jboss-jaxrpc-api_1.1_spec-1.0.1.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
jboss-jaxrpc-api_1.1_spec-1.0.1.Final.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
jboss-jaxws-api_2.2_spec-2.0.2.Final.jar -> jboss-saaj-api_1.3_spec-1.0.3.Final.jar
jboss-jaxws-api_2.2_spec-2.0.2.Final.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
jboss-jaxws-api_2.2_spec-2.0.2.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
jboss-jms-api_2.0_spec-1.0.0.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jboss-jms-api_2.0_spec-1.0.0.Final.jar -> jboss-client.jar
jboss-jsf-api_2.2_spec-2.2.4.jar -> jboss-jstl-api_1.2_spec-1.0.4.Beta1.jar
jboss-jsf-api_2.2_spec-2.2.4.jar -> javax.inject-1.jar
jboss-jsf-api_2.2_spec-2.2.4.jar -> cdi-api-1.1.jar
jboss-jsf-api_2.2_spec-2.2.4.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
jboss-jsf-api_2.2_spec-2.2.4.jar -> javax.el-3.0-b07.jar
jboss-jsf-api_2.2_spec-2.2.4.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
jboss-jsf-api_2.2_spec-2.2.4.jar -> jboss-jsp-api_2.3_spec-1.0.0.Beta1.jar
jboss-jsf-api_2.2_spec-2.2.4.jar -> jsf-impl-2.2.4-jbossorg-1.jar
jboss-jsf-api_2.2_spec-2.2.4.jar -> validation-api-1.1.0.Final.jar
jboss-jsp-api_2.3_spec-1.0.0.Beta1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
jboss-jsp-api_2.3_spec-1.0.0.Beta1.jar -> javax.el-3.0-b07.jar
jboss-jsp-api_2.3_spec-1.0.0.Beta1.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
jboss-jstl-api_1.2_spec-1.0.4.Beta1.jar -> xalan-2.7.1.jbossorg-1.jar
jboss-jstl-api_1.2_spec-1.0.4.Beta1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
jboss-jstl-api_1.2_spec-1.0.4.Beta1.jar -> javax.el-3.0-b07.jar
jboss-jstl-api_1.2_spec-1.0.4.Beta1.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
jboss-jstl-api_1.2_spec-1.0.4.Beta1.jar -> jboss-jsp-api_2.3_spec-1.0.0.Beta1.jar
jboss-logging-3.1.3.GA.jar -> jboss-logmanager-1.5.0.Final.jar
jboss-logging-3.1.3.GA.jar -> log4j-jboss-logmanager-1.0.2.Final.jar
jboss-logging-3.1.3.GA.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jboss-logging-3.1.3.GA.jar -> slf4j-api-1.7.2.jbossorg-1.jar
jboss-logmanager-1.5.0.Final.jar -> jboss-modules.jar
jboss-logmanager-1.5.0.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
jboss-marshalling-1.4.2.Final.jar -> jboss-modules.jar
jboss-marshalling-1.4.2.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
   org.jboss.marshalling.reflect.SerializableClass (jboss-marshalling-1.4.2.Final.jar)
      -> sun.reflect.ReflectionFactory                      JDK internal API (rt.jar)
      -> sun.reflect.ReflectionFactory$GetReflectionFactoryAction JDK internal API (rt.jar)
jboss-marshalling-river-1.4.2.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jboss-marshalling-river-1.4.2.Final.jar -> jboss-cli-client.jar
jboss-metadata-appclient-8.0.0.Beta5.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
jboss-metadata-appclient-8.0.0.Beta5.jar -> jboss-metadata-common-8.0.0.Beta5.jar
jboss-metadata-common-8.0.0.Beta5.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
jboss-metadata-common-8.0.0.Beta5.jar -> hibernate-jpa-2.1-api-1.0.0.Final.jar
jboss-metadata-common-8.0.0.Beta5.jar -> jboss-cli-client.jar
jboss-metadata-ear-8.0.0.Beta5.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
jboss-metadata-ear-8.0.0.Beta5.jar -> jboss-cli-client.jar
jboss-metadata-ear-8.0.0.Beta5.jar -> jboss-metadata-common-8.0.0.Beta5.jar
jboss-metadata-ejb-8.0.0.Beta5.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
jboss-metadata-ejb-8.0.0.Beta5.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
jboss-metadata-ejb-8.0.0.Beta5.jar -> jboss-cli-client.jar
jboss-metadata-ejb-8.0.0.Beta5.jar -> jboss-client.jar
jboss-metadata-ejb-8.0.0.Beta5.jar -> jboss-metadata-common-8.0.0.Beta5.jar
jboss-metadata-web-8.0.0.Beta5.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
jboss-metadata-web-8.0.0.Beta5.jar -> jboss-cli-client.jar
jboss-metadata-web-8.0.0.Beta5.jar -> jboss-metadata-common-8.0.0.Beta5.jar
jboss-modules.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
   org.jboss.modules.ConcurrentClassLoader (jboss-modules.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   org.jboss.modules.ConcurrentClassLoader$UnsafeHolder (jboss-modules.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
jboss-msc-1.2.0.CR1.jar -> jboss-modules.jar
jboss-msc-1.2.0.CR1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
jboss-msc-1.2.0.CR1.jar -> jboss-cli-client.jar
jboss-negotiation-common-2.2.6.Final.jar -> not found
jboss-negotiation-common-2.2.6.Final.jar -> picketbox-4.0.20.Beta2.jar
jboss-negotiation-common-2.2.6.Final.jar -> /opt/jdk1.8.0/jre/lib/jce.jar (compact1)
jboss-negotiation-common-2.2.6.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
jboss-negotiation-common-2.2.6.Final.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
jboss-negotiation-common-2.2.6.Final.jar -> picketbox-commons-1.0.0.final.jar
jboss-negotiation-common-2.2.6.Final.jar -> jboss-cli-client.jar
jboss-negotiation-extras-2.2.6.Final.jar -> picketbox-4.0.20.Beta2.jar
jboss-negotiation-extras-2.2.6.Final.jar -> jboss-negotiation-common-2.2.6.Final.jar
jboss-negotiation-extras-2.2.6.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
jboss-negotiation-extras-2.2.6.Final.jar -> picketbox-commons-1.0.0.final.jar
jboss-negotiation-extras-2.2.6.Final.jar -> jboss-cli-client.jar
jboss-negotiation-net-2.2.6.Final.jar -> picketbox-4.0.20.Beta2.jar
jboss-negotiation-net-2.2.6.Final.jar -> jboss-negotiation-common-2.2.6.Final.jar
jboss-negotiation-net-2.2.6.Final.jar -> jboss-negotiation-spnego-2.2.6.Final.jar
jboss-negotiation-net-2.2.6.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
jboss-negotiation-net-2.2.6.Final.jar -> jboss-cli-client.jar
jboss-negotiation-ntlm-2.2.6.Final.jar -> jboss-negotiation-common-2.2.6.Final.jar
jboss-negotiation-ntlm-2.2.6.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jboss-negotiation-spnego-2.2.6.Final.jar -> not found
jboss-negotiation-spnego-2.2.6.Final.jar -> picketbox-4.0.20.Beta2.jar
jboss-negotiation-spnego-2.2.6.Final.jar -> jboss-negotiation-common-2.2.6.Final.jar
jboss-negotiation-spnego-2.2.6.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
jboss-negotiation-spnego-2.2.6.Final.jar -> jboss-cli-client.jar
jboss-remote-naming-2.0.0.Beta2.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
jboss-remote-naming-2.0.0.Beta2.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
jboss-remote-naming-2.0.0.Beta2.jar -> jboss-cli-client.jar
jboss-remote-naming-2.0.0.Beta2.jar -> jboss-client.jar
jboss-remoting-4.0.0.Beta3.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
jboss-remoting-4.0.0.Beta3.jar -> jboss-cli-client.jar
jboss-rmi-api_1.0_spec-1.0.4.Final.jar -> jacorb-2.3.2-jbossorg-5.jar
jboss-rmi-api_1.0_spec-1.0.4.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
jboss-rmi-api_1.0_spec-1.0.4.Final.jar -> jboss-client.jar
   org.jboss.sun.corba.Bridge (jboss-rmi-api_1.0_spec-1.0.4.Final.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
      -> sun.reflect.ReflectionFactory                      JDK internal API (rt.jar)
      -> sun.reflect.ReflectionFactory$GetReflectionFactoryAction JDK internal API (rt.jar)
   org.jboss.sun.corba.Bridge$2 (jboss-rmi-api_1.0_spec-1.0.4.Final.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
jboss-saaj-api_1.3_spec-1.0.3.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
jboss-saaj-api_1.3_spec-1.0.3.Final.jar -> activation-1.1.1.jar
jboss-sasl-1.0.4.CR1.jar -> /opt/jdk1.8.0/jre/lib/jce.jar (compact1)
jboss-sasl-1.0.4.CR1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
jboss-sasl-1.0.4.CR1.jar -> jboss-cli-client.jar
jboss-seam-int.jar -> not found
jboss-seam-int.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jboss-seam-int.jar -> jboss-cli-client.jar
jboss-servlet-api_3.1_spec-1.0.0.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jboss-stdio-1.0.2.GA.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jboss-threads-2.1.1.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jboss-threads-2.1.1.Final.jar -> jboss-cli-client.jar
jboss-transaction-api_1.2_spec-1.0.0.Final.jar -> jboss-interceptors-api_1.2_spec-1.0.0.Final.jar
jboss-transaction-api_1.2_spec-1.0.0.Final.jar -> cdi-api-1.1.jar
jboss-transaction-api_1.2_spec-1.0.0.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
jboss-transaction-spi-7.1.0.Final.jar -> jboss-connector-api_1.7_spec-1.0.0.Final.jar
jboss-transaction-spi-7.1.0.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
jboss-transaction-spi-7.1.0.Final.jar -> jboss-cli-client.jar
jboss-transaction-spi-7.1.0.Final.jar -> jboss-client.jar
jbosstxbridge-5.0.0.CR2.jar -> jboss-connector-api_1.7_spec-1.0.0.Final.jar
jbosstxbridge-5.0.0.CR2.jar -> jboss-saaj-api_1.3_spec-1.0.3.Final.jar
jbosstxbridge-5.0.0.CR2.jar -> not found
jbosstxbridge-5.0.0.CR2.jar -> narayana-jts-jacorb-5.0.0.CR2.jar
jbosstxbridge-5.0.0.CR2.jar -> jbossxts-5.0.0.CR2.jar
jbosstxbridge-5.0.0.CR2.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jbosstxbridge-5.0.0.CR2.jar -> jbossws-api-1.0.2.Final.jar
jbosstxbridge-5.0.0.CR2.jar -> jboss-cli-client.jar
jbosstxbridge-5.0.0.CR2.jar -> jboss-client.jar
jbosstxbridge-5.0.0.CR2.jar -> jboss-jaxws-api_2.2_spec-2.0.2.Final.jar
jboss-vfs-3.2.2.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
jboss-vfs-3.2.2.Final.jar -> jboss-cli-client.jar
jboss-websocket-api_1.0_spec-1.0.0.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jbossws-api-1.0.2.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
jbossws-api-1.0.2.Final.jar -> jboss-cli-client.jar
jbossws-api-1.0.2.Final.jar -> jboss-jaxws-api_2.2_spec-2.0.2.Final.jar
jbossws-common-2.2.3.Final.jar -> jbossws-spi-2.2.2.Final.jar
jbossws-common-2.2.3.Final.jar -> jboss-saaj-api_1.3_spec-1.0.3.Final.jar
jbossws-common-2.2.3.Final.jar -> jsr181-api-1.0-MR1.jar
jbossws-common-2.2.3.Final.jar -> wsdl4j-1.6.3.jar
jbossws-common-2.2.3.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
jbossws-common-2.2.3.Final.jar -> activation-1.1.1.jar
jbossws-common-2.2.3.Final.jar -> jboss-jaxws-api_2.2_spec-2.0.2.Final.jar
jbossws-common-2.2.3.Final.jar -> jboss-jaxb-intros-1.0.2.GA.jar
jbossws-common-2.2.3.Final.jar -> jboss-jaxrpc-api_1.1_spec-1.0.1.Final.jar
jbossws-common-2.2.3.Final.jar -> jboss-common-core-2.2.22.GA.jar
jbossws-common-2.2.3.Final.jar -> jboss-annotations-api_1.2_spec-1.0.0.Final.jar
jbossws-common-2.2.3.Final.jar -> jbossws-api-1.0.2.Final.jar
jbossws-common-2.2.3.Final.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
jbossws-common-2.2.3.Final.jar -> jboss-cli-client.jar
jbossws-common-2.2.3.Final.jar -> jboss-client.jar
jbossws-common-tools-1.2.0.Final.jar -> not found
jbossws-common-tools-1.2.0.Final.jar -> log4j-jboss-logmanager-1.0.2.Final.jar
jbossws-common-tools-1.2.0.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jbossws-common-tools-1.2.0.Final.jar -> jbossws-api-1.0.2.Final.jar
jbossws-common-tools-1.2.0.Final.jar -> java-getopt-1.0.13.jar
jbossws-cxf-client-4.2.3.Final.jar -> jboss-saaj-api_1.3_spec-1.0.3.Final.jar
jbossws-cxf-client-4.2.3.Final.jar -> jbossws-spi-2.2.2.Final.jar
jbossws-cxf-client-4.2.3.Final.jar -> not found
jbossws-cxf-client-4.2.3.Final.jar -> cxf-rt-core-2.7.7.jar
jbossws-cxf-client-4.2.3.Final.jar -> cxf-rt-databinding-jaxb-2.7.7.jar
jbossws-cxf-client-4.2.3.Final.jar -> cxf-tools-java2ws-2.7.7.jar
jbossws-cxf-client-4.2.3.Final.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
jbossws-cxf-client-4.2.3.Final.jar -> wsdl4j-1.6.3.jar
jbossws-cxf-client-4.2.3.Final.jar -> cxf-tools-common-2.7.7.jar
jbossws-cxf-client-4.2.3.Final.jar -> cxf-rt-frontend-jaxws-2.7.7.jar
jbossws-cxf-client-4.2.3.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
jbossws-cxf-client-4.2.3.Final.jar -> cxf-rt-transports-http-2.7.7.jar
jbossws-cxf-client-4.2.3.Final.jar -> jbossws-common-2.2.3.Final.jar
jbossws-cxf-client-4.2.3.Final.jar -> jboss-jaxws-api_2.2_spec-2.0.2.Final.jar
jbossws-cxf-client-4.2.3.Final.jar -> cxf-api-2.7.7.jar
jbossws-cxf-client-4.2.3.Final.jar -> jbossws-api-1.0.2.Final.jar
jbossws-cxf-client-4.2.3.Final.jar -> cxf-tools-wsdlto-core-2.7.7.jar
jbossws-cxf-client-4.2.3.Final.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
jbossws-cxf-client-4.2.3.Final.jar -> jboss-cli-client.jar
jbossws-cxf-client-4.2.3.Final.jar -> wss4j-1.6.12.jar
jbossws-cxf-client-4.2.3.Final.jar -> cxf-rt-frontend-simple-2.7.7.jar
jbossws-cxf-server-4.2.3.Final.jar -> jbossws-spi-2.2.2.Final.jar
jbossws-cxf-server-4.2.3.Final.jar -> not found
jbossws-cxf-server-4.2.3.Final.jar -> picketbox-4.0.20.Beta2.jar
jbossws-cxf-server-4.2.3.Final.jar -> jsr181-api-1.0-MR1.jar
jbossws-cxf-server-4.2.3.Final.jar -> cxf-rt-core-2.7.7.jar
jbossws-cxf-server-4.2.3.Final.jar -> wsdl4j-1.6.3.jar
jbossws-cxf-server-4.2.3.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
jbossws-cxf-server-4.2.3.Final.jar -> cxf-rt-transports-http-2.7.7.jar
jbossws-cxf-server-4.2.3.Final.jar -> cxf-rt-ws-addr-2.7.7.jar
jbossws-cxf-server-4.2.3.Final.jar -> jbossws-common-2.2.3.Final.jar
jbossws-cxf-server-4.2.3.Final.jar -> cxf-rt-management-2.7.7.jar
jbossws-cxf-server-4.2.3.Final.jar -> cxf-api-2.7.7.jar
jbossws-cxf-server-4.2.3.Final.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
jbossws-cxf-server-4.2.3.Final.jar -> cxf-rt-ws-rm-2.7.7.jar
jbossws-cxf-server-4.2.3.Final.jar -> cxf-services-ws-discovery-api-2.7.7.jar
jbossws-cxf-server-4.2.3.Final.jar -> cxf-rt-ws-policy-2.7.7.jar
jbossws-cxf-server-4.2.3.Final.jar -> cxf-rt-frontend-jaxws-2.7.7.jar
jbossws-cxf-server-4.2.3.Final.jar -> cxf-rt-ws-security-2.7.7.jar
jbossws-cxf-server-4.2.3.Final.jar -> jboss-jaxws-api_2.2_spec-2.0.2.Final.jar
jbossws-cxf-server-4.2.3.Final.jar -> jboss-common-core-2.2.22.GA.jar
jbossws-cxf-server-4.2.3.Final.jar -> jbossws-cxf-client-4.2.3.Final.jar
jbossws-cxf-server-4.2.3.Final.jar -> jbossws-api-1.0.2.Final.jar
jbossws-cxf-server-4.2.3.Final.jar -> cxf-rt-bindings-soap-2.7.7.jar
jbossws-cxf-server-4.2.3.Final.jar -> wss4j-1.6.12.jar
jbossws-cxf-server-4.2.3.Final.jar -> cxf-rt-frontend-simple-2.7.7.jar
jbossws-cxf-transports-httpserver-4.2.3.Final.jar -> jaxws-jboss-httpserver-httpspi-1.0.1.GA.jar
jbossws-cxf-transports-httpserver-4.2.3.Final.jar -> cxf-rt-frontend-jaxws-2.7.7.jar
jbossws-cxf-transports-httpserver-4.2.3.Final.jar -> jboss-annotations-api_1.2_spec-1.0.0.Final.jar
jbossws-cxf-transports-httpserver-4.2.3.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jbossws-cxf-transports-httpserver-4.2.3.Final.jar -> cxf-api-2.7.7.jar
jbossws-cxf-transports-httpserver-4.2.3.Final.jar -> httpserver-1.0.1.Final.jar
jbossws-cxf-transports-httpserver-4.2.3.Final.jar -> cxf-rt-transports-http-2.7.7.jar
jbossws-cxf-transports-httpserver-4.2.3.Final.jar -> jboss-jaxws-api_2.2_spec-2.0.2.Final.jar
jbossws-cxf-transports-udp-4.2.3.Final.jar -> jboss-annotations-api_1.2_spec-1.0.0.Final.jar
jbossws-cxf-transports-udp-4.2.3.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jbossws-cxf-transports-udp-4.2.3.Final.jar -> cxf-api-2.7.7.jar
jbossws-spi-2.2.2.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
jbossws-spi-2.2.2.Final.jar -> jbossws-api-1.0.2.Final.jar
jbossws-spi-2.2.2.Final.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
jbossws-spi-2.2.2.Final.jar -> jboss-cli-client.jar
jbossws-spi-2.2.2.Final.jar -> jboss-client.jar
jbossws-spi-2.2.2.Final.jar -> jboss-jaxws-api_2.2_spec-2.0.2.Final.jar
jbossxacml-2.0.8.Final.jar -> /opt/jdk1.8.0/jre/lib/jce.jar (compact1)
jbossxacml-2.0.8.Final.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
jbossxacml-2.0.8.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
jbossxacml-2.0.8.Final.jar -> picketbox-commons-1.0.0.final.jar
jbossxb-2.0.3.GA.jar -> not found
jbossxb-2.0.3.GA.jar -> xercesImpl-2.9.1-jbossas-2.jar
jbossxb-2.0.3.GA.jar -> jboss-common-core-2.2.22.GA.jar
jbossxb-2.0.3.GA.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
jbossxb-2.0.3.GA.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
jbossxb-2.0.3.GA.jar -> activation-1.1.1.jar
jbossxb-2.0.3.GA.jar -> jboss-cli-client.jar
jbossxts-5.0.0.CR2.jar -> jboss-saaj-api_1.3_spec-1.0.3.Final.jar
jbossxts-5.0.0.CR2.jar -> jsr181-api-1.0-MR1.jar
jbossxts-5.0.0.CR2.jar -> narayana-jts-jacorb-5.0.0.CR2.jar
jbossxts-5.0.0.CR2.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
jbossxts-5.0.0.CR2.jar -> jboss-annotations-api_1.2_spec-1.0.0.Final.jar
jbossxts-5.0.0.CR2.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
jbossxts-5.0.0.CR2.jar -> jbossws-api-1.0.2.Final.jar
jbossxts-5.0.0.CR2.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
jbossxts-5.0.0.CR2.jar -> jboss-cli-client.jar
jbossxts-5.0.0.CR2.jar -> jboss-jaxws-api_2.2_spec-2.0.2.Final.jar
jcip-annotations-1.0.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jcl-over-slf4j-1.7.2.jbossorg-1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jcl-over-slf4j-1.7.2.jbossorg-1.jar -> slf4j-api-1.7.2.jbossorg-1.jar
jdom-1.1.2.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
jdom-1.1.2.jar -> jaxen-1.1.3.jar
jettison-1.3.1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
jgroups-3.4.1.Final.jar -> not found
jgroups-3.4.1.Final.jar -> /opt/jdk1.8.0/jre/lib/jce.jar (compact1)
jgroups-3.4.1.Final.jar -> log4j-jboss-logmanager-1.0.2.Final.jar
jgroups-3.4.1.Final.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
jgroups-3.4.1.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
jipijapa-eclipselink-1.0.0.Final.jar -> not found
jipijapa-eclipselink-1.0.0.Final.jar -> jipijapa-spi-1.0.0.Final.jar
jipijapa-eclipselink-1.0.0.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
jipijapa-eclipselink-1.0.0.Final.jar -> jboss-cli-client.jar
jipijapa-eclipselink-1.0.0.Final.jar -> jboss-client.jar
jipijapa-hibernate3-1.0.0.Final.jar -> not found
jipijapa-hibernate3-1.0.0.Final.jar -> jipijapa-spi-1.0.0.Final.jar
jipijapa-hibernate3-1.0.0.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jipijapa-hibernate3-1.0.0.Final.jar -> jandex-1.1.0.Final.jar
jipijapa-hibernate3-1.0.0.Final.jar -> hibernate-core-4.3.0.Final.jar
jipijapa-hibernate3-1.0.0.Final.jar -> jboss-cli-client.jar
jipijapa-hibernate3-1.0.0.Final.jar -> hibernate-entitymanager-4.3.0.Final.jar
jipijapa-hibernate3-1.0.0.Final.jar -> jboss-client.jar
jipijapa-hibernate4-1-1.0.0.Final.jar -> not found
jipijapa-hibernate4-1-1.0.0.Final.jar -> jipijapa-spi-1.0.0.Final.jar
jipijapa-hibernate4-1-1.0.0.Final.jar -> hibernate-infinispan-4.3.0.Final.jar
jipijapa-hibernate4-1-1.0.0.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jipijapa-hibernate4-1-1.0.0.Final.jar -> hibernate-jpa-2.1-api-1.0.0.Final.jar
jipijapa-hibernate4-1-1.0.0.Final.jar -> jandex-1.1.0.Final.jar
jipijapa-hibernate4-1-1.0.0.Final.jar -> hibernate-core-4.3.0.Final.jar
jipijapa-hibernate4-1-1.0.0.Final.jar -> jboss-cli-client.jar
jipijapa-hibernate4-1-1.0.0.Final.jar -> hibernate-entitymanager-4.3.0.Final.jar
jipijapa-hibernate4-1-1.0.0.Final.jar -> jboss-client.jar
jipijapa-hibernate4-1-1.0.0.Final.jar -> infinispan-core-6.0.1.Final.jar
jipijapa-hibernate4-3-1.0.0.Final.jar -> jipijapa-spi-1.0.0.Final.jar
jipijapa-hibernate4-3-1.0.0.Final.jar -> hibernate-infinispan-4.3.0.Final.jar
jipijapa-hibernate4-3-1.0.0.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jipijapa-hibernate4-3-1.0.0.Final.jar -> hibernate-jpa-2.1-api-1.0.0.Final.jar
jipijapa-hibernate4-3-1.0.0.Final.jar -> hibernate-core-4.3.0.Final.jar
jipijapa-hibernate4-3-1.0.0.Final.jar -> jboss-cli-client.jar
jipijapa-hibernate4-3-1.0.0.Final.jar -> hibernate-entitymanager-4.3.0.Final.jar
jipijapa-hibernate4-3-1.0.0.Final.jar -> jboss-client.jar
jipijapa-hibernate4-3-1.0.0.Final.jar -> infinispan-core-6.0.1.Final.jar
jipijapa-openjpa-1.0.0.Final.jar -> not found
jipijapa-openjpa-1.0.0.Final.jar -> jipijapa-spi-1.0.0.Final.jar
jipijapa-openjpa-1.0.0.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jipijapa-openjpa-1.0.0.Final.jar -> hibernate-jpa-2.1-api-1.0.0.Final.jar
jipijapa-openjpa-1.0.0.Final.jar -> jandex-1.1.0.Final.jar
jipijapa-spi-1.0.0.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
jipijapa-spi-1.0.0.Final.jar -> hibernate-jpa-2.1-api-1.0.0.Final.jar
jipijapa-spi-1.0.0.Final.jar -> jandex-1.1.0.Final.jar
jipijapa-spi-1.0.0.Final.jar -> jboss-client.jar
joda-time-1.6.2.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jose-jwt-3.0.6.Final.jar -> jackson-mapper-asl-1.9.12.jar
jose-jwt-3.0.6.Final.jar -> /opt/jdk1.8.0/jre/lib/jce.jar (compact1)
jose-jwt-3.0.6.Final.jar -> jcip-annotations-1.0.jar
jose-jwt-3.0.6.Final.jar -> bcprov-jdk16-1.46.jar
jose-jwt-3.0.6.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jose-jwt-3.0.6.Final.jar -> jackson-core-asl-1.9.12.jar
jose-jwt-3.0.6.Final.jar -> resteasy-jackson-provider-3.0.6.Final.jar
jose-jwt-3.0.6.Final.jar -> resteasy-jaxrs-3.0.6.Final.jar
jose-jwt-3.0.6.Final.jar -> jaxrs-api-3.0.6.Final.jar
jsf-impl-2.2.4-jbossorg-1.jar -> jboss-jsf-api_2.2_spec-2.2.4.jar
jsf-impl-2.2.4-jbossorg-1.jar -> not found
jsf-impl-2.2.4-jbossorg-1.jar -> /opt/jdk1.8.0/jre/lib/jce.jar (compact1)
jsf-impl-2.2.4-jbossorg-1.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
jsf-impl-2.2.4-jbossorg-1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
jsf-impl-2.2.4-jbossorg-1.jar -> javax.el-3.0-b07.jar
jsf-impl-2.2.4-jbossorg-1.jar -> hibernate-jpa-2.1-api-1.0.0.Final.jar
jsf-impl-2.2.4-jbossorg-1.jar -> jboss-jsp-api_2.3_spec-1.0.0.Beta1.jar
jsf-impl-2.2.4-jbossorg-1.jar -> jboss-jaxws-api_2.2_spec-2.0.2.Final.jar
jsf-impl-2.2.4-jbossorg-1.jar -> jboss-jstl-api_1.2_spec-1.0.4.Beta1.jar
jsf-impl-2.2.4-jbossorg-1.jar -> javax.inject-1.jar
jsf-impl-2.2.4-jbossorg-1.jar -> cdi-api-1.1.jar
jsf-impl-2.2.4-jbossorg-1.jar -> jboss-annotations-api_1.2_spec-1.0.0.Final.jar
jsf-impl-2.2.4-jbossorg-1.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
jsf-impl-2.2.4-jbossorg-1.jar -> jboss-client.jar
jsf-impl-2.2.4-jbossorg-1.jar -> validation-api-1.1.0.Final.jar
jsoup-1.6.1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jsr181-api-1.0-MR1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jul-to-slf4j-stub-1.0.1.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
jul-to-slf4j-stub-1.0.1.Final.jar -> slf4j-api-1.7.2.jbossorg-1.jar
log4j-jboss-logmanager-1.0.2.Final.jar -> jboss-logmanager-1.5.0.Final.jar
log4j-jboss-logmanager-1.0.2.Final.jar -> jboss-modules.jar
log4j-jboss-logmanager-1.0.2.Final.jar -> javax.mail-1.5.0.jar
log4j-jboss-logmanager-1.0.2.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
log4j-jboss-logmanager-1.0.2.Final.jar -> jboss-client.jar
lucene-analyzers-3.6.2.jar -> lucene-core-3.6.2.jar
lucene-analyzers-3.6.2.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
lucene-core-3.6.2.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
lucene-facet-3.6.2.jar -> lucene-core-3.6.2.jar
lucene-facet-3.6.2.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
lucene-memory-3.6.2.jar -> lucene-core-3.6.2.jar
lucene-memory-3.6.2.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
mod_cluster-container-spi-1.3.0.Alpha1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
mod_cluster-container-spi-1.3.0.Alpha1.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
mod_cluster-core-1.3.0.Alpha1.jar -> mod_cluster-container-spi-1.3.0.Alpha1.jar
mod_cluster-core-1.3.0.Alpha1.jar -> jcip-annotations-1.0.jar
mod_cluster-core-1.3.0.Alpha1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
mod_cluster-core-1.3.0.Alpha1.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
mod_cluster-core-1.3.0.Alpha1.jar -> jboss-cli-client.jar
narayana-jts-integration-5.0.0.CR2.jar -> jboss-connector-api_1.7_spec-1.0.0.Final.jar
narayana-jts-integration-5.0.0.CR2.jar -> jacorb-2.3.2-jbossorg-5.jar
narayana-jts-integration-5.0.0.CR2.jar -> wildfly-transactions-8.0.0.Beta2-SNAPSHOT.jar
narayana-jts-integration-5.0.0.CR2.jar -> narayana-jts-jacorb-5.0.0.CR2.jar
narayana-jts-integration-5.0.0.CR2.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
narayana-jts-integration-5.0.0.CR2.jar -> jboss-cli-client.jar
narayana-jts-integration-5.0.0.CR2.jar -> jboss-client.jar
narayana-jts-integration-5.0.0.CR2.jar -> jboss-transaction-spi-7.1.0.Final.jar
narayana-jts-jacorb-5.0.0.CR2.jar -> jboss-connector-api_1.7_spec-1.0.0.Final.jar
narayana-jts-jacorb-5.0.0.CR2.jar -> jboss-interceptors-api_1.2_spec-1.0.0.Final.jar
narayana-jts-jacorb-5.0.0.CR2.jar -> not found
narayana-jts-jacorb-5.0.0.CR2.jar -> jacorb-2.3.2-jbossorg-5.jar
narayana-jts-jacorb-5.0.0.CR2.jar -> javax.inject-1.jar
narayana-jts-jacorb-5.0.0.CR2.jar -> cdi-api-1.1.jar
narayana-jts-jacorb-5.0.0.CR2.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
narayana-jts-jacorb-5.0.0.CR2.jar -> jboss-cli-client.jar
narayana-jts-jacorb-5.0.0.CR2.jar -> hornetq-journal-2.4.0.Final.jar
narayana-jts-jacorb-5.0.0.CR2.jar -> jboss-client.jar
narayana-jts-jacorb-5.0.0.CR2.jar -> jboss-transaction-spi-7.1.0.Final.jar
narayana-jts-jacorb-5.0.0.CR2.jar -> jaxrs-api-3.0.6.Final.jar
neethi-3.0.2.jar -> not found
neethi-3.0.2.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
netty-3.6.6.Final.jar -> not found
netty-3.6.6.Final.jar -> log4j-jboss-logmanager-1.0.2.Final.jar
netty-3.6.6.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
netty-3.6.6.Final.jar -> protobuf-java-2.5.0.jar
netty-3.6.6.Final.jar -> jcl-over-slf4j-1.7.2.jbossorg-1.jar
netty-3.6.6.Final.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
netty-3.6.6.Final.jar -> slf4j-api-1.7.2.jbossorg-1.jar
netty-3.6.6.Final.jar -> org.osgi.core-5.0.0.jar
netty-3.6.6.Final.jar -> jboss-cli-client.jar
netty-all-4.0.13.Final.jar -> not found
netty-all-4.0.13.Final.jar -> log4j-jboss-logmanager-1.0.2.Final.jar
netty-all-4.0.13.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
netty-all-4.0.13.Final.jar -> protobuf-java-2.5.0.jar
netty-all-4.0.13.Final.jar -> jcl-over-slf4j-1.7.2.jbossorg-1.jar
netty-all-4.0.13.Final.jar -> javassist-3.18.1-GA.jar
netty-all-4.0.13.Final.jar -> slf4j-api-1.7.2.jbossorg-1.jar
netty-all-4.0.13.Final.jar -> jboss-cli-client.jar
   io.netty.util.internal.PlatformDependent0 (netty-all-4.0.13.Final.jar)
      -> sun.misc.Cleaner                                   JDK internal API (rt.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   io.netty.util.internal.chmv8.ConcurrentHashMapV8 (netty-all-4.0.13.Final.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   io.netty.util.internal.chmv8.ConcurrentHashMapV8$1 (netty-all-4.0.13.Final.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   io.netty.util.internal.chmv8.ConcurrentHashMapV8$TreeBin (netty-all-4.0.13.Final.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   io.netty.util.internal.chmv8.CountedCompleter (netty-all-4.0.13.Final.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   io.netty.util.internal.chmv8.CountedCompleter$1 (netty-all-4.0.13.Final.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   io.netty.util.internal.chmv8.ForkJoinPool (netty-all-4.0.13.Final.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   io.netty.util.internal.chmv8.ForkJoinPool$2 (netty-all-4.0.13.Final.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   io.netty.util.internal.chmv8.ForkJoinPool$WorkQueue (netty-all-4.0.13.Final.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   io.netty.util.internal.chmv8.ForkJoinTask (netty-all-4.0.13.Final.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   io.netty.util.internal.chmv8.ForkJoinTask$1 (netty-all-4.0.13.Final.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   io.netty.util.internal.chmv8.Striped64 (netty-all-4.0.13.Final.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   io.netty.util.internal.chmv8.Striped64$1 (netty-all-4.0.13.Final.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   io.netty.util.internal.chmv8.Striped64$Cell (netty-all-4.0.13.Final.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
netty-xnio-transport-0.1.0.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
netty-xnio-transport-0.1.0.jar -> jboss-cli-client.jar
netty-xnio-transport-0.1.0.jar -> jboss-client.jar
opensaml-2.5.3.jar -> not found
opensaml-2.5.3.jar -> velocity-1.7.jar
opensaml-2.5.3.jar -> /opt/jdk1.8.0/jre/lib/jce.jar (compact1)
opensaml-2.5.3.jar -> xmltooling-1.3.4.jar
opensaml-2.5.3.jar -> xmlsec-1.5.5.jar
opensaml-2.5.3.jar -> openws-1.4.4.jar
opensaml-2.5.3.jar -> bcprov-jdk16-1.46.jar
opensaml-2.5.3.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
opensaml-2.5.3.jar -> slf4j-api-1.7.2.jbossorg-1.jar
opensaml-2.5.3.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
opensaml-2.5.3.jar -> joda-time-1.6.2.jar
openws-1.4.4.jar -> not found
openws-1.4.4.jar -> jcip-annotations-1.0.jar
openws-1.4.4.jar -> xmltooling-1.3.4.jar
openws-1.4.4.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
openws-1.4.4.jar -> slf4j-api-1.7.2.jbossorg-1.jar
openws-1.4.4.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
openws-1.4.4.jar -> joda-time-1.6.2.jar
org.osgi.core-5.0.0.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
picketbox-4.0.20.Beta2.jar -> jboss-connector-api_1.7_spec-1.0.0.Final.jar
picketbox-4.0.20.Beta2.jar -> jbossxacml-2.0.8.Final.jar
picketbox-4.0.20.Beta2.jar -> /opt/jdk1.8.0/jre/lib/jce.jar (compact1)
picketbox-4.0.20.Beta2.jar -> jboss-jacc-api_1.5_spec-1.0.0.Beta1.jar
picketbox-4.0.20.Beta2.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
picketbox-4.0.20.Beta2.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
picketbox-4.0.20.Beta2.jar -> hibernate-jpa-2.1-api-1.0.0.Final.jar
picketbox-4.0.20.Beta2.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
picketbox-4.0.20.Beta2.jar -> hibernate-core-4.3.0.Final.jar
picketbox-4.0.20.Beta2.jar -> jboss-jaspi-api_1.1_spec-1.0.0.Alpha1.jar
picketbox-4.0.20.Beta2.jar -> jboss-cli-client.jar
picketbox-4.0.20.Beta2.jar -> jboss-client.jar
picketbox-commons-1.0.0.final.jar -> /opt/jdk1.8.0/jre/lib/jce.jar (compact1)
picketbox-commons-1.0.0.final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
picketbox-infinispan-4.0.20.Beta2.jar -> picketbox-4.0.20.Beta2.jar
picketbox-infinispan-4.0.20.Beta2.jar -> jboss-jacc-api_1.5_spec-1.0.0.Beta1.jar
picketbox-infinispan-4.0.20.Beta2.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
picketlink-api-2.5.1.Final.jar -> javax.inject-1.jar
picketlink-api-2.5.1.Final.jar -> cdi-api-1.1.jar
picketlink-api-2.5.1.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
picketlink-api-2.5.1.Final.jar -> picketlink-idm-api-2.5.1.Final.jar
picketlink-api-2.5.1.Final.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
picketlink-api-2.5.1.Final.jar -> picketlink-common-2.5.1.Final.jar
picketlink-common-2.5.1.Final.jar -> /opt/jdk1.8.0/jre/lib/jce.jar (compact1)
picketlink-common-2.5.1.Final.jar -> javax.inject-1.jar
picketlink-common-2.5.1.Final.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
picketlink-common-2.5.1.Final.jar -> xmlsec-1.5.5.jar
picketlink-common-2.5.1.Final.jar -> cdi-api-1.1.jar
picketlink-common-2.5.1.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
picketlink-common-2.5.1.Final.jar -> jboss-cli-client.jar
picketlink-common-2.5.1.Final.jar -> jboss-jaxws-api_2.2_spec-2.0.2.Final.jar
picketlink-config-2.5.1.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
picketlink-config-2.5.1.Final.jar -> picketlink-idm-api-2.5.1.Final.jar
picketlink-config-2.5.1.Final.jar -> picketlink-common-2.5.1.Final.jar
picketlink-federation-2.5.1.Final.jar -> jboss-saaj-api_1.3_spec-1.0.3.Final.jar
picketlink-federation-2.5.1.Final.jar -> picketbox-4.0.20.Beta2.jar
picketlink-federation-2.5.1.Final.jar -> jbossxacml-2.0.8.Final.jar
picketlink-federation-2.5.1.Final.jar -> /opt/jdk1.8.0/jre/lib/jce.jar (compact1)
picketlink-federation-2.5.1.Final.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
picketlink-federation-2.5.1.Final.jar -> xmlsec-1.5.5.jar
picketlink-federation-2.5.1.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
picketlink-federation-2.5.1.Final.jar -> hibernate-jpa-2.1-api-1.0.0.Final.jar
picketlink-federation-2.5.1.Final.jar -> picketlink-config-2.5.1.Final.jar
picketlink-federation-2.5.1.Final.jar -> jboss-jaxws-api_2.2_spec-2.0.2.Final.jar
picketlink-federation-2.5.1.Final.jar -> jboss-annotations-api_1.2_spec-1.0.0.Final.jar
picketlink-federation-2.5.1.Final.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
picketlink-federation-2.5.1.Final.jar -> picketlink-common-2.5.1.Final.jar
picketlink-federation-2.5.1.Final.jar -> jboss-cli-client.jar
picketlink-idm-api-2.5.1.Final.jar -> /opt/jdk1.8.0/jre/lib/jce.jar (compact1)
picketlink-idm-api-2.5.1.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
picketlink-idm-api-2.5.1.Final.jar -> jboss-cli-client.jar
picketlink-idm-api-2.5.1.Final.jar -> picketlink-common-2.5.1.Final.jar
picketlink-idm-impl-2.5.1.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
picketlink-idm-impl-2.5.1.Final.jar -> picketlink-idm-api-2.5.1.Final.jar
picketlink-idm-impl-2.5.1.Final.jar -> hibernate-jpa-2.1-api-1.0.0.Final.jar
picketlink-idm-impl-2.5.1.Final.jar -> picketlink-common-2.5.1.Final.jar
picketlink-impl-2.5.1.Final.jar -> picketlink-api-2.5.1.Final.jar
picketlink-impl-2.5.1.Final.jar -> javax.inject-1.jar
picketlink-impl-2.5.1.Final.jar -> cdi-api-1.1.jar
picketlink-impl-2.5.1.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
picketlink-impl-2.5.1.Final.jar -> picketlink-idm-api-2.5.1.Final.jar
picketlink-impl-2.5.1.Final.jar -> hibernate-jpa-2.1-api-1.0.0.Final.jar
picketlink-impl-2.5.1.Final.jar -> picketlink-idm-impl-2.5.1.Final.jar
picketlink-jbas7-2.5.1.Final.jar -> picketbox-4.0.20.Beta2.jar
picketlink-jbas7-2.5.1.Final.jar -> not found
picketlink-jbas7-2.5.1.Final.jar -> jboss-saaj-api_1.3_spec-1.0.3.Final.jar
picketlink-jbas7-2.5.1.Final.jar -> jbossxacml-2.0.8.Final.jar
picketlink-jbas7-2.5.1.Final.jar -> log4j-jboss-logmanager-1.0.2.Final.jar
picketlink-jbas7-2.5.1.Final.jar -> jboss-jacc-api_1.5_spec-1.0.0.Beta1.jar
picketlink-jbas7-2.5.1.Final.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
picketlink-jbas7-2.5.1.Final.jar -> xmlsec-1.5.5.jar
picketlink-jbas7-2.5.1.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
picketlink-jbas7-2.5.1.Final.jar -> picketlink-federation-2.5.1.Final.jar
picketlink-jbas7-2.5.1.Final.jar -> picketlink-config-2.5.1.Final.jar
picketlink-jbas7-2.5.1.Final.jar -> jboss-jaxws-api_2.2_spec-2.0.2.Final.jar
picketlink-jbas7-2.5.1.Final.jar -> cxf-api-2.7.7.jar
picketlink-jbas7-2.5.1.Final.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
picketlink-jbas7-2.5.1.Final.jar -> picketlink-common-2.5.1.Final.jar
picketlink-jbas7-2.5.1.Final.jar -> jboss-cli-client.jar
protobuf-java-2.5.0.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
proton-api-0.4.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
proton-j-impl-0.4.jar -> bcprov-jdk16-1.46.jar
proton-j-impl-0.4.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
proton-j-impl-0.4.jar -> proton-api-0.4.jar
proton-jms-0.4.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
proton-jms-0.4.jar -> proton-j-impl-0.4.jar
proton-jms-0.4.jar -> proton-api-0.4.jar
proton-jms-0.4.jar -> jboss-client.jar
protostream-1.0.0.CR1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
protostream-1.0.0.CR1.jar -> protobuf-java-2.5.0.jar
protostream-1.0.0.CR1.jar -> jboss-cli-client.jar
relaxngDatatype-2011.1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
remoting-jmx-2.0.0.CR4.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
remoting-jmx-2.0.0.CR4.jar -> jboss-cli-client.jar
restat-api-5.0.0.CR2.jar -> restat-util-5.0.0.CR2.jar
restat-api-5.0.0.CR2.jar -> narayana-jts-jacorb-5.0.0.CR2.jar
restat-api-5.0.0.CR2.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
restat-api-5.0.0.CR2.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
restat-api-5.0.0.CR2.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
restat-api-5.0.0.CR2.jar -> jboss-cli-client.jar
restat-api-5.0.0.CR2.jar -> jaxrs-api-3.0.6.Final.jar
restat-bridge-5.0.0.CR2.jar -> jboss-connector-api_1.7_spec-1.0.0.Final.jar
restat-bridge-5.0.0.CR2.jar -> narayana-jts-jacorb-5.0.0.CR2.jar
restat-bridge-5.0.0.CR2.jar -> restat-integration-5.0.0.CR2.jar
restat-bridge-5.0.0.CR2.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
restat-bridge-5.0.0.CR2.jar -> resteasy-jaxrs-3.0.6.Final.jar
restat-bridge-5.0.0.CR2.jar -> jboss-cli-client.jar
restat-bridge-5.0.0.CR2.jar -> jboss-client.jar
restat-bridge-5.0.0.CR2.jar -> jaxrs-api-3.0.6.Final.jar
restat-integration-5.0.0.CR2.jar -> restat-util-5.0.0.CR2.jar
restat-integration-5.0.0.CR2.jar -> restat-api-5.0.0.CR2.jar
restat-integration-5.0.0.CR2.jar -> narayana-jts-jacorb-5.0.0.CR2.jar
restat-integration-5.0.0.CR2.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
restat-integration-5.0.0.CR2.jar -> resteasy-jaxrs-3.0.6.Final.jar
restat-integration-5.0.0.CR2.jar -> jboss-cli-client.jar
restat-integration-5.0.0.CR2.jar -> jaxrs-api-3.0.6.Final.jar
restat-util-5.0.0.CR2.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
restat-util-5.0.0.CR2.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
restat-util-5.0.0.CR2.jar -> resteasy-jaxrs-3.0.6.Final.jar
restat-util-5.0.0.CR2.jar -> jboss-cli-client.jar
restat-util-5.0.0.CR2.jar -> jaxrs-api-3.0.6.Final.jar
resteasy-atom-provider-3.0.6.Final.jar -> jaxb-impl-2.2.5.jboss-1.jar
resteasy-atom-provider-3.0.6.Final.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
resteasy-atom-provider-3.0.6.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
resteasy-atom-provider-3.0.6.Final.jar -> resteasy-jaxb-provider-3.0.6.Final.jar
resteasy-atom-provider-3.0.6.Final.jar -> resteasy-jaxrs-3.0.6.Final.jar
resteasy-atom-provider-3.0.6.Final.jar -> jaxrs-api-3.0.6.Final.jar
resteasy-cdi-3.0.6.Final.jar -> cdi-api-1.1.jar
resteasy-cdi-3.0.6.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
resteasy-cdi-3.0.6.Final.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
resteasy-cdi-3.0.6.Final.jar -> resteasy-jaxrs-3.0.6.Final.jar
resteasy-cdi-3.0.6.Final.jar -> jaxrs-api-3.0.6.Final.jar
resteasy-client-3.0.6.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
resteasy-client-3.0.6.Final.jar -> httpclient-4.2.1.jar
resteasy-client-3.0.6.Final.jar -> commons-io-2.1.jar
resteasy-client-3.0.6.Final.jar -> httpcore-4.2.1.jar
resteasy-client-3.0.6.Final.jar -> resteasy-jaxrs-3.0.6.Final.jar
resteasy-client-3.0.6.Final.jar -> jaxrs-api-3.0.6.Final.jar
resteasy-crypto-3.0.6.Final.jar -> bcmail-jdk16-1.46.jar
resteasy-crypto-3.0.6.Final.jar -> javax.mail-1.5.0.jar
resteasy-crypto-3.0.6.Final.jar -> bcprov-jdk16-1.46.jar
resteasy-crypto-3.0.6.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
resteasy-crypto-3.0.6.Final.jar -> activation-1.1.1.jar
resteasy-crypto-3.0.6.Final.jar -> resteasy-jaxrs-3.0.6.Final.jar
resteasy-crypto-3.0.6.Final.jar -> jaxrs-api-3.0.6.Final.jar
resteasy-jackson2-provider-3.0.6.Final.jar -> jackson-core-2.2.3.jar
resteasy-jackson2-provider-3.0.6.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
resteasy-jackson2-provider-3.0.6.Final.jar -> resteasy-jaxrs-3.0.6.Final.jar
resteasy-jackson2-provider-3.0.6.Final.jar -> jackson-jaxrs-base-2.2.3.jar
resteasy-jackson2-provider-3.0.6.Final.jar -> jackson-databind-2.2.3.jar
resteasy-jackson2-provider-3.0.6.Final.jar -> jaxrs-api-3.0.6.Final.jar
resteasy-jackson2-provider-3.0.6.Final.jar -> jackson-jaxrs-json-provider-2.2.3.jar
resteasy-jackson-provider-3.0.6.Final.jar -> jackson-mapper-asl-1.9.12.jar
resteasy-jackson-provider-3.0.6.Final.jar -> jackson-jaxrs-1.9.12.jar
resteasy-jackson-provider-3.0.6.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
resteasy-jackson-provider-3.0.6.Final.jar -> resteasy-jaxrs-3.0.6.Final.jar
resteasy-jackson-provider-3.0.6.Final.jar -> jaxrs-api-3.0.6.Final.jar
resteasy-jaxb-provider-3.0.6.Final.jar -> jaxb-impl-2.2.5.jboss-1.jar
resteasy-jaxb-provider-3.0.6.Final.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
resteasy-jaxb-provider-3.0.6.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
resteasy-jaxb-provider-3.0.6.Final.jar -> resteasy-jaxrs-3.0.6.Final.jar
resteasy-jaxb-provider-3.0.6.Final.jar -> jaxrs-api-3.0.6.Final.jar
resteasy-jaxrs-3.0.6.Final.jar -> not found
resteasy-jaxrs-3.0.6.Final.jar -> log4j-jboss-logmanager-1.0.2.Final.jar
resteasy-jaxrs-3.0.6.Final.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
resteasy-jaxrs-3.0.6.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
resteasy-jaxrs-3.0.6.Final.jar -> activation-1.1.1.jar
resteasy-jaxrs-3.0.6.Final.jar -> jaxrs-api-3.0.6.Final.jar
resteasy-jaxrs-3.0.6.Final.jar -> scannotation-1.0.3.jar
resteasy-jaxrs-3.0.6.Final.jar -> jboss-annotations-api_1.2_spec-1.0.0.Final.jar
resteasy-jaxrs-3.0.6.Final.jar -> httpclient-4.2.1.jar
resteasy-jaxrs-3.0.6.Final.jar -> commons-io-2.1.jar
resteasy-jaxrs-3.0.6.Final.jar -> httpcore-4.2.1.jar
resteasy-jaxrs-3.0.6.Final.jar -> slf4j-api-1.7.2.jbossorg-1.jar
resteasy-jaxrs-3.0.6.Final.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
resteasy-jaxrs-3.0.6.Final.jar -> commons-codec-1.4.jar
resteasy-jettison-provider-3.0.6.Final.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
resteasy-jettison-provider-3.0.6.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
resteasy-jettison-provider-3.0.6.Final.jar -> resteasy-jaxb-provider-3.0.6.Final.jar
resteasy-jettison-provider-3.0.6.Final.jar -> resteasy-jaxrs-3.0.6.Final.jar
resteasy-jettison-provider-3.0.6.Final.jar -> jettison-1.3.1.jar
resteasy-jettison-provider-3.0.6.Final.jar -> jaxrs-api-3.0.6.Final.jar
resteasy-jsapi-3.0.6.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
resteasy-jsapi-3.0.6.Final.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
resteasy-jsapi-3.0.6.Final.jar -> resteasy-jaxrs-3.0.6.Final.jar
resteasy-jsapi-3.0.6.Final.jar -> jaxrs-api-3.0.6.Final.jar
resteasy-json-p-provider-3.0.6.Final.jar -> javax.json-1.0.3.jar
resteasy-json-p-provider-3.0.6.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
resteasy-json-p-provider-3.0.6.Final.jar -> jaxrs-api-3.0.6.Final.jar
resteasy-multipart-provider-3.0.6.Final.jar -> javax.mail-1.5.0.jar
resteasy-multipart-provider-3.0.6.Final.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
resteasy-multipart-provider-3.0.6.Final.jar -> apache-mime4j-0.6.jar
resteasy-multipart-provider-3.0.6.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
resteasy-multipart-provider-3.0.6.Final.jar -> resteasy-jaxb-provider-3.0.6.Final.jar
resteasy-multipart-provider-3.0.6.Final.jar -> activation-1.1.1.jar
resteasy-multipart-provider-3.0.6.Final.jar -> resteasy-jaxrs-3.0.6.Final.jar
resteasy-multipart-provider-3.0.6.Final.jar -> jaxrs-api-3.0.6.Final.jar
resteasy-validator-provider-11-3.0.6.Final.jar -> classmate-1.0.0.jar
resteasy-validator-provider-11-3.0.6.Final.jar -> jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
resteasy-validator-provider-11-3.0.6.Final.jar -> hibernate-validator-5.0.2.Final.jar
resteasy-validator-provider-11-3.0.6.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
resteasy-validator-provider-11-3.0.6.Final.jar -> resteasy-jaxrs-3.0.6.Final.jar
resteasy-validator-provider-11-3.0.6.Final.jar -> validation-api-1.1.0.Final.jar
resteasy-validator-provider-11-3.0.6.Final.jar -> jaxrs-api-3.0.6.Final.jar
resteasy-yaml-provider-3.0.6.Final.jar -> snakeyaml-1.8.jar
resteasy-yaml-provider-3.0.6.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
resteasy-yaml-provider-3.0.6.Final.jar -> resteasy-jaxrs-3.0.6.Final.jar
resteasy-yaml-provider-3.0.6.Final.jar -> jaxrs-api-3.0.6.Final.jar
rngom-201103.jboss-1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
rngom-201103.jboss-1.jar -> relaxngDatatype-2011.1.jar
saaj-impl-1.3.16-jbossorg-1.jar -> jboss-saaj-api_1.3_spec-1.0.3.Final.jar
saaj-impl-1.3.16-jbossorg-1.jar -> not found
saaj-impl-1.3.16-jbossorg-1.jar -> xercesImpl-2.9.1-jbossas-2.jar
saaj-impl-1.3.16-jbossorg-1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
saaj-impl-1.3.16-jbossorg-1.jar -> activation-1.1.1.jar
saaj-impl-1.3.16-jbossorg-1.jar -> jaxen-1.1.3.jar
scannotation-1.0.3.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
scannotation-1.0.3.jar -> javassist-3.18.1-GA.jar
scannotation-1.0.3.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
serializer-2.7.1.jbossorg-1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
shrinkwrap-api-1.1.2.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
shrinkwrap-impl-base-1.1.2.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
shrinkwrap-impl-base-1.1.2.jar -> shrinkwrap-api-1.1.2.jar
shrinkwrap-impl-base-1.1.2.jar -> activation-1.1.1.jar
shrinkwrap-impl-base-1.1.2.jar -> shrinkwrap-spi-1.1.2.jar
shrinkwrap-spi-1.1.2.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
shrinkwrap-spi-1.1.2.jar -> shrinkwrap-api-1.1.2.jar
slf4j-api-1.7.2.jbossorg-1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
slf4j-api-1.7.2.jbossorg-1.jar -> slf4j-jboss-logmanager-1.0.3.GA.jar
slf4j-ext-1.7.2.jbossorg-1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
slf4j-ext-1.7.2.jbossorg-1.jar -> slf4j-api-1.7.2.jbossorg-1.jar
slf4j-ext-1.7.2.jbossorg-1.jar -> javassist-3.18.1-GA.jar
slf4j-ext-1.7.2.jbossorg-1.jar -> cal10n-api-0.8.1.jar
slf4j-ext-1.7.2.jbossorg-1.jar -> commons-lang-2.6.jar
slf4j-jboss-logmanager-1.0.3.GA.jar -> jboss-logmanager-1.5.0.Final.jar
slf4j-jboss-logmanager-1.0.3.GA.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
slf4j-jboss-logmanager-1.0.3.GA.jar -> slf4j-api-1.7.2.jbossorg-1.jar
snakeyaml-1.8.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
stax2-api-3.1.1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
staxmapper-1.1.0.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
txframework-5.0.0.CR2.jar -> jboss-interceptors-api_1.2_spec-1.0.0.Final.jar
txframework-5.0.0.CR2.jar -> javax.inject-1.jar
txframework-5.0.0.CR2.jar -> cdi-api-1.1.jar
txframework-5.0.0.CR2.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
txframework-5.0.0.CR2.jar -> jbossxts-5.0.0.CR2.jar
txframework-5.0.0.CR2.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
txframework-5.0.0.CR2.jar -> resteasy-jaxrs-3.0.6.Final.jar
txframework-5.0.0.CR2.jar -> jaxrs-api-3.0.6.Final.jar
txw2-20110809.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
undertow-core-1.0.0.Beta28.jar -> not found
undertow-core-1.0.0.Beta28.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
undertow-core-1.0.0.Beta28.jar -> jboss-cli-client.jar
   io.undertow.server.handlers.cache.FastConcurrentDirectDeque (undertow-core-1.0.0.Beta28.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   io.undertow.server.handlers.cache.FastConcurrentDirectDeque$1 (undertow-core-1.0.0.Beta28.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   io.undertow.server.handlers.cache.FastConcurrentDirectDeque$Node (undertow-core-1.0.0.Beta28.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
undertow-servlet-1.0.0.Beta28.jar -> undertow-core-1.0.0.Beta28.jar
undertow-servlet-1.0.0.Beta28.jar -> jboss-annotations-api_1.2_spec-1.0.0.Final.jar
undertow-servlet-1.0.0.Beta28.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
undertow-servlet-1.0.0.Beta28.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
undertow-servlet-1.0.0.Beta28.jar -> jboss-cli-client.jar
   io.undertow.servlet.spec.ServletPrintWriterDelegate$1 (undertow-servlet-1.0.0.Beta28.jar)
      -> sun.reflect.ReflectionFactory                      JDK internal API (rt.jar)
undertow-websockets-jsr-1.0.0.Beta28.jar -> undertow-servlet-1.0.0.Beta28.jar
undertow-websockets-jsr-1.0.0.Beta28.jar -> undertow-core-1.0.0.Beta28.jar
undertow-websockets-jsr-1.0.0.Beta28.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
undertow-websockets-jsr-1.0.0.Beta28.jar -> jboss-websocket-api_1.0_spec-1.0.0.Final.jar
undertow-websockets-jsr-1.0.0.Beta28.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
undertow-websockets-jsr-1.0.0.Beta28.jar -> jboss-cli-client.jar
validation-api-1.1.0.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
velocity-1.7.jar -> not found
velocity-1.7.jar -> log4j-jboss-logmanager-1.0.2.Final.jar
velocity-1.7.jar -> commons-collections-3.2.1.jar
velocity-1.7.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
velocity-1.7.jar -> jcl-over-slf4j-1.7.2.jbossorg-1.jar
velocity-1.7.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
velocity-1.7.jar -> jdom-1.1.2.jar
velocity-1.7.jar -> commons-lang-2.6.jar
weld-api-2.1.Final.jar -> jboss-interceptors-api_1.2_spec-1.0.0.Final.jar
weld-api-2.1.Final.jar -> javax.inject-1.jar
weld-api-2.1.Final.jar -> cdi-api-1.1.jar
weld-api-2.1.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
weld-api-2.1.Final.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
weld-core-impl-2.1.1.Final.jar -> weld-api-2.1.Final.jar
weld-core-impl-2.1.1.Final.jar -> not found
weld-core-impl-2.1.1.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
weld-core-impl-2.1.1.Final.jar -> guava-15.0.jar
weld-core-impl-2.1.1.Final.jar -> javax.el-3.0-b07.jar
weld-core-impl-2.1.1.Final.jar -> jboss-interceptors-api_1.2_spec-1.0.0.Final.jar
weld-core-impl-2.1.1.Final.jar -> weld-spi-2.1.Final.jar
weld-core-impl-2.1.1.Final.jar -> javax.inject-1.jar
weld-core-impl-2.1.1.Final.jar -> jboss-classfilewriter-1.0.4.Final.jar
weld-core-impl-2.1.1.Final.jar -> cdi-api-1.1.jar
weld-core-impl-2.1.1.Final.jar -> jboss-annotations-api_1.2_spec-1.0.0.Final.jar
weld-core-impl-2.1.1.Final.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
weld-core-impl-2.1.1.Final.jar -> jboss-cli-client.jar
weld-core-impl-2.1.1.Final.jar -> jboss-client.jar
weld-core-jsf-2.1.1.Final.jar -> jboss-jsf-api_2.2_spec-2.2.4.jar
weld-core-jsf-2.1.1.Final.jar -> weld-core-impl-2.1.1.Final.jar
weld-core-jsf-2.1.1.Final.jar -> weld-api-2.1.Final.jar
weld-core-jsf-2.1.1.Final.jar -> weld-spi-2.1.Final.jar
weld-core-jsf-2.1.1.Final.jar -> cdi-api-1.1.jar
weld-core-jsf-2.1.1.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
weld-core-jsf-2.1.1.Final.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
weld-spi-2.1.Final.jar -> cdi-api-1.1.jar
weld-spi-2.1.Final.jar -> jboss-annotations-api_1.2_spec-1.0.0.Final.jar
weld-spi-2.1.Final.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
weld-spi-2.1.Final.jar -> hibernate-jpa-2.1-api-1.0.0.Final.jar
weld-spi-2.1.Final.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
weld-spi-2.1.Final.jar -> jboss-client.jar
weld-spi-2.1.Final.jar -> validation-api-1.1.0.Final.jar
wildfly-appclient-8.0.0.Beta2-SNAPSHOT.jar -> picketbox-4.0.20.Beta2.jar
wildfly-appclient-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-process-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-appclient-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
wildfly-appclient-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-appclient-8.0.0.Beta2-SNAPSHOT.jar -> jboss-metadata-appclient-8.0.0.Beta5.jar
wildfly-appclient-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-server-8.0.0.Beta2-SNAPSHOT.jar
wildfly-appclient-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-naming-8.0.0.Beta2-SNAPSHOT.jar
wildfly-appclient-8.0.0.Beta2-SNAPSHOT.jar -> jboss-logmanager-1.5.0.Final.jar
wildfly-appclient-8.0.0.Beta2-SNAPSHOT.jar -> jboss-invocation-1.2.0.Beta4.jar
wildfly-appclient-8.0.0.Beta2-SNAPSHOT.jar -> jboss-stdio-1.0.2.GA.jar
wildfly-appclient-8.0.0.Beta2-SNAPSHOT.jar -> jboss-modules.jar
wildfly-appclient-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar
wildfly-appclient-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-appclient-8.0.0.Beta2-SNAPSHOT.jar -> jboss-client.jar
wildfly-appclient-8.0.0.Beta2-SNAPSHOT.jar -> jboss-as-version-8.0.0.Beta2-SNAPSHOT.jar
wildfly-appclient-8.0.0.Beta2-SNAPSHOT.jar -> jboss-metadata-common-8.0.0.Beta5.jar
wildfly-appclient-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-batch-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-jberet-8.0.0.Beta2-SNAPSHOT.jar
wildfly-batch-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-transactions-8.0.0.Beta2-SNAPSHOT.jar
wildfly-batch-8.0.0.Beta2-SNAPSHOT.jar -> jboss-modules.jar
wildfly-batch-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar
wildfly-batch-8.0.0.Beta2-SNAPSHOT.jar -> cdi-api-1.1.jar
wildfly-batch-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
wildfly-batch-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-batch-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-server-8.0.0.Beta2-SNAPSHOT.jar
wildfly-batch-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-batch-8.0.0.Beta2-SNAPSHOT.jar -> jboss-client.jar
wildfly-batch-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-threads-8.0.0.Beta2-SNAPSHOT.jar
wildfly-batch-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-cli-8.0.0.Beta2-SNAPSHOT.jar -> not found
wildfly-cli-8.0.0.Beta2-SNAPSHOT.jar -> aesh-0.33.11.jar
wildfly-cli-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
wildfly-cli-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-clustering-api-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
wildfly-clustering-common-8.0.0.Beta2-SNAPSHOT.jar -> jboss-modules.jar
wildfly-clustering-common-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
wildfly-clustering-common-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-clustering-common-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-server-8.0.0.Beta2-SNAPSHOT.jar
wildfly-clustering-common-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-clustering-common-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-naming-8.0.0.Beta2-SNAPSHOT.jar
wildfly-clustering-common-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-clustering-ejb-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-clustering-infinispan-8.0.0.Beta2-SNAPSHOT.jar
wildfly-clustering-ejb-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-clustering-ejb-spi-8.0.0.Beta2-SNAPSHOT.jar
wildfly-clustering-ejb-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-clustering-api-8.0.0.Beta2-SNAPSHOT.jar
wildfly-clustering-ejb-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
wildfly-clustering-ejb-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-clustering-ejb-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-clustering-common-8.0.0.Beta2-SNAPSHOT.jar
wildfly-clustering-ejb-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-network-8.0.0.Beta2-SNAPSHOT.jar
wildfly-clustering-ejb-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-server-8.0.0.Beta2-SNAPSHOT.jar
wildfly-clustering-ejb-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-clustering-ejb-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> jboss-client.jar
wildfly-clustering-ejb-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> jboss-transaction-spi-7.1.0.Final.jar
wildfly-clustering-ejb-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> infinispan-core-6.0.1.Final.jar
wildfly-clustering-ejb-spi-8.0.0.Beta2-SNAPSHOT.jar -> jboss-modules.jar
wildfly-clustering-ejb-spi-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
wildfly-clustering-ejb-spi-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-clustering-ejb-spi-8.0.0.Beta2-SNAPSHOT.jar -> jboss-client.jar
wildfly-clustering-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> infinispan-cachestore-remote-6.0.1.Final.jar
wildfly-clustering-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
wildfly-clustering-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-clustering-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> infinispan-commons-6.0.1.Final.jar
wildfly-clustering-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-server-8.0.0.Beta2-SNAPSHOT.jar
wildfly-clustering-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-naming-8.0.0.Beta2-SNAPSHOT.jar
wildfly-clustering-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-clustering-jgroups-8.0.0.Beta2-SNAPSHOT.jar
wildfly-clustering-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> jboss-transaction-spi-7.1.0.Final.jar
wildfly-clustering-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-jmx-8.0.0.Beta2-SNAPSHOT.jar
wildfly-clustering-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> infinispan-cachestore-jdbc-6.0.1.Final.jar
wildfly-clustering-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-transactions-8.0.0.Beta2-SNAPSHOT.jar
wildfly-clustering-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> jboss-modules.jar
wildfly-clustering-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-clustering-common-8.0.0.Beta2-SNAPSHOT.jar
wildfly-clustering-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-network-8.0.0.Beta2-SNAPSHOT.jar
wildfly-clustering-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-clustering-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> jboss-client.jar
wildfly-clustering-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> infinispan-core-6.0.1.Final.jar
wildfly-clustering-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-clustering-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-threads-8.0.0.Beta2-SNAPSHOT.jar
wildfly-clustering-jgroups-8.0.0.Beta2-SNAPSHOT.jar -> jboss-modules.jar
wildfly-clustering-jgroups-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
wildfly-clustering-jgroups-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-clustering-common-8.0.0.Beta2-SNAPSHOT.jar
wildfly-clustering-jgroups-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-network-8.0.0.Beta2-SNAPSHOT.jar
wildfly-clustering-jgroups-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-clustering-jgroups-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-server-8.0.0.Beta2-SNAPSHOT.jar
wildfly-clustering-jgroups-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-clustering-jgroups-8.0.0.Beta2-SNAPSHOT.jar -> jboss-client.jar
wildfly-clustering-jgroups-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-jmx-8.0.0.Beta2-SNAPSHOT.jar
wildfly-clustering-jgroups-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-clustering-jgroups-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-threads-8.0.0.Beta2-SNAPSHOT.jar
wildfly-clustering-server-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-clustering-api-8.0.0.Beta2-SNAPSHOT.jar
wildfly-clustering-server-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
wildfly-clustering-server-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-clustering-server-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-server-8.0.0.Beta2-SNAPSHOT.jar
wildfly-clustering-server-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-clustering-jgroups-8.0.0.Beta2-SNAPSHOT.jar
wildfly-clustering-server-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-naming-8.0.0.Beta2-SNAPSHOT.jar
wildfly-clustering-server-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-clustering-infinispan-8.0.0.Beta2-SNAPSHOT.jar
wildfly-clustering-server-8.0.0.Beta2-SNAPSHOT.jar -> jboss-modules.jar
wildfly-clustering-server-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-clustering-common-8.0.0.Beta2-SNAPSHOT.jar
wildfly-clustering-server-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-clustering-singleton-8.0.0.Beta2-SNAPSHOT.jar
wildfly-clustering-server-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-clustering-server-8.0.0.Beta2-SNAPSHOT.jar -> jboss-client.jar
wildfly-clustering-server-8.0.0.Beta2-SNAPSHOT.jar -> infinispan-core-6.0.1.Final.jar
wildfly-clustering-singleton-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-clustering-api-8.0.0.Beta2-SNAPSHOT.jar
wildfly-clustering-singleton-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
wildfly-clustering-singleton-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-clustering-web-api-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
wildfly-clustering-web-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-clustering-api-8.0.0.Beta2-SNAPSHOT.jar
wildfly-clustering-web-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
wildfly-clustering-web-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-clustering-web-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> infinispan-commons-6.0.1.Final.jar
wildfly-clustering-web-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-clustering-web-spi-8.0.0.Beta2-SNAPSHOT.jar
wildfly-clustering-web-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> jboss-transaction-spi-7.1.0.Final.jar
wildfly-clustering-web-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-clustering-infinispan-8.0.0.Beta2-SNAPSHOT.jar
wildfly-clustering-web-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-clustering-web-api-8.0.0.Beta2-SNAPSHOT.jar
wildfly-clustering-web-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> jboss-modules.jar
wildfly-clustering-web-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-clustering-common-8.0.0.Beta2-SNAPSHOT.jar
wildfly-clustering-web-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
wildfly-clustering-web-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-clustering-web-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> jboss-metadata-web-8.0.0.Beta5.jar
wildfly-clustering-web-infinispan-8.0.0.Beta2-SNAPSHOT.jar -> infinispan-core-6.0.1.Final.jar
wildfly-clustering-web-spi-8.0.0.Beta2-SNAPSHOT.jar -> jboss-modules.jar
wildfly-clustering-web-spi-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
wildfly-clustering-web-spi-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-clustering-web-spi-8.0.0.Beta2-SNAPSHOT.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
wildfly-clustering-web-spi-8.0.0.Beta2-SNAPSHOT.jar -> jboss-metadata-web-8.0.0.Beta5.jar
wildfly-clustering-web-undertow-8.0.0.Beta2-SNAPSHOT.jar -> undertow-core-1.0.0.Beta28.jar
wildfly-clustering-web-undertow-8.0.0.Beta2-SNAPSHOT.jar -> undertow-servlet-1.0.0.Beta28.jar
wildfly-clustering-web-undertow-8.0.0.Beta2-SNAPSHOT.jar -> jboss-modules.jar
wildfly-clustering-web-undertow-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
wildfly-clustering-web-undertow-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-clustering-web-undertow-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-undertow-8.0.0.Beta2-SNAPSHOT.jar
wildfly-clustering-web-undertow-8.0.0.Beta2-SNAPSHOT.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
wildfly-clustering-web-undertow-8.0.0.Beta2-SNAPSHOT.jar -> jboss-metadata-web-8.0.0.Beta5.jar
wildfly-clustering-web-undertow-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-clustering-web-spi-8.0.0.Beta2-SNAPSHOT.jar
wildfly-cmp-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
wildfly-cmp-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-cmp-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-configadmin-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
wildfly-configadmin-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-configadmin-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-server-8.0.0.Beta2-SNAPSHOT.jar
wildfly-configadmin-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-configadmin-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-connector-8.0.0.Beta2-SNAPSHOT.jar -> picketbox-4.0.20.Beta2.jar
wildfly-connector-8.0.0.Beta2-SNAPSHOT.jar -> jboss-connector-api_1.7_spec-1.0.0.Final.jar
wildfly-connector-8.0.0.Beta2-SNAPSHOT.jar -> ironjacamar-core-impl-1.1.2.Final.jar
wildfly-connector-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
wildfly-connector-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-connector-8.0.0.Beta2-SNAPSHOT.jar -> jboss-invocation-1.2.0.Beta4.jar
wildfly-connector-8.0.0.Beta2-SNAPSHOT.jar -> ironjacamar-core-api-1.1.2.Final.jar
wildfly-connector-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-transactions-8.0.0.Beta2-SNAPSHOT.jar
wildfly-connector-8.0.0.Beta2-SNAPSHOT.jar -> jboss-annotations-api_1.2_spec-1.0.0.Final.jar
wildfly-connector-8.0.0.Beta2-SNAPSHOT.jar -> ironjacamar-common-api-1.1.2.Final.jar
wildfly-connector-8.0.0.Beta2-SNAPSHOT.jar -> ironjacamar-deployers-common-1.1.2.Final.jar
wildfly-connector-8.0.0.Beta2-SNAPSHOT.jar -> jboss-client.jar
wildfly-connector-8.0.0.Beta2-SNAPSHOT.jar -> validation-api-1.1.0.Final.jar
wildfly-connector-8.0.0.Beta2-SNAPSHOT.jar -> ironjacamar-common-spi-1.1.2.Final.jar
wildfly-connector-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-security-8.0.0.Beta2-SNAPSHOT.jar
wildfly-connector-8.0.0.Beta2-SNAPSHOT.jar -> narayana-jts-integration-5.0.0.CR2.jar
wildfly-connector-8.0.0.Beta2-SNAPSHOT.jar -> ironjacamar-common-impl-1.1.2.Final.jar
wildfly-connector-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-server-8.0.0.Beta2-SNAPSHOT.jar
wildfly-connector-8.0.0.Beta2-SNAPSHOT.jar -> ironjacamar-jdbc-1.1.2.Final.jar
wildfly-connector-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-naming-8.0.0.Beta2-SNAPSHOT.jar
wildfly-connector-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-clustering-jgroups-8.0.0.Beta2-SNAPSHOT.jar
wildfly-connector-8.0.0.Beta2-SNAPSHOT.jar -> jboss-transaction-spi-7.1.0.Final.jar
wildfly-connector-8.0.0.Beta2-SNAPSHOT.jar -> jboss-modules.jar
wildfly-connector-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar
wildfly-connector-8.0.0.Beta2-SNAPSHOT.jar -> hibernate-validator-5.0.2.Final.jar
wildfly-connector-8.0.0.Beta2-SNAPSHOT.jar -> jandex-1.1.0.Final.jar
wildfly-connector-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-connector-8.0.0.Beta2-SNAPSHOT.jar -> jboss-metadata-common-8.0.0.Beta5.jar
wildfly-connector-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-connector-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-threads-8.0.0.Beta2-SNAPSHOT.jar
wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar -> jboss-logmanager-1.5.0.Final.jar
wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-core-security-8.0.0.Beta2-SNAPSHOT.jar
wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar -> jboss-modules.jar
wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-controller-client-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
wildfly-controller-client-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-core-security-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
wildfly-core-security-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-deployment-repository-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
wildfly-deployment-repository-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-deployment-repository-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-deployment-scanner-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
wildfly-deployment-scanner-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-deployment-scanner-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-server-8.0.0.Beta2-SNAPSHOT.jar
wildfly-deployment-scanner-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-deployment-scanner-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-domain-http-interface-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-domain-management-8.0.0.Beta2-SNAPSHOT.jar
wildfly-domain-http-interface-8.0.0.Beta2-SNAPSHOT.jar -> undertow-core-1.0.0.Beta28.jar
wildfly-domain-http-interface-8.0.0.Beta2-SNAPSHOT.jar -> jboss-modules.jar
wildfly-domain-http-interface-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-core-security-8.0.0.Beta2-SNAPSHOT.jar
wildfly-domain-http-interface-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
wildfly-domain-http-interface-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-domain-http-interface-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-domain-management-8.0.0.Beta2-SNAPSHOT.jar -> jboss-logmanager-1.5.0.Final.jar
wildfly-domain-management-8.0.0.Beta2-SNAPSHOT.jar -> jboss-common-core-2.2.22.GA.jar
wildfly-domain-management-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-core-security-8.0.0.Beta2-SNAPSHOT.jar
wildfly-domain-management-8.0.0.Beta2-SNAPSHOT.jar -> jboss-modules.jar
wildfly-domain-management-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
wildfly-domain-management-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-domain-management-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-domain-management-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar -> picketbox-4.0.20.Beta2.jar
wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar -> jboss-metadata-ear-8.0.0.Beta5.jar
wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-server-8.0.0.Beta2-SNAPSHOT.jar
wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-naming-8.0.0.Beta2-SNAPSHOT.jar
wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar -> jboss-interceptors-api_1.2_spec-1.0.0.Final.jar
wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar -> jboss-concurrency-api_1.0_spec-1.0.0.Final.jar
wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar -> jboss-invocation-1.2.0.Beta4.jar
wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar -> jboss-modules.jar
wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar -> hibernate-validator-5.0.2.Final.jar
wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar -> jboss-annotations-api_1.2_spec-1.0.0.Final.jar
wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar -> javax.enterprise.concurrent-1.0.jar
wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar -> jandex-1.1.0.Final.jar
wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar -> jboss-client.jar
wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar -> validation-api-1.1.0.Final.jar
wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar -> jboss-metadata-common-8.0.0.Beta5.jar
wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> jboss-connector-api_1.7_spec-1.0.0.Final.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> picketbox-4.0.20.Beta2.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-clustering-api-8.0.0.Beta2-SNAPSHOT.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-domain-management-8.0.0.Beta2-SNAPSHOT.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> jboss-jaxrpc-api_1.1_spec-1.0.1.Final.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> jboss-invocation-1.2.0.Beta4.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> ironjacamar-core-api-1.1.2.Final.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-transactions-8.0.0.Beta2-SNAPSHOT.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> jboss-annotations-api_1.2_spec-1.0.0.Final.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-remoting-8.0.0.Beta2-SNAPSHOT.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> jboss-client.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-security-8.0.0.Beta2-SNAPSHOT.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> jboss-metadata-ear-8.0.0.Beta5.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-clustering-ejb-spi-8.0.0.Beta2-SNAPSHOT.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> narayana-jts-integration-5.0.0.CR2.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-core-security-8.0.0.Beta2-SNAPSHOT.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> jboss-jacc-api_1.5_spec-1.0.0.Beta1.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> narayana-jts-jacorb-5.0.0.CR2.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-server-8.0.0.Beta2-SNAPSHOT.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-connector-8.0.0.Beta2-SNAPSHOT.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> hibernate-jpa-2.1-api-1.0.0.Final.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> jboss-ejb3-ext-api-2.1.0.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-naming-8.0.0.Beta2-SNAPSHOT.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> jboss-metadata-ejb-8.0.0.Beta5.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> jboss-transaction-spi-7.1.0.Final.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> jboss-interceptors-api_1.2_spec-1.0.0.Final.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-jacorb-8.0.0.Beta2-SNAPSHOT.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> jboss-concurrency-api_1.0_spec-1.0.0.Final.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> jacorb-2.3.2-jbossorg-5.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> jboss-common-core-2.2.22.GA.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> jboss-modules.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> jboss-classfilewriter-1.0.4.Final.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> jboss-rmi-api_1.0_spec-1.0.4.Final.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-clustering-common-8.0.0.Beta2-SNAPSHOT.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-network-8.0.0.Beta2-SNAPSHOT.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> jandex-1.1.0.Final.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> jboss-iiop-client-1.0.0.Final.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> jboss-metadata-common-8.0.0.Beta5.jar
wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-threads-8.0.0.Beta2-SNAPSHOT.jar
wildfly-embedded-8.0.0.Beta2-SNAPSHOT.jar -> jboss-modules.jar
wildfly-embedded-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
wildfly-embedded-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-embedded-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-server-8.0.0.Beta2-SNAPSHOT.jar
wildfly-embedded-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-embedded-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-host-controller-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/jce.jar (compact1)
wildfly-host-controller-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-process-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-host-controller-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
wildfly-host-controller-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-deployment-repository-8.0.0.Beta2-SNAPSHOT.jar
wildfly-host-controller-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-host-controller-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-management-client-content-8.0.0.Beta2-SNAPSHOT.jar
wildfly-host-controller-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-server-8.0.0.Beta2-SNAPSHOT.jar
wildfly-host-controller-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-domain-http-interface-8.0.0.Beta2-SNAPSHOT.jar
wildfly-host-controller-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-domain-management-8.0.0.Beta2-SNAPSHOT.jar
wildfly-host-controller-8.0.0.Beta2-SNAPSHOT.jar -> jboss-logmanager-1.5.0.Final.jar
wildfly-host-controller-8.0.0.Beta2-SNAPSHOT.jar -> undertow-core-1.0.0.Beta28.jar
wildfly-host-controller-8.0.0.Beta2-SNAPSHOT.jar -> jboss-stdio-1.0.2.GA.jar
wildfly-host-controller-8.0.0.Beta2-SNAPSHOT.jar -> jboss-common-core-2.2.22.GA.jar
wildfly-host-controller-8.0.0.Beta2-SNAPSHOT.jar -> jboss-modules.jar
wildfly-host-controller-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-network-8.0.0.Beta2-SNAPSHOT.jar
wildfly-host-controller-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-remoting-8.0.0.Beta2-SNAPSHOT.jar
wildfly-host-controller-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-platform-mbean-8.0.0.Beta2-SNAPSHOT.jar
wildfly-host-controller-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-host-controller-8.0.0.Beta2-SNAPSHOT.jar -> jboss-as-version-8.0.0.Beta2-SNAPSHOT.jar
wildfly-host-controller-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-io-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
wildfly-io-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-io-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-io-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jacorb-8.0.0.Beta2-SNAPSHOT.jar -> picketbox-4.0.20.Beta2.jar
wildfly-jacorb-8.0.0.Beta2-SNAPSHOT.jar -> narayana-jts-jacorb-5.0.0.CR2.jar
wildfly-jacorb-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
wildfly-jacorb-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-jacorb-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-server-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jacorb-8.0.0.Beta2-SNAPSHOT.jar -> jboss-metadata-ejb-8.0.0.Beta5.jar
wildfly-jacorb-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-naming-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jacorb-8.0.0.Beta2-SNAPSHOT.jar -> jacorb-2.3.2-jbossorg-5.jar
wildfly-jacorb-8.0.0.Beta2-SNAPSHOT.jar -> jboss-modules.jar
wildfly-jacorb-8.0.0.Beta2-SNAPSHOT.jar -> jboss-rmi-api_1.0_spec-1.0.4.Final.jar
wildfly-jacorb-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-network-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jacorb-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-jacorb-8.0.0.Beta2-SNAPSHOT.jar -> jboss-client.jar
wildfly-jacorb-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jaxr-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
wildfly-jaxr-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-jaxr-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jaxrs-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jaxrs-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
wildfly-jaxrs-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-jaxrs-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-server-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jaxrs-8.0.0.Beta2-SNAPSHOT.jar -> jaxrs-api-3.0.6.Final.jar
wildfly-jaxrs-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jaxrs-8.0.0.Beta2-SNAPSHOT.jar -> async-http-servlet-3.0-3.0.6.Final.jar
wildfly-jaxrs-8.0.0.Beta2-SNAPSHOT.jar -> jboss-modules.jar
wildfly-jaxrs-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jaxrs-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-web-common-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jaxrs-8.0.0.Beta2-SNAPSHOT.jar -> jandex-1.1.0.Final.jar
wildfly-jaxrs-8.0.0.Beta2-SNAPSHOT.jar -> resteasy-jaxrs-3.0.6.Final.jar
wildfly-jaxrs-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-jaxrs-8.0.0.Beta2-SNAPSHOT.jar -> jboss-metadata-web-8.0.0.Beta5.jar
wildfly-jaxrs-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jaxrs-8.0.0.Beta2-SNAPSHOT.jar -> jboss-metadata-common-8.0.0.Beta5.jar
wildfly-jberet-8.0.0.Beta2-SNAPSHOT.jar -> picketbox-4.0.20.Beta2.jar
wildfly-jberet-8.0.0.Beta2-SNAPSHOT.jar -> cdi-api-1.1.jar
wildfly-jberet-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
wildfly-jberet-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-jberet-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-jberet-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-naming-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jberet-8.0.0.Beta2-SNAPSHOT.jar -> jboss-client.jar
wildfly-jberet-8.0.0.Beta2-SNAPSHOT.jar -> jberet-core-1.0.0.CR1.jar
wildfly-jdr-8.0.0.Beta2-SNAPSHOT.jar -> commons-cli-1.2.jar
wildfly-jdr-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
wildfly-jdr-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-jdr-8.0.0.Beta2-SNAPSHOT.jar -> commons-io-2.1.jar
wildfly-jdr-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-server-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jdr-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-jdr-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jmx-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-domain-management-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jmx-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-core-security-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jmx-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
wildfly-jmx-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-jmx-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-remoting-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jmx-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-server-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jmx-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-jmx-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-naming-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jmx-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jpa-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
wildfly-jpa-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-jpa-8.0.0.Beta2-SNAPSHOT.jar -> weld-core-impl-2.1.1.Final.jar
wildfly-jpa-8.0.0.Beta2-SNAPSHOT.jar -> jboss-invocation-1.2.0.Beta4.jar
wildfly-jpa-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-transactions-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jpa-8.0.0.Beta2-SNAPSHOT.jar -> cdi-api-1.1.jar
wildfly-jpa-8.0.0.Beta2-SNAPSHOT.jar -> jboss-client.jar
wildfly-jpa-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-jpa-util-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jpa-8.0.0.Beta2-SNAPSHOT.jar -> validation-api-1.1.0.Final.jar
wildfly-jpa-8.0.0.Beta2-SNAPSHOT.jar -> infinispan-core-6.0.1.Final.jar
wildfly-jpa-8.0.0.Beta2-SNAPSHOT.jar -> hibernate-jpa-2.1-api-1.0.0.Final.jar
wildfly-jpa-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-server-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jpa-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-connector-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jpa-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-naming-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jpa-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-clustering-jgroups-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jpa-8.0.0.Beta2-SNAPSHOT.jar -> jboss-transaction-spi-7.1.0.Final.jar
wildfly-jpa-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-clustering-infinispan-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jpa-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jpa-8.0.0.Beta2-SNAPSHOT.jar -> jipijapa-spi-1.0.0.Final.jar
wildfly-jpa-8.0.0.Beta2-SNAPSHOT.jar -> jboss-modules.jar
wildfly-jpa-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jpa-8.0.0.Beta2-SNAPSHOT.jar -> hibernate-validator-5.0.2.Final.jar
wildfly-jpa-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-clustering-common-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jpa-8.0.0.Beta2-SNAPSHOT.jar -> jandex-1.1.0.Final.jar
wildfly-jpa-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-jpa-8.0.0.Beta2-SNAPSHOT.jar -> jboss-metadata-common-8.0.0.Beta5.jar
wildfly-jpa-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jpa-util-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
wildfly-jpa-util-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-jsf-8.0.0.Beta2-SNAPSHOT.jar -> jboss-jsf-api_2.2_spec-2.2.4.jar
wildfly-jsf-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
wildfly-jsf-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-jsf-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-server-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jsf-8.0.0.Beta2-SNAPSHOT.jar -> jboss-modules.jar
wildfly-jsf-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jsf-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-web-common-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jsf-8.0.0.Beta2-SNAPSHOT.jar -> jandex-1.1.0.Final.jar
wildfly-jsf-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-jsf-8.0.0.Beta2-SNAPSHOT.jar -> jboss-metadata-web-8.0.0.Beta5.jar
wildfly-jsf-8.0.0.Beta2-SNAPSHOT.jar -> validation-api-1.1.0.Final.jar
wildfly-jsf-8.0.0.Beta2-SNAPSHOT.jar -> jboss-metadata-common-8.0.0.Beta5.jar
wildfly-jsf-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jsf-injection-8.0.0.Beta2-SNAPSHOT.jar -> jboss-jsf-api_2.2_spec-2.2.4.jar
wildfly-jsf-injection-8.0.0.Beta2-SNAPSHOT.jar -> not found
wildfly-jsf-injection-8.0.0.Beta2-SNAPSHOT.jar -> weld-core-impl-2.1.1.Final.jar
wildfly-jsf-injection-8.0.0.Beta2-SNAPSHOT.jar -> weld-core-jsf-2.1.1.Final.jar
wildfly-jsf-injection-8.0.0.Beta2-SNAPSHOT.jar -> cdi-api-1.1.jar
wildfly-jsf-injection-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
wildfly-jsf-injection-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-web-common-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jsf-injection-8.0.0.Beta2-SNAPSHOT.jar -> javax.el-3.0-b07.jar
wildfly-jsf-injection-8.0.0.Beta2-SNAPSHOT.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
wildfly-jsf-injection-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-jsf-injection-8.0.0.Beta2-SNAPSHOT.jar -> jsf-impl-2.2.4-jbossorg-1.jar
wildfly-jsr77-8.0.0.Beta2-SNAPSHOT.jar -> jboss-j2eemgmt-api_1.1_spec-1.0.1.Final.jar
wildfly-jsr77-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
wildfly-jsr77-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-jsr77-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-server-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jsr77-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-naming-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jsr77-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-jmx-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jsr77-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jsr77-8.0.0.Beta2-SNAPSHOT.jar -> jboss-invocation-1.2.0.Beta4.jar
wildfly-jsr77-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jsr77-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-jsr77-8.0.0.Beta2-SNAPSHOT.jar -> jboss-client.jar
wildfly-jsr77-8.0.0.Beta2-SNAPSHOT.jar -> jboss-as-version-8.0.0.Beta2-SNAPSHOT.jar
wildfly-jsr77-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-logging-8.0.0.Beta2-SNAPSHOT.jar -> jboss-logmanager-1.5.0.Final.jar
wildfly-logging-8.0.0.Beta2-SNAPSHOT.jar -> not found
wildfly-logging-8.0.0.Beta2-SNAPSHOT.jar -> log4j-jboss-logmanager-1.0.2.Final.jar
wildfly-logging-8.0.0.Beta2-SNAPSHOT.jar -> jboss-stdio-1.0.2.GA.jar
wildfly-logging-8.0.0.Beta2-SNAPSHOT.jar -> jboss-common-core-2.2.22.GA.jar
wildfly-logging-8.0.0.Beta2-SNAPSHOT.jar -> jboss-modules.jar
wildfly-logging-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
wildfly-logging-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-logging-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-server-8.0.0.Beta2-SNAPSHOT.jar
wildfly-logging-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-logging-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-mail-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar
wildfly-mail-8.0.0.Beta2-SNAPSHOT.jar -> javax.mail-1.5.0.jar
wildfly-mail-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
wildfly-mail-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-mail-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-network-8.0.0.Beta2-SNAPSHOT.jar
wildfly-mail-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-server-8.0.0.Beta2-SNAPSHOT.jar
wildfly-mail-8.0.0.Beta2-SNAPSHOT.jar -> jandex-1.1.0.Final.jar
wildfly-mail-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-naming-8.0.0.Beta2-SNAPSHOT.jar
wildfly-mail-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-mail-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-mail-8.0.0.Beta2-SNAPSHOT.jar -> jboss-metadata-common-8.0.0.Beta5.jar
wildfly-management-client-content-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
wildfly-management-client-content-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-deployment-repository-8.0.0.Beta2-SNAPSHOT.jar
wildfly-management-client-content-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-management-client-content-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-messaging-8.0.0.Beta2-SNAPSHOT.jar -> picketbox-4.0.20.Beta2.jar
wildfly-messaging-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar
wildfly-messaging-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
wildfly-messaging-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-messaging-8.0.0.Beta2-SNAPSHOT.jar -> hornetq-server-2.4.0.Final.jar
wildfly-messaging-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-transactions-8.0.0.Beta2-SNAPSHOT.jar
wildfly-messaging-8.0.0.Beta2-SNAPSHOT.jar -> ironjacamar-core-api-1.1.2.Final.jar
wildfly-messaging-8.0.0.Beta2-SNAPSHOT.jar -> cdi-api-1.1.jar
wildfly-messaging-8.0.0.Beta2-SNAPSHOT.jar -> netty-xnio-transport-0.1.0.jar
wildfly-messaging-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-remoting-8.0.0.Beta2-SNAPSHOT.jar
wildfly-messaging-8.0.0.Beta2-SNAPSHOT.jar -> ironjacamar-common-api-1.1.2.Final.jar
wildfly-messaging-8.0.0.Beta2-SNAPSHOT.jar -> jboss-client.jar
wildfly-messaging-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-security-8.0.0.Beta2-SNAPSHOT.jar
wildfly-messaging-8.0.0.Beta2-SNAPSHOT.jar -> hornetq-jms-server-2.4.0.Final.jar
wildfly-messaging-8.0.0.Beta2-SNAPSHOT.jar -> ironjacamar-common-impl-1.1.2.Final.jar
wildfly-messaging-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-server-8.0.0.Beta2-SNAPSHOT.jar
wildfly-messaging-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-connector-8.0.0.Beta2-SNAPSHOT.jar
wildfly-messaging-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-naming-8.0.0.Beta2-SNAPSHOT.jar
wildfly-messaging-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-clustering-jgroups-8.0.0.Beta2-SNAPSHOT.jar
wildfly-messaging-8.0.0.Beta2-SNAPSHOT.jar -> hornetq-journal-2.4.0.Final.jar
wildfly-messaging-8.0.0.Beta2-SNAPSHOT.jar -> jboss-transaction-spi-7.1.0.Final.jar
wildfly-messaging-8.0.0.Beta2-SNAPSHOT.jar -> hornetq-core-client-2.4.0.Final.jar
wildfly-messaging-8.0.0.Beta2-SNAPSHOT.jar -> hornetq-commons-2.4.0.Final.jar
wildfly-messaging-8.0.0.Beta2-SNAPSHOT.jar -> undertow-core-1.0.0.Beta28.jar
wildfly-messaging-8.0.0.Beta2-SNAPSHOT.jar -> jboss-modules.jar
wildfly-messaging-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar
wildfly-messaging-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-network-8.0.0.Beta2-SNAPSHOT.jar
wildfly-messaging-8.0.0.Beta2-SNAPSHOT.jar -> hornetq-jms-client-2.4.0.Final.jar
wildfly-messaging-8.0.0.Beta2-SNAPSHOT.jar -> jandex-1.1.0.Final.jar
wildfly-messaging-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-messaging-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-messaging-8.0.0.Beta2-SNAPSHOT.jar -> jboss-metadata-common-8.0.0.Beta5.jar
wildfly-mod_cluster-extension-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
wildfly-mod_cluster-extension-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-mod_cluster-extension-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-network-8.0.0.Beta2-SNAPSHOT.jar
wildfly-mod_cluster-extension-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-clustering-common-8.0.0.Beta2-SNAPSHOT.jar
wildfly-mod_cluster-extension-8.0.0.Beta2-SNAPSHOT.jar -> mod_cluster-core-1.3.0.Alpha1.jar
wildfly-mod_cluster-extension-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-mod_cluster-extension-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-mod_cluster-undertow-8.0.0.Beta2-SNAPSHOT.jar -> mod_cluster-container-spi-1.3.0.Alpha1.jar
wildfly-mod_cluster-undertow-8.0.0.Beta2-SNAPSHOT.jar -> undertow-core-1.0.0.Beta28.jar
wildfly-mod_cluster-undertow-8.0.0.Beta2-SNAPSHOT.jar -> undertow-servlet-1.0.0.Beta28.jar
wildfly-mod_cluster-undertow-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-mod_cluster-extension-8.0.0.Beta2-SNAPSHOT.jar
wildfly-mod_cluster-undertow-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
wildfly-mod_cluster-undertow-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-network-8.0.0.Beta2-SNAPSHOT.jar
wildfly-mod_cluster-undertow-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-mod_cluster-undertow-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-undertow-8.0.0.Beta2-SNAPSHOT.jar
wildfly-mod_cluster-undertow-8.0.0.Beta2-SNAPSHOT.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
wildfly-mod_cluster-undertow-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
   org.wildfly.mod_cluster.undertow.metric.jdk8backported.Striped64 (wildfly-mod_cluster-undertow-8.0.0.Beta2-SNAPSHOT.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   org.wildfly.mod_cluster.undertow.metric.jdk8backported.Striped64$1 (wildfly-mod_cluster-undertow-8.0.0.Beta2-SNAPSHOT.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
   org.wildfly.mod_cluster.undertow.metric.jdk8backported.Striped64$Cell (wildfly-mod_cluster-undertow-8.0.0.Beta2-SNAPSHOT.jar)
      -> sun.misc.Unsafe                                    JDK internal API (rt.jar)
wildfly-naming-8.0.0.Beta2-SNAPSHOT.jar -> jboss-invocation-1.2.0.Beta4.jar
wildfly-naming-8.0.0.Beta2-SNAPSHOT.jar -> jboss-modules.jar
wildfly-naming-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
wildfly-naming-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-naming-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-remoting-8.0.0.Beta2-SNAPSHOT.jar
wildfly-naming-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-server-8.0.0.Beta2-SNAPSHOT.jar
wildfly-naming-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-naming-8.0.0.Beta2-SNAPSHOT.jar -> jboss-client.jar
wildfly-naming-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-network-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
wildfly-network-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-network-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-patching-8.0.0.Beta2-SNAPSHOT.jar -> jboss-modules.jar
wildfly-patching-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
wildfly-patching-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-patching-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-patching-8.0.0.Beta2-SNAPSHOT.jar -> jboss-as-version-8.0.0.Beta2-SNAPSHOT.jar
wildfly-patching-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-platform-mbean-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
wildfly-platform-mbean-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-platform-mbean-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-platform-mbean-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-pojo-8.0.0.Beta2-SNAPSHOT.jar -> jboss-common-beans-1.1.0.Final.jar
wildfly-pojo-8.0.0.Beta2-SNAPSHOT.jar -> jboss-modules.jar
wildfly-pojo-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
wildfly-pojo-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-pojo-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-server-8.0.0.Beta2-SNAPSHOT.jar
wildfly-pojo-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-pojo-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-process-controller-8.0.0.Beta2-SNAPSHOT.jar -> jboss-logmanager-1.5.0.Final.jar
wildfly-process-controller-8.0.0.Beta2-SNAPSHOT.jar -> jboss-modules.jar
wildfly-process-controller-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
wildfly-process-controller-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-process-controller-8.0.0.Beta2-SNAPSHOT.jar -> jboss-as-version-8.0.0.Beta2-SNAPSHOT.jar
wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-remoting-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-domain-management-8.0.0.Beta2-SNAPSHOT.jar
wildfly-remoting-8.0.0.Beta2-SNAPSHOT.jar -> undertow-core-1.0.0.Beta28.jar
wildfly-remoting-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-core-security-8.0.0.Beta2-SNAPSHOT.jar
wildfly-remoting-8.0.0.Beta2-SNAPSHOT.jar -> jboss-modules.jar
wildfly-remoting-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
wildfly-remoting-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-remoting-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-network-8.0.0.Beta2-SNAPSHOT.jar
wildfly-remoting-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-remoting-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-rts-8.0.0.Beta2-SNAPSHOT.jar -> resteasy-jettison-provider-3.0.6.Final.jar
wildfly-rts-8.0.0.Beta2-SNAPSHOT.jar -> restat-api-5.0.0.CR2.jar
wildfly-rts-8.0.0.Beta2-SNAPSHOT.jar -> narayana-jts-jacorb-5.0.0.CR2.jar
wildfly-rts-8.0.0.Beta2-SNAPSHOT.jar -> restat-integration-5.0.0.CR2.jar
wildfly-rts-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
wildfly-rts-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-rts-8.0.0.Beta2-SNAPSHOT.jar -> resteasy-jaxb-provider-3.0.6.Final.jar
wildfly-rts-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-undertow-8.0.0.Beta2-SNAPSHOT.jar
wildfly-rts-8.0.0.Beta2-SNAPSHOT.jar -> restat-bridge-5.0.0.CR2.jar
wildfly-rts-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-server-8.0.0.Beta2-SNAPSHOT.jar
wildfly-rts-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-jaxrs-8.0.0.Beta2-SNAPSHOT.jar
wildfly-rts-8.0.0.Beta2-SNAPSHOT.jar -> jaxrs-api-3.0.6.Final.jar
wildfly-rts-8.0.0.Beta2-SNAPSHOT.jar -> undertow-core-1.0.0.Beta28.jar
wildfly-rts-8.0.0.Beta2-SNAPSHOT.jar -> undertow-servlet-1.0.0.Beta28.jar
wildfly-rts-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-transactions-8.0.0.Beta2-SNAPSHOT.jar
wildfly-rts-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-network-8.0.0.Beta2-SNAPSHOT.jar
wildfly-rts-8.0.0.Beta2-SNAPSHOT.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
wildfly-rts-8.0.0.Beta2-SNAPSHOT.jar -> jandex-1.1.0.Final.jar
wildfly-rts-8.0.0.Beta2-SNAPSHOT.jar -> resteasy-jaxrs-3.0.6.Final.jar
wildfly-rts-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-rts-8.0.0.Beta2-SNAPSHOT.jar -> jboss-client.jar
wildfly-rts-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-sar-8.0.0.Beta2-SNAPSHOT.jar -> jboss-common-beans-1.1.0.Final.jar
wildfly-sar-8.0.0.Beta2-SNAPSHOT.jar -> jboss-invocation-1.2.0.Beta4.jar
wildfly-sar-8.0.0.Beta2-SNAPSHOT.jar -> jboss-modules.jar
wildfly-sar-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar
wildfly-sar-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
wildfly-sar-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-sar-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-server-8.0.0.Beta2-SNAPSHOT.jar
wildfly-sar-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-naming-8.0.0.Beta2-SNAPSHOT.jar
wildfly-sar-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-sar-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-jmx-8.0.0.Beta2-SNAPSHOT.jar
wildfly-sar-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-sar-8.0.0.Beta2-SNAPSHOT.jar -> jboss-metadata-common-8.0.0.Beta5.jar
wildfly-security-8.0.0.Beta2-SNAPSHOT.jar -> picketbox-4.0.20.Beta2.jar
wildfly-security-8.0.0.Beta2-SNAPSHOT.jar -> picketbox-infinispan-4.0.20.Beta2.jar
wildfly-security-8.0.0.Beta2-SNAPSHOT.jar -> jboss-metadata-ear-8.0.0.Beta5.jar
wildfly-security-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/jce.jar (compact1)
wildfly-security-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-core-security-8.0.0.Beta2-SNAPSHOT.jar
wildfly-security-8.0.0.Beta2-SNAPSHOT.jar -> jboss-jacc-api_1.5_spec-1.0.0.Beta1.jar
wildfly-security-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
wildfly-security-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-security-8.0.0.Beta2-SNAPSHOT.jar -> infinispan-commons-6.0.1.Final.jar
wildfly-security-8.0.0.Beta2-SNAPSHOT.jar -> jboss-negotiation-extras-2.2.6.Final.jar
wildfly-security-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-server-8.0.0.Beta2-SNAPSHOT.jar
wildfly-security-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-naming-8.0.0.Beta2-SNAPSHOT.jar
wildfly-security-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-domain-management-8.0.0.Beta2-SNAPSHOT.jar
wildfly-security-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-clustering-infinispan-8.0.0.Beta2-SNAPSHOT.jar
wildfly-security-8.0.0.Beta2-SNAPSHOT.jar -> commons-cli-1.2.jar
wildfly-security-8.0.0.Beta2-SNAPSHOT.jar -> jboss-negotiation-spnego-2.2.6.Final.jar
wildfly-security-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-transactions-8.0.0.Beta2-SNAPSHOT.jar
wildfly-security-8.0.0.Beta2-SNAPSHOT.jar -> jboss-modules.jar
wildfly-security-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar
wildfly-security-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-security-8.0.0.Beta2-SNAPSHOT.jar -> jboss-client.jar
wildfly-security-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-security-8.0.0.Beta2-SNAPSHOT.jar -> infinispan-core-6.0.1.Final.jar
wildfly-security-8.0.0.Beta2-SNAPSHOT.jar -> jboss-metadata-common-8.0.0.Beta5.jar
wildfly-security-manager-1.0.0.Beta3.jar -> jboss-modules.jar
wildfly-security-manager-1.0.0.Beta3.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
wildfly-security-manager-1.0.0.Beta3.jar -> jboss-cli-client.jar
   org.wildfly.security.manager.WildFlySecurityManager (wildfly-security-manager-1.0.0.Beta3.jar)
      -> sun.reflect.Reflection                             JDK internal API (rt.jar)
wildfly-security-manager-8.0.0.Beta2-SNAPSHOT.jar -> jboss-modules.jar
wildfly-security-manager-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
wildfly-security-manager-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-security-manager-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-server-8.0.0.Beta2-SNAPSHOT.jar
wildfly-security-manager-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-security-manager-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-security-manager-8.0.0.Beta2-SNAPSHOT.jar -> jboss-metadata-common-8.0.0.Beta5.jar
wildfly-server-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-process-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-server-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
wildfly-server-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-deployment-repository-8.0.0.Beta2-SNAPSHOT.jar
wildfly-server-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-server-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-domain-http-interface-8.0.0.Beta2-SNAPSHOT.jar
wildfly-server-8.0.0.Beta2-SNAPSHOT.jar -> jboss-logmanager-1.5.0.Final.jar
wildfly-server-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-domain-management-8.0.0.Beta2-SNAPSHOT.jar
wildfly-server-8.0.0.Beta2-SNAPSHOT.jar -> undertow-core-1.0.0.Beta28.jar
wildfly-server-8.0.0.Beta2-SNAPSHOT.jar -> jboss-stdio-1.0.2.GA.jar
wildfly-server-8.0.0.Beta2-SNAPSHOT.jar -> jboss-invocation-1.2.0.Beta4.jar
wildfly-server-8.0.0.Beta2-SNAPSHOT.jar -> jboss-modules.jar
wildfly-server-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-network-8.0.0.Beta2-SNAPSHOT.jar
wildfly-server-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-remoting-8.0.0.Beta2-SNAPSHOT.jar
wildfly-server-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-platform-mbean-8.0.0.Beta2-SNAPSHOT.jar
wildfly-server-8.0.0.Beta2-SNAPSHOT.jar -> jandex-1.1.0.Final.jar
wildfly-server-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-server-8.0.0.Beta2-SNAPSHOT.jar -> jboss-as-version-8.0.0.Beta2-SNAPSHOT.jar
wildfly-server-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-system-jmx-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
wildfly-system-jmx-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-threads-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
wildfly-threads-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-threads-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-threads-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-transactions-8.0.0.Beta2-SNAPSHOT.jar -> narayana-jts-integration-5.0.0.CR2.jar
wildfly-transactions-8.0.0.Beta2-SNAPSHOT.jar -> narayana-jts-jacorb-5.0.0.CR2.jar
wildfly-transactions-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
wildfly-transactions-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-transactions-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-server-8.0.0.Beta2-SNAPSHOT.jar
wildfly-transactions-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-naming-8.0.0.Beta2-SNAPSHOT.jar
wildfly-transactions-8.0.0.Beta2-SNAPSHOT.jar -> jboss-transaction-spi-7.1.0.Final.jar
wildfly-transactions-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-jacorb-8.0.0.Beta2-SNAPSHOT.jar
wildfly-transactions-8.0.0.Beta2-SNAPSHOT.jar -> jacorb-2.3.2-jbossorg-5.jar
wildfly-transactions-8.0.0.Beta2-SNAPSHOT.jar -> jboss-modules.jar
wildfly-transactions-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar
wildfly-transactions-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-network-8.0.0.Beta2-SNAPSHOT.jar
wildfly-transactions-8.0.0.Beta2-SNAPSHOT.jar -> jandex-1.1.0.Final.jar
wildfly-transactions-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-transactions-8.0.0.Beta2-SNAPSHOT.jar -> jboss-client.jar
wildfly-transactions-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-undertow-8.0.0.Beta2-SNAPSHOT.jar -> picketbox-4.0.20.Beta2.jar
wildfly-undertow-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
wildfly-undertow-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-undertow-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-io-8.0.0.Beta2-SNAPSHOT.jar
wildfly-undertow-8.0.0.Beta2-SNAPSHOT.jar -> jastow-1.0.0.CR1.jar
wildfly-undertow-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-domain-management-8.0.0.Beta2-SNAPSHOT.jar
wildfly-undertow-8.0.0.Beta2-SNAPSHOT.jar -> undertow-servlet-1.0.0.Beta28.jar
wildfly-undertow-8.0.0.Beta2-SNAPSHOT.jar -> undertow-websockets-jsr-1.0.0.Beta28.jar
wildfly-undertow-8.0.0.Beta2-SNAPSHOT.jar -> jboss-annotations-api_1.2_spec-1.0.0.Final.jar
wildfly-undertow-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-web-common-8.0.0.Beta2-SNAPSHOT.jar
wildfly-undertow-8.0.0.Beta2-SNAPSHOT.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
wildfly-undertow-8.0.0.Beta2-SNAPSHOT.jar -> jboss-metadata-ear-8.0.0.Beta5.jar
wildfly-undertow-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-security-8.0.0.Beta2-SNAPSHOT.jar
wildfly-undertow-8.0.0.Beta2-SNAPSHOT.jar -> jboss-jacc-api_1.5_spec-1.0.0.Beta1.jar
wildfly-undertow-8.0.0.Beta2-SNAPSHOT.jar -> javax.el-3.0-b07.jar
wildfly-undertow-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-server-8.0.0.Beta2-SNAPSHOT.jar
wildfly-undertow-8.0.0.Beta2-SNAPSHOT.jar -> jboss-jsp-api_2.3_spec-1.0.0.Beta1.jar
wildfly-undertow-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-naming-8.0.0.Beta2-SNAPSHOT.jar
wildfly-undertow-8.0.0.Beta2-SNAPSHOT.jar -> undertow-core-1.0.0.Beta28.jar
wildfly-undertow-8.0.0.Beta2-SNAPSHOT.jar -> jboss-modules.jar
wildfly-undertow-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar
wildfly-undertow-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-network-8.0.0.Beta2-SNAPSHOT.jar
wildfly-undertow-8.0.0.Beta2-SNAPSHOT.jar -> jboss-websocket-api_1.0_spec-1.0.0.Final.jar
wildfly-undertow-8.0.0.Beta2-SNAPSHOT.jar -> jandex-1.1.0.Final.jar
wildfly-undertow-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-undertow-8.0.0.Beta2-SNAPSHOT.jar -> jboss-metadata-web-8.0.0.Beta5.jar
wildfly-undertow-8.0.0.Beta2-SNAPSHOT.jar -> jboss-jaspi-api_1.1_spec-1.0.0.Alpha1.jar
wildfly-undertow-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-undertow-8.0.0.Beta2-SNAPSHOT.jar -> jboss-metadata-common-8.0.0.Beta5.jar
wildfly-version-8.0.0.Beta2-SNAPSHOT.jar -> jboss-modules.jar
wildfly-version-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
wildfly-version-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-web-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
wildfly-web-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-web-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-web-common-8.0.0.Beta2-SNAPSHOT.jar -> jboss-modules.jar
wildfly-web-common-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar
wildfly-web-common-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
wildfly-web-common-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-web-common-8.0.0.Beta2-SNAPSHOT.jar -> javax.el-3.0-b07.jar
wildfly-web-common-8.0.0.Beta2-SNAPSHOT.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
wildfly-web-common-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-server-8.0.0.Beta2-SNAPSHOT.jar
wildfly-web-common-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-web-common-8.0.0.Beta2-SNAPSHOT.jar -> jboss-metadata-web-8.0.0.Beta5.jar
wildfly-web-common-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-naming-8.0.0.Beta2-SNAPSHOT.jar
wildfly-web-common-8.0.0.Beta2-SNAPSHOT.jar -> jboss-metadata-common-8.0.0.Beta5.jar
wildfly-webservices-server-integration-8.0.0.Beta2-SNAPSHOT.jar -> jbossws-spi-2.2.2.Final.jar
wildfly-webservices-server-integration-8.0.0.Beta2-SNAPSHOT.jar -> picketbox-4.0.20.Beta2.jar
wildfly-webservices-server-integration-8.0.0.Beta2-SNAPSHOT.jar -> jsr181-api-1.0-MR1.jar
wildfly-webservices-server-integration-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
wildfly-webservices-server-integration-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-webservices-server-integration-8.0.0.Beta2-SNAPSHOT.jar -> jbossws-common-2.2.3.Final.jar
wildfly-webservices-server-integration-8.0.0.Beta2-SNAPSHOT.jar -> jboss-invocation-1.2.0.Beta4.jar
wildfly-webservices-server-integration-8.0.0.Beta2-SNAPSHOT.jar -> jboss-annotations-api_1.2_spec-1.0.0.Final.jar
wildfly-webservices-server-integration-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-web-common-8.0.0.Beta2-SNAPSHOT.jar
wildfly-webservices-server-integration-8.0.0.Beta2-SNAPSHOT.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
wildfly-webservices-server-integration-8.0.0.Beta2-SNAPSHOT.jar -> jboss-client.jar
wildfly-webservices-server-integration-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-security-8.0.0.Beta2-SNAPSHOT.jar
wildfly-webservices-server-integration-8.0.0.Beta2-SNAPSHOT.jar -> jboss-metadata-ear-8.0.0.Beta5.jar
wildfly-webservices-server-integration-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-server-8.0.0.Beta2-SNAPSHOT.jar
wildfly-webservices-server-integration-8.0.0.Beta2-SNAPSHOT.jar -> jboss-metadata-ejb-8.0.0.Beta5.jar
wildfly-webservices-server-integration-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-naming-8.0.0.Beta2-SNAPSHOT.jar
wildfly-webservices-server-integration-8.0.0.Beta2-SNAPSHOT.jar -> jboss-jaxws-api_2.2_spec-2.0.2.Final.jar
wildfly-webservices-server-integration-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar
wildfly-webservices-server-integration-8.0.0.Beta2-SNAPSHOT.jar -> jboss-modules.jar
wildfly-webservices-server-integration-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar
wildfly-webservices-server-integration-8.0.0.Beta2-SNAPSHOT.jar -> jbossws-api-1.0.2.Final.jar
wildfly-webservices-server-integration-8.0.0.Beta2-SNAPSHOT.jar -> jandex-1.1.0.Final.jar
wildfly-webservices-server-integration-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-webservices-server-integration-8.0.0.Beta2-SNAPSHOT.jar -> jboss-metadata-web-8.0.0.Beta5.jar
wildfly-webservices-server-integration-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-webservices-server-integration-8.0.0.Beta2-SNAPSHOT.jar -> jboss-metadata-common-8.0.0.Beta5.jar
wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar -> weld-api-2.1.Final.jar
wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar -> jsr181-api-1.0-MR1.jar
wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar -> guava-15.0.jar
wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar -> weld-core-impl-2.1.1.Final.jar
wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar -> weld-spi-2.1.Final.jar
wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar -> jboss-invocation-1.2.0.Beta4.jar
wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-transactions-8.0.0.Beta2-SNAPSHOT.jar
wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar -> cdi-api-1.1.jar
wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar -> jboss-annotations-api_1.2_spec-1.0.0.Final.jar
wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-web-common-8.0.0.Beta2-SNAPSHOT.jar
wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar -> jboss-servlet-api_3.1_spec-1.0.0.Final.jar
wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar -> jboss-client.jar
wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar -> validation-api-1.1.0.Final.jar
wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-security-8.0.0.Beta2-SNAPSHOT.jar
wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar -> jboss-metadata-ear-8.0.0.Beta5.jar
wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar -> javax.el-3.0-b07.jar
wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-server-8.0.0.Beta2-SNAPSHOT.jar
wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar -> hibernate-jpa-2.1-api-1.0.0.Final.jar
wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar -> jboss-jsp-api_2.3_spec-1.0.0.Beta1.jar
wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-naming-8.0.0.Beta2-SNAPSHOT.jar
wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar -> jboss-jaxws-api_2.2_spec-2.0.2.Final.jar
wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-webservices-server-integration-8.0.0.Beta2-SNAPSHOT.jar
wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar -> jboss-interceptors-api_1.2_spec-1.0.0.Final.jar
wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar
wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar -> jacorb-2.3.2-jbossorg-5.jar
wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar -> jipijapa-spi-1.0.0.Final.jar
wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar -> jboss-modules.jar
wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-jpa-8.0.0.Beta2-SNAPSHOT.jar
wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar
wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar -> jandex-1.1.0.Final.jar
wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar -> jboss-metadata-web-8.0.0.Beta5.jar
wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar -> jboss-metadata-common-8.0.0.Beta5.jar
wildfly-xts-8.0.0.Beta2-SNAPSHOT.jar -> jbossws-spi-2.2.2.Final.jar
wildfly-xts-8.0.0.Beta2-SNAPSHOT.jar -> jsr181-api-1.0-MR1.jar
wildfly-xts-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar
wildfly-xts-8.0.0.Beta2-SNAPSHOT.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
wildfly-xts-8.0.0.Beta2-SNAPSHOT.jar -> jboss-msc-1.2.0.CR1.jar
wildfly-xts-8.0.0.Beta2-SNAPSHOT.jar -> jbossxts-5.0.0.CR2.jar
wildfly-xts-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-server-8.0.0.Beta2-SNAPSHOT.jar
wildfly-xts-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-naming-8.0.0.Beta2-SNAPSHOT.jar
wildfly-xts-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-webservices-server-integration-8.0.0.Beta2-SNAPSHOT.jar
wildfly-xts-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar
wildfly-xts-8.0.0.Beta2-SNAPSHOT.jar -> jboss-invocation-1.2.0.Beta4.jar
wildfly-xts-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-transactions-8.0.0.Beta2-SNAPSHOT.jar
wildfly-xts-8.0.0.Beta2-SNAPSHOT.jar -> jboss-modules.jar
wildfly-xts-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar
wildfly-xts-8.0.0.Beta2-SNAPSHOT.jar -> jbosstxbridge-5.0.0.CR2.jar
wildfly-xts-8.0.0.Beta2-SNAPSHOT.jar -> jandex-1.1.0.Final.jar
wildfly-xts-8.0.0.Beta2-SNAPSHOT.jar -> jboss-cli-client.jar
wildfly-xts-8.0.0.Beta2-SNAPSHOT.jar -> jboss-client.jar
wildfly-xts-8.0.0.Beta2-SNAPSHOT.jar -> txframework-5.0.0.CR2.jar
wildfly-xts-8.0.0.Beta2-SNAPSHOT.jar -> wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar
woodstox-core-asl-4.2.0.jar -> not found
woodstox-core-asl-4.2.0.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
woodstox-core-asl-4.2.0.jar -> relaxngDatatype-2011.1.jar
woodstox-core-asl-4.2.0.jar -> org.osgi.core-5.0.0.jar
woodstox-core-asl-4.2.0.jar -> stax2-api-3.1.1.jar
wsdl4j-1.6.3.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
wss4j-1.6.12.jar -> /opt/jdk1.8.0/jre/lib/jce.jar (compact1)
wss4j-1.6.12.jar -> opensaml-2.5.3.jar
wss4j-1.6.12.jar -> xmltooling-1.3.4.jar
wss4j-1.6.12.jar -> xmlsec-1.5.5.jar
wss4j-1.6.12.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
wss4j-1.6.12.jar -> jcl-over-slf4j-1.7.2.jbossorg-1.jar
wss4j-1.6.12.jar -> joda-time-1.6.2.jar
xalan-2.7.1.jbossorg-1.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
xalan-2.7.1.jbossorg-1.jar -> serializer-2.7.1.jbossorg-1.jar
xalan-2.7.1.jbossorg-1.jar -> jaxen-1.1.3.jar
   org.apache.xpath.domapi.XPathEvaluatorImpl (xalan-2.7.1.jbossorg-1.jar)
      -> org.w3c.dom.xpath.XPathEvaluator                   JDK internal API (rt.jar)
      -> org.w3c.dom.xpath.XPathException                   JDK internal API (rt.jar)
      -> org.w3c.dom.xpath.XPathExpression                  JDK internal API (rt.jar)
      -> org.w3c.dom.xpath.XPathNSResolver                  JDK internal API (rt.jar)
   org.apache.xpath.domapi.XPathExpressionImpl (xalan-2.7.1.jbossorg-1.jar)
      -> org.w3c.dom.xpath.XPathException                   JDK internal API (rt.jar)
      -> org.w3c.dom.xpath.XPathExpression                  JDK internal API (rt.jar)
   org.apache.xpath.domapi.XPathNSResolverImpl (xalan-2.7.1.jbossorg-1.jar)
      -> org.w3c.dom.xpath.XPathNSResolver                  JDK internal API (rt.jar)
   org.apache.xpath.domapi.XPathNamespaceImpl (xalan-2.7.1.jbossorg-1.jar)
      -> org.w3c.dom.xpath.XPathNamespace                   JDK internal API (rt.jar)
   org.apache.xpath.domapi.XPathResultImpl (xalan-2.7.1.jbossorg-1.jar)
      -> org.w3c.dom.xpath.XPathException                   JDK internal API (rt.jar)
      -> org.w3c.dom.xpath.XPathResult                      JDK internal API (rt.jar)
xercesImpl-2.9.1-jbossas-2.jar -> xml-resolver-1.2.jar
xercesImpl-2.9.1-jbossas-2.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
xercesImpl-2.9.1-jbossas-2.jar -> jaxen-1.1.3.jar
xml-resolver-1.2.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
xmlschema-core-2.0.2.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
xmlsec-1.5.5.jar -> /opt/jdk1.8.0/jre/lib/jce.jar (compact1)
xmlsec-1.5.5.jar -> xalan-2.7.1.jbossorg-1.jar
xmlsec-1.5.5.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
xmlsec-1.5.5.jar -> jcl-over-slf4j-1.7.2.jbossorg-1.jar
xmltooling-1.3.4.jar -> not found
xmltooling-1.3.4.jar -> /opt/jdk1.8.0/jre/lib/jce.jar (compact1)
xmltooling-1.3.4.jar -> jcip-annotations-1.0.jar
xmltooling-1.3.4.jar -> xmlsec-1.5.5.jar
xmltooling-1.3.4.jar -> bcprov-jdk16-1.46.jar
xmltooling-1.3.4.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
xmltooling-1.3.4.jar -> slf4j-api-1.7.2.jbossorg-1.jar
xmltooling-1.3.4.jar -> joda-time-1.6.2.jar
xnio-api-3.2.0.Beta3.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact3)
xnio-api-3.2.0.Beta3.jar -> jboss-cli-client.jar
xnio-nio-3.2.0.Beta3.jar -> not found
xnio-nio-3.2.0.Beta3.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact1)
xnio-nio-3.2.0.Beta3.jar -> jboss-cli-client.jar
xom-1.2.5.jar -> not found
xom-1.2.5.jar -> xercesImpl-2.9.1-jbossas-2.jar
xom-1.2.5.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (compact2)
   nu.xom.JDK15XML1_0Parser (xom-1.2.5.jar)
      -> com.sun.org.apache.xerces.internal.parsers.DTDConfiguration JDK internal API (rt.jar)
      -> com.sun.org.apache.xerces.internal.parsers.SAXParser JDK internal API (rt.jar)
      -> com.sun.org.apache.xerces.internal.util.SecurityManager JDK internal API (rt.jar)
      -> com.sun.org.apache.xerces.internal.xni.parser.XMLParserConfiguration JDK internal API (rt.jar)
xsom-20110809.jar -> /opt/jdk1.8.0/jre/lib/rt.jar (Full JRE)
xsom-20110809.jar -> relaxngDatatype-2011.1.jar

From rory.odonnell at oracle.com  Wed Dec 18 10:12:38 2013
From: rory.odonnell at oracle.com (Rory O'Donnell Oracle, Dublin Ireland)
Date: Wed, 18 Dec 2013 15:12:38 +0000
Subject: [wildfly-dev] New JDK 8 tool: jdeps
In-Reply-To: <52B1B703.7000509@gmx.net>
References: <52B04D71.2020405@oracle.com> <52B1B703.7000509@gmx.net>
Message-ID: <52B1BB66.6090002@oracle.com>

Thank you for the data.

Rgds,Rory
On 18/12/2013 14:53, Philippe Marschall wrote:
>
>
> On 17.12.2013 14:11, Rory O'Donnell wrote:
>> Hi All,
>>
>> Here's a blog from Erik Costlow on a new tool in JDK 8 that lets you
>> analyze your code
>> for dependencies on JDK internal APIs :
>>
>> https://blogs.oracle.com/java-platform-group/entry/closing_the_closed_apis 
>>
>>
>> Please let me know if you have any feedback - I'd be interested to hear
>> if you use any
>> internal APIs.
>
> I ran the tool and here's the output:
>  - codemodel (a Sun/Oracle project nonetheless) uses sun.nio.cs.Surrogate
>  - jaxb-xjc (a Sun/Oracle project nonetheless) uses 
> com.sun.org.apache.xml.internal.resolver
>  - jacorb uses sun.security.jgss.spi
>  - xalan uses org.apache.xpath.domapi (this looks like a false positive)
>  - xom uses com.sun.org.apache.xerces.internal
>  - xnio-nio uses the following classes through reflection 
> (Class.forName) sun.nio.ch.KQueueSelectorProvider, 
> sun.nio.ch.EPollSelectorProvider, sun.nio.ch.DevPollSelectorProvider, 
> sun.nio.ch.PollsetSelectorProvider, sun.nio.ch.PollSelectorProvider, 
> sun.nio.ch.PollSelectorImpl. This looks like a limitation of jdeps 
> that it doesn't catch Class.forName.
>  - undertow-core tests use com.sun.security.auth.module.Krb5LoginModule
>  - wildfly-security uses com.sun.security.auth.module.Krb5LoginModule
>  - wildfly-domain-managment uses com.sun.jndi.ldap.LdapCtxFactory
>  - wildfly-ts-integ-basic uses sun.security.tools.JarSigner, 
> com.sun.jndi.cosnaming.CNCtxFactory, com.sun.jndi.ldap.LdapCtx, 
> com.sun.jndi.ldap.LdapCtxFactory and sun.tools.jar.resources.jar
>  - wildfly-testsuite-shared uses 
> com.sun.security.auth.module.Krb5LoginModule
>
> sun.misc.Signal and sun.misc.SignalHandler are used in several places 
> (AFAIK there's still not API for this)
>  - aesh
>  - jboss-cli-client
>
> sun.reflect.ReflectionFactory and sun.reflect.Reflection are used in 
> several places
>  - jboss-client
>  - jboss-cli-client
>  - jboss-rmi-api_1.0_spec
>  - jboss-marshalling
>  - undertow-servlet
>  - wildfly-security-manager
>
> sun.misc.Cleaner is used in several places (AFAIK you're still 
> unwilling to provide an API for this)
>  - jboss-client
>  - netty-all
>
> sun.misc.Unsafe is used all over the place
>  - avro
>  - guava
>  - infinispan-commons
>  - jboss-client
>  - jboss-modules
>  - jboss-rmi-api_1.0_spec
>  - netty-all
>  - undertow-core
>  - wildfly-mod_cluster-undertow
>
> Cheers
> Philippe

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland


From jason.greene at redhat.com  Wed Dec 18 11:23:50 2013
From: jason.greene at redhat.com (Jason Greene)
Date: Wed, 18 Dec 2013 10:23:50 -0600
Subject: [wildfly-dev] Intermittent Yet Frequent Failure in
	JmsClientTestCase
In-Reply-To: <23BA56F0-B55A-4390-97A3-7942227659BE@redhat.com>
References: <25A2E6D3-6467-4214-8AE7-1C34AC55EA3B@redhat.com>
	<23BA56F0-B55A-4390-97A3-7942227659BE@redhat.com>
Message-ID: <B41B8ACE-758D-4C62-8E9E-D86FF67FA9FC@redhat.com>

Thanks Jeff!

On Dec 18, 2013, at 8:21 AM, Jeff Mesnil <jmesnil at redhat.com> wrote:

> 
> On 17 Dec 2013, at 23:48, Jason Greene <jason.greene at redhat.com> wrote:
> 
>> I merged the one-port hq PR (thanks for that!)
>> 
>> Although now I am seeing this:
>> http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=7156&tab=buildResultsDiv&buildTypeId=WF_MasterLinux
>> 
>> Can you look into it. I might have to revert it tomorrow if there isn?t a simple fix.
> 
> It was a bug in the netty-xnio bridge that norman promptly fixed.
> 
> I?ve opened a PR for it: https://github.com/wildfly/wildfly/pull/5625
> 
> jeff
> 
> -- 
> Jeff Mesnil
> JBoss, a division of Red Hat
> http://jmesnil.net/
> 

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat



From jason.greene at redhat.com  Wed Dec 18 11:24:31 2013
From: jason.greene at redhat.com (Jason Greene)
Date: Wed, 18 Dec 2013 10:24:31 -0600
Subject: [wildfly-dev] Intermittent Yet Frequent Failure in
	JmsClientTestCase
In-Reply-To: <B41B8ACE-758D-4C62-8E9E-D86FF67FA9FC@redhat.com>
References: <25A2E6D3-6467-4214-8AE7-1C34AC55EA3B@redhat.com>
	<23BA56F0-B55A-4390-97A3-7942227659BE@redhat.com>
	<B41B8ACE-758D-4C62-8E9E-D86FF67FA9FC@redhat.com>
Message-ID: <64C2CEBB-AAA8-40B7-9B33-39225FFDC31A@redhat.com>

and Norman! That was fast!
On Dec 18, 2013, at 10:23 AM, Jason Greene <jason.greene at redhat.com> wrote:

> Thanks Jeff!
> 
> On Dec 18, 2013, at 8:21 AM, Jeff Mesnil <jmesnil at redhat.com> wrote:
> 
>> 
>> On 17 Dec 2013, at 23:48, Jason Greene <jason.greene at redhat.com> wrote:
>> 
>>> I merged the one-port hq PR (thanks for that!)
>>> 
>>> Although now I am seeing this:
>>> http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=7156&tab=buildResultsDiv&buildTypeId=WF_MasterLinux
>>> 
>>> Can you look into it. I might have to revert it tomorrow if there isn?t a simple fix.
>> 
>> It was a bug in the netty-xnio bridge that norman promptly fixed.
>> 
>> I?ve opened a PR for it: https://github.com/wildfly/wildfly/pull/5625
>> 
>> jeff
>> 
>> -- 
>> Jeff Mesnil
>> JBoss, a division of Red Hat
>> http://jmesnil.net/
>> 
> 
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat



From bburke at redhat.com  Wed Dec 18 18:27:35 2013
From: bburke at redhat.com (Bill Burke)
Date: Wed, 18 Dec 2013 18:27:35 -0500
Subject: [wildfly-dev] beta2 ETA?
Message-ID: <52B22F67.7090302@redhat.com>

I was wondering if Wildfly Beta 2 will be released anytime soon.  I'm 
bundling an app server with 1st Keycloak release as an "appliance" 
download.  Have a hard requirement on Wildfly beta 2, otherwise I'll 
bundle AS7.1.1 instead.

Thanks

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From jason.greene at redhat.com  Wed Dec 18 22:06:04 2013
From: jason.greene at redhat.com (Jason Greene)
Date: Wed, 18 Dec 2013 21:06:04 -0600
Subject: [wildfly-dev] beta2 ETA?
In-Reply-To: <52B22F67.7090302@redhat.com>
References: <52B22F67.7090302@redhat.com>
Message-ID: <224C692C-7D03-4FA1-9232-CB2EFE6C41D4@redhat.com>

We are very very close to releasing CR1. We have one TCK regression and are in the process of rerunning the full TCK.

On Dec 18, 2013, at 5:27 PM, Bill Burke <bburke at redhat.com> wrote:

> I was wondering if Wildfly Beta 2 will be released anytime soon.  I'm 
> bundling an app server with 1st Keycloak release as an "appliance" 
> download.  Have a hard requirement on Wildfly beta 2, otherwise I'll 
> bundle AS7.1.1 instead.
> 
> Thanks
> 
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat



From rory.odonnell at oracle.com  Thu Dec 19 06:15:13 2013
From: rory.odonnell at oracle.com (Rory O'Donnell Oracle, Dublin Ireland)
Date: Thu, 19 Dec 2013 11:15:13 +0000
Subject: [wildfly-dev] New JDK 8 tool: jdeps
In-Reply-To: <6C515481-E09A-43F1-936A-AA3FBD044BF1@googlemail.com>
References: <52B04D71.2020405@oracle.com>
	<6C515481-E09A-43F1-936A-AA3FBD044BF1@googlemail.com>
Message-ID: <52B2D541.6080001@oracle.com>

Hi Norman,

Would it be possible to send the jdeps output  (jdeps -jdkinternals) ?

Rgds, Rory
On 17/12/2013 13:28, Norman Maurer wrote:
> In netty we use sun.misc.Unsafe if present ... I know this is evil ;)
>
>> Am 17.12.2013 um 14:11 schrieb "Rory O'Donnell" <rory.odonnell at oracle.com>:
>>
>> Hi All,
>>
>> Here's a blog from Erik Costlow on a new tool in JDK 8 that lets you analyze your code
>> for dependencies on JDK internal APIs :
>>
>> https://blogs.oracle.com/java-platform-group/entry/closing_the_closed_apis
>>
>> Please let me know if you have any feedback - I'd be interested to hear if you use any
>> internal APIs.
>>
>> Rgds,Rory
>>
>> -- 
>> Rgds,Rory O'Donnell
>> Quality Engineering Manager
>> Oracle EMEA , Dublin, Ireland
>>

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland


From arjan.tijms at gmail.com  Thu Dec 19 10:47:19 2013
From: arjan.tijms at gmail.com (arjan tijms)
Date: Thu, 19 Dec 2013 16:47:19 +0100
Subject: [wildfly-dev] beta2 ETA?
In-Reply-To: <224C692C-7D03-4FA1-9232-CB2EFE6C41D4@redhat.com>
References: <52B22F67.7090302@redhat.com>
	<224C692C-7D03-4FA1-9232-CB2EFE6C41D4@redhat.com>
Message-ID: <CAE=-AhA0gp+pc_2uBqcuW9LBngmrHLwOS3d+7tAW_x7Y32mxxQ@mail.gmail.com>

Hi,

On Thu, Dec 19, 2013 at 4:06 AM, Jason Greene <jason.greene at redhat.com>wrote:

> We are very very close to releasing CR1. We have one TCK regression and
> are in the process of rerunning the full TCK.
>

Maybe something to be aware of; the majority of the tests for JASPIC in the
Java EE 7 Samples project from Arun Gupta are still failing.

Kind regards,
Arjan Tijms


On Dec 18, 2013, at 5:27 PM, Bill Burke <bburke at redhat.com> wrote:
>
> > I was wondering if Wildfly Beta 2 will be released anytime soon.  I'm
> > bundling an app server with 1st Keycloak release as an "appliance"
> > download.  Have a hard requirement on Wildfly beta 2, otherwise I'll
> > bundle AS7.1.1 instead.
> >
> > Thanks
> >
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131219/432bf723/attachment.html 

From arjan.tijms at gmail.com  Thu Dec 19 10:48:14 2013
From: arjan.tijms at gmail.com (arjan tijms)
Date: Thu, 19 Dec 2013 16:48:14 +0100
Subject: [wildfly-dev] beta2 ETA?
In-Reply-To: <CAE=-AhA0gp+pc_2uBqcuW9LBngmrHLwOS3d+7tAW_x7Y32mxxQ@mail.gmail.com>
References: <52B22F67.7090302@redhat.com>
	<224C692C-7D03-4FA1-9232-CB2EFE6C41D4@redhat.com>
	<CAE=-AhA0gp+pc_2uBqcuW9LBngmrHLwOS3d+7tAW_x7Y32mxxQ@mail.gmail.com>
Message-ID: <CAE=-AhDBnYeWUjbtjYgoDtRWw7D1p_a-=f4Ru1fnUNc8OEr2Gw@mail.gmail.com>

On Thu, Dec 19, 2013 at 4:47 PM, arjan tijms <arjan.tijms at gmail.com> wrote:

> Maybe something to be aware of; the majority of the tests for JASPIC in
> the Java EE 7 Samples project from Arun Gupta are still failing.
>

See this:
https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20WildFly-cb/119/#showFailuresLink



>
> Kind regards,
> Arjan Tijms
>
>
> On Dec 18, 2013, at 5:27 PM, Bill Burke <bburke at redhat.com> wrote:
>>
>> > I was wondering if Wildfly Beta 2 will be released anytime soon.  I'm
>> > bundling an app server with 1st Keycloak release as an "appliance"
>> > download.  Have a hard requirement on Wildfly beta 2, otherwise I'll
>> > bundle AS7.1.1 instead.
>> >
>> > Thanks
>> >
>> > --
>> > Bill Burke
>> > JBoss, a division of Red Hat
>> > http://bill.burkecentral.com
>> > _______________________________________________
>> > wildfly-dev mailing list
>> > wildfly-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>> --
>> Jason T. Greene
>> WildFly Lead / JBoss EAP Platform Architect
>> JBoss, a division of Red Hat
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131219/50de9e19/attachment-0001.html 

From rory.odonnell at oracle.com  Fri Dec 20 03:54:37 2013
From: rory.odonnell at oracle.com (Rory O'Donnell Oracle, Dublin Ireland)
Date: Fri, 20 Dec 2013 08:54:37 +0000
Subject: [wildfly-dev] New JDK 8 tool: jdeps
In-Reply-To: <etPan.52b3e4f2.3d1b58ba.c5@Normans-MacBook-Pro.local>
References: <52B04D71.2020405@oracle.com>
	<6C515481-E09A-43F1-936A-AA3FBD044BF1@googlemail.com>
	<52B2D541.6080001@oracle.com>
	<etPan.52b3e4f2.3d1b58ba.c5@Normans-MacBook-Pro.local>
Message-ID: <52B405CD.9080003@oracle.com>

Thank you Norman.

Rgds,Rory
On 20/12/2013 06:34, Norman Maurer wrote:
> Hi Rory,
>
> here you go:
>
> ?  target git:(master) ? 
> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/jdeps 
> -P -jdkinternals netty-all-5.0.0.Alpha1-SNAPSHOT.jar
> netty-all-5.0.0.Alpha1-SNAPSHOT.jar -> 
> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/rt.jar 
> (compact3)
> netty-all-5.0.0.Alpha1-SNAPSHOT.jar -> not found
>  io.netty.util.internal.PlatformDependent0 
> (netty-all-5.0.0.Alpha1-SNAPSHOT.jar)
>       -> sun.misc.Cleaner                                   JDK 
> internal API (rt.jar)
>       -> sun.misc.Unsafe                                    JDK 
> internal API (rt.jar)
>  io.netty.util.internal.chmv8.ConcurrentHashMapV8 
> (netty-all-5.0.0.Alpha1-SNAPSHOT.jar)
>       -> sun.misc.Unsafe                                    JDK 
> internal API (rt.jar)
>  io.netty.util.internal.chmv8.ConcurrentHashMapV8$1 
> (netty-all-5.0.0.Alpha1-SNAPSHOT.jar)
>       -> sun.misc.Unsafe                                    JDK 
> internal API (rt.jar)
>  io.netty.util.internal.chmv8.ConcurrentHashMapV8$TreeBin 
> (netty-all-5.0.0.Alpha1-SNAPSHOT.jar)
>       -> sun.misc.Unsafe                                    JDK 
> internal API (rt.jar)
>  io.netty.util.internal.chmv8.CountedCompleter 
> (netty-all-5.0.0.Alpha1-SNAPSHOT.jar)
>       -> sun.misc.Unsafe                                    JDK 
> internal API (rt.jar)
>  io.netty.util.internal.chmv8.CountedCompleter$1 
> (netty-all-5.0.0.Alpha1-SNAPSHOT.jar)
>       -> sun.misc.Unsafe                                    JDK 
> internal API (rt.jar)
>  io.netty.util.internal.chmv8.ForkJoinPool 
> (netty-all-5.0.0.Alpha1-SNAPSHOT.jar)
>       -> sun.misc.Unsafe                                    JDK 
> internal API (rt.jar)
>  io.netty.util.internal.chmv8.ForkJoinPool$2 
> (netty-all-5.0.0.Alpha1-SNAPSHOT.jar)
>       -> sun.misc.Unsafe                                    JDK 
> internal API (rt.jar)
>  io.netty.util.internal.chmv8.ForkJoinPool$WorkQueue 
> (netty-all-5.0.0.Alpha1-SNAPSHOT.jar)
>       -> sun.misc.Unsafe                                    JDK 
> internal API (rt.jar)
>  io.netty.util.internal.chmv8.ForkJoinTask 
> (netty-all-5.0.0.Alpha1-SNAPSHOT.jar)
>       -> sun.misc.Unsafe                                    JDK 
> internal API (rt.jar)
>  io.netty.util.internal.chmv8.ForkJoinTask$1 
> (netty-all-5.0.0.Alpha1-SNAPSHOT.jar)
>       -> sun.misc.Unsafe                                    JDK 
> internal API (rt.jar)
>  io.netty.util.internal.chmv8.Striped64 
> (netty-all-5.0.0.Alpha1-SNAPSHOT.jar)
>       -> sun.misc.Unsafe                                    JDK 
> internal API (rt.jar)
>  io.netty.util.internal.chmv8.Striped64$1 
> (netty-all-5.0.0.Alpha1-SNAPSHOT.jar)
>       -> sun.misc.Unsafe                                    JDK 
> internal API (rt.jar)
>  io.netty.util.internal.chmv8.Striped64$Cell 
> (netty-all-5.0.0.Alpha1-SNAPSHOT.jar)
>       -> sun.misc.Unsafe                                    JDK 
> internal API (rt.jar)
>
> -- 
> Norman Maurer
>
> An 19. Dezember 2013 at 12:15:21, Rory O'Donnell Oracle, Dublin 
> Ireland (rory.odonnell at oracle.com <mailto://rory.odonnell at oracle.com>) 
> schrieb:
>
>> Hi Norman,
>>
>> Would it be possible to send the jdeps output (jdeps -jdkinternals) ?
>>
>> Rgds, Rory
>> On 17/12/2013 13:28, Norman Maurer wrote:
>> > In netty we use sun.misc.Unsafe if present ... I know this is evil ;)
>> >
>> >> Am 17.12.2013 um 14:11 schrieb "Rory O'Donnell" 
>> <rory.odonnell at oracle.com>:
>> >>
>> >> Hi All,
>> >>
>> >> Here's a blog from Erik Costlow on a new tool in JDK 8 that lets 
>> you analyze your code
>> >> for dependencies on JDK internal APIs :
>> >>
>> >> 
>> https://blogs.oracle.com/java-platform-group/entry/closing_the_closed_apis
>> >>
>> >> Please let me know if you have any feedback - I'd be interested to 
>> hear if you use any
>> >> internal APIs.
>> >>
>> >> Rgds,Rory
>> >>
>> >> --
>> >> Rgds,Rory O'Donnell
>> >> Quality Engineering Manager
>> >> Oracle EMEA , Dublin, Ireland
>> >>
>>
>> -- 
>> Rgds,Rory O'Donnell
>> Quality Engineering Manager
>> Oracle EMEA , Dublin, Ireland
>>

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131220/534a4017/attachment.html 

From jason.greene at redhat.com  Fri Dec 20 14:36:16 2013
From: jason.greene at redhat.com (Jason Greene)
Date: Fri, 20 Dec 2013 13:36:16 -0600
Subject: [wildfly-dev] WildFly 8 CR1 Update
Message-ID: <FFA46019-8ED9-4A57-AD66-59805EA00026@redhat.com>

Hello Everyone,

I know many of you have left for the holidays but for those that are still around and wonder whats going on with CR1, I thought I would give you an update. The good news is that this week we think we have resolved all TCK issues and *should* be passing 100%. 

However, we hit some bad luck during the week and the JBoss.ORG nexus repository has been unreliable preventing and/or slowing down our ability to perform needed updates. That was finally sorted last night. However, immediately after that was resolved, we ran into a new issue with an internal shared testing environment that we use to execute the TCK. This prevents us from doing one last necessary sanity run, and testing takes approximately 24 hours. 

So, unfortunately, this means there will be no release today. However, as soon as we get those test results I will cut the release.

Thanks, and my apologies for the inconvenience. 

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat



From bgeorges at redhat.com  Fri Dec 20 14:51:05 2013
From: bgeorges at redhat.com (Bruno Georges)
Date: Fri, 20 Dec 2013 14:51:05 -0500 (EST)
Subject: [wildfly-dev] WildFly 8 CR1 Update
In-Reply-To: <FFA46019-8ED9-4A57-AD66-59805EA00026@redhat.com>
References: <FFA46019-8ED9-4A57-AD66-59805EA00026@redhat.com>
Message-ID: <78446DCF-2E84-4069-82B6-2B1E46B4A6E6@redhat.com>

Hi Jason,
Thank you and your team for your continuous efforts. 
Have a great week-end!

Bruno 

Sent from my iPhone

> On 21 Dec, 2013, at 8:36, Jason Greene <jason.greene at redhat.com> wrote:
> 
> Hello Everyone,
> 
> I know many of you have left for the holidays but for those that are still around and wonder whats going on with CR1, I thought I would give you an update. The good news is that this week we think we have resolved all TCK issues and *should* be passing 100%. 
> 
> However, we hit some bad luck during the week and the JBoss.ORG nexus repository has been unreliable preventing and/or slowing down our ability to perform needed updates. That was finally sorted last night. However, immediately after that was resolved, we ran into a new issue with an internal shared testing environment that we use to execute the TCK. This prevents us from doing one last necessary sanity run, and testing takes approximately 24 hours. 
> 
> So, unfortunately, this means there will be no release today. However, as soon as we get those test results I will cut the release.
> 
> Thanks, and my apologies for the inconvenience. 
> 
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From adietish at redhat.com  Fri Dec 20 16:00:28 2013
From: adietish at redhat.com (=?ISO-8859-1?Q?Andr=E9_Dietisheim?=)
Date: Fri, 20 Dec 2013 22:00:28 +0100
Subject: [wildfly-dev] WFLY-705: what's replacing undertow-jsp in latest
	undertow?
Message-ID: <52B4AFEC.9070006@redhat.com>

Hi Stuart

I am looking into having the new request header- and ip based filters in 
undertow available to wildfly/ManagementHttpServer. When switching 
undertow in wildfly from Beta26 to Beta31 I saw that the module 
undertow-jsp was removed in Beta29. Thus wondering what's replacing it? 
I'd appreciate a lot if you could hint me some migration path for 
wildfly so that I can stick to latest undertow in current wildfly.

Thanks
Andr?

From stuart.w.douglas at gmail.com  Fri Dec 20 16:04:39 2013
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Fri, 20 Dec 2013 22:04:39 +0100
Subject: [wildfly-dev] WFLY-705: what's replacing undertow-jsp in latest
	undertow?
In-Reply-To: <52B4AFEC.9070006@redhat.com>
References: <52B4AFEC.9070006@redhat.com>
Message-ID: <CAAoo=c46hX+4NM+2ep5t-hvdPKFWAn2=C7p-u88zUd_wrtP5AA@mail.gmail.com>

If you upgrade to Wildfly master this has already been taken care of. This
module only contained a few classes and they have all be moved into Jastow
(which lives in the io.undertion.jsp module anyway).

Stuart


On Fri, Dec 20, 2013 at 10:00 PM, Andr? Dietisheim <adietish at redhat.com>wrote:

> Hi Stuart
>
> I am looking into having the new request header- and ip based filters in
> undertow available to wildfly/ManagementHttpServer. When switching
> undertow in wildfly from Beta26 to Beta31 I saw that the module
> undertow-jsp was removed in Beta29. Thus wondering what's replacing it?
> I'd appreciate a lot if you could hint me some migration path for
> wildfly so that I can stick to latest undertow in current wildfly.
>
> Thanks
> Andr?
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131220/766cc5d5/attachment.html 

From adietish at redhat.com  Fri Dec 20 16:35:26 2013
From: adietish at redhat.com (=?ISO-8859-1?Q?Andr=E9_Dietisheim?=)
Date: Fri, 20 Dec 2013 22:35:26 +0100
Subject: [wildfly-dev] WFLY-705: what's replacing undertow-jsp in latest
 undertow?
In-Reply-To: <CAAoo=c46hX+4NM+2ep5t-hvdPKFWAn2=C7p-u88zUd_wrtP5AA@mail.gmail.com>
References: <52B4AFEC.9070006@redhat.com>
	<CAAoo=c46hX+4NM+2ep5t-hvdPKFWAn2=C7p-u88zUd_wrtP5AA@mail.gmail.com>
Message-ID: <52B4B81E.4010003@redhat.com>

On 12/20/2013 10:04 PM, Stuart Douglas wrote:
> If you upgrade to Wildfly master this has already been taken care of. 
> This module only contained a few classes and they have all be moved 
> into Jastow (which lives in the io.undertion.jsp module anyway).
>

Great, thanks! Missed these changes.

> Stuart
>
>
> On Fri, Dec 20, 2013 at 10:00 PM, Andr? Dietisheim 
> <adietish at redhat.com <mailto:adietish at redhat.com>> wrote:
>
>     Hi Stuart
>
>     I am looking into having the new request header- and ip based
>     filters in
>     undertow available to wildfly/ManagementHttpServer. When switching
>     undertow in wildfly from Beta26 to Beta31 I saw that the module
>     undertow-jsp was removed in Beta29. Thus wondering what's
>     replacing it?
>     I'd appreciate a lot if you could hint me some migration path for
>     wildfly so that I can stick to latest undertow in current wildfly.
>
>     Thanks
>     Andr?
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131220/6c5b29b9/attachment-0001.html 

From jason.greene at redhat.com  Sun Dec 22 02:34:18 2013
From: jason.greene at redhat.com (Jason Greene)
Date: Sun, 22 Dec 2013 01:34:18 -0600
Subject: [wildfly-dev] WildFly 8.0.0.CR1 Released!
Message-ID: <F8189E34-9B89-4393-9109-6F9E3D65A8D4@redhat.com>

Read all about it!

http://wildfly.org/news/2013/12/21/WildFly8-CR1-Released/

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


From dandread at redhat.com  Sun Dec 22 17:37:22 2013
From: dandread at redhat.com (Dimitris Andreadis)
Date: Sun, 22 Dec 2013 23:37:22 +0100
Subject: [wildfly-dev] WildFly 8.0.0.CR1 Released!
In-Reply-To: <F8189E34-9B89-4393-9109-6F9E3D65A8D4@redhat.com>
References: <F8189E34-9B89-4393-9109-6F9E3D65A8D4@redhat.com>
Message-ID: <52B769A2.10409@redhat.com>

Nice work, congrats!

On 22/12/2013 08:34, Jason Greene wrote:
> Read all about it!
>
> http://wildfly.org/news/2013/12/21/WildFly8-CR1-Released/
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From cdaley at redhat.com  Mon Dec 23 00:05:37 2013
From: cdaley at redhat.com (Corey Daley)
Date: Mon, 23 Dec 2013 00:05:37 -0500 (EST)
Subject: [wildfly-dev] WildFly 8.0.0.CR1 Released!
In-Reply-To: <52B769A2.10409@redhat.com>
References: <F8189E34-9B89-4393-9109-6F9E3D65A8D4@redhat.com>
	<52B769A2.10409@redhat.com>
Message-ID: <620672330.7205500.1387775137058.JavaMail.root@redhat.com>

That's awesome! Congrats!

Corey Daley
Senior Product Marketing Manager
OpenShift | PaaS by Red Hat, Inc.
(o) 919.754.4623

www.openshift.com
Twitter: @openshift, @developercorey

----- Original Message -----
From: "Dimitris Andreadis" <dandread at redhat.com>
To: wildfly-dev at lists.jboss.org
Sent: Sunday, December 22, 2013 5:37:22 PM
Subject: Re: [wildfly-dev] WildFly 8.0.0.CR1 Released!

Nice work, congrats!

On 22/12/2013 08:34, Jason Greene wrote:
> Read all about it!
>
> http://wildfly.org/news/2013/12/21/WildFly8-CR1-Released/
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev

From Anil.Saldhana at redhat.com  Mon Dec 23 12:43:02 2013
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Mon, 23 Dec 2013 11:43:02 -0600
Subject: [wildfly-dev] WildFly 8.0.0.CR1 Released!
In-Reply-To: <F8189E34-9B89-4393-9109-6F9E3D65A8D4@redhat.com>
References: <F8189E34-9B89-4393-9109-6F9E3D65A8D4@redhat.com>
Message-ID: <52B87626.1050403@redhat.com>

This is fantastic news. JavaEE7. :)

On 12/22/2013 01:34 AM, Jason Greene wrote:
> Read all about it!
>
> http://wildfly.org/news/2013/12/21/WildFly8-CR1-Released/
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>

From ales.justin at gmail.com  Fri Dec 27 07:54:59 2013
From: ales.justin at gmail.com (Ales Justin)
Date: Fri, 27 Dec 2013 13:54:59 +0100
Subject: [wildfly-dev] app policy race
Message-ID: <11D264CE-737F-46D8-A888-C44831A2EDEB@gmail.com>

I often get this error: 
* https://gist.github.com/alesj/8146623

I guess it's related to https://issues.jboss.org/browse/SECURITY-777 ?

Do we have a JIRA for WF as well?

-Ales

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131227/4be47d93/attachment.html 

From rory.odonnell at oracle.com  Fri Dec 27 08:11:22 2013
From: rory.odonnell at oracle.com (Rory O'Donnell Oracle, Dublin Ireland)
Date: Fri, 27 Dec 2013 13:11:22 +0000
Subject: [wildfly-dev] JDK 8 Build 121 & JDK 7 Update 60 build 02 are
	available on java.net
In-Reply-To: <52BD79D6.4050202@oracle.com>
References: <52BD79D6.4050202@oracle.com>
Message-ID: <52BD7C7A.3010006@oracle.com>

cc'ing wildfly-dev at lists.jboss.org

Rgds,Rory
On 27/12/2013 13:00, Rory O'Donnell Oracle, Dublin Ireland wrote:
> Hi Guys,
>
> Hope you enjoyed the holidays, all the best for 2014.
>
> JDK 8 Build b121 Early Access Build is now available for download 
> <http://jdk8.java.net/download.html> & test.
> JDK 7u60 b02 Early Access Build is also available for download 
> <https://jdk7.java.net/download.html>& test.
>
> We are now very late in the release cycle of JDK 8 , issues found late 
> may
> be postponed to JDK 9 time frame. Please log all show stopper issues as
> soon as possible.
>
> Thanks for your support, Rory

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131227/3e8fcf62/attachment.html 

From ales.justin at gmail.com  Fri Dec 27 08:14:38 2013
From: ales.justin at gmail.com (Ales Justin)
Date: Fri, 27 Dec 2013 14:14:38 +0100
Subject: [wildfly-dev] xnio selection err
Message-ID: <5261DD65-1CFB-48CD-8BB9-8F5167D879D4@gmail.com>

While using UnderTow's JSR WebSockets,
implementing simple chat app, between 2 diff browsers (Chrome and Safari),
I get a flood of these log lines:

14:09:22,890 WARN  [org.xnio.nio.selector] (default I/O-3) XNIO008000: Received an I/O error on selection: java.io.IOException: Invalid argument

Any idea?

-Ales

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131227/d50f431a/attachment.html 

From tomaz.cerar at gmail.com  Fri Dec 27 09:35:47 2013
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Fri, 27 Dec 2013 06:35:47 -0800
Subject: [wildfly-dev] xnio selection err
Message-ID: <3244818932206876948@unknownmsgid>

  Isn't that the same error that happens only on your mac also in few other
cases?

Can you try on any other platform?

Sent from my Phone
 ------------------------------
From: Ales Justin <ales.justin at gmail.com>
Sent: ?27.?12.?2013 14:14
To: Wildfly Dev mailing list <wildfly-dev at lists.jboss.org>
Subject: [wildfly-dev] xnio selection err

While using UnderTow's JSR WebSockets,
implementing simple chat app, between 2 diff browsers (Chrome and Safari),
I get a flood of these log lines:

14:09:22,890 WARN  [org.xnio.nio.selector] (default I/O-3) XNIO008000:
Received an I/O error on selection: java.io.IOException: Invalid argument

Any idea?

-Ales
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131227/d694bc97/attachment.html 

From jgreene at redhat.com  Fri Dec 27 10:07:03 2013
From: jgreene at redhat.com (Jason Greene)
Date: Fri, 27 Dec 2013 10:07:03 -0500 (EST)
Subject: [wildfly-dev] xnio selection err
In-Reply-To: <C1DBB6DC-A98B-4565-ACEF-622D95310704@redhat.com>
References: <3244818932206876948@unknownmsgid>
	<C1DBB6DC-A98B-4565-ACEF-622D95310704@redhat.com>
Message-ID: <C9F670A0-C0A4-47F4-8629-36C2FBAC4E88@redhat.com>

Oops

Sent from my iPhone

> On Dec 27, 2013, at 9:00 AM, Jason Greene <jgreene at redhat.com> wrote:
> 
> Any chance you can get a stack trace out of it? Upping the log level or using a debugger to catch IOException would do the trick.
> 
> The error means the OS is throwing EINVAL.
> 
> Is this a OSX Mavericks? If so can you double check you are running the latest JVM?
> 
> Sent from my iPhone
> 
>> On Dec 27, 2013, at 8:36 AM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
>> 
>> Isn't that the same error that happens only on your mac also in few other cases?
>> 
>> Can you try on any other platform?
>> 
>> Sent from my Phone
>> From: Ales Justin
>> Sent: ?27.?12.?2013 14:14
>> To: Wildfly Dev mailing list
>> Subject: [wildfly-dev] xnio selection err
>> 
>> While using UnderTow's JSR WebSockets,
>> implementing simple chat app, between 2 diff browsers (Chrome and Safari),
>> I get a flood of these log lines:
>> 
>> 14:09:22,890 WARN  [org.xnio.nio.selector] (default I/O-3) XNIO008000: Received an I/O error on selection: java.io.IOException: Invalid argument
>> 
>> Any idea?
>> 
>> -Ales
>> 
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131227/4fb2e563/attachment-0001.html 

From jgreene at redhat.com  Fri Dec 27 10:16:23 2013
From: jgreene at redhat.com (Jason Greene)
Date: Fri, 27 Dec 2013 10:16:23 -0500 (EST)
Subject: [wildfly-dev] xnio selection err
In-Reply-To: <C9F670A0-C0A4-47F4-8629-36C2FBAC4E88@redhat.com>
References: <3244818932206876948@unknownmsgid>
	<C1DBB6DC-A98B-4565-ACEF-622D95310704@redhat.com>
	<C9F670A0-C0A4-47F4-8629-36C2FBAC4E88@redhat.com>
Message-ID: <A555DA32-13FD-47A3-B060-3061CA39790F@redhat.com>

BTW one possible cause is that your user has exceeded the max open files  limit, and you need to bump ulimit.

The reason I am interested in the stack trace though is to see which poll provider is throwing the error.

Sent from my iPhone

> On Dec 27, 2013, at 9:07 AM, Jason Greene <jgreene at redhat.com> wrote:
> 
> Oops
> 
> Sent from my iPhone
> 
>> On Dec 27, 2013, at 9:00 AM, Jason Greene <jgreene at redhat.com> wrote:
>> 
>> Any chance you can get a stack trace out of it? Upping the log level or using a debugger to catch IOException would do the trick.
>> 
>> The error means the OS is throwing EINVAL.
>> 
>> Is this a OSX Mavericks? If so can you double check you are running the latest JVM?
>> 
>> Sent from my iPhone
>> 
>>> On Dec 27, 2013, at 8:36 AM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
>>> 
>>> Isn't that the same error that happens only on your mac also in few other cases?
>>> 
>>> Can you try on any other platform?
>>> 
>>> Sent from my Phone
>>> From: Ales Justin
>>> Sent: ?27.?12.?2013 14:14
>>> To: Wildfly Dev mailing list
>>> Subject: [wildfly-dev] xnio selection err
>>> 
>>> While using UnderTow's JSR WebSockets,
>>> implementing simple chat app, between 2 diff browsers (Chrome and Safari),
>>> I get a flood of these log lines:
>>> 
>>> 14:09:22,890 WARN  [org.xnio.nio.selector] (default I/O-3) XNIO008000: Received an I/O error on selection: java.io.IOException: Invalid argument
>>> 
>>> Any idea?
>>> 
>>> -Ales
>>> 
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131227/7d081c3b/attachment.html 

From ales.justin at gmail.com  Fri Dec 27 10:47:24 2013
From: ales.justin at gmail.com (Ales Justin)
Date: Fri, 27 Dec 2013 16:47:24 +0100
Subject: [wildfly-dev] xnio selection err
In-Reply-To: <A555DA32-13FD-47A3-B060-3061CA39790F@redhat.com>
References: <3244818932206876948@unknownmsgid>
	<C1DBB6DC-A98B-4565-ACEF-622D95310704@redhat.com>
	<C9F670A0-C0A4-47F4-8629-36C2FBAC4E88@redhat.com>
	<A555DA32-13FD-47A3-B060-3061CA39790F@redhat.com>
Message-ID: <6E3B43B9-79F8-4D47-A5C3-5675DB4CDAB8@gmail.com>

Debugging org.xnio.nio.WorkerThread : 
(with few e.printStackTrace() invocations)

https://gist.github.com/alesj/8148775

On 27 Dec 2013, at 16:16, Jason Greene <jgreene at redhat.com> wrote:

> BTW one possible cause is that your user has exceeded the max open files  limit, and you need to bump ulimit.
> 
> The reason I am interested in the stack trace though is to see which poll provider is throwing the error.
> 
> Sent from my iPhone
> 
> On Dec 27, 2013, at 9:07 AM, Jason Greene <jgreene at redhat.com> wrote:
> 
>> Oops
>> 
>> Sent from my iPhone
>> 
>> On Dec 27, 2013, at 9:00 AM, Jason Greene <jgreene at redhat.com> wrote:
>> 
>>> Any chance you can get a stack trace out of it? Upping the log level or using a debugger to catch IOException would do the trick.
>>> 
>>> The error means the OS is throwing EINVAL.
>>> 
>>> Is this a OSX Mavericks? If so can you double check you are running the latest JVM?
>>> 
>>> Sent from my iPhone
>>> 
>>> On Dec 27, 2013, at 8:36 AM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
>>> 
>>>> Isn't that the same error that happens only on your mac also in few other cases?
>>>> 
>>>> Can you try on any other platform?
>>>> 
>>>> Sent from my Phone
>>>> From: Ales Justin
>>>> Sent: ?27.?12.?2013 14:14
>>>> To: Wildfly Dev mailing list
>>>> Subject: [wildfly-dev] xnio selection err
>>>> 
>>>> While using UnderTow's JSR WebSockets,
>>>> implementing simple chat app, between 2 diff browsers (Chrome and Safari),
>>>> I get a flood of these log lines:
>>>> 
>>>> 14:09:22,890 WARN  [org.xnio.nio.selector] (default I/O-3) XNIO008000: Received an I/O error on selection: java.io.IOException: Invalid argument
>>>> 
>>>> Any idea?
>>>> 
>>>> -Ales
>>>> 
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131227/2dc79a74/attachment.html 

From ales.justin at gmail.com  Fri Dec 27 10:49:22 2013
From: ales.justin at gmail.com (Ales Justin)
Date: Fri, 27 Dec 2013 16:49:22 +0100
Subject: [wildfly-dev] xnio selection err
In-Reply-To: <C9F670A0-C0A4-47F4-8629-36C2FBAC4E88@redhat.com>
References: <3244818932206876948@unknownmsgid>
	<C1DBB6DC-A98B-4565-ACEF-622D95310704@redhat.com>
	<C9F670A0-C0A4-47F4-8629-36C2FBAC4E88@redhat.com>
Message-ID: <97B99B8D-4D91-4AB7-9B22-8A988DC07F20@gmail.com>

>> Is this a OSX Mavericks?

Yes.

>> If so can you double check you are running the latest JVM?

Skywalker:bin alesj$ java -version
java version "1.7.0_45"
Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)

Latest?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131227/8cf61a0e/attachment.html 

From tomaz.cerar at gmail.com  Fri Dec 27 11:42:10 2013
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Fri, 27 Dec 2013 17:42:10 +0100
Subject: [wildfly-dev] xnio selection err
In-Reply-To: <97B99B8D-4D91-4AB7-9B22-8A988DC07F20@gmail.com>
References: <3244818932206876948@unknownmsgid>
	<C1DBB6DC-A98B-4565-ACEF-622D95310704@redhat.com>
	<C9F670A0-C0A4-47F4-8629-36C2FBAC4E88@redhat.com>
	<97B99B8D-4D91-4AB7-9B22-8A988DC07F20@gmail.com>
Message-ID: <CAMquZP5wZ+dyGxY3V7o87-iNdRrW-C87dGr_vEgLYei6QM6WoQ@mail.gmail.com>

On Fri, Dec 27, 2013 at 4:49 PM, Ales Justin <ales.justin at gmail.com> wrote:

>
> Skywalker:bin alesj$ java -version
> java version "1.7.0_45"
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
>
> Latest?
>


Latest would be EA of u60 https://jdk7.java.net/download.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131227/6ba7bbca/attachment.html 

From Anil.Saldhana at redhat.com  Fri Dec 27 11:50:46 2013
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Fri, 27 Dec 2013 10:50:46 -0600
Subject: [wildfly-dev] app policy race
In-Reply-To: <11D264CE-737F-46D8-A888-C44831A2EDEB@gmail.com>
References: <11D264CE-737F-46D8-A888-C44831A2EDEB@gmail.com>
Message-ID: <52BDAFE6.6090009@redhat.com>

Stefan merged the fixes recently. I guess we need a PicketBox upgrade in WF.

On 12/27/2013 06:54 AM, Ales Justin wrote:
> I often get this error:
> * https://gist.github.com/alesj/8146623
>
> I guess it's related to https://issues.jboss.org/browse/SECURITY-777 ?
>
> Do we have a JIRA for WF as well?
>
> -Ales
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131227/2a0f2af8/attachment-0001.html 

From ales.justin at gmail.com  Fri Dec 27 14:26:03 2013
From: ales.justin at gmail.com (Ales Justin)
Date: Fri, 27 Dec 2013 20:26:03 +0100
Subject: [wildfly-dev] app policy race
In-Reply-To: <52BDAFE6.6090009@redhat.com>
References: <11D264CE-737F-46D8-A888-C44831A2EDEB@gmail.com>
	<52BDAFE6.6090009@redhat.com>
Message-ID: <355609B6-44C0-4348-8F24-A76EAC77D1EF@gmail.com>

That's one thing -- dunno how that did pop-up before. ;-)

But I doubt that just non-synchronised collections/maps cause this -- it would manifest differently.
Imo, it must also be a race-condition in WF.

On 27 Dec 2013, at 17:50, Anil Saldhana <Anil.Saldhana at redhat.com> wrote:

> Stefan merged the fixes recently. I guess we need a PicketBox upgrade in WF.
> 
> On 12/27/2013 06:54 AM, Ales Justin wrote:
>> I often get this error: 
>> * https://gist.github.com/alesj/8146623
>> 
>> I guess it's related to https://issues.jboss.org/browse/SECURITY-777 ?
>> 
>> Do we have a JIRA for WF as well?
>> 
>> -Ales
>> 
>  
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131227/040063d1/attachment.html 

From mpallas at gmail.com  Fri Dec 27 16:02:09 2013
From: mpallas at gmail.com (Nick Mpallas)
Date: Fri, 27 Dec 2013 22:02:09 +0100
Subject: [wildfly-dev] admin console question/resources
Message-ID: <CAFz_cFucsipUpZ9_r+bwj9Z+uqa4MsrZCdWcZ14dz3CUMWYecw@mail.gmail.com>

Hi guys,
according tot he new JMS API 2.0 you can use the @JMSDestinationDefinition
to define the queue resources you want to have. The functionality is
correct. When I deploy my module I can see it creates the resource as
expected. But when I go to the admin console interface, under the queue I
don't see this resource. Only the ones defined through the jboss-cli or
directly by editing the *.xml configuration file, will be available to be
monitored by the console? Shouldn't the console provide insights for the
other stuff also?

have fun
-- 
\n\m
"camel is a horse made up in a laboratory"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131227/ac53aa75/attachment.html 

From jgreene at redhat.com  Sat Dec 28 11:14:27 2013
From: jgreene at redhat.com (Jason Greene)
Date: Sat, 28 Dec 2013 11:14:27 -0500 (EST)
Subject: [wildfly-dev] xnio selection err
In-Reply-To: <6E3B43B9-79F8-4D47-A5C3-5675DB4CDAB8@gmail.com>
References: <3244818932206876948@unknownmsgid>
	<C1DBB6DC-A98B-4565-ACEF-622D95310704@redhat.com>
	<C9F670A0-C0A4-47F4-8629-36C2FBAC4E88@redhat.com>
	<A555DA32-13FD-47A3-B060-3061CA39790F@redhat.com>
	<6E3B43B9-79F8-4D47-A5C3-5675DB4CDAB8@gmail.com>
Message-ID: <E24431FB-EE1F-433F-A259-2966E4D05700@redhat.com>

Can you try using dtruss for kevent:

1. Start server
2. Get PID (jps)
3. sudo dtruss -f -t kevent -p PID 2> truss.log


Sent from my iPad

> On Dec 27, 2013, at 9:47 AM, Ales Justin <ales.justin at gmail.com> wrote:
> 
> Debugging org.xnio.nio.WorkerThread : 
> (with few e.printStackTrace() invocations)
> 
> https://gist.github.com/alesj/8148775
> 
>> On 27 Dec 2013, at 16:16, Jason Greene <jgreene at redhat.com> wrote:
>> 
>> BTW one possible cause is that your user has exceeded the max open files  limit, and you need to bump ulimit.
>> 
>> The reason I am interested in the stack trace though is to see which poll provider is throwing the error.
>> 
>> Sent from my iPhone
>> 
>>> On Dec 27, 2013, at 9:07 AM, Jason Greene <jgreene at redhat.com> wrote:
>>> 
>>> Oops
>>> 
>>> Sent from my iPhone
>>> 
>>>> On Dec 27, 2013, at 9:00 AM, Jason Greene <jgreene at redhat.com> wrote:
>>>> 
>>>> Any chance you can get a stack trace out of it? Upping the log level or using a debugger to catch IOException would do the trick.
>>>> 
>>>> The error means the OS is throwing EINVAL.
>>>> 
>>>> Is this a OSX Mavericks? If so can you double check you are running the latest JVM?
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>>> On Dec 27, 2013, at 8:36 AM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
>>>>> 
>>>>> Isn't that the same error that happens only on your mac also in few other cases?
>>>>> 
>>>>> Can you try on any other platform?
>>>>> 
>>>>> Sent from my Phone
>>>>> From: Ales Justin
>>>>> Sent: ?27.?12.?2013 14:14
>>>>> To: Wildfly Dev mailing list
>>>>> Subject: [wildfly-dev] xnio selection err
>>>>> 
>>>>> While using UnderTow's JSR WebSockets,
>>>>> implementing simple chat app, between 2 diff browsers (Chrome and Safari),
>>>>> I get a flood of these log lines:
>>>>> 
>>>>> 14:09:22,890 WARN  [org.xnio.nio.selector] (default I/O-3) XNIO008000: Received an I/O error on selection: java.io.IOException: Invalid argument
>>>>> 
>>>>> Any idea?
>>>>> 
>>>>> -Ales
>>>>> 
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131228/3d6e69c6/attachment.html 

From jgreene at redhat.com  Sat Dec 28 20:56:05 2013
From: jgreene at redhat.com (Jason Greene)
Date: Sat, 28 Dec 2013 20:56:05 -0500 (EST)
Subject: [wildfly-dev] app policy race
In-Reply-To: <355609B6-44C0-4348-8F24-A76EAC77D1EF@gmail.com>
References: <11D264CE-737F-46D8-A888-C44831A2EDEB@gmail.com>
	<52BDAFE6.6090009@redhat.com>
	<355609B6-44C0-4348-8F24-A76EAC77D1EF@gmail.com>
Message-ID: <508A0D77-F66E-4EE9-8CF9-F6C97FECD115@redhat.com>

It looks exactly how it would manifest. Something isn't in the map that should be, so an error is thrown.

> On Dec 27, 2013, at 1:26 PM, Ales Justin <ales.justin at gmail.com> wrote:
> 
> That's one thing -- dunno how that did pop-up before. ;-)
> 
> But I doubt that just non-synchronised collections/maps cause this -- it would manifest differently.
> Imo, it must also be a race-condition in WF.
> 
>> On 27 Dec 2013, at 17:50, Anil Saldhana <Anil.Saldhana at redhat.com> wrote:
>> 
>> Stefan merged the fixes recently. I guess we need a PicketBox upgrade in WF.
>> 
>>> On 12/27/2013 06:54 AM, Ales Justin wrote:
>>> I often get this error: 
>>> * https://gist.github.com/alesj/8146623
>>> 
>>> I guess it's related to https://issues.jboss.org/browse/SECURITY-777 ?
>>> 
>>> Do we have a JIRA for WF as well?
>>> 
>>> -Ales
>>> 
>>  
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131228/e34d4bf9/attachment.html 

From ales.justin at gmail.com  Sun Dec 29 05:53:54 2013
From: ales.justin at gmail.com (Ales Justin)
Date: Sun, 29 Dec 2013 11:53:54 +0100
Subject: [wildfly-dev] app policy race
In-Reply-To: <508A0D77-F66E-4EE9-8CF9-F6C97FECD115@redhat.com>
References: <11D264CE-737F-46D8-A888-C44831A2EDEB@gmail.com>
	<52BDAFE6.6090009@redhat.com>
	<355609B6-44C0-4348-8F24-A76EAC77D1EF@gmail.com>
	<508A0D77-F66E-4EE9-8CF9-F6C97FECD115@redhat.com>
Message-ID: <E27608D3-853A-40C3-A717-2D04A03F6B83@gmail.com>

How would proper map sync help here then?

Are you saying there is a put and get going on at the same time?
Imo, this then means WF' dependencies are not done right.

btw: when do you "corrupt" a HashMap? (wrt my diff manifestation)
With multiple concurrent puts/removes, or can it be mixture of puts/gets/removes?

> On Dec 29, 2013, at 2:56, Jason Greene <jgreene at redhat.com> wrote:
> 
> It looks exactly how it would manifest. Something isn't in the map that should be, so an error is thrown.
> 
>> On Dec 27, 2013, at 1:26 PM, Ales Justin <ales.justin at gmail.com> wrote:
>> 
>> That's one thing -- dunno how that did pop-up before. ;-)
>> 
>> But I doubt that just non-synchronised collections/maps cause this -- it would manifest differently.
>> Imo, it must also be a race-condition in WF.
>> 
>>> On 27 Dec 2013, at 17:50, Anil Saldhana <Anil.Saldhana at redhat.com> wrote:
>>> 
>>> Stefan merged the fixes recently. I guess we need a PicketBox upgrade in WF.
>>> 
>>>> On 12/27/2013 06:54 AM, Ales Justin wrote:
>>>> I often get this error: 
>>>> * https://gist.github.com/alesj/8146623
>>>> 
>>>> I guess it's related to https://issues.jboss.org/browse/SECURITY-777 ?
>>>> 
>>>> Do we have a JIRA for WF as well?
>>>> 
>>>> -Ales
>>>  
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> 
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131229/1fdb479e/attachment-0001.html 

From jgreene at redhat.com  Sun Dec 29 20:12:31 2013
From: jgreene at redhat.com (Jason Greene)
Date: Sun, 29 Dec 2013 20:12:31 -0500 (EST)
Subject: [wildfly-dev] app policy race
In-Reply-To: <E27608D3-853A-40C3-A717-2D04A03F6B83@gmail.com>
References: <11D264CE-737F-46D8-A888-C44831A2EDEB@gmail.com>
	<52BDAFE6.6090009@redhat.com>
	<355609B6-44C0-4348-8F24-A76EAC77D1EF@gmail.com>
	<508A0D77-F66E-4EE9-8CF9-F6C97FECD115@redhat.com>
	<E27608D3-853A-40C3-A717-2D04A03F6B83@gmail.com>
Message-ID: <165D07E8-CE67-4FC1-9320-FCF27C246CF3@redhat.com>

Memory visibility would be guaranteed. If there is no happens-before ordering then one thread's put is not always visible to another thread's get even if they happen in the proper order. Also corruption of the table could result in a dead table.

E.g.

1. Thread A -> put Kz
2. Other stuff
3. Thread B -> get Kz 
(Returns cached stale value, null)


Granted there could still be some ordering problem. Like we are allowing requests to get handled before the server is started.


Sent from my iPhone

> On Dec 29, 2013, at 4:54 AM, Ales Justin <ales.justin at gmail.com> wrote:
> 
> How would proper map sync help here then?
> 
> Are you saying there is a put and get going on at the same time?
> Imo, this then means WF' dependencies are not done right.
> 
> btw: when do you "corrupt" a HashMap? (wrt my diff manifestation)
> With multiple concurrent puts/removes, or can it be mixture of puts/gets/removes?
> 
>> On Dec 29, 2013, at 2:56, Jason Greene <jgreene at redhat.com> wrote:
>> 
>> It looks exactly how it would manifest. Something isn't in the map that should be, so an error is thrown.
>> 
>>> On Dec 27, 2013, at 1:26 PM, Ales Justin <ales.justin at gmail.com> wrote:
>>> 
>>> That's one thing -- dunno how that did pop-up before. ;-)
>>> 
>>> But I doubt that just non-synchronised collections/maps cause this -- it would manifest differently.
>>> Imo, it must also be a race-condition in WF.
>>> 
>>>> On 27 Dec 2013, at 17:50, Anil Saldhana <Anil.Saldhana at redhat.com> wrote:
>>>> 
>>>> Stefan merged the fixes recently. I guess we need a PicketBox upgrade in WF.
>>>> 
>>>>> On 12/27/2013 06:54 AM, Ales Justin wrote:
>>>>> I often get this error: 
>>>>> * https://gist.github.com/alesj/8146623
>>>>> 
>>>>> I guess it's related to https://issues.jboss.org/browse/SECURITY-777 ?
>>>>> 
>>>>> Do we have a JIRA for WF as well?
>>>>> 
>>>>> -Ales
>>>>  
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> 
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131229/d38e5bec/attachment.html 

From ssilvert at redhat.com  Mon Dec 30 21:17:26 2013
From: ssilvert at redhat.com (ssilvert at redhat.com)
Date: Mon, 30 Dec 2013 21:17:26 -0500
Subject: [wildfly-dev] New Year's Eve bug broke the build
Message-ID: <52C22936.2020506@redhat.com>

https://github.com/wildfly/wildfly/pull/5653

I'm not sure if this is a bug in the test or a bug in
org.jboss.as.ejb3.timerservice.schedule.CalendarBasedTimeout.  But I'm
pretty sure that the build will be working again in a few hours.

Happy New Year!

From stuart.w.douglas at gmail.com  Tue Dec 31 06:13:02 2013
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Tue, 31 Dec 2013 12:13:02 +0100
Subject: [wildfly-dev] app policy race
In-Reply-To: <E27608D3-853A-40C3-A717-2D04A03F6B83@gmail.com>
References: <11D264CE-737F-46D8-A888-C44831A2EDEB@gmail.com>
	<52BDAFE6.6090009@redhat.com>
	<355609B6-44C0-4348-8F24-A76EAC77D1EF@gmail.com>
	<508A0D77-F66E-4EE9-8CF9-F6C97FECD115@redhat.com>
	<E27608D3-853A-40C3-A717-2D04A03F6B83@gmail.com>
Message-ID: <CAAoo=c5w3naUv7vpj6zuc-u=qqjqnH_e2fHQb05ETbY7aUxNHQ@mail.gmail.com>

I think what is happening is two security domains are being started at the
same time, which results in two concurrent put() calls.

Sometimes this will result in both items being put into the same place in
the table, and one put() will essentially be lost.

Using a sync map makes this problem go away.

Stuart


On Sun, Dec 29, 2013 at 11:53 AM, Ales Justin <ales.justin at gmail.com> wrote:

> How would proper map sync help here then?
>
> Are you saying there is a put and get going on at the same time?
> Imo, this then means WF' dependencies are not done right.
>
> btw: when do you "corrupt" a HashMap? (wrt my diff manifestation)
> With multiple concurrent puts/removes, or can it be mixture of
> puts/gets/removes?
>
> On Dec 29, 2013, at 2:56, Jason Greene <jgreene at redhat.com> wrote:
>
> It looks exactly how it would manifest. Something isn't in the map that
> should be, so an error is thrown.
>
> On Dec 27, 2013, at 1:26 PM, Ales Justin <ales.justin at gmail.com> wrote:
>
> That's one thing -- dunno how that did pop-up before. ;-)
>
> But I doubt that just non-synchronised collections/maps cause this -- it
> would manifest differently.
> Imo, it must also be a race-condition in WF.
>
> On 27 Dec 2013, at 17:50, Anil Saldhana <Anil.Saldhana at redhat.com> wrote:
>
>  Stefan merged the fixes recently. I guess we need a PicketBox upgrade in
> WF.
>
> On 12/27/2013 06:54 AM, Ales Justin wrote:
>
> I often get this error:
> * https://gist.github.com/alesj/8146623
>
>  I guess it's related to https://issues.jboss.org/browse/SECURITY-777 ?
>
>  Do we have a JIRA for WF as well?
>
>  -Ales
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131231/c1ab6773/attachment.html 

From emartins at redhat.com  Tue Dec 31 09:30:59 2013
From: emartins at redhat.com (Eduardo Martins)
Date: Tue, 31 Dec 2013 14:30:59 +0000
Subject: [wildfly-dev] New Year's Eve bug broke the build
In-Reply-To: <52C22936.2020506@redhat.com>
References: <52C22936.2020506@redhat.com>
Message-ID: <9FD95B53-DC8C-4E90-9FB8-D1BB853B1A21@redhat.com>

Same at my end.

?E


On 31 Dec 2013, at 02:17, ssilvert at redhat.com wrote:

> https://github.com/wildfly/wildfly/pull/5653
> 
> I'm not sure if this is a bug in the test or a bug in
> org.jboss.as.ejb3.timerservice.schedule.CalendarBasedTimeout.  But I'm
> pretty sure that the build will be working again in a few hours.
> 
> Happy New Year!
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



From emartins at redhat.com  Tue Dec 31 09:34:58 2013
From: emartins at redhat.com (Eduardo Martins)
Date: Tue, 31 Dec 2013 14:34:58 +0000
Subject: [wildfly-dev] New Year's Eve bug broke the build
In-Reply-To: <9FD95B53-DC8C-4E90-9FB8-D1BB853B1A21@redhat.com>
References: <52C22936.2020506@redhat.com>
	<9FD95B53-DC8C-4E90-9FB8-D1BB853B1A21@redhat.com>
Message-ID: <69FED65C-661D-4390-A290-111DAD45958F@redhat.com>

Yet this already shown up yesterday, so not sure it?s due to new year, is anyone looking at it please reply, otherwise I will have a look at it.

?E

On 31 Dec 2013, at 14:30, Eduardo Martins <emartins at redhat.com> wrote:

> Same at my end.
> 
> ?E
> 
> 
> On 31 Dec 2013, at 02:17, ssilvert at redhat.com wrote:
> 
>> https://github.com/wildfly/wildfly/pull/5653
>> 
>> I'm not sure if this is a bug in the test or a bug in
>> org.jboss.as.ejb3.timerservice.schedule.CalendarBasedTimeout.  But I'm
>> pretty sure that the build will be working again in a few hours.
>> 
>> Happy New Year!
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



From cfang at redhat.com  Tue Dec 31 10:02:04 2013
From: cfang at redhat.com (Cheng Fang)
Date: Tue, 31 Dec 2013 10:02:04 -0500
Subject: [wildfly-dev] New Year's Eve bug broke the build
In-Reply-To: <69FED65C-661D-4390-A290-111DAD45958F@redhat.com>
References: <52C22936.2020506@redhat.com>	<9FD95B53-DC8C-4E90-9FB8-D1BB853B1A21@redhat.com>
	<69FED65C-661D-4390-A290-111DAD45958F@redhat.com>
Message-ID: <52C2DC6C.3030004@redhat.com>

Looks similar to https://issues.jboss.org/browse/JBCTS-1253 (ejb3 timer 
failures at end of month) on a yearly scale.

Cheng

On 12/31/13, 9:34 AM, Eduardo Martins wrote:
> Yet this already shown up yesterday, so not sure it?s due to new year, is anyone looking at it please reply, otherwise I will have a look at it.
>
> ?E
>
> On 31 Dec 2013, at 14:30, Eduardo Martins <emartins at redhat.com> wrote:
>
>> Same at my end.
>>
>> ?E
>>
>>
>> On 31 Dec 2013, at 02:17, ssilvert at redhat.com wrote:
>>
>>> https://github.com/wildfly/wildfly/pull/5653
>>>
>>> I'm not sure if this is a bug in the test or a bug in
>>> org.jboss.as.ejb3.timerservice.schedule.CalendarBasedTimeout.  But I'm
>>> pretty sure that the build will be working again in a few hours.
>>>
>>> Happy New Year!
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From emartins at redhat.com  Tue Dec 31 10:14:35 2013
From: emartins at redhat.com (Eduardo Martins)
Date: Tue, 31 Dec 2013 15:14:35 +0000
Subject: [wildfly-dev] New Year's Eve bug broke the build
In-Reply-To: <52C2DC6C.3030004@redhat.com>
References: <52C22936.2020506@redhat.com>	<9FD95B53-DC8C-4E90-9FB8-D1BB853B1A21@redhat.com>
	<69FED65C-661D-4390-A290-111DAD45958F@redhat.com>
	<52C2DC6C.3030004@redhat.com>
Message-ID: <C9E6C9D7-AA70-4A6E-9925-349EADE70308@redhat.com>

Will you work on it? If not please let me know and I will take over.

?E

On 31 Dec 2013, at 15:02, Cheng Fang <cfang at redhat.com> wrote:

> Looks similar to https://issues.jboss.org/browse/JBCTS-1253 (ejb3 timer 
> failures at end of month) on a yearly scale.
> 
> Cheng
> 
> On 12/31/13, 9:34 AM, Eduardo Martins wrote:
>> Yet this already shown up yesterday, so not sure it?s due to new year, is anyone looking at it please reply, otherwise I will have a look at it.
>> 
>> ?E
>> 
>> On 31 Dec 2013, at 14:30, Eduardo Martins <emartins at redhat.com> wrote:
>> 
>>> Same at my end.
>>> 
>>> ?E
>>> 
>>> 
>>> On 31 Dec 2013, at 02:17, ssilvert at redhat.com wrote:
>>> 
>>>> https://github.com/wildfly/wildfly/pull/5653
>>>> 
>>>> I'm not sure if this is a bug in the test or a bug in
>>>> org.jboss.as.ejb3.timerservice.schedule.CalendarBasedTimeout.  But I'm
>>>> pretty sure that the build will be working again in a few hours.
>>>> 
>>>> Happy New Year!
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> 
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> 
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



From cfang at redhat.com  Tue Dec 31 10:46:57 2013
From: cfang at redhat.com (Cheng Fang)
Date: Tue, 31 Dec 2013 10:46:57 -0500
Subject: [wildfly-dev] New Year's Eve bug broke the build
In-Reply-To: <C9E6C9D7-AA70-4A6E-9925-349EADE70308@redhat.com>
References: <52C22936.2020506@redhat.com>	<9FD95B53-DC8C-4E90-9FB8-D1BB853B1A21@redhat.com>
	<69FED65C-661D-4390-A290-111DAD45958F@redhat.com>
	<52C2DC6C.3030004@redhat.com>
	<C9E6C9D7-AA70-4A6E-9925-349EADE70308@redhat.com>
Message-ID: <52C2E6F1.20404@redhat.com>

Feel free to tackle it.

Cheng

On 12/31/13, 10:14 AM, Eduardo Martins wrote:
> Will you work on it? If not please let me know and I will take over.
>
> ?E
>
> On 31 Dec 2013, at 15:02, Cheng Fang <cfang at redhat.com> wrote:
>
>> Looks similar to https://issues.jboss.org/browse/JBCTS-1253 (ejb3 timer
>> failures at end of month) on a yearly scale.
>>
>> Cheng
>>
>> On 12/31/13, 9:34 AM, Eduardo Martins wrote:
>>> Yet this already shown up yesterday, so not sure it?s due to new year, is anyone looking at it please reply, otherwise I will have a look at it.
>>>
>>> ?E
>>>
>>> On 31 Dec 2013, at 14:30, Eduardo Martins <emartins at redhat.com> wrote:
>>>
>>>> Same at my end.
>>>>
>>>> ?E
>>>>
>>>>
>>>> On 31 Dec 2013, at 02:17, ssilvert at redhat.com wrote:
>>>>
>>>>> https://github.com/wildfly/wildfly/pull/5653
>>>>>
>>>>> I'm not sure if this is a bug in the test or a bug in
>>>>> org.jboss.as.ejb3.timerservice.schedule.CalendarBasedTimeout.  But I'm
>>>>> pretty sure that the build will be working again in a few hours.
>>>>>
>>>>> Happy New Year!
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From ssilvert at redhat.com  Tue Dec 31 12:49:41 2013
From: ssilvert at redhat.com (ssilvert at redhat.com)
Date: Tue, 31 Dec 2013 12:49:41 -0500
Subject: [wildfly-dev] New Year's Eve bug broke the build
In-Reply-To: <69FED65C-661D-4390-A290-111DAD45958F@redhat.com>
References: <52C22936.2020506@redhat.com>
	<9FD95B53-DC8C-4E90-9FB8-D1BB853B1A21@redhat.com>
	<69FED65C-661D-4390-A290-111DAD45958F@redhat.com>
Message-ID: <52C303B5.8010108@redhat.com>

On 12/31/2013 9:34 AM, Eduardo Martins wrote:
> Yet this already shown up yesterday, so not sure it?s due to new year, is anyone looking at it please reply, otherwise I will have a look at it.
It showed up yesterday, but this test goes through and tests all the
time zones in the world based on the return value of
TimeZone.getAvailableIDs(). 

So wherever it happened to be just past midnight on December 31st the
test would fail.  I saw it fail on "Greenwich Mean Time" then in the
next hour it started failing on "Eastern Greenland Time", then after an
hour it failed on "Brasilia Time" and so on.

Now that it is well past midnight, Dec. 31st everywhere in the world, it
always fails on the time zone named "531 GMT-12:00".  At least that's
what I've seen on my box.
>
> ?E
>
> On 31 Dec 2013, at 14:30, Eduardo Martins <emartins at redhat.com> wrote:
>
>> Same at my end.
>>
>> ?E
>>
>>
>> On 31 Dec 2013, at 02:17, ssilvert at redhat.com wrote:
>>
>>> https://github.com/wildfly/wildfly/pull/5653
>>>
>>> I'm not sure if this is a bug in the test or a bug in
>>> org.jboss.as.ejb3.timerservice.schedule.CalendarBasedTimeout.  But I'm
>>> pretty sure that the build will be working again in a few hours.
>>>
>>> Happy New Year!
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev