License evolution
by Michael Bilalis
Hello,
I'm an happy user of JBoss AS 7 and I'm waiting for a Wildfly release.
I've heard that Fuse license has evolved and it can only be used for
dev. License must be purchased to use it in production.
Is same evolution will be applied to JBoss AS 7 and/or Wildfly in the
future ?
Kind Regards.
Michaël
13 years
Implementing enforce-victims-rule in wildfly builds
by David Jorm
Hi All
First I should introduce myself for those who don't know me, as I have not participated in wildfly dev discussions before. I am a security response engineer working for Red Hat, handling security patches for the commercial JBoss products. Recently some colleagues and I have been working on a tool called 'victims'. The victims tool aims to provide a canonical database of known-vulnerable JAR files, along with tools that allow developers and system administrator to determine whether their projects and systems contain any known-vulnerable JARs. The project's about page contains a more detailed explanation:
http://www.victi.ms/about.html
enforce-victims-rule is a maven plugin that walks the dependency tree at build time, and uses the victims database to check whether a project is including any known-vulnerable JARs as dependencies. The plugin is available on maven central:
http://search.maven.org/#artifactdetails|com.redhat.victims|enforce-victi...
Please see the README.md and sample app here for configuration details:
https://github.com/victims/victims-enforcer
I think there would be great value in incorporating this plugin into the wildfly POM(s). It can catch security flaws at build time, eliminating the need for much more work to ship patches for flaws later down the line. It is also designed such that it should not trigger any false positives. There will be false negatives where there are gaps in the database.
What do people think? Is this something you'd consider implementing?
Thanks
--
David Jorm / Red Hat Security Response Team
13 years
Re: [wildfly-dev] manifest.mf jboss-deployment-structure.xml order of precedence
by Petr Sakar
I would suggest if the user should not do that, then such situation should be detected and should trigger an error, otherwise user is left in the wild. If it is allowed, than it should be documented and the order defined
Petr
----- Original Message -----
From: "Jaikiran Pai" <jpai(a)redhat.com>
To: "Rebecca Searls" <rsearls(a)redhat.com>
Cc: wildfly-dev(a)lists.jboss.org
Sent: Friday, August 16, 2013 5:12:08 AM
Subject: Re: [wildfly-dev] manifest.mf jboss-deployment-structure.xml order of precedence
I think what Stuart meant in his mail was that the order is "undefined"
for such cases from an end user point of view. i.e. don't do that, since
we do not guarantee the ordering or such.
-Jaikiran
On Friday 16 August 2013 01:20 AM, Rebecca Searls wrote:
> I'm trying to understand the nature of how this works. I have not found any information in the documentation about
> the rules under which these 2 files are processed by AS7/WildFly. If MANIFEST.MF is present is it always processed
> first? Who wins when there are conflicting rules like the one I described?
>
>
> ----- Original Message -----
>> From: "Stuart Douglas" <stuart.w.douglas(a)gmail.com>
>> To: "Rebecca Searls" <rsearls(a)redhat.com>
>> Cc: wildfly-dev(a)lists.jboss.org
>> Sent: Thursday, August 15, 2013 3:41:55 PM
>> Subject: Re: [wildfly-dev] manifest.mf jboss-deployment-structure.xml order of precedence
>>
>> Don't do that.
>>
>> Pretty sure the remove will take precedence but I don't think this is
>> something we should consider supported behavior.
>>
>> Stuart
>>
>>
>> On Thu, Aug 15, 2013 at 5:51 PM, Rebecca Searls <rsearls(a)redhat.com> wrote:
>>
>>> What if manifest.mf adds a dependency and jboss-deployment-structure.xml
>>> removes it?
>>> Is manifest.mf processes first?
>>>
>>> ----- Original Message -----
>>>> From: "Stuart Douglas" <stuart.w.douglas(a)gmail.com>
>>>> To: "Rebecca Searls" <rsearls(a)redhat.com>
>>>> Cc: wildfly-dev(a)lists.jboss.org
>>>> Sent: Thursday, August 15, 2013 11:37:19 AM
>>>> Subject: Re: [wildfly-dev] manifest.mf jboss-deployment-structure.xml
>>> order of precedence
>>>> If both are present both sets of dependencies will be added to the
>>>> deployment.
>>>>
>>>> Stuart
>>>>
>>>>
>>>> On Thu, Aug 15, 2013 at 5:32 PM, Rebecca Searls <rsearls(a)redhat.com>
>>> wrote:
>>>>> Is there are order of precedence if both a manifest.mf
>>>>> jboss-deployment-structure.xml
>>>>> are present in an archive? Does one override the other?
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
13 years
Re: [wildfly-dev] Reading Logs from Web Console
by James R. Perkins
Ha, yes it's been a couple of years now :) I'm enjoying Red Hat a lot
and I hope you are too.
Thanks. I'll see what Google turns up with that. Maybe we could at least
get some ideas from it.
On 08/14/2013 11:51 AM, Rob Cernich wrote:
>> The problem with filtering comes in parsing the log file. While I have
>> had some success doing this with I tool I was playing with for Jesper,
>> once you get a stack trace you have to start making guesses. I tend to
>> agree with dmlloyd in that log files tend to be a one way write. You can
>> do some parsing with a best guess, but well we all know what happens
>> when we start assuming and guessing :)
>>
>> That said I do like the challenge of trying to parse log files. I did
>> start a project to do it in my spare time I just haven't found time to
>> put into working on it lately.
>>
> Hey James, long time since orientation...
>
> Eclipse used to have a project called TPTP which did some of this. It was architected with a "collector" that received events from various "agents" associated with servers running in your system. I believe the events were typed as Common Base Events which included fields to help correlate events across multiple servers. I don't recall whether or not the source for the server components (collector and agent) was open sourced or not (the binaries were available from Eclipse). The Eclipse side provided tooling for viewing and analyzing these CBE messages, which included the capability for creating rules that could be used to diagnose common problems when applied across a set of events.
>
> Hope you've been enjoying your time at Red Hat!
>
> Rob
--
James R. Perkins
Red Hat JBoss Middleware
13 years
8.0.0.Alpha4 released!
by Jason Greene
I am happy to announce WildFLy 8.0.0.Alpha4!
Get it here:
http://www.wildfly.org/download/
Notable Updates
• RBAC support for management (standalone mode only this iteration)
• Audit logging
• Initial JMS 2.0 support
• Improved CDI 1.1 integration
• Introduction of Undertow development mode
Compatibility Notes
• Web subsystem with JBossWeb was removed from WildFly, leaving Undertow as only Web server.
Issue Resolution
• 62 issues were resolved since Alpha3, including a serious redeployment memory leak
Component Updates
• Weld 2.0.3
• Undertow Beta 7
• Console 2.0.0.Beta2
• JBoss Modules 1.3.0.Beta3
• HornetQ 2.4.0.Alpha1
• aesh 0.33.7
• Jipijapa 1.0.0.Alpha5
• Javassist 3.18.1-Beta1
• Remoting JMX 2.0.0.Beta2
• JBoss WS 4.2.0.Final
• Jgroups 3.3.4.Final
Enjoy!
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
13 years
Broken logout / HAL-60
by Harald Pehl
I'm trying to fix the broken logout in the console (https://issues.jboss.org/browse/HAL-60). With the switch to undertow, the redirects in LogoutHandler do not longer work in Chrome and Safari. I came up with a solution that adds a call to SecurityContext.logout() before doing the redirects.
My changes are in PR #4879: https://github.com/wildfly/wildfly/pull/4897. Can you take a look at my solution. I don't know if that's an appropriate solution to get rid of the digest authentication information. At least it does work across common browsers.
Thanks
Harald
---
Harald Pehl
JBoss by Red Hat
http://hpehl.info
13 years
WILDFLY 1650
by Emmanuel Hugonnet
Hi,
I 'm writting this to try to explain my position on WILDFLY 1650.
I don't know how to change the PR
(https://github.com/wildfly/wildfly/pull/4749) to have it intergated.
Currently I can't build EAP nor Wildfly with all tests on a French
loacle machine.
On GNU/Linux I can do it by changing the LANG in my shell but on Windows
I just had to forget about it.
This problem happens because of the assumption that the default locale
is English so some messages in tet are using 'hardcoded' string instead
og I18n message.
Second, which affects EAP only (but which is still an issue in Wildfly
even if it is hidden), some tests which check for model
retro-compatibility will use 'old' version of JBoss AS which contains
translated logger messages in generated classes. Alas for French you
have old versions without any French and new with French, because of an
issue with the classloader we happens to be casting a $Logger to a
Logger which wasn't loaded by the same classloader.
I have tried to replicate this behaviour in Wildlfy, using the codehaus
mojo annotation processor to generate the translated loggers using the
main source code for the test source code.
While this complicated test maybe too much I think it should be possible
to make Wildlfy fully buildable on a French Windows computer (even if we
know Windows sucks and French rules ;o) )
So I'm asking here about how we should tackle this issue.
Emmanuel
13 years
Re: [wildfly-dev] Changes to the PicketLink Module
by Anil Saldhana
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?
> Should we fix/adapt the PicketLink JPA Registry usage of
> EntityManagerFactory such that we do not need hibernate/javassist
> module dependencies? Guidance appreciated.
>
> 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>
>>
>>
>>
13 years
