Not sure I agree with your perspective on this anymore. JPA is
something that does not require Wildfly to run. You can use it in
library/resource-locale mode if desired. WTF do we have JBoss Modules
if we can't use it to scope services exactly like this?
The integration with JPA is complex in that it needs to do scanning of classes, reflective
analysis, annotation analysis, bytecode generation, etc. The SE implementations assume all
kinds of things like you can just go back and forth between Files and Jar URLs to do the
scanning bit. You also need multiple class loaders in this very ugly stupid SPI so that
various implementations can load the classes analyze them, then throw them away generate
new classes and get those reloaded in a new class loader.
JBoss modules itself doesn't currently provide a traversal API, mainly because the
intention was not to preclude sources that do not have one (network etc). That can be made
unnecessary by hardcoding the classnames in persistence.xml and/or using jandex indexes.
Although even if you do all of that you end up duplicating a lot of aspects of the
deployment chains. Now of course *everything* could be a deployment but then if everything
was a deployment server start would be much much slower. Even just JPA by itself can have
initialization time that doubles server startup, and when everyone is doing it we could
easily be several times slower.
There are other issues as well, like someone implements something that is tied to
hibernate (pretty easy to do) or a specific version of hibernate.
So, you're also saying that if I have an auth service that uses Resteasy
client, I can't use Resteasy client because it is a subsystem we ship with?
It depends on what dependency requirements we want to have. I mean the question really
should be should the auth service pull in resteasy and everything it depends on? Maybe
thats ok. I'd argue that a core authentication infrastructure we are using, like
picket link, should support all potential configurations of WildFly, including perhaps
servlet only, or maybe even just a web proxy with no servlet, or maybe some new non -EE
api framework set like Play or some ruby thing. If it's a core reusable service we
should ensure that it can be properly shared.
As far as the IDM API goes, I'm already worried it is turning into a
Federated JDO project rather than an IDM API.
Not being able to use JPA
will require it to re-implement a lot of the features JPA has:
session/transaction management, connection pooling, 1st/2nd level
caching etc…
If we look at this use case, its simply persisting and loading a token. To me it's
overkill to pull in JPA for that. I could see some use cases with very complex relational
designs that maybe motivates you, but even then it really should be balanced with what the
overall architecture is going to look like.
So if we just need to share things like transactions and connection pooling it would make
much more sense to split out those areas. We could for example look at can ironjacamar
provide a tiny module that doesn't require all of RAR support to do connection
pooling. Transactions is already small enough with just JTA, and naryana also has a new
small core API.
Second level cache is something I am not sure matched up nicely with at least the IDM
case. I mean the IDM already does caching, and using a second level cache is just
duplicative.
Anyway my key point is that I think we sometimes look at problems from an application
developers perspective, as in whats the easiest way to solve the problem I need to solve
from that very specific perspective vs really looking at what the whole system integration
feels like. Those really need to be balanced.
On 8/5/2013 4:13 PM, Jason Greene wrote:
> OK. The first guideline is that if you are implementing a service on WildFly, you
need to remove any assumption on Java EE. Just because WildFly currently ships as a full
Java EE full profile container today does not mean it will not one day ship different
options, like a tiny non-Java EE platform. It could even be possible that we would ship
multiple selectable versions of Java EE (or subsets) on the same underlying platform.
Intra-service dependencies should be as rare as possible. This also brings in lots of
other benefits like removing complexity, and improving performance (in particular boot)
and memory foot print usage.
>
> So in this particular example STS should be using JDBC and not JPA for a DB
persistence feature.
>
> That said if it were to be done (hopefully temporarily), the right way to do it
(assuming we are talking a server wide scenario) would be to split the JPA feature into
its own separate plugin with its own separate module. It would then need a mechanism to
load the plugin, perhaps by referencing the module name in a configuration file. The JPA
bootstrap itself assumes a Java EE context is using it, so it probably would need to use a
special JPA integration API to obtain an EM. Those API enhancements would have to be
capable of taking in a list of classnames and a classloader for the entities and likely
also a prerun jandex index for the module containing the entities.
>
> On Aug 5, 2013, at 2:26 PM, Anil Saldhana <Anil.Saldhana(a)redhat.com> wrote:
>
>> Hi Jason,
>> this thread is not related to the JPA/IDM support we discussed in the
>> sec-dev mailing list.
>>
>> The functionality that this thread is discussing is the presence of a
>> token registry in PicketLink that serializes token identifiers to a file
>> by default. Optionally, you can use a DB via JPA to store the tokens.
>> Enterprise users may want to use a db to manage the tokens.
>>
>> I do agree on your concern about JPA usage.
>>
>> We are looking at guidance from the WF team on managing the module
>> dependencies. I hope the team can come up with some guidelines for the
>> projects integrating.
>>
>> Regards,
>> Anil
>>
>> On 08/05/2013 02:05 PM, Jason Greene wrote:
>>> You can add this to the stack of examples of why JPA support in an IDM is
just a bad idea. If this must be done though then it needs to be properly modularized. The
last this was discussed on security-dev, this was supposedly an individual app feature, to
integrate with a users application code from their direct entity model, and not a global
application server usage. If that is indeed the case, then we need to identify exactly how
a user consumes and expands upon these classes.
>>>
>>> On Aug 5, 2013, at 10:07 AM, Scott Marlow <smarlow(a)redhat.com> wrote:
>>>
>>>> On 08/05/2013 10:32 AM, Anil Saldhana wrote:
>>>>> Resend.
>>>>>
>>>>> On 08/01/2013 01:04 PM, Anil Saldhana wrote:
>>>>>> Options 3 and 4 are not suitable. I wonder how this issue has
not
>>>>>> manifested in other subsystems using JPA?
>>>> I think that SwitchYard is another module that depends on a non-EE JPA
>>>> bootstrap of Hibernate. SwitchYard isn't integrated into the WildFly
8
>>>> core (I think its integrated as a layered project). SwitchYard is
>>>> likely also depending on the Hibernate/Javassist modules. I expect that
>>>> SwitchYard probably also has a dependency on the (global) JPAService
>>>>
>>>> I should of listed option 5 below, which is to add the
>>>> Hibernate/Javassist dependencies to the PicketLink module which was
>>>> previously rejected on the pull request.
>>>>
>>>>>> Should we fix/adapt the PicketLink JPA Registry usage of
>>>>>> EntityManagerFactory such that we do not need
hibernate/javassist
>>>>>> module dependencies? Guidance appreciated.
>>>> Is the PicketLink JPA Registry of EntityManagerFactory's shared
across
>>>> multiple application deployments?
>>>>
>>>>>> On 07/26/2013 07:53 AM, Fernando Ribeiro wrote:
>>>>>>> Option 4 can be rephrased to "removing the JPA-based
registries from
>>>>>>> the code and delivering them instead as quickstarts",
which is good,
>>>>>>> though it will impact current users/subscribers. Regards.
>>>>>>>
>>>>>>> On Jul 26, 2013 7:51 AM, "Scott Marlow"
<smarlow(a)redhat.com
>>>>>>> <mailto:smarlow@redhat.com>> wrote:
>>>>>>>
>>>>>>> Turns out that using the org.hibernate.annotations.Proxy
>>>>>>> annotation is currently the only workaround:
>>>>>>>
>>>>>>> @Entity @Proxy(lazy=false) public class SecurityToken
>>>>>>>
>>>>>>> However, that requires changing the PicketLink module to
add a
>>>>>>> dependency on the Hibernate module.
>>>>>>>
>>>>>>> Options for addressing this issue are:
>>>>>>>
>>>>>>> 1. Someone contributes a patch to Hibernate to change
bytecode
>>>>>>> enhancing to not require Hibernate/Javassist on the
classpath.
>>>>>>> Not sure when this might happen or if it will happen.
>>>>>>>
>>>>>>> 2. Add the javassist jar to the WildFly org.hibernate
static
>>>>>>> module so that only the Hibernate module needs to be on
the
>>>>>>> PicketLink module classpath (which we would add to the
PicketLink
>>>>>>> module).
>>>>>>>
>>>>>>> 3. Change PicketLink to directly depend on Hibernate and
make
>>>>>>> code changes to avoid lazy loading. The PicketLink module
is
>>>>>>> changed to depend on Hibernate.
>>>>>>>
>>>>>>> 4. Change PicketLink to not directly use JPA, but
instead
>>>>>>> delegate to the application for access to a persistence
store
>>>>>>> (let the application use EE JPA container managed access
if it
>>>>>>> desires).
>>>>>>>
>>>>>>> Scott
>>>>>>>
>>>>>>> On 07/25/2013 11:24 AM, Scott Marlow wrote:
>>>>>>>
>>>>>>> Fernando, could you try updating the SecurityToken
entity from:
>>>>>>>
>>>>>>> @Lob
>>>>>>> private byte[] token;
>>>>>>>
>>>>>>> To:
>>>>>>>
>>>>>>> @Lob @Basic(fetch=LAZY)
>>>>>>> private byte[] token;
>>>>>>>
>>>>>>> And see if that helps, just to see if we can avoid
adding the
>>>>>>> hibernate/javassist dependencies if we want.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 07/25/2013 11:16 AM, Scott Marlow wrote:
>>>>>>>
>>>>>>> From private email, I now have the server.log
that
>>>>>>> contains the full
>>>>>>> call stacks.
http://pastebin.com/dpUG5NFA is the
first one.
>>>>>>>
>>>>>>> It looks like in AbstractEntityTuplizer ctor, we
are
>>>>>>> using Javassist to
>>>>>>> generate a lazy proxy:
>>>>>>>
>>>>>>> if ( entityMetamodel.isLazy() ) {
>>>>>>> proxyFactory = buildProxyFactory( mappingInfo,
>>>>>>> idGetter, idSetter );
>>>>>>> if (proxyFactory == null) {
>>>>>>> entityMetamodel.setLazy( false );
>>>>>>> }
>>>>>>> }
>>>>>>> else {
>>>>>>> proxyFactory = null;
>>>>>>> }
>>>>>>>
>>>>>>> I must be missing something as I don't see
what is being
>>>>>>> "lazy" loaded
>>>>>>> for
>>>>>>>
org.picketlink.identity.federation.core.sts.registry.SecurityToken.
>>>>>>>
>>>>>>> We either need to avoid lazy loading or include
the
>>>>>>> Hibernate/Javassist
>>>>>>> dependencies in PicketLink.
>>>>>>>
>>>>>>> On 07/24/2013 10:26 PM, Scott Marlow wrote:
>>>>>>>
>>>>>>> On 07/24/2013 09:56 PM, Fernando Ribeiro
wrote:
>>>>>>>
>>>>>>> Scott,
>>>>>>>
>>>>>>> Here are the stack traces.
>>>>>>>
>>>>>>> ** Original Descriptor **
>>>>>>>
>>>>>>>
>>>>>>> This first one should be resolved by
PicketLink
>>>>>>> (org.picketlink module)
>>>>>>> adding a dependency on the
javax.persistence.api module.
>>>>>>>
>>>>>>> For the other two, I need more context.
>>>>>>>
>>>>>>> [Server:server-one] Caused by:
>>>>>>> java.lang.ClassNotFoundException:
>>>>>>> javax.persistence.Persistence from
[Module
>>>>>>> "org.picketlink:main" from
>>>>>>> local module loader @509f5011 (roots:
>>>>>>> /opt/jboss-eap-6.0/modules)]
>>>>>>> [Server:server-one] at
>>>>>>>
org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
>>>>>>>
>>>>>>> [Server:server-one] at
>>>>>>>
org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
>>>>>>>
>>>>>>> [Server:server-one] at
>>>>>>>
org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
>>>>>>>
>>>>>>> [Server:server-one] at
>>>>>>>
org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:423)
>>>>>>>
>>>>>>> [Server:server-one] at
>>>>>>>
org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
>>>>>>>
>>>>>>> [Server:server-one] at
>>>>>>>
org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
>>>>>>>
>>>>>>> [Server:server-one] ... 24 more
>>>>>>>
>>>>>>> ** Descriptor w/ the JPA API **
>>>>>>>
>>>>>>> [Server:server-one] Caused by:
>>>>>>> java.lang.ClassNotFoundException:
>>>>>>> org.hibernate.proxy.HibernateProxy from
[Module
>>>>>>> "org.picketlink:main"
>>>>>>> from local module loader @3b835282
(roots:
>>>>>>> /opt/jboss-eap-6.0/modules)]
>>>>>>> [Server:server-one] at
>>>>>>>
org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
>>>>>>>
>>>>>>> [Server:server-one] at
>>>>>>>
org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
>>>>>>>
>>>>>>> [Server:server-one] at
>>>>>>>
org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
>>>>>>>
>>>>>>> [Server:server-one] at
>>>>>>>
org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:423)
>>>>>>>
>>>>>>> [Server:server-one] at
>>>>>>>
org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
>>>>>>>
>>>>>>> [Server:server-one] at
>>>>>>>
org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
>>>>>>>
>>>>>>> [Server:server-one] ... 64 more
>>>>>>>
>>>>>>> ** Descriptor w/ Hibernate **
>>>>>>>
>>>>>>> [Server:server-one] Caused by:
>>>>>>> java.lang.ClassNotFoundException:
>>>>>>> javassist.util.proxy.ProxyObject from
[Module
>>>>>>> "org.picketlink:main" from
>>>>>>> local module loader @67d225a7 (roots:
>>>>>>> /opt/jboss-eap-6.0/modules)]
>>>>>>> [Server:server-one] at
>>>>>>>
org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
>>>>>>>
>>>>>>> [Server:server-one] at
>>>>>>>
org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
>>>>>>>
>>>>>>> [Server:server-one] at
>>>>>>>
org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
>>>>>>>
>>>>>>> [Server:server-one] at
>>>>>>>
org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:423)
>>>>>>>
>>>>>>> [Server:server-one] at
>>>>>>>
org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
>>>>>>>
>>>>>>> [Server:server-one] at
>>>>>>>
org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
>>>>>>>
>>>>>>> [Server:server-one] ... 64 more
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> On Wed, Jul 24, 2013 at 10:22 PM, Scott
Marlow
>>>>>>> <smarlow(a)redhat.com
<mailto:smarlow@redhat.com>
>>>>>>> <mailto:smarlow@redhat.com
>>>>>>> <mailto:smarlow@redhat.com>>>
wrote:
>>>>>>>
>>>>>>> On 07/24/2013 06:23 PM, Fernando
Ribeiro wrote:
>>>>>>>
>>>>>>> I guess that is the
AbstractJPARegistry
>>>>>>> class referred to in my
>>>>>>> previous
>>>>>>> message, right?
>>>>>>>
>>>>>>>
>>>>>>> Thanks, answering my current
questions in
>>>>>>> the past is awesome! I
>>>>>>> don't see anything references
that should
>>>>>>> need Hibernate or
>>>>>>> Javassist in AbstractJPARegistry.
>>>>>>>
>>>>>>> Could you try removing the
PicketLink
>>>>>>> module dependency on the
>>>>>>> Hibernate and Javassist modules and
show me
>>>>>>> the full exception call
>>>>>>> stack that you get as a result of
doing that?
>>>>>>>
>>>>>>>
>>>>>>> On Jul 24, 2013 6:42 PM,
"Scott Marlow"
>>>>>>> <smarlow(a)redhat.com
<mailto:smarlow@redhat.com>
>>>>>>> <mailto:smarlow@redhat.com
>>>>>>> <mailto:smarlow@redhat.com>>
>>>>>>> <mailto:smarlow@redhat.com
>>>>>>> <mailto:smarlow@redhat.com>
>>>>>>> <mailto:smarlow@redhat.com
>>>>>>>
<mailto:smarlow@redhat.com>>>> wrote:
>>>>>>>
>>>>>>> Can you give me a link to
the
>>>>>>> PicketLink code that does
>>>>>>> the
>>>>>>> bootstrap? I'd like to
see why you
>>>>>>> need to reference
>>>>>>> Hibernate directly.
>>>>>>>
>>>>>>> As long as the JPA
subsystem
>>>>>>> JPAExtension.initialize() has
>>>>>>> run, the
>>>>>>> default persistence
provider
>>>>>>> (Hibernate) will be
>>>>>>> available to
>>>>>>>
>>>>>>>
>>>>>>>
javax.persistence.Persistence.____createEntityManagerFactory()__.
>>>>>>>
>>>>>>>
>>>>>>> On 07/24/2013 03:39 PM,
Fernando
>>>>>>> Ribeiro wrote:
>>>>>>>
>>>>>>> Scott,
>>>>>>>
>>>>>>> PicketLink doesn't
use any
>>>>>>> Hibernate extensions, and
>>>>>>> users are
>>>>>>> expected
>>>>>>> to provide a
persistence unit
>>>>>>> called "picketlink-sts"
>>>>>>> in their
>>>>>>> applications.
>>>>>>>
>>>>>>> Regarding the
bootstraping of
>>>>>>> the persistence unit,
>>>>>>> you
>>>>>>> guessed
>>>>>>> right [1].
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> --
>>>>>>> Fernando
>>>>>>>
>>>>>>> [1]
>>>>>>>
>>>>>>>
https://github.com/picketlink/____picketlink/blob/____277c5b8ec9b6eee5dcd...
>>>>>>>
>>>>>>>
>>>>>>>
<
https://github.com/picketlink/__picketlink/blob/__277c5b8ec9b6eee5dcd3642...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
<
https://github.com/__picketlink/picketlink/blob/__277c5b8ec9b6eee5dcd3642...
>>>>>>>
>>>>>>>
>>>>>>>
<
https://github.com/picketlink/picketlink/blob/277c5b8ec9b6eee5dcd36422763...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> r
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Jul 24, 2013 at
4:17
>>>>>>> PM, Scott Marlow
>>>>>>> <smarlow(a)redhat.com
>>>>>>> <mailto:smarlow@redhat.com>
>>>>>>> <mailto:smarlow@redhat.com
>>>>>>> <mailto:smarlow@redhat.com>>
>>>>>>> <mailto:smarlow@redhat.com
>>>>>>> <mailto:smarlow@redhat.com>
>>>>>>> <mailto:smarlow@redhat.com
>>>>>>> <mailto:smarlow@redhat.com>>>
>>>>>>>
<mailto:smarlow@redhat.com
>>>>>>> <mailto:smarlow@redhat.com>
>>>>>>> <mailto:smarlow@redhat.com
>>>>>>> <mailto:smarlow@redhat.com>>
>>>>>>> <mailto:smarlow@redhat.com
>>>>>>> <mailto:smarlow@redhat.com>
>>>>>>> <mailto:smarlow@redhat.com
>>>>>>>
<mailto:smarlow@redhat.com>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>> How does PickLink
>>>>>>> bootstrap the persistence unit
>>>>>>> mentioned
>>>>>>> in [5] +
>>>>>>> [6]? I assume not
via EE
>>>>>>> JPA container managed
>>>>>>> deployment.
>>>>>>> I'm
>>>>>>> guessing via
direct calls to
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
javax.persistence.Persistence.________createEntityManagerFactory("______picketlink-sts").
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Does PicketLink
use any
>>>>>>> Hibernate extensions? Or
>>>>>>> just the
>>>>>>> JPA api?
>>>>>>>
>>>>>>> Do we have a more
>>>>>>> complete example than
>>>>>>> [5]+[6], that
>>>>>>> include how
>>>>>>> users are expected
to
>>>>>>> supply datasource/database
>>>>>>> configuration.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 07/24/2013
02:34 PM,
>>>>>>> Fernando Ribeiro wrote:
>>>>>>>
>>>>>>> The issue is
the
>>>>>>> PicketLink module
>>>>>>> depending on a
>>>>>>> specific JPA
>>>>>>>
implementation, which
>>>>>>> is not really
>>>>>>> desirable, and
>>>>>>> currently looks
>>>>>>> unavoidable.
Regards.
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Jul
24, 2013
>>>>>>> at 11:55 AM, Jaikiran
>>>>>>> Pai
>>>>>>> <jpai(a)redhat.com
>>>>>>> <mailto:jpai@redhat.com>
<mailto:jpai@redhat.com
>>>>>>> <mailto:jpai@redhat.com>>
>>>>>>> <mailto:jpai@redhat.com
>>>>>>> <mailto:jpai@redhat.com>
<mailto:jpai@redhat.com
>>>>>>> <mailto:jpai@redhat.com>>>
>>>>>>>
>>>>>>> <mailto:jpai@redhat.com
<mailto:jpai@redhat.com>
>>>>>>> <mailto:jpai@redhat.com
>>>>>>> <mailto:jpai@redhat.com>>
<mailto:jpai@redhat.com
>>>>>>> <mailto:jpai@redhat.com>
>>>>>>> <mailto:jpai@redhat.com
>>>>>>>
<mailto:jpai@redhat.com>>>>
>>>>>>>
>>>>>>> <mailto:jpai@redhat.com
<mailto:jpai@redhat.com>
>>>>>>> <mailto:jpai@redhat.com
>>>>>>> <mailto:jpai@redhat.com>>
<mailto:jpai@redhat.com
>>>>>>> <mailto:jpai@redhat.com>
>>>>>>> <mailto:jpai@redhat.com
>>>>>>> <mailto:jpai@redhat.com>>>
>>>>>>>
<mailto:jpai@redhat.com
>>>>>>> <mailto:jpai@redhat.com>
<mailto:jpai@redhat.com
>>>>>>> <mailto:jpai@redhat.com>>
>>>>>>> <mailto:jpai@redhat.com
>>>>>>> <mailto:jpai@redhat.com>
<mailto:jpai@redhat.com
>>>>>>>
<mailto:jpai@redhat.com>>>>>> wrote:
>>>>>>>
>>>>>>> Fernando
>>>>>>> actually proposed a fix
>>>>>>> which we
>>>>>>> wanted to be
>>>>>>> discussed here
in
>>>>>>> the
mailing list
>>>>>>> since the fix didn't
>>>>>>> look right
>>>>>>> for a core
>>>>>>> component
>>>>>>> like
PicketLink.
>>>>>>> The PR (which we
>>>>>>> closed)
>>>>>>> is here
>>>>>>>
https://github.com/wildfly/______wildfly/issues/4786
>>>>>>>
>>>>>>>
<
https://github.com/wildfly/____wildfly/issues/4786>
>>>>>>>
>>>>>>>
<
https://github.com/wildfly/____wildfly/issues/4786
>>>>>>>
>>>>>>>
<
https://github.com/wildfly/__wildfly/issues/4786>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
<
https://github.com/wildfly/____wildfly/issues/4786
>>>>>>>
>>>>>>>
<
https://github.com/wildfly/__wildfly/issues/4786>
>>>>>>>
>>>>>>>
<
https://github.com/wildfly/__wildfly/issues/4786
>>>>>>>
>>>>>>>
<
https://github.com/wildfly/wildfly/issues/4786>>>
>>>>>>>
>>>>>>>
-Jaikiran
>>>>>>> On
Wednesday 24
>>>>>>> July 2013 08:22 PM,
>>>>>>> Darran
>>>>>>> Lofthouse wrote:
>>>>>>>> On 24/07/13
>>>>>>> 15:46, Fernando
>>>>>>> Ribeiro wrote:
>>>>>>>>> All,
>>>>>>>>>
>>>>>>>>> There is an
>>>>>>> issue in PicketLink
>>>>>>> [1] that
>>>>>>> requires the
>>>>>>> module
>>>>>>>
descriptor
>>>>>>>>> in WildFly
>>>>>>> to depend on
>>>>>>> "org.hibernate" and
>>>>>>>
"org.javassist" to
>>>>>>> support
>>>>>>>>> two
>>>>>>> components called
>>>>>>>
"JPABasedTokenRegistry"
>>>>>>> [2] and
>>>>>>> "JPABasedRevocationRegistry"
[3].
>>>>>>>>> How would
>>>>>>> you suggest this issue to
>>>>>>> be fixed?
>>>>>>>> If you
>>>>>>> already have the proposed
>>>>>>> fix I
>>>>>>> would
>>>>>>> suggest
>>>>>>> sending over
>>>>>>> a pull
>>>>>>>> request.
>>>>>>>>
>>>>>>>>
>>>>>>>
https://community.jboss.org/______wiki/HackingOnWildFly
>>>>>>>
>>>>>>>
<
https://community.jboss.org/____wiki/HackingOnWildFly>
>>>>>>>
>>>>>>>
<
https://community.jboss.org/____wiki/HackingOnWildFly
>>>>>>>
>>>>>>>
<
https://community.jboss.org/__wiki/HackingOnWildFly>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
<
https://community.jboss.org/____wiki/HackingOnWildFly
>>>>>>>
>>>>>>>
<
https://community.jboss.org/__wiki/HackingOnWildFly>
>>>>>>>
>>>>>>>
<
https://community.jboss.org/__wiki/HackingOnWildFly
>>>>>>>
>>>>>>>
<
https://community.jboss.org/wiki/HackingOnWildFly>>>
>>>>>>>> If you are an
>>>>>>> EAP customer I would
>>>>>>> suggest
>>>>>>> opening a
>>>>>>> support case
so
>>>>>>>> that the
>>>>>>> support team can request the
>>>>>>> fix is
>>>>>>> included in
>>>>>>> EAP.
>>>>>>>>> The issue
>>>>>>> has also been logged in
>>>>>>> WildFly
>>>>>>> already [4].
>>>>>>> There are
>>>>>>> samples
>>>>>>>>> of the JPA
>>>>>>> registries available
>>>>>>> in my
>>>>>>> blog [5][6].
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Fernando
>>>>>>>>>
>>>>>>>>> [1]
>>>>>>>
https://issues.jboss.org/______browse/PLINK2-97
>>>>>>>
>>>>>>>
<
https://issues.jboss.org/____browse/PLINK2-97>
>>>>>>>
>>>>>>>
<
https://issues.jboss.org/____browse/PLINK2-97
>>>>>>>
>>>>>>>
<
https://issues.jboss.org/__browse/PLINK2-97>>
>>>>>>>
>>>>>>>
>>>>>>>
<
https://issues.jboss.org/____browse/PLINK2-97
>>>>>>>
>>>>>>>
<
https://issues.jboss.org/__browse/PLINK2-97>
>>>>>>>
>>>>>>>
<
https://issues.jboss.org/__browse/PLINK2-97
>>>>>>>
>>>>>>>
<
https://issues.jboss.org/browse/PLINK2-97>>>
>>>>>>>>> [2]
>>>>>>>>>
>>>>>>>
https://access.redhat.com/______site/documentation/en-US/______JBoss_Ente...
>>>>>>>
>>>>>>>
>>>>>>>
<
https://access.redhat.com/____site/documentation/en-US/____JBoss_Enterpri...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
<
https://access.redhat.com/____site/documentation/en-US/____JBoss_Enterpri...
>>>>>>>
>>>>>>>
>>>>>>>
<
https://access.redhat.com/__site/documentation/en-US/__JBoss_Enterprise_A...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
<
https://access.redhat.com/____site/documentation/en-US/____JBoss_Enterpri...
>>>>>>>
>>>>>>>
>>>>>>>
<
https://access.redhat.com/__site/documentation/en-US/__JBoss_Enterprise_A...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
<
https://access.redhat.com/__site/documentation/en-US/__JBoss_Enterprise_A...
>>>>>>>
>>>>>>>
>>>>>>>
<
https://access.redhat.com/site/documentation/en-US/JBoss_Enterprise_Appli...
>>>>>>>
>>>>>>>>> [3]
>>>>>>>>>
>>>>>>>
https://access.redhat.com/______site/documentation/en-US/______JBoss_Ente...
>>>>>>>
>>>>>>>
>>>>>>>
<
https://access.redhat.com/____site/documentation/en-US/____JBoss_Enterpri...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
<
https://access.redhat.com/____site/documentation/en-US/____JBoss_Enterpri...
>>>>>>>
>>>>>>>
>>>>>>>
<
https://access.redhat.com/__site/documentation/en-US/__JBoss_Enterprise_A...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
<
https://access.redhat.com/____site/documentation/en-US/____JBoss_Enterpri...
>>>>>>>
>>>>>>>
>>>>>>>
<
https://access.redhat.com/__site/documentation/en-US/__JBoss_Enterprise_A...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
<
https://access.redhat.com/__site/documentation/en-US/__JBoss_Enterprise_A...
>>>>>>>
>>>>>>>
>>>>>>>
<
https://access.redhat.com/site/documentation/en-US/JBoss_Enterprise_Appli...
>>>>>>>
>>>>>>>>> [4]
>>>>>>>
https://issues.jboss.org/______browse/WFLY-1691
>>>>>>>
>>>>>>>
<
https://issues.jboss.org/____browse/WFLY-1691>
>>>>>>>
>>>>>>>
<
https://issues.jboss.org/____browse/WFLY-1691
>>>>>>>
>>>>>>>
<
https://issues.jboss.org/__browse/WFLY-1691>>
>>>>>>>
>>>>>>>
>>>>>>>
<
https://issues.jboss.org/____browse/WFLY-1691
>>>>>>>
>>>>>>>
<
https://issues.jboss.org/__browse/WFLY-1691>
>>>>>>>
>>>>>>>
<
https://issues.jboss.org/__browse/WFLY-1691
>>>>>>>
>>>>>>>
<
https://issues.jboss.org/browse/WFLY-1691>>>
>>>>>>>>> [5]
>>>>>>>>>
>>>>>>>
http://simplesassim.wordpress.______com/2013/07/12/how-to-use-____the-__j...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
<
http://simplesassim.__wordpre__ss.com/2013/07/12/how-__to-__use-the-jpa-b...
>>>>>>>
<
http://wordpre__ss.com/2013/07/12/how-__to-__use-the-jpa-based-token-____...
>>>>>>>
>>>>>>>
>>>>>>>
<
http://wordpress.com/2013/07/12/how-__to-use-the-jpa-based-token-__regist...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
<
http://simplesassim.__wordpress.com/2013/07/12/how-__to-use-the-jpa-based...
>>>>>>>
<
http://wordpress.com/2013/07/12/how-__to-use-the-jpa-based-token-__regist...
>>>>>>>
>>>>>>>
>>>>>>>
<
http://simplesassim.wordpress.com/2013/07/12/how-to-use-the-jpa-based-tok...
>>>>>>>
>>>>>>>>> [6]
>>>>>>>>>
>>>>>>>
http://simplesassim.wordpress.______com/2013/07/21/how-to-use-____the-__j...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
<
http://simplesassim.__wordpre__ss.com/2013/07/21/how-__to-__use-the-jpa-b...
>>>>>>>
<
http://wordpre__ss.com/2013/07/21/how-__to-__use-the-jpa-based-____revoca...
>>>>>>>
>>>>>>>
>>>>>>>
<
http://wordpress.com/2013/07/21/how-__to-use-the-jpa-based-__revocation-r...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
<
http://simplesassim.__wordpress.com/2013/07/21/how-__to-use-the-jpa-based...
>>>>>>>
<
http://wordpress.com/2013/07/21/how-__to-use-the-jpa-based-__revocation-r...
>>>>>>>
>>>>>>>
>>>>>>>
<
http://simplesassim.wordpress.com/2013/07/21/how-to-use-the-jpa-based-rev...
>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
_____________________________________________________
>>>>>>>
>>>>>>>>> wildfly-dev
>>>>>>> mailing list
>>>>>>> wildfly-dev(a)lists.jboss.org
>>>>>>>
<mailto:wildfly-dev@lists.jboss.org>
>>>>>>>
<mailto:wildfly-dev@lists.jboss.org
>>>>>>>
<mailto:wildfly-dev@lists.jboss.org>>
>>>>>>>
<mailto:wildfly-dev@lists.
>>>>>>>
<mailto:wildfly-dev@lists.>__jboss.org
>>>>>>> <
http://jboss.org>
>>>>>>>
<mailto:wildfly-dev@lists.jboss.org
>>>>>>>
<mailto:wildfly-dev@lists.jboss.org>>>
>>>>>>>
>>>>>>> <mailto:wildfly-dev@lists
<mailto:wildfly-dev@lists>.
>>>>>>> <mailto:wildfly-dev@lists
>>>>>>>
<mailto:wildfly-dev@lists>.>__jb__oss.org
>>>>>>> <
http://jb__oss.org>
<
http://jboss.org>
>>>>>>>
<mailto:wildfly-dev@lists.
>>>>>>>
<mailto:wildfly-dev@lists.>__jboss.org
>>>>>>> <
http://jboss.org>
>>>>>>>
<mailto:wildfly-dev@lists.jboss.org
>>>>>>>
<mailto:wildfly-dev@lists.jboss.org>>>>
>>>>>>>
>>>>>>> <mailto:wildfly-dev@lists
<mailto:wildfly-dev@lists>
>>>>>>> <mailto:wildfly-dev@lists
>>>>>>> <mailto:wildfly-dev@lists>>.
>>>>>>>
<mailto:wildfly-dev@lists
>>>>>>> <mailto:wildfly-dev@lists>
>>>>>>> <mailto:wildfly-dev@lists
>>>>>>>
<mailto:wildfly-dev@lists>>.>__j__b__oss.org
>>>>>>> <
http://j__b__oss.org>
>>>>>>> <
http://jb__oss.org>
>>>>>>> <
http://jboss.org>
>>>>>>>
>>>>>>> <mailto:wildfly-dev@lists
<mailto:wildfly-dev@lists>.
>>>>>>> <mailto:wildfly-dev@lists
>>>>>>>
<mailto:wildfly-dev@lists>.>__jb__oss.org
>>>>>>> <
http://jb__oss.org>
<
http://jboss.org>
>>>>>>>
<mailto:wildfly-dev@lists.
>>>>>>>
<mailto:wildfly-dev@lists.>__jboss.org
>>>>>>> <
http://jboss.org>
>>>>>>>
<mailto:wildfly-dev@lists.jboss.org
>>>>>>>
<mailto:wildfly-dev@lists.jboss.org>>>>>
>>>>>>>
>>>>>>>
https://lists.jboss.org/______mailman/listinfo/wildfly-dev
>>>>>>>
>>>>>>>
<
https://lists.jboss.org/____mailman/listinfo/wildfly-dev>
>>>>>>>
>>>>>>>
>>>>>>>
<
https://lists.jboss.org/____mailman/listinfo/wildfly-dev
>>>>>>>
>>>>>>>
<
https://lists.jboss.org/__mailman/listinfo/wildfly-dev>>
>>>>>>>
>>>>>>>
>>>>>>>
<
https://lists.jboss.org/____mailman/listinfo/wildfly-dev
>>>>>>>
>>>>>>>
<
https://lists.jboss.org/__mailman/listinfo/wildfly-dev>
>>>>>>>
>>>>>>>
<
https://lists.jboss.org/__mailman/listinfo/wildfly-dev
>>>>>>>
>>>>>>>
<
https://lists.jboss.org/mailman/listinfo/wildfly-dev>>>
>>>>>>>
_____________________________________________________
>>>>>>>
>>>>>>>> wildfly-dev
>>>>>>> mailing list
>>>>>>> wildfly-dev(a)lists.jboss.org
>>>>>>>
<mailto:wildfly-dev@lists.jboss.org>
>>>>>>>
<mailto:wildfly-dev@lists.jboss.org
>>>>>>>
<mailto:wildfly-dev@lists.jboss.org>>
>>>>>>>
<mailto:wildfly-dev@lists.
>>>>>>>
<mailto:wildfly-dev@lists.>__jboss.org
>>>>>>> <
http://jboss.org>
>>>>>>>
<mailto:wildfly-dev@lists.jboss.org
>>>>>>>
<mailto:wildfly-dev@lists.jboss.org>>>
>>>>>>>
>>>>>>> <mailto:wildfly-dev@lists
<mailto:wildfly-dev@lists>.
>>>>>>> <mailto:wildfly-dev@lists
>>>>>>>
<mailto:wildfly-dev@lists>.>__jb__oss.org
>>>>>>> <
http://jb__oss.org>
<
http://jboss.org>
>>>>>>>
<mailto:wildfly-dev@lists.
>>>>>>>
<mailto:wildfly-dev@lists.>__jboss.org
>>>>>>> <
http://jboss.org>
>>>>>>>
<mailto:wildfly-dev@lists.jboss.org
>>>>>>>
<mailto:wildfly-dev@lists.jboss.org>>>>
>>>>>>>
>>>>>>> <mailto:wildfly-dev@lists
<mailto:wildfly-dev@lists>
>>>>>>> <mailto:wildfly-dev@lists
>>>>>>> <mailto:wildfly-dev@lists>>.
>>>>>>>
<mailto:wildfly-dev@lists
>>>>>>> <mailto:wildfly-dev@lists>
>>>>>>> <mailto:wildfly-dev@lists
>>>>>>>
<mailto:wildfly-dev@lists>>.>__j__b__oss.org
>>>>>>> <
http://j__b__oss.org>
>>>>>>> <
http://jb__oss.org>
>>>>>>> <
http://jboss.org>
>>>>>>>
>>>>>>> <mailto:wildfly-dev@lists
<mailto:wildfly-dev@lists>.
>>>>>>> <mailto:wildfly-dev@lists
>>>>>>>
<mailto:wildfly-dev@lists>.>__jb__oss.org
>>>>>>> <
http://jb__oss.org>
<
http://jboss.org>
>>>>>>>
<mailto:wildfly-dev@lists.
>>>>>>>
<mailto:wildfly-dev@lists.>__jboss.org
>>>>>>> <
http://jboss.org>
>>>>>>>
<mailto:wildfly-dev@lists.jboss.org
>>>>>>>
<mailto:wildfly-dev@lists.jboss.org>>>>>
>>>>>>>
>>>>>>>
https://lists.jboss.org/______mailman/listinfo/wildfly-dev
>>>>>>>
>>>>>>>
<
https://lists.jboss.org/____mailman/listinfo/wildfly-dev>
>>>>>>>
>>>>>>>
>>>>>>>
<
https://lists.jboss.org/____mailman/listinfo/wildfly-dev
>>>>>>>
>>>>>>>
<
https://lists.jboss.org/__mailman/listinfo/wildfly-dev>>
>>>>>>>
>>>>>>>
>>>>>>>
<
https://lists.jboss.org/____mailman/listinfo/wildfly-dev
>>>>>>>
>>>>>>>
<
https://lists.jboss.org/__mailman/listinfo/wildfly-dev>
>>>>>>>
>>>>>>>
<
https://lists.jboss.org/__mailman/listinfo/wildfly-dev
>>>>>>>
>>>>>>>
<
https://lists.jboss.org/mailman/listinfo/wildfly-dev>>>
>>>>>>>
>>>>>>>
>>>>>>>
_____________________________________________________
>>>>>>>
>>>>>>>
wildfly-dev
>>>>>>> mailing list
>>>>>>> wildfly-dev(a)lists.jboss.org
>>>>>>>
<mailto:wildfly-dev@lists.jboss.org>
>>>>>>> <mailto:wildfly-dev@lists.jboss.org
>>>>>>>
<mailto:wildfly-dev@lists.jboss.org>>
>>>>>>> <mailto:wildfly-dev@lists.
>>>>>>>
<mailto:wildfly-dev@lists.>__jboss.org
>>>>>>> <
http://jboss.org>
>>>>>>>
<mailto:wildfly-dev@lists.jboss.org
>>>>>>>
<mailto:wildfly-dev@lists.jboss.org>>>
>>>>>>>
<mailto:wildfly-dev@lists
>>>>>>> <mailto:wildfly-dev@lists>.
>>>>>>> <mailto:wildfly-dev@lists
>>>>>>>
<mailto:wildfly-dev@lists>.>__jb__oss.org
>>>>>>> <
http://jb__oss.org>
<
http://jboss.org>
>>>>>>>
<mailto:wildfly-dev@lists.
>>>>>>>
<mailto:wildfly-dev@lists.>__jboss.org
>>>>>>> <
http://jboss.org>
>>>>>>>
<mailto:wildfly-dev@lists.jboss.org
>>>>>>>
<mailto:wildfly-dev@lists.jboss.org>>>>
>>>>>>>
>>>>>>> <mailto:wildfly-dev@lists
<mailto:wildfly-dev@lists>
>>>>>>> <mailto:wildfly-dev@lists
>>>>>>> <mailto:wildfly-dev@lists>>.
>>>>>>>
<mailto:wildfly-dev@lists
>>>>>>> <mailto:wildfly-dev@lists>
>>>>>>> <mailto:wildfly-dev@lists
>>>>>>>
<mailto:wildfly-dev@lists>>.>__j__b__oss.org
>>>>>>> <
http://j__b__oss.org>
>>>>>>> <
http://jb__oss.org>
>>>>>>> <
http://jboss.org>
>>>>>>>
>>>>>>> <mailto:wildfly-dev@lists
<mailto:wildfly-dev@lists>.
>>>>>>> <mailto:wildfly-dev@lists
>>>>>>>
<mailto:wildfly-dev@lists>.>__jb__oss.org
>>>>>>> <
http://jb__oss.org>
<
http://jboss.org>
>>>>>>>
<mailto:wildfly-dev@lists.
>>>>>>>
<mailto:wildfly-dev@lists.>__jboss.org
>>>>>>> <
http://jboss.org>
>>>>>>>
<mailto:wildfly-dev@lists.jboss.org
>>>>>>>
<mailto:wildfly-dev@lists.jboss.org>>>>>
>>>>>>>
>>>>>>>
https://lists.jboss.org/______mailman/listinfo/wildfly-dev
>>>>>>>
>>>>>>>
<
https://lists.jboss.org/____mailman/listinfo/wildfly-dev>
>>>>>>>
>>>>>>>
>>>>>>>
<
https://lists.jboss.org/____mailman/listinfo/wildfly-dev
>>>>>>>
>>>>>>>
<
https://lists.jboss.org/__mailman/listinfo/wildfly-dev>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
<
https://lists.jboss.org/____mailman/listinfo/wildfly-dev
>>>>>>>
>>>>>>>
<
https://lists.jboss.org/__mailman/listinfo/wildfly-dev>
>>>>>>>
>>>>>>>
<
https://lists.jboss.org/__mailman/listinfo/wildfly-dev
>>>>>>>
>>>>>>>
<
https://lists.jboss.org/mailman/listinfo/wildfly-dev>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Fernando
Ribeiro
>>>>>>> Upic
>>>>>>> +55 11 9 8111 4078
<tel:%2B55%2011%209%208111%204078>
>>>>>>>
<tel:%2B55%2011%209%208111%__204078>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
_____________________________________________________
>>>>>>>
>>>>>>> wildfly-dev
mailing list
>>>>>>> wildfly-dev(a)lists.jboss.org
>>>>>>>
<mailto:wildfly-dev@lists.jboss.org>
>>>>>>> <mailto:wildfly-dev@lists.jboss.org
>>>>>>>
<mailto:wildfly-dev@lists.jboss.org>>
>>>>>>> <mailto:wildfly-dev@lists.
>>>>>>>
<mailto:wildfly-dev@lists.>__jboss.org
>>>>>>> <
http://jboss.org>
>>>>>>>
<mailto:wildfly-dev@lists.jboss.org
>>>>>>>
<mailto:wildfly-dev@lists.jboss.org>>>
>>>>>>>
<mailto:wildfly-dev@lists
>>>>>>> <mailto:wildfly-dev@lists>.
>>>>>>> <mailto:wildfly-dev@lists
>>>>>>>
<mailto:wildfly-dev@lists>.>__jb__oss.org
>>>>>>> <
http://jb__oss.org>
<
http://jboss.org>
>>>>>>>
<mailto:wildfly-dev@lists.
>>>>>>>
<mailto:wildfly-dev@lists.>__jboss.org
>>>>>>> <
http://jboss.org>
>>>>>>>
<mailto:wildfly-dev@lists.jboss.org
>>>>>>>
<mailto:wildfly-dev@lists.jboss.org>>>>
>>>>>>>
https://lists.jboss.org/______mailman/listinfo/wildfly-dev
>>>>>>>
>>>>>>>
<
https://lists.jboss.org/____mailman/listinfo/wildfly-dev>
>>>>>>>
>>>>>>>
>>>>>>>
<
https://lists.jboss.org/____mailman/listinfo/wildfly-dev
>>>>>>>
>>>>>>>
<
https://lists.jboss.org/__mailman/listinfo/wildfly-dev>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
<
https://lists.jboss.org/____mailman/listinfo/wildfly-dev
>>>>>>>
>>>>>>>
<
https://lists.jboss.org/__mailman/listinfo/wildfly-dev>
>>>>>>>
>>>>>>>
<
https://lists.jboss.org/__mailman/listinfo/wildfly-dev
>>>>>>>
>>>>>>>
<
https://lists.jboss.org/mailman/listinfo/wildfly-dev>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Fernando Ribeiro
>>>>>>> Upic
>>>>>>> +55 11 9 8111 4078
<tel:%2B55%2011%209%208111%204078>
>>>>>>>
<tel:%2B55%2011%209%208111%__204078>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)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