From ropalka at redhat.com  Thu Jan  2 03:49:08 2014
From: ropalka at redhat.com (Richard Opalka)
Date: Thu, 02 Jan 2014 09:49:08 +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: <52C52804.3080902@redhat.com>

Well done everybody!

Rio

On 12/22/2013 08: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
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 


-- 
Richard Opalka
Principal Software Engineer
JBoss, by Red Hat
Cell: +420 731 186 942

From jmesnil at redhat.com  Thu Jan  2 05:18:58 2014
From: jmesnil at redhat.com (Jeff Mesnil)
Date: Thu, 2 Jan 2014 11:18:58 +0100
Subject: [wildfly-dev] admin console question/resources
In-Reply-To: <CAFz_cFucsipUpZ9_r+bwj9Z+uqa4MsrZCdWcZ14dz3CUMWYecw@mail.gmail.com>
References: <CAFz_cFucsipUpZ9_r+bwj9Z+uqa4MsrZCdWcZ14dz3CUMWYecw@mail.gmail.com>
Message-ID: <3C436141-711D-4DC3-AEDA-04FE7E010D74@redhat.com>


On 27 Dec 2013, at 22:02, Nick Mpallas <mpallas at gmail.com> wrote:

> 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?

You are right, the admin console should allow to manage deployed JMS resources.

It works for the CLI console, the deployed JMS resources (jms-queue, jms-topic and pooled-connection-factory) are manageable under /deployment=*/subsystem=messaging/hornetq-server=*.
It is missing from the GUI console and I have opened WFLY-2701[1] to track this feature request.

jeff

[1] https://issues.jboss.org/browse/WFLY-2701

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



From ales.justin at gmail.com  Thu Jan  2 06:28:10 2014
From: ales.justin at gmail.com (Ales Justin)
Date: Thu, 2 Jan 2014 12:28:10 +0100
Subject: [wildfly-dev] xnio selection err
In-Reply-To: <E24431FB-EE1F-433F-A259-2966E4D05700@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>
	<6E3B43B9-79F8-4D47-A5C3-5675DB4CDAB8@gmail.com>
	<E24431FB-EE1F-433F-A259-2966E4D05700@redhat.com>
Message-ID: <8B57431B-3BC6-4ECE-BB0F-ED8012DDA6BD@gmail.com>

Here:
* https://gist.github.com/alesj/8217872

But I didn't get any WARN log during my "chat", only at shutdown.
Does it still help? Otherwise I can try to catch this when getting WARNings during chat.

-Ales

On 28 Dec 2013, at 17:14, Jason Greene <jgreene at redhat.com> wrote:

> 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/20140102/a1fcacb9/attachment.html 

From emartins at redhat.com  Thu Jan  2 06:43:05 2014
From: emartins at redhat.com (Eduardo Martins)
Date: Thu, 2 Jan 2014 11:43:05 +0000
Subject: [wildfly-dev] New Year's Eve bug broke the build
In-Reply-To: <52C303B5.8010108@redhat.com>
References: <52C22936.2020506@redhat.com>
	<9FD95B53-DC8C-4E90-9FB8-D1BB853B1A21@redhat.com>
	<69FED65C-661D-4390-A290-111DAD45958F@redhat.com>
	<52C303B5.8010108@redhat.com>
Message-ID: <BE0813BA-D349-47E5-8716-78FBB85EF6FF@redhat.com>

The issue seems to be just a test bug that does not handles well the last and first couple of days for each.

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

Cheng, dunno if the JBCTS issue is relative, please check.

?E

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

> 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
> 

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

From filippespolti at gmail.com  Thu Jan  2 06:45:35 2014
From: filippespolti at gmail.com (Filippe Costa Spolti)
Date: Thu, 02 Jan 2014 09:45:35 -0200
Subject: [wildfly-dev] WildFly 8.0.0.CR1 Released!
In-Reply-To: <52C52804.3080902@redhat.com>
References: <F8189E34-9B89-4393-9109-6F9E3D65A8D4@redhat.com>
	<52C52804.3080902@redhat.com>
Message-ID: <52C5515F.4050409@gmail.com>

Great notice.. :)

Regards,
______________________________________
Filippe Costa Spolti
Linux User n?515639 - http://counter.li.org/
filippespolti at gmail.com
"Be yourself"
<http://www.linkedin.com/pub/filippe-costa-spolti/67/985/575>
On 01/02/2014 06:49 AM, Richard Opalka wrote:
> Well done everybody!
>
> Rio
>
> On 12/22/2013 08: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
>>
>> _______________________________________________
>> 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/20140102/ceb7901f/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: linkedin.png
Type: image/png
Size: 957 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140102/ceb7901f/attachment.png 

From jgreene at redhat.com  Thu Jan  2 09:08:48 2014
From: jgreene at redhat.com (Jason Greene)
Date: Thu, 2 Jan 2014 09:08:48 -0500 (EST)
Subject: [wildfly-dev] xnio selection err
In-Reply-To: <8B57431B-3BC6-4ECE-BB0F-ED8012DDA6BD@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>
	<E24431FB-EE1F-433F-A259-2966E4D05700@redhat.com>
	<8B57431B-3BC6-4ECE-BB0F-ED8012DDA6BD@gmail.com>
Message-ID: <A6B1562C-2906-4E02-9C24-8FF511B605A5@redhat.com>

Oh is it always at shutdown?

Sent from my iPhone

> On Jan 2, 2014, at 5:28 AM, Ales Justin <ales.justin at gmail.com> wrote:
> 
> Here:
> * https://gist.github.com/alesj/8217872
> 
> But I didn't get any WARN log during my "chat", only at shutdown.
> Does it still help? Otherwise I can try to catch this when getting WARNings during chat.
> 
> -Ales
> 
>> On 28 Dec 2013, at 17:14, Jason Greene <jgreene at redhat.com> wrote:
>> 
>> 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
> 
> _______________________________________________
> 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/20140102/637a4cf5/attachment.html 

From jgreene at redhat.com  Thu Jan  2 09:15:01 2014
From: jgreene at redhat.com (Jason Greene)
Date: Thu, 2 Jan 2014 09:15:01 -0500 (EST)
Subject: [wildfly-dev] admin console question/resources
In-Reply-To: <3C436141-711D-4DC3-AEDA-04FE7E010D74@redhat.com>
References: <CAFz_cFucsipUpZ9_r+bwj9Z+uqa4MsrZCdWcZ14dz3CUMWYecw@mail.gmail.com>
	<3C436141-711D-4DC3-AEDA-04FE7E010D74@redhat.com>
Message-ID: <1716CAD0-19E3-4B6F-9F62-2F3674D28DC0@redhat.com>

It's important to note though that deployment created resources (destinations, data sources, etc) are effectively READ ONLY (but with temporary runtime operations allowed), since we can't/won't alter the deployment.

The only solution for that is using our deployment override facility.

If you want full config management the resource needs to be part of the server configuration instead of the deployment.

> On Jan 2, 2014, at 4:19 AM, Jeff Mesnil <jmesnil at redhat.com> wrote:
> 
> 
>> On 27 Dec 2013, at 22:02, Nick Mpallas <mpallas at gmail.com> wrote:
>> 
>> 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?
> 
> You are right, the admin console should allow to manage deployed JMS resources.
> 
> It works for the CLI console, the deployed JMS resources (jms-queue, jms-topic and pooled-connection-factory) are manageable under /deployment=*/subsystem=messaging/hornetq-server=*.
> It is missing from the GUI console and I have opened WFLY-2701[1] to track this feature request.
> 
> jeff
> 
> [1] https://issues.jboss.org/browse/WFLY-2701
> 
> -- 
> Jeff Mesnil
> JBoss, a division of Red Hat
> http://jmesnil.net/
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From jmesnil at redhat.com  Thu Jan  2 09:25:10 2014
From: jmesnil at redhat.com (Jeff Mesnil)
Date: Thu, 2 Jan 2014 15:25:10 +0100
Subject: [wildfly-dev] admin console question/resources
In-Reply-To: <1716CAD0-19E3-4B6F-9F62-2F3674D28DC0@redhat.com>
References: <CAFz_cFucsipUpZ9_r+bwj9Z+uqa4MsrZCdWcZ14dz3CUMWYecw@mail.gmail.com>
	<3C436141-711D-4DC3-AEDA-04FE7E010D74@redhat.com>
	<1716CAD0-19E3-4B6F-9F62-2F3674D28DC0@redhat.com>
Message-ID: <9E5D23E7-238E-42E4-8E07-3DF12A67FD30@redhat.com>

Jason?s right: JMS resources that are part of a deployment are not fully manageable (you can not change their attributes, such as durable, selector, etc.).
Only their runtime management operations are available (list consumers, flush queues, metrics, etc.).

On 2 Jan 2014, at 15:15, Jason Greene <jgreene at redhat.com> wrote:

> It's important to note though that deployment created resources (destinations, data sources, etc) are effectively READ ONLY (but with temporary runtime operations allowed), since we can't/won't alter the deployment.
> 
> The only solution for that is using our deployment override facility.
> 
> If you want full config management the resource needs to be part of the server configuration instead of the deployment.
> 
>> On Jan 2, 2014, at 4:19 AM, Jeff Mesnil <jmesnil at redhat.com> wrote:
>> 
>> 
>>> On 27 Dec 2013, at 22:02, Nick Mpallas <mpallas at gmail.com> wrote:
>>> 
>>> 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?
>> 
>> You are right, the admin console should allow to manage deployed JMS resources.
>> 
>> It works for the CLI console, the deployed JMS resources (jms-queue, jms-topic and pooled-connection-factory) are manageable under /deployment=*/subsystem=messaging/hornetq-server=*.
>> It is missing from the GUI console and I have opened WFLY-2701[1] to track this feature request.
>> 
>> jeff
>> 
>> [1] https://issues.jboss.org/browse/WFLY-2701
>> 
>> -- 
>> Jeff Mesnil
>> JBoss, a division of Red Hat
>> http://jmesnil.net/
>> 
>> 
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev

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



From ales.justin at gmail.com  Thu Jan  2 09:25:59 2014
From: ales.justin at gmail.com (Ales Justin)
Date: Thu, 2 Jan 2014 15:25:59 +0100
Subject: [wildfly-dev] xnio selection err
In-Reply-To: <A6B1562C-2906-4E02-9C24-8FF511B605A5@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>
	<6E3B43B9-79F8-4D47-A5C3-5675DB4CDAB8@gmail.com>
	<E24431FB-EE1F-433F-A259-2966E4D05700@redhat.com>
	<8B57431B-3BC6-4ECE-BB0F-ED8012DDA6BD@gmail.com>
	<A6B1562C-2906-4E02-9C24-8FF511B605A5@redhat.com>
Message-ID: <6DFAE785-FF64-4540-A7C6-48D7FF10B425@gmail.com>

> Oh is it always at shutdown?

No.
It's also while the app runs.
But dunno how to re-produce it on a constant basis.

-Ales

> On Jan 2, 2014, at 5:28 AM, Ales Justin <ales.justin at gmail.com> wrote:
> 
>> Here:
>> * https://gist.github.com/alesj/8217872
>> 
>> But I didn't get any WARN log during my "chat", only at shutdown.
>> Does it still help? Otherwise I can try to catch this when getting WARNings during chat.
>> 
>> -Ales
>> 
>> On 28 Dec 2013, at 17:14, Jason Greene <jgreene at redhat.com> wrote:
>> 
>>> 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
>>>> 
>> 
>> _______________________________________________
>> 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/20140102/63e59d6d/attachment-0001.html 

From anmiller at redhat.com  Thu Jan  2 09:57:21 2014
From: anmiller at redhat.com (Andrig Miller)
Date: Thu, 2 Jan 2014 09:57:21 -0500 (EST)
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: <3926894.1114.1388674636887.JavaMail.andrig@worklaptop.miller.org>

Congratulations to the entire team!

Andy

----- Original Message -----
> From: "Jason Greene" <jason.greene at redhat.com>
> To: "Wildfly Dev mailing list" <wildfly-dev at lists.jboss.org>
> Sent: Sunday, December 22, 2013 12:34:18 AM
> Subject: [wildfly-dev] WildFly 8.0.0.CR1 Released!
> 
> 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 david.lloyd at redhat.com  Thu Jan  2 14:02:48 2014
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Thu, 02 Jan 2014 13:02:48 -0600
Subject: [wildfly-dev] New Year's Eve bug broke the build
In-Reply-To: <52C2E6F1.20404@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>
	<52C2E6F1.20404@redhat.com>
Message-ID: <52C5B7D8.8040201@redhat.com>

We should not be relying on the current date/calendar to change the 
outcome of any test.  We should be using some type of "pre-cooked" clock 
which is set to specific test dates for these tests in particular.

On 12/31/2013 09:46 AM, Cheng Fang wrote:
> 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
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
- DML

From emartins at redhat.com  Thu Jan  2 14:04:56 2014
From: emartins at redhat.com (Eduardo Martins)
Date: Thu, 2 Jan 2014 19:04:56 +0000
Subject: [wildfly-dev] New Year's Eve bug broke the build
In-Reply-To: <52C5B7D8.8040201@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>
	<52C2E6F1.20404@redhat.com> <52C5B7D8.8040201@redhat.com>
Message-ID: <C203C2B2-FAA5-4104-B496-4C01AC5EF4EB@redhat.com>

IMO it?s good to use actual dates and timezones, this way we may get bugs that only show with specific dates ;-)

Anyway, the PR is merged, it should not be an issue anymore.

?E

On 02 Jan 2014, at 19:02, David M. Lloyd <david.lloyd at redhat.com> wrote:

> We should not be relying on the current date/calendar to change the 
> outcome of any test.  We should be using some type of "pre-cooked" clock 
> which is set to specific test dates for these tests in particular.
> 
> On 12/31/2013 09:46 AM, Cheng Fang wrote:
>> 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
>> 
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> 
> 
> 
> -- 
> - DML
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



From jason.greene at redhat.com  Thu Jan  2 14:53:10 2014
From: jason.greene at redhat.com (Jason Greene)
Date: Thu, 2 Jan 2014 13:53:10 -0600
Subject: [wildfly-dev] New Year's Eve bug broke the build
In-Reply-To: <C203C2B2-FAA5-4104-B496-4C01AC5EF4EB@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>
	<52C2E6F1.20404@redhat.com> <52C5B7D8.8040201@redhat.com>
	<C203C2B2-FAA5-4104-B496-4C01AC5EF4EB@redhat.com>
Message-ID: <BF22F01A-B0D3-4FA4-838E-B52D0E8A4D22@redhat.com>

I have to agree with David on this one. It?s fine to use actual dates and timezones. It?s bad to have the time the test as ran be an input into the test. 
On Jan 2, 2014, at 1:04 PM, Eduardo Martins <emartins at redhat.com> wrote:

> IMO it?s good to use actual dates and timezones, this way we may get bugs that only show with specific dates ;-)
> 
> Anyway, the PR is merged, it should not be an issue anymore.
> 
> ?E
> 
> On 02 Jan 2014, at 19:02, David M. Lloyd <david.lloyd at redhat.com> wrote:
> 
>> We should not be relying on the current date/calendar to change the 
>> outcome of any test.  We should be using some type of "pre-cooked" clock 
>> which is set to specific test dates for these tests in particular.
>> 
>> On 12/31/2013 09:46 AM, Cheng Fang wrote:
>>> 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
>>> 
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> 
>> 
>> 
>> -- 
>> - DML
>> _______________________________________________
>> 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

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



From jason.greene at redhat.com  Thu Jan  2 14:57:56 2014
From: jason.greene at redhat.com (Jason Greene)
Date: Thu, 2 Jan 2014 13:57:56 -0600
Subject: [wildfly-dev] New Year's Eve bug broke the build
In-Reply-To: <BF22F01A-B0D3-4FA4-838E-B52D0E8A4D22@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>
	<52C2E6F1.20404@redhat.com> <52C5B7D8.8040201@redhat.com>
	<C203C2B2-FAA5-4104-B496-4C01AC5EF4EB@redhat.com>
	<BF22F01A-B0D3-4FA4-838E-B52D0E8A4D22@redhat.com>
Message-ID: <2C5432B7-2BFD-476B-9DD7-169A9A9852B5@redhat.com>

To illustrate why this is bad, its going to be a whole year from now until we know if the ?bug? is fixed, and thats assuming the test suite is even ran that day. Perhaps for some reason it?s not. 

On Jan 2, 2014, at 1:53 PM, Jason Greene <jason.greene at redhat.com> wrote:

> I have to agree with David on this one. It?s fine to use actual dates and timezones. It?s bad to have the time the test as ran be an input into the test. 
> On Jan 2, 2014, at 1:04 PM, Eduardo Martins <emartins at redhat.com> wrote:
> 
>> IMO it?s good to use actual dates and timezones, this way we may get bugs that only show with specific dates ;-)
>> 
>> Anyway, the PR is merged, it should not be an issue anymore.
>> 
>> ?E
>> 
>> On 02 Jan 2014, at 19:02, David M. Lloyd <david.lloyd at redhat.com> wrote:
>> 
>>> We should not be relying on the current date/calendar to change the 
>>> outcome of any test.  We should be using some type of "pre-cooked" clock 
>>> which is set to specific test dates for these tests in particular.
>>> 
>>> On 12/31/2013 09:46 AM, Cheng Fang wrote:
>>>> 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
>>>> 
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>> 
>>> 
>>> 
>>> -- 
>>> - DML
>>> _______________________________________________
>>> 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
> 
> --
> 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 arun.gupta at gmail.com  Tue Jan  7 20:24:09 2014
From: arun.gupta at gmail.com (Arun Gupta)
Date: Tue, 7 Jan 2014 17:24:09 -0800
Subject: [wildfly-dev] HTTP Management API
Message-ID: <CAGBoHQVP=an8c9gVnnzunyf5oFCS1TPBEmgJbZHiid4t7EqD4w@mail.gmail.com>

Hi there ...

I'm trying some samples from:

https://docs.jboss.org/author/display/WFLY8/The+HTTP+management+API

and have questions/comments.

1). First one is giving:

curl --digest -L -D - http://localhost:9990/management --header
"Content-Type: application/json" -d
'{"operation":"read-attribute","name":"server-state","json.pretty":1}'
-u u3:p3
HTTP/1.1 401 Unauthorized
Connection: keep-alive
WWW-Authenticate: Digest
realm="ManagementRealm",domain="/management",nonce="n6l3IRhNwTwNMTM4OTE0MjA3MTE4N55G54PM/ll8QrzSK+RrvTM=",opaque="00000000000000000000000000000000",algorithm=MD5
Content-Length: 77
Content-Type: text/html

HTTP/1.1 500 Internal Server Error
Connection: keep-alive
Authentication-Info:
nextnonce="I7Yrew1s+j4NMTM4OTE0MjA3MTE4NxXgrLGjS/rWgbUveRrchio="
Content-Type: text/plain;utf-8
Content-Length: 128

{
    "outcome" : "failed",
    "failure-description" : "JBAS014792: Unknown attribute server-state",
    "rolled-back" : true
}

http://wildscribe.github.io/Wildfly/8.0.0.CR1/index.html shows
server-state as a valid attribute.

Similar error for:

"JBAS014792: Unknown attribute profile-name"

Reading product-name and product-version returns:

{"outcome" : "success", "result" : null}

"name" attribute returns:

{"outcome" : "success", "result" : "Unnamed Domain"}

2). curl --digest -L -D - http://localhost:9990/management --header
"Content-Type: application/json" -d
'{"operation":"whoami","json.pretty":1}' -u u3:p3

does not return pretty JSON and instead returns:

{"outcome" : "success", "result" : {"identity" : {"username" : "u3",
"realm" : "ManagementRealm"}}}

release-name and release-version returned correct values.

3). I think a restart-server operation would be useful.

4). Why is the following command failing:

 curl --digest -D - http://localhost:9990/management --header
"Content-Type: application/json" -d '{"operation":"read-resource",
"address":["subsystem","data-sources"], "json.pretty":1}' -u u3:p3
HTTP/1.1 401 Unauthorized
Connection: keep-alive
WWW-Authenticate: Digest
realm="ManagementRealm",domain="/management",nonce="2oB+bvt990QNMTM4OTE0MzQ4Nzc0NkxPJHWOl6yAkN/F7PGdbYo=",opaque="00000000000000000000000000000000",algorithm=MD5
Content-Length: 77
Content-Type: text/html

HTTP/1.1 500 Internal Server Error
Connection: keep-alive
Authentication-Info:
nextnonce="JXNHCPPtBVwNMTM4OTE0MzQ4Nzc0N5YLxVykiaapgV5zTDnV++I="
Content-Type: text/plain;utf-8
Content-Length: 184

{
    "outcome" : "failed",
    "failure-description" : "JBAS014883: No resource definition is
registered for address [(\"subsystem\" => \"data-sources\")]",
    "rolled-back" : true
}

Even though there is a default data source already registered. The
management model

Either I'm not doing something basic correctly, the management model
is out of sync, or the API is not fully implemented.

Comments ?

Thanks,
Arun

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

From brian.stansberry at redhat.com  Tue Jan  7 21:13:20 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 07 Jan 2014 20:13:20 -0600
Subject: [wildfly-dev] HTTP Management API
In-Reply-To: <CAGBoHQVP=an8c9gVnnzunyf5oFCS1TPBEmgJbZHiid4t7EqD4w@mail.gmail.com>
References: <CAGBoHQVP=an8c9gVnnzunyf5oFCS1TPBEmgJbZHiid4t7EqD4w@mail.gmail.com>
Message-ID: <52CCB440.8080003@redhat.com>

Are you connecting to a domain host controller? The examples are for a 
standalone server.

On 1/7/14, 7:24 PM, Arun Gupta wrote:
> Hi there ...
>
> I'm trying some samples from:
>
> https://docs.jboss.org/author/display/WFLY8/The+HTTP+management+API
>
> and have questions/comments.
>
> 1). First one is giving:
>
> curl --digest -L -D - http://localhost:9990/management --header
> "Content-Type: application/json" -d
> '{"operation":"read-attribute","name":"server-state","json.pretty":1}'
> -u u3:p3
> HTTP/1.1 401 Unauthorized
> Connection: keep-alive
> WWW-Authenticate: Digest
> realm="ManagementRealm",domain="/management",nonce="n6l3IRhNwTwNMTM4OTE0MjA3MTE4N55G54PM/ll8QrzSK+RrvTM=",opaque="00000000000000000000000000000000",algorithm=MD5
> Content-Length: 77
> Content-Type: text/html
>
> HTTP/1.1 500 Internal Server Error
> Connection: keep-alive
> Authentication-Info:
> nextnonce="I7Yrew1s+j4NMTM4OTE0MjA3MTE4NxXgrLGjS/rWgbUveRrchio="
> Content-Type: text/plain;utf-8
> Content-Length: 128
>
> {
>      "outcome" : "failed",
>      "failure-description" : "JBAS014792: Unknown attribute server-state",
>      "rolled-back" : true
> }
>
> http://wildscribe.github.io/Wildfly/8.0.0.CR1/index.html shows
> server-state as a valid attribute.
>
> Similar error for:
>
> "JBAS014792: Unknown attribute profile-name"
>
> Reading product-name and product-version returns:
>
> {"outcome" : "success", "result" : null}
>
> "name" attribute returns:
>
> {"outcome" : "success", "result" : "Unnamed Domain"}
>
> 2). curl --digest -L -D - http://localhost:9990/management --header
> "Content-Type: application/json" -d
> '{"operation":"whoami","json.pretty":1}' -u u3:p3
>
> does not return pretty JSON and instead returns:
>
> {"outcome" : "success", "result" : {"identity" : {"username" : "u3",
> "realm" : "ManagementRealm"}}}
>
> release-name and release-version returned correct values.
>
> 3). I think a restart-server operation would be useful.
>
> 4). Why is the following command failing:
>
>   curl --digest -D - http://localhost:9990/management --header
> "Content-Type: application/json" -d '{"operation":"read-resource",
> "address":["subsystem","data-sources"], "json.pretty":1}' -u u3:p3
> HTTP/1.1 401 Unauthorized
> Connection: keep-alive
> WWW-Authenticate: Digest
> realm="ManagementRealm",domain="/management",nonce="2oB+bvt990QNMTM4OTE0MzQ4Nzc0NkxPJHWOl6yAkN/F7PGdbYo=",opaque="00000000000000000000000000000000",algorithm=MD5
> Content-Length: 77
> Content-Type: text/html
>
> HTTP/1.1 500 Internal Server Error
> Connection: keep-alive
> Authentication-Info:
> nextnonce="JXNHCPPtBVwNMTM4OTE0MzQ4Nzc0N5YLxVykiaapgV5zTDnV++I="
> Content-Type: text/plain;utf-8
> Content-Length: 184
>
> {
>      "outcome" : "failed",
>      "failure-description" : "JBAS014883: No resource definition is
> registered for address [(\"subsystem\" => \"data-sources\")]",
>      "rolled-back" : true
> }
>
> Even though there is a default data source already registered. The
> management model
>
> Either I'm not doing something basic correctly, the management model
> is out of sync, or the API is not fully implemented.
>
> Comments ?
>
> Thanks,
> Arun
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From arun.gupta at gmail.com  Wed Jan  8 00:46:25 2014
From: arun.gupta at gmail.com (Arun Gupta)
Date: Tue, 7 Jan 2014 21:46:25 -0800
Subject: [wildfly-dev] HTTP Management API
In-Reply-To: <52CCB440.8080003@redhat.com>
References: <CAGBoHQVP=an8c9gVnnzunyf5oFCS1TPBEmgJbZHiid4t7EqD4w@mail.gmail.com>
	<52CCB440.8080003@redhat.com>
Message-ID: <CAGBoHQUQzPtMYxGwOp=iSCN3SeY=VTxXcwmP1enGtmF8C5C3JQ@mail.gmail.com>

I realized I was doing something basic incorrectly ;)

For a standalone instance, should it not show the default data source:

-- cut here --
[standalone at localhost:9990 subsystem=datasources] ls

data-source

jdbc-driver

xa-data-source

installed-drivers=[{"driver-name" => "h2","deployment-name" =>
undefined,"driver-module-name" => "com.h2database.h2","module-slot" =>
"main","driver-datasource-class-name" =>
"","driver-xa-datasource-class-name" =>
"org.h2.jdbcx.JdbcDataSource","driver-class-name" =>
"org.h2.Driver","driver-major-version" => 1,"driver-minor-version" =>
3,"jdbc-compliant" => true}]
-- cut here --

How do I know which commands are targeted to domain host controller ?

product-name, product-version, profile-name are returning "undefined".

Is there a typical set of operations that can be incorporated in a
WildFly hands-on lab for standalone and domain host controller ?

Arun

On Tue, Jan 7, 2014 at 6:13 PM, Brian Stansberry
<brian.stansberry at redhat.com> wrote:
> Are you connecting to a domain host controller? The examples are for a
> standalone server.
>
> On 1/7/14, 7:24 PM, Arun Gupta wrote:
>> Hi there ...
>>
>> I'm trying some samples from:
>>
>> https://docs.jboss.org/author/display/WFLY8/The+HTTP+management+API
>>
>> and have questions/comments.
>>
>> 1). First one is giving:
>>
>> curl --digest -L -D - http://localhost:9990/management --header
>> "Content-Type: application/json" -d
>> '{"operation":"read-attribute","name":"server-state","json.pretty":1}'
>> -u u3:p3
>> HTTP/1.1 401 Unauthorized
>> Connection: keep-alive
>> WWW-Authenticate: Digest
>> realm="ManagementRealm",domain="/management",nonce="n6l3IRhNwTwNMTM4OTE0MjA3MTE4N55G54PM/ll8QrzSK+RrvTM=",opaque="00000000000000000000000000000000",algorithm=MD5
>> Content-Length: 77
>> Content-Type: text/html
>>
>> HTTP/1.1 500 Internal Server Error
>> Connection: keep-alive
>> Authentication-Info:
>> nextnonce="I7Yrew1s+j4NMTM4OTE0MjA3MTE4NxXgrLGjS/rWgbUveRrchio="
>> Content-Type: text/plain;utf-8
>> Content-Length: 128
>>
>> {
>>      "outcome" : "failed",
>>      "failure-description" : "JBAS014792: Unknown attribute server-state",
>>      "rolled-back" : true
>> }
>>
>> http://wildscribe.github.io/Wildfly/8.0.0.CR1/index.html shows
>> server-state as a valid attribute.
>>
>> Similar error for:
>>
>> "JBAS014792: Unknown attribute profile-name"
>>
>> Reading product-name and product-version returns:
>>
>> {"outcome" : "success", "result" : null}
>>
>> "name" attribute returns:
>>
>> {"outcome" : "success", "result" : "Unnamed Domain"}
>>
>> 2). curl --digest -L -D - http://localhost:9990/management --header
>> "Content-Type: application/json" -d
>> '{"operation":"whoami","json.pretty":1}' -u u3:p3
>>
>> does not return pretty JSON and instead returns:
>>
>> {"outcome" : "success", "result" : {"identity" : {"username" : "u3",
>> "realm" : "ManagementRealm"}}}
>>
>> release-name and release-version returned correct values.
>>
>> 3). I think a restart-server operation would be useful.
>>
>> 4). Why is the following command failing:
>>
>>   curl --digest -D - http://localhost:9990/management --header
>> "Content-Type: application/json" -d '{"operation":"read-resource",
>> "address":["subsystem","data-sources"], "json.pretty":1}' -u u3:p3
>> HTTP/1.1 401 Unauthorized
>> Connection: keep-alive
>> WWW-Authenticate: Digest
>> realm="ManagementRealm",domain="/management",nonce="2oB+bvt990QNMTM4OTE0MzQ4Nzc0NkxPJHWOl6yAkN/F7PGdbYo=",opaque="00000000000000000000000000000000",algorithm=MD5
>> Content-Length: 77
>> Content-Type: text/html
>>
>> HTTP/1.1 500 Internal Server Error
>> Connection: keep-alive
>> Authentication-Info:
>> nextnonce="JXNHCPPtBVwNMTM4OTE0MzQ4Nzc0N5YLxVykiaapgV5zTDnV++I="
>> Content-Type: text/plain;utf-8
>> Content-Length: 184
>>
>> {
>>      "outcome" : "failed",
>>      "failure-description" : "JBAS014883: No resource definition is
>> registered for address [(\"subsystem\" => \"data-sources\")]",
>>      "rolled-back" : true
>> }
>>
>> Even though there is a default data source already registered. The
>> management model
>>
>> Either I'm not doing something basic correctly, the management model
>> is out of sync, or the API is not fully implemented.
>>
>> Comments ?
>>
>> Thanks,
>> Arun
>>
>
>
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> 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  Wed Jan  8 04:55:00 2014
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Wed, 08 Jan 2014 09:55:00 +0000
Subject: [wildfly-dev] Removing curl support from management HTTP
Message-ID: <52CD2074.7050501@jboss.com>

Hello all,

Just starting to plan some upstream changes for WildFly and just wanted 
to gauge how much simple http tools like curl are in use?

If we were to completely disable their use would it cause problems?

Note: Where management messages are sent in using code to construct a 
HTTP request this will still be possible with minor changes to the 
message exchanges.

Regards,
Darran Lofthouse.

From hrupp at redhat.com  Wed Jan  8 05:42:32 2014
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Wed, 8 Jan 2014 11:42:32 +0100
Subject: [wildfly-dev] Removing curl support from management HTTP
In-Reply-To: <52CD2074.7050501@jboss.com>
References: <52CD2074.7050501@jboss.com>
Message-ID: <CC7B0C50-E120-436D-ABDD-C305A191B487@redhat.com>

Curl is what admins often use in their shell scripts .. I would at least continue supporting it for read-access



From lthon at redhat.com  Wed Jan  8 06:58:17 2014
From: lthon at redhat.com (Ladislav Thon)
Date: Wed, 8 Jan 2014 06:58:17 -0500 (EST)
Subject: [wildfly-dev] Removing curl support from management HTTP
In-Reply-To: <52CD2074.7050501@jboss.com>
References: <52CD2074.7050501@jboss.com>
Message-ID: <604383443.14887255.1389182297622.JavaMail.root@redhat.com>

> Just starting to plan some upstream changes for WildFly and just wanted
> to gauge how much simple http tools like curl are in use?
> 
> If we were to completely disable their use would it cause problems?

That would be a blocker regression for me :-)

Could you share what's the reasoning behind this? I use curl basically for everything that supports HTTP interaction (unless I build a specialized tool, but even then, I use curl for debugging the tool. It's immensely useful and I would hate losing it).

LT

From darran.lofthouse at jboss.com  Wed Jan  8 07:35:00 2014
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Wed, 08 Jan 2014 12:35:00 +0000
Subject: [wildfly-dev] Removing curl support from management HTTP
In-Reply-To: <604383443.14887255.1389182297622.JavaMail.root@redhat.com>
References: <52CD2074.7050501@jboss.com>
	<604383443.14887255.1389182297622.JavaMail.root@redhat.com>
Message-ID: <52CD45F4.6090204@jboss.com>

Hello Ladislav,

No 'reasoning' as such at this point, and no decisions taken yet.  We 
are currently discussing the future of domain management especially over 
HTTP and I need to understand how important tools like this are.

We originally had support for standard HTTP clients on the requirements 
list, just need to validate now if it was a valid requirement ;-)

Regards,
Darran Lofthouse.


On 08/01/14 11:58, Ladislav Thon wrote:
>> Just starting to plan some upstream changes for WildFly and just wanted
>> to gauge how much simple http tools like curl are in use?
>>
>> If we were to completely disable their use would it cause problems?
>
> That would be a blocker regression for me :-)
>
> Could you share what's the reasoning behind this? I use curl basically for everything that supports HTTP interaction (unless I build a specialized tool, but even then, I use curl for debugging the tool. It's immensely useful and I would hate losing it).
>
> LT
>

From arun.gupta at gmail.com  Wed Jan  8 08:59:03 2014
From: arun.gupta at gmail.com (Arun Gupta)
Date: Wed, 8 Jan 2014 05:59:03 -0800
Subject: [wildfly-dev] Removing curl support from management HTTP
In-Reply-To: <52CD45F4.6090204@jboss.com>
References: <52CD2074.7050501@jboss.com>
	<604383443.14887255.1389182297622.JavaMail.root@redhat.com>
	<52CD45F4.6090204@jboss.com>
Message-ID: <CAGBoHQWTrbbcEBauKFroJBXQAkuYSfYMfy6MbXeF1biMKH15iQ@mail.gmail.com>

I would agree with Heiko, Curl is often used by admins in their shell
scripts. This makes their scripts portable.

Is there an overhead to supporting curl ?

Arun

On Wed, Jan 8, 2014 at 4:35 AM, Darran Lofthouse
<darran.lofthouse at jboss.com> wrote:
> Hello Ladislav,
>
> No 'reasoning' as such at this point, and no decisions taken yet.  We
> are currently discussing the future of domain management especially over
> HTTP and I need to understand how important tools like this are.
>
> We originally had support for standard HTTP clients on the requirements
> list, just need to validate now if it was a valid requirement ;-)
>
> Regards,
> Darran Lofthouse.
>
>
> On 08/01/14 11:58, Ladislav Thon wrote:
>>> Just starting to plan some upstream changes for WildFly and just wanted
>>> to gauge how much simple http tools like curl are in use?
>>>
>>> If we were to completely disable their use would it cause problems?
>>
>> That would be a blocker regression for me :-)
>>
>> Could you share what's the reasoning behind this? I use curl basically for everything that supports HTTP interaction (unless I build a specialized tool, but even then, I use curl for debugging the tool. It's immensely useful and I would hate losing it).
>>
>> LT
>>
> _______________________________________________
> 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  Wed Jan  8 09:36:42 2014
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Wed, 08 Jan 2014 14:36:42 +0000
Subject: [wildfly-dev] Removing curl support from management HTTP
In-Reply-To: <CAGBoHQWTrbbcEBauKFroJBXQAkuYSfYMfy6MbXeF1biMKH15iQ@mail.gmail.com>
References: <52CD2074.7050501@jboss.com>	<604383443.14887255.1389182297622.JavaMail.root@redhat.com>	<52CD45F4.6090204@jboss.com>
	<CAGBoHQWTrbbcEBauKFroJBXQAkuYSfYMfy6MbXeF1biMKH15iQ@mail.gmail.com>
Message-ID: <52CD627A.5010703@jboss.com>

On 08/01/14 13:59, Arun Gupta wrote:
> I would agree with Heiko, Curl is often used by admins in their shell
> scripts. This makes their scripts portable.
>
> Is there an overhead to supporting curl ?

Not necessarily, new features are being discussed regarding 
authentication at this point I am just trying to confirm if my 
perception that users are using tools like curl is actually true ;-)

>
> Arun
>
> On Wed, Jan 8, 2014 at 4:35 AM, Darran Lofthouse
> <darran.lofthouse at jboss.com> wrote:
>> Hello Ladislav,
>>
>> No 'reasoning' as such at this point, and no decisions taken yet.  We
>> are currently discussing the future of domain management especially over
>> HTTP and I need to understand how important tools like this are.
>>
>> We originally had support for standard HTTP clients on the requirements
>> list, just need to validate now if it was a valid requirement ;-)
>>
>> Regards,
>> Darran Lofthouse.
>>
>>
>> On 08/01/14 11:58, Ladislav Thon wrote:
>>>> Just starting to plan some upstream changes for WildFly and just wanted
>>>> to gauge how much simple http tools like curl are in use?
>>>>
>>>> If we were to completely disable their use would it cause problems?
>>>
>>> That would be a blocker regression for me :-)
>>>
>>> Could you share what's the reasoning behind this? I use curl basically for everything that supports HTTP interaction (unless I build a specialized tool, but even then, I use curl for debugging the tool. It's immensely useful and I would hate losing it).
>>>
>>> LT
>>>
>> _______________________________________________
>> 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 Jan  8 10:15:47 2014
From: arun.gupta at gmail.com (Arun Gupta)
Date: Wed, 8 Jan 2014 07:15:47 -0800
Subject: [wildfly-dev] Removing curl support from management HTTP
In-Reply-To: <52CD627A.5010703@jboss.com>
References: <52CD2074.7050501@jboss.com>
	<604383443.14887255.1389182297622.JavaMail.root@redhat.com>
	<52CD45F4.6090204@jboss.com>
	<CAGBoHQWTrbbcEBauKFroJBXQAkuYSfYMfy6MbXeF1biMKH15iQ@mail.gmail.com>
	<52CD627A.5010703@jboss.com>
Message-ID: <CAGBoHQUrpPBXaa+swaT4e_2z=jq8n66ERx0bqA9Xyvs9diN8zQ@mail.gmail.com>

+1 that we should keep curl support :-)

On Wed, Jan 8, 2014 at 6:36 AM, Darran Lofthouse
<darran.lofthouse at jboss.com> wrote:
> On 08/01/14 13:59, Arun Gupta wrote:
>>
>> I would agree with Heiko, Curl is often used by admins in their shell
>> scripts. This makes their scripts portable.
>>
>> Is there an overhead to supporting curl ?
>
>
> Not necessarily, new features are being discussed regarding authentication
> at this point I am just trying to confirm if my perception that users are
> using tools like curl is actually true ;-)
>
>
>>
>> Arun
>>
>> On Wed, Jan 8, 2014 at 4:35 AM, Darran Lofthouse
>> <darran.lofthouse at jboss.com> wrote:
>>>
>>> Hello Ladislav,
>>>
>>> No 'reasoning' as such at this point, and no decisions taken yet.  We
>>> are currently discussing the future of domain management especially over
>>> HTTP and I need to understand how important tools like this are.
>>>
>>> We originally had support for standard HTTP clients on the requirements
>>> list, just need to validate now if it was a valid requirement ;-)
>>>
>>> Regards,
>>> Darran Lofthouse.
>>>
>>>
>>> On 08/01/14 11:58, Ladislav Thon wrote:
>>>>>
>>>>> Just starting to plan some upstream changes for WildFly and just wanted
>>>>> to gauge how much simple http tools like curl are in use?
>>>>>
>>>>> If we were to completely disable their use would it cause problems?
>>>>
>>>>
>>>> That would be a blocker regression for me :-)
>>>>
>>>> Could you share what's the reasoning behind this? I use curl basically
>>>> for everything that supports HTTP interaction (unless I build a specialized
>>>> tool, but even then, I use curl for debugging the tool. It's immensely
>>>> useful and I would hate losing it).
>>>>
>>>> LT
>>>>
>>> _______________________________________________
>>> 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 tsegismo at redhat.com  Wed Jan  8 10:39:31 2014
From: tsegismo at redhat.com (Thomas Segismont)
Date: Wed, 08 Jan 2014 16:39:31 +0100
Subject: [wildfly-dev] Removing curl support from management HTTP
In-Reply-To: <52CD627A.5010703@jboss.com>
References: <52CD2074.7050501@jboss.com>	<604383443.14887255.1389182297622.JavaMail.root@redhat.com>	<52CD45F4.6090204@jboss.com>	<CAGBoHQWTrbbcEBauKFroJBXQAkuYSfYMfy6MbXeF1biMKH15iQ@mail.gmail.com>
	<52CD627A.5010703@jboss.com>
Message-ID: <52CD7133.4040204@redhat.com>

Le 08/01/2014 15:36, Darran Lofthouse a ?crit :
> Not necessarily, new features are being discussed regarding
> authentication at this point I am just trying to confirm if my
> perception that users are using tools like curl is actually true ;-)

Sorry this is maybe a stupid question but what do you mean by "curl 
support"? Is there anything special done when the HTTP client is curl?

Thomas


From darran.lofthouse at jboss.com  Wed Jan  8 12:01:57 2014
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Wed, 08 Jan 2014 17:01:57 +0000
Subject: [wildfly-dev] Removing curl support from management HTTP
In-Reply-To: <52CD7133.4040204@redhat.com>
References: <52CD2074.7050501@jboss.com>	<604383443.14887255.1389182297622.JavaMail.root@redhat.com>	<52CD45F4.6090204@jboss.com>	<CAGBoHQWTrbbcEBauKFroJBXQAkuYSfYMfy6MbXeF1biMKH15iQ@mail.gmail.com>	<52CD627A.5010703@jboss.com>
	<52CD7133.4040204@redhat.com>
Message-ID: <52CD8485.7050008@jboss.com>



On 08/01/14 15:39, Thomas Segismont wrote:
> Le 08/01/2014 15:36, Darran Lofthouse a ?crit :
>> Not necessarily, new features are being discussed regarding
>> authentication at this point I am just trying to confirm if my
>> perception that users are using tools like curl is actually true ;-)
>
> Sorry this is maybe a stupid question but what do you mean by "curl
> support"? Is there anything special done when the HTTP client is curl?

As it stands today as we are only using the standard HTTP authentication 
mechanisms there is nothing special other than maybe a --digest argument 
to make a call using curl.

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

From filippespolti at gmail.com  Wed Jan  8 12:20:51 2014
From: filippespolti at gmail.com (Filippe Costa Spolti)
Date: Wed, 08 Jan 2014 15:20:51 -0200
Subject: [wildfly-dev] Remoting port
Message-ID: <52CD88F3.9060809@gmail.com>

Hello guys.

Let me ask something.

In the WildFly announcements says that the remoting port was deprecated, 
but in WFLY CR1 the port still present.
Here: http://wildfly.org/news/2013/12/21/WildFly8-CR1-Released/

But when i start the standalone mode the port 9990 appears:

[root at wfly_tests ~]# netstat -anp | grep java
tcp        0      0 127.0.0.1:9999 0.0.0.0:*                   
LISTEN      3070/java
tcp        0      0 192.168.11.109:8080 0.0.0.0:*                   
LISTEN      3070/java
tcp        0      0 127.0.0.1:9990 0.0.0.0:*                   
LISTEN      3070/java

This port will be removed only in the Final version?

-- 
Regards,
______________________________________
Filippe Costa Spolti
Linux User n?515639 - http://counter.li.org/
filippespolti at gmail.com
"Be yourself"
<http://www.linkedin.com/pub/filippe-costa-spolti/67/985/575>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140108/37f8b97d/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: linkedin.png
Type: image/png
Size: 957 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140108/37f8b97d/attachment.png 

From jgreene at redhat.com  Wed Jan  8 12:25:33 2014
From: jgreene at redhat.com (Jason Greene)
Date: Wed, 8 Jan 2014 12:25:33 -0500 (EST)
Subject: [wildfly-dev] Removing curl support from management HTTP
In-Reply-To: <52CD8485.7050008@jboss.com>
References: <52CD2074.7050501@jboss.com>
	<604383443.14887255.1389182297622.JavaMail.root@redhat.com>
	<52CD45F4.6090204@jboss.com>
	<CAGBoHQWTrbbcEBauKFroJBXQAkuYSfYMfy6MbXeF1biMKH15iQ@mail.gmail.com>
	<52CD627A.5010703@jboss.com> <52CD7133.4040204@redhat.com>
	<52CD8485.7050008@jboss.com>
Message-ID: <8EFBFA4E-A372-4256-8240-5C36BB28312F@redhat.com>

So the big problem is that http digest has not been updated to use stronger  crypto hash. There is a proposed RFC but no one has implemented it.

We could implement it and contribute that to curl as well but I suspect we still need standard digest compatibility until most OS's have caught up with that version of curl.

Alternatively we could move to SSL by default, and switch to plain with scrypt and solve the various challenges there.

> On Jan 8, 2014, at 11:02 AM, Darran Lofthouse <darran.lofthouse at jboss.com> wrote:
> 
> 
> 
>> On 08/01/14 15:39, Thomas Segismont wrote:
>> Le 08/01/2014 15:36, Darran Lofthouse a ?crit :
>>> Not necessarily, new features are being discussed regarding
>>> authentication at this point I am just trying to confirm if my
>>> perception that users are using tools like curl is actually true ;-)
>> 
>> Sorry this is maybe a stupid question but what do you mean by "curl
>> support"? Is there anything special done when the HTTP client is curl?
> 
> As it stands today as we are only using the standard HTTP authentication 
> mechanisms there is nothing special other than maybe a --digest argument 
> to make a call using curl.
> 
>> 
>> Thomas
>> 
>> _______________________________________________
>> 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 jgreene at redhat.com  Wed Jan  8 12:27:08 2014
From: jgreene at redhat.com (Jason Greene)
Date: Wed, 8 Jan 2014 12:27:08 -0500 (EST)
Subject: [wildfly-dev] Remoting port
In-Reply-To: <52CD88F3.9060809@gmail.com>
References: <52CD88F3.9060809@gmail.com>
Message-ID: <2ECD5FA5-7EFD-4E03-A853-7E9D10BDF87D@redhat.com>

That's correct. The plan is to remove by Final once we make sure that various tools and ides are using the new http upgrade mechanism.

Sent from my iPhone

> On Jan 8, 2014, at 11:21 AM, Filippe Costa Spolti <filippespolti at gmail.com> wrote:
> 
> Hello guys.
> 
> Let me ask something.
> 
> In the WildFly announcements says that the remoting port was deprecated, but in WFLY CR1 the port still present.
> Here: http://wildfly.org/news/2013/12/21/WildFly8-CR1-Released/
> 
> But when i start the standalone mode the port 9990 appears: 
> 
> [root at wfly_tests ~]# netstat -anp | grep java 
> tcp        0      0 127.0.0.1:9999                  0.0.0.0:*                   LISTEN      3070/java 
> tcp        0      0 192.168.11.109:8080             0.0.0.0:*                   LISTEN      3070/java 
> tcp        0      0 127.0.0.1:9990                  0.0.0.0:*                   LISTEN      3070/java
> 
> This port will be removed only in the Final version?
> 
> -- 
> Regards,
> ______________________________________
> Filippe Costa Spolti
> Linux User n?515639 - http://counter.li.org/
> filippespolti at gmail.com
> "Be yourself"
> <linkedin.png>
> _______________________________________________
> 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/20140108/b1664cd3/attachment.html 

From brian.stansberry at redhat.com  Wed Jan  8 12:33:54 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 08 Jan 2014 11:33:54 -0600
Subject: [wildfly-dev] HTTP Management API
In-Reply-To: <CAGBoHQUQzPtMYxGwOp=iSCN3SeY=VTxXcwmP1enGtmF8C5C3JQ@mail.gmail.com>
References: <CAGBoHQVP=an8c9gVnnzunyf5oFCS1TPBEmgJbZHiid4t7EqD4w@mail.gmail.com>	<52CCB440.8080003@redhat.com>
	<CAGBoHQUQzPtMYxGwOp=iSCN3SeY=VTxXcwmP1enGtmF8C5C3JQ@mail.gmail.com>
Message-ID: <52CD8C02.6000300@redhat.com>

On 1/7/14, 11:46 PM, Arun Gupta wrote:
> I realized I was doing something basic incorrectly ;)
>
> For a standalone instance, should it not show the default data source:
>

It's in the ee subsystem. I believe there was a thread on this list a 
few months back if you're interested in why it's there. I don't trust 
myself to do justice to the reasoning. ;)

[standalone at localhost:9990 /] cd subsystem=ee/service=default-bindings
[standalone at localhost:9990 service=default-bindings] ls -l
ATTRIBUTE                          VALUE 
        TYPE
context-service 
java:jboss/ee/concurrency/context/default   STRING
datasource                         java:jboss/datasources/ExampleDS 
        STRING
jms-connection-factory 
java:jboss/DefaultJMSConnectionFactory      STRING
managed-executor-service 
java:jboss/ee/concurrency/executor/default  STRING
managed-scheduled-executor-service 
java:jboss/ee/concurrency/scheduler/default STRING
managed-thread-factory 
java:jboss/ee/concurrency/factory/default   STRING

> -- cut here --
> [standalone at localhost:9990 subsystem=datasources] ls
>
> data-source
>
> jdbc-driver
>
> xa-data-source
>
> installed-drivers=[{"driver-name" => "h2","deployment-name" =>
> undefined,"driver-module-name" => "com.h2database.h2","module-slot" =>
> "main","driver-datasource-class-name" =>
> "","driver-xa-datasource-class-name" =>
> "org.h2.jdbcx.JdbcDataSource","driver-class-name" =>
> "org.h2.Driver","driver-major-version" => 1,"driver-minor-version" =>
> 3,"jdbc-compliant" => true}]
> -- cut here --
>
> How do I know which commands are targeted to domain host controller ?
>

For low level operations, use the 
:read-resource-description(operations=true) op to determine the relevant 
API for a resource.

For high level commands, the set of commands the CLI offers is tailored 
to the type of process to which you are connected. Start the CLI 
(without the -c param) and hit tab from the root resource prompt; you 
get a limited set of options. Then run the "connect" command and hit tab 
again; the options are greater and there will be small differences 
depending on whether the process is a standalone server or a host 
controller.


> product-name, product-version,

Because WildFly is not a Red Hat product. ;) These only have values with 
EAP, SOAP, etc.

> profile-name are returning "undefined".
>

I'm tempted to remove this from the standalone server API. It's only 
relevant to a managed domain server, where it identifies the name of the 
profile mapped to the server's server group. There is no name for the 
profile being run by a standalone server.

> Is there a typical set of operations that can be incorporated in a
> WildFly hands-on lab for standalone and domain host controller ?
>

I've attached a text file with a kind of script (as in movie, not as in 
software) for the demo that makes up the bulk of my "JBoss EAP CLI: 
Ninja Management" presentation. It takes quite a while to go through all 
that with me typing and talking, but it's at least an outline of the 
stuff I thought was important to cover.

Ping me privately if you'd like more details.


> Arun
>
> On Tue, Jan 7, 2014 at 6:13 PM, Brian Stansberry
> <brian.stansberry at redhat.com> wrote:
>> Are you connecting to a domain host controller? The examples are for a
>> standalone server.
>>
>> On 1/7/14, 7:24 PM, Arun Gupta wrote:
>>> Hi there ...
>>>
>>> I'm trying some samples from:
>>>
>>> https://docs.jboss.org/author/display/WFLY8/The+HTTP+management+API
>>>
>>> and have questions/comments.
>>>
>>> 1). First one is giving:
>>>
>>> curl --digest -L -D - http://localhost:9990/management --header
>>> "Content-Type: application/json" -d
>>> '{"operation":"read-attribute","name":"server-state","json.pretty":1}'
>>> -u u3:p3
>>> HTTP/1.1 401 Unauthorized
>>> Connection: keep-alive
>>> WWW-Authenticate: Digest
>>> realm="ManagementRealm",domain="/management",nonce="n6l3IRhNwTwNMTM4OTE0MjA3MTE4N55G54PM/ll8QrzSK+RrvTM=",opaque="00000000000000000000000000000000",algorithm=MD5
>>> Content-Length: 77
>>> Content-Type: text/html
>>>
>>> HTTP/1.1 500 Internal Server Error
>>> Connection: keep-alive
>>> Authentication-Info:
>>> nextnonce="I7Yrew1s+j4NMTM4OTE0MjA3MTE4NxXgrLGjS/rWgbUveRrchio="
>>> Content-Type: text/plain;utf-8
>>> Content-Length: 128
>>>
>>> {
>>>       "outcome" : "failed",
>>>       "failure-description" : "JBAS014792: Unknown attribute server-state",
>>>       "rolled-back" : true
>>> }
>>>
>>> http://wildscribe.github.io/Wildfly/8.0.0.CR1/index.html shows
>>> server-state as a valid attribute.
>>>
>>> Similar error for:
>>>
>>> "JBAS014792: Unknown attribute profile-name"
>>>
>>> Reading product-name and product-version returns:
>>>
>>> {"outcome" : "success", "result" : null}
>>>
>>> "name" attribute returns:
>>>
>>> {"outcome" : "success", "result" : "Unnamed Domain"}
>>>
>>> 2). curl --digest -L -D - http://localhost:9990/management --header
>>> "Content-Type: application/json" -d
>>> '{"operation":"whoami","json.pretty":1}' -u u3:p3
>>>
>>> does not return pretty JSON and instead returns:
>>>
>>> {"outcome" : "success", "result" : {"identity" : {"username" : "u3",
>>> "realm" : "ManagementRealm"}}}
>>>
>>> release-name and release-version returned correct values.
>>>
>>> 3). I think a restart-server operation would be useful.
>>>
>>> 4). Why is the following command failing:
>>>
>>>    curl --digest -D - http://localhost:9990/management --header
>>> "Content-Type: application/json" -d '{"operation":"read-resource",
>>> "address":["subsystem","data-sources"], "json.pretty":1}' -u u3:p3
>>> HTTP/1.1 401 Unauthorized
>>> Connection: keep-alive
>>> WWW-Authenticate: Digest
>>> realm="ManagementRealm",domain="/management",nonce="2oB+bvt990QNMTM4OTE0MzQ4Nzc0NkxPJHWOl6yAkN/F7PGdbYo=",opaque="00000000000000000000000000000000",algorithm=MD5
>>> Content-Length: 77
>>> Content-Type: text/html
>>>
>>> HTTP/1.1 500 Internal Server Error
>>> Connection: keep-alive
>>> Authentication-Info:
>>> nextnonce="JXNHCPPtBVwNMTM4OTE0MzQ4Nzc0N5YLxVykiaapgV5zTDnV++I="
>>> Content-Type: text/plain;utf-8
>>> Content-Length: 184
>>>
>>> {
>>>       "outcome" : "failed",
>>>       "failure-description" : "JBAS014883: No resource definition is
>>> registered for address [(\"subsystem\" => \"data-sources\")]",
>>>       "rolled-back" : true
>>> }
>>>
>>> Even though there is a default data source already registered. The
>>> management model
>>>
>>> Either I'm not doing something basic correctly, the management model
>>> is out of sync, or the API is not fully implemented.
>>>
>>> Comments ?
>>>
>>> Thanks,
>>> Arun
>>>
>>
>>
>> --
>> Brian Stansberry
>> Senior Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
-------------- next part --------------
CLI demo plan:

1) Start standalone server
2) Start CLI, connect
3) tab
4) ls
5) ls -l
6) cd and tab completion to /subsystem=web/connector=http
7) read-attribute bytesSent
8) read-attribute bytesSent --verbose
9) access the root webapp
10) read-attribute bytesSent
10) :read-resource
10) :read-resource(include-runtime=true)
11) :read-resource-description
12) /deployment=kitchensink.ear:read-resource(include-runtime=true,recursive=true)
12) change some setting (JCA pool size)
13) batch
14) add jms queue
15) deploy the war
19) deploy the mdb
16) show app, add 3
18) run CLI with a file to remove everything
13) change HTTP port
14) reload
15) change it back, but with shutdown ?restart=true


20) disable local-auth
21) connect, authenticate

31) Start 3 hosts, master, 2 slaves
32) add a new server group
33) add a server in the group on each host
34) deploy w/ rollout plan
35) save rollout plan
36) undeploy with rollout plan


40) show and execute a bash script to stop 2 hosts

From filippespolti at gmail.com  Wed Jan  8 12:57:52 2014
From: filippespolti at gmail.com (Filippe Costa Spolti)
Date: Wed, 08 Jan 2014 15:57:52 -0200
Subject: [wildfly-dev] Remoting port
In-Reply-To: <2ECD5FA5-7EFD-4E03-A853-7E9D10BDF87D@redhat.com>
References: <52CD88F3.9060809@gmail.com>
	<2ECD5FA5-7EFD-4E03-A853-7E9D10BDF87D@redhat.com>
Message-ID: <52CD91A0.1050709@gmail.com>

Nice, tks.

Regards,
______________________________________
Filippe Costa Spolti
Linux User n?515639 - http://counter.li.org/
filippespolti at gmail.com
"Be yourself"
<http://www.linkedin.com/pub/filippe-costa-spolti/67/985/575>
On 01/08/2014 03:27 PM, Jason Greene wrote:
> That's correct. The plan is to remove by Final once we make sure that 
> various tools and ides are using the new http upgrade mechanism.
>
> Sent from my iPhone
>
> On Jan 8, 2014, at 11:21 AM, Filippe Costa Spolti 
> <filippespolti at gmail.com <mailto:filippespolti at gmail.com>> wrote:
>
>> Hello guys.
>>
>> Let me ask something.
>>
>> In the WildFly announcements says that the remoting port was 
>> deprecated, but in WFLY CR1 the port still present.
>> Here: http://wildfly.org/news/2013/12/21/WildFly8-CR1-Released/
>>
>> But when i start the standalone mode the port 9990 appears:
>>
>> [root at wfly_tests ~]# netstat -anp | grep java
>> tcp        0      0 127.0.0.1:9999 0.0.0.0:*                   
>> LISTEN      3070/java
>> tcp        0      0 192.168.11.109:8080 0.0.0.0:*                   
>> LISTEN      3070/java
>> tcp        0      0 127.0.0.1:9990 0.0.0.0:*                   
>> LISTEN      3070/java
>>
>> This port will be removed only in the Final version?
>>
>> -- 
>> Regards,
>> ______________________________________
>> Filippe Costa Spolti
>> Linux User n?515639 - http://counter.li.org/
>> filippespolti at gmail.com
>> "Be yourself"
>> <linkedin.png> 
>> <http://www.linkedin.com/pub/filippe-costa-spolti/67/985/575>
>> _______________________________________________
>> 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/20140108/2869dcf4/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: linkedin.png
Type: image/png
Size: 957 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140108/2869dcf4/attachment-0001.png 

From akostadi at redhat.com  Wed Jan  8 15:00:59 2014
From: akostadi at redhat.com (Aleksandar Kostadinov)
Date: Wed, 08 Jan 2014 22:00:59 +0200
Subject: [wildfly-dev] Removing curl support from management HTTP
In-Reply-To: <8EFBFA4E-A372-4256-8240-5C36BB28312F@redhat.com>
References: <52CD2074.7050501@jboss.com>	<604383443.14887255.1389182297622.JavaMail.root@redhat.com>	<52CD45F4.6090204@jboss.com>	<CAGBoHQWTrbbcEBauKFroJBXQAkuYSfYMfy6MbXeF1biMKH15iQ@mail.gmail.com>	<52CD627A.5010703@jboss.com>
	<52CD7133.4040204@redhat.com>	<52CD8485.7050008@jboss.com>
	<8EFBFA4E-A372-4256-8240-5C36BB28312F@redhat.com>
Message-ID: <52CDAE7B.1070306@redhat.com>

I'm not sure what other auth mechanism you are talking about. There 
might be something new and very elaborated.

But the problem with non-encrypted connections is that any hash could be 
used without the need to recover the plain text password. With cookies, 
one can sniff and use them.
Yes, it is somehow worse to steal the plaintext password but at the end 
do benefits outweight the inconvenience and effort?

Jason Greene wrote, On 01/08/2014 07:25 PM (EEST):
> So the big problem is that http digest has not been updated to use stronger  crypto hash. There is a proposed RFC but no one has implemented it.
>
> We could implement it and contribute that to curl as well but I suspect we still need standard digest compatibility until most OS's have caught up with that version of curl.
>
> Alternatively we could move to SSL by default, and switch to plain with scrypt and solve the various challenges there.
>
>> On Jan 8, 2014, at 11:02 AM, Darran Lofthouse <darran.lofthouse at jboss.com> wrote:
>>
>>
>>
>>> On 08/01/14 15:39, Thomas Segismont wrote:
>>> Le 08/01/2014 15:36, Darran Lofthouse a ?crit :
>>>> Not necessarily, new features are being discussed regarding
>>>> authentication at this point I am just trying to confirm if my
>>>> perception that users are using tools like curl is actually true ;-)
>>>
>>> Sorry this is maybe a stupid question but what do you mean by "curl
>>> support"? Is there anything special done when the HTTP client is curl?
>>
>> As it stands today as we are only using the standard HTTP authentication
>> mechanisms there is nothing special other than maybe a --digest argument
>> to make a call using curl.
>>
>>>
>>> Thomas
>>>
>>> _______________________________________________
>>> 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 darran.lofthouse at jboss.com  Wed Jan  8 15:19:12 2014
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Wed, 08 Jan 2014 20:19:12 +0000
Subject: [wildfly-dev] Removing curl support from management HTTP
In-Reply-To: <52CDAE7B.1070306@redhat.com>
References: <52CD2074.7050501@jboss.com>	<604383443.14887255.1389182297622.JavaMail.root@redhat.com>	<52CD45F4.6090204@jboss.com>	<CAGBoHQWTrbbcEBauKFroJBXQAkuYSfYMfy6MbXeF1biMKH15iQ@mail.gmail.com>	<52CD627A.5010703@jboss.com>	<52CD7133.4040204@redhat.com>	<52CD8485.7050008@jboss.com>	<8EFBFA4E-A372-4256-8240-5C36BB28312F@redhat.com>
	<52CDAE7B.1070306@redhat.com>
Message-ID: <52CDB2C0.6060401@jboss.com>



On 08/01/14 20:00, Aleksandar Kostadinov wrote:
> I'm not sure what other auth mechanism you are talking about. There
> might be something new and very elaborated.
>
> But the problem with non-encrypted connections is that any hash could be
> used without the need to recover the plain text password.

They still need to go through the trouble of processing the hash to 
discover the password used to create the hash.

However I will start some threads later on the actual changes, all I am 
looking for at the moment is to verify how widely tools like curl are 
currently used to confirm if we need to spend time considering them.

> With cookies,
> one can sniff and use them.
> Yes, it is somehow worse to steal the plaintext password but at the end
> do benefits outweight the inconvenience and effort?
>
> Jason Greene wrote, On 01/08/2014 07:25 PM (EEST):
>> So the big problem is that http digest has not been updated to use stronger  crypto hash. There is a proposed RFC but no one has implemented it.
>>
>> We could implement it and contribute that to curl as well but I suspect we still need standard digest compatibility until most OS's have caught up with that version of curl.
>>
>> Alternatively we could move to SSL by default, and switch to plain with scrypt and solve the various challenges there.
>>
>>> On Jan 8, 2014, at 11:02 AM, Darran Lofthouse <darran.lofthouse at jboss.com> wrote:
>>>
>>>
>>>
>>>> On 08/01/14 15:39, Thomas Segismont wrote:
>>>> Le 08/01/2014 15:36, Darran Lofthouse a ?crit :
>>>>> Not necessarily, new features are being discussed regarding
>>>>> authentication at this point I am just trying to confirm if my
>>>>> perception that users are using tools like curl is actually true ;-)
>>>>
>>>> Sorry this is maybe a stupid question but what do you mean by "curl
>>>> support"? Is there anything special done when the HTTP client is curl?
>>>
>>> As it stands today as we are only using the standard HTTP authentication
>>> mechanisms there is nothing special other than maybe a --digest argument
>>> to make a call using curl.
>>>
>>>>
>>>> Thomas
>>>>
>>>> _______________________________________________
>>>> 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 jason.greene at redhat.com  Wed Jan  8 15:54:25 2014
From: jason.greene at redhat.com (Jason Greene)
Date: Wed, 8 Jan 2014 14:54:25 -0600
Subject: [wildfly-dev] Removing curl support from management HTTP
In-Reply-To: <52CDAE7B.1070306@redhat.com>
References: <52CD2074.7050501@jboss.com>	<604383443.14887255.1389182297622.JavaMail.root@redhat.com>	<52CD45F4.6090204@jboss.com>	<CAGBoHQWTrbbcEBauKFroJBXQAkuYSfYMfy6MbXeF1biMKH15iQ@mail.gmail.com>	<52CD627A.5010703@jboss.com>
	<52CD7133.4040204@redhat.com>	<52CD8485.7050008@jboss.com>
	<8EFBFA4E-A372-4256-8240-5C36BB28312F@redhat.com>
	<52CDAE7B.1070306@redhat.com>
Message-ID: <6BF53C68-5183-4079-B7D1-C8B73EFFB6FA@redhat.com>


On Jan 8, 2014, at 2:00 PM, Aleksandar Kostadinov <akostadi at redhat.com> wrote:

> I'm not sure what other auth mechanism you are talking about. There 
> might be something new and very elaborated.

Just a SHA based digest vs an MD5 one

> 
> But the problem with non-encrypted connections is that any hash could be 
> used without the need to recover the plain text password. With cookies, 
> one can sniff and use them.

That?s not true. Digest is a challenge response protocol that uses a nonce as part of the sent hash. A packet sniffed hash can?t be replayed. 

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



From rodakr at gmx.ch  Wed Jan  8 16:24:51 2014
From: rodakr at gmx.ch (Radoslaw Rodak)
Date: Wed, 8 Jan 2014 22:24:51 +0100
Subject: [wildfly-dev] Removing curl support from management HTTP
In-Reply-To: <6BF53C68-5183-4079-B7D1-C8B73EFFB6FA@redhat.com>
References: <52CD2074.7050501@jboss.com>	<604383443.14887255.1389182297622.JavaMail.root@redhat.com>	<52CD45F4.6090204@jboss.com>	<CAGBoHQWTrbbcEBauKFroJBXQAkuYSfYMfy6MbXeF1biMKH15iQ@mail.gmail.com>	<52CD627A.5010703@jboss.com>
	<52CD7133.4040204@redhat.com>	<52CD8485.7050008@jboss.com>
	<8EFBFA4E-A372-4256-8240-5C36BB28312F@redhat.com>
	<52CDAE7B.1070306@redhat.com>
	<6BF53C68-5183-4079-B7D1-C8B73EFFB6FA@redhat.com>
Message-ID: <3FF1EB73-A45E-4F5F-B227-015285C138AE@gmx.ch>

Hi

It starts to be interesting :-)
Whats about hash length extension attack...

https://blog.whitehatsec.com/hash-length-extension-attacks/

Cheers Radek


Am 08.01.2014 um 21:54 schrieb Jason Greene <jason.greene at redhat.com>:

> 
> On Jan 8, 2014, at 2:00 PM, Aleksandar Kostadinov <akostadi at redhat.com> wrote:
> 
>> I'm not sure what other auth mechanism you are talking about. There 
>> might be something new and very elaborated.
> 
> Just a SHA based digest vs an MD5 one
> 
>> 
>> But the problem with non-encrypted connections is that any hash could be 
>> used without the need to recover the plain text password. With cookies, 
>> one can sniff and use them.
> 
> That?s not true. Digest is a challenge response protocol that uses a nonce as part of the sent hash. A packet sniffed hash can?t be replayed. 
> 
> --
> 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  Wed Jan  8 16:46:31 2014
From: jason.greene at redhat.com (Jason Greene)
Date: Wed, 8 Jan 2014 15:46:31 -0600
Subject: [wildfly-dev] Removing curl support from management HTTP
In-Reply-To: <6BF53C68-5183-4079-B7D1-C8B73EFFB6FA@redhat.com>
References: <52CD2074.7050501@jboss.com>	<604383443.14887255.1389182297622.JavaMail.root@redhat.com>	<52CD45F4.6090204@jboss.com>	<CAGBoHQWTrbbcEBauKFroJBXQAkuYSfYMfy6MbXeF1biMKH15iQ@mail.gmail.com>	<52CD627A.5010703@jboss.com>
	<52CD7133.4040204@redhat.com>	<52CD8485.7050008@jboss.com>
	<8EFBFA4E-A372-4256-8240-5C36BB28312F@redhat.com>
	<52CDAE7B.1070306@redhat.com>
	<6BF53C68-5183-4079-B7D1-C8B73EFFB6FA@redhat.com>
Message-ID: <A6434EC5-2378-489B-90CD-45288B8C1C58@redhat.com>


On Jan 8, 2014, at 2:54 PM, Jason Greene <jason.greene at redhat.com> wrote:

> 
> On Jan 8, 2014, at 2:00 PM, Aleksandar Kostadinov <akostadi at redhat.com> wrote:
> 
>> I'm not sure what other auth mechanism you are talking about. There 
>> might be something new and very elaborated.
> 
> Just a SHA based digest vs an MD5 one

https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/?include_text=1

It?s in draft state which is why no one has implemented it yet.

> 
>> 
>> But the problem with non-encrypted connections is that any hash could be 
>> used without the need to recover the plain text password. With cookies, 
>> one can sniff and use them.
> 
> That?s not true. Digest is a challenge response protocol that uses a nonce as part of the sent hash. A packet sniffed hash can?t be replayed. 
> 
> --
> 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 jason.greene at redhat.com  Wed Jan  8 16:55:29 2014
From: jason.greene at redhat.com (Jason Greene)
Date: Wed, 8 Jan 2014 15:55:29 -0600
Subject: [wildfly-dev] Removing curl support from management HTTP
In-Reply-To: <3FF1EB73-A45E-4F5F-B227-015285C138AE@gmx.ch>
References: <52CD2074.7050501@jboss.com>	<604383443.14887255.1389182297622.JavaMail.root@redhat.com>	<52CD45F4.6090204@jboss.com>	<CAGBoHQWTrbbcEBauKFroJBXQAkuYSfYMfy6MbXeF1biMKH15iQ@mail.gmail.com>	<52CD627A.5010703@jboss.com>
	<52CD7133.4040204@redhat.com>	<52CD8485.7050008@jboss.com>
	<8EFBFA4E-A372-4256-8240-5C36BB28312F@redhat.com>
	<52CDAE7B.1070306@redhat.com>
	<6BF53C68-5183-4079-B7D1-C8B73EFFB6FA@redhat.com>
	<3FF1EB73-A45E-4F5F-B227-015285C138AE@gmx.ch>
Message-ID: <DE6B8288-84A5-4016-9AE8-37DF7EB42886@redhat.com>

That?s an attack against a signature where you know the content and the length of the secret. In a challenge response protocol this information is not known. 

On Jan 8, 2014, at 3:24 PM, Radoslaw Rodak <rodakr at gmx.ch> wrote:

> Hi
> 
> It starts to be interesting :-)
> Whats about hash length extension attack...
> 
> https://blog.whitehatsec.com/hash-length-extension-attacks/
> 
> Cheers Radek
> 
> 
> Am 08.01.2014 um 21:54 schrieb Jason Greene <jason.greene at redhat.com>:
> 
>> 
>> On Jan 8, 2014, at 2:00 PM, Aleksandar Kostadinov <akostadi at redhat.com> wrote:
>> 
>>> I'm not sure what other auth mechanism you are talking about. There 
>>> might be something new and very elaborated.
>> 
>> Just a SHA based digest vs an MD5 one
>> 
>>> 
>>> But the problem with non-encrypted connections is that any hash could be 
>>> used without the need to recover the plain text password. With cookies, 
>>> one can sniff and use them.
>> 
>> That?s not true. Digest is a challenge response protocol that uses a nonce as part of the sent hash. A packet sniffed hash can?t be replayed. 
>> 
>> --
>> 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 arjan.tijms at gmail.com  Wed Jan  8 17:32:46 2014
From: arjan.tijms at gmail.com (arjan tijms)
Date: Wed, 8 Jan 2014 23:32:46 +0100
Subject: [wildfly-dev] 13 JASPIC tests failing on WildFly
In-Reply-To: <CAE=-AhAhNyykap2Bjjf_eOqiW3FG3JOH74TQPRry3nSjRbmWHQ@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>
	<52A9F918.6080200@redhat.com>
	<CAE=-AhAhNyykap2Bjjf_eOqiW3FG3JOH74TQPRry3nSjRbmWHQ@mail.gmail.com>
Message-ID: <CAE=-AhD5pf3NEUhwVrwt==jMjoET00_-RSuTWYieEBpZcFpZqg@mail.gmail.com>

Hi,


> On Thu, Dec 12, 2013 at 6:57 PM, Stefan Guilhen <sguilhen at redhat.com>wrote:
>
>>  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.
>>
>

Just wondering if there has been some progress in the meantime. The JASPIC
tests unfortunately still don't run at all on WildFly.

I do have to update the tests to HtmlUnit though, and check whether there
is or isn't an exception after a 403. The original tests were based on
Drone and that one didn't threw an exception. GlassFish doesn't return a
403 by itself but just a blank response, so that's why I didn't catch this
one earlier.

Anyway, it would be great if we can work together to get the tests to run.

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

From jaromir.hamala at gmail.com  Thu Jan  9 05:20:21 2014
From: jaromir.hamala at gmail.com (Jaromir Hamala)
Date: Thu, 9 Jan 2014 10:20:21 +0000
Subject: [wildfly-dev] WildFly 8 - list of missing features?
Message-ID: <CAMxXA6_6ZT8dNNd3fNNRGmrZ6+UHDgiMY=7ttJH-w9GVgOQRag@mail.gmail.com>

Hi guys,

I wonder if there is a list of features implemented in JBoss AS 7, but
missing from the WildFly 8? It would make migration assessments way easier.
I stumbled upon the issue with SAML (
https://issues.jboss.org/browse/PLINK2-119) and I wonder what are the other
features missing in the current WildFly.

Cheers,
Jaromir


-- 
?Perfection is achieved, not when there is nothing more to add, but when
there is nothing left to take away.?
Antoine de Saint Exup?ry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140109/6ed6890b/attachment-0001.html 

From tomaz.cerar at gmail.com  Thu Jan  9 05:46:44 2014
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Thu, 9 Jan 2014 11:46:44 +0100
Subject: [wildfly-dev] WildFly 8 - list of missing features?
In-Reply-To: <CAMxXA6_6ZT8dNNd3fNNRGmrZ6+UHDgiMY=7ttJH-w9GVgOQRag@mail.gmail.com>
References: <CAMxXA6_6ZT8dNNd3fNNRGmrZ6+UHDgiMY=7ttJH-w9GVgOQRag@mail.gmail.com>
Message-ID: <CAMquZP4vyTh=7BH+hOiuGNn8-aN7QfNkJ5XAUOPwEhKVwsR4-g@mail.gmail.com>

Hi,

obvious things missing from WildFly are ones that ware removed:
- cmp, removed, as it is no longer EE7 requirement
- jaxr, removed, as it is no longer EE7 requirement
- osgi, removed as it was moved to separate project and can be re-added
manually

However the big thing we changed in WildFly is replacement of web server
from jbossweb to undertow (web subsystem to undertow subsystem).

There ware many things that ware integrated with jbossweb in it's specific
way (using valves for example) and things like that need to be migrated /
updated to be compatible with undertow.

Issue you linked is case of such incompatibility. It is hard to determine
how many other projects were relying on jbossweb/tomcat specific APIs so
producing any list would be quite hard.
All we could do is crate wiki page that list external projects and its
compatibility status.

My opinion is that beyond some custom auth mechanisms (what picketlink does
for example) most of things should work. As auth mechanisms APIs ware one
thing that (w)are tied to servlet container.

--
tomaz



On Thu, Jan 9, 2014 at 11:20 AM, Jaromir Hamala <jaromir.hamala at gmail.com>wrote:

> Hi guys,
>
> I wonder if there is a list of features implemented in JBoss AS 7, but
> missing from the WildFly 8? It would make migration assessments way easier.
> I stumbled upon the issue with SAML (
> https://issues.jboss.org/browse/PLINK2-119) and I wonder what are the
> other features missing in the current WildFly.
>
> Cheers,
> Jaromir
>
>
> --
> ?Perfection is achieved, not when there is nothing more to add, but when
> there is nothing left to take away.?
> Antoine de Saint Exup?ry
>
> _______________________________________________
> 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/20140109/be67c665/attachment.html 

From arjan.tijms at gmail.com  Thu Jan  9 05:56:38 2014
From: arjan.tijms at gmail.com (arjan tijms)
Date: Thu, 9 Jan 2014 11:56:38 +0100
Subject: [wildfly-dev] WildFly 8 - list of missing features?
In-Reply-To: <CAMxXA6_6ZT8dNNd3fNNRGmrZ6+UHDgiMY=7ttJH-w9GVgOQRag@mail.gmail.com>
References: <CAMxXA6_6ZT8dNNd3fNNRGmrZ6+UHDgiMY=7ttJH-w9GVgOQRag@mail.gmail.com>
Message-ID: <CAE=-AhBtjYsUms8LYGohGD22jQ_jvrDe8XtSmsJXh+YcOxzvtw@mail.gmail.com>

Hi,


On Thu, Jan 9, 2014 at 11:20 AM, Jaromir Hamala <jaromir.hamala at gmail.com>wrote:

> I wonder if there is a list of features implemented in JBoss AS 7, but
> missing from the WildFly 8? It would make migration assessments way easier.
>

Maybe JASPIC is still open. All the tests in the Java EE 7 samples project
are still failing. This may be an issue with the tests themselves, with the
way JASPIC needs to be setup in JBoss products (ideally no setup should be
needed, but alas), missing functionality or any combination of the above.

At any length, I can't yet run any application that depends on JASPIC on
WildFly, so this obviously makes migration of these apps impossible.

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

From tomaz.cerar at gmail.com  Thu Jan  9 06:07:17 2014
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Thu, 9 Jan 2014 12:07:17 +0100
Subject: [wildfly-dev] 13 JASPIC tests failing on WildFly
In-Reply-To: <CAE=-AhD5pf3NEUhwVrwt==jMjoET00_-RSuTWYieEBpZcFpZqg@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>
	<52A9F918.6080200@redhat.com>
	<CAE=-AhAhNyykap2Bjjf_eOqiW3FG3JOH74TQPRry3nSjRbmWHQ@mail.gmail.com>
	<CAE=-AhD5pf3NEUhwVrwt==jMjoET00_-RSuTWYieEBpZcFpZqg@mail.gmail.com>
Message-ID: <CAMquZP4E90nUWH6b0X1+SsOYOJ70QQocha=9Q1bvbCSpBGhZ3A@mail.gmail.com>

Hey,

this PR https://github.com/wildfly/wildfly/pull/5683 was merged yesterday,
can you check if it fixes any of your problems?

--
tomaz


On Wed, Jan 8, 2014 at 11:32 PM, arjan tijms <arjan.tijms at gmail.com> wrote:

> Hi,
>
>
>> On Thu, Dec 12, 2013 at 6:57 PM, Stefan Guilhen <sguilhen at redhat.com>wrote:
>>
>>>  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.
>>>
>>
>
> Just wondering if there has been some progress in the meantime. The JASPIC
> tests unfortunately still don't run at all on WildFly.
>
> I do have to update the tests to HtmlUnit though, and check whether there
> is or isn't an exception after a 403. The original tests were based on
> Drone and that one didn't threw an exception. GlassFish doesn't return a
> 403 by itself but just a blank response, so that's why I didn't catch this
> one earlier.
>
> Anyway, it would be great if we can work together to get the tests to run.
>
> Kind regards,
> Arjan
>
>
>
>
> _______________________________________________
> 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/20140109/c9322e35/attachment.html 

From arjan.tijms at gmail.com  Thu Jan  9 06:11:22 2014
From: arjan.tijms at gmail.com (arjan tijms)
Date: Thu, 9 Jan 2014 12:11:22 +0100
Subject: [wildfly-dev] 13 JASPIC tests failing on WildFly
In-Reply-To: <CAMquZP4E90nUWH6b0X1+SsOYOJ70QQocha=9Q1bvbCSpBGhZ3A@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>
	<52A9F918.6080200@redhat.com>
	<CAE=-AhAhNyykap2Bjjf_eOqiW3FG3JOH74TQPRry3nSjRbmWHQ@mail.gmail.com>
	<CAE=-AhD5pf3NEUhwVrwt==jMjoET00_-RSuTWYieEBpZcFpZqg@mail.gmail.com>
	<CAMquZP4E90nUWH6b0X1+SsOYOJ70QQocha=9Q1bvbCSpBGhZ3A@mail.gmail.com>
Message-ID: <CAE=-AhDdCLwV0LgR+OY5-SvP0Jx+=tJzo_Ed57Or8h0yOR7N3A@mail.gmail.com>

Hi,


On Thu, Jan 9, 2014 at 12:07 PM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:

> Hey,
>
> this PR https://github.com/wildfly/wildfly/pull/5683 was merged
> yesterday, can you check if it fixes any of your problems?
>

I'll check it out, thanks! Any convenient place where I can download a
nightly WildFly build?





>
> --
> tomaz
>
>
> On Wed, Jan 8, 2014 at 11:32 PM, arjan tijms <arjan.tijms at gmail.com>wrote:
>
>> Hi,
>>
>>
>>> On Thu, Dec 12, 2013 at 6:57 PM, Stefan Guilhen <sguilhen at redhat.com>wrote:
>>>
>>>>  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.
>>>>
>>>
>>
>> Just wondering if there has been some progress in the meantime. The
>> JASPIC tests unfortunately still don't run at all on WildFly.
>>
>> I do have to update the tests to HtmlUnit though, and check whether there
>> is or isn't an exception after a 403. The original tests were based on
>> Drone and that one didn't threw an exception. GlassFish doesn't return a
>> 403 by itself but just a blank response, so that's why I didn't catch this
>> one earlier.
>>
>> Anyway, it would be great if we can work together to get the tests to run.
>>
>> Kind regards,
>> Arjan
>>
>>
>>
>>
>> _______________________________________________
>> 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/20140109/b1931951/attachment.html 

From jaromir.hamala at gmail.com  Thu Jan  9 06:18:07 2014
From: jaromir.hamala at gmail.com (Jaromir Hamala)
Date: Thu, 9 Jan 2014 11:18:07 +0000
Subject: [wildfly-dev] WildFly 8 - list of missing features?
In-Reply-To: <CAE=-AhBtjYsUms8LYGohGD22jQ_jvrDe8XtSmsJXh+YcOxzvtw@mail.gmail.com>
References: <CAMxXA6_6ZT8dNNd3fNNRGmrZ6+UHDgiMY=7ttJH-w9GVgOQRag@mail.gmail.com>
	<CAE=-AhBtjYsUms8LYGohGD22jQ_jvrDe8XtSmsJXh+YcOxzvtw@mail.gmail.com>
Message-ID: <CAMxXA6-ZeN7pO1BMmARaMjnB403oThEiUe=yeTgBDd2F6Oxb2w@mail.gmail.com>

Hi,

thanks a lot for the replies! I suppose having such list would be
beneficial for a lot of people. "Migration Considerations" or something
like this.

I can see there are two kinds of potential issues:
1. missing or changed (CMP, JAXR, JBossWeb Valves, etc) API
2. missing "features"  - or generally stuff on somewhat higher level than
Java API - such as the SAML issue - it may or may not be the result of the
API changes.  This can be somewhat tricky to identify, but I believe it
should be documented if the feature was part of the JBoss AS 7
distribution.

Cheers,
Jaromir


On Thu, Jan 9, 2014 at 10:56 AM, arjan tijms <arjan.tijms at gmail.com> wrote:

> Hi,
>
>
> On Thu, Jan 9, 2014 at 11:20 AM, Jaromir Hamala <jaromir.hamala at gmail.com>wrote:
>
>> I wonder if there is a list of features implemented in JBoss AS 7, but
>> missing from the WildFly 8? It would make migration assessments way easier.
>>
>
> Maybe JASPIC is still open. All the tests in the Java EE 7 samples project
> are still failing. This may be an issue with the tests themselves, with the
> way JASPIC needs to be setup in JBoss products (ideally no setup should be
> needed, but alas), missing functionality or any combination of the above.
>
> At any length, I can't yet run any application that depends on JASPIC on
> WildFly, so this obviously makes migration of these apps impossible.
>
> Kind regards,
> Arjan
>
>



-- 
?Perfection is achieved, not when there is nothing more to add, but when
there is nothing left to take away.?
Antoine de Saint Exup?ry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140109/30708d58/attachment-0001.html 

From tomaz.cerar at gmail.com  Thu Jan  9 06:51:42 2014
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Thu, 9 Jan 2014 12:51:42 +0100
Subject: [wildfly-dev] 13 JASPIC tests failing on WildFly
In-Reply-To: <CAE=-AhDdCLwV0LgR+OY5-SvP0Jx+=tJzo_Ed57Or8h0yOR7N3A@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>
	<52A9F918.6080200@redhat.com>
	<CAE=-AhAhNyykap2Bjjf_eOqiW3FG3JOH74TQPRry3nSjRbmWHQ@mail.gmail.com>
	<CAE=-AhD5pf3NEUhwVrwt==jMjoET00_-RSuTWYieEBpZcFpZqg@mail.gmail.com>
	<CAMquZP4E90nUWH6b0X1+SsOYOJ70QQocha=9Q1bvbCSpBGhZ3A@mail.gmail.com>
	<CAE=-AhDdCLwV0LgR+OY5-SvP0Jx+=tJzo_Ed57Or8h0yOR7N3A@mail.gmail.com>
Message-ID: <CAMquZP5q25RC3eQqUPYN-H=67n5hFpkv5-6TYdG4rzLkY9W69g@mail.gmail.com>

You can find info about nightly builds here
https://community.jboss.org/thread/224262

but just wait a bit for new build that is currently building, that one will
have changes you want.

--
tomaz


On Thu, Jan 9, 2014 at 12:11 PM, arjan tijms <arjan.tijms at gmail.com> wrote:

> Hi,
>
>
> On Thu, Jan 9, 2014 at 12:07 PM, Toma? Cerar <tomaz.cerar at gmail.com>wrote:
>
>> Hey,
>>
>> this PR https://github.com/wildfly/wildfly/pull/5683 was merged
>> yesterday, can you check if it fixes any of your problems?
>>
>
> I'll check it out, thanks! Any convenient place where I can download a
> nightly WildFly build?
>
>
>
>
>
>>
>> --
>> tomaz
>>
>>
>> On Wed, Jan 8, 2014 at 11:32 PM, arjan tijms <arjan.tijms at gmail.com>wrote:
>>
>>> Hi,
>>>
>>>
>>>> On Thu, Dec 12, 2013 at 6:57 PM, Stefan Guilhen <sguilhen at redhat.com>wrote:
>>>>
>>>>>  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.
>>>>>
>>>>
>>>
>>> Just wondering if there has been some progress in the meantime. The
>>> JASPIC tests unfortunately still don't run at all on WildFly.
>>>
>>> I do have to update the tests to HtmlUnit though, and check whether
>>> there is or isn't an exception after a 403. The original tests were based
>>> on Drone and that one didn't threw an exception. GlassFish doesn't return a
>>> 403 by itself but just a blank response, so that's why I didn't catch this
>>> one earlier.
>>>
>>> Anyway, it would be great if we can work together to get the tests to
>>> run.
>>>
>>> Kind regards,
>>> Arjan
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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/20140109/7dcb4472/attachment.html 

From tsegismo at redhat.com  Thu Jan  9 07:35:00 2014
From: tsegismo at redhat.com (Thomas Segismont)
Date: Thu, 09 Jan 2014 13:35:00 +0100
Subject: [wildfly-dev] Remoting port
In-Reply-To: <2ECD5FA5-7EFD-4E03-A853-7E9D10BDF87D@redhat.com>
References: <52CD88F3.9060809@gmail.com>
	<2ECD5FA5-7EFD-4E03-A853-7E9D10BDF87D@redhat.com>
Message-ID: <52CE9774.5010001@redhat.com>

Hi,

JMX connectivity is currently supported over the remoting port. How will 
JMX clients be able to connect when the remoting port goes away?

Thanks,
Thomas

Le 08/01/2014 18:27, Jason Greene a ?crit :
> That's correct. The plan is to remove by Final once we make sure that
> various tools and ides are using the new http upgrade mechanism.
>
> Sent from my iPhone
>
> On Jan 8, 2014, at 11:21 AM, Filippe Costa Spolti
> <filippespolti at gmail.com <mailto:filippespolti at gmail.com>> wrote:
>
>> Hello guys.
>>
>> Let me ask something.
>>
>> In the WildFly announcements says that the remoting port was
>> deprecated, but in WFLY CR1 the port still present.
>> Here: http://wildfly.org/news/2013/12/21/WildFly8-CR1-Released/
>>
>> But when i start the standalone mode the port 9990 appears:
>>
>> [root at wfly_tests ~]# netstat -anp | grep java
>> tcp        0      0 127.0.0.1:9999 0.0.0.0:*
>> LISTEN      3070/java
>> tcp        0      0 192.168.11.109:8080 0.0.0.0:*
>> LISTEN      3070/java
>> tcp        0      0 127.0.0.1:9990 0.0.0.0:*
>> LISTEN      3070/java
>>
>> This port will be removed only in the Final version?
>>
>> --
>> Regards,
>> ______________________________________
>> Filippe Costa Spolti
>> Linux User n?515639 - http://counter.li.org/
>> filippespolti at gmail.com
>> "Be yourself"
>> <linkedin.png>
>> <http://www.linkedin.com/pub/filippe-costa-spolti/67/985/575>
>> _______________________________________________
>> 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 darran.lofthouse at jboss.com  Thu Jan  9 07:51:16 2014
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Thu, 09 Jan 2014 12:51:16 +0000
Subject: [wildfly-dev] Remoting port
In-Reply-To: <52CE9774.5010001@redhat.com>
References: <52CD88F3.9060809@gmail.com>	<2ECD5FA5-7EFD-4E03-A853-7E9D10BDF87D@redhat.com>
	<52CE9774.5010001@redhat.com>
Message-ID: <52CE9B44.7040709@jboss.com>

On 09/01/14 12:35, Thomas Segismont wrote:
> Hi,
>
> JMX connectivity is currently supported over the remoting port. How will
> JMX clients be able to connect when the remoting port goes away?

Over the HTTP port with a HTTP Upgrade, overall just a slight change in 
the URL used to establish the connection from the end users perspective.

>
> Thanks,
> Thomas
>
> Le 08/01/2014 18:27, Jason Greene a ?crit :
>> That's correct. The plan is to remove by Final once we make sure that
>> various tools and ides are using the new http upgrade mechanism.
>>
>> Sent from my iPhone
>>
>> On Jan 8, 2014, at 11:21 AM, Filippe Costa Spolti
>> <filippespolti at gmail.com <mailto:filippespolti at gmail.com>> wrote:
>>
>>> Hello guys.
>>>
>>> Let me ask something.
>>>
>>> In the WildFly announcements says that the remoting port was
>>> deprecated, but in WFLY CR1 the port still present.
>>> Here: http://wildfly.org/news/2013/12/21/WildFly8-CR1-Released/
>>>
>>> But when i start the standalone mode the port 9990 appears:
>>>
>>> [root at wfly_tests ~]# netstat -anp | grep java
>>> tcp        0      0 127.0.0.1:9999 0.0.0.0:*
>>> LISTEN      3070/java
>>> tcp        0      0 192.168.11.109:8080 0.0.0.0:*
>>> LISTEN      3070/java
>>> tcp        0      0 127.0.0.1:9990 0.0.0.0:*
>>> LISTEN      3070/java
>>>
>>> This port will be removed only in the Final version?
>>>
>>> --
>>> Regards,
>>> ______________________________________
>>> Filippe Costa Spolti
>>> Linux User n?515639 - http://counter.li.org/
>>> filippespolti at gmail.com
>>> "Be yourself"
>>> <linkedin.png>
>>> <http://www.linkedin.com/pub/filippe-costa-spolti/67/985/575>
>>> _______________________________________________
>>> 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
>>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From tsegismo at redhat.com  Thu Jan  9 07:56:13 2014
From: tsegismo at redhat.com (Thomas Segismont)
Date: Thu, 09 Jan 2014 13:56:13 +0100
Subject: [wildfly-dev] Remoting port
In-Reply-To: <52CE9B44.7040709@jboss.com>
References: <52CD88F3.9060809@gmail.com>	<2ECD5FA5-7EFD-4E03-A853-7E9D10BDF87D@redhat.com>
	<52CE9774.5010001@redhat.com> <52CE9B44.7040709@jboss.com>
Message-ID: <52CE9C6D.3040505@redhat.com>

Le 09/01/2014 13:51, Darran Lofthouse a ?crit :
> On 09/01/14 12:35, Thomas Segismont wrote:
>> Hi,
>>
>> JMX connectivity is currently supported over the remoting port. How will
>> JMX clients be able to connect when the remoting port goes away?
>
> Over the HTTP port with a HTTP Upgrade, overall just a slight change in
> the URL used to establish the connection from the end users perspective.

Great! Is this documented somewhere in the wiki? Or maybe not yet 
implemented?

I found 
https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration 
but it only refers to the remoting port solution.

Thomas

From darran.lofthouse at jboss.com  Thu Jan  9 08:30:35 2014
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Thu, 09 Jan 2014 13:30:35 +0000
Subject: [wildfly-dev] Remoting port
In-Reply-To: <52CE9C6D.3040505@redhat.com>
References: <52CD88F3.9060809@gmail.com>	<2ECD5FA5-7EFD-4E03-A853-7E9D10BDF87D@redhat.com>
	<52CE9774.5010001@redhat.com> <52CE9B44.7040709@jboss.com>
	<52CE9C6D.3040505@redhat.com>
Message-ID: <52CEA47B.7060909@jboss.com>

It is implemented just probably not documented, change the scheme in the 
URL from remoting-jmx to http-remoting-jmx and of course change the port 
in the URL to the HTTP port should be all that is required.

Regards,
Darran Lofthouse.


On 09/01/14 12:56, Thomas Segismont wrote:
> Le 09/01/2014 13:51, Darran Lofthouse a ?crit :
>> On 09/01/14 12:35, Thomas Segismont wrote:
>>> Hi,
>>>
>>> JMX connectivity is currently supported over the remoting port. How will
>>> JMX clients be able to connect when the remoting port goes away?
>>
>> Over the HTTP port with a HTTP Upgrade, overall just a slight change in
>> the URL used to establish the connection from the end users perspective.
>
> Great! Is this documented somewhere in the wiki? Or maybe not yet
> implemented?
>
> I found
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
> but it only refers to the remoting port solution.
>
> Thomas

From tsegismo at redhat.com  Thu Jan  9 09:04:22 2014
From: tsegismo at redhat.com (Thomas Segismont)
Date: Thu, 09 Jan 2014 15:04:22 +0100
Subject: [wildfly-dev] Remoting port
In-Reply-To: <52CEA47B.7060909@jboss.com>
References: <52CD88F3.9060809@gmail.com>	<2ECD5FA5-7EFD-4E03-A853-7E9D10BDF87D@redhat.com>
	<52CE9774.5010001@redhat.com> <52CE9B44.7040709@jboss.com>
	<52CE9C6D.3040505@redhat.com> <52CEA47B.7060909@jboss.com>
Message-ID: <52CEAC66.8010100@redhat.com>

Le 09/01/2014 14:30, Darran Lofthouse a ?crit :
> It is implemented just probably not documented, change the scheme in the
> URL from remoting-jmx to http-remoting-jmx and of course change the port
> in the URL to the HTTP port should be all that is required.

I just tried with 'http-remoting-jmx' and could make it work.

Thanks!
Thomas

From ales.justin at gmail.com  Thu Jan  9 10:41:33 2014
From: ales.justin at gmail.com (Ales Justin)
Date: Thu, 9 Jan 2014 16:41:33 +0100
Subject: [wildfly-dev] xnio selection err
In-Reply-To: <6DFAE785-FF64-4540-A7C6-48D7FF10B425@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>
	<E24431FB-EE1F-433F-A259-2966E4D05700@redhat.com>
	<8B57431B-3BC6-4ECE-BB0F-ED8012DDA6BD@gmail.com>
	<A6B1562C-2906-4E02-9C24-8FF511B605A5@redhat.com>
	<6DFAE785-FF64-4540-A7C6-48D7FF10B425@gmail.com>
Message-ID: <2CFF953C-0F64-4263-930C-1C0E93351C25@gmail.com>

I guess you still need this, while the app is running?

-Ales

On 02 Jan 2014, at 15:25, Ales Justin <ales.justin at gmail.com> wrote:

>> Oh is it always at shutdown?
> 
> No.
> It's also while the app runs.
> But dunno how to re-produce it on a constant basis.
> 
> -Ales
> 
>> On Jan 2, 2014, at 5:28 AM, Ales Justin <ales.justin at gmail.com> wrote:
>> 
>>> Here:
>>> * https://gist.github.com/alesj/8217872
>>> 
>>> But I didn't get any WARN log during my "chat", only at shutdown.
>>> Does it still help? Otherwise I can try to catch this when getting WARNings during chat.
>>> 
>>> -Ales
>>> 
>>> On 28 Dec 2013, at 17:14, Jason Greene <jgreene at redhat.com> wrote:
>>> 
>>>> 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
>>>>> 
>>> 
>>> _______________________________________________
>>> 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/20140109/7312d376/attachment-0001.html 

From arun.gupta at gmail.com  Thu Jan  9 12:32:17 2014
From: arun.gupta at gmail.com (Arun Gupta)
Date: Thu, 9 Jan 2014 09:32:17 -0800
Subject: [wildfly-dev] 13 JASPIC tests failing on WildFly
In-Reply-To: <CAMquZP5q25RC3eQqUPYN-H=67n5hFpkv5-6TYdG4rzLkY9W69g@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>
	<52A9F918.6080200@redhat.com>
	<CAE=-AhAhNyykap2Bjjf_eOqiW3FG3JOH74TQPRry3nSjRbmWHQ@mail.gmail.com>
	<CAE=-AhD5pf3NEUhwVrwt==jMjoET00_-RSuTWYieEBpZcFpZqg@mail.gmail.com>
	<CAMquZP4E90nUWH6b0X1+SsOYOJ70QQocha=9Q1bvbCSpBGhZ3A@mail.gmail.com>
	<CAE=-AhDdCLwV0LgR+OY5-SvP0Jx+=tJzo_Ed57Or8h0yOR7N3A@mail.gmail.com>
	<CAMquZP5q25RC3eQqUPYN-H=67n5hFpkv5-6TYdG4rzLkY9W69g@mail.gmail.com>
Message-ID: <CAGBoHQXrw+fx5hP_uJcs8LG6F4fhf3O8m0TDgi8Wec0PAWf5nA@mail.gmail.com>

Arjan,

5 test failures have gone down for now, jboss-web.xml is added to them for now.

Arun

On Thu, Jan 9, 2014 at 3:51 AM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
> You can find info about nightly builds here
> https://community.jboss.org/thread/224262
>
> but just wait a bit for new build that is currently building, that one will
> have changes you want.
>
> --
> tomaz
>
>
> On Thu, Jan 9, 2014 at 12:11 PM, arjan tijms <arjan.tijms at gmail.com> wrote:
>>
>> Hi,
>>
>>
>> On Thu, Jan 9, 2014 at 12:07 PM, Toma? Cerar <tomaz.cerar at gmail.com>
>> wrote:
>>>
>>> Hey,
>>>
>>> this PR https://github.com/wildfly/wildfly/pull/5683 was merged
>>> yesterday, can you check if it fixes any of your problems?
>>
>>
>> I'll check it out, thanks! Any convenient place where I can download a
>> nightly WildFly build?
>>
>>
>>
>>
>>>
>>>
>>> --
>>> tomaz
>>>
>>>
>>> On Wed, Jan 8, 2014 at 11:32 PM, arjan tijms <arjan.tijms at gmail.com>
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>>>
>>>>> On Thu, Dec 12, 2013 at 6:57 PM, Stefan Guilhen <sguilhen at redhat.com>
>>>>> wrote:
>>>>>>
>>>>>> 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.
>>>>
>>>>
>>>>
>>>> Just wondering if there has been some progress in the meantime. The
>>>> JASPIC tests unfortunately still don't run at all on WildFly.
>>>>
>>>> I do have to update the tests to HtmlUnit though, and check whether
>>>> there is or isn't an exception after a 403. The original tests were based on
>>>> Drone and that one didn't threw an exception. GlassFish doesn't return a 403
>>>> by itself but just a blank response, so that's why I didn't catch this one
>>>> earlier.
>>>>
>>>> Anyway, it would be great if we can work together to get the tests to
>>>> run.
>>>>
>>>> Kind regards,
>>>> Arjan
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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  Thu Jan  9 15:06:45 2014
From: sguilhen at redhat.com (Stefan Guilhen)
Date: Thu, 09 Jan 2014 18:06:45 -0200
Subject: [wildfly-dev] 13 JASPIC tests failing on WildFly
In-Reply-To: <CAGBoHQXrw+fx5hP_uJcs8LG6F4fhf3O8m0TDgi8Wec0PAWf5nA@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>	<52A9F918.6080200@redhat.com>	<CAE=-AhAhNyykap2Bjjf_eOqiW3FG3JOH74TQPRry3nSjRbmWHQ@mail.gmail.com>	<CAE=-AhD5pf3NEUhwVrwt==jMjoET00_-RSuTWYieEBpZcFpZqg@mail.gmail.com>	<CAMquZP4E90nUWH6b0X1+SsOYOJ70QQocha=9Q1bvbCSpBGhZ3A@mail.gmail.com>	<CAE=-AhDdCLwV0LgR+OY5-SvP0Jx+=tJzo_Ed57Or8h0yOR7N3A@mail.gmail.com>	<CAMquZP5q25RC3eQqUPYN-H=67n5hFpkv5-6TYdG4rzLkY9W69g@mail.gmail.com>
	<CAGBoHQXrw+fx5hP_uJcs8LG6F4fhf3O8m0TDgi8Wec0PAWf5nA@mail.gmail.com>
Message-ID: <52CF0155.1090105@redhat.com>

I've put a PR for a commit that fixes the wrapping tests. Remaining 
failures have been analysed and will be fixed soon.

On 01/09/2014 03:32 PM, Arun Gupta wrote:
> Arjan,
>
> 5 test failures have gone down for now, jboss-web.xml is added to them for now.
>
> Arun
>
> On Thu, Jan 9, 2014 at 3:51 AM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
>> You can find info about nightly builds here
>> https://community.jboss.org/thread/224262
>>
>> but just wait a bit for new build that is currently building, that one will
>> have changes you want.
>>
>> --
>> tomaz
>>
>>
>> On Thu, Jan 9, 2014 at 12:11 PM, arjan tijms <arjan.tijms at gmail.com> wrote:
>>> Hi,
>>>
>>>
>>> On Thu, Jan 9, 2014 at 12:07 PM, Toma? Cerar <tomaz.cerar at gmail.com>
>>> wrote:
>>>> Hey,
>>>>
>>>> this PR https://github.com/wildfly/wildfly/pull/5683 was merged
>>>> yesterday, can you check if it fixes any of your problems?
>>>
>>> I'll check it out, thanks! Any convenient place where I can download a
>>> nightly WildFly build?
>>>
>>>
>>>
>>>
>>>>
>>>> --
>>>> tomaz
>>>>
>>>>
>>>> On Wed, Jan 8, 2014 at 11:32 PM, arjan tijms <arjan.tijms at gmail.com>
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>>> On Thu, Dec 12, 2013 at 6:57 PM, Stefan Guilhen <sguilhen at redhat.com>
>>>>>> wrote:
>>>>>>> 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.
>>>>>
>>>>>
>>>>> Just wondering if there has been some progress in the meantime. The
>>>>> JASPIC tests unfortunately still don't run at all on WildFly.
>>>>>
>>>>> I do have to update the tests to HtmlUnit though, and check whether
>>>>> there is or isn't an exception after a 403. The original tests were based on
>>>>> Drone and that one didn't threw an exception. GlassFish doesn't return a 403
>>>>> by itself but just a blank response, so that's why I didn't catch this one
>>>>> earlier.
>>>>>
>>>>> Anyway, it would be great if we can work together to get the tests to
>>>>> run.
>>>>>
>>>>> Kind regards,
>>>>> Arjan
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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 Jan  9 16:28:43 2014
From: arjan.tijms at gmail.com (arjan tijms)
Date: Thu, 9 Jan 2014 22:28:43 +0100
Subject: [wildfly-dev] 13 JASPIC tests failing on WildFly
In-Reply-To: <52CF0155.1090105@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>
	<CAE=-AhAhNyykap2Bjjf_eOqiW3FG3JOH74TQPRry3nSjRbmWHQ@mail.gmail.com>
	<CAE=-AhD5pf3NEUhwVrwt==jMjoET00_-RSuTWYieEBpZcFpZqg@mail.gmail.com>
	<CAMquZP4E90nUWH6b0X1+SsOYOJ70QQocha=9Q1bvbCSpBGhZ3A@mail.gmail.com>
	<CAE=-AhDdCLwV0LgR+OY5-SvP0Jx+=tJzo_Ed57Or8h0yOR7N3A@mail.gmail.com>
	<CAMquZP5q25RC3eQqUPYN-H=67n5hFpkv5-6TYdG4rzLkY9W69g@mail.gmail.com>
	<CAGBoHQXrw+fx5hP_uJcs8LG6F4fhf3O8m0TDgi8Wec0PAWf5nA@mail.gmail.com>
	<52CF0155.1090105@redhat.com>
Message-ID: <CAE=-AhDZbPk0uDNF_z2TNWeUXOWMTTGbZMEs3nKn8ESS+sCAhg@mail.gmail.com>

That's very good news Stefan!

I'll also take a look at the 403/Exception that you mentioned before.
Indeed, HttpUnit throws an exception upon a 403 where Drone that I used for
the original tests didn't. This will probably also fix a few test breakages.

Kind regards,
Arjan


On Thu, Jan 9, 2014 at 9:06 PM, Stefan Guilhen <sguilhen at redhat.com> wrote:

> I've put a PR for a commit that fixes the wrapping tests. Remaining
> failures have been analysed and will be fixed soon.
>
> On 01/09/2014 03:32 PM, Arun Gupta wrote:
> > Arjan,
> >
> > 5 test failures have gone down for now, jboss-web.xml is added to them
> for now.
> >
> > Arun
> >
> > On Thu, Jan 9, 2014 at 3:51 AM, Toma? Cerar <tomaz.cerar at gmail.com>
> wrote:
> >> You can find info about nightly builds here
> >> https://community.jboss.org/thread/224262
> >>
> >> but just wait a bit for new build that is currently building, that one
> will
> >> have changes you want.
> >>
> >> --
> >> tomaz
> >>
> >>
> >> On Thu, Jan 9, 2014 at 12:11 PM, arjan tijms <arjan.tijms at gmail.com>
> wrote:
> >>> Hi,
> >>>
> >>>
> >>> On Thu, Jan 9, 2014 at 12:07 PM, Toma? Cerar <tomaz.cerar at gmail.com>
> >>> wrote:
> >>>> Hey,
> >>>>
> >>>> this PR https://github.com/wildfly/wildfly/pull/5683 was merged
> >>>> yesterday, can you check if it fixes any of your problems?
> >>>
> >>> I'll check it out, thanks! Any convenient place where I can download a
> >>> nightly WildFly build?
> >>>
> >>>
> >>>
> >>>
> >>>>
> >>>> --
> >>>> tomaz
> >>>>
> >>>>
> >>>> On Wed, Jan 8, 2014 at 11:32 PM, arjan tijms <arjan.tijms at gmail.com>
> >>>> wrote:
> >>>>> Hi,
> >>>>>
> >>>>>> On Thu, Dec 12, 2013 at 6:57 PM, Stefan Guilhen <
> sguilhen at redhat.com>
> >>>>>> wrote:
> >>>>>>> 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.
> >>>>>
> >>>>>
> >>>>> Just wondering if there has been some progress in the meantime. The
> >>>>> JASPIC tests unfortunately still don't run at all on WildFly.
> >>>>>
> >>>>> I do have to update the tests to HtmlUnit though, and check whether
> >>>>> there is or isn't an exception after a 403. The original tests were
> based on
> >>>>> Drone and that one didn't threw an exception. GlassFish doesn't
> return a 403
> >>>>> by itself but just a blank response, so that's why I didn't catch
> this one
> >>>>> earlier.
> >>>>>
> >>>>> Anyway, it would be great if we can work together to get the tests to
> >>>>> run.
> >>>>>
> >>>>> Kind regards,
> >>>>> Arjan
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> 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/20140109/1a78f60d/attachment.html 

From arun.gupta at gmail.com  Sat Jan 11 04:54:45 2014
From: arun.gupta at gmail.com (Arun Gupta)
Date: Sat, 11 Jan 2014 01:54:45 -0800
Subject: [wildfly-dev] Deploying app on managed domain
Message-ID: <CAGBoHQVpGyq0waC+4pOsmo-StZfwpKfk0da2bVESK+yzyYY3Jg@mail.gmail.com>

I started bin/standalone.sh, deployed a WAR file (name is
http-1.0-SNAPSHOT.war) with just one index.jsp. Accessing
localhost:8080/http shows the expected results. Tried the same with
bin/domain.sh but now localhost:8080/http is giving a 404.

What are the port number of the servers started in this managed domain
? Is Ports +0 and +150 in admin console trying to display that
information ? If yes, then that is not very intuitive and the exact
value of the port should be displayed. If not, what are these values ?
Should this app be accessible on localhost:8080 ?

Tried enabling the app from admin console and got the error:
Failed to enable http-1.0-SNAPSHOT.war.

Unexpected HTTP response: 500

Request
{
    "address" => [("deployment" => "http-1.0-SNAPSHOT.war")],
    "operation" => "deploy"
}

Response

Internal Server Error
{
    "outcome" => "failed",
    "failure-description" => "JBAS014884: No operation named 'deploy'
exists at address [(\"deployment\" => \"http-1.0-SNAPSHOT.war\")]",
    "rolled-back" => true
}

Is this the correct way to deploy the app on managed domain ?

Arun

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

From arun.gupta at gmail.com  Sat Jan 11 04:56:56 2014
From: arun.gupta at gmail.com (Arun Gupta)
Date: Sat, 11 Jan 2014 01:56:56 -0800
Subject: [wildfly-dev] Misc questions about WF8
Message-ID: <CAGBoHQWe-i2D2NZHS_Z0WbPm63HjkzxAfATFb6wNOV3mNButNA@mail.gmail.com>

- There are a bunch of ports listed in different
<socket-binding-group>s in domain.xml such as for jacorb, groups-tcp,
and messaging. I thought that only two ports are exposed by WildFly.
What purpose do these ports serve ? What about 8443 ?

- What is new in jboss-cli.sh in WildFly from AS 7 ?

- Where can I find the complete feature set for everything new in WF8 ?

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

From stuart.w.douglas at gmail.com  Sat Jan 11 05:01:01 2014
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Sat, 11 Jan 2014 11:01:01 +0100
Subject: [wildfly-dev] Misc questions about WF8
In-Reply-To: <CAGBoHQWe-i2D2NZHS_Z0WbPm63HjkzxAfATFb6wNOV3mNButNA@mail.gmail.com>
References: <CAGBoHQWe-i2D2NZHS_Z0WbPm63HjkzxAfATFb6wNOV3mNButNA@mail.gmail.com>
Message-ID: <CAAoo=c7RNFPizWhpn=x8YrzNJLckVtw_NUX0_SKJY6M3CEytrA@mail.gmail.com>

On Sat, Jan 11, 2014 at 10:56 AM, Arun Gupta <arun.gupta at gmail.com> wrote:

> - There are a bunch of ports listed in different
> <socket-binding-group>s in domain.xml such as for jacorb, groups-tcp,
> and messaging. I thought that only two ports are exposed by WildFly.
> What purpose do these ports serve ? What about 8443 ?
>

We are only going to have 2 ports in our default config, however when
running in full profile mode there are some additional services that are
not compatible with HTTP upgrade.

8443 is the HTTPS port.
Jacorb is for CORBA, which cannot be done over HTTP upgrade.
jgroups is for clustering

Stuart


> - What is new in jboss-cli.sh in WildFly from AS 7 ?
>
> - Where can I find the complete feature set for everything new in WF8 ?
>
> Thanks
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140111/9609977b/attachment-0001.html 

From arun.gupta at gmail.com  Sat Jan 11 05:13:09 2014
From: arun.gupta at gmail.com (Arun Gupta)
Date: Sat, 11 Jan 2014 02:13:09 -0800
Subject: [wildfly-dev] Misc questions about WF8
In-Reply-To: <CAAoo=c7RNFPizWhpn=x8YrzNJLckVtw_NUX0_SKJY6M3CEytrA@mail.gmail.com>
References: <CAGBoHQWe-i2D2NZHS_Z0WbPm63HjkzxAfATFb6wNOV3mNButNA@mail.gmail.com>
	<CAAoo=c7RNFPizWhpn=x8YrzNJLckVtw_NUX0_SKJY6M3CEytrA@mail.gmail.com>
Message-ID: <CAGBoHQVFBdr6_a7P96NNcEBkAHWRJ3MHqYfiCeP0t4ideob58A@mail.gmail.com>

Default config is Web profile ?

Will HTTPs be not supported there ?

Arun

On Sat, Jan 11, 2014 at 2:01 AM, Stuart Douglas
<stuart.w.douglas at gmail.com> wrote:
>
>
>
> On Sat, Jan 11, 2014 at 10:56 AM, Arun Gupta <arun.gupta at gmail.com> wrote:
>>
>> - There are a bunch of ports listed in different
>> <socket-binding-group>s in domain.xml such as for jacorb, groups-tcp,
>> and messaging. I thought that only two ports are exposed by WildFly.
>> What purpose do these ports serve ? What about 8443 ?
>
>
> We are only going to have 2 ports in our default config, however when
> running in full profile mode there are some additional services that are not
> compatible with HTTP upgrade.
>
> 8443 is the HTTPS port.
> Jacorb is for CORBA, which cannot be done over HTTP upgrade.
> jgroups is for clustering
>
> Stuart
>
>>
>> - What is new in jboss-cli.sh in WildFly from AS 7 ?
>>
>> - Where can I find the complete feature set for everything new in WF8 ?
>>
>> Thanks
>> 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
>
>



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

From darran.lofthouse at jboss.com  Sat Jan 11 05:22:51 2014
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Sat, 11 Jan 2014 10:22:51 +0000
Subject: [wildfly-dev] Misc questions about WF8
In-Reply-To: <CAGBoHQVFBdr6_a7P96NNcEBkAHWRJ3MHqYfiCeP0t4ideob58A@mail.gmail.com>
References: <CAGBoHQWe-i2D2NZHS_Z0WbPm63HjkzxAfATFb6wNOV3mNButNA@mail.gmail.com>	<CAAoo=c7RNFPizWhpn=x8YrzNJLckVtw_NUX0_SKJY6M3CEytrA@mail.gmail.com>
	<CAGBoHQVFBdr6_a7P96NNcEBkAHWRJ3MHqYfiCeP0t4ideob58A@mail.gmail.com>
Message-ID: <52D11B7B.6010709@jboss.com>

On 11/01/14 10:13, Arun Gupta wrote:
> Default config is Web profile ?
>
> Will HTTPs be not supported there ?

HTTPS is supported just not enabled by default as we don't have keys in 
the distribution to be able to enable it.  This is actually a topic I 
want to discuss next week.

We have a few problems with having it enabled by default: -
  - If we include keys in the distribution being open source those keys 
are public knowledge.
  - Also keys are specific to the host name used to connect to the 
server so at best we could assume 'localhost' but in that scenario the 
benefits of SSL are limited.
  - We could create a new key on start up, this would delay the start up 
time and also we have the default hostname assumption issue again.
  - We could provide a set of ops and add wizards to the CLI and admin 
console to manage the keys and certificates.

The latter is actually my preferred option but it would involve a little 
bit of work all round but the main benefit being that a wizard gets to 
ask the right questions.

Regards,
Darran Lofthouse.

>
> Arun
>
> On Sat, Jan 11, 2014 at 2:01 AM, Stuart Douglas
> <stuart.w.douglas at gmail.com> wrote:
>>
>>
>>
>> On Sat, Jan 11, 2014 at 10:56 AM, Arun Gupta <arun.gupta at gmail.com> wrote:
>>>
>>> - There are a bunch of ports listed in different
>>> <socket-binding-group>s in domain.xml such as for jacorb, groups-tcp,
>>> and messaging. I thought that only two ports are exposed by WildFly.
>>> What purpose do these ports serve ? What about 8443 ?
>>
>>
>> We are only going to have 2 ports in our default config, however when
>> running in full profile mode there are some additional services that are not
>> compatible with HTTP upgrade.
>>
>> 8443 is the HTTPS port.
>> Jacorb is for CORBA, which cannot be done over HTTP upgrade.
>> jgroups is for clustering
>>
>> Stuart
>>
>>>
>>> - What is new in jboss-cli.sh in WildFly from AS 7 ?
>>>
>>> - Where can I find the complete feature set for everything new in WF8 ?
>>>
>>> Thanks
>>> 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
>>
>>
>
>
>

From arun.gupta at gmail.com  Sat Jan 11 05:30:09 2014
From: arun.gupta at gmail.com (Arun Gupta)
Date: Sat, 11 Jan 2014 02:30:09 -0800
Subject: [wildfly-dev] Misc questions about WF8
In-Reply-To: <52D11B7B.6010709@jboss.com>
References: <CAGBoHQWe-i2D2NZHS_Z0WbPm63HjkzxAfATFb6wNOV3mNButNA@mail.gmail.com>
	<CAAoo=c7RNFPizWhpn=x8YrzNJLckVtw_NUX0_SKJY6M3CEytrA@mail.gmail.com>
	<CAGBoHQVFBdr6_a7P96NNcEBkAHWRJ3MHqYfiCeP0t4ideob58A@mail.gmail.com>
	<52D11B7B.6010709@jboss.com>
Message-ID: <CAGBoHQWv-vO-uxBbJESHoHHCRr7PN4enNvx1s700EiEv9mYQBw@mail.gmail.com>

+1 on that option as well.

Let the user consciously make a decision about enabling security and
configuring certificates. Providing tools would certainly simplify it
otherwise it would be daunting.

Arun

On Sat, Jan 11, 2014 at 2:22 AM, Darran Lofthouse
<darran.lofthouse at jboss.com> wrote:
> On 11/01/14 10:13, Arun Gupta wrote:
>> Default config is Web profile ?
>>
>> Will HTTPs be not supported there ?
>
> HTTPS is supported just not enabled by default as we don't have keys in
> the distribution to be able to enable it.  This is actually a topic I
> want to discuss next week.
>
> We have a few problems with having it enabled by default: -
>   - If we include keys in the distribution being open source those keys
> are public knowledge.
>   - Also keys are specific to the host name used to connect to the
> server so at best we could assume 'localhost' but in that scenario the
> benefits of SSL are limited.
>   - We could create a new key on start up, this would delay the start up
> time and also we have the default hostname assumption issue again.
>   - We could provide a set of ops and add wizards to the CLI and admin
> console to manage the keys and certificates.
>
> The latter is actually my preferred option but it would involve a little
> bit of work all round but the main benefit being that a wizard gets to
> ask the right questions.
>
> Regards,
> Darran Lofthouse.
>
>>
>> Arun
>>
>> On Sat, Jan 11, 2014 at 2:01 AM, Stuart Douglas
>> <stuart.w.douglas at gmail.com> wrote:
>>>
>>>
>>>
>>> On Sat, Jan 11, 2014 at 10:56 AM, Arun Gupta <arun.gupta at gmail.com> wrote:
>>>>
>>>> - There are a bunch of ports listed in different
>>>> <socket-binding-group>s in domain.xml such as for jacorb, groups-tcp,
>>>> and messaging. I thought that only two ports are exposed by WildFly.
>>>> What purpose do these ports serve ? What about 8443 ?
>>>
>>>
>>> We are only going to have 2 ports in our default config, however when
>>> running in full profile mode there are some additional services that are not
>>> compatible with HTTP upgrade.
>>>
>>> 8443 is the HTTPS port.
>>> Jacorb is for CORBA, which cannot be done over HTTP upgrade.
>>> jgroups is for clustering
>>>
>>> Stuart
>>>
>>>>
>>>> - What is new in jboss-cli.sh in WildFly from AS 7 ?
>>>>
>>>> - Where can I find the complete feature set for everything new in WF8 ?
>>>>
>>>> Thanks
>>>> 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
>>>
>>>
>>
>>
>>
> _______________________________________________
> 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 arun.gupta at gmail.com  Sat Jan 11 14:40:14 2014
From: arun.gupta at gmail.com (Arun Gupta)
Date: Sat, 11 Jan 2014 20:40:14 +0100
Subject: [wildfly-dev] WF8 domain in Web Profile
Message-ID: <CAGBoHQWQsvQcxzhD8CKwA_cdr752hFuLjkc_A0c+xrSVhtDMdg@mail.gmail.com>

How do I start a WF8 domain in Web Profile ? There is no corresponding
configuration file in domain/configuration.

Arun

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

From jason.greene at redhat.com  Sun Jan 12 05:20:57 2014
From: jason.greene at redhat.com (Jason Greene)
Date: Sun, 12 Jan 2014 10:20:57 +0000
Subject: [wildfly-dev] Misc questions about WF8
In-Reply-To: <CAGBoHQWe-i2D2NZHS_Z0WbPm63HjkzxAfATFb6wNOV3mNButNA@mail.gmail.com>
References: <CAGBoHQWe-i2D2NZHS_Z0WbPm63HjkzxAfATFb6wNOV3mNButNA@mail.gmail.com>
Message-ID: <8C72C97C-BF78-46D0-B3FB-FE07E6AF223B@redhat.com>


On Jan 11, 2014, at 9:56 AM, Arun Gupta <arun.gupta at gmail.com> wrote:

> - There are a bunch of ports listed in different
> <socket-binding-group>s in domain.xml such as for jacorb, groups-tcp,
> and messaging. I thought that only two ports are exposed by WildFly.
> What purpose do these ports serve ? What about 8443 ?
> 
> - What is new in jboss-cli.sh in WildFly from AS 7 ?

jboss-admin was renamed to jboss-cli

> 
> - Where can I find the complete feature set for everything new in WF8 ?
> 
> Thanks
> 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

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


From jason.greene at redhat.com  Sun Jan 12 05:24:11 2014
From: jason.greene at redhat.com (Jason Greene)
Date: Sun, 12 Jan 2014 10:24:11 +0000
Subject: [wildfly-dev] WF8 domain in Web Profile
In-Reply-To: <CAGBoHQWQsvQcxzhD8CKwA_cdr752hFuLjkc_A0c+xrSVhtDMdg@mail.gmail.com>
References: <CAGBoHQWQsvQcxzhD8CKwA_cdr752hFuLjkc_A0c+xrSVhtDMdg@mail.gmail.com>
Message-ID: <D391ED95-3D23-4357-B7E0-BAF598830257@redhat.com>

Domain mode stores multiple configuration profiles in domain.xml. profile name=?default? is web profile++

On Jan 11, 2014, at 7:40 PM, Arun Gupta <arun.gupta at gmail.com> wrote:

> How do I start a WF8 domain in Web Profile ? There is no corresponding
> configuration file in domain/configuration.
> 
> 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

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



From arun.gupta at gmail.com  Sun Jan 12 06:11:10 2014
From: arun.gupta at gmail.com (Arun Gupta)
Date: Sun, 12 Jan 2014 12:11:10 +0100
Subject: [wildfly-dev] WF8 domain in Web Profile
In-Reply-To: <D391ED95-3D23-4357-B7E0-BAF598830257@redhat.com>
References: <CAGBoHQWQsvQcxzhD8CKwA_cdr752hFuLjkc_A0c+xrSVhtDMdg@mail.gmail.com>
	<D391ED95-3D23-4357-B7E0-BAF598830257@redhat.com>
Message-ID: <CAGBoHQWtj+Jj5KOOYnEjFnGLibcmDOOXxNfgTGC5nu2YCsAhzQ@mail.gmail.com>

./bin/domain.sh will start in "default" profile.

domain.sh takes -c and --domain-config switches but they take
configuration files only.

How do I tell the domain to start in a non-default profile ?

As no other configuration files are provided, is the expectation that
the user will create their own configuration files and refer to them ?
What would they add in those configuration files instead of add new
profiles in domain.xml ?

Arun

On Sun, Jan 12, 2014 at 11:24 AM, Jason Greene <jason.greene at redhat.com> wrote:
> Domain mode stores multiple configuration profiles in domain.xml. profile name=?default? is web profile++
>
> On Jan 11, 2014, at 7:40 PM, Arun Gupta <arun.gupta at gmail.com> wrote:
>
>> How do I start a WF8 domain in Web Profile ? There is no corresponding
>> configuration file in domain/configuration.
>>
>> 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
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>



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


From literakl at centrum.cz  Sun Jan 12 12:25:05 2014
From: literakl at centrum.cz (=?utf-8?q?Leos_Literak?=)
Date: Sun, 12 Jan 2014 18:25:05 +0100
Subject: [wildfly-dev] =?utf-8?q?Charset_encoding_problem_in_servlet_with_?=
	=?utf-8?q?JPA?=
Message-ID: <20140112182505.E9533027@centrum.cz>

?
Hi,
?
I installed WF CR1 and started to create simple web application consisting of one servlet and one JPA entity. But when I ran it, I found that encoding is incorrect. After many many hours of investigation I realized that if there is servlet only then I receive form parameter in correct encoding. But if I bundle JPA part then encoding is incorrect. The encoding is even broken in my filter already. There is parsedFormData property with data and it has wrong charset already. I do not know undertow-io so it is hard for me to guess who parses this data and when. It is really strange, why this behaviour depends on JPA usage in war.
?
I can provide complete (short) sources: https://drive.google.com/file/d/0B-adlc5KThQDWTdYOEwxOUpTVEU/edit?usp=sharing <https://drive.google.com/file/d/0B-adlc5KThQDWTdYOEwxOUpTVEU/edit?usp=sharing>
SO question: http://stackoverflow.com/questions/21068291/servlet-character-encoding-issue-with-jpa/21074074?noredirect=1#21074074
?
I really do not understand this problem.
?
Thanks for your help
?
Leos
?
?

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

From marko.luksa at gmail.com  Sun Jan 12 13:11:25 2014
From: marko.luksa at gmail.com (=?windows-1252?Q?Marko_Luk=9Aa?=)
Date: Sun, 12 Jan 2014 19:11:25 +0100
Subject: [wildfly-dev] Charset encoding problem in servlet with JPA
In-Reply-To: <20140112182505.E9533027@centrum.cz>
References: <20140112182505.E9533027@centrum.cz>
Message-ID: <52D2DACD.4060209@gmail.com>


This is caused by CDI/Weld. See 
https://issues.jboss.org/browse/WELD-1467 and 
https://issues.jboss.org/browse/CDI-411

Marko


On 12.1.2014 18:25, Leos Literak wrote:
>
> Hi,
>
> I installed WF CR1 and started to create simple web application 
> consisting of one servlet and one JPA entity. But when I ran it, I 
> found that encoding is incorrect. After many many hours of 
> investigation I realized that if there is servlet only then I receive 
> form parameter in correct encoding. But if I bundle JPA part then 
> encoding is incorrect. The encoding is even broken in my filter 
> already. There is parsedFormData property with data and it has wrong 
> charset already. I do not know undertow-io so it is hard for me to 
> guess who parses this data and when. It is really strange, why this 
> behaviour depends on JPA usage in war.
>
> I can provide complete (short) sources: 
> https://drive.google.com/file/d/0B-adlc5KThQDWTdYOEwxOUpTVEU/edit?usp=sharing
>
> SO question: 
> http://stackoverflow.com/questions/21068291/servlet-character-encoding-issue-with-jpa/21074074?noredirect=1#21074074
>
> I really do not understand this problem.
>
> Thanks for your help
>
> Leos
>
>
>
> _______________________________________________
> 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/20140112/66f1749b/attachment-0001.html 

From jgreene at redhat.com  Sun Jan 12 16:15:52 2014
From: jgreene at redhat.com (Jason Greene)
Date: Sun, 12 Jan 2014 16:15:52 -0500 (EST)
Subject: [wildfly-dev] WF8 domain in Web Profile
In-Reply-To: <CAGBoHQWtj+Jj5KOOYnEjFnGLibcmDOOXxNfgTGC5nu2YCsAhzQ@mail.gmail.com>
References: <CAGBoHQWQsvQcxzhD8CKwA_cdr752hFuLjkc_A0c+xrSVhtDMdg@mail.gmail.com>
	<D391ED95-3D23-4357-B7E0-BAF598830257@redhat.com>
	<CAGBoHQWtj+Jj5KOOYnEjFnGLibcmDOOXxNfgTGC5nu2YCsAhzQ@mail.gmail.com>
Message-ID: <07159796-EAEA-4943-80B4-3EA9F91EE8B0@redhat.com>

See:

https://docs.jboss.org/author/display/WFLY8/Admin+Guide#AdminGuide-ServerGroup

Sent from my iPhone

> On Jan 12, 2014, at 12:11 PM, Arun Gupta <arun.gupta at gmail.com> wrote:
> 
> ./bin/domain.sh will start in "default" profile.
> 
> domain.sh takes -c and --domain-config switches but they take
> configuration files only.
> 
> How do I tell the domain to start in a non-default profile ?
> 
> As no other configuration files are provided, is the expectation that
> the user will create their own configuration files and refer to them ?
> What would they add in those configuration files instead of add new
> profiles in domain.xml ?
> 
> Arun
> 
>> On Sun, Jan 12, 2014 at 11:24 AM, Jason Greene <jason.greene at redhat.com> wrote:
>> Domain mode stores multiple configuration profiles in domain.xml. profile name=?default? is web profile++
>> 
>>> On Jan 11, 2014, at 7:40 PM, Arun Gupta <arun.gupta at gmail.com> wrote:
>>> 
>>> How do I start a WF8 domain in Web Profile ? There is no corresponding
>>> configuration file in domain/configuration.
>>> 
>>> 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
>> 
>> --
>> Jason T. Greene
>> WildFly Lead / JBoss EAP Platform Architect
>> JBoss, a division of Red Hat
> 
> 
> 
> -- 
> http://blog.arungupta.me
> http://twitter.com/arungupta


From arjan.tijms at gmail.com  Sun Jan 12 18:53:25 2014
From: arjan.tijms at gmail.com (arjan tijms)
Date: Mon, 13 Jan 2014 00:53:25 +0100
Subject: [wildfly-dev] 13 JASPIC tests failing on WildFly
In-Reply-To: <CAE=-AhDZbPk0uDNF_z2TNWeUXOWMTTGbZMEs3nKn8ESS+sCAhg@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>
	<52A9F918.6080200@redhat.com>
	<CAE=-AhAhNyykap2Bjjf_eOqiW3FG3JOH74TQPRry3nSjRbmWHQ@mail.gmail.com>
	<CAE=-AhD5pf3NEUhwVrwt==jMjoET00_-RSuTWYieEBpZcFpZqg@mail.gmail.com>
	<CAMquZP4E90nUWH6b0X1+SsOYOJ70QQocha=9Q1bvbCSpBGhZ3A@mail.gmail.com>
	<CAE=-AhDdCLwV0LgR+OY5-SvP0Jx+=tJzo_Ed57Or8h0yOR7N3A@mail.gmail.com>
	<CAMquZP5q25RC3eQqUPYN-H=67n5hFpkv5-6TYdG4rzLkY9W69g@mail.gmail.com>
	<CAGBoHQXrw+fx5hP_uJcs8LG6F4fhf3O8m0TDgi8Wec0PAWf5nA@mail.gmail.com>
	<52CF0155.1090105@redhat.com>
	<CAE=-AhDZbPk0uDNF_z2TNWeUXOWMTTGbZMEs3nKn8ESS+sCAhg@mail.gmail.com>
Message-ID: <CAE=-AhBioWQ7cwB+J2ALu44nC8++uYEHqYKBzqR77LHSaX1mnA@mail.gmail.com>

Hi,

I fixed the tests so they don't throw exceptions anymore after a 403. Using
a SNAPSHOT build from January 11, things start to get better now :)

[INFO] common ............................................ SUCCESS [1.422s]
[INFO] basic-authentication .............................. SUCCESS [5.315s]
[INFO] ejb-propagation ................................... FAILURE [5.010s]
[INFO] lifecycle ......................................... FAILURE [3.747s]
[INFO] register-session .................................. FAILURE [4.160s]
[INFO] wrapping .......................................... SUCCESS [3.739s]

ejb-propagation even partially succeeds. The authentication details are
available in the public EJB bean (EJB bean without a security interceptor
for @RolesAllowed), but access to a protected EJB (EJB bean with the
security interceptor) fails.

This looks exactly like the bug in JBoss EAP 6.x. The security interceptor
always tries to authenticate with the "security domain", where it expects a
proprietary JBoss login module. I think the interceptor should just use the
identity of the caller for local calls (calls to local EJB beans).

If I'm not mistaken, the entire reason to consult a security domain for
every method call to an EJB bean is for remote EJB beans, not for local
ones. I agree, the spec is not clear about this, but I think other servers
indeed use the authenticated identity of the caller for local calls. See
also the issue logged for EAP 6.x:
https://issues.jboss.org/browse/SECURITY-746

lifecycle is also failing, but this should hopefully be rather simple to
fix.

register-session may be a bit more tricky. I remember it took the GlassFish
guys some effort.

Btw, there are some things that historically failed on JBoss for which I
haven't created tests yet, like forwarding and including from a SAM, which
are now mandatory for JASPIC 1.1 (but which the TCK probably doesn't test
for either).

Kind regards,
Arjan Tijms














On Thu, Jan 9, 2014 at 10:28 PM, arjan tijms <arjan.tijms at gmail.com> wrote:

> That's very good news Stefan!
>
> I'll also take a look at the 403/Exception that you mentioned before.
> Indeed, HttpUnit throws an exception upon a 403 where Drone that I used for
> the original tests didn't. This will probably also fix a few test breakages.
>
> Kind regards,
> Arjan
>
>
> On Thu, Jan 9, 2014 at 9:06 PM, Stefan Guilhen <sguilhen at redhat.com>wrote:
>
>> I've put a PR for a commit that fixes the wrapping tests. Remaining
>> failures have been analysed and will be fixed soon.
>>
>> On 01/09/2014 03:32 PM, Arun Gupta wrote:
>> > Arjan,
>> >
>> > 5 test failures have gone down for now, jboss-web.xml is added to them
>> for now.
>> >
>> > Arun
>> >
>> > On Thu, Jan 9, 2014 at 3:51 AM, Toma? Cerar <tomaz.cerar at gmail.com>
>> wrote:
>> >> You can find info about nightly builds here
>> >> https://community.jboss.org/thread/224262
>> >>
>> >> but just wait a bit for new build that is currently building, that one
>> will
>> >> have changes you want.
>> >>
>> >> --
>> >> tomaz
>> >>
>> >>
>> >> On Thu, Jan 9, 2014 at 12:11 PM, arjan tijms <arjan.tijms at gmail.com>
>> wrote:
>> >>> Hi,
>> >>>
>> >>>
>> >>> On Thu, Jan 9, 2014 at 12:07 PM, Toma? Cerar <tomaz.cerar at gmail.com>
>> >>> wrote:
>> >>>> Hey,
>> >>>>
>> >>>> this PR https://github.com/wildfly/wildfly/pull/5683 was merged
>> >>>> yesterday, can you check if it fixes any of your problems?
>> >>>
>> >>> I'll check it out, thanks! Any convenient place where I can download a
>> >>> nightly WildFly build?
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>>
>> >>>> --
>> >>>> tomaz
>> >>>>
>> >>>>
>> >>>> On Wed, Jan 8, 2014 at 11:32 PM, arjan tijms <arjan.tijms at gmail.com>
>> >>>> wrote:
>> >>>>> Hi,
>> >>>>>
>> >>>>>> On Thu, Dec 12, 2013 at 6:57 PM, Stefan Guilhen <
>> sguilhen at redhat.com>
>> >>>>>> wrote:
>> >>>>>>> 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.
>> >>>>>
>> >>>>>
>> >>>>> Just wondering if there has been some progress in the meantime. The
>> >>>>> JASPIC tests unfortunately still don't run at all on WildFly.
>> >>>>>
>> >>>>> I do have to update the tests to HtmlUnit though, and check whether
>> >>>>> there is or isn't an exception after a 403. The original tests were
>> based on
>> >>>>> Drone and that one didn't threw an exception. GlassFish doesn't
>> return a 403
>> >>>>> by itself but just a blank response, so that's why I didn't catch
>> this one
>> >>>>> earlier.
>> >>>>>
>> >>>>> Anyway, it would be great if we can work together to get the tests
>> to
>> >>>>> run.
>> >>>>>
>> >>>>> Kind regards,
>> >>>>> Arjan
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> 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/20140113/a9e6f471/attachment.html 

From alexey.loubyansky at redhat.com  Mon Jan 13 09:30:44 2014
From: alexey.loubyansky at redhat.com (Alexey Loubyansky)
Date: Mon, 13 Jan 2014 15:30:44 +0100
Subject: [wildfly-dev] Deploying app on managed domain
In-Reply-To: <CAGBoHQVpGyq0waC+4pOsmo-StZfwpKfk0da2bVESK+yzyYY3Jg@mail.gmail.com>
References: <CAGBoHQVpGyq0waC+4pOsmo-StZfwpKfk0da2bVESK+yzyYY3Jg@mail.gmail.com>
Message-ID: <52D3F894.9000503@redhat.com>

On 01/11/2014 10:54 AM, Arun Gupta wrote:
> I started bin/standalone.sh, deployed a WAR file (name is
> http-1.0-SNAPSHOT.war) with just one index.jsp. Accessing
> localhost:8080/http shows the expected results. Tried the same with
> bin/domain.sh but now localhost:8080/http is giving a 404.

How exactly did you deploy it?

> What are the port number of the servers started in this managed domain
> ? Is Ports +0 and +150 in admin console trying to display that
> information ? If yes, then that is not very intuitive and the exact
> value of the port should be displayed. If not, what are these values ?
> Should this app be accessible on localhost:8080 ?
>
> Tried enabling the app from admin console and got the error:
> Failed to enable http-1.0-SNAPSHOT.war.
>
> Unexpected HTTP response: 500
>
> Request
> {
>      "address" => [("deployment" => "http-1.0-SNAPSHOT.war")],
>      "operation" => "deploy"
> }
>
> Response
>
> Internal Server Error
> {
>      "outcome" => "failed",
>      "failure-description" => "JBAS014884: No operation named 'deploy'
> exists at address [(\"deployment\" => \"http-1.0-SNAPSHOT.war\")]",
>      "rolled-back" => true
> }
>
> Is this the correct way to deploy the app on managed domain ?

No, it has to be deployed on server groups.


Alexey

>
> Arun
>

From arun.gupta at gmail.com  Mon Jan 13 11:03:22 2014
From: arun.gupta at gmail.com (Arun Gupta)
Date: Mon, 13 Jan 2014 17:03:22 +0100
Subject: [wildfly-dev] Deploying app on managed domain
In-Reply-To: <52D3F894.9000503@redhat.com>
References: <CAGBoHQVpGyq0waC+4pOsmo-StZfwpKfk0da2bVESK+yzyYY3Jg@mail.gmail.com>
	<52D3F894.9000503@redhat.com>
Message-ID: <CAGBoHQXjH7Nar1oAudjM7pw3ca6463L7CcMDM3K1JZvQcyN0xQ@mail.gmail.com>

>> I started bin/standalone.sh, deployed a WAR file (name is
>> http-1.0-SNAPSHOT.war) with just one index.jsp. Accessing
>> localhost:8080/http shows the expected results. Tried the same with
>> bin/domain.sh but now localhost:8080/http is giving a 404.
>
> How exactly did you deploy it?

- localhost:9990/console
- Manage Deployments
- Deployed the app and it did not ask for server groups.

Redeployed using jboss-cli as:

deploy ~/workspaces/wildfly-lab/samples/javaee7/target/javaee7-1.0-SNAPSHOT.war
--server-groups=main-server-group

and that worked.

However deploying using admin console (following the steps listed
above) does not work for standalone. Or at least the application is
not accessible at http://localhost:8080/javaee7-1.0-SNAPSHOT. What is
the context path of the deployed application ?

Arun



>
>> What are the port number of the servers started in this managed domain
>> ? Is Ports +0 and +150 in admin console trying to display that
>> information ? If yes, then that is not very intuitive and the exact
>> value of the port should be displayed. If not, what are these values ?
>> Should this app be accessible on localhost:8080 ?
>>
>> Tried enabling the app from admin console and got the error:
>> Failed to enable http-1.0-SNAPSHOT.war.
>>
>> Unexpected HTTP response: 500
>>
>> Request
>> {
>>      "address" => [("deployment" => "http-1.0-SNAPSHOT.war")],
>>      "operation" => "deploy"
>> }
>>
>> Response
>>
>> Internal Server Error
>> {
>>      "outcome" => "failed",
>>      "failure-description" => "JBAS014884: No operation named 'deploy'
>> exists at address [(\"deployment\" => \"http-1.0-SNAPSHOT.war\")]",
>>      "rolled-back" => true
>> }
>>
>> Is this the correct way to deploy the app on managed domain ?
>
> No, it has to be deployed on server groups.
>
>
> Alexey
>
>>
>> Arun
>>
> _______________________________________________
> 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 rory.odonnell at oracle.com  Tue Jan 14 05:38:36 2014
From: rory.odonnell at oracle.com (Rory O'Donnell Oracle, Dublin Ireland)
Date: Tue, 14 Jan 2014 10:38:36 +0000
Subject: [wildfly-dev] JDK 8 Build 123 & JDK 7 Update 60 build 02 are
	available on java.net
Message-ID: <52D513AC.3070008@oracle.com>

Hi Guys,

Haven't heard from you in sometime, hope all is progressing well. Please
let me know if you are seeing any issues.

JDK 8 Build b123 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/20140114/1a6f2274/attachment-0001.html 

From rsearls at redhat.com  Tue Jan 14 14:20:35 2014
From: rsearls at redhat.com (Rebecca Searls)
Date: Tue, 14 Jan 2014 14:20:35 -0500 (EST)
Subject: [wildfly-dev] Referencing BouncyCastle
In-Reply-To: <938969317.1178545.1389727194389.JavaMail.root@redhat.com>
Message-ID: <80816505.1178706.1389727235664.JavaMail.root@redhat.com>


Need wildFly to use bouncycastle for cxf tests.
Add bouncycastle ref in standalone.xml as follows:

<subsystem xmlns="urn:jboss:domain:ee:2.0">
            <global-modules>
                <module name="org.bouncycastle" slot="main"/>
            </global-modules>
  :


But it does not appear to be found and getting stacktrace.
Any suggestions?


13:45:10,529 ERROR [stderr] (default task-3) java.lang.Exception: Please check that the Bouncy Castle provider is installed.
13:45:10,529 ERROR [stderr] (default task-3) 	at org.jboss.test.ws.jaxws.samples.wsse.policy.basic.SignEncryptHelper.invoke(SignEncryptHelper.java:94)
13:45:10,529 ERROR [stderr] (default task-3) 	at org.jboss.test.ws.jaxws.samples.wsse.policy.basic.SignEncryptHelper.testSignEncryptUsingConfigProperties(SignEncryptHelper.java:72)
13:45:10,529 ERROR [stderr] (default task-3) 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
13:45:10,529 ERROR [stderr] (default task-3) 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
13:45:10,529 ERROR [stderr] (default task-3) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
13:45:10,529 ERROR [stderr] (default task-3) 	at java.lang.reflect.Method.invoke(Method.java:606)
13:45:10,530 ERROR [stderr] (default task-3) 	at org.jboss.wsf.test.TestServlet.invokeMethod(TestServlet.java:152)
13:45:10,530 ERROR [stderr] (default task-3) 	at org.jboss.wsf.test.TestServlet.doGet(TestServlet.java:89)
13:45:10,530 ERROR [stderr] (default task-3) 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
13:45:10,530 ERROR [stderr] (default task-3) 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
13:45:10,530 ERROR [stderr] (default task-3) 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87)
13:45:10,530 ERROR [stderr] (default task-3) 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
13:45:10,530 ERROR [stderr] (default task-3) 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
13:45:10,531 ERROR [stderr] (default task-3) 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:70)
13:45:10,531 ERROR [stderr] (default task-3) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
13:45:10,531 ERROR [stderr] (default task-3) 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113)
13:45:10,531 ERROR [stderr] (default task-3) 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
13:45:10,531 ERROR [stderr] (default task-3) 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
13:45:10,531 ERROR [stderr] (default task-3) 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61)
13:45:10,531 ERROR [stderr] (default task-3) 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:67)
13:45:10,532 ERROR [stderr] (default task-3) 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70)
13:45:10,532 ERROR [stderr] (default task-3) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
13:45:10,532 ERROR [stderr] (default task-3) 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
13:45:10,532 ERROR [stderr] (default task-3) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
13:45:10,532 ERROR [stderr] (default task-3) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
13:45:10,532 ERROR [stderr] (default task-3) 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240)
13:45:10,532 ERROR [stderr] (default task-3) 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
13:45:10,533 ERROR [stderr] (default task-3) 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
13:45:10,533 ERROR [stderr] (default task-3) 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
13:45:10,533 ERROR [stderr] (default task-3) 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:164)
13:45:10,533 ERROR [stderr] (default task-3) 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:654)
13:45:10,533 ERROR [stderr] (default task-3) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
13:45:10,533 ERROR [stderr] (default task-3) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
13:45:10,533 ERROR [stderr] (default task-3) 	at java.lang.Thread.run(Thread.java:724)
13:45:10,534 ERROR [stderr] (default task-3) Caused by: javax.xml.ws.soap.SOAPFaultException: Cannot encrypt data
13:45:10,534 ERROR [stderr] (default task-3) 	at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:157)
13:45:10,534 ERROR [stderr] (default task-3) 	at com.sun.proxy.$Proxy280.sayHello(Unknown Source)
13:45:10,534 ERROR [stderr] (default task-3) 	at org.jboss.test.ws.jaxws.samples.wsse.policy.basic.SignEncryptHelper.invoke(SignEncryptHelper.java:90)
13:45:10,534 ERROR [stderr] (default task-3) 	... 33 more
13:45:10,534 ERROR [stderr] (default task-3) Caused by: org.apache.cxf.ws.policy.PolicyException: Cannot encrypt data
13:45:10,535 ERROR [stderr] (default task-3) 	at org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder.policyNotAsserted(AbstractBindingBuilder.java:294)
13:45:10,535 ERROR [stderr] (default task-3) 	at org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.doEncryption(AsymmetricBindingHandler.java:461)
13:45:10,535 ERROR [stderr] (default task-3) 	at org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.doSignBeforeEncrypt(AsymmetricBindingHandler.java:190)
13:45:10,535 ERROR [stderr] (default task-3) 	at org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.handleBinding(AsymmetricBindingHandler.java:98)
13:45:10,535 ERROR [stderr] (default task-3) 	at org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:176)
13:45:10,535 ERROR [stderr] (default task-3) 	at org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:90)
13:45:10,535 ERROR [stderr] (default task-3) 	at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
13:45:10,535 ERROR [stderr] (default task-3) 	at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:565)
13:45:10,536 ERROR [stderr] (default task-3) 	at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:474)
13:45:10,536 ERROR [stderr] (default task-3) 	at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:377)
13:45:10,536 ERROR [stderr] (default task-3) 	at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:330)
13:45:10,536 ERROR [stderr] (default task-3) 	at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
13:45:10,536 ERROR [stderr] (default task-3) 	at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135)
13:45:10,536 ERROR [stderr] (default task-3) 	... 35 more
13:45:12,533 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-6) JBAS017535: Unregister web context: /jaxws-samples-wsse-policy-sign-encrypt-gcm

From asoldano at redhat.com  Wed Jan 15 02:08:04 2014
From: asoldano at redhat.com (Alessio Soldano)
Date: Wed, 15 Jan 2014 08:08:04 +0100
Subject: [wildfly-dev] Referencing BouncyCastle
In-Reply-To: <80816505.1178706.1389727235664.JavaMail.root@redhat.com>
References: <80816505.1178706.1389727235664.JavaMail.root@redhat.com>
Message-ID: <52D633D4.2030505@redhat.com>

Hi Rebecca,
the test you're running here is also run with an equivalent client 
executed out of container; is that failing too? (and hence is the 
problem a more general one, unrelated to WildFly dependencies?)
Is the org.bouncycastle.jce.provider.BouncyCastleProvider security 
provider registered in your JDK /jre/lib/security/java.security file?

Cheers
Alessio

On 14/01/14 20:20, Rebecca Searls wrote:
> Need wildFly to use bouncycastle for cxf tests.
> Add bouncycastle ref in standalone.xml as follows:
>
> <subsystem xmlns="urn:jboss:domain:ee:2.0">
>              <global-modules>
>                  <module name="org.bouncycastle" slot="main"/>
>              </global-modules>
>    :
>
>
> But it does not appear to be found and getting stacktrace.
> Any suggestions?
>
>
> 13:45:10,529 ERROR [stderr] (default task-3) java.lang.Exception: Please check that the Bouncy Castle provider is installed.
> 13:45:10,529 ERROR [stderr] (default task-3) 	at org.jboss.test.ws.jaxws.samples.wsse.policy.basic.SignEncryptHelper.invoke(SignEncryptHelper.java:94)
> 13:45:10,529 ERROR [stderr] (default task-3) 	at org.jboss.test.ws.jaxws.samples.wsse.policy.basic.SignEncryptHelper.testSignEncryptUsingConfigProperties(SignEncryptHelper.java:72)
> 13:45:10,529 ERROR [stderr] (default task-3) 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 13:45:10,529 ERROR [stderr] (default task-3) 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 13:45:10,529 ERROR [stderr] (default task-3) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 13:45:10,529 ERROR [stderr] (default task-3) 	at java.lang.reflect.Method.invoke(Method.java:606)
> 13:45:10,530 ERROR [stderr] (default task-3) 	at org.jboss.wsf.test.TestServlet.invokeMethod(TestServlet.java:152)
> 13:45:10,530 ERROR [stderr] (default task-3) 	at org.jboss.wsf.test.TestServlet.doGet(TestServlet.java:89)
> 13:45:10,530 ERROR [stderr] (default task-3) 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> 13:45:10,530 ERROR [stderr] (default task-3) 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> 13:45:10,530 ERROR [stderr] (default task-3) 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87)
> 13:45:10,530 ERROR [stderr] (default task-3) 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
> 13:45:10,530 ERROR [stderr] (default task-3) 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> 13:45:10,531 ERROR [stderr] (default task-3) 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:70)
> 13:45:10,531 ERROR [stderr] (default task-3) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> 13:45:10,531 ERROR [stderr] (default task-3) 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113)
> 13:45:10,531 ERROR [stderr] (default task-3) 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
> 13:45:10,531 ERROR [stderr] (default task-3) 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
> 13:45:10,531 ERROR [stderr] (default task-3) 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61)
> 13:45:10,531 ERROR [stderr] (default task-3) 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:67)
> 13:45:10,532 ERROR [stderr] (default task-3) 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70)
> 13:45:10,532 ERROR [stderr] (default task-3) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> 13:45:10,532 ERROR [stderr] (default task-3) 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 13:45:10,532 ERROR [stderr] (default task-3) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> 13:45:10,532 ERROR [stderr] (default task-3) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> 13:45:10,532 ERROR [stderr] (default task-3) 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240)
> 13:45:10,532 ERROR [stderr] (default task-3) 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
> 13:45:10,533 ERROR [stderr] (default task-3) 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
> 13:45:10,533 ERROR [stderr] (default task-3) 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
> 13:45:10,533 ERROR [stderr] (default task-3) 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:164)
> 13:45:10,533 ERROR [stderr] (default task-3) 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:654)
> 13:45:10,533 ERROR [stderr] (default task-3) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> 13:45:10,533 ERROR [stderr] (default task-3) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> 13:45:10,533 ERROR [stderr] (default task-3) 	at java.lang.Thread.run(Thread.java:724)
> 13:45:10,534 ERROR [stderr] (default task-3) Caused by: javax.xml.ws.soap.SOAPFaultException: Cannot encrypt data
> 13:45:10,534 ERROR [stderr] (default task-3) 	at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:157)
> 13:45:10,534 ERROR [stderr] (default task-3) 	at com.sun.proxy.$Proxy280.sayHello(Unknown Source)
> 13:45:10,534 ERROR [stderr] (default task-3) 	at org.jboss.test.ws.jaxws.samples.wsse.policy.basic.SignEncryptHelper.invoke(SignEncryptHelper.java:90)
> 13:45:10,534 ERROR [stderr] (default task-3) 	... 33 more
> 13:45:10,534 ERROR [stderr] (default task-3) Caused by: org.apache.cxf.ws.policy.PolicyException: Cannot encrypt data
> 13:45:10,535 ERROR [stderr] (default task-3) 	at org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder.policyNotAsserted(AbstractBindingBuilder.java:294)
> 13:45:10,535 ERROR [stderr] (default task-3) 	at org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.doEncryption(AsymmetricBindingHandler.java:461)
> 13:45:10,535 ERROR [stderr] (default task-3) 	at org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.doSignBeforeEncrypt(AsymmetricBindingHandler.java:190)
> 13:45:10,535 ERROR [stderr] (default task-3) 	at org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.handleBinding(AsymmetricBindingHandler.java:98)
> 13:45:10,535 ERROR [stderr] (default task-3) 	at org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:176)
> 13:45:10,535 ERROR [stderr] (default task-3) 	at org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:90)
> 13:45:10,535 ERROR [stderr] (default task-3) 	at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
> 13:45:10,535 ERROR [stderr] (default task-3) 	at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:565)
> 13:45:10,536 ERROR [stderr] (default task-3) 	at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:474)
> 13:45:10,536 ERROR [stderr] (default task-3) 	at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:377)
> 13:45:10,536 ERROR [stderr] (default task-3) 	at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:330)
> 13:45:10,536 ERROR [stderr] (default task-3) 	at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
> 13:45:10,536 ERROR [stderr] (default task-3) 	at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135)
> 13:45:10,536 ERROR [stderr] (default task-3) 	... 35 more
> 13:45:12,533 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-6) JBAS017535: Unregister web context: /jaxws-samples-wsse-policy-sign-encrypt-gcm
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


-- 
Alessio Soldano
Web Service Lead, JBoss


From rsearls at redhat.com  Wed Jan 15 08:13:36 2014
From: rsearls at redhat.com (Rebecca Searls)
Date: Wed, 15 Jan 2014 08:13:36 -0500 (EST)
Subject: [wildfly-dev] Referencing BouncyCastle
In-Reply-To: <52D633D4.2030505@redhat.com>
References: <80816505.1178706.1389727235664.JavaMail.root@redhat.com>
	<52D633D4.2030505@redhat.com>
Message-ID: <1089541087.1685631.1389791616225.JavaMail.root@redhat.com>

Hi Alessio,

My JDK /jre/lib/security/java.security is set as follows. BouncyCastleProvider is security.provider.10.
       security.provider.1=sun.security.provider.Sun
       security.provider.2=sun.security.rsa.SunRsaSign
       security.provider.3=sun.security.ec.SunEC
       security.provider.4=com.sun.net.ssl.internal.ssl.Provider
       security.provider.5=com.sun.crypto.provider.SunJCE
       security.provider.6=sun.security.jgss.SunProvider
       security.provider.7=com.sun.security.sasl.Provider
       security.provider.8=org.jcp.xml.dsig.internal.dom.XMLDSigRI
       security.provider.9=sun.security.smartcardio.SunPCSC
       security.provider.10=org.bouncycastle.jce.provider.BouncyCastleProvider

Here is one of the tests that is failing.  If the method name is an accurate description of its function, then this
is a serverSide issue of some type.

Failed tests:      testServerSideUsingConfigProperties(org.jboss.test.ws.jaxws.samples.wsse.policy.basic.SignEncryptGCMTestCase): expected:<[1]> but was:<[# Failed tests:  # Error tests: testSignEncryptUsingConfigProperties: java.lang.Exception Please check that the Bouncy Castle provider is installed.]>








----- Original Message -----
> From: "Alessio Soldano" <asoldano at redhat.com>
> To: wildfly-dev at lists.jboss.org
> Sent: Wednesday, January 15, 2014 2:08:04 AM
> Subject: Re: [wildfly-dev] Referencing BouncyCastle
> 
> Hi Rebecca,
> the test you're running here is also run with an equivalent client
> executed out of container; is that failing too? (and hence is the
> problem a more general one, unrelated to WildFly dependencies?)
> Is the org.bouncycastle.jce.provider.BouncyCastleProvider security
> provider registered in your JDK /jre/lib/security/java.security file?
> 
> Cheers
> Alessio
> 
> On 14/01/14 20:20, Rebecca Searls wrote:
> > Need wildFly to use bouncycastle for cxf tests.
> > Add bouncycastle ref in standalone.xml as follows:
> >
> > <subsystem xmlns="urn:jboss:domain:ee:2.0">
> >              <global-modules>
> >                  <module name="org.bouncycastle" slot="main"/>
> >              </global-modules>
> >    :
> >
> >
> > But it does not appear to be found and getting stacktrace.
> > Any suggestions?
> >
> >
> > 13:45:10,529 ERROR [stderr] (default task-3) java.lang.Exception: Please
> > check that the Bouncy Castle provider is installed.
> > 13:45:10,529 ERROR [stderr] (default task-3) 	at
> > org.jboss.test.ws.jaxws.samples.wsse.policy.basic.SignEncryptHelper.invoke(SignEncryptHelper.java:94)
> > 13:45:10,529 ERROR [stderr] (default task-3) 	at
> > org.jboss.test.ws.jaxws.samples.wsse.policy.basic.SignEncryptHelper.testSignEncryptUsingConfigProperties(SignEncryptHelper.java:72)
> > 13:45:10,529 ERROR [stderr] (default task-3) 	at
> > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > 13:45:10,529 ERROR [stderr] (default task-3) 	at
> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> > 13:45:10,529 ERROR [stderr] (default task-3) 	at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > 13:45:10,529 ERROR [stderr] (default task-3) 	at
> > java.lang.reflect.Method.invoke(Method.java:606)
> > 13:45:10,530 ERROR [stderr] (default task-3) 	at
> > org.jboss.wsf.test.TestServlet.invokeMethod(TestServlet.java:152)
> > 13:45:10,530 ERROR [stderr] (default task-3) 	at
> > org.jboss.wsf.test.TestServlet.doGet(TestServlet.java:89)
> > 13:45:10,530 ERROR [stderr] (default task-3) 	at
> > javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> > 13:45:10,530 ERROR [stderr] (default task-3) 	at
> > javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> > 13:45:10,530 ERROR [stderr] (default task-3) 	at
> > io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87)
> > 13:45:10,530 ERROR [stderr] (default task-3) 	at
> > io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
> > 13:45:10,530 ERROR [stderr] (default task-3) 	at
> > io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> > 13:45:10,531 ERROR [stderr] (default task-3) 	at
> > org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:70)
> > 13:45:10,531 ERROR [stderr] (default task-3) 	at
> > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> > 13:45:10,531 ERROR [stderr] (default task-3) 	at
> > io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113)
> > 13:45:10,531 ERROR [stderr] (default task-3) 	at
> > io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
> > 13:45:10,531 ERROR [stderr] (default task-3) 	at
> > io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
> > 13:45:10,531 ERROR [stderr] (default task-3) 	at
> > io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61)
> > 13:45:10,531 ERROR [stderr] (default task-3) 	at
> > io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:67)
> > 13:45:10,532 ERROR [stderr] (default task-3) 	at
> > io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70)
> > 13:45:10,532 ERROR [stderr] (default task-3) 	at
> > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> > 13:45:10,532 ERROR [stderr] (default task-3) 	at
> > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> > 13:45:10,532 ERROR [stderr] (default task-3) 	at
> > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> > 13:45:10,532 ERROR [stderr] (default task-3) 	at
> > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> > 13:45:10,532 ERROR [stderr] (default task-3) 	at
> > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240)
> > 13:45:10,532 ERROR [stderr] (default task-3) 	at
> > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
> > 13:45:10,533 ERROR [stderr] (default task-3) 	at
> > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
> > 13:45:10,533 ERROR [stderr] (default task-3) 	at
> > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
> > 13:45:10,533 ERROR [stderr] (default task-3) 	at
> > io.undertow.server.Connectors.executeRootHandler(Connectors.java:164)
> > 13:45:10,533 ERROR [stderr] (default task-3) 	at
> > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:654)
> > 13:45:10,533 ERROR [stderr] (default task-3) 	at
> > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> > 13:45:10,533 ERROR [stderr] (default task-3) 	at
> > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> > 13:45:10,533 ERROR [stderr] (default task-3) 	at
> > java.lang.Thread.run(Thread.java:724)
> > 13:45:10,534 ERROR [stderr] (default task-3) Caused by:
> > javax.xml.ws.soap.SOAPFaultException: Cannot encrypt data
> > 13:45:10,534 ERROR [stderr] (default task-3) 	at
> > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:157)
> > 13:45:10,534 ERROR [stderr] (default task-3) 	at
> > com.sun.proxy.$Proxy280.sayHello(Unknown Source)
> > 13:45:10,534 ERROR [stderr] (default task-3) 	at
> > org.jboss.test.ws.jaxws.samples.wsse.policy.basic.SignEncryptHelper.invoke(SignEncryptHelper.java:90)
> > 13:45:10,534 ERROR [stderr] (default task-3) 	... 33 more
> > 13:45:10,534 ERROR [stderr] (default task-3) Caused by:
> > org.apache.cxf.ws.policy.PolicyException: Cannot encrypt data
> > 13:45:10,535 ERROR [stderr] (default task-3) 	at
> > org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder.policyNotAsserted(AbstractBindingBuilder.java:294)
> > 13:45:10,535 ERROR [stderr] (default task-3) 	at
> > org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.doEncryption(AsymmetricBindingHandler.java:461)
> > 13:45:10,535 ERROR [stderr] (default task-3) 	at
> > org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.doSignBeforeEncrypt(AsymmetricBindingHandler.java:190)
> > 13:45:10,535 ERROR [stderr] (default task-3) 	at
> > org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.handleBinding(AsymmetricBindingHandler.java:98)
> > 13:45:10,535 ERROR [stderr] (default task-3) 	at
> > org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:176)
> > 13:45:10,535 ERROR [stderr] (default task-3) 	at
> > org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:90)
> > 13:45:10,535 ERROR [stderr] (default task-3) 	at
> > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
> > 13:45:10,535 ERROR [stderr] (default task-3) 	at
> > org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:565)
> > 13:45:10,536 ERROR [stderr] (default task-3) 	at
> > org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:474)
> > 13:45:10,536 ERROR [stderr] (default task-3) 	at
> > org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:377)
> > 13:45:10,536 ERROR [stderr] (default task-3) 	at
> > org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:330)
> > 13:45:10,536 ERROR [stderr] (default task-3) 	at
> > org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
> > 13:45:10,536 ERROR [stderr] (default task-3) 	at
> > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135)
> > 13:45:10,536 ERROR [stderr] (default task-3) 	... 35 more
> > 13:45:12,533 INFO  [org.wildfly.extension.undertow] (MSC service thread
> > 1-6) JBAS017535: Unregister web context:
> > /jaxws-samples-wsse-policy-sign-encrypt-gcm
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> 
> --
> Alessio Soldano
> Web Service Lead, JBoss
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 

From rsearls at redhat.com  Wed Jan 15 11:13:23 2014
From: rsearls at redhat.com (Rebecca Searls)
Date: Wed, 15 Jan 2014 11:13:23 -0500 (EST)
Subject: [wildfly-dev] Referencing BouncyCastle
In-Reply-To: <1089541087.1685631.1389791616225.JavaMail.root@redhat.com>
References: <80816505.1178706.1389727235664.JavaMail.root@redhat.com>
	<52D633D4.2030505@redhat.com>
	<1089541087.1685631.1389791616225.JavaMail.root@redhat.com>
Message-ID: <1606766642.1869373.1389802403270.JavaMail.root@redhat.com>


Getting the unlimited crypto jdk extension installed properly and adding 
<module name="org.bouncycastle" slot="main"/> to standalone.xml has resolved 
these test failures.


----- Original Message -----
> From: "Rebecca Searls" <rsearls at redhat.com>
> To: "Alessio Soldano" <asoldano at redhat.com>
> Cc: wildfly-dev at lists.jboss.org
> Sent: Wednesday, January 15, 2014 8:13:36 AM
> Subject: Re: [wildfly-dev] Referencing BouncyCastle
> 
> Hi Alessio,
> 
> My JDK /jre/lib/security/java.security is set as follows.
> BouncyCastleProvider is security.provider.10.
>        security.provider.1=sun.security.provider.Sun
>        security.provider.2=sun.security.rsa.SunRsaSign
>        security.provider.3=sun.security.ec.SunEC
>        security.provider.4=com.sun.net.ssl.internal.ssl.Provider
>        security.provider.5=com.sun.crypto.provider.SunJCE
>        security.provider.6=sun.security.jgss.SunProvider
>        security.provider.7=com.sun.security.sasl.Provider
>        security.provider.8=org.jcp.xml.dsig.internal.dom.XMLDSigRI
>        security.provider.9=sun.security.smartcardio.SunPCSC
>        security.provider.10=org.bouncycastle.jce.provider.BouncyCastleProvider
> 
> Here is one of the tests that is failing.  If the method name is an accurate
> description of its function, then this
> is a serverSide issue of some type.
> 
> Failed tests:
> testServerSideUsingConfigProperties(org.jboss.test.ws.jaxws.samples.wsse.policy.basic.SignEncryptGCMTestCase):
> expected:<[1]> but was:<[# Failed tests:  # Error tests:
> testSignEncryptUsingConfigProperties: java.lang.Exception Please check that
> the Bouncy Castle provider is installed.]>
> 
> 
> 
> 
> 
> 
> 
> 
> ----- Original Message -----
> > From: "Alessio Soldano" <asoldano at redhat.com>
> > To: wildfly-dev at lists.jboss.org
> > Sent: Wednesday, January 15, 2014 2:08:04 AM
> > Subject: Re: [wildfly-dev] Referencing BouncyCastle
> > 
> > Hi Rebecca,
> > the test you're running here is also run with an equivalent client
> > executed out of container; is that failing too? (and hence is the
> > problem a more general one, unrelated to WildFly dependencies?)
> > Is the org.bouncycastle.jce.provider.BouncyCastleProvider security
> > provider registered in your JDK /jre/lib/security/java.security file?
> > 
> > Cheers
> > Alessio
> > 
> > On 14/01/14 20:20, Rebecca Searls wrote:
> > > Need wildFly to use bouncycastle for cxf tests.
> > > Add bouncycastle ref in standalone.xml as follows:
> > >
> > > <subsystem xmlns="urn:jboss:domain:ee:2.0">
> > >              <global-modules>
> > >                  <module name="org.bouncycastle" slot="main"/>
> > >              </global-modules>
> > >    :
> > >
> > >
> > > But it does not appear to be found and getting stacktrace.
> > > Any suggestions?
> > >
> > >
> > > 13:45:10,529 ERROR [stderr] (default task-3) java.lang.Exception: Please
> > > check that the Bouncy Castle provider is installed.
> > > 13:45:10,529 ERROR [stderr] (default task-3) 	at
> > > org.jboss.test.ws.jaxws.samples.wsse.policy.basic.SignEncryptHelper.invoke(SignEncryptHelper.java:94)
> > > 13:45:10,529 ERROR [stderr] (default task-3) 	at
> > > org.jboss.test.ws.jaxws.samples.wsse.policy.basic.SignEncryptHelper.testSignEncryptUsingConfigProperties(SignEncryptHelper.java:72)
> > > 13:45:10,529 ERROR [stderr] (default task-3) 	at
> > > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > 13:45:10,529 ERROR [stderr] (default task-3) 	at
> > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> > > 13:45:10,529 ERROR [stderr] (default task-3) 	at
> > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > > 13:45:10,529 ERROR [stderr] (default task-3) 	at
> > > java.lang.reflect.Method.invoke(Method.java:606)
> > > 13:45:10,530 ERROR [stderr] (default task-3) 	at
> > > org.jboss.wsf.test.TestServlet.invokeMethod(TestServlet.java:152)
> > > 13:45:10,530 ERROR [stderr] (default task-3) 	at
> > > org.jboss.wsf.test.TestServlet.doGet(TestServlet.java:89)
> > > 13:45:10,530 ERROR [stderr] (default task-3) 	at
> > > javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> > > 13:45:10,530 ERROR [stderr] (default task-3) 	at
> > > javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> > > 13:45:10,530 ERROR [stderr] (default task-3) 	at
> > > io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87)
> > > 13:45:10,530 ERROR [stderr] (default task-3) 	at
> > > io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
> > > 13:45:10,530 ERROR [stderr] (default task-3) 	at
> > > io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> > > 13:45:10,531 ERROR [stderr] (default task-3) 	at
> > > org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:70)
> > > 13:45:10,531 ERROR [stderr] (default task-3) 	at
> > > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> > > 13:45:10,531 ERROR [stderr] (default task-3) 	at
> > > io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113)
> > > 13:45:10,531 ERROR [stderr] (default task-3) 	at
> > > io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
> > > 13:45:10,531 ERROR [stderr] (default task-3) 	at
> > > io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
> > > 13:45:10,531 ERROR [stderr] (default task-3) 	at
> > > io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61)
> > > 13:45:10,531 ERROR [stderr] (default task-3) 	at
> > > io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:67)
> > > 13:45:10,532 ERROR [stderr] (default task-3) 	at
> > > io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70)
> > > 13:45:10,532 ERROR [stderr] (default task-3) 	at
> > > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> > > 13:45:10,532 ERROR [stderr] (default task-3) 	at
> > > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> > > 13:45:10,532 ERROR [stderr] (default task-3) 	at
> > > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> > > 13:45:10,532 ERROR [stderr] (default task-3) 	at
> > > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> > > 13:45:10,532 ERROR [stderr] (default task-3) 	at
> > > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240)
> > > 13:45:10,532 ERROR [stderr] (default task-3) 	at
> > > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
> > > 13:45:10,533 ERROR [stderr] (default task-3) 	at
> > > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
> > > 13:45:10,533 ERROR [stderr] (default task-3) 	at
> > > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
> > > 13:45:10,533 ERROR [stderr] (default task-3) 	at
> > > io.undertow.server.Connectors.executeRootHandler(Connectors.java:164)
> > > 13:45:10,533 ERROR [stderr] (default task-3) 	at
> > > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:654)
> > > 13:45:10,533 ERROR [stderr] (default task-3) 	at
> > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> > > 13:45:10,533 ERROR [stderr] (default task-3) 	at
> > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> > > 13:45:10,533 ERROR [stderr] (default task-3) 	at
> > > java.lang.Thread.run(Thread.java:724)
> > > 13:45:10,534 ERROR [stderr] (default task-3) Caused by:
> > > javax.xml.ws.soap.SOAPFaultException: Cannot encrypt data
> > > 13:45:10,534 ERROR [stderr] (default task-3) 	at
> > > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:157)
> > > 13:45:10,534 ERROR [stderr] (default task-3) 	at
> > > com.sun.proxy.$Proxy280.sayHello(Unknown Source)
> > > 13:45:10,534 ERROR [stderr] (default task-3) 	at
> > > org.jboss.test.ws.jaxws.samples.wsse.policy.basic.SignEncryptHelper.invoke(SignEncryptHelper.java:90)
> > > 13:45:10,534 ERROR [stderr] (default task-3) 	... 33 more
> > > 13:45:10,534 ERROR [stderr] (default task-3) Caused by:
> > > org.apache.cxf.ws.policy.PolicyException: Cannot encrypt data
> > > 13:45:10,535 ERROR [stderr] (default task-3) 	at
> > > org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder.policyNotAsserted(AbstractBindingBuilder.java:294)
> > > 13:45:10,535 ERROR [stderr] (default task-3) 	at
> > > org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.doEncryption(AsymmetricBindingHandler.java:461)
> > > 13:45:10,535 ERROR [stderr] (default task-3) 	at
> > > org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.doSignBeforeEncrypt(AsymmetricBindingHandler.java:190)
> > > 13:45:10,535 ERROR [stderr] (default task-3) 	at
> > > org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.handleBinding(AsymmetricBindingHandler.java:98)
> > > 13:45:10,535 ERROR [stderr] (default task-3) 	at
> > > org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:176)
> > > 13:45:10,535 ERROR [stderr] (default task-3) 	at
> > > org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:90)
> > > 13:45:10,535 ERROR [stderr] (default task-3) 	at
> > > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
> > > 13:45:10,535 ERROR [stderr] (default task-3) 	at
> > > org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:565)
> > > 13:45:10,536 ERROR [stderr] (default task-3) 	at
> > > org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:474)
> > > 13:45:10,536 ERROR [stderr] (default task-3) 	at
> > > org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:377)
> > > 13:45:10,536 ERROR [stderr] (default task-3) 	at
> > > org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:330)
> > > 13:45:10,536 ERROR [stderr] (default task-3) 	at
> > > org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
> > > 13:45:10,536 ERROR [stderr] (default task-3) 	at
> > > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135)
> > > 13:45:10,536 ERROR [stderr] (default task-3) 	... 35 more
> > > 13:45:12,533 INFO  [org.wildfly.extension.undertow] (MSC service thread
> > > 1-6) JBAS017535: Unregister web context:
> > > /jaxws-samples-wsse-policy-sign-encrypt-gcm
> > > _______________________________________________
> > > wildfly-dev mailing list
> > > wildfly-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> > 
> > 
> > --
> > Alessio Soldano
> > Web Service Lead, JBoss
> > 
> > _______________________________________________
> > 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 jason.greene at redhat.com  Thu Jan 16 08:25:59 2014
From: jason.greene at redhat.com (Jason Greene)
Date: Thu, 16 Jan 2014 14:25:59 +0100
Subject: [wildfly-dev] xnio selection err
In-Reply-To: <2CFF953C-0F64-4263-930C-1C0E93351C25@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>
	<E24431FB-EE1F-433F-A259-2966E4D05700@redhat.com>
	<8B57431B-3BC6-4ECE-BB0F-ED8012DDA6BD@gmail.com>
	<A6B1562C-2906-4E02-9C24-8FF511B605A5@redhat.com>
	<6DFAE785-FF64-4540-A7C6-48D7FF10B425@gmail.com>
	<2CFF953C-0F64-4263-930C-1C0E93351C25@gmail.com>
Message-ID: <52F4F230-E801-4D31-B7D8-5DFF329D2CFC@redhat.com>

Yeah if possible that would be great. I didn?t see any errors in the gist you linked.
On Jan 9, 2014, at 4:41 PM, Ales Justin <ales.justin at gmail.com> wrote:

> I guess you still need this, while the app is running?
> 
> -Ales
> 
> On 02 Jan 2014, at 15:25, Ales Justin <ales.justin at gmail.com> wrote:
> 
>>> Oh is it always at shutdown?
>> 
>> No.
>> It's also while the app runs.
>> But dunno how to re-produce it on a constant basis.
>> 
>> -Ales
>> 
>>> On Jan 2, 2014, at 5:28 AM, Ales Justin <ales.justin at gmail.com> wrote:
>>> 
>>>> Here:
>>>> * https://gist.github.com/alesj/8217872
>>>> 
>>>> But I didn't get any WARN log during my "chat", only at shutdown.
>>>> Does it still help? Otherwise I can try to catch this when getting WARNings during chat.
>>>> 
>>>> -Ales
>>>> 
>>>> On 28 Dec 2013, at 17:14, Jason Greene <jgreene at redhat.com> wrote:
>>>> 
>>>>> 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
>>>>>> 
>>>> 
>>>> _______________________________________________
>>>> 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

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



From kpiwko at redhat.com  Thu Jan 16 09:03:48 2014
From: kpiwko at redhat.com (Karel Piwko)
Date: Thu, 16 Jan 2014 15:03:48 +0100
Subject: [wildfly-dev] (Maven) Modules in Arquillian directory
Message-ID: <20140116150348.303eef6f@kapy-ntb-x220>

Hi All,

while focusing on WFLY-2441, I've noticed that only 10 out of 12 modules are
built from Arquillian directory. The rest seem to be some unused code. As my
favorite programming key is 'Del', is there any reason why to keep code that
is very like not used anywhere in the repository, confusing the people?

Namely, it is:

* protocol-servlet
* processor-jsfunit

I can create a JIRA and file a PR if agreed.

Thanks,

Karel

From kpiwko at redhat.com  Thu Jan 16 11:55:30 2014
From: kpiwko at redhat.com (Karel Piwko)
Date: Thu, 16 Jan 2014 17:55:30 +0100
Subject: [wildfly-dev] (Maven) Modules in Arquillian directory
In-Reply-To: <20140116150348.303eef6f@kapy-ntb-x220>
References: <20140116150348.303eef6f@kapy-ntb-x220>
Message-ID: <20140116175530.74acb156@kapy-ntb-x220>

On Thu, 16 Jan 2014 15:03:48 +0100
Karel Piwko <kpiwko at redhat.com> wrote:

> Hi All,
> 
> while focusing on WFLY-2441, I've noticed that only 10 out of 12 modules are
> built from Arquillian directory. The rest seem to be some unused code. As my
> favorite programming key is 'Del', is there any reason why to keep code that
> is very like not used anywhere in the repository, confusing the people?
> 
> Namely, it is:
> 
> * protocol-servlet
> * processor-jsfunit
> 
> I can create a JIRA and file a PR if agreed.

Here it is: https://issues.jboss.org/browse/WFLY-2768

> 
> Thanks,
> 
> Karel
> _______________________________________________
> 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 Jan 16 16:16:07 2014
From: arun.gupta at gmail.com (Arun Gupta)
Date: Thu, 16 Jan 2014 22:16:07 +0100
Subject: [wildfly-dev] How to delete a user ?
Message-ID: <CAGBoHQWkP=n5urdtHKDbpehX5opE+k7AaVtHKOM46juHmL3Xrg@mail.gmail.com>

There is a way to disable a user using add-user.sh -d but no way to delete it.

Is that intentional or a left over ?

Arun

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

From tomaz.cerar at gmail.com  Fri Jan 17 04:18:07 2014
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Fri, 17 Jan 2014 10:18:07 +0100
Subject: [wildfly-dev] How to delete a user ?
In-Reply-To: <CAGBoHQWkP=n5urdtHKDbpehX5opE+k7AaVtHKOM46juHmL3Xrg@mail.gmail.com>
References: <CAGBoHQWkP=n5urdtHKDbpehX5opE+k7AaVtHKOM46juHmL3Xrg@mail.gmail.com>
Message-ID: <CAMquZP4hb5TeiVrxV3SVb4-UH7B-zLmF21-S-f_f1iRa3vP5Eg@mail.gmail.com>

You can open mgmt-users.properties in standalone/configuration
and remove entry you want.

--
tomaz


On Thu, Jan 16, 2014 at 10:16 PM, Arun Gupta <arun.gupta at gmail.com> wrote:

> There is a way to disable a user using add-user.sh -d but no way to delete
> it.
>
> Is that intentional or a left over ?
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140117/5bd786d3/attachment-0001.html 

From tomaz.cerar at gmail.com  Fri Jan 17 04:20:45 2014
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Fri, 17 Jan 2014 10:20:45 +0100
Subject: [wildfly-dev] (Maven) Modules in Arquillian directory
In-Reply-To: <20140116175530.74acb156@kapy-ntb-x220>
References: <20140116150348.303eef6f@kapy-ntb-x220>
	<20140116175530.74acb156@kapy-ntb-x220>
Message-ID: <CAMquZP7CBHNH0ofJEi9S+AO0Phwjb76jBPiC9ey-F5=6xryOsw@mail.gmail.com>

We discussed this yesterday with few people.

We all agree that that two modules should be removed as they have been
commented out of active build more than two years ago, and as such don't
even compile anymore.

--
tomaz


On Thu, Jan 16, 2014 at 5:55 PM, Karel Piwko <kpiwko at redhat.com> wrote:

> On Thu, 16 Jan 2014 15:03:48 +0100
> Karel Piwko <kpiwko at redhat.com> wrote:
>
> > Hi All,
> >
> > while focusing on WFLY-2441, I've noticed that only 10 out of 12 modules
> are
> > built from Arquillian directory. The rest seem to be some unused code.
> As my
> > favorite programming key is 'Del', is there any reason why to keep code
> that
> > is very like not used anywhere in the repository, confusing the people?
> >
> > Namely, it is:
> >
> > * protocol-servlet
> > * processor-jsfunit
> >
> > I can create a JIRA and file a PR if agreed.
>
> Here it is: https://issues.jboss.org/browse/WFLY-2768
>
> >
> > Thanks,
> >
> > Karel
> > _______________________________________________
> > 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/20140117/113c1266/attachment.html 

From arun.gupta at gmail.com  Fri Jan 17 16:09:33 2014
From: arun.gupta at gmail.com (Arun Gupta)
Date: Fri, 17 Jan 2014 22:09:33 +0100
Subject: [wildfly-dev] How to delete a user ?
In-Reply-To: <CAMquZP4hb5TeiVrxV3SVb4-UH7B-zLmF21-S-f_f1iRa3vP5Eg@mail.gmail.com>
References: <CAGBoHQWkP=n5urdtHKDbpehX5opE+k7AaVtHKOM46juHmL3Xrg@mail.gmail.com>
	<CAMquZP4hb5TeiVrxV3SVb4-UH7B-zLmF21-S-f_f1iRa3vP5Eg@mail.gmail.com>
Message-ID: <CAGBoHQWTrqgqs1L6oJAY3sO5ym_yf9irmbAGsU_r_PseOHMcog@mail.gmail.com>

That's what I've been doing :)

I think providing a switch would be a handy RFE.

On Fri, Jan 17, 2014 at 10:18 AM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
> You can open mgmt-users.properties in standalone/configuration
> and remove entry you want.
>
> --
> tomaz
>
>
> On Thu, Jan 16, 2014 at 10:16 PM, Arun Gupta <arun.gupta at gmail.com> wrote:
>>
>> There is a way to disable a user using add-user.sh -d but no way to delete
>> it.
>>
>> Is that intentional or a left over ?
>>
>> 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
>
>



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


From wolfgang.knauf at gmx.de  Fri Jan 17 16:54:09 2014
From: wolfgang.knauf at gmx.de (Wolfgang Knauf)
Date: Fri, 17 Jan 2014 22:54:09 +0100
Subject: [wildfly-dev] How to delete a user ?
In-Reply-To: <CAMquZP4hb5TeiVrxV3SVb4-UH7B-zLmF21-S-f_f1iRa3vP5Eg@mail.gmail.com>
References: <CAGBoHQWkP=n5urdtHKDbpehX5opE+k7AaVtHKOM46juHmL3Xrg@mail.gmail.com>
	<CAMquZP4hb5TeiVrxV3SVb4-UH7B-zLmF21-S-f_f1iRa3vP5Eg@mail.gmail.com>
Message-ID: <52D9A681.3080100@gmx.de>

I got the same idea (with WF8 CR1) a few days ago, and when adding the 
same user name again with "add-user.bat", it still asked me "user 
exists, do you want to update or enable" it. It was an application user, 
and I removed it from "application-users.properties".

But I cannot verify this in the moment, so it is just my reminiscence.

Best regards

Wolfgang

-------- Original-Nachricht --------
Betreff: Re: [wildfly-dev] How to delete a user ?
Von: =?UTF-8?B?VG9tYcW+IENlcmFy?= <tomaz.cerar at gmail.com>
An: Arun Gupta <arun.gupta at gmail.com>
Kopie (CC): WildFly Dev <wildfly-dev at lists.jboss.org>
Datum: Fri, 17 Jan 2014 10:18:07 +0100

> You can open mgmt-users.properties in standalone/configuration
> and remove entry you want.
>
> --
> tomaz
>
>
> On Thu, Jan 16, 2014 at 10:16 PM, Arun Gupta <arun.gupta at gmail.com
> <mailto:arun.gupta at gmail.com>> wrote:
>
>     There is a way to disable a user using add-user.sh -d but no way to
>     delete it.
>
>     Is that intentional or a left over ?
>
>     Arun
>
>     --
>     http://blog.arungupta.me
>     http://twitter.com/arungupta
>     _______________________________________________
>     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
>
>

From claudio at claudius.com.br  Fri Jan 17 21:48:39 2014
From: claudio at claudius.com.br (Claudio Miranda)
Date: Sat, 18 Jan 2014 00:48:39 -0200
Subject: [wildfly-dev] HC and server addresses
Message-ID: <CALbD--pHS3QJMqBm7VvCLFUa-xAM3np-k-ASAqmAc1dbDPE=pQ@mail.gmail.com>

Hi, I was looking for a way to get the HC and server instance ip
address, using the management api.

The server is started as

./domain.sh -b pavlov-0 -bmanagement pavlov-0
-Djboss.domain.base.dir=../lab1-dc
-Djboss.domain.master.address=pavlov-0

I found out the following command

/host=master/core-service=host-environment:read-resource(include-runtime=true,recursive=true,include-defaults=true,include-aliases=true)

The output

{
    "outcome" => "success",
    "result" => {
        "backup-domain-files" => false,
        "default-jvm" => "/opt/javavm/bin/java",
        "domain-base-dir" =>
"/home/claudio/alphaworks/projects/wildfly/build/target/wildfly-8.0.0.Final-SNAPSHOT/bin/../lab1-dc",
        "domain-config-dir" =>
"/home/claudio/alphaworks/projects/wildfly/build/target/wildfly-8.0.0.Final-SNAPSHOT/bin/../lab1-dc/configuration",
        "domain-config-file" =>
"/home/claudio/alphaworks/projects/wildfly/build/target/wildfly-8.0.0.Final-SNAPSHOT/lab1-dc/configuration/domain.xml",
        "domain-content-dir" =>
"/home/claudio/alphaworks/projects/wildfly/build/target/wildfly-8.0.0.Final-SNAPSHOT/bin/../lab1-dc/data/content",
        "domain-data-dir" =>
"/home/claudio/alphaworks/projects/wildfly/build/target/wildfly-8.0.0.Final-SNAPSHOT/bin/../lab1-dc/data",
        "domain-log-dir" =>
"/home/claudio/alphaworks/projects/wildfly/build/target/wildfly-8.0.0.Final-SNAPSHOT/bin/../lab1-dc/log",
        "domain-servers-dir" =>
"/home/claudio/alphaworks/projects/wildfly/build/target/wildfly-8.0.0.Final-SNAPSHOT/bin/../lab1-dc/servers",
        "domain-temp-dir" =>
"/home/claudio/alphaworks/projects/wildfly/build/target/wildfly-8.0.0.Final-SNAPSHOT/bin/../lab1-dc/tmp",
        "home-dir" =>
"/home/claudio/alphaworks/projects/wildfly/build/target/wildfly-8.0.0.Final-SNAPSHOT",
        "host-config-file" =>
"/home/claudio/alphaworks/projects/wildfly/build/target/wildfly-8.0.0.Final-SNAPSHOT/lab1-dc/configuration/host.xml",
        "host-controller-address" => "/127.0.0.1",
        "host-controller-port" => 0,
        "host-name" => "pavlov",
        "initial-running-mode" => "NORMAL",
        "is-restart" => false,
        "modules-dir" =>
"/home/claudio/alphaworks/projects/wildfly/build/target/wildfly-8.0.0.Final-SNAPSHOT/modules",
        "process-controller-address" => "/127.0.0.1",
        "process-controller-port" => 51798,
        "qualified-host-name" => "pavlov",
        "use-cached-dc" => false
    }
}

Looking at the java properties,

jboss.bind.address = pavlov-0
jboss.domain.master.address = pavlov-0
jboss.bind.address.management = pavlov-0

Does the "host-controller-address" property should be pavlov-0 and
"host-controller-port" equal to 9999 ?
Also the "qualified-host-name" and "host-name" equals to pavlov-0 ?

Regards

-- 
  Claudio Miranda

claudio at claudius.com.br
http://www.claudius.com.br

From claudio at claudius.com.br  Sat Jan 18 12:31:50 2014
From: claudio at claudius.com.br (Claudio Miranda)
Date: Sat, 18 Jan 2014 15:31:50 -0200
Subject: [wildfly-dev] Denied to access admin web console of EAP6 after
	removing server-groups
Message-ID: <CALbD--qTzT3bmUzVZu4VBLCoZZnYviyvD5gG62Pk-e8tXnpg2A@mail.gmail.com>

Hi, related to HAL-336

The class org.jboss.as.console.client.core.bootstrap.LoadMainApp,
method execute() has the following


        if(!bootstrapContext.isStandalone()
                && (bootstrapContext.isGroupManagementDisabled() ||
bootstrapContext.isHostManagementDisabled())
                )
        {
            new InsufficientPrivileges().execute();


Just out of curiosity, I set the
bootstrapContext.setGroupManagementDisabled(false) and everything
worked fine on the surface. I was able to add a server group and
server configuration.

What are the consequences if the
bootstrapContext.isGroupManagementDisabled() is removed from above
condition ?

Regards
-- 
  Claudio Miranda

claudio at claudius.com.br
http://www.claudius.com.br

From claudio at claudius.com.br  Mon Jan 20 08:42:17 2014
From: claudio at claudius.com.br (Claudio Miranda)
Date: Mon, 20 Jan 2014 11:42:17 -0200
Subject: [wildfly-dev] Submitted PR to HAL
Message-ID: <CALbD--rkV6OvJQtoiA10eV4g6bZxh-bJkgmbXWd_pnc14yD+EQ@mail.gmail.com>

Hi, just to let you know, I submitted a PR to HAL

https://github.com/hal/core/pull/10

They are small enhancements accordingly to
https://issues.jboss.org/browse/HAL-265

The contributions are:

* case insensitive filter and filter for text in the middle for:
environment properties and deployed applications
* test datasource connection for domain mode (it is in runtime -> datasource)
* flush connection for domain mode (it is in runtime -> datasource)
* added help text to ctrl+click assign deployment to multiple groups

Regards
-- 
  Claudio Miranda

claudio at claudius.com.br
http://www.claudius.com.br

From hpehl at redhat.com  Mon Jan 20 08:46:40 2014
From: hpehl at redhat.com (Harald Pehl)
Date: Mon, 20 Jan 2014 14:46:40 +0100
Subject: [wildfly-dev] Submitted PR to HAL
In-Reply-To: <CALbD--rkV6OvJQtoiA10eV4g6bZxh-bJkgmbXWd_pnc14yD+EQ@mail.gmail.com>
References: <CALbD--rkV6OvJQtoiA10eV4g6bZxh-bJkgmbXWd_pnc14yD+EQ@mail.gmail.com>
Message-ID: <A2F53929-CE14-4591-A7B4-04CA23D02DA3@redhat.com>

Thanks for the contribution! I will look into it asap.

Regards
Harald
 

Am 20.01.2014 um 14:42 schrieb Claudio Miranda <claudio at claudius.com.br>:

> Hi, just to let you know, I submitted a PR to HAL
> 
> https://github.com/hal/core/pull/10
> 
> They are small enhancements accordingly to
> https://issues.jboss.org/browse/HAL-265
> 
> The contributions are:
> 
> * case insensitive filter and filter for text in the middle for:
> environment properties and deployed applications
> * test datasource connection for domain mode (it is in runtime -> datasource)
> * flush connection for domain mode (it is in runtime -> datasource)
> * added help text to ctrl+click assign deployment to multiple groups
> 
> Regards
> -- 
>  Claudio Miranda
> 
> claudio at claudius.com.br
> http://www.claudius.com.br
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

---
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/20140120/89806732/attachment.bin 

From hbraun at redhat.com  Mon Jan 20 09:43:29 2014
From: hbraun at redhat.com (Heiko Braun)
Date: Mon, 20 Jan 2014 15:43:29 +0100
Subject: [wildfly-dev] Submitted PR to HAL
In-Reply-To: <A2F53929-CE14-4591-A7B4-04CA23D02DA3@redhat.com>
References: <CALbD--rkV6OvJQtoiA10eV4g6bZxh-bJkgmbXWd_pnc14yD+EQ@mail.gmail.com>
	<A2F53929-CE14-4591-A7B4-04CA23D02DA3@redhat.com>
Message-ID: <5E89D6C0-3621-4037-8DA1-56889C9A7D8E@redhat.com>

Right in time for WF 8.0.Final.

Thanks, Claudio.

On 20 Jan 2014, at 14:46, Harald Pehl <hpehl at redhat.com> wrote:

> Thanks for the contribution! I will look into it asap.
> 
> Regards
> Harald
> 
> 
> Am 20.01.2014 um 14:42 schrieb Claudio Miranda <claudio at claudius.com.br>:
> 
>> Hi, just to let you know, I submitted a PR to HAL
>> 
>> https://github.com/hal/core/pull/10
>> 
>> They are small enhancements accordingly to
>> https://issues.jboss.org/browse/HAL-265
>> 
>> The contributions are:
>> 
>> * case insensitive filter and filter for text in the middle for:
>> environment properties and deployed applications
>> * test datasource connection for domain mode (it is in runtime -> datasource)
>> * flush connection for domain mode (it is in runtime -> datasource)
>> * added help text to ctrl+click assign deployment to multiple groups
>> 
>> Regards
>> -- 
>> Claudio Miranda
>> 
>> claudio at claudius.com.br
>> http://www.claudius.com.br
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> ---
> Harald Pehl
> JBoss by Red Hat
> http://hpehl.info
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



From claudio at claudius.com.br  Mon Jan 20 10:02:53 2014
From: claudio at claudius.com.br (Claudio Miranda)
Date: Mon, 20 Jan 2014 13:02:53 -0200
Subject: [wildfly-dev] Submitted PR to HAL
In-Reply-To: <5E89D6C0-3621-4037-8DA1-56889C9A7D8E@redhat.com>
References: <CALbD--rkV6OvJQtoiA10eV4g6bZxh-bJkgmbXWd_pnc14yD+EQ@mail.gmail.com>
	<A2F53929-CE14-4591-A7B4-04CA23D02DA3@redhat.com>
	<5E89D6C0-3621-4037-8DA1-56889C9A7D8E@redhat.com>
Message-ID: <CALbD--rwxSwriw0mtsgFJfz7iHAPqVyVHO=DrF1A0CVbZjNrbw@mail.gmail.com>

On Mon, Jan 20, 2014 at 12:43 PM, Heiko Braun <hbraun at redhat.com> wrote:
> Right in time for WF 8.0.Final.

Wow, that was FAST.

Thank you.
-- 
  Claudio Miranda

claudio at claudius.com.br
http://www.claudius.com.br

From jsightle at redhat.com  Mon Jan 20 10:08:54 2014
From: jsightle at redhat.com (Jess Sightler)
Date: Mon, 20 Jan 2014 10:08:54 -0500 (EST)
Subject: [wildfly-dev] Hibernate Bug (tables starting with "and")...
In-Reply-To: <972119098.3028406.1390230465638.JavaMail.root@redhat.com>
Message-ID: <238591768.3028872.1390230534795.JavaMail.root@redhat.com>

Is there any chance of getting a fix for this into the 8.0.0.Final release?
https://github.com/hibernate/hibernate-orm/pull/658

It seems to break a lot of generated queries on tables starting with "and".

From tomaz.cerar at gmail.com  Mon Jan 20 10:28:40 2014
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Mon, 20 Jan 2014 16:28:40 +0100
Subject: [wildfly-dev] Hibernate Bug (tables starting with "and")...
In-Reply-To: <238591768.3028872.1390230534795.JavaMail.root@redhat.com>
References: <972119098.3028406.1390230465638.JavaMail.root@redhat.com>
	<238591768.3028872.1390230534795.JavaMail.root@redhat.com>
Message-ID: <CAMquZP5+H5pEBn8zrEPvdYfFcuHzO5Xf+heO-12AX_3+sww+kA@mail.gmail.com>

Question would be more suitable for hibernate-dev mailing list.
but in any case i am pretty sure your fix is wrong, given that you can
achieve what you want different way.

see
http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html/ch05.html#mapping-quotedidentifiersfor
more details.
or even
http://stackoverflow.com/questions/9463240/how-to-configure-hibernate-to-put-quotes-around-table-names

--
tomaz


On Mon, Jan 20, 2014 at 4:08 PM, Jess Sightler <jsightle at redhat.com> wrote:

> Is there any chance of getting a fix for this into the 8.0.0.Final release?
> https://github.com/hibernate/hibernate-orm/pull/658
>
> It seems to break a lot of generated queries on tables starting with "and".
> _______________________________________________
> 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/20140120/91a021cc/attachment.html 

From jsightle at redhat.com  Mon Jan 20 10:35:17 2014
From: jsightle at redhat.com (Jess Sightler)
Date: Mon, 20 Jan 2014 10:35:17 -0500 (EST)
Subject: [wildfly-dev] Hibernate Bug (tables starting with "and")...
In-Reply-To: <CAMquZP5+H5pEBn8zrEPvdYfFcuHzO5Xf+heO-12AX_3+sww+kA@mail.gmail.com>
References: <972119098.3028406.1390230465638.JavaMail.root@redhat.com>
	<238591768.3028872.1390230534795.JavaMail.root@redhat.com>
	<CAMquZP5+H5pEBn8zrEPvdYfFcuHzO5Xf+heO-12AX_3+sww+kA@mail.gmail.com>
Message-ID: <1612511220.3043439.1390232117726.JavaMail.root@redhat.com>

I agree, but I am not on hibernate-dev, unfortunately, and this seems like an issue that could affect a lot of people if it goes into the Wildfly final release.

I believe that you have misunderstood the issue here. The issue is not putting quotes around it (although I guess that might work around the bug).

The issue is that if you have a table starting with "and" (eg, "androidvariant"), then this code will think it starts with " and" (note the space). It will then proceed to rip off the first 4 characters, turning your table name into "oidvariant".

Note how the code also does not do what the comment describing it says it will do. Ie, it tries to remove " and" and "and ", but only checks for "and" (no spaces) before doing the trimming.

----- Original Message -----
> From: "Toma? Cerar" <tomaz.cerar at gmail.com>
> To: "Jess Sightler" <jsightle at redhat.com>
> Cc: wildfly-dev at lists.jboss.org
> Sent: Monday, January 20, 2014 10:28:40 AM
> Subject: Re: [wildfly-dev] Hibernate Bug (tables starting with "and")...
> 
> Question would be more suitable for hibernate-dev mailing list.
> but in any case i am pretty sure your fix is wrong, given that you can
> achieve what you want different way.
> 
> see
> http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html/ch05.html#mapping-quotedidentifiersfor
> more details.
> or even
> http://stackoverflow.com/questions/9463240/how-to-configure-hibernate-to-put-quotes-around-table-names
> 
> --
> tomaz
> 
> 
> On Mon, Jan 20, 2014 at 4:08 PM, Jess Sightler <jsightle at redhat.com> wrote:
> 
> > Is there any chance of getting a fix for this into the 8.0.0.Final release?
> > https://github.com/hibernate/hibernate-orm/pull/658
> >
> > It seems to break a lot of generated queries on tables starting with "and".
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> 


From gunnar at hibernate.org  Mon Jan 20 10:41:37 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 20 Jan 2014 16:41:37 +0100
Subject: [wildfly-dev] Hibernate Bug (tables starting with "and")...
In-Reply-To: <1612511220.3043439.1390232117726.JavaMail.root@redhat.com>
References: <972119098.3028406.1390230465638.JavaMail.root@redhat.com>
	<238591768.3028872.1390230534795.JavaMail.root@redhat.com>
	<CAMquZP5+H5pEBn8zrEPvdYfFcuHzO5Xf+heO-12AX_3+sww+kA@mail.gmail.com>
	<1612511220.3043439.1390232117726.JavaMail.root@redhat.com>
Message-ID: <CADGJaX_dhPzi3HUT5uefev6kMW3Qn30v-kyDtadr2HPTkE3THA@mail.gmail.com>

Hi,

I've forwarded your mail to hibernate-dev. Our mailing list is open, you
can register at [1].

--Gunnar

[1] https://lists.jboss.org/mailman/listinfo/hibernate-dev




2014/1/20 Jess Sightler <jsightle at redhat.com>

> I agree, but I am not on hibernate-dev, unfortunately, and this seems like
> an issue that could affect a lot of people if it goes into the Wildfly
> final release.
>
> I believe that you have misunderstood the issue here. The issue is not
> putting quotes around it (although I guess that might work around the bug).
>
> The issue is that if you have a table starting with "and" (eg,
> "androidvariant"), then this code will think it starts with " and" (note
> the space). It will then proceed to rip off the first 4 characters, turning
> your table name into "oidvariant".
>
> Note how the code also does not do what the comment describing it says it
> will do. Ie, it tries to remove " and" and "and ", but only checks for
> "and" (no spaces) before doing the trimming.
>
> ----- Original Message -----
> > From: "Toma? Cerar" <tomaz.cerar at gmail.com>
> > To: "Jess Sightler" <jsightle at redhat.com>
> > Cc: wildfly-dev at lists.jboss.org
> > Sent: Monday, January 20, 2014 10:28:40 AM
> > Subject: Re: [wildfly-dev] Hibernate Bug (tables starting with "and")...
> >
> > Question would be more suitable for hibernate-dev mailing list.
> > but in any case i am pretty sure your fix is wrong, given that you can
> > achieve what you want different way.
> >
> > see
> >
> http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html/ch05.html#mapping-quotedidentifiersfor
> > more details.
> > or even
> >
> http://stackoverflow.com/questions/9463240/how-to-configure-hibernate-to-put-quotes-around-table-names
> >
> > --
> > tomaz
> >
> >
> > On Mon, Jan 20, 2014 at 4:08 PM, Jess Sightler <jsightle at redhat.com>
> wrote:
> >
> > > Is there any chance of getting a fix for this into the 8.0.0.Final
> release?
> > > https://github.com/hibernate/hibernate-orm/pull/658
> > >
> > > It seems to break a lot of generated queries on tables starting with
> "and".
> > > _______________________________________________
> > > 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/20140120/0b2f477b/attachment.html 

From jsightle at redhat.com  Mon Jan 20 10:46:12 2014
From: jsightle at redhat.com (Jess Sightler)
Date: Mon, 20 Jan 2014 10:46:12 -0500 (EST)
Subject: [wildfly-dev] Hibernate Bug (tables starting with "and")...
In-Reply-To: <CADGJaX_dhPzi3HUT5uefev6kMW3Qn30v-kyDtadr2HPTkE3THA@mail.gmail.com>
References: <972119098.3028406.1390230465638.JavaMail.root@redhat.com>
	<238591768.3028872.1390230534795.JavaMail.root@redhat.com>
	<CAMquZP5+H5pEBn8zrEPvdYfFcuHzO5Xf+heO-12AX_3+sww+kA@mail.gmail.com>
	<1612511220.3043439.1390232117726.JavaMail.root@redhat.com>
	<CADGJaX_dhPzi3HUT5uefev6kMW3Qn30v-kyDtadr2HPTkE3THA@mail.gmail.com>
Message-ID: <891028405.3050336.1390232772318.JavaMail.root@redhat.com>

Thanks... I will subscribe there as well.

----- Original Message -----
> From: "Gunnar Morling" <gunnar at hibernate.org>
> To: "Jess Sightler" <jsightle at redhat.com>
> Cc: "Toma? Cerar" <tomaz.cerar at gmail.com>, wildfly-dev at lists.jboss.org
> Sent: Monday, January 20, 2014 10:41:37 AM
> Subject: Re: [wildfly-dev] Hibernate Bug (tables starting with "and")...
> 
> Hi,
> 
> I've forwarded your mail to hibernate-dev. Our mailing list is open, you
> can register at [1].
> 
> --Gunnar
> 
> [1] https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 
> 
> 
> 
> 2014/1/20 Jess Sightler <jsightle at redhat.com>
> 
> > I agree, but I am not on hibernate-dev, unfortunately, and this seems like
> > an issue that could affect a lot of people if it goes into the Wildfly
> > final release.
> >
> > I believe that you have misunderstood the issue here. The issue is not
> > putting quotes around it (although I guess that might work around the bug).
> >
> > The issue is that if you have a table starting with "and" (eg,
> > "androidvariant"), then this code will think it starts with " and" (note
> > the space). It will then proceed to rip off the first 4 characters, turning
> > your table name into "oidvariant".
> >
> > Note how the code also does not do what the comment describing it says it
> > will do. Ie, it tries to remove " and" and "and ", but only checks for
> > "and" (no spaces) before doing the trimming.
> >
> > ----- Original Message -----
> > > From: "Toma? Cerar" <tomaz.cerar at gmail.com>
> > > To: "Jess Sightler" <jsightle at redhat.com>
> > > Cc: wildfly-dev at lists.jboss.org
> > > Sent: Monday, January 20, 2014 10:28:40 AM
> > > Subject: Re: [wildfly-dev] Hibernate Bug (tables starting with "and")...
> > >
> > > Question would be more suitable for hibernate-dev mailing list.
> > > but in any case i am pretty sure your fix is wrong, given that you can
> > > achieve what you want different way.
> > >
> > > see
> > >
> > http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html/ch05.html#mapping-quotedidentifiersfor
> > > more details.
> > > or even
> > >
> > http://stackoverflow.com/questions/9463240/how-to-configure-hibernate-to-put-quotes-around-table-names
> > >
> > > --
> > > tomaz
> > >
> > >
> > > On Mon, Jan 20, 2014 at 4:08 PM, Jess Sightler <jsightle at redhat.com>
> > wrote:
> > >
> > > > Is there any chance of getting a fix for this into the 8.0.0.Final
> > release?
> > > > https://github.com/hibernate/hibernate-orm/pull/658
> > > >
> > > > It seems to break a lot of generated queries on tables starting with
> > "and".
> > > > _______________________________________________
> > > > 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  Mon Jan 20 13:48:22 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 20 Jan 2014 12:48:22 -0600
Subject: [wildfly-dev] Deploying app on managed domain
In-Reply-To: <CAGBoHQXjH7Nar1oAudjM7pw3ca6463L7CcMDM3K1JZvQcyN0xQ@mail.gmail.com>
References: <CAGBoHQVpGyq0waC+4pOsmo-StZfwpKfk0da2bVESK+yzyYY3Jg@mail.gmail.com>	<52D3F894.9000503@redhat.com>
	<CAGBoHQXjH7Nar1oAudjM7pw3ca6463L7CcMDM3K1JZvQcyN0xQ@mail.gmail.com>
Message-ID: <52DD6F76.5060808@redhat.com>

On 1/13/14, 10:03 AM, Arun Gupta wrote:
>>> I started bin/standalone.sh, deployed a WAR file (name is
>>> http-1.0-SNAPSHOT.war) with just one index.jsp. Accessing
>>> localhost:8080/http shows the expected results. Tried the same with
>>> bin/domain.sh but now localhost:8080/http is giving a 404.
>>
>> How exactly did you deploy it?
>
> - localhost:9990/console
> - Manage Deployments
> - Deployed the app and it did not ask for server groups.
>

Use the "Assign" button to the right of the "Add" and "Remove" buttons 
to assign the deployment to server groups.

IMO including this as part of the "Add" wizard makes sense.

https://issues.jboss.org/browse/HAL-340

> Redeployed using jboss-cli as:
>
> deploy ~/workspaces/wildfly-lab/samples/javaee7/target/javaee7-1.0-SNAPSHOT.war
> --server-groups=main-server-group
>
> and that worked.
>
> However deploying using admin console (following the steps listed
> above) does not work for standalone. Or at least the application is
> not accessible at http://localhost:8080/javaee7-1.0-SNAPSHOT. What is
> the context path of the deployed application ?
>

It should be javaee7-1.0-SNAPSHOT unless you set the runtime-name 
attribute to something else in the console wizard or override the 
default in a deployment descriptor.

> Arun
>
>
>
>>
>>> What are the port number of the servers started in this managed domain
>>> ? Is Ports +0 and +150 in admin console trying to display that
>>> information ? If yes, then that is not very intuitive and the exact
>>> value of the port should be displayed. If not, what are these values ?
>>> Should this app be accessible on localhost:8080 ?
>>>
>>> Tried enabling the app from admin console and got the error:
>>> Failed to enable http-1.0-SNAPSHOT.war.
>>>
>>> Unexpected HTTP response: 500
>>>
>>> Request
>>> {
>>>       "address" => [("deployment" => "http-1.0-SNAPSHOT.war")],
>>>       "operation" => "deploy"
>>> }
>>>
>>> Response
>>>
>>> Internal Server Error
>>> {
>>>       "outcome" => "failed",
>>>       "failure-description" => "JBAS014884: No operation named 'deploy'
>>> exists at address [(\"deployment\" => \"http-1.0-SNAPSHOT.war\")]",
>>>       "rolled-back" => true
>>> }
>>>
>>> Is this the correct way to deploy the app on managed domain ?
>>
>> No, it has to be deployed on server groups.
>>
>>
>> Alexey
>>
>>>
>>> Arun
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From brian.stansberry at redhat.com  Mon Jan 20 14:31:32 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 20 Jan 2014 13:31:32 -0600
Subject: [wildfly-dev] HC and server addresses
In-Reply-To: <CALbD--pHS3QJMqBm7VvCLFUa-xAM3np-k-ASAqmAc1dbDPE=pQ@mail.gmail.com>
References: <CALbD--pHS3QJMqBm7VvCLFUa-xAM3np-k-ASAqmAc1dbDPE=pQ@mail.gmail.com>
Message-ID: <52DD7994.7060901@redhat.com>

For a server, you can find out a resolved address for a interface 
resource as follows:

[domain at localhost:9990 /] 
/host=master/server=server-one/interface=public:read-attribute(name=resolved-address)
{
     "outcome" => "success",
     "result" => "127.0.0.1"
}

The value will be "undefined" if the resource is not actually in use 
(i.e. the server didn't have to start the MSC service backing the resource)

[domain at localhost:9990 /] 
/host=master/server=server-one/interface=other:read-attribute(name=resolved-address)
{
     "outcome" => "success",
     "result" => undefined
}

There's no equivalent option for the host controller processes though. 
For example /host=master/interface=management has no resolved-address 
property. I'll need to think about how to deal with that.

The reason there's no attribute is because the meaning of such an 
attribute is unclear when it's applied to a resource that is scoped to 
more than one process. That is /interface=x or host=master/interface=y 
are config resources that can eventually drive the config on multiple 
host processes and server processes, with each process resolving the 
config differently. A "resolved-address" attribute can only tell you the 
value it was resolved to on the process that provides the response.

Perhaps for the higher level resources we could just call the attribute 
"locally-resolved-address" or something and document the meaning in the 
attribute description text.

Probably even better would be to expose bound-address and bound-port 
attributes on the 
host=master/core-service=management/management-interface=* resources 
like we have on the socket-binding resources. That's probably a better 
match for what you are looking for.

More inline.

On 1/17/14, 8:48 PM, Claudio Miranda wrote:
> Hi, I was looking for a way to get the HC and server instance ip
> address, using the management api.
>
> The server is started as
>
> ./domain.sh -b pavlov-0 -bmanagement pavlov-0
> -Djboss.domain.base.dir=../lab1-dc
> -Djboss.domain.master.address=pavlov-0
>
> I found out the following command
>
> /host=master/core-service=host-environment:read-resource(include-runtime=true,recursive=true,include-defaults=true,include-aliases=true)
>
> The output
>
> {
>      "outcome" => "success",
>      "result" => {
>          "backup-domain-files" => false,
>          "default-jvm" => "/opt/javavm/bin/java",
>          "domain-base-dir" =>
> "/home/claudio/alphaworks/projects/wildfly/build/target/wildfly-8.0.0.Final-SNAPSHOT/bin/../lab1-dc",
>          "domain-config-dir" =>
> "/home/claudio/alphaworks/projects/wildfly/build/target/wildfly-8.0.0.Final-SNAPSHOT/bin/../lab1-dc/configuration",
>          "domain-config-file" =>
> "/home/claudio/alphaworks/projects/wildfly/build/target/wildfly-8.0.0.Final-SNAPSHOT/lab1-dc/configuration/domain.xml",
>          "domain-content-dir" =>
> "/home/claudio/alphaworks/projects/wildfly/build/target/wildfly-8.0.0.Final-SNAPSHOT/bin/../lab1-dc/data/content",
>          "domain-data-dir" =>
> "/home/claudio/alphaworks/projects/wildfly/build/target/wildfly-8.0.0.Final-SNAPSHOT/bin/../lab1-dc/data",
>          "domain-log-dir" =>
> "/home/claudio/alphaworks/projects/wildfly/build/target/wildfly-8.0.0.Final-SNAPSHOT/bin/../lab1-dc/log",
>          "domain-servers-dir" =>
> "/home/claudio/alphaworks/projects/wildfly/build/target/wildfly-8.0.0.Final-SNAPSHOT/bin/../lab1-dc/servers",
>          "domain-temp-dir" =>
> "/home/claudio/alphaworks/projects/wildfly/build/target/wildfly-8.0.0.Final-SNAPSHOT/bin/../lab1-dc/tmp",
>          "home-dir" =>
> "/home/claudio/alphaworks/projects/wildfly/build/target/wildfly-8.0.0.Final-SNAPSHOT",
>          "host-config-file" =>
> "/home/claudio/alphaworks/projects/wildfly/build/target/wildfly-8.0.0.Final-SNAPSHOT/lab1-dc/configuration/host.xml",
>          "host-controller-address" => "/127.0.0.1",
>          "host-controller-port" => 0,
>          "host-name" => "pavlov",
>          "initial-running-mode" => "NORMAL",
>          "is-restart" => false,
>          "modules-dir" =>
> "/home/claudio/alphaworks/projects/wildfly/build/target/wildfly-8.0.0.Final-SNAPSHOT/modules",
>          "process-controller-address" => "/127.0.0.1",
>          "process-controller-port" => 51798,
>          "qualified-host-name" => "pavlov",
>          "use-cached-dc" => false
>      }
> }
>
> Looking at the java properties,
>
> jboss.bind.address = pavlov-0
> jboss.domain.master.address = pavlov-0
> jboss.bind.address.management = pavlov-0
>
> Does the "host-controller-address" property should be pavlov-0 and
> "host-controller-port" equal to 9999 ?

No. Those values are unrelated to communication by end users. Those are 
the HC-side values for the internal communication between the HC process 
and the ProcessController process that spawned it.

I noticed that some docs re: this are incorrect:

https://issues.jboss.org/browse/WFLY-2781

> Also the "qualified-host-name" and "host-name" equals to pavlov-0 ?
>

Those values are unrelated to bind address settings. They can be set via 
-Djboss.host.name and -Djboss.qualified.host.name. If 
jboss.qualified.host.name is not set, the HC will look for the 
environment variable "HOSTNAME" (on Windows, "COMPUTERNAME"). If not 
set, it will fall back to InetAddress.getLocalHost().getHostName() and 
if that doesn't work to "unknown-host.unknown-domain". If 
-Djboss.host.name isn't set, the qualified host name value will be used, 
with everything up to and including the first '.' removed.

> Regards
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From david.lloyd at redhat.com  Mon Jan 20 23:19:20 2014
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Mon, 20 Jan 2014 22:19:20 -0600
Subject: [wildfly-dev] New JNDI-based remote service API (for EJB etc.)
Message-ID: <52DDF548.1070405@redhat.com>

We've been having some discussions around improving the way that the EJB 
invocation API looks, feels, and behaves to produce smaller, simpler, 
and perhaps more "expected" code for more common cases.  I'm going to 
outline some of the design points here so that everyone knows what's 
coming and has a chance to ask questions.

Part 1: JNDI API
----------------
Right now connection management is accomplished via a mishmash of APIs 
from different client libraries.  In most cases the connections are 
automatically "managed", but in different ways, and such that each 
client really cannot interact with each other.

 From the user's perspective, this is really not desirable.  Most users 
are, for better or worse, expecting to use an API like JNDI to establish 
and maintain their connection to the remote system.  So the first idea 
here is to encapsulate all common Remoting-based services into a single 
JNDI context.  The user should be able to do something like this:

    Hashtable env = new Hashtable();
    env.put(Context.PROVIDER_URL, "remote+http://myserver.com:8080");
    ...couple other properties here...
    InitialContext c = new InitialContext(env);

Now 'c' is a useful server connection that can be used for various 
services.  These services would include remote transaction control:

    UserTransaction ut = (UserTransaction) c.lookup("UserTransaction");

Remote authentication/authorization:

    SomeLoginContextLike lc = (...) c.lookup("AuthenticationService");
    lc.login(subject, ...);
    subject.doAs(...{
        ...do stuff...
    });

Remote JNDI:

    Context rc = (Context) c.lookup("RemoteNaming");

And of course EJBs:

    MyEJBRemote rem = (MyEJBRemote) 
c.lookup("EJB/MyApp/MyModule/MyEJB!com.mycom.MyEJB");

Please note that none of these JNDI names or APIs are final, just examples.

Once these services use a common infrastructure, a couple of things 
become possible:

1) The services shared among a connection can work together more 
effectively; for example, a UserTransaction can encapsulate all services 
running over that connection, rather than just EJBs.  Likewise for the 
upcoming authentication service.

2) This API can be expanded to cover transport protocols other than 
Remoting-based protocols for use cases in which a single persistent 
connection is not the best option.

Part 2: Connection Management
-----------------------------
By using a URI as the connection destination, we can have one unified 
configuration infrastructure for connection establishment.  We can also 
potentially cache and reuse connections with the same URI.  In this 
case, the user would not need to close the initial context; it could be 
maintained indefinitely or closed after a configurable "idle" interval.

Configuration could be set up in a properties file for simple clients. 
However there will also (often) be cases where the user simply wants to 
establish a connection programmatically in the InitialContext 
environment.  To support this use case, a context will also be able to 
be configured in this way (though there is still a little bit of 
figuring out to do to work out a way that won't result in weird behavior 
if this method is used when there is also an external configuration).

Part 3: Connection Authentication
---------------------------------
In order for connection reuse to work in the presence of multiple 
identities (and make various other things nicer, as an aside), we need 
to create a separate concept of connection authentication, to avoid the 
situation where we ask for a connection as user A and get user B's 
connection instead, or a situation where a user feels they must make one 
connection per identity.  Thus we need a separate client authentication 
context and configuration method to determine the client authentication 
method and credentials to use for the connection itself.

Once a connection is established, the authentication service on that 
connection can be used to switch between authenticated identities.  The 
connection itself need only authenticate to an identity which has 
adequate authorization to switch to, or authenticate as, those 
identities.  On the other hand, for simple cases, the client might only 
need one identity: in this case the authentication service need not be 
used; instead the client authentication context would be set up to 
authenticate the desired user from the outset, and no other identity 
would be established during its usage.

To switch identities, the user would have to acquire some type of 
JAAS-like login context and authenticate a JAAS-like subject with it. 
Then the user would use a typical "doAs"-style construct to perform some 
body of work as that identity.  This will be the subject (!) of a 
different email.

Again, there will be cases where an external configuration for this 
purpose will be too heavy-handed for the specific use case; in this case 
we should allow an environment-based configuration mode.

Part 4: EJB Proxy Behavior
--------------------------
An EJB proxy which was acquired from this sort of connection can attain 
an association to the remote system by URI.  The identifying 
characteristic of the proxy would then be: view type, URI, application 
name, module name, EJB name.  The 'distinct name' concept will no longer 
be necessary and could possibly be deprecated if there is no remaining 
use case for it.

The URI is significant primarily when the proxy is realized in a new 
context.  When the proxy is invoked upon for the first time, it must be 
associated with a connection to the target system.  The information in 
the URI must therefore be sufficient to establish such a connection and 
register it with the connection cache in order to allow such proxies to 
be useful.

This is simple in the case of a URL; if a proxy is deserialized in an 
unknown context, the URL plus any environment security settings may be 
used to establish a new connection to allow the proxy to be invoked upon 
again automatically (without compromising security in any way).

However on the negative side, if a URL is used for the URI, the URL may 
not be valid after deserialization across certain types of NAT 
configuration.  This is a very real problem in some environments.  In 
order to mitigate this problem, a discovery mechanism is introduced.

Part 5: Discovery
-----------------
It will be possible for more advanced environments to utilize a URN 
instead of a URL for connection establishment.  The benefit of doing 
this is that the URN given can be resolved in a location-specific 
manner.  A proxy with a URN of, say, "node:usa-1" might use a discovery 
protocol to locate a node named "usa-1", find a URL that can be used to 
connect, and establish and maintain the connection automatically.  An 
EJB proxy associated with this URN may be serialized and deserialized in 
a completely different network environment, and the URN may still be 
used (but resolved in a different manner) allowing the proxy (and its 
connection) to continue to function.

The discovery mechanism should be pluggable to allow support for cloud 
environments and potentially the Service Location Protocol (SLP, RFC 
2608) for data center environments.  Other schemes may be introduced 
which do simple name-to-DNS-name mappings or other such simple schemes.

Part 6: Compatibility
---------------------
EJB Proxies acquired using the existing AS 7/WildFly 8 EJB API should 
map the EJB locator information to a locator which is compatible with 
the URI scheme given here, and vice versa, so that there is a seamless 
migration path between old and new location schemes.

The wire protocol should also be made compatible so that old clients 
will continue to function against new servers (and the reverse as well, 
if possible).

-- 
- DML

From jason.greene at redhat.com  Tue Jan 21 14:00:22 2014
From: jason.greene at redhat.com (Jason Greene)
Date: Tue, 21 Jan 2014 13:00:22 -0600
Subject: [wildfly-dev] "It's The Final Countdown!"
Message-ID: <C380E806-0FAD-4A87-A2C0-90F357BFF9F7@redhat.com>

No this isn?t the Europe song (Sorry to disappoint!).

It is however the countdown to WildFly 8 Final release!

The key things that remain are:

1) Final Components - We need PRs upgrading to ?Final? for all outstanding 
subcomponents[1]. If you own one of them, then please make this a high priority. 
The sooner the better.

2) Identify Blockers - We need to identify all remaining blockers that have been
reported against CR1. I?m hoping everyone can look through the forms for likely
blockers and convert them to JIRAs. As a reminder a blocker is anything that is 
mass user effecting and severe in nature. Examples include: hangs, crashes, 
memory leaks, vulnerabilities, and data corruption.

3) JASPIC Acceptance - A few of you on this list have noted issues. We need to 
ensure that the Final release has addressed the outstanding issues.

Thanks!

[1] Outstanding components.

io.undertow 1.0.0.Beta30
io.undertow.jastow 1.0.0.CR1
org.glassfish.javax.el 3.0-b07
org.hibernate.search 4.5.0.Alpha2 *exception*
org.infinispan.protostream 1.0.0.CR1
org.jberet 1.0.0.CR1
org.jboss.ejb-client 2.0.0.Beta5
org.jboss.narayana 5.0.0.CR2
org.jboss.jsfunit 2.0.0.Beta1
org.jboss.logging.jboss-logging-tools 1.2.0.Beta1
org.jboss.metadata 8.0.0.CR1
org.jboss.mod_cluster 1.3.0.Alpha1
org.jboss.msc.jboss-msc 1.2.0.CR1
org.jboss.xnio.netty.netty-xnio-transport 0.1.1.CR2
org.jboss.remote-naming 2.0.0.Beta2
org.jboss.remoting 4.0.0.Beta3
org.jboss.remotingjmx.remoting-jmx 2.0.0.CR4
org.jboss.sasl 1.0.4.CR1
org.jboss.spec.javax.el.jboss-el-api_3.0_spec 1.0.0.Beta1
org.jboss.spec.javax.security.auth.message.jboss-jaspi-api_1.1_spec 1.0.0.Alpha1
org.jboss.spec.javax.security.jacc.jboss-jacc-api_1.5_spec 1.0.0.Beta1
org.jboss.spec.javax.servlet.jsp.jboss-jsp-api_2.3_spec 1.0.0.Beta1
org.jboss.spec.javax.servlet.jstl.jboss-jstl-api_1.2_spec 1.0.4.Beta1
org.jboss.xnio 3.2.0.Beta4
org.picketbox 4.0.20.Beta4
org.wildfly.security.manager 1.0.0.Beta3



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



From jason.greene at redhat.com  Tue Jan 21 14:57:22 2014
From: jason.greene at redhat.com (Jason Greene)
Date: Tue, 21 Jan 2014 13:57:22 -0600
Subject: [wildfly-dev] "It's The Final Countdown!"
In-Reply-To: <52DECD7C.4000605@gmail.com>
References: <C380E806-0FAD-4A87-A2C0-90F357BFF9F7@redhat.com>
	<52DECD7C.4000605@gmail.com>
Message-ID: <5A39BADD-343F-4AA6-BDD1-249C20998B32@redhat.com>

Hmm I guess we shouldn?t use that keyboard riff when you walk up to give your next JUDCon talk :)

4.3.1 sounds like a good thing to get in. Let?s plan on that.

On Jan 21, 2014, at 1:41 PM, Steve Ebersole <steven.ebersole at gmail.com> wrote:

> Damn it, you ruined my day putting that song in my head! ;)
> 
> We should talk about using Hibernate ORM 4.3.1 here.  One bug at least was hitting some WildFly users: https://hibernate.atlassian.net/browse/HHH-8884
> 
> I am cutting 4.3.1 tomorrow...
> 
> 
> On Tue 21 Jan 2014 01:00:22 PM CST, Jason Greene wrote:
>> 
>> No this isn?t the Europe song (Sorry to disappoint!).
>> 
>> It is however the countdown to WildFly 8 Final release!
>> 
>> The key things that remain are:
>> 
>> 1) Final Components - We need PRs upgrading to ?Final? for all outstanding
>> subcomponents[1]. If you own one of them, then please make this a high priority.
>> The sooner the better.
>> 
>> 2) Identify Blockers - We need to identify all remaining blockers that have been
>> reported against CR1. I?m hoping everyone can look through the forms for likely
>> blockers and convert them to JIRAs. As a reminder a blocker is anything that is
>> mass user effecting and severe in nature. Examples include: hangs, crashes,
>> memory leaks, vulnerabilities, and data corruption.
>> 
>> 3) JASPIC Acceptance - A few of you on this list have noted issues. We need to
>> ensure that the Final release has addressed the outstanding issues.
>> 
>> Thanks!
>> 
>> [1] Outstanding components.
>> 
>> io.undertow 1.0.0.Beta30
>> io.undertow.jastow 1.0.0.CR1
>> org.glassfish.javax.el 3.0-b07
>> org.hibernate.search 4.5.0.Alpha2 *exception*
>> org.infinispan.protostream 1.0.0.CR1
>> org.jberet 1.0.0.CR1
>> org.jboss.ejb-client 2.0.0.Beta5
>> org.jboss.narayana 5.0.0.CR2
>> org.jboss.jsfunit 2.0.0.Beta1
>> org.jboss.logging.jboss-logging-tools 1.2.0.Beta1
>> org.jboss.metadata 8.0.0.CR1
>> org.jboss.mod_cluster 1.3.0.Alpha1
>> org.jboss.msc.jboss-msc 1.2.0.CR1
>> org.jboss.xnio.netty.netty-xnio-transport 0.1.1.CR2
>> org.jboss.remote-naming 2.0.0.Beta2
>> org.jboss.remoting 4.0.0.Beta3
>> org.jboss.remotingjmx.remoting-jmx 2.0.0.CR4
>> org.jboss.sasl 1.0.4.CR1
>> org.jboss.spec.javax.el.jboss-el-api_3.0_spec 1.0.0.Beta1
>> org.jboss.spec.javax.security.auth.message.jboss-jaspi-api_1.1_spec 1.0.0.Alpha1
>> org.jboss.spec.javax.security.jacc.jboss-jacc-api_1.5_spec 1.0.0.Beta1
>> org.jboss.spec.javax.servlet.jsp.jboss-jsp-api_2.3_spec 1.0.0.Beta1
>> org.jboss.spec.javax.servlet.jstl.jboss-jstl-api_1.2_spec 1.0.4.Beta1
>> org.jboss.xnio 3.2.0.Beta4
>> org.picketbox 4.0.20.Beta4
>> org.wildfly.security.manager 1.0.0.Beta3
>> 
>> 
>> 
>> --
>> 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 claudio at claudius.com.br  Tue Jan 21 20:03:17 2014
From: claudio at claudius.com.br (Claudio Miranda)
Date: Tue, 21 Jan 2014 23:03:17 -0200
Subject: [wildfly-dev] set instance-id as default in web subsystem
Message-ID: <CALbD--o0JUY8Xw1kSfVEg09V_iU7THjHMjAH0UP2Dyj7Hp27rg@mail.gmail.com>

Hi, for every server that wants to work in a cluster with mod_cluster,
they need to set instance-id="${jboss.node.name}" in the web subsystem
[1].

Also for every jboss server I configure, I set this property.

I suggest to let this as default in domain.xml and standalone.xml,
what do you think ?

https://access.redhat.com/site/documentation/en-US/JBoss_Enterprise_Application_Platform/6.2/html/Administration_and_Configuration_Guide/Configure_the_Enterprise_Application_Platform_to_Accept_Requests_From_an_External_HTTPD1.html

-- 
  Claudio Miranda

claudio at claudius.com.br
http://www.claudius.com.br

From claudio at claudius.com.br  Tue Jan 21 22:09:53 2014
From: claudio at claudius.com.br (Claudio Miranda)
Date: Wed, 22 Jan 2014 01:09:53 -0200
Subject: [wildfly-dev] WFLY-818 Slave host does not register to DC
Message-ID: <CALbD--q_SRzg=zW8X+GQwv2ioQgBDjtB6H=aqxKFnQHoUygYuQ@mail.gmail.com>

Hi, do you have any solution for this ?

What do you think about this ?

1. HC starts with NO --cached-dc, it try to registers to DC, if it
doesn't register, HC fails to starts, as it is today.

2. HC starts with --cached-dc, it try to registers to DC,
a) if HC doesn't register to DC, HC uses the cached copy of
domain.xml. Try to registers to DC at interval times, if register is
successful see 3.a
b) if HC registers to DC, it works as is today copy domain.xml from DC
and replaces local backup.

3. HC starts with NO --cached-dc, HC register to DC, everything works
as is today. If HC disconnects from DC (unknown reason), HC keeps
trying to registers at interval times.
a) HC re-connects to DC, and detects domain.xml changed between DC and
HC. HC emits a warning and asks to restart the HC and their servers.


regards

-- 
  Claudio Miranda

claudio at claudius.com.br
http://www.claudius.com.br

From hpehl at redhat.com  Wed Jan 22 03:04:39 2014
From: hpehl at redhat.com (Harald Pehl)
Date: Wed, 22 Jan 2014 09:04:39 +0100
Subject: [wildfly-dev] Denied to access admin web console of EAP6 after
	removing server-groups
In-Reply-To: <CALbD--qTzT3bmUzVZu4VBLCoZZnYviyvD5gG62Pk-e8tXnpg2A@mail.gmail.com>
References: <CALbD--qTzT3bmUzVZu4VBLCoZZnYviyvD5gG62Pk-e8tXnpg2A@mail.gmail.com>
Message-ID: <E07791D9-DF32-41DB-9CBA-B57D28A73F3B@redhat.com>

I added a fix for HAL-336 which detects when there are no server groups defined. In that case the default place is changed to "Profiles". 

Regards
Harald


Am 18.01.2014 um 18:31 schrieb Claudio Miranda <claudio at claudius.com.br>:

> Hi, related to HAL-336
> 
> The class org.jboss.as.console.client.core.bootstrap.LoadMainApp,
> method execute() has the following
> 
> 
>        if(!bootstrapContext.isStandalone()
>                && (bootstrapContext.isGroupManagementDisabled() ||
> bootstrapContext.isHostManagementDisabled())
>                )
>        {
>            new InsufficientPrivileges().execute();
> 
> 
> Just out of curiosity, I set the
> bootstrapContext.setGroupManagementDisabled(false) and everything
> worked fine on the surface. I was able to add a server group and
> server configuration.
> 
> What are the consequences if the
> bootstrapContext.isGroupManagementDisabled() is removed from above
> condition ?
> 
> Regards
> -- 
>  Claudio Miranda
> 
> claudio at claudius.com.br
> http://www.claudius.com.br
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

---
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/20140122/d9fedc25/attachment.bin 

From hardy at hibernate.org  Wed Jan 22 05:05:31 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 22 Jan 2014 11:05:31 +0100
Subject: [wildfly-dev] "It's The Final Countdown!"
In-Reply-To: <C380E806-0FAD-4A87-A2C0-90F357BFF9F7@redhat.com>
References: <C380E806-0FAD-4A87-A2C0-90F357BFF9F7@redhat.com>
Message-ID: <AC897958-F5E1-4FAB-9DA9-CA90C7DDBB6C@hibernate.org>


On 21 Jan 2014, at 20:00, Jason Greene <jason.greene at redhat.com> wrote:

> No this isn?t the Europe song (Sorry to disappoint!).
> 
> It is however the countdown to WildFly 8 Final release!


What is the time frame? When is the release date? And until when have pull requests for component 
upgrades to be submitted?

I would like to upgrade Hibernate Validator, but 5.1.0 is not ready yet. Depending on the time frame
I might be able to get it ready, otherwise I would consider creating a 5.0.3 to backport a potential 
memory leak.

?Hardy




From tomaz.cerar at gmail.com  Wed Jan 22 05:14:45 2014
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Wed, 22 Jan 2014 11:14:45 +0100
Subject: [wildfly-dev] "It's The Final Countdown!"
In-Reply-To: <AC897958-F5E1-4FAB-9DA9-CA90C7DDBB6C@hibernate.org>
References: <C380E806-0FAD-4A87-A2C0-90F357BFF9F7@redhat.com>
	<AC897958-F5E1-4FAB-9DA9-CA90C7DDBB6C@hibernate.org>
Message-ID: <CAMquZP5m_BegSA4hPCwuNTHP-qJrGezs8ur0j2A==hJB7XKUWA@mail.gmail.com>

On Wed, Jan 22, 2014 at 11:05 AM, Hardy Ferentschik <hardy at hibernate.org>wrote:

> When is the release date?



Plan is to do release by end of month.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140122/fb748038/attachment.html 

From rory.odonnell at oracle.com  Wed Jan 22 06:16:47 2014
From: rory.odonnell at oracle.com (Rory O'Donnell Oracle, Dublin Ireland)
Date: Wed, 22 Jan 2014 11:16:47 +0000
Subject: [wildfly-dev] JDK 8 Build 124 & JDK 7 Update 60 build 03 are
	available on java.net
Message-ID: <52DFA89F.7010805@oracle.com>

Hi Guys,

JDK 8 Build b124 Early Access Build is now available for download 
<http://jdk8.java.net/download.html> & test.
JDK 7u60 b03 Early Access Build is also available for download 
<https://jdk7.java.net/download.html>& test.

Please log all show stopper issues as soon as possible.

If any of you are going to FOSDEM next week,please let me know we should 
meet up.

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/20140122/3b35f830/attachment.html 

From tomaz.cerar at gmail.com  Wed Jan 22 06:48:34 2014
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Wed, 22 Jan 2014 12:48:34 +0100
Subject: [wildfly-dev] set instance-id as default in web subsystem
In-Reply-To: <CALbD--o0JUY8Xw1kSfVEg09V_iU7THjHMjAH0UP2Dyj7Hp27rg@mail.gmail.com>
References: <CALbD--o0JUY8Xw1kSfVEg09V_iU7THjHMjAH0UP2Dyj7Hp27rg@mail.gmail.com>
Message-ID: <CAMquZP5hLGV-gWY1m-EC55xXH78dtN8R1WfPOopvb1XfPp3K0w@mail.gmail.com>

Hey,

this is not proper mailing list for this kind of questions anymore given
that wildfly does not contain web subsystem anymore.

in any case, my memory around this is fading so take this with grain of
salt :-)

if instance-id is not set if defaults to jboss.node.name in case you are
proxying directly to web, but in case of mod-cluster integration mod
cluster generates its own id that does not folow same convetion unless
instance-id is defined.
I don't see any big reason why not change default, but it should in any
case get bugzilla entry so it could be considered for fix in EAP.

I will make sure undertow's instance-id will have proper defaults but for
EAP go trough "official" channels.

--
tomaz


On Wed, Jan 22, 2014 at 2:03 AM, Claudio Miranda <claudio at claudius.com.br>wrote:

> Hi, for every server that wants to work in a cluster with mod_cluster,
> they need to set instance-id="${jboss.node.name}" in the web subsystem
> [1].
>
> Also for every jboss server I configure, I set this property.
>
> I suggest to let this as default in domain.xml and standalone.xml,
> what do you think ?
>
>
> https://access.redhat.com/site/documentation/en-US/JBoss_Enterprise_Application_Platform/6.2/html/Administration_and_Configuration_Guide/Configure_the_Enterprise_Application_Platform_to_Accept_Requests_From_an_External_HTTPD1.html
>
> --
>   Claudio Miranda
>
> claudio at claudius.com.br
> http://www.claudius.com.br
> _______________________________________________
> 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/20140122/f6735012/attachment.html 

From emuckenh at redhat.com  Wed Jan 22 06:58:39 2014
From: emuckenh at redhat.com (Emanuel Muckenhuber)
Date: Wed, 22 Jan 2014 12:58:39 +0100
Subject: [wildfly-dev] WFLY-818 Slave host does not register to DC
In-Reply-To: <CALbD--q_SRzg=zW8X+GQwv2ioQgBDjtB6H=aqxKFnQHoUygYuQ@mail.gmail.com>
References: <CALbD--q_SRzg=zW8X+GQwv2ioQgBDjtB6H=aqxKFnQHoUygYuQ@mail.gmail.com>
Message-ID: <52DFB26F.2080609@redhat.com>


Hi,

we don't have a solution yet. There are other open issues related to 
this, i.e. when using --cached-dc and --backup-dc at the same time. We 
do plan on allowing this case in future, which should behave similar to 
what you described. However it will probably only happen in the WidlFly 
9 time frame.

Emanuel

On 01/22/2014 04:09 AM, Claudio Miranda wrote:
> Hi, do you have any solution for this ?
>
> What do you think about this ?
>
> 1. HC starts with NO --cached-dc, it try to registers to DC, if it
> doesn't register, HC fails to starts, as it is today.
>
> 2. HC starts with --cached-dc, it try to registers to DC,
> a) if HC doesn't register to DC, HC uses the cached copy of
> domain.xml. Try to registers to DC at interval times, if register is
> successful see 3.a
> b) if HC registers to DC, it works as is today copy domain.xml from DC
> and replaces local backup.
>
> 3. HC starts with NO --cached-dc, HC register to DC, everything works
> as is today. If HC disconnects from DC (unknown reason), HC keeps
> trying to registers at interval times.
> a) HC re-connects to DC, and detects domain.xml changed between DC and
> HC. HC emits a warning and asks to restart the HC and their servers.
>
>
> regards
>

From brian.stansberry at redhat.com  Wed Jan 22 07:47:23 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 22 Jan 2014 06:47:23 -0600
Subject: [wildfly-dev] WFLY-818 Slave host does not register to DC
In-Reply-To: <52DFB26F.2080609@redhat.com>
References: <CALbD--q_SRzg=zW8X+GQwv2ioQgBDjtB6H=aqxKFnQHoUygYuQ@mail.gmail.com>
	<52DFB26F.2080609@redhat.com>
Message-ID: <52DFBDDB.4000102@redhat.com>

Agreed. The 3a) part needs some discussion; i.e. whether in this case 
the slave just "asks" to restart or whether it just takes the update and 
restarts servers. Currently if a slave loses contact with the master and 
then reestablishes contact, it automatically restarts servers if the 
domain config has changed. Basically we prioritize maintaining 
consistency among members of a server group over giving humans control. 
Plus, TBH, it's simpler.

If a server wasn't brought in sync automatically, I think it would have 
to be put into a state where it could no longer receive or execute any 
write ops. Reads are ok. Basically it's config is out of sync and it 
needs to be restarted.

I'm not sure if there's any reason not to immediately apply the new 
domain config to the HC itself, which is what we do now. Don't think 
there is. If we didn't, the slave couldn't fully register with the 
master, as all registered slaves need to be consistent with the master.

On 1/22/14, 5:58 AM, Emanuel Muckenhuber wrote:
>
> Hi,
>
> we don't have a solution yet. There are other open issues related to
> this, i.e. when using --cached-dc and --backup-dc at the same time. We
> do plan on allowing this case in future, which should behave similar to
> what you described. However it will probably only happen in the WidlFly
> 9 time frame.
>
> Emanuel
>
> On 01/22/2014 04:09 AM, Claudio Miranda wrote:
>> Hi, do you have any solution for this ?
>>
>> What do you think about this ?
>>
>> 1. HC starts with NO --cached-dc, it try to registers to DC, if it
>> doesn't register, HC fails to starts, as it is today.
>>
>> 2. HC starts with --cached-dc, it try to registers to DC,
>> a) if HC doesn't register to DC, HC uses the cached copy of
>> domain.xml. Try to registers to DC at interval times, if register is
>> successful see 3.a
>> b) if HC registers to DC, it works as is today copy domain.xml from DC
>> and replaces local backup.
>>
>> 3. HC starts with NO --cached-dc, HC register to DC, everything works
>> as is today. If HC disconnects from DC (unknown reason), HC keeps
>> trying to registers at interval times.
>> a) HC re-connects to DC, and detects domain.xml changed between DC and
>> HC. HC emits a warning and asks to restart the HC and their servers.
>>
>>
>> regards
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From claudio at claudius.com.br  Wed Jan 22 09:42:54 2014
From: claudio at claudius.com.br (Claudio Miranda)
Date: Wed, 22 Jan 2014 12:42:54 -0200
Subject: [wildfly-dev] set instance-id as default in web subsystem
In-Reply-To: <CAMquZP5hLGV-gWY1m-EC55xXH78dtN8R1WfPOopvb1XfPp3K0w@mail.gmail.com>
References: <CALbD--o0JUY8Xw1kSfVEg09V_iU7THjHMjAH0UP2Dyj7Hp27rg@mail.gmail.com>
	<CAMquZP5hLGV-gWY1m-EC55xXH78dtN8R1WfPOopvb1XfPp3K0w@mail.gmail.com>
Message-ID: <CALbD--qYWCwKhv1CVKfwMhXzrr2gMamaYEiBBWV21PrpMAFJaw@mail.gmail.com>

On Wed, Jan 22, 2014 at 9:48 AM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
>
> this is not proper mailing list for this kind of questions anymore given
> that wildfly does not contain web subsystem anymore.

Oh, sure. It is undertow. Just forget that :(

I will try other way to ask about this instance-id in EAP channel.

Thanks
-- 
  Claudio Miranda

claudio at claudius.com.br
http://www.claudius.com.br


From claudio at claudius.com.br  Wed Jan 22 09:49:59 2014
From: claudio at claudius.com.br (Claudio Miranda)
Date: Wed, 22 Jan 2014 12:49:59 -0200
Subject: [wildfly-dev] WFLY-818 Slave host does not register to DC
In-Reply-To: <52DFB26F.2080609@redhat.com>
References: <CALbD--q_SRzg=zW8X+GQwv2ioQgBDjtB6H=aqxKFnQHoUygYuQ@mail.gmail.com>
	<52DFB26F.2080609@redhat.com>
Message-ID: <CALbD--pnYa5h_UJ-LGLS=kKv-YBB1fy3ETP6SxoxzQ5-+x96jQ@mail.gmail.com>

Hi

On Wed, Jan 22, 2014 at 9:58 AM, Emanuel Muckenhuber
<emuckenh at redhat.com> wrote:
> There are other open issues related to
> this, i.e. when using --cached-dc and --backup-dc at the same time.

What do you think to let this as default ?
Thinking from a HA view, the sysadmin, always wants their HC to work,
so, if HC caches a local copy by default, it makes sense to load it if
HC cannot registers itself with DC.

I have worked with some customers, they just want to start jboss,
regardless if HC are able to connect to DC. Of course, there should
exist some mechanism to warn sysadmin the registration was not
possible and they must look into it.

Regards
-- 
  Claudio Miranda

claudio at claudius.com.br
http://www.claudius.com.br

From steve at hibernate.org  Wed Jan 22 13:54:34 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 22 Jan 2014 12:54:34 -0600
Subject: [wildfly-dev] "It's The Final Countdown!"
In-Reply-To: <5A39BADD-343F-4AA6-BDD1-249C20998B32@redhat.com>
References: <C380E806-0FAD-4A87-A2C0-90F357BFF9F7@redhat.com>
	<52DECD7C.4000605@gmail.com>
	<5A39BADD-343F-4AA6-BDD1-249C20998B32@redhat.com>
Message-ID: <52E013EA.5070904@hibernate.org>

Eye of the Tiger might be better :D

http://in.relation.to/Bloggers/HibernateORM431FinalRelease

On 01/21/2014 01:57 PM, Jason Greene wrote:
> Hmm I guess we shouldn?t use that keyboard riff when you walk up to give your next JUDCon talk :)
>
> 4.3.1 sounds like a good thing to get in. Let?s plan on that.
>
> On Jan 21, 2014, at 1:41 PM, Steve Ebersole <steven.ebersole at gmail.com> wrote:
>
>> Damn it, you ruined my day putting that song in my head! ;)
>>
>> We should talk about using Hibernate ORM 4.3.1 here.  One bug at least was hitting some WildFly users: https://hibernate.atlassian.net/browse/HHH-8884
>>
>> I am cutting 4.3.1 tomorrow...
>>
>>
>> On Tue 21 Jan 2014 01:00:22 PM CST, Jason Greene wrote:
>>> No this isn?t the Europe song (Sorry to disappoint!).
>>>
>>> It is however the countdown to WildFly 8 Final release!
>>>
>>> The key things that remain are:
>>>
>>> 1) Final Components - We need PRs upgrading to ?Final? for all outstanding
>>> subcomponents[1]. If you own one of them, then please make this a high priority.
>>> The sooner the better.
>>>
>>> 2) Identify Blockers - We need to identify all remaining blockers that have been
>>> reported against CR1. I?m hoping everyone can look through the forms for likely
>>> blockers and convert them to JIRAs. As a reminder a blocker is anything that is
>>> mass user effecting and severe in nature. Examples include: hangs, crashes,
>>> memory leaks, vulnerabilities, and data corruption.
>>>
>>> 3) JASPIC Acceptance - A few of you on this list have noted issues. We need to
>>> ensure that the Final release has addressed the outstanding issues.
>>>
>>> Thanks!
>>>
>>> [1] Outstanding components.
>>>
>>> io.undertow 1.0.0.Beta30
>>> io.undertow.jastow 1.0.0.CR1
>>> org.glassfish.javax.el 3.0-b07
>>> org.hibernate.search 4.5.0.Alpha2 *exception*
>>> org.infinispan.protostream 1.0.0.CR1
>>> org.jberet 1.0.0.CR1
>>> org.jboss.ejb-client 2.0.0.Beta5
>>> org.jboss.narayana 5.0.0.CR2
>>> org.jboss.jsfunit 2.0.0.Beta1
>>> org.jboss.logging.jboss-logging-tools 1.2.0.Beta1
>>> org.jboss.metadata 8.0.0.CR1
>>> org.jboss.mod_cluster 1.3.0.Alpha1
>>> org.jboss.msc.jboss-msc 1.2.0.CR1
>>> org.jboss.xnio.netty.netty-xnio-transport 0.1.1.CR2
>>> org.jboss.remote-naming 2.0.0.Beta2
>>> org.jboss.remoting 4.0.0.Beta3
>>> org.jboss.remotingjmx.remoting-jmx 2.0.0.CR4
>>> org.jboss.sasl 1.0.4.CR1
>>> org.jboss.spec.javax.el.jboss-el-api_3.0_spec 1.0.0.Beta1
>>> org.jboss.spec.javax.security.auth.message.jboss-jaspi-api_1.1_spec 1.0.0.Alpha1
>>> org.jboss.spec.javax.security.jacc.jboss-jacc-api_1.5_spec 1.0.0.Beta1
>>> org.jboss.spec.javax.servlet.jsp.jboss-jsp-api_2.3_spec 1.0.0.Beta1
>>> org.jboss.spec.javax.servlet.jstl.jboss-jstl-api_1.2_spec 1.0.4.Beta1
>>> org.jboss.xnio 3.2.0.Beta4
>>> org.picketbox 4.0.20.Beta4
>>> org.wildfly.security.manager 1.0.0.Beta3
>>>
>>>
>>>
>>> --
>>> 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 tsegismo at redhat.com  Thu Jan 23 06:32:43 2014
From: tsegismo at redhat.com (Thomas Segismont)
Date: Thu, 23 Jan 2014 12:32:43 +0100
Subject: [wildfly-dev] How to map a client certificate to a management user?
Message-ID: <52E0FDDB.40701@redhat.com>

Hi,

I have setup client certificate authentication on AS7.1.1 with this 
Management realm definition:

<security-realm name="ManagementRealm">
     <server-identities>
         <ssl>
             <keystore path="server.jks" 
relative-to="jboss.server.config.dir" password="abcdef"/>
         </ssl>
     </server-identities>
     <authentication>
         <truststore path="server.jks" 
relative-to="jboss.server.config.dir" password="abcdef" />
         <properties path="mgmt-users.properties" relative
to="jboss.server.config.dir"/>
     </authentication>
</security-realm>

When I try to browse the admin console in Firefox, it asks me to confirm 
I want to authenticate with the client cert (good) and then I can only 
see the error page:

===
Your JBoss Application Server 7 is running.

However you have not yet added any users to be able to access the admin 
console.
===

How can I map a client certificate to a management user?

Thanks for your help,
Thomas

From darran.lofthouse at jboss.com  Thu Jan 23 07:14:44 2014
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Thu, 23 Jan 2014 12:14:44 +0000
Subject: [wildfly-dev] How to map a client certificate to a management
 user?
In-Reply-To: <52E0FDDB.40701@redhat.com>
References: <52E0FDDB.40701@redhat.com>
Message-ID: <52E107B4.5070907@jboss.com>

I believe you are running into an old bug, in later releases that page 
should no longer be displayed if a trust store is defined against the realm.

Regards,
Darran Lofthouse.


On 23/01/14 11:32, Thomas Segismont wrote:
> Hi,
>
> I have setup client certificate authentication on AS7.1.1 with this
> Management realm definition:
>
> <security-realm name="ManagementRealm">
>       <server-identities>
>           <ssl>
>               <keystore path="server.jks"
> relative-to="jboss.server.config.dir" password="abcdef"/>
>           </ssl>
>       </server-identities>
>       <authentication>
>           <truststore path="server.jks"
> relative-to="jboss.server.config.dir" password="abcdef" />
>           <properties path="mgmt-users.properties" relative
> to="jboss.server.config.dir"/>
>       </authentication>
> </security-realm>
>
> When I try to browse the admin console in Firefox, it asks me to confirm
> I want to authenticate with the client cert (good) and then I can only
> see the error page:
>
> ===
> Your JBoss Application Server 7 is running.
>
> However you have not yet added any users to be able to access the admin
> console.
> ===
>
> How can I map a client certificate to a management user?
>
> Thanks for your help,
> Thomas
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From darran.lofthouse at jboss.com  Thu Jan 23 07:15:48 2014
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Thu, 23 Jan 2014 12:15:48 +0000
Subject: [wildfly-dev] How to map a client certificate to a management
 user?
In-Reply-To: <52E107B4.5070907@jboss.com>
References: <52E0FDDB.40701@redhat.com> <52E107B4.5070907@jboss.com>
Message-ID: <52E107F4.9050702@jboss.com>

Should add the workaround would be to just add a dummy user definition 
to the properties file so that one user is defined - the password hash 
does not need to be a valid hash.

On 23/01/14 12:14, Darran Lofthouse wrote:
> I believe you are running into an old bug, in later releases that page
> should no longer be displayed if a trust store is defined against the realm.
>
> Regards,
> Darran Lofthouse.
>
>
> On 23/01/14 11:32, Thomas Segismont wrote:
>> Hi,
>>
>> I have setup client certificate authentication on AS7.1.1 with this
>> Management realm definition:
>>
>> <security-realm name="ManagementRealm">
>>        <server-identities>
>>            <ssl>
>>                <keystore path="server.jks"
>> relative-to="jboss.server.config.dir" password="abcdef"/>
>>            </ssl>
>>        </server-identities>
>>        <authentication>
>>            <truststore path="server.jks"
>> relative-to="jboss.server.config.dir" password="abcdef" />
>>            <properties path="mgmt-users.properties" relative
>> to="jboss.server.config.dir"/>
>>        </authentication>
>> </security-realm>
>>
>> When I try to browse the admin console in Firefox, it asks me to confirm
>> I want to authenticate with the client cert (good) and then I can only
>> see the error page:
>>
>> ===
>> Your JBoss Application Server 7 is running.
>>
>> However you have not yet added any users to be able to access the admin
>> console.
>> ===
>>
>> How can I map a client certificate to a management user?
>>
>> Thanks for your help,
>> Thomas
>> _______________________________________________
>> 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 tsegismo at redhat.com  Thu Jan 23 07:23:42 2014
From: tsegismo at redhat.com (Thomas Segismont)
Date: Thu, 23 Jan 2014 13:23:42 +0100
Subject: [wildfly-dev] How to map a client certificate to a management
 user?
In-Reply-To: <52E107B4.5070907@jboss.com>
References: <52E0FDDB.40701@redhat.com> <52E107B4.5070907@jboss.com>
Message-ID: <52E109CE.5000009@redhat.com>

I just tried with EAP6.1.1, it works.

Thanks!

Le 23/01/2014 13:14, Darran Lofthouse a ?crit :
> I believe you are running into an old bug, in later releases that page
> should no longer be displayed if a trust store is defined against the realm.
>
> Regards,
> Darran Lofthouse.
>
>
> On 23/01/14 11:32, Thomas Segismont wrote:
>> Hi,
>>
>> I have setup client certificate authentication on AS7.1.1 with this
>> Management realm definition:
>>
>> <security-realm name="ManagementRealm">
>>        <server-identities>
>>            <ssl>
>>                <keystore path="server.jks"
>> relative-to="jboss.server.config.dir" password="abcdef"/>
>>            </ssl>
>>        </server-identities>
>>        <authentication>
>>            <truststore path="server.jks"
>> relative-to="jboss.server.config.dir" password="abcdef" />
>>            <properties path="mgmt-users.properties" relative
>> to="jboss.server.config.dir"/>
>>        </authentication>
>> </security-realm>
>>
>> When I try to browse the admin console in Firefox, it asks me to confirm
>> I want to authenticate with the client cert (good) and then I can only
>> see the error page:
>>
>> ===
>> Your JBoss Application Server 7 is running.
>>
>> However you have not yet added any users to be able to access the admin
>> console.
>> ===
>>
>> How can I map a client certificate to a management user?
>>
>> Thanks for your help,
>> Thomas
>> _______________________________________________
>> 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 tsegismo at redhat.com  Thu Jan 23 07:30:24 2014
From: tsegismo at redhat.com (Thomas Segismont)
Date: Thu, 23 Jan 2014 13:30:24 +0100
Subject: [wildfly-dev] How to map a client certificate to a management
 user?
In-Reply-To: <52E107F4.9050702@jboss.com>
References: <52E0FDDB.40701@redhat.com> <52E107B4.5070907@jboss.com>
	<52E107F4.9050702@jboss.com>
Message-ID: <52E10B60.8030101@redhat.com>

Yes, that works too. Thanks for your help.

Le 23/01/2014 13:15, Darran Lofthouse a ?crit :
> Should add the workaround would be to just add a dummy user definition
> to the properties file so that one user is defined - the password hash
> does not need to be a valid hash.
>
> On 23/01/14 12:14, Darran Lofthouse wrote:
>> I believe you are running into an old bug, in later releases that page
>> should no longer be displayed if a trust store is defined against the realm.
>>
>> Regards,
>> Darran Lofthouse.
>>
>>
>> On 23/01/14 11:32, Thomas Segismont wrote:
>>> Hi,
>>>
>>> I have setup client certificate authentication on AS7.1.1 with this
>>> Management realm definition:
>>>
>>> <security-realm name="ManagementRealm">
>>>         <server-identities>
>>>             <ssl>
>>>                 <keystore path="server.jks"
>>> relative-to="jboss.server.config.dir" password="abcdef"/>
>>>             </ssl>
>>>         </server-identities>
>>>         <authentication>
>>>             <truststore path="server.jks"
>>> relative-to="jboss.server.config.dir" password="abcdef" />
>>>             <properties path="mgmt-users.properties" relative
>>> to="jboss.server.config.dir"/>
>>>         </authentication>
>>> </security-realm>
>>>
>>> When I try to browse the admin console in Firefox, it asks me to confirm
>>> I want to authenticate with the client cert (good) and then I can only
>>> see the error page:
>>>
>>> ===
>>> Your JBoss Application Server 7 is running.
>>>
>>> However you have not yet added any users to be able to access the admin
>>> console.
>>> ===
>>>
>>> How can I map a client certificate to a management user?
>>>
>>> Thanks for your help,
>>> Thomas
>>> _______________________________________________
>>> 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 brian.stansberry at redhat.com  Thu Jan 23 11:50:23 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 23 Jan 2014 10:50:23 -0600
Subject: [wildfly-dev] WFLY-818 Slave host does not register to DC
In-Reply-To: <CALbD--pnYa5h_UJ-LGLS=kKv-YBB1fy3ETP6SxoxzQ5-+x96jQ@mail.gmail.com>
References: <CALbD--q_SRzg=zW8X+GQwv2ioQgBDjtB6H=aqxKFnQHoUygYuQ@mail.gmail.com>	<52DFB26F.2080609@redhat.com>
	<CALbD--pnYa5h_UJ-LGLS=kKv-YBB1fy3ETP6SxoxzQ5-+x96jQ@mail.gmail.com>
Message-ID: <52E1484F.9060108@redhat.com>

On 1/22/14, 8:49 AM, Claudio Miranda wrote:
> Hi
>
> On Wed, Jan 22, 2014 at 9:58 AM, Emanuel Muckenhuber
> <emuckenh at redhat.com> wrote:
>> There are other open issues related to
>> this, i.e. when using --cached-dc and --backup-dc at the same time.
>
> What do you think to let this as default ?
> Thinking from a HA view, the sysadmin, always wants their HC to work,
> so, if HC caches a local copy by default, it makes sense to load it if
> HC cannot registers itself with DC.
>
> I have worked with some customers, they just want to start jboss,
> regardless if HC are able to connect to DC. Of course, there should
> exist some mechanism to warn sysadmin the registration was not
> possible and they must look into it.
>

If we made --cached-dc + --backup-dc semantics the default, we'd have to 
introduce some mechanism to turn them off. I'm not sure the gain is 
worth it, particularly in the --cached-dc case. If you're starting an HC 
I think it's better to explicitly state that you're ok with that HC 
being out of sync with the domain.

OTOH, --backup-dc by default makes a lot of sense. If we don't have a 
local copy of the domain config and then the admin discovers he needs 
one so he can start the HC, it's too late.



-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From bburke at redhat.com  Thu Jan 23 13:24:13 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 23 Jan 2014 13:24:13 -0500
Subject: [wildfly-dev] Keycloak SSO Alpha 1 Released
Message-ID: <52E15E4D.7000601@redhat.com>

Keycloak is an SSO auth server and appliance for web applications and 
RESTful web services.  It can act as a Social Broker for Social Login 
via Google, Twitter, and Facebook.  It has a nice admin console UI for 
managing a variety of security metadata and much much more...

Please view my blog for more details on features, videos, downloads, and 
documentation:

http://bill.burkecentral.com/2014/01/23/keycloak-sso-released-alpha-1/

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

From tconway556 at yahoo.com  Sat Jan 25 22:58:34 2014
From: tconway556 at yahoo.com (tjc)
Date: Sat, 25 Jan 2014 19:58:34 -0800 (PST)
Subject: [wildfly-dev] localhost:8080 always has AS 7 running,
	even right after reboot
Message-ID: <1390708714225-5713409.post@n5.nabble.com>


How can I disable as 7 from starting automatically whenever I login to my pc
?
I need to use other app servers on this port.

I am using jboss-as-7.1.1.Final, standalone config, more or less out of the
box.

Right after booting and logging in, if I browse to localhost:8080 the as 7
server screen will be there and tell me it is running. (no other apps have
been started) 

I want it to only start when I tell it to.

trying to stop it using the cli just gets me an error saying:
"The controller is not available at localhost:9999"



--
View this message in context: http://wildfly-development.1055759.n5.nabble.com/localhost-8080-always-has-AS-7-running-even-right-after-reboot-tp5713409.html
Sent from the WildFly Development mailing list archive at Nabble.com.

From jsightle at redhat.com  Sun Jan 26 14:06:33 2014
From: jsightle at redhat.com (Jess Sightler)
Date: Sun, 26 Jan 2014 14:06:33 -0500 (EST)
Subject: [wildfly-dev] localhost:8080 always has AS 7 running,
 even right after reboot
In-Reply-To: <1390708714225-5713409.post@n5.nabble.com>
References: <1390708714225-5713409.post@n5.nabble.com>
Message-ID: <534466903.5870117.1390763193783.JavaMail.root@redhat.com>

What operating system are you using? And how did you install AS originally?

----- Original Message -----
> From: "tjc" <tconway556 at yahoo.com>
> To: wildfly-dev at lists.jboss.org
> Sent: Saturday, January 25, 2014 10:58:34 PM
> Subject: [wildfly-dev] localhost:8080 always has AS 7 running,	even right after reboot
> 
> 
> How can I disable as 7 from starting automatically whenever I login to my pc
> ?
> I need to use other app servers on this port.
> 
> I am using jboss-as-7.1.1.Final, standalone config, more or less out of the
> box.
> 
> Right after booting and logging in, if I browse to localhost:8080 the as 7
> server screen will be there and tell me it is running. (no other apps have
> been started)
> 
> I want it to only start when I tell it to.
> 
> trying to stop it using the cli just gets me an error saying:
> "The controller is not available at localhost:9999"
> 
> 
> 
> --
> View this message in context:
> http://wildfly-development.1055759.n5.nabble.com/localhost-8080-always-has-AS-7-running-even-right-after-reboot-tp5713409.html
> Sent from the WildFly Development mailing list archive at Nabble.com.
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 

From hpehl at redhat.com  Sun Jan 26 14:59:49 2014
From: hpehl at redhat.com (Harald Pehl)
Date: Sun, 26 Jan 2014 20:59:49 +0100
Subject: [wildfly-dev] "It's The Final Countdown!"
In-Reply-To: <C380E806-0FAD-4A87-A2C0-90F357BFF9F7@redhat.com>
References: <C380E806-0FAD-4A87-A2C0-90F357BFF9F7@redhat.com>
Message-ID: <DAED7773-8D12-4F2D-B56F-7575E378DCA9@redhat.com>

I'm planing to do a final release for the Admin Console on Wednesday 29th. Is this in time for the WildFly final?

Thanks 
Harald


Am 21.01.2014 um 20:00 schrieb Jason Greene <jason.greene at redhat.com>:

> No this isn?t the Europe song (Sorry to disappoint!).
> 
> It is however the countdown to WildFly 8 Final release!
> 
> The key things that remain are:
> 
> 1) Final Components - We need PRs upgrading to ?Final? for all outstanding 
> subcomponents[1]. If you own one of them, then please make this a high priority. 
> The sooner the better.
> 
> 2) Identify Blockers - We need to identify all remaining blockers that have been
> reported against CR1. I?m hoping everyone can look through the forms for likely
> blockers and convert them to JIRAs. As a reminder a blocker is anything that is 
> mass user effecting and severe in nature. Examples include: hangs, crashes, 
> memory leaks, vulnerabilities, and data corruption.
> 
> 3) JASPIC Acceptance - A few of you on this list have noted issues. We need to 
> ensure that the Final release has addressed the outstanding issues.
> 
> Thanks!
> 
> [1] Outstanding components.
> 
> io.undertow 1.0.0.Beta30
> io.undertow.jastow 1.0.0.CR1
> org.glassfish.javax.el 3.0-b07
> org.hibernate.search 4.5.0.Alpha2 *exception*
> org.infinispan.protostream 1.0.0.CR1
> org.jberet 1.0.0.CR1
> org.jboss.ejb-client 2.0.0.Beta5
> org.jboss.narayana 5.0.0.CR2
> org.jboss.jsfunit 2.0.0.Beta1
> org.jboss.logging.jboss-logging-tools 1.2.0.Beta1
> org.jboss.metadata 8.0.0.CR1
> org.jboss.mod_cluster 1.3.0.Alpha1
> org.jboss.msc.jboss-msc 1.2.0.CR1
> org.jboss.xnio.netty.netty-xnio-transport 0.1.1.CR2
> org.jboss.remote-naming 2.0.0.Beta2
> org.jboss.remoting 4.0.0.Beta3
> org.jboss.remotingjmx.remoting-jmx 2.0.0.CR4
> org.jboss.sasl 1.0.4.CR1
> org.jboss.spec.javax.el.jboss-el-api_3.0_spec 1.0.0.Beta1
> org.jboss.spec.javax.security.auth.message.jboss-jaspi-api_1.1_spec 1.0.0.Alpha1
> org.jboss.spec.javax.security.jacc.jboss-jacc-api_1.5_spec 1.0.0.Beta1
> org.jboss.spec.javax.servlet.jsp.jboss-jsp-api_2.3_spec 1.0.0.Beta1
> org.jboss.spec.javax.servlet.jstl.jboss-jstl-api_1.2_spec 1.0.4.Beta1
> org.jboss.xnio 3.2.0.Beta4
> org.picketbox 4.0.20.Beta4
> org.wildfly.security.manager 1.0.0.Beta3
> 
> 
> 
> --
> 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

---
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/20140126/0f85b401/attachment-0001.bin 

From jgreene at redhat.com  Sun Jan 26 19:35:58 2014
From: jgreene at redhat.com (Jason Greene)
Date: Sun, 26 Jan 2014 19:35:58 -0500 (EST)
Subject: [wildfly-dev] "It's The Final Countdown!"
In-Reply-To: <DAED7773-8D12-4F2D-B56F-7575E378DCA9@redhat.com>
References: <C380E806-0FAD-4A87-A2C0-90F357BFF9F7@redhat.com>
	<DAED7773-8D12-4F2D-B56F-7575E378DCA9@redhat.com>
Message-ID: <A28F1555-B5E2-4BEC-A3E1-A69EF6BF95C3@redhat.com>

Sure that's fine.

Sent from my iPhone

> On Jan 26, 2014, at 1:59 PM, Harald Pehl <hpehl at redhat.com> wrote:
> 
> I'm planing to do a final release for the Admin Console on Wednesday 29th. Is this in time for the WildFly final?
> 
> Thanks 
> Harald
> 
> 
>> Am 21.01.2014 um 20:00 schrieb Jason Greene <jason.greene at redhat.com>:
>> 
>> No this isn?t the Europe song (Sorry to disappoint!).
>> 
>> It is however the countdown to WildFly 8 Final release!
>> 
>> The key things that remain are:
>> 
>> 1) Final Components - We need PRs upgrading to ?Final? for all outstanding 
>> subcomponents[1]. If you own one of them, then please make this a high priority. 
>> The sooner the better.
>> 
>> 2) Identify Blockers - We need to identify all remaining blockers that have been
>> reported against CR1. I?m hoping everyone can look through the forms for likely
>> blockers and convert them to JIRAs. As a reminder a blocker is anything that is 
>> mass user effecting and severe in nature. Examples include: hangs, crashes, 
>> memory leaks, vulnerabilities, and data corruption.
>> 
>> 3) JASPIC Acceptance - A few of you on this list have noted issues. We need to 
>> ensure that the Final release has addressed the outstanding issues.
>> 
>> Thanks!
>> 
>> [1] Outstanding components.
>> 
>> io.undertow 1.0.0.Beta30
>> io.undertow.jastow 1.0.0.CR1
>> org.glassfish.javax.el 3.0-b07
>> org.hibernate.search 4.5.0.Alpha2 *exception*
>> org.infinispan.protostream 1.0.0.CR1
>> org.jberet 1.0.0.CR1
>> org.jboss.ejb-client 2.0.0.Beta5
>> org.jboss.narayana 5.0.0.CR2
>> org.jboss.jsfunit 2.0.0.Beta1
>> org.jboss.logging.jboss-logging-tools 1.2.0.Beta1
>> org.jboss.metadata 8.0.0.CR1
>> org.jboss.mod_cluster 1.3.0.Alpha1
>> org.jboss.msc.jboss-msc 1.2.0.CR1
>> org.jboss.xnio.netty.netty-xnio-transport 0.1.1.CR2
>> org.jboss.remote-naming 2.0.0.Beta2
>> org.jboss.remoting 4.0.0.Beta3
>> org.jboss.remotingjmx.remoting-jmx 2.0.0.CR4
>> org.jboss.sasl 1.0.4.CR1
>> org.jboss.spec.javax.el.jboss-el-api_3.0_spec 1.0.0.Beta1
>> org.jboss.spec.javax.security.auth.message.jboss-jaspi-api_1.1_spec 1.0.0.Alpha1
>> org.jboss.spec.javax.security.jacc.jboss-jacc-api_1.5_spec 1.0.0.Beta1
>> org.jboss.spec.javax.servlet.jsp.jboss-jsp-api_2.3_spec 1.0.0.Beta1
>> org.jboss.spec.javax.servlet.jstl.jboss-jstl-api_1.2_spec 1.0.4.Beta1
>> org.jboss.xnio 3.2.0.Beta4
>> org.picketbox 4.0.20.Beta4
>> org.wildfly.security.manager 1.0.0.Beta3
>> 
>> 
>> 
>> --
>> 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
> 
> ---
> Harald Pehl
> JBoss by Red Hat
> http://hpehl.info
> 


From arun.gupta at gmail.com  Sun Jan 26 21:07:52 2014
From: arun.gupta at gmail.com (Arun Gupta)
Date: Mon, 27 Jan 2014 07:37:52 +0530
Subject: [wildfly-dev] "It's The Final Countdown!"
In-Reply-To: <DAED7773-8D12-4F2D-B56F-7575E378DCA9@redhat.com>
References: <C380E806-0FAD-4A87-A2C0-90F357BFF9F7@redhat.com>
	<DAED7773-8D12-4F2D-B56F-7575E378DCA9@redhat.com>
Message-ID: <CAGBoHQW5xyCNPBZtcFgWNYj5Wxh0BY8q9Cbvkpn=xz4cN99ARg@mail.gmail.com>

Hi Harald,

I sent several comments on Admin Console to you and Heiko. Any chances
any of that would make it in for this release ?

Arun

On Mon, Jan 27, 2014 at 1:29 AM, Harald Pehl <hpehl at redhat.com> wrote:
> I'm planing to do a final release for the Admin Console on Wednesday 29th. Is this in time for the WildFly final?
>
> Thanks
> Harald
>
>
> Am 21.01.2014 um 20:00 schrieb Jason Greene <jason.greene at redhat.com>:
>
>> No this isn?t the Europe song (Sorry to disappoint!).
>>
>> It is however the countdown to WildFly 8 Final release!
>>
>> The key things that remain are:
>>
>> 1) Final Components - We need PRs upgrading to ?Final? for all outstanding
>> subcomponents[1]. If you own one of them, then please make this a high priority.
>> The sooner the better.
>>
>> 2) Identify Blockers - We need to identify all remaining blockers that have been
>> reported against CR1. I?m hoping everyone can look through the forms for likely
>> blockers and convert them to JIRAs. As a reminder a blocker is anything that is
>> mass user effecting and severe in nature. Examples include: hangs, crashes,
>> memory leaks, vulnerabilities, and data corruption.
>>
>> 3) JASPIC Acceptance - A few of you on this list have noted issues. We need to
>> ensure that the Final release has addressed the outstanding issues.
>>
>> Thanks!
>>
>> [1] Outstanding components.
>>
>> io.undertow 1.0.0.Beta30
>> io.undertow.jastow 1.0.0.CR1
>> org.glassfish.javax.el 3.0-b07
>> org.hibernate.search 4.5.0.Alpha2 *exception*
>> org.infinispan.protostream 1.0.0.CR1
>> org.jberet 1.0.0.CR1
>> org.jboss.ejb-client 2.0.0.Beta5
>> org.jboss.narayana 5.0.0.CR2
>> org.jboss.jsfunit 2.0.0.Beta1
>> org.jboss.logging.jboss-logging-tools 1.2.0.Beta1
>> org.jboss.metadata 8.0.0.CR1
>> org.jboss.mod_cluster 1.3.0.Alpha1
>> org.jboss.msc.jboss-msc 1.2.0.CR1
>> org.jboss.xnio.netty.netty-xnio-transport 0.1.1.CR2
>> org.jboss.remote-naming 2.0.0.Beta2
>> org.jboss.remoting 4.0.0.Beta3
>> org.jboss.remotingjmx.remoting-jmx 2.0.0.CR4
>> org.jboss.sasl 1.0.4.CR1
>> org.jboss.spec.javax.el.jboss-el-api_3.0_spec 1.0.0.Beta1
>> org.jboss.spec.javax.security.auth.message.jboss-jaspi-api_1.1_spec 1.0.0.Alpha1
>> org.jboss.spec.javax.security.jacc.jboss-jacc-api_1.5_spec 1.0.0.Beta1
>> org.jboss.spec.javax.servlet.jsp.jboss-jsp-api_2.3_spec 1.0.0.Beta1
>> org.jboss.spec.javax.servlet.jstl.jboss-jstl-api_1.2_spec 1.0.4.Beta1
>> org.jboss.xnio 3.2.0.Beta4
>> org.picketbox 4.0.20.Beta4
>> org.wildfly.security.manager 1.0.0.Beta3
>>
>>
>>
>> --
>> 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
>
> ---
> Harald Pehl
> JBoss by Red Hat
> http://hpehl.info
>
>
> _______________________________________________
> 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  Mon Jan 27 05:33:01 2014
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Mon, 27 Jan 2014 10:33:01 +0000
Subject: [wildfly-dev] localhost:8080 always has AS 7 running,
 even right after reboot
In-Reply-To: <534466903.5870117.1390763193783.JavaMail.root@redhat.com>
References: <1390708714225-5713409.post@n5.nabble.com>
	<534466903.5870117.1390763193783.JavaMail.root@redhat.com>
Message-ID: <52E635DD.8020100@jboss.com>

You also should double check that AS 7 is really running, it is not 
unheard of for other processes to listen on port 8080 that leave the web 
browser to just display whatever it has cached for that address.

Maybe try completely clearing your browser caches to see if it is really 
JBoss AS7 responding,

Regards,
Darran Lofthouse.


On 26/01/14 19:06, Jess Sightler wrote:
> What operating system are you using? And how did you install AS originally?
>
> ----- Original Message -----
>> From: "tjc" <tconway556 at yahoo.com>
>> To: wildfly-dev at lists.jboss.org
>> Sent: Saturday, January 25, 2014 10:58:34 PM
>> Subject: [wildfly-dev] localhost:8080 always has AS 7 running,	even right after reboot
>>
>>
>> How can I disable as 7 from starting automatically whenever I login to my pc
>> ?
>> I need to use other app servers on this port.
>>
>> I am using jboss-as-7.1.1.Final, standalone config, more or less out of the
>> box.
>>
>> Right after booting and logging in, if I browse to localhost:8080 the as 7
>> server screen will be there and tell me it is running. (no other apps have
>> been started)
>>
>> I want it to only start when I tell it to.
>>
>> trying to stop it using the cli just gets me an error saying:
>> "The controller is not available at localhost:9999"
>>
>>
>>
>> --
>> View this message in context:
>> http://wildfly-development.1055759.n5.nabble.com/localhost-8080-always-has-AS-7-running-even-right-after-reboot-tp5713409.html
>> Sent from the WildFly Development mailing list archive at Nabble.com.
>> _______________________________________________
>> 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 hpehl at redhat.com  Mon Jan 27 05:34:09 2014
From: hpehl at redhat.com (Harald Pehl)
Date: Mon, 27 Jan 2014 11:34:09 +0100
Subject: [wildfly-dev] "It's The Final Countdown!"
In-Reply-To: <CAGBoHQW5xyCNPBZtcFgWNYj5Wxh0BY8q9Cbvkpn=xz4cN99ARg@mail.gmail.com>
References: <C380E806-0FAD-4A87-A2C0-90F357BFF9F7@redhat.com>
	<DAED7773-8D12-4F2D-B56F-7575E378DCA9@redhat.com>
	<CAGBoHQW5xyCNPBZtcFgWNYj5Wxh0BY8q9Cbvkpn=xz4cN99ARg@mail.gmail.com>
Message-ID: <D20655F9-38ED-44A4-9BB0-9504A7F3E472@redhat.com>

Hi Arun, 

thanks for your feedback. I already fixed some of them in upstream.

.: Harald


Am 27.01.2014 um 03:07 schrieb Arun Gupta <arun.gupta at gmail.com>:

> Hi Harald,
> 
> I sent several comments on Admin Console to you and Heiko. Any chances
> any of that would make it in for this release ?
> 
> Arun
> 
> On Mon, Jan 27, 2014 at 1:29 AM, Harald Pehl <hpehl at redhat.com> wrote:
>> I'm planing to do a final release for the Admin Console on Wednesday 29th. Is this in time for the WildFly final?
>> 
>> Thanks
>> Harald
>> 
>> 
>> Am 21.01.2014 um 20:00 schrieb Jason Greene <jason.greene at redhat.com>:
>> 
>>> No this isn?t the Europe song (Sorry to disappoint!).
>>> 
>>> It is however the countdown to WildFly 8 Final release!
>>> 
>>> The key things that remain are:
>>> 
>>> 1) Final Components - We need PRs upgrading to ?Final? for all outstanding
>>> subcomponents[1]. If you own one of them, then please make this a high priority.
>>> The sooner the better.
>>> 
>>> 2) Identify Blockers - We need to identify all remaining blockers that have been
>>> reported against CR1. I?m hoping everyone can look through the forms for likely
>>> blockers and convert them to JIRAs. As a reminder a blocker is anything that is
>>> mass user effecting and severe in nature. Examples include: hangs, crashes,
>>> memory leaks, vulnerabilities, and data corruption.
>>> 
>>> 3) JASPIC Acceptance - A few of you on this list have noted issues. We need to
>>> ensure that the Final release has addressed the outstanding issues.
>>> 
>>> Thanks!
>>> 
>>> [1] Outstanding components.
>>> 
>>> io.undertow 1.0.0.Beta30
>>> io.undertow.jastow 1.0.0.CR1
>>> org.glassfish.javax.el 3.0-b07
>>> org.hibernate.search 4.5.0.Alpha2 *exception*
>>> org.infinispan.protostream 1.0.0.CR1
>>> org.jberet 1.0.0.CR1
>>> org.jboss.ejb-client 2.0.0.Beta5
>>> org.jboss.narayana 5.0.0.CR2
>>> org.jboss.jsfunit 2.0.0.Beta1
>>> org.jboss.logging.jboss-logging-tools 1.2.0.Beta1
>>> org.jboss.metadata 8.0.0.CR1
>>> org.jboss.mod_cluster 1.3.0.Alpha1
>>> org.jboss.msc.jboss-msc 1.2.0.CR1
>>> org.jboss.xnio.netty.netty-xnio-transport 0.1.1.CR2
>>> org.jboss.remote-naming 2.0.0.Beta2
>>> org.jboss.remoting 4.0.0.Beta3
>>> org.jboss.remotingjmx.remoting-jmx 2.0.0.CR4
>>> org.jboss.sasl 1.0.4.CR1
>>> org.jboss.spec.javax.el.jboss-el-api_3.0_spec 1.0.0.Beta1
>>> org.jboss.spec.javax.security.auth.message.jboss-jaspi-api_1.1_spec 1.0.0.Alpha1
>>> org.jboss.spec.javax.security.jacc.jboss-jacc-api_1.5_spec 1.0.0.Beta1
>>> org.jboss.spec.javax.servlet.jsp.jboss-jsp-api_2.3_spec 1.0.0.Beta1
>>> org.jboss.spec.javax.servlet.jstl.jboss-jstl-api_1.2_spec 1.0.4.Beta1
>>> org.jboss.xnio 3.2.0.Beta4
>>> org.picketbox 4.0.20.Beta4
>>> org.wildfly.security.manager 1.0.0.Beta3
>>> 
>>> 
>>> 
>>> --
>>> 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
>> 
>> ---
>> Harald Pehl
>> JBoss by Red Hat
>> http://hpehl.info
>> 
>> 
>> _______________________________________________
>> 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

---
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/20140127/b70360db/attachment.bin 

From mmmzzz at gmail.com  Mon Jan 27 10:01:14 2014
From: mmmzzz at gmail.com (Marrrrck)
Date: Mon, 27 Jan 2014 10:01:14 -0500
Subject: [wildfly-dev] Small Defect in cli xa-data-source command
Message-ID: <CAD8EKPFmiUHchMgpXvAq5aWzP9BX65TY-QB_h3dW4+_KkMF8fA@mail.gmail.com>

Hello everyone,

I think I found a minor defect in the jboss-cli /xa-data-source operation
in Widlfly 8. Can anyone confirm this or correct me if I'm wrong?

Currently the jboss-cli doesn't let you set the jta true/false property on
an XA data source. You can set this property on a regular data source, but
not an XA one. Is this intentional or a defect?

If it is a defect, I think the problem might be in this file:

https://github.com/wildfly/wildfly/blob/master/connector/src/main/java/org/jboss/as/connector/subsystems/datasources/Constants.java

You can see on line 419 that DATASOURCE_ATTRIBUTE includes the JTA
attribute definition:

static final SimpleAttributeDefinition[] DATASOURCE_ATTRIBUTE = new
SimpleAttributeDefinition[]{CONNECTION_URL,
>             DRIVER_CLASS, Constants.DATASOURCE_CLASS, JNDI_NAME,
>             DATASOURCE_DRIVER,
>             NEW_CONNECTION_SQL, URL_DELIMITER,
>             URL_SELECTOR_STRATEGY_CLASS_NAME, USE_JAVA_CONTEXT,
>             *JTA*, org.jboss.as.connector.subsystems.common.pool.Constants.MAX_POOL_SIZE,


But on line 492, the XA_DATASOURCE_ATTRIBUTE doesn't have JTA

    static final SimpleAttributeDefinition[] XA_DATASOURCE_ATTRIBUTE =
new SimpleAttributeDefinition[]{
>             Constants.XA_DATASOURCE_CLASS, JNDI_NAME, DATASOURCE_DRIVER,
>             NEW_CONNECTION_SQL, URL_DELIMITER,
>             URL_SELECTOR_STRATEGY_CLASS_NAME, USE_JAVA_CONTEXT,
>             org.jboss.as.connector.subsystems.common.pool.Constants.MAX_POOL_SIZE,


Would just adding "JTA," after USE_JAVA_CONTEXT on line 492 fix this, or is
there more that needs to be done? I'm happy to submit a pull request to
fix, but it is such a minor change that it might be easier for someone
already working in the code to do it.

Thanks for your help and my apologies if this is already been reported or
previously discussed.

Marc Zbyszynski
Verifi LLC
http://verificoncrete.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140127/bedee9b1/attachment-0001.html 

From tsegismo at redhat.com  Mon Jan 27 11:02:30 2014
From: tsegismo at redhat.com (Thomas Segismont)
Date: Mon, 27 Jan 2014 17:02:30 +0100
Subject: [wildfly-dev] Decoding query name attribute in
 deployment/subsystem/jpa/hibernate-persistence-unit/query-cache nodes
Message-ID: <52E68316.8090709@redhat.com>

Hi,

deployment/subsystem/jpa/hibernate-persistence-unit/query-cache nodes 
expose an "encoded" query name attribute. Here's an example:

"rhq.ear/rhq-core-domain-ejb3.jar#rhqpu.rhq.ear_divide_rhq_minus_core_minus_domain_minus_ejb3.jar#rhqpu.rhq.ear_divide_rhq_minus_core_minus_domain_minus_ejb3.jar#rhqpu.SELECT_space_subject_newline_FROM_space_Subject_space_subject_newline_WHERE_space__left_paren__space_LOWER_left_paren__space_subject.name_space__right_paren__space_like_space__colon_name_space_ESCAPE_space__quote_\\_quote__space__space__right_paren__newline_ORDER_space_BY_space_subject.id_space_ASC_newline_"

I could write something to decode every occurrence of "_minus_", 
"_space_" and so on, provided I can get the list of all the keywords in 
use. But I wonder if there's already a library in the Hibernate 
subsystem which does that.

By the way, these nodes exist in AS7 and EAP6, but I found no equivalent 
in Wildfly management model. Did I miss the definition on the Wildscribe 
site?

http://wildscribe.github.io/JBoss%20AS7/7.1.1/deployment/subsystem/jpa/hibernate-persistence-unit/query-cache/index.html

Thanks,
Thomas

From jesper.pedersen at jboss.org  Mon Jan 27 11:02:50 2014
From: jesper.pedersen at jboss.org (Jesper Pedersen)
Date: Mon, 27 Jan 2014 11:02:50 -0500
Subject: [wildfly-dev] Small Defect in cli xa-data-source command
In-Reply-To: <CAD8EKPFmiUHchMgpXvAq5aWzP9BX65TY-QB_h3dW4+_KkMF8fA@mail.gmail.com>
References: <CAD8EKPFmiUHchMgpXvAq5aWzP9BX65TY-QB_h3dW4+_KkMF8fA@mail.gmail.com>
Message-ID: <52E6832A.20605@jboss.org>

On 01/27/2014 10:01 AM, Marrrrck wrote:
> Currently the jboss-cli doesn't let you set the jta true/false property on
> an XA data source. You can set this property on a regular data source, but
> not an XA one. Is this intentional or a defect?

XA datasources are always enlisted in a transaction - so there is no jta 
attribute.



From tomaz.cerar at gmail.com  Mon Jan 27 11:22:00 2014
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Mon, 27 Jan 2014 17:22:00 +0100
Subject: [wildfly-dev] Decoding query name attribute in
 deployment/subsystem/jpa/hibernate-persistence-unit/query-cache nodes
In-Reply-To: <52E68316.8090709@redhat.com>
References: <52E68316.8090709@redhat.com>
Message-ID: <CAMquZP7inAccG-_Q0VLpAJ4qimNuggnxzXWZW-hBAXdQS9HVsQ@mail.gmail.com>

It was removed as part of this commit
https://github.com/wildfly/wildfly/commit/ac3bee2#diff-d3c9757d55cdb99a978579547b2f5cc6R105

why, that would be question for Scott.

--
tomaz


On Mon, Jan 27, 2014 at 5:02 PM, Thomas Segismont <tsegismo at redhat.com>wrote:

> Hi,
>
> deployment/subsystem/jpa/hibernate-persistence-unit/query-cache nodes
> expose an "encoded" query name attribute. Here's an example:
>
>
> "rhq.ear/rhq-core-domain-ejb3.jar#rhqpu.rhq.ear_divide_rhq_minus_core_minus_domain_minus_ejb3.jar#rhqpu.rhq.ear_divide_rhq_minus_core_minus_domain_minus_ejb3.jar#rhqpu.SELECT_space_subject_newline_FROM_space_Subject_space_subject_newline_WHERE_space__left_paren__space_LOWER_left_paren__space_subject.name_space__right_paren__space_like_space__colon_name_space_ESCAPE_space__quote_\\_quote__space__space__right_paren__newline_ORDER_space_BY_space_subject.id_space_ASC_newline_"
>
> I could write something to decode every occurrence of "_minus_",
> "_space_" and so on, provided I can get the list of all the keywords in
> use. But I wonder if there's already a library in the Hibernate
> subsystem which does that.
>
> By the way, these nodes exist in AS7 and EAP6, but I found no equivalent
> in Wildfly management model. Did I miss the definition on the Wildscribe
> site?
>
>
> http://wildscribe.github.io/JBoss%20AS7/7.1.1/deployment/subsystem/jpa/hibernate-persistence-unit/query-cache/index.html
>
> Thanks,
> Thomas
> _______________________________________________
> 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/20140127/ae448529/attachment.html 

From mmmzzz at gmail.com  Mon Jan 27 11:57:46 2014
From: mmmzzz at gmail.com (Marrrrck)
Date: Mon, 27 Jan 2014 11:57:46 -0500
Subject: [wildfly-dev] Small Defect in cli xa-data-source command
In-Reply-To: <52E6832A.20605@jboss.org>
References: <CAD8EKPFmiUHchMgpXvAq5aWzP9BX65TY-QB_h3dW4+_KkMF8fA@mail.gmail.com>
	<52E6832A.20605@jboss.org>
Message-ID: <CAD8EKPEpmqELUznQLsZV5AJbLx7O0Coj7C_tvnbAEH1o9V1BEw@mail.gmail.com>

Ah ha! Ok that makes sense.

Thanks for clearing that up Jesper!


On Mon, Jan 27, 2014 at 11:02 AM, Jesper Pedersen <jesper.pedersen at jboss.org
> wrote:

> On 01/27/2014 10:01 AM, Marrrrck wrote:
> > Currently the jboss-cli doesn't let you set the jta true/false property
> on
> > an XA data source. You can set this property on a regular data source,
> but
> > not an XA one. Is this intentional or a defect?
>
> XA datasources are always enlisted in a transaction - so there is no jta
> attribute.
>
>
> _______________________________________________
> 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/20140127/4f167db4/attachment.html 

From smarlow at redhat.com  Mon Jan 27 11:57:57 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Mon, 27 Jan 2014 11:57:57 -0500
Subject: [wildfly-dev] Decoding query name attribute in
 deployment/subsystem/jpa/hibernate-persistence-unit/query-cache nodes
In-Reply-To: <CAMquZP7inAccG-_Q0VLpAJ4qimNuggnxzXWZW-hBAXdQS9HVsQ@mail.gmail.com>
References: <52E68316.8090709@redhat.com>
	<CAMquZP7inAccG-_Q0VLpAJ4qimNuggnxzXWZW-hBAXdQS9HVsQ@mail.gmail.com>
Message-ID: <52E69015.5010703@redhat.com>

Thomas,

In WildFly 8, the code moved to the Jipijapa project.

For Hibernate 4.3.x, the (private api) QueryName class transforms the 
query via 
https://github.com/jipijapa/jipijapa/blob/master/hibernate4_3/src/main/java/org/jboss/as/jpa/hibernate4/management/QueryName.java

There is also a Hibernate 4.1.x/4.2.x implementation here 
https://github.com/jipijapa/jipijapa/blob/master/hibernate4_1/src/main/java/org/jboss/as/jpa/hibernate4/management/QueryName.java

The *why* is to turn the query name into a legal name (e.g. that can be 
displayed by the jboss-cli tool).

Why are you trying to decode the query back into its original (internal 
Hibernate) form?  Which project are you trying to do this for?

Scott

On 01/27/2014 11:22 AM, Toma? Cerar wrote:
> It was removed as part of this commit
> https://github.com/wildfly/wildfly/commit/ac3bee2#diff-d3c9757d55cdb99a978579547b2f5cc6R105
>
> why, that would be question for Scott.
>
> --
> tomaz
>
>
> On Mon, Jan 27, 2014 at 5:02 PM, Thomas Segismont <tsegismo at redhat.com
> <mailto:tsegismo at redhat.com>> wrote:
>
>     Hi,
>
>     deployment/subsystem/jpa/hibernate-persistence-unit/query-cache nodes
>     expose an "encoded" query name attribute. Here's an example:
>
>     "rhq.ear/rhq-core-domain-ejb3.jar#rhqpu.rhq.ear_divide_rhq_minus_core_minus_domain_minus_ejb3.jar#rhqpu.rhq.ear_divide_rhq_minus_core_minus_domain_minus_ejb3.jar#rhqpu.SELECT_space_subject_newline_FROM_space_Subject_space_subject_newline_WHERE_space__left_paren__space_LOWER_left_paren__space_subject.name_space__right_paren__space_like_space__colon_name_space_ESCAPE_space__quote_\\_quote__space__space__right_paren__newline_ORDER_space_BY_space_subject.id_space_ASC_newline_"
>
>     I could write something to decode every occurrence of "_minus_",
>     "_space_" and so on, provided I can get the list of all the keywords in
>     use. But I wonder if there's already a library in the Hibernate
>     subsystem which does that.
>
>     By the way, these nodes exist in AS7 and EAP6, but I found no equivalent
>     in Wildfly management model. Did I miss the definition on the Wildscribe
>     site?
>
>     http://wildscribe.github.io/JBoss%20AS7/7.1.1/deployment/subsystem/jpa/hibernate-persistence-unit/query-cache/index.html
>
>     Thanks,
>     Thomas
>     _______________________________________________
>     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 tsegismo at redhat.com  Mon Jan 27 12:10:26 2014
From: tsegismo at redhat.com (Thomas Segismont)
Date: Mon, 27 Jan 2014 18:10:26 +0100
Subject: [wildfly-dev] Decoding query name attribute in
 deployment/subsystem/jpa/hibernate-persistence-unit/query-cache nodes
In-Reply-To: <52E69015.5010703@redhat.com>
References: <52E68316.8090709@redhat.com>
	<CAMquZP7inAccG-_Q0VLpAJ4qimNuggnxzXWZW-hBAXdQS9HVsQ@mail.gmail.com>
	<52E69015.5010703@redhat.com>
Message-ID: <52E69302.3090709@redhat.com>

Hi Scott,

Thanks for replying. Please find my answers below.

Le 27/01/2014 17:57, Scott Marlow a ?crit :
> Thomas,
>
> In WildFly 8, the code moved to the Jipijapa project.
>
> For Hibernate 4.3.x, the (private api) QueryName class transforms the
> query via
> https://github.com/jipijapa/jipijapa/blob/master/hibernate4_3/src/main/java/org/jboss/as/jpa/hibernate4/management/QueryName.java
>
>
> There is also a Hibernate 4.1.x/4.2.x implementation here
> https://github.com/jipijapa/jipijapa/blob/master/hibernate4_1/src/main/java/org/jboss/as/jpa/hibernate4/management/QueryName.java
>

OK. Where in the management tree will the nodes appear?

>
> The *why* is to turn the query name into a legal name (e.g. that can be
> displayed by the jboss-cli tool).

Got you.

>
> Why are you trying to decode the query back into its original (internal
> Hibernate) form?  Which project are you trying to do this for?

I'm trying to decode the name to show the query statistics in RHQ. I 
wish there was an attribute in the node with the plain query string. 
That would be a nice add in Wildfly, but for RHQ to work with already 
released versions of AS7 and EAP6, there's no other way...

>
> Scott
>
> On 01/27/2014 11:22 AM, Toma? Cerar wrote:
>> It was removed as part of this commit
>> https://github.com/wildfly/wildfly/commit/ac3bee2#diff-d3c9757d55cdb99a978579547b2f5cc6R105
>>
>>
>> why, that would be question for Scott.
>>
>> --
>> tomaz
>>
>>
>> On Mon, Jan 27, 2014 at 5:02 PM, Thomas Segismont <tsegismo at redhat.com
>> <mailto:tsegismo at redhat.com>> wrote:
>>
>>     Hi,
>>
>>     deployment/subsystem/jpa/hibernate-persistence-unit/query-cache nodes
>>     expose an "encoded" query name attribute. Here's an example:
>>
>>
>> "rhq.ear/rhq-core-domain-ejb3.jar#rhqpu.rhq.ear_divide_rhq_minus_core_minus_domain_minus_ejb3.jar#rhqpu.rhq.ear_divide_rhq_minus_core_minus_domain_minus_ejb3.jar#rhqpu.SELECT_space_subject_newline_FROM_space_Subject_space_subject_newline_WHERE_space__left_paren__space_LOWER_left_paren__space_subject.name_space__right_paren__space_like_space__colon_name_space_ESCAPE_space__quote_\\_quote__space__space__right_paren__newline_ORDER_space_BY_space_subject.id_space_ASC_newline_"
>>
>>
>>     I could write something to decode every occurrence of "_minus_",
>>     "_space_" and so on, provided I can get the list of all the
>> keywords in
>>     use. But I wonder if there's already a library in the Hibernate
>>     subsystem which does that.
>>
>>     By the way, these nodes exist in AS7 and EAP6, but I found no
>> equivalent
>>     in Wildfly management model. Did I miss the definition on the
>> Wildscribe
>>     site?
>>
>>
>> http://wildscribe.github.io/JBoss%20AS7/7.1.1/deployment/subsystem/jpa/hibernate-persistence-unit/query-cache/index.html
>>
>>
>>     Thanks,
>>     Thomas
>>     _______________________________________________
>>     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
>>
>

Thanks,
Thomas

From tomaz.cerar at gmail.com  Mon Jan 27 12:12:37 2014
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Mon, 27 Jan 2014 18:12:37 +0100
Subject: [wildfly-dev] Decoding query name attribute in
 deployment/subsystem/jpa/hibernate-persistence-unit/query-cache nodes
In-Reply-To: <52E69015.5010703@redhat.com>
References: <52E68316.8090709@redhat.com>
	<CAMquZP7inAccG-_Q0VLpAJ4qimNuggnxzXWZW-hBAXdQS9HVsQ@mail.gmail.com>
	<52E69015.5010703@redhat.com>
Message-ID: <CAMquZP5HAWh0rLGM1r=fuVvRVgtbQwDc-CSVdFpuhhUf4nokZQ@mail.gmail.com>

On Mon, Jan 27, 2014 at 5:57 PM, Scott Marlow <smarlow at redhat.com> wrote:

> In WildFly 8, the code moved to the Jipijapa project.



This does not explain why deployment resources are not present / registered
anymore.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140127/7a8d8daa/attachment.html 

From smarlow at redhat.com  Mon Jan 27 12:25:50 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Mon, 27 Jan 2014 12:25:50 -0500
Subject: [wildfly-dev] Decoding query name attribute in
 deployment/subsystem/jpa/hibernate-persistence-unit/query-cache nodes
In-Reply-To: <CAMquZP5HAWh0rLGM1r=fuVvRVgtbQwDc-CSVdFpuhhUf4nokZQ@mail.gmail.com>
References: <52E68316.8090709@redhat.com>	<CAMquZP7inAccG-_Q0VLpAJ4qimNuggnxzXWZW-hBAXdQS9HVsQ@mail.gmail.com>	<52E69015.5010703@redhat.com>
	<CAMquZP5HAWh0rLGM1r=fuVvRVgtbQwDc-CSVdFpuhhUf4nokZQ@mail.gmail.com>
Message-ID: <52E6969E.4060702@redhat.com>

On 01/27/2014 12:12 PM, Toma? Cerar wrote:
>
> On Mon, Jan 27, 2014 at 5:57 PM, Scott Marlow <smarlow at redhat.com
> <mailto:smarlow at redhat.com>> wrote:
>
>     In WildFly 8, the code moved to the Jipijapa project.
>
>
>
> This does not explain why deployment resources are not present /
> registered anymore.

I'll take a look.

From tsegismo at redhat.com  Mon Jan 27 12:44:58 2014
From: tsegismo at redhat.com (Thomas Segismont)
Date: Mon, 27 Jan 2014 18:44:58 +0100
Subject: [wildfly-dev] Decoding query name attribute in
 deployment/subsystem/jpa/hibernate-persistence-unit/query-cache nodes
In-Reply-To: <52E69302.3090709@redhat.com>
References: <52E68316.8090709@redhat.com>	<CAMquZP7inAccG-_Q0VLpAJ4qimNuggnxzXWZW-hBAXdQS9HVsQ@mail.gmail.com>	<52E69015.5010703@redhat.com>
	<52E69302.3090709@redhat.com>
Message-ID: <52E69B1A.5040008@redhat.com>

Le 27/01/2014 18:10, Thomas Segismont a ?crit :
>> >
>> >Why are you trying to decode the query back into its original (internal
>> >Hibernate) form?  Which project are you trying to do this for?
> I'm trying to decode the name to show the query statistics in RHQ. I
> wish there was an attribute in the node with the plain query string.
> That would be a nice add in Wildfly, but for RHQ to work with already
> released versions of AS7 and EAP6, there's no other way...
>

Scott,

I want to file a JIRA about a new attribute showing the plain query 
string, should it be against WILDFLY or JIPI?

Thanks,
Thomas

From smarlow at redhat.com  Mon Jan 27 12:46:46 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Mon, 27 Jan 2014 12:46:46 -0500
Subject: [wildfly-dev] Decoding query name attribute in
 deployment/subsystem/jpa/hibernate-persistence-unit/query-cache nodes
In-Reply-To: <52E6969E.4060702@redhat.com>
References: <52E68316.8090709@redhat.com>	<CAMquZP7inAccG-_Q0VLpAJ4qimNuggnxzXWZW-hBAXdQS9HVsQ@mail.gmail.com>	<52E69015.5010703@redhat.com>	<CAMquZP5HAWh0rLGM1r=fuVvRVgtbQwDc-CSVdFpuhhUf4nokZQ@mail.gmail.com>
	<52E6969E.4060702@redhat.com>
Message-ID: <52E69B86.3080700@redhat.com>

On 01/27/2014 12:25 PM, Scott Marlow wrote:
> On 01/27/2014 12:12 PM, Toma? Cerar wrote:
>>
>> On Mon, Jan 27, 2014 at 5:57 PM, Scott Marlow <smarlow at redhat.com
>> <mailto:smarlow at redhat.com>> wrote:
>>
>>      In WildFly 8, the code moved to the Jipijapa project.
>>
>>
>>
>> This does not explain why deployment resources are not present /
>> registered anymore.
>
> I'll take a look.

I deployed a test from another issue and am able to change into 
/deployment=jmxp.ear.ear/subdeployment=jmxp.ejb.jar/subsystem=jpa/hibernate-persistence-unit=jmxp.ear.ear/jmxp.ejb.jar#fraudPU/query-cache 
and doing an "ls" shows:

SELECT_space_m_space_FROM_space_Message_space_m

SELECT_space_m_space_FROM_space_Message_space_m_space_where_space_m.reliable_space__equal__space__quote_y_quote_

If these queries didn't exist, I wouldn't see them but otherwise I don't 
see the problem.

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


From tsegismo at redhat.com  Mon Jan 27 12:51:59 2014
From: tsegismo at redhat.com (Thomas Segismont)
Date: Mon, 27 Jan 2014 18:51:59 +0100
Subject: [wildfly-dev] Decoding query name attribute in
 deployment/subsystem/jpa/hibernate-persistence-unit/query-cache nodes
In-Reply-To: <52E69B86.3080700@redhat.com>
References: <52E68316.8090709@redhat.com>	<CAMquZP7inAccG-_Q0VLpAJ4qimNuggnxzXWZW-hBAXdQS9HVsQ@mail.gmail.com>	<52E69015.5010703@redhat.com>	<CAMquZP5HAWh0rLGM1r=fuVvRVgtbQwDc-CSVdFpuhhUf4nokZQ@mail.gmail.com>	<52E6969E.4060702@redhat.com>
	<52E69B86.3080700@redhat.com>
Message-ID: <52E69CBF.3090700@redhat.com>

Le 27/01/2014 18:46, Scott Marlow a ?crit :
> On 01/27/2014 12:25 PM, Scott Marlow wrote:
>> On 01/27/2014 12:12 PM, Toma? Cerar wrote:
>>>
>>> On Mon, Jan 27, 2014 at 5:57 PM, Scott Marlow <smarlow at redhat.com
>>> <mailto:smarlow at redhat.com>> wrote:
>>>
>>>       In WildFly 8, the code moved to the Jipijapa project.
>>>
>>>
>>>
>>> This does not explain why deployment resources are not present /
>>> registered anymore.
>>
>> I'll take a look.
>
> I deployed a test from another issue and am able to change into
> /deployment=jmxp.ear.ear/subdeployment=jmxp.ejb.jar/subsystem=jpa/hibernate-persistence-unit=jmxp.ear.ear/jmxp.ejb.jar#fraudPU/query-cache
> and doing an "ls" shows:
>
> SELECT_space_m_space_FROM_space_Message_space_m
>
> SELECT_space_m_space_FROM_space_Message_space_m_space_where_space_m.reliable_space__equal__space__quote_y_quote_
>
> If these queries didn't exist, I wouldn't see them but otherwise I don't
> see the problem.
>

Good news. Still why the "Hibernate Persistence Unit" description does 
not appear on Wildscribe site?

http://wildscribe.github.io/Wildfly/8.0.0.CR1/deployment/subsystem/jpa/index.html

It does appear in EAP6.2 model:

http://wildscribe.github.io/JBoss%20EAP/6.2.0/deployment/subsystem/jpa/index.html


From smarlow at redhat.com  Mon Jan 27 12:53:33 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Mon, 27 Jan 2014 12:53:33 -0500
Subject: [wildfly-dev] Decoding query name attribute in
 deployment/subsystem/jpa/hibernate-persistence-unit/query-cache nodes
In-Reply-To: <52E69B1A.5040008@redhat.com>
References: <52E68316.8090709@redhat.com>	<CAMquZP7inAccG-_Q0VLpAJ4qimNuggnxzXWZW-hBAXdQS9HVsQ@mail.gmail.com>	<52E69015.5010703@redhat.com>	<52E69302.3090709@redhat.com>
	<52E69B1A.5040008@redhat.com>
Message-ID: <52E69D1D.3050809@redhat.com>

On 01/27/2014 12:44 PM, Thomas Segismont wrote:
> Le 27/01/2014 18:10, Thomas Segismont a ?crit :
>>>>
>>>> Why are you trying to decode the query back into its original (internal
>>>> Hibernate) form?  Which project are you trying to do this for?
>> I'm trying to decode the name to show the query statistics in RHQ. I
>> wish there was an attribute in the node with the plain query string.
>> That would be a nice add in Wildfly, but for RHQ to work with already
>> released versions of AS7 and EAP6, there's no other way...
>>
>
> Scott,
>
> I want to file a JIRA about a new attribute showing the plain query
> string, should it be against WILDFLY or JIPI?

I'm not sure.  If I didn't translate the query as I did, it wouldn't be 
displayable in the jboss-cli tool.


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


From smarlow at redhat.com  Mon Jan 27 14:35:46 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Mon, 27 Jan 2014 14:35:46 -0500
Subject: [wildfly-dev] Decoding query name attribute in
 deployment/subsystem/jpa/hibernate-persistence-unit/query-cache nodes
In-Reply-To: <52E69302.3090709@redhat.com>
References: <52E68316.8090709@redhat.com>	<CAMquZP7inAccG-_Q0VLpAJ4qimNuggnxzXWZW-hBAXdQS9HVsQ@mail.gmail.com>	<52E69015.5010703@redhat.com>
	<52E69302.3090709@redhat.com>
Message-ID: <52E6B512.1010501@redhat.com>

On 01/27/2014 12:10 PM, Thomas Segismont wrote:
> I'm trying to decode the name to show the query statistics in RHQ. I
> wish there was an attribute in the node with the plain query string.
> That would be a nice add in Wildfly, but for RHQ to work with already
> released versions of AS7 and EAP6, there's no other way...

Currently, the plain query string would cause an (Dynamic Model 
Representation) exception to be thrown, as it could contain illegal 
characters sequences.


From brian.stansberry at redhat.com  Mon Jan 27 14:49:23 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 27 Jan 2014 13:49:23 -0600
Subject: [wildfly-dev] Decoding query name attribute in
 deployment/subsystem/jpa/hibernate-persistence-unit/query-cache nodes
In-Reply-To: <52E6B512.1010501@redhat.com>
References: <52E68316.8090709@redhat.com>	<CAMquZP7inAccG-_Q0VLpAJ4qimNuggnxzXWZW-hBAXdQS9HVsQ@mail.gmail.com>	<52E69015.5010703@redhat.com>	<52E69302.3090709@redhat.com>
	<52E6B512.1010501@redhat.com>
Message-ID: <52E6B843.8020005@redhat.com>

On 1/27/14, 1:35 PM, Scott Marlow wrote:
> On 01/27/2014 12:10 PM, Thomas Segismont wrote:
>> I'm trying to decode the name to show the query statistics in RHQ. I
>> wish there was an attribute in the node with the plain query string.
>> That would be a nice add in Wildfly, but for RHQ to work with already
>> released versions of AS7 and EAP6, there's no other way...
>
> Currently, the plain query string would cause an (Dynamic Model
> Representation) exception to be thrown, as it could contain illegal
> characters sequences.
>

In an attribute?

PathAddress has rules, but an attribute of ModelType.STRING should be 
able to store arbitrary text.

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


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From smarlow at redhat.com  Mon Jan 27 14:54:49 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Mon, 27 Jan 2014 14:54:49 -0500
Subject: [wildfly-dev] Decoding query name attribute in
 deployment/subsystem/jpa/hibernate-persistence-unit/query-cache nodes
In-Reply-To: <52E6B843.8020005@redhat.com>
References: <52E68316.8090709@redhat.com>	<CAMquZP7inAccG-_Q0VLpAJ4qimNuggnxzXWZW-hBAXdQS9HVsQ@mail.gmail.com>	<52E69015.5010703@redhat.com>	<52E69302.3090709@redhat.com>	<52E6B512.1010501@redhat.com>
	<52E6B843.8020005@redhat.com>
Message-ID: <52E6B989.5000000@redhat.com>

On 01/27/2014 02:49 PM, Brian Stansberry wrote:
> On 1/27/14, 1:35 PM, Scott Marlow wrote:
>> On 01/27/2014 12:10 PM, Thomas Segismont wrote:
>>> I'm trying to decode the name to show the query statistics in RHQ. I
>>> wish there was an attribute in the node with the plain query string.
>>> That would be a nice add in Wildfly, but for RHQ to work with already
>>> released versions of AS7 and EAP6, there's no other way...
>>
>> Currently, the plain query string would cause an (Dynamic Model
>> Representation) exception to be thrown, as it could contain illegal
>> characters sequences.
>>
>
> In an attribute?
>
> PathAddress has rules, but an attribute of ModelType.STRING should be
> able to store arbitrary text.

In the PathAddress.  for example:

cd 
SELECT_space_m_space_FROM_space_Message_space_m_space_where_space_m.reliable_space__equal__space__quote_y_quote_

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


From tsegismo at redhat.com  Mon Jan 27 15:01:52 2014
From: tsegismo at redhat.com (Thomas Segismont)
Date: Mon, 27 Jan 2014 21:01:52 +0100
Subject: [wildfly-dev] Decoding query name attribute in
 deployment/subsystem/jpa/hibernate-persistence-unit/query-cache nodes
In-Reply-To: <52E6B989.5000000@redhat.com>
References: <52E68316.8090709@redhat.com>	<CAMquZP7inAccG-_Q0VLpAJ4qimNuggnxzXWZW-hBAXdQS9HVsQ@mail.gmail.com>	<52E69015.5010703@redhat.com>	<52E69302.3090709@redhat.com>	<52E6B512.1010501@redhat.com>	<52E6B843.8020005@redhat.com>
	<52E6B989.5000000@redhat.com>
Message-ID: <52E6BB30.7010401@redhat.com>

Le 27/01/2014 20:54, Scott Marlow a ?crit :
>> In an attribute?
>> >
>> >PathAddress has rules, but an attribute of ModelType.STRING should be
>> >able to store arbitrary text.
> In the PathAddress.  for example:
>
> cd
> SELECT_space_m_space_FROM_space_Message_space_m_space_where_space_m.reliable_space__equal__space__quote_y_quote_
>

The JIRA I want to file is actually about adding an attribute.

WILDFLY or JIPI?

From smarlow at redhat.com  Mon Jan 27 15:06:59 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Mon, 27 Jan 2014 15:06:59 -0500
Subject: [wildfly-dev] Decoding query name attribute in
 deployment/subsystem/jpa/hibernate-persistence-unit/query-cache nodes
In-Reply-To: <52E6B989.5000000@redhat.com>
References: <52E68316.8090709@redhat.com>	<CAMquZP7inAccG-_Q0VLpAJ4qimNuggnxzXWZW-hBAXdQS9HVsQ@mail.gmail.com>	<52E69015.5010703@redhat.com>	<52E69302.3090709@redhat.com>	<52E6B512.1010501@redhat.com>	<52E6B843.8020005@redhat.com>
	<52E6B989.5000000@redhat.com>
Message-ID: <52E6BC63.5030701@redhat.com>

On 01/27/2014 02:54 PM, Scott Marlow wrote:
> On 01/27/2014 02:49 PM, Brian Stansberry wrote:
>> On 1/27/14, 1:35 PM, Scott Marlow wrote:
>>> On 01/27/2014 12:10 PM, Thomas Segismont wrote:
>>>> I'm trying to decode the name to show the query statistics in RHQ. I
>>>> wish there was an attribute in the node with the plain query string.
>>>> That would be a nice add in Wildfly, but for RHQ to work with already
>>>> released versions of AS7 and EAP6, there's no other way...
>>>
>>> Currently, the plain query string would cause an (Dynamic Model
>>> Representation) exception to be thrown, as it could contain illegal
>>> characters sequences.
>>>
>>
>> In an attribute?
>>
>> PathAddress has rules, but an attribute of ModelType.STRING should be
>> able to store arbitrary text.
>
> In the PathAddress.  for example:
>
> cd
> SELECT_space_m_space_FROM_space_Message_space_m_space_where_space_m.reliable_space__equal__space__quote_y_quote_

Before translation, the PathAddress would of been:

SELECT m FROM Message m where m.reliable = 'y'

>
>>
>>> _______________________________________________
>>> 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  Mon Jan 27 15:16:21 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Mon, 27 Jan 2014 15:16:21 -0500
Subject: [wildfly-dev] Decoding query name attribute in
 deployment/subsystem/jpa/hibernate-persistence-unit/query-cache nodes
In-Reply-To: <52E6BB30.7010401@redhat.com>
References: <52E68316.8090709@redhat.com>	<CAMquZP7inAccG-_Q0VLpAJ4qimNuggnxzXWZW-hBAXdQS9HVsQ@mail.gmail.com>	<52E69015.5010703@redhat.com>	<52E69302.3090709@redhat.com>	<52E6B512.1010501@redhat.com>	<52E6B843.8020005@redhat.com>	<52E6B989.5000000@redhat.com>
	<52E6BB30.7010401@redhat.com>
Message-ID: <52E6BE95.4070602@redhat.com>

On 01/27/2014 03:01 PM, Thomas Segismont wrote:
> Le 27/01/2014 20:54, Scott Marlow a ?crit :
>>> In an attribute?
>>>>
>>>> PathAddress has rules, but an attribute of ModelType.STRING should be
>>>> able to store arbitrary text.
>> In the PathAddress.  for example:
>>
>> cd
>> SELECT_space_m_space_FROM_space_Message_space_m_space_where_space_m.reliable_space__equal__space__quote_y_quote_
>>
>
> The JIRA I want to file is actually about adding an attribute.
>
> WILDFLY or JIPI?

Thomas,

Do you want to add another attribute within the 
SELECT_space_m_space_FROM_space_Message_space_m_space_where_space_m.reliable_space__equal__space__quote_y_quote_?

Or at a higher level?

Currently, for this test application that I deployed, the path to the 
query cache entries is:

/deployment=jmxp.ear.ear/subdeployment=jmxp.ejb.jar/subsystem=jpa/hibernate-persistence-unit=jmxp.ear.ear/jmxp.ejb.jar#fraudPU/query-cache 
which contains two PathAddress entries:

SELECT_space_m_space_FROM_space_Message_space_m
SELECT_space_m_space_FROM_space_Message_space_m_space_where_space_m.reliable_space__equal__space__quote_y_quote_

Scott

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


From tsegismo at redhat.com  Mon Jan 27 15:26:00 2014
From: tsegismo at redhat.com (Thomas Segismont)
Date: Mon, 27 Jan 2014 21:26:00 +0100
Subject: [wildfly-dev] Decoding query name attribute in
 deployment/subsystem/jpa/hibernate-persistence-unit/query-cache nodes
In-Reply-To: <52E6BE95.4070602@redhat.com>
References: <52E68316.8090709@redhat.com>	<CAMquZP7inAccG-_Q0VLpAJ4qimNuggnxzXWZW-hBAXdQS9HVsQ@mail.gmail.com>	<52E69015.5010703@redhat.com>	<52E69302.3090709@redhat.com>	<52E6B512.1010501@redhat.com>	<52E6B843.8020005@redhat.com>	<52E6B989.5000000@redhat.com>
	<52E6BB30.7010401@redhat.com> <52E6BE95.4070602@redhat.com>
Message-ID: <52E6C0D8.9010800@redhat.com>

Le 27/01/2014 21:16, Scott Marlow a ?crit :
> On 01/27/2014 03:01 PM, Thomas Segismont wrote:
>> Le 27/01/2014 20:54, Scott Marlow a ?crit :
>>>> In an attribute?
>>>>>
>>>>> PathAddress has rules, but an attribute of ModelType.STRING should be
>>>>> able to store arbitrary text.
>>> In the PathAddress.  for example:
>>>
>>> cd
>>> SELECT_space_m_space_FROM_space_Message_space_m_space_where_space_m.reliable_space__equal__space__quote_y_quote_
>>>
>>>
>>
>> The JIRA I want to file is actually about adding an attribute.
>>
>> WILDFLY or JIPI?
>
> Thomas,
>
> Do you want to add another attribute within the
> SELECT_space_m_space_FROM_space_Message_space_m_space_where_space_m.reliable_space__equal__space__quote_y_quote_?
>
>
> Or at a higher level?
>
> Currently, for this test application that I deployed, the path to the
> query cache entries is:
>
> /deployment=jmxp.ear.ear/subdeployment=jmxp.ejb.jar/subsystem=jpa/hibernate-persistence-unit=jmxp.ear.ear/jmxp.ejb.jar#fraudPU/query-cache
> which contains two PathAddress entries:
>
> SELECT_space_m_space_FROM_space_Message_space_m
> SELECT_space_m_space_FROM_space_Message_space_m_space_where_space_m.reliable_space__equal__space__quote_y_quote_
>
>
> Scott
>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>

Yes, a new attribute in "query-cache" nodes, named "query-string", 
sibling of "query-cache-hit-count", "query-cache-miss-count", 
"query-execution-average-time" ... etc



From smarlow at redhat.com  Mon Jan 27 16:44:23 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Mon, 27 Jan 2014 16:44:23 -0500
Subject: [wildfly-dev] Decoding query name attribute in
 deployment/subsystem/jpa/hibernate-persistence-unit/query-cache nodes
In-Reply-To: <52E6C0D8.9010800@redhat.com>
References: <52E68316.8090709@redhat.com>	<CAMquZP7inAccG-_Q0VLpAJ4qimNuggnxzXWZW-hBAXdQS9HVsQ@mail.gmail.com>	<52E69015.5010703@redhat.com>	<52E69302.3090709@redhat.com>	<52E6B512.1010501@redhat.com>	<52E6B843.8020005@redhat.com>	<52E6B989.5000000@redhat.com>
	<52E6BB30.7010401@redhat.com> <52E6BE95.4070602@redhat.com>
	<52E6C0D8.9010800@redhat.com>
Message-ID: <52E6D337.3010909@redhat.com>

On 01/27/2014 03:26 PM, Thomas Segismont wrote:
> Yes, a new attribute in "query-cache" nodes, named "query-string",
> sibling of "query-cache-hit-count", "query-cache-miss-count",
> "query-execution-average-time" ... etc

Sure, that should be doable.  The upstream jira should be in 
https://issues.jboss.org/browse/JIPI.

From bburke at redhat.com  Mon Jan 27 17:22:50 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 27 Jan 2014 17:22:50 -0500
Subject: [wildfly-dev] access to mgmt api/services
Message-ID: <52E6DC3A.6010504@redhat.com>

Is there an example somewhere of getting access to the mgmt api from a 
deployed servlet app? I'd like to be able to manage subsystem 
configuration and store it (within standalone.xml or whatever).

Also, what is the best practice for managing in-VM services that are 
shared between deployments (specifically services shared between web 
deployments)?
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From mazz at redhat.com  Mon Jan 27 17:40:23 2014
From: mazz at redhat.com (John Mazzitelli)
Date: Mon, 27 Jan 2014 17:40:23 -0500 (EST)
Subject: [wildfly-dev] access to mgmt api/services
In-Reply-To: <52E6DC3A.6010504@redhat.com>
References: <52E6DC3A.6010504@redhat.com>
Message-ID: <1561139815.7485397.1390862423582.JavaMail.root@redhat.com>

> Is there an example somewhere of getting access to the mgmt api from a
> deployed servlet app? I'd like to be able to manage subsystem
> configuration and store it (within standalone.xml or whatever).

You can take a look at RHQ's DMR client library. It was written to be a generic DMR client to access the mgmt API.

https://git.fedorahosted.org/cgit/rhq/rhq.git/tree/modules/common/jboss-as-dmr-client/src/main/java/org/rhq/common/jbossas/client/controller

Obtain a ModelControllerClient "somehow" (see MCCHelper, for example) and pass it to the constructor for the different types of clients (DatasourceJBossASClient, CoreJBossASClient, SecurityDomainJBossASClient, etc, etc)

Then there is my blog from 2012 that talks about getting a co-located ModelControllerClient that may be of help:

http://management-platform.blogspot.com/2012/07/co-located-management-client-for.html

Anyway, the code in those places can serve as examples that you are asking for. We do use these from within servlets and EJBs running in EAP 6.

From bburke at redhat.com  Mon Jan 27 17:45:24 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 27 Jan 2014 17:45:24 -0500
Subject: [wildfly-dev] access to mgmt api/services
In-Reply-To: <1561139815.7485397.1390862423582.JavaMail.root@redhat.com>
References: <52E6DC3A.6010504@redhat.com>
	<1561139815.7485397.1390862423582.JavaMail.root@redhat.com>
Message-ID: <52E6E184.1070507@redhat.com>



On 1/27/2014 5:40 PM, John Mazzitelli wrote:
>> Is there an example somewhere of getting access to the mgmt api from a
>> deployed servlet app? I'd like to be able to manage subsystem
>> configuration and store it (within standalone.xml or whatever).
>
> You can take a look at RHQ's DMR client library. It was written to be a generic DMR client to access the mgmt API.
>
> https://git.fedorahosted.org/cgit/rhq/rhq.git/tree/modules/common/jboss-as-dmr-client/src/main/java/org/rhq/common/jbossas/client/controller
>
> Obtain a ModelControllerClient "somehow" (see MCCHelper, for example) and pass it to the constructor for the different types of clients (DatasourceJBossASClient, CoreJBossASClient, SecurityDomainJBossASClient, etc, etc)
>
> Then there is my blog from 2012 that talks about getting a co-located ModelControllerClient that may be of help:
>
> http://management-platform.blogspot.com/2012/07/co-located-management-client-for.html
>
> Anyway, the code in those places can serve as examples that you are asking for. We do use these from within servlets and EJBs running in EAP 6.
>

Thanks for the links!

What about sharing a "service" between different applications?  i.e. a 
shared service like the TxMgr.

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

From jason.greene at redhat.com  Mon Jan 27 18:02:56 2014
From: jason.greene at redhat.com (Jason Greene)
Date: Mon, 27 Jan 2014 17:02:56 -0600
Subject: [wildfly-dev] access to mgmt api/services
In-Reply-To: <1561139815.7485397.1390862423582.JavaMail.root@redhat.com>
References: <52E6DC3A.6010504@redhat.com>
	<1561139815.7485397.1390862423582.JavaMail.root@redhat.com>
Message-ID: <E64B7C40-8CEA-4ABD-BFF9-AFE8B4186B9A@redhat.com>


On Jan 27, 2014, at 4:40 PM, John Mazzitelli <mazz at redhat.com> wrote:

>> Is there an example somewhere of getting access to the mgmt api from a
>> deployed servlet app? I'd like to be able to manage subsystem
>> configuration and store it (within standalone.xml or whatever).
> 
> You can take a look at RHQ's DMR client library. It was written to be a generic DMR client to access the mgmt API.
> 
> https://git.fedorahosted.org/cgit/rhq/rhq.git/tree/modules/common/jboss-as-dmr-client/src/main/java/org/rhq/common/jbossas/client/controller
> 
> Obtain a ModelControllerClient "somehow" (see MCCHelper, for example) and pass it to the constructor for the different types of clients (DatasourceJBossASClient, CoreJBossASClient, SecurityDomainJBossASClient, etc, etc)
> 
> Then there is my blog from 2012 that talks about getting a co-located ModelControllerClient that may be of help:
> 
> http://management-platform.blogspot.com/2012/07/co-located-management-client-for.html
> 
> Anyway, the code in those places can serve as examples that you are asking for. We do use these from within servlets and EJBs running in EAP 6.

There are some caveats to this though:

1. You can?t make a management call during the call patch of deployment (servlet initializers etc), since deployment itself is part of a management call, and thus you will deadlock trying to start a parallel modification (until the op triggering the deployment times out). A runtime thread is fine though.

2. You won?t get responses on things which impact your deployment or the servlet container (e.g. redeploying yourself or downing the container)

3. Role based access control is defeated, all management ops will appear to come from the container itself.

4. Due to 3 if someone is running WildFly under a security manager you will need permissions


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



From jason.greene at redhat.com  Mon Jan 27 18:07:34 2014
From: jason.greene at redhat.com (Jason Greene)
Date: Mon, 27 Jan 2014 17:07:34 -0600
Subject: [wildfly-dev] access to mgmt api/services
In-Reply-To: <52E6DC3A.6010504@redhat.com>
References: <52E6DC3A.6010504@redhat.com>
Message-ID: <D9C805C0-717F-4D29-B8A0-6120AB5F10E6@redhat.com>


On Jan 27, 2014, at 4:22 PM, Bill Burke <bburke at redhat.com> wrote:

> Is there an example somewhere of getting access to the mgmt api from a 
> deployed servlet app? I'd like to be able to manage subsystem 
> configuration and store it (within standalone.xml or whatever).
> 
> Also, what is the best practice for managing in-VM services that are 
> shared between deployments (specifically services shared between web 
> deployments)?

Singleton EJBs and @EJB references is the simplest. Although you could also use MSC services. Either case
means you have to deploy things together (e.g. in the same deploy operation, or part of boot) or if separate they have to be in the right order.

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



From bburke at redhat.com  Mon Jan 27 18:15:26 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 27 Jan 2014 18:15:26 -0500
Subject: [wildfly-dev] access to mgmt api/services
In-Reply-To: <E64B7C40-8CEA-4ABD-BFF9-AFE8B4186B9A@redhat.com>
References: <52E6DC3A.6010504@redhat.com>
	<1561139815.7485397.1390862423582.JavaMail.root@redhat.com>
	<E64B7C40-8CEA-4ABD-BFF9-AFE8B4186B9A@redhat.com>
Message-ID: <52E6E88E.2020006@redhat.com>



On 1/27/2014 6:02 PM, Jason Greene wrote:
>
> On Jan 27, 2014, at 4:40 PM, John Mazzitelli <mazz at redhat.com> wrote:
>
>>> Is there an example somewhere of getting access to the mgmt api from a
>>> deployed servlet app? I'd like to be able to manage subsystem
>>> configuration and store it (within standalone.xml or whatever).
>>
>> You can take a look at RHQ's DMR client library. It was written to be a generic DMR client to access the mgmt API.
>>
>> https://git.fedorahosted.org/cgit/rhq/rhq.git/tree/modules/common/jboss-as-dmr-client/src/main/java/org/rhq/common/jbossas/client/controller
>>
>> Obtain a ModelControllerClient "somehow" (see MCCHelper, for example) and pass it to the constructor for the different types of clients (DatasourceJBossASClient, CoreJBossASClient, SecurityDomainJBossASClient, etc, etc)
>>
>> Then there is my blog from 2012 that talks about getting a co-located ModelControllerClient that may be of help:
>>
>> http://management-platform.blogspot.com/2012/07/co-located-management-client-for.html
>>
>> Anyway, the code in those places can serve as examples that you are asking for. We do use these from within servlets and EJBs running in EAP 6.
>
> There are some caveats to this though:
>
> 1. You can?t make a management call during the call patch of deployment (servlet initializers etc), since deployment itself is part of a management call, and thus you will deadlock trying to start a parallel modification (until the op triggering the deployment times out). A runtime thread is fine though.
>
> 2. You won?t get responses on things which impact your deployment or the servlet container (e.g. redeploying yourself or downing the container)
>
> 3. Role based access control is defeated, all management ops will appear to come from the container itself.
>
> 4. Due to 3 if someone is running WildFly under a security manager you will need permissions
>

This is for bootstrap purposes for getting a Wildfly instance to join a 
Keycloak federation.  I want the Keycloak server to be able to send 
realm configuration information to a Wildfly instance (over HTTP(S)) 
that is joining the federation and have that instance store this 
information within a subsystem.  So, it is a one off service that 
happens after boot and may even be disabled afterwards.


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

From brian.stansberry at redhat.com  Mon Jan 27 19:59:47 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 27 Jan 2014 18:59:47 -0600
Subject: [wildfly-dev] access to mgmt api/services
In-Reply-To: <52E6E88E.2020006@redhat.com>
References: <52E6DC3A.6010504@redhat.com>	<1561139815.7485397.1390862423582.JavaMail.root@redhat.com>	<E64B7C40-8CEA-4ABD-BFF9-AFE8B4186B9A@redhat.com>
	<52E6E88E.2020006@redhat.com>
Message-ID: <52E70103.8000100@redhat.com>

On 1/27/14, 5:15 PM, Bill Burke wrote:
>
>
> On 1/27/2014 6:02 PM, Jason Greene wrote:
>>
>> On Jan 27, 2014, at 4:40 PM, John Mazzitelli <mazz at redhat.com> wrote:
>>
>>>> Is there an example somewhere of getting access to the mgmt api from a
>>>> deployed servlet app? I'd like to be able to manage subsystem
>>>> configuration and store it (within standalone.xml or whatever).
>>>
>>> You can take a look at RHQ's DMR client library. It was written to be a generic DMR client to access the mgmt API.
>>>
>>> https://git.fedorahosted.org/cgit/rhq/rhq.git/tree/modules/common/jboss-as-dmr-client/src/main/java/org/rhq/common/jbossas/client/controller
>>>
>>> Obtain a ModelControllerClient "somehow" (see MCCHelper, for example) and pass it to the constructor for the different types of clients (DatasourceJBossASClient, CoreJBossASClient, SecurityDomainJBossASClient, etc, etc)
>>>
>>> Then there is my blog from 2012 that talks about getting a co-located ModelControllerClient that may be of help:
>>>
>>> http://management-platform.blogspot.com/2012/07/co-located-management-client-for.html
>>>
>>> Anyway, the code in those places can serve as examples that you are asking for. We do use these from within servlets and EJBs running in EAP 6.
>>
>> There are some caveats to this though:
>>
>> 1. You can?t make a management call during the call patch of deployment (servlet initializers etc), since deployment itself is part of a management call, and thus you will deadlock trying to start a parallel modification (until the op triggering the deployment times out). A runtime thread is fine though.
>>
>> 2. You won?t get responses on things which impact your deployment or the servlet container (e.g. redeploying yourself or downing the container)
>>
>> 3. Role based access control is defeated, all management ops will appear to come from the container itself.
>>
>> 4. Due to 3 if someone is running WildFly under a security manager you will need permissions
>>
>
> This is for bootstrap purposes for getting a Wildfly instance to join a
> Keycloak federation.  I want the Keycloak server to be able to send
> realm configuration information to a Wildfly instance (over HTTP(S))
> that is joining the federation and have that instance store this
> information within a subsystem.  So, it is a one off service that
> happens after boot and may even be disabled afterwards.
>
>

This can't be done using the HTTP management interface?

-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From bburke at redhat.com  Mon Jan 27 21:48:01 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 27 Jan 2014 21:48:01 -0500
Subject: [wildfly-dev] access to mgmt api/services
In-Reply-To: <52E70103.8000100@redhat.com>
References: <52E6DC3A.6010504@redhat.com>	<1561139815.7485397.1390862423582.JavaMail.root@redhat.com>	<E64B7C40-8CEA-4ABD-BFF9-AFE8B4186B9A@redhat.com>	<52E6E88E.2020006@redhat.com>
	<52E70103.8000100@redhat.com>
Message-ID: <52E71A61.2050409@redhat.com>



On 1/27/2014 7:59 PM, Brian Stansberry wrote:
> On 1/27/14, 5:15 PM, Bill Burke wrote:
>>
>>
>> On 1/27/2014 6:02 PM, Jason Greene wrote:
>>>
>>> On Jan 27, 2014, at 4:40 PM, John Mazzitelli <mazz at redhat.com> wrote:
>>>
>>>>> Is there an example somewhere of getting access to the mgmt api from a
>>>>> deployed servlet app? I'd like to be able to manage subsystem
>>>>> configuration and store it (within standalone.xml or whatever).
>>>>
>>>> You can take a look at RHQ's DMR client library. It was written to be a generic DMR client to access the mgmt API.
>>>>
>>>> https://git.fedorahosted.org/cgit/rhq/rhq.git/tree/modules/common/jboss-as-dmr-client/src/main/java/org/rhq/common/jbossas/client/controller
>>>>
>>>> Obtain a ModelControllerClient "somehow" (see MCCHelper, for example) and pass it to the constructor for the different types of clients (DatasourceJBossASClient, CoreJBossASClient, SecurityDomainJBossASClient, etc, etc)
>>>>
>>>> Then there is my blog from 2012 that talks about getting a co-located ModelControllerClient that may be of help:
>>>>
>>>> http://management-platform.blogspot.com/2012/07/co-located-management-client-for.html
>>>>
>>>> Anyway, the code in those places can serve as examples that you are asking for. We do use these from within servlets and EJBs running in EAP 6.
>>>
>>> There are some caveats to this though:
>>>
>>> 1. You can?t make a management call during the call patch of deployment (servlet initializers etc), since deployment itself is part of a management call, and thus you will deadlock trying to start a parallel modification (until the op triggering the deployment times out). A runtime thread is fine though.
>>>
>>> 2. You won?t get responses on things which impact your deployment or the servlet container (e.g. redeploying yourself or downing the container)
>>>
>>> 3. Role based access control is defeated, all management ops will appear to come from the container itself.
>>>
>>> 4. Due to 3 if someone is running WildFly under a security manager you will need permissions
>>>
>>
>> This is for bootstrap purposes for getting a Wildfly instance to join a
>> Keycloak federation.  I want the Keycloak server to be able to send
>> realm configuration information to a Wildfly instance (over HTTP(S))
>> that is joining the federation and have that instance store this
>> information within a subsystem.  So, it is a one off service that
>> happens after boot and may even be disabled afterwards.
>>
>>
>
> This can't be done using the HTTP management interface?
>

After thinking a bit, I guess it could just use the HTTP mgmt intf. 
Thanks for your patience helping me work this out.

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

From emartins at redhat.com  Tue Jan 28 08:06:20 2014
From: emartins at redhat.com (Eduardo Martins)
Date: Tue, 28 Jan 2014 13:06:20 +0000
Subject: [wildfly-dev] Wildfly Quickstarts
Message-ID: <D9408698-B803-4966-9098-CBA9DC56F5FC@redhat.com>

I have been updating Wildfly Quickstarts, for now mostly reworking Maven POMs to use the updated dependencies, but it?s a long way to go, there are a lot of quickstarts, and no way all of these will be ready for primetime when WFLY 8 is out. So I was thinking in changing my strategy, and define a list with quickstarts of highest priority to be ready very soon. 

The quickstarts list can be seen at http://www.jboss.org/jdf/quickstarts/get-started/

May a person related to each Java EE spec/technology go through that list and help my build the priority list? My guess is that first priority is to have the ones that show off Java EE and Wildfly 8 features only, leaving the ones that show integration with other JBoss projects for a second release, but still this will be a big list so I definitely need help.

Also, we will need new Batch quickstart(s).

Thanks in advance.

?E



From rstryker at redhat.com  Tue Jan 28 08:36:15 2014
From: rstryker at redhat.com (Rob Stryker)
Date: Tue, 28 Jan 2014 21:36:15 +0800
Subject: [wildfly-dev] "It's The Final Countdown!"
In-Reply-To: <C380E806-0FAD-4A87-A2C0-90F357BFF9F7@redhat.com>
References: <C380E806-0FAD-4A87-A2C0-90F357BFF9F7@redhat.com>
Message-ID: <52E7B24F.20808@redhat.com>

Hey all:

On the recent call with JBossTools from your dev meeting, we were told 
we'd be pointed to a build that has the legacy port removed so we can 
verify everything works as expected.

Anyone have a link for a build that we can test?

On 01/22/2014 03:00 AM, Jason Greene wrote:
> No this isn?t the Europe song (Sorry to disappoint!).
>
> It is however the countdown to WildFly 8 Final release!
>
> The key things that remain are:
>
> 1) Final Components - We need PRs upgrading to ?Final? for all outstanding
> subcomponents[1]. If you own one of them, then please make this a high priority.
> The sooner the better.
>
> 2) Identify Blockers - We need to identify all remaining blockers that have been
> reported against CR1. I?m hoping everyone can look through the forms for likely
> blockers and convert them to JIRAs. As a reminder a blocker is anything that is
> mass user effecting and severe in nature. Examples include: hangs, crashes,
> memory leaks, vulnerabilities, and data corruption.
>
> 3) JASPIC Acceptance - A few of you on this list have noted issues. We need to
> ensure that the Final release has addressed the outstanding issues.
>
> Thanks!
>
> [1] Outstanding components.
>
> io.undertow 1.0.0.Beta30
> io.undertow.jastow 1.0.0.CR1
> org.glassfish.javax.el 3.0-b07
> org.hibernate.search 4.5.0.Alpha2 *exception*
> org.infinispan.protostream 1.0.0.CR1
> org.jberet 1.0.0.CR1
> org.jboss.ejb-client 2.0.0.Beta5
> org.jboss.narayana 5.0.0.CR2
> org.jboss.jsfunit 2.0.0.Beta1
> org.jboss.logging.jboss-logging-tools 1.2.0.Beta1
> org.jboss.metadata 8.0.0.CR1
> org.jboss.mod_cluster 1.3.0.Alpha1
> org.jboss.msc.jboss-msc 1.2.0.CR1
> org.jboss.xnio.netty.netty-xnio-transport 0.1.1.CR2
> org.jboss.remote-naming 2.0.0.Beta2
> org.jboss.remoting 4.0.0.Beta3
> org.jboss.remotingjmx.remoting-jmx 2.0.0.CR4
> org.jboss.sasl 1.0.4.CR1
> org.jboss.spec.javax.el.jboss-el-api_3.0_spec 1.0.0.Beta1
> org.jboss.spec.javax.security.auth.message.jboss-jaspi-api_1.1_spec 1.0.0.Alpha1
> org.jboss.spec.javax.security.jacc.jboss-jacc-api_1.5_spec 1.0.0.Beta1
> org.jboss.spec.javax.servlet.jsp.jboss-jsp-api_2.3_spec 1.0.0.Beta1
> org.jboss.spec.javax.servlet.jstl.jboss-jstl-api_1.2_spec 1.0.4.Beta1
> org.jboss.xnio 3.2.0.Beta4
> org.picketbox 4.0.20.Beta4
> org.wildfly.security.manager 1.0.0.Beta3
>
>
>
> --
> 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 Jan 28 10:29:51 2014
From: jason.greene at redhat.com (Jason Greene)
Date: Tue, 28 Jan 2014 09:29:51 -0600
Subject: [wildfly-dev] "It's The Final Countdown!"
In-Reply-To: <52E7B24F.20808@redhat.com>
References: <C380E806-0FAD-4A87-A2C0-90F357BFF9F7@redhat.com>
	<52E7B24F.20808@redhat.com>
Message-ID: <B0704CBA-CCC8-4141-B51A-6E8957E889CC@redhat.com>

It?s coming soon :)
On Jan 28, 2014, at 7:36 AM, Rob Stryker <rstryker at redhat.com> wrote:

> Hey all:
> 
> On the recent call with JBossTools from your dev meeting, we were told 
> we'd be pointed to a build that has the legacy port removed so we can 
> verify everything works as expected.
> 
> Anyone have a link for a build that we can test?
> 
> On 01/22/2014 03:00 AM, Jason Greene wrote:
>> No this isn?t the Europe song (Sorry to disappoint!).
>> 
>> It is however the countdown to WildFly 8 Final release!
>> 
>> The key things that remain are:
>> 
>> 1) Final Components - We need PRs upgrading to ?Final? for all outstanding
>> subcomponents[1]. If you own one of them, then please make this a high priority.
>> The sooner the better.
>> 
>> 2) Identify Blockers - We need to identify all remaining blockers that have been
>> reported against CR1. I?m hoping everyone can look through the forms for likely
>> blockers and convert them to JIRAs. As a reminder a blocker is anything that is
>> mass user effecting and severe in nature. Examples include: hangs, crashes,
>> memory leaks, vulnerabilities, and data corruption.
>> 
>> 3) JASPIC Acceptance - A few of you on this list have noted issues. We need to
>> ensure that the Final release has addressed the outstanding issues.
>> 
>> Thanks!
>> 
>> [1] Outstanding components.
>> 
>> io.undertow 1.0.0.Beta30
>> io.undertow.jastow 1.0.0.CR1
>> org.glassfish.javax.el 3.0-b07
>> org.hibernate.search 4.5.0.Alpha2 *exception*
>> org.infinispan.protostream 1.0.0.CR1
>> org.jberet 1.0.0.CR1
>> org.jboss.ejb-client 2.0.0.Beta5
>> org.jboss.narayana 5.0.0.CR2
>> org.jboss.jsfunit 2.0.0.Beta1
>> org.jboss.logging.jboss-logging-tools 1.2.0.Beta1
>> org.jboss.metadata 8.0.0.CR1
>> org.jboss.mod_cluster 1.3.0.Alpha1
>> org.jboss.msc.jboss-msc 1.2.0.CR1
>> org.jboss.xnio.netty.netty-xnio-transport 0.1.1.CR2
>> org.jboss.remote-naming 2.0.0.Beta2
>> org.jboss.remoting 4.0.0.Beta3
>> org.jboss.remotingjmx.remoting-jmx 2.0.0.CR4
>> org.jboss.sasl 1.0.4.CR1
>> org.jboss.spec.javax.el.jboss-el-api_3.0_spec 1.0.0.Beta1
>> org.jboss.spec.javax.security.auth.message.jboss-jaspi-api_1.1_spec 1.0.0.Alpha1
>> org.jboss.spec.javax.security.jacc.jboss-jacc-api_1.5_spec 1.0.0.Beta1
>> org.jboss.spec.javax.servlet.jsp.jboss-jsp-api_2.3_spec 1.0.0.Beta1
>> org.jboss.spec.javax.servlet.jstl.jboss-jstl-api_1.2_spec 1.0.4.Beta1
>> org.jboss.xnio 3.2.0.Beta4
>> org.picketbox 4.0.20.Beta4
>> org.wildfly.security.manager 1.0.0.Beta3
>> 
>> 
>> 
>> --
>> 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

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



From brian.stansberry at redhat.com  Tue Jan 28 15:37:38 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 28 Jan 2014 14:37:38 -0600
Subject: [wildfly-dev] Pull requests testing using IPv6
Message-ID: <52E81512.5080909@redhat.com>

Just an FYI, the CI job that tests github pull requests has been 
reconfigured to test using IPv6 addresses.

This is the way the PR testing was done for most of AS7. We've gotten 
away from it for a while but now we're switching back to help catch 
regressions or new tests that incorrectly assume IPv4.

The nightly build job still uses the IPv4 config, as do the 
"master-ignore" jobs we often run before merging sets of patches. So we 
have coverage both ways.

-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From tomaz.cerar at gmail.com  Tue Jan 28 17:38:08 2014
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Tue, 28 Jan 2014 23:38:08 +0100
Subject: [wildfly-dev] Wildfly Quickstarts
In-Reply-To: <D9408698-B803-4966-9098-CBA9DC56F5FC@redhat.com>
References: <D9408698-B803-4966-9098-CBA9DC56F5FC@redhat.com>
Message-ID: <CAMquZP4ye11m=T6mO7ON7KyMaF7cxQ9pO_2EPjXpcRo+Ab8DaQ@mail.gmail.com>

Aren't we updating quick starts here https://github.com/wildfly/quickstart ?
I thought that jdf ones ware mostly for EAP...

--
tomaz


On Tue, Jan 28, 2014 at 2:06 PM, Eduardo Martins <emartins at redhat.com>wrote:

> I have been updating Wildfly Quickstarts, for now mostly reworking Maven
> POMs to use the updated dependencies, but it?s a long way to go, there are
> a lot of quickstarts, and no way all of these will be ready for primetime
> when WFLY 8 is out. So I was thinking in changing my strategy, and define a
> list with quickstarts of highest priority to be ready very soon.
>
> The quickstarts list can be seen at
> http://www.jboss.org/jdf/quickstarts/get-started/
>
> May a person related to each Java EE spec/technology go through that list
> and help my build the priority list? My guess is that first priority is to
> have the ones that show off Java EE and Wildfly 8 features only, leaving
> the ones that show integration with other JBoss projects for a second
> release, but still this will be a big list so I definitely need help.
>
> Also, we will need new Batch quickstart(s).
>
> Thanks in advance.
>
> ?E
>
>
> _______________________________________________
> 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/20140128/2204bab3/attachment.html 

From emartins at redhat.com  Wed Jan 29 09:31:42 2014
From: emartins at redhat.com (Eduardo Martins)
Date: Wed, 29 Jan 2014 14:31:42 +0000
Subject: [wildfly-dev] Wildfly Quickstarts
In-Reply-To: <CAMquZP4ye11m=T6mO7ON7KyMaF7cxQ9pO_2EPjXpcRo+Ab8DaQ@mail.gmail.com>
References: <D9408698-B803-4966-9098-CBA9DC56F5FC@redhat.com>
	<CAMquZP4ye11m=T6mO7ON7KyMaF7cxQ9pO_2EPjXpcRo+Ab8DaQ@mail.gmail.com>
Message-ID: <0FD1F75A-9F01-436D-AD4F-73858666D5CD@redhat.com>

Those are the ones I?m working with, but afaik the JDF EAP ones are the same.

?E

On 28 Jan 2014, at 22:38, Toma? Cerar <tomaz.cerar at gmail.com> wrote:

> Aren't we updating quick starts here https://github.com/wildfly/quickstart ?
> I thought that jdf ones ware mostly for EAP...
> 
> --
> tomaz
> 
> 
> On Tue, Jan 28, 2014 at 2:06 PM, Eduardo Martins <emartins at redhat.com> wrote:
> I have been updating Wildfly Quickstarts, for now mostly reworking Maven POMs to use the updated dependencies, but it?s a long way to go, there are a lot of quickstarts, and no way all of these will be ready for primetime when WFLY 8 is out. So I was thinking in changing my strategy, and define a list with quickstarts of highest priority to be ready very soon.
> 
> The quickstarts list can be seen at http://www.jboss.org/jdf/quickstarts/get-started/
> 
> May a person related to each Java EE spec/technology go through that list and help my build the priority list? My guess is that first priority is to have the ones that show off Java EE and Wildfly 8 features only, leaving the ones that show integration with other JBoss projects for a second release, but still this will be a big list so I definitely need help.
> 
> Also, we will need new Batch quickstart(s).
> 
> Thanks in advance.
> 
> ?E
> 
> 
> _______________________________________________
> 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/20140129/f328de6d/attachment-0001.html 

From emartins at redhat.com  Wed Jan 29 09:31:42 2014
From: emartins at redhat.com (Eduardo Martins)
Date: Wed, 29 Jan 2014 14:31:42 +0000
Subject: [wildfly-dev] Wildfly Quickstarts
In-Reply-To: <CAMquZP4ye11m=T6mO7ON7KyMaF7cxQ9pO_2EPjXpcRo+Ab8DaQ@mail.gmail.com>
References: <D9408698-B803-4966-9098-CBA9DC56F5FC@redhat.com>
	<CAMquZP4ye11m=T6mO7ON7KyMaF7cxQ9pO_2EPjXpcRo+Ab8DaQ@mail.gmail.com>
Message-ID: <B63E885B-C986-4AC6-A873-2CD95345C0F9@redhat.com>

Those are the ones I?m working with, but afaik the JDF EAP ones are the same.

?E

On 28 Jan 2014, at 22:38, Toma? Cerar <tomaz.cerar at gmail.com> wrote:

> Aren't we updating quick starts here https://github.com/wildfly/quickstart ?
> I thought that jdf ones ware mostly for EAP...
> 
> --
> tomaz
> 
> 
> On Tue, Jan 28, 2014 at 2:06 PM, Eduardo Martins <emartins at redhat.com> wrote:
> I have been updating Wildfly Quickstarts, for now mostly reworking Maven POMs to use the updated dependencies, but it?s a long way to go, there are a lot of quickstarts, and no way all of these will be ready for primetime when WFLY 8 is out. So I was thinking in changing my strategy, and define a list with quickstarts of highest priority to be ready very soon.
> 
> The quickstarts list can be seen at http://www.jboss.org/jdf/quickstarts/get-started/
> 
> May a person related to each Java EE spec/technology go through that list and help my build the priority list? My guess is that first priority is to have the ones that show off Java EE and Wildfly 8 features only, leaving the ones that show integration with other JBoss projects for a second release, but still this will be a big list so I definitely need help.
> 
> Also, we will need new Batch quickstart(s).
> 
> Thanks in advance.
> 
> ?E
> 
> 
> _______________________________________________
> 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/20140129/d98b9824/attachment.html 

From Christopher.Klein at neos-it.de  Wed Jan 29 14:39:09 2014
From: Christopher.Klein at neos-it.de (Klein, Christopher)
Date: Wed, 29 Jan 2014 19:39:09 +0000
Subject: [wildfly-dev] Favour jboss-persistence.xml if present
Message-ID: <590E7374D74F224883CB3D49A8899E240CFA198C@EX1.neos-it.local>

Hey guys,
I already filled out a feature request in JIRA (https://issues.jboss.org/browse/WFLY-2816).

We have the situation that our development environment (currently JBoss AS 7.1.1) differs from the production instance (WebSphere 8.5). Our persistence.xml has to be adjusted for production environment: different jta-data-source, different properties. The dirty solution for this problem would be to generate separate build artifacts for both environments. As you can imagine I don't like the idea of having two binaries just because of a few different settings. Other options (WildFly or WebSphere specific JPA properties; extending Hibernate persistence provider) do not work.

A much nicer solution would be: WildFly checks on deployment process for the existence of a jboss-persistence.xml. If it does, the jboss-persistence.xml is used for configuring the JPA subsystem. Otherwise it falls back to the standard persistence.xml. The jboss-persistence.xml would use the XML schema from persistence.xml.

I lookup into the WildFly sources and this change should be an easy patch which I would provide.

So here are my questsions:
1. Are you generally interested in accepting such a pull request or is it a feature you don't want?
2. Does another solution exists to my problem apart from generating different artifacts which makes this pull request needless?

Greetings from Wolfsburg/Germany,
Christopher

From david.lloyd at redhat.com  Wed Jan 29 14:43:00 2014
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Wed, 29 Jan 2014 13:43:00 -0600
Subject: [wildfly-dev] Interoperability testing
Message-ID: <52E959C4.1080302@redhat.com>

Folks, we need some solution for interoperability testing between 
WildFly versions.  Something CI-based would be ideal - remember the old 
jboss-test stuff that could test multiple versions of things?  Something 
like that but updated for modularity and/or in-container execution and 
Maven support seems to be indicated.

We'd want to test interop between the current release and each previous 
Final release.  Anyone have any ideas or is willing to tackle such a beast?

-- 
- DML

From david.lloyd at redhat.com  Wed Jan 29 14:44:46 2014
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Wed, 29 Jan 2014 13:44:46 -0600
Subject: [wildfly-dev] Favour jboss-persistence.xml if present
In-Reply-To: <590E7374D74F224883CB3D49A8899E240CFA198C@EX1.neos-it.local>
References: <590E7374D74F224883CB3D49A8899E240CFA198C@EX1.neos-it.local>
Message-ID: <52E95A2E.4000607@redhat.com>

On 01/29/2014 01:39 PM, Klein, Christopher wrote:
> Hey guys,
> I already filled out a feature request in JIRA (https://issues.jboss.org/browse/WFLY-2816).
>
> We have the situation that our development environment (currently JBoss AS 7.1.1) differs from the production instance (WebSphere 8.5). Our persistence.xml has to be adjusted for production environment: different jta-data-source, different properties. The dirty solution for this problem would be to generate separate build artifacts for both environments. As you can imagine I don't like the idea of having two binaries just because of a few different settings. Other options (WildFly or WebSphere specific JPA properties; extending Hibernate persistence provider) do not work.
>
> A much nicer solution would be: WildFly checks on deployment process for the existence of a jboss-persistence.xml. If it does, the jboss-persistence.xml is used for configuring the JPA subsystem. Otherwise it falls back to the standard persistence.xml. The jboss-persistence.xml would use the XML schema from persistence.xml.
>
> I lookup into the WildFly sources and this change should be an easy patch which I would provide.
>
> So here are my questsions:
> 1. Are you generally interested in accepting such a pull request or is it a feature you don't want?
> 2. Does another solution exists to my problem apart from generating different artifacts which makes this pull request needless?

It sounds like a reasonable idea that actually applies generally.  If I 
recall correctly, we have something of a mix today of descriptors which 
override versus supplementing existing configuration.  But overall the 
unofficial policy for new descriptors has been to add them in to 
jboss-all.xml as subdescriptors, FWIW.


-- 
- DML

From tomaz.cerar at gmail.com  Wed Jan 29 14:49:37 2014
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Wed, 29 Jan 2014 20:49:37 +0100
Subject: [wildfly-dev] Interoperability testing
In-Reply-To: <52E959C4.1080302@redhat.com>
References: <52E959C4.1080302@redhat.com>
Message-ID: <CAMquZP53d1cTWpzLHfCyRFjyqwnYho0o3Zzu_oJxQ0DcpJMEHw@mail.gmail.com>

Testing of what exactly do you have in mind?

we already do interoperability testing between all 7.1.2+.Final releases
against latest when it comes to management.
But you probably have something else in mind.


On Wed, Jan 29, 2014 at 8:43 PM, David M. Lloyd <david.lloyd at redhat.com>wrote:

> Folks, we need some solution for interoperability testing between
> WildFly versions.  Something CI-based would be ideal - remember the old
> jboss-test stuff that could test multiple versions of things?  Something
> like that but updated for modularity and/or in-container execution and
> Maven support seems to be indicated.
>
> We'd want to test interop between the current release and each previous
> Final release.  Anyone have any ideas or is willing to tackle such a beast?
>
> --
> - DML
> _______________________________________________
> 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/20140129/f9a75c47/attachment.html 

From smarlow at redhat.com  Wed Jan 29 15:11:04 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 29 Jan 2014 15:11:04 -0500
Subject: [wildfly-dev] Favour jboss-persistence.xml if present
In-Reply-To: <52E95A2E.4000607@redhat.com>
References: <590E7374D74F224883CB3D49A8899E240CFA198C@EX1.neos-it.local>
	<52E95A2E.4000607@redhat.com>
Message-ID: <52E96058.50003@redhat.com>

On 01/29/2014 02:44 PM, David M. Lloyd wrote:
> On 01/29/2014 01:39 PM, Klein, Christopher wrote:
>> Hey guys,
>> I already filled out a feature request in JIRA (https://issues.jboss.org/browse/WFLY-2816).
>>
>> We have the situation that our development environment (currently JBoss AS 7.1.1) differs from the production instance (WebSphere 8.5). Our persistence.xml has to be adjusted for production environment: different jta-data-source, different properties. The dirty solution for this problem would be to generate separate build artifacts for both environments. As you can imagine I don't like the idea of having two binaries just because of a few different settings. Other options (WildFly or WebSphere specific JPA properties; extending Hibernate persistence provider) do not work.
>>
>> A much nicer solution would be: WildFly checks on deployment process for the existence of a jboss-persistence.xml. If it does, the jboss-persistence.xml is used for configuring the JPA subsystem. Otherwise it falls back to the standard persistence.xml. The jboss-persistence.xml would use the XML schema from persistence.xml.
>>
>> I lookup into the WildFly sources and this change should be an easy patch which I would provide.
>>
>> So here are my questsions:
>> 1. Are you generally interested in accepting such a pull request or is it a feature you don't want?
>> 2. Does another solution exists to my problem apart from generating different artifacts which makes this pull request needless?
>
> It sounds like a reasonable idea that actually applies generally.  If I
> recall correctly, we have something of a mix today of descriptors which
> override versus supplementing existing configuration.  But overall the
> unofficial policy for new descriptors has been to add them in to
> jboss-all.xml as subdescriptors, FWIW.
>

I'm not sure that jboss-all.xml would be a good place for the 
persistence unit definitions.

I think that the proposed jboss-persistence.xml (or 
wildfly-persistence.xml) could be helpful for anyone that wants to only 
develop on WildFly but deploy on other application servers.  I suppose 
this could help someone that wants to migrate off of WildFly as well (to 
prepare for a switch to something else).  Is that what you mean by the 
proposed solution applying generally?





From jason.greene at redhat.com  Wed Jan 29 15:17:07 2014
From: jason.greene at redhat.com (Jason Greene)
Date: Wed, 29 Jan 2014 14:17:07 -0600
Subject: [wildfly-dev] Favour jboss-persistence.xml if present
In-Reply-To: <52E96058.50003@redhat.com>
References: <590E7374D74F224883CB3D49A8899E240CFA198C@EX1.neos-it.local>
	<52E95A2E.4000607@redhat.com> <52E96058.50003@redhat.com>
Message-ID: <96250D79-4AD4-4395-B178-7BBFDDB9423D@redhat.com>


On Jan 29, 2014, at 2:11 PM, Scott Marlow <smarlow at redhat.com> wrote:

> On 01/29/2014 02:44 PM, David M. Lloyd wrote:
>> On 01/29/2014 01:39 PM, Klein, Christopher wrote:
>>> Hey guys,
>>> I already filled out a feature request in JIRA (https://issues.jboss.org/browse/WFLY-2816).
>>> 
>>> We have the situation that our development environment (currently JBoss AS 7.1.1) differs from the production instance (WebSphere 8.5). Our persistence.xml has to be adjusted for production environment: different jta-data-source, different properties. The dirty solution for this problem would be to generate separate build artifacts for both environments. As you can imagine I don't like the idea of having two binaries just because of a few different settings. Other options (WildFly or WebSphere specific JPA properties; extending Hibernate persistence provider) do not work.
>>> 
>>> A much nicer solution would be: WildFly checks on deployment process for the existence of a jboss-persistence.xml. If it does, the jboss-persistence.xml is used for configuring the JPA subsystem. Otherwise it falls back to the standard persistence.xml. The jboss-persistence.xml would use the XML schema from persistence.xml.
>>> 
>>> I lookup into the WildFly sources and this change should be an easy patch which I would provide.
>>> 
>>> So here are my questsions:
>>> 1. Are you generally interested in accepting such a pull request or is it a feature you don't want?
>>> 2. Does another solution exists to my problem apart from generating different artifacts which makes this pull request needless?
>> 
>> It sounds like a reasonable idea that actually applies generally.  If I
>> recall correctly, we have something of a mix today of descriptors which
>> override versus supplementing existing configuration.  But overall the
>> unofficial policy for new descriptors has been to add them in to
>> jboss-all.xml as subdescriptors, FWIW.
>> 
> 
> I'm not sure that jboss-all.xml would be a good place for the 
> persistence unit definitions.

I would agree that this is probably impractical.

> 
> I think that the proposed jboss-persistence.xml (or 
> wildfly-persistence.xml) could be helpful for anyone that wants to only 
> develop on WildFly but deploy on other application servers.  I suppose 
> this could help someone that wants to migrate off of WildFly as well (to 
> prepare for a switch to something else).  Is that what you mean by the 
> proposed solution applying generally?

It does sound a lot like a vendor specific alt-dd feature. We have some other solutions as well that might be relevant:

1) Deployment overlay feature - This allows you to override the descriptors in a deployment without modifying the deployment. These are added in a separate management op with a match pattern, and preserved outside the lifecycle of the deployment. Available in WildFly 8 and EAP 6.2 (can?t recall if it made EAP 6.1).

2) Property Substituion - There is a flag you can optionally enable in standalone/domain.xml that allows descriptors to contain property expressions. However, this only works for this use case if all venders are using the same expression language (unlikely). I just thought I would mention it.


> 
> 
> 
> 
> _______________________________________________
> 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  Wed Jan 29 15:17:07 2014
From: jason.greene at redhat.com (Jason Greene)
Date: Wed, 29 Jan 2014 14:17:07 -0600
Subject: [wildfly-dev] Favour jboss-persistence.xml if present
In-Reply-To: <52E96058.50003@redhat.com>
References: <590E7374D74F224883CB3D49A8899E240CFA198C@EX1.neos-it.local>
	<52E95A2E.4000607@redhat.com> <52E96058.50003@redhat.com>
Message-ID: <6F814CB3-BC91-471E-AC57-EA2864B45CAA@redhat.com>


On Jan 29, 2014, at 2:11 PM, Scott Marlow <smarlow at redhat.com> wrote:

> On 01/29/2014 02:44 PM, David M. Lloyd wrote:
>> On 01/29/2014 01:39 PM, Klein, Christopher wrote:
>>> Hey guys,
>>> I already filled out a feature request in JIRA (https://issues.jboss.org/browse/WFLY-2816).
>>> 
>>> We have the situation that our development environment (currently JBoss AS 7.1.1) differs from the production instance (WebSphere 8.5). Our persistence.xml has to be adjusted for production environment: different jta-data-source, different properties. The dirty solution for this problem would be to generate separate build artifacts for both environments. As you can imagine I don't like the idea of having two binaries just because of a few different settings. Other options (WildFly or WebSphere specific JPA properties; extending Hibernate persistence provider) do not work.
>>> 
>>> A much nicer solution would be: WildFly checks on deployment process for the existence of a jboss-persistence.xml. If it does, the jboss-persistence.xml is used for configuring the JPA subsystem. Otherwise it falls back to the standard persistence.xml. The jboss-persistence.xml would use the XML schema from persistence.xml.
>>> 
>>> I lookup into the WildFly sources and this change should be an easy patch which I would provide.
>>> 
>>> So here are my questsions:
>>> 1. Are you generally interested in accepting such a pull request or is it a feature you don't want?
>>> 2. Does another solution exists to my problem apart from generating different artifacts which makes this pull request needless?
>> 
>> It sounds like a reasonable idea that actually applies generally.  If I
>> recall correctly, we have something of a mix today of descriptors which
>> override versus supplementing existing configuration.  But overall the
>> unofficial policy for new descriptors has been to add them in to
>> jboss-all.xml as subdescriptors, FWIW.
>> 
> 
> I'm not sure that jboss-all.xml would be a good place for the 
> persistence unit definitions.

I would agree that this is probably impractical.

> 
> I think that the proposed jboss-persistence.xml (or 
> wildfly-persistence.xml) could be helpful for anyone that wants to only 
> develop on WildFly but deploy on other application servers.  I suppose 
> this could help someone that wants to migrate off of WildFly as well (to 
> prepare for a switch to something else).  Is that what you mean by the 
> proposed solution applying generally?

It does sound a lot like a vendor specific alt-dd feature. We have some other solutions as well that might be relevant:

1) Deployment overlay feature - This allows you to override the descriptors in a deployment without modifying the deployment. These are added in a separate management op with a match pattern, and preserved outside the lifecycle of the deployment. Available in WildFly 8 and EAP 6.2 (can?t recall if it made EAP 6.1).

2) Property Substituion - There is a flag you can optionally enable in standalone/domain.xml that allows descriptors to contain property expressions. However, this only works for this use case if all venders are using the same expression language (unlikely). I just thought I would mention it.


> 
> 
> 
> 
> _______________________________________________
> 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 smarlow at redhat.com  Wed Jan 29 15:00:04 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 29 Jan 2014 15:00:04 -0500
Subject: [wildfly-dev] Favour jboss-persistence.xml if present
In-Reply-To: <590E7374D74F224883CB3D49A8899E240CFA198C@EX1.neos-it.local>
References: <590E7374D74F224883CB3D49A8899E240CFA198C@EX1.neos-it.local>
Message-ID: <52E95DC4.7050001@redhat.com>

On 01/29/2014 02:39 PM, Klein, Christopher wrote:
> Hey guys,
> I already filled out a feature request in JIRA (https://issues.jboss.org/browse/WFLY-2816).
>
> We have the situation that our development environment (currently JBoss AS 7.1.1) differs from the production instance (WebSphere 8.5). Our persistence.xml has to be adjusted for production environment: different jta-data-source, different properties. The dirty solution for this problem would be to generate separate build artifacts for both environments. As you can imagine I don't like the idea of having two binaries just because of a few different settings. Other options (WildFly or WebSphere specific JPA properties; extending Hibernate persistence provider) do not work.
>
> A much nicer solution would be: WildFly checks on deployment process for the existence of a jboss-persistence.xml. If it does, the jboss-persistence.xml is used for configuring the JPA subsystem. Otherwise it falls back to the standard persistence.xml. The jboss-persistence.xml would use the XML schema from persistence.xml.
>
> I lookup into the WildFly sources and this change should be an easy patch which I would provide.
>
> So here are my questsions:
> 1. Are you generally interested in accepting such a pull request or is it a feature you don't want?
> 2. Does another solution exists to my problem apart from generating different artifacts which makes this pull request needless?

During the building of your application.  If building for WebShere, 
generate a WebSphere persistence.xml 
("hibernate.transaction.manager_lookup_class" is set to for WebSphere). 
  Otherwise, generate a persistence.xml for WildFly.  If you like, you 
could generate two separate application archives during your build as 
well.  Is this what your doing now?

>
> Greetings from Wolfsburg/Germany,
> Christopher
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


From smarlow at redhat.com  Wed Jan 29 16:20:04 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 29 Jan 2014 16:20:04 -0500
Subject: [wildfly-dev] Favour jboss-persistence.xml if present
In-Reply-To: <6F814CB3-BC91-471E-AC57-EA2864B45CAA@redhat.com>
References: <590E7374D74F224883CB3D49A8899E240CFA198C@EX1.neos-it.local>
	<52E95A2E.4000607@redhat.com> <52E96058.50003@redhat.com>
	<6F814CB3-BC91-471E-AC57-EA2864B45CAA@redhat.com>
Message-ID: <52E97084.5040807@redhat.com>

On 01/29/2014 03:17 PM, Jason Greene wrote:
>
> On Jan 29, 2014, at 2:11 PM, Scott Marlow <smarlow at redhat.com> wrote:
>
>> On 01/29/2014 02:44 PM, David M. Lloyd wrote:
>>> On 01/29/2014 01:39 PM, Klein, Christopher wrote:
>>>> Hey guys,
>>>> I already filled out a feature request in JIRA (https://issues.jboss.org/browse/WFLY-2816).
>>>>
>>>> We have the situation that our development environment (currently JBoss AS 7.1.1) differs from the production instance (WebSphere 8.5). Our persistence.xml has to be adjusted for production environment: different jta-data-source, different properties. The dirty solution for this problem would be to generate separate build artifacts for both environments. As you can imagine I don't like the idea of having two binaries just because of a few different settings. Other options (WildFly or WebSphere specific JPA properties; extending Hibernate persistence provider) do not work.
>>>>
>>>> A much nicer solution would be: WildFly checks on deployment process for the existence of a jboss-persistence.xml. If it does, the jboss-persistence.xml is used for configuring the JPA subsystem. Otherwise it falls back to the standard persistence.xml. The jboss-persistence.xml would use the XML schema from persistence.xml.
>>>>
>>>> I lookup into the WildFly sources and this change should be an easy patch which I would provide.
>>>>
>>>> So here are my questsions:
>>>> 1. Are you generally interested in accepting such a pull request or is it a feature you don't want?
>>>> 2. Does another solution exists to my problem apart from generating different artifacts which makes this pull request needless?
>>>
>>> It sounds like a reasonable idea that actually applies generally.  If I
>>> recall correctly, we have something of a mix today of descriptors which
>>> override versus supplementing existing configuration.  But overall the
>>> unofficial policy for new descriptors has been to add them in to
>>> jboss-all.xml as subdescriptors, FWIW.
>>>
>>
>> I'm not sure that jboss-all.xml would be a good place for the
>> persistence unit definitions.
>
> I would agree that this is probably impractical.
>
>>
>> I think that the proposed jboss-persistence.xml (or
>> wildfly-persistence.xml) could be helpful for anyone that wants to only
>> develop on WildFly but deploy on other application servers.  I suppose
>> this could help someone that wants to migrate off of WildFly as well (to
>> prepare for a switch to something else).  Is that what you mean by the
>> proposed solution applying generally?
>
> It does sound a lot like a vendor specific alt-dd feature. We have some other solutions as well that might be relevant:
>
> 1) Deployment overlay feature - This allows you to override the descriptors in a deployment without modifying the deployment. These are added in a separate management op with a match pattern, and preserved outside the lifecycle of the deployment. Available in WildFly 8 and EAP 6.2 (can?t recall if it made EAP 6.1).

I was just reading 
https://docs.jboss.org/author/display/WFLY8/Deployment+Overlays but I'm 
not sure that would help with this use case.  Since the deployment will 
fail due to the persistence.xml targeting WebSphere (persistence unit 
property "hibernate.transaction.manager_lookup_class" is set to 
"org.hibernate.transaction.WebSphereExtendedJTATransactionLookup").

What might help is if we could ignore (or auto-magically remove during 
deployment) certain persistence unit property settings that we know will 
cause the deployment to fail.

>
> 2) Property Substituion - There is a flag you can optionally enable in standalone/domain.xml that allows descriptors to contain property expressions. However, this only works for this use case if all venders are using the same expression language (unlikely). I just thought I would mention it.
>
>
>>
>>
>>
>>
>> _______________________________________________
>> 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  Wed Jan 29 16:24:56 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 29 Jan 2014 15:24:56 -0600
Subject: [wildfly-dev] Favour jboss-persistence.xml if present
In-Reply-To: <52E97084.5040807@redhat.com>
References: <590E7374D74F224883CB3D49A8899E240CFA198C@EX1.neos-it.local>	<52E95A2E.4000607@redhat.com>
	<52E96058.50003@redhat.com>	<6F814CB3-BC91-471E-AC57-EA2864B45CAA@redhat.com>
	<52E97084.5040807@redhat.com>
Message-ID: <52E971A8.7040008@redhat.com>

On 1/29/14, 3:20 PM, Scott Marlow wrote:
> On 01/29/2014 03:17 PM, Jason Greene wrote:
>>
>> On Jan 29, 2014, at 2:11 PM, Scott Marlow <smarlow at redhat.com> wrote:
>>
>>> On 01/29/2014 02:44 PM, David M. Lloyd wrote:
>>>> On 01/29/2014 01:39 PM, Klein, Christopher wrote:
>>>>> Hey guys,
>>>>> I already filled out a feature request in JIRA (https://issues.jboss.org/browse/WFLY-2816).
>>>>>
>>>>> We have the situation that our development environment (currently JBoss AS 7.1.1) differs from the production instance (WebSphere 8.5). Our persistence.xml has to be adjusted for production environment: different jta-data-source, different properties. The dirty solution for this problem would be to generate separate build artifacts for both environments. As you can imagine I don't like the idea of having two binaries just because of a few different settings. Other options (WildFly or WebSphere specific JPA properties; extending Hibernate persistence provider) do not work.
>>>>>
>>>>> A much nicer solution would be: WildFly checks on deployment process for the existence of a jboss-persistence.xml. If it does, the jboss-persistence.xml is used for configuring the JPA subsystem. Otherwise it falls back to the standard persistence.xml. The jboss-persistence.xml would use the XML schema from persistence.xml.
>>>>>
>>>>> I lookup into the WildFly sources and this change should be an easy patch which I would provide.
>>>>>
>>>>> So here are my questsions:
>>>>> 1. Are you generally interested in accepting such a pull request or is it a feature you don't want?
>>>>> 2. Does another solution exists to my problem apart from generating different artifacts which makes this pull request needless?
>>>>
>>>> It sounds like a reasonable idea that actually applies generally.  If I
>>>> recall correctly, we have something of a mix today of descriptors which
>>>> override versus supplementing existing configuration.  But overall the
>>>> unofficial policy for new descriptors has been to add them in to
>>>> jboss-all.xml as subdescriptors, FWIW.
>>>>
>>>
>>> I'm not sure that jboss-all.xml would be a good place for the
>>> persistence unit definitions.
>>
>> I would agree that this is probably impractical.
>>
>>>
>>> I think that the proposed jboss-persistence.xml (or
>>> wildfly-persistence.xml) could be helpful for anyone that wants to only
>>> develop on WildFly but deploy on other application servers.  I suppose
>>> this could help someone that wants to migrate off of WildFly as well (to
>>> prepare for a switch to something else).  Is that what you mean by the
>>> proposed solution applying generally?
>>
>> It does sound a lot like a vendor specific alt-dd feature. We have some other solutions as well that might be relevant:
>>
>> 1) Deployment overlay feature - This allows you to override the descriptors in a deployment without modifying the deployment. These are added in a separate management op with a match pattern, and preserved outside the lifecycle of the deployment. Available in WildFly 8 and EAP 6.2 (can?t recall if it made EAP 6.1).
>
> I was just reading
> https://docs.jboss.org/author/display/WFLY8/Deployment+Overlays but I'm
> not sure that would help with this use case.  Since the deployment will
> fail due to the persistence.xml targeting WebSphere (persistence unit
> property "hibernate.transaction.manager_lookup_class" is set to
> "org.hibernate.transaction.WebSphereExtendedJTATransactionLookup").
>

The persistence.xml that is the deployment overlay would not include 
those settings. The deployment overlay feature hides the original 
persistence.xml in the deployment archive from the deployment 
processors; they only see the overlay.

> What might help is if we could ignore (or auto-magically remove during
> deployment) certain persistence unit property settings that we know will
> cause the deployment to fail.
>
>>
>> 2) Property Substituion - There is a flag you can optionally enable in standalone/domain.xml that allows descriptors to contain property expressions. However, this only works for this use case if all venders are using the same expression language (unlikely). I just thought I would mention it.
>>
>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From smarlow at redhat.com  Wed Jan 29 16:33:45 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 29 Jan 2014 16:33:45 -0500
Subject: [wildfly-dev] Favour jboss-persistence.xml if present
In-Reply-To: <52E971A8.7040008@redhat.com>
References: <590E7374D74F224883CB3D49A8899E240CFA198C@EX1.neos-it.local>	<52E95A2E.4000607@redhat.com>	<52E96058.50003@redhat.com>	<6F814CB3-BC91-471E-AC57-EA2864B45CAA@redhat.com>	<52E97084.5040807@redhat.com>
	<52E971A8.7040008@redhat.com>
Message-ID: <52E973B9.1040303@redhat.com>

On 01/29/2014 04:24 PM, Brian Stansberry wrote:
> On 1/29/14, 3:20 PM, Scott Marlow wrote:
>> On 01/29/2014 03:17 PM, Jason Greene wrote:
>>>
>>> On Jan 29, 2014, at 2:11 PM, Scott Marlow <smarlow at redhat.com> wrote:
>>>
>>>> On 01/29/2014 02:44 PM, David M. Lloyd wrote:
>>>>> On 01/29/2014 01:39 PM, Klein, Christopher wrote:
>>>>>> Hey guys,
>>>>>> I already filled out a feature request in JIRA (https://issues.jboss.org/browse/WFLY-2816).
>>>>>>
>>>>>> We have the situation that our development environment (currently JBoss AS 7.1.1) differs from the production instance (WebSphere 8.5). Our persistence.xml has to be adjusted for production environment: different jta-data-source, different properties. The dirty solution for this problem would be to generate separate build artifacts for both environments. As you can imagine I don't like the idea of having two binaries just because of a few different settings. Other options (WildFly or WebSphere specific JPA properties; extending Hibernate persistence provider) do not work.
>>>>>>
>>>>>> A much nicer solution would be: WildFly checks on deployment process for the existence of a jboss-persistence.xml. If it does, the jboss-persistence.xml is used for configuring the JPA subsystem. Otherwise it falls back to the standard persistence.xml. The jboss-persistence.xml would use the XML schema from persistence.xml.
>>>>>>
>>>>>> I lookup into the WildFly sources and this change should be an easy patch which I would provide.
>>>>>>
>>>>>> So here are my questsions:
>>>>>> 1. Are you generally interested in accepting such a pull request or is it a feature you don't want?
>>>>>> 2. Does another solution exists to my problem apart from generating different artifacts which makes this pull request needless?
>>>>>
>>>>> It sounds like a reasonable idea that actually applies generally.  If I
>>>>> recall correctly, we have something of a mix today of descriptors which
>>>>> override versus supplementing existing configuration.  But overall the
>>>>> unofficial policy for new descriptors has been to add them in to
>>>>> jboss-all.xml as subdescriptors, FWIW.
>>>>>
>>>>
>>>> I'm not sure that jboss-all.xml would be a good place for the
>>>> persistence unit definitions.
>>>
>>> I would agree that this is probably impractical.
>>>
>>>>
>>>> I think that the proposed jboss-persistence.xml (or
>>>> wildfly-persistence.xml) could be helpful for anyone that wants to only
>>>> develop on WildFly but deploy on other application servers.  I suppose
>>>> this could help someone that wants to migrate off of WildFly as well (to
>>>> prepare for a switch to something else).  Is that what you mean by the
>>>> proposed solution applying generally?
>>>
>>> It does sound a lot like a vendor specific alt-dd feature. We have some other solutions as well that might be relevant:
>>>
>>> 1) Deployment overlay feature - This allows you to override the descriptors in a deployment without modifying the deployment. These are added in a separate management op with a match pattern, and preserved outside the lifecycle of the deployment. Available in WildFly 8 and EAP 6.2 (can?t recall if it made EAP 6.1).
>>
>> I was just reading
>> https://docs.jboss.org/author/display/WFLY8/Deployment+Overlays but I'm
>> not sure that would help with this use case.  Since the deployment will
>> fail due to the persistence.xml targeting WebSphere (persistence unit
>> property "hibernate.transaction.manager_lookup_class" is set to
>> "org.hibernate.transaction.WebSphereExtendedJTATransactionLookup").
>>
>
> The persistence.xml that is the deployment overlay would not include
> those settings. The deployment overlay feature hides the original
> persistence.xml in the deployment archive from the deployment
> processors; they only see the overlay.

Thanks Brian, I missed that the deployment overlay is created before 
deploying.  So that could help someone crack open an archive and replace 
the persistence.xml with one that will work.

>
>> What might help is if we could ignore (or auto-magically remove during
>> deployment) certain persistence unit property settings that we know will
>> cause the deployment to fail.
>>
>>>
>>> 2) Property Substituion - There is a flag you can optionally enable in standalone/domain.xml that allows descriptors to contain property expressions. However, this only works for this use case if all venders are using the same expression language (unlikely). I just thought I would mention it.
>>>
>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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 jgreene at redhat.com  Wed Jan 29 16:51:32 2014
From: jgreene at redhat.com (Jason Greene)
Date: Wed, 29 Jan 2014 16:51:32 -0500 (EST)
Subject: [wildfly-dev] Favour jboss-persistence.xml if present
In-Reply-To: <52E973B9.1040303@redhat.com>
References: <590E7374D74F224883CB3D49A8899E240CFA198C@EX1.neos-it.local>
	<52E95A2E.4000607@redhat.com> <52E96058.50003@redhat.com>
	<6F814CB3-BC91-471E-AC57-EA2864B45CAA@redhat.com>
	<52E97084.5040807@redhat.com> <52E971A8.7040008@redhat.com>
	<52E973B9.1040303@redhat.com>
Message-ID: <B887B6B1-626C-4C0F-8A28-45E8ECE57BCC@redhat.com>



> On Jan 29, 2014, at 3:33 PM, Scott Marlow <smarlow at redhat.com> wrote:
> 
>> On 01/29/2014 04:24 PM, Brian Stansberry wrote:
>>> On 1/29/14, 3:20 PM, Scott Marlow wrote:
>>>> On 01/29/2014 03:17 PM, Jason Greene wrote:
>>>> 
>>>>> On Jan 29, 2014, at 2:11 PM, Scott Marlow <smarlow at redhat.com> wrote:
>>>>> 
>>>>>> On 01/29/2014 02:44 PM, David M. Lloyd wrote:
>>>>>>> On 01/29/2014 01:39 PM, Klein, Christopher wrote:
>>>>>>> Hey guys,
>>>>>>> I already filled out a feature request in JIRA (https://issues.jboss.org/browse/WFLY-2816).
>>>>>>> 
>>>>>>> We have the situation that our development environment (currently JBoss AS 7.1.1) differs from the production instance (WebSphere 8.5). Our persistence.xml has to be adjusted for production environment: different jta-data-source, different properties. The dirty solution for this problem would be to generate separate build artifacts for both environments. As you can imagine I don't like the idea of having two binaries just because of a few different settings. Other options (WildFly or WebSphere specific JPA properties; extending Hibernate persistence provider) do not work.
>>>>>>> 
>>>>>>> A much nicer solution would be: WildFly checks on deployment process for the existence of a jboss-persistence.xml. If it does, the jboss-persistence.xml is used for configuring the JPA subsystem. Otherwise it falls back to the standard persistence.xml. The jboss-persistence.xml would use the XML schema from persistence.xml.
>>>>>>> 
>>>>>>> I lookup into the WildFly sources and this change should be an easy patch which I would provide.
>>>>>>> 
>>>>>>> So here are my questsions:
>>>>>>> 1. Are you generally interested in accepting such a pull request or is it a feature you don't want?
>>>>>>> 2. Does another solution exists to my problem apart from generating different artifacts which makes this pull request needless?
>>>>>> 
>>>>>> It sounds like a reasonable idea that actually applies generally.  If I
>>>>>> recall correctly, we have something of a mix today of descriptors which
>>>>>> override versus supplementing existing configuration.  But overall the
>>>>>> unofficial policy for new descriptors has been to add them in to
>>>>>> jboss-all.xml as subdescriptors, FWIW.
>>>>> 
>>>>> I'm not sure that jboss-all.xml would be a good place for the
>>>>> persistence unit definitions.
>>>> 
>>>> I would agree that this is probably impractical.
>>>> 
>>>>> 
>>>>> I think that the proposed jboss-persistence.xml (or
>>>>> wildfly-persistence.xml) could be helpful for anyone that wants to only
>>>>> develop on WildFly but deploy on other application servers.  I suppose
>>>>> this could help someone that wants to migrate off of WildFly as well (to
>>>>> prepare for a switch to something else).  Is that what you mean by the
>>>>> proposed solution applying generally?
>>>> 
>>>> It does sound a lot like a vendor specific alt-dd feature. We have some other solutions as well that might be relevant:
>>>> 
>>>> 1) Deployment overlay feature - This allows you to override the descriptors in a deployment without modifying the deployment. These are added in a separate management op with a match pattern, and preserved outside the lifecycle of the deployment. Available in WildFly 8 and EAP 6.2 (can?t recall if it made EAP 6.1).
>>> 
>>> I was just reading
>>> https://docs.jboss.org/author/display/WFLY8/Deployment+Overlays but I'm
>>> not sure that would help with this use case.  Since the deployment will
>>> fail due to the persistence.xml targeting WebSphere (persistence unit
>>> property "hibernate.transaction.manager_lookup_class" is set to
>>> "org.hibernate.transaction.WebSphereExtendedJTATransactionLookup").
>> 
>> The persistence.xml that is the deployment overlay would not include
>> those settings. The deployment overlay feature hides the original
>> persistence.xml in the deployment archive from the deployment
>> processors; they only see the overlay.
> 
> Thanks Brian, I missed that the deployment overlay is created before 
> deploying.  So that could help someone crack open an archive and replace 
> the persistence.xml with one that will work.

Right exactly. The disadvantage is every update to the descriptor requires an updates overlay.

Just thinking out loud that we could do a proprietary alt-dd thing in jboss-all.xml where we allow you to set replacement names. E.g web.xml=other-web.xml etc.

Then we just parse this before anything else and it would apply AFTER overlay.


> 
>> 
>>> What might help is if we could ignore (or auto-magically remove during
>>> deployment) certain persistence unit property settings that we know will
>>> cause the deployment to fail.
>>> 
>>>> 
>>>> 2) Property Substituion - There is a flag you can optionally enable in standalone/domain.xml that allows descriptors to contain property expressions. However, this only works for this use case if all venders are using the same expression language (unlikely). I just thought I would mention it.
>>>> 
>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> 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 kabir.khan at jboss.com  Wed Jan 29 17:18:47 2014
From: kabir.khan at jboss.com (Kabir Khan)
Date: Wed, 29 Jan 2014 22:18:47 +0000
Subject: [wildfly-dev] Interoperability testing
In-Reply-To: <CAMquZP53d1cTWpzLHfCyRFjyqwnYho0o3Zzu_oJxQ0DcpJMEHw@mail.gmail.com>
References: <52E959C4.1080302@redhat.com>
	<CAMquZP53d1cTWpzLHfCyRFjyqwnYho0o3Zzu_oJxQ0DcpJMEHw@mail.gmail.com>
Message-ID: <7E1A48E6-AADE-44B7-8321-2EF1EDE69CE0@jboss.com>

Is this something beyond the transformers and mixed-domain tests?
On 29 Jan 2014, at 19:49, Toma? Cerar <tomaz.cerar at gmail.com> wrote:

> Testing of what exactly do you have in mind?
> 
> we already do interoperability testing between all 7.1.2+.Final releases against latest when it comes to management.
> But you probably have something else in mind.
> 
> 
> On Wed, Jan 29, 2014 at 8:43 PM, David M. Lloyd <david.lloyd at redhat.com> wrote:
> Folks, we need some solution for interoperability testing between
> WildFly versions.  Something CI-based would be ideal - remember the old
> jboss-test stuff that could test multiple versions of things?  Something
> like that but updated for modularity and/or in-container execution and
> Maven support seems to be indicated.
> 
> We'd want to test interop between the current release and each previous
> Final release.  Anyone have any ideas or is willing to tackle such a beast?
> 
> --
> - DML
> _______________________________________________
> 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 david.lloyd at redhat.com  Wed Jan 29 17:23:29 2014
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Wed, 29 Jan 2014 16:23:29 -0600
Subject: [wildfly-dev] Interoperability testing
In-Reply-To: <7E1A48E6-AADE-44B7-8321-2EF1EDE69CE0@jboss.com>
References: <52E959C4.1080302@redhat.com>
	<CAMquZP53d1cTWpzLHfCyRFjyqwnYho0o3Zzu_oJxQ0DcpJMEHw@mail.gmail.com>
	<7E1A48E6-AADE-44B7-8321-2EF1EDE69CE0@jboss.com>
Message-ID: <52E97F61.8000503@redhat.com>

Yes.  I'm talking not just management interoperability, but also EJB, 
naming, messaging, transactions.  Basically every remotely available 
service.

On 01/29/2014 04:18 PM, Kabir Khan wrote:
> Is this something beyond the transformers and mixed-domain tests?
> On 29 Jan 2014, at 19:49, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
>
>> Testing of what exactly do you have in mind?
>>
>> we already do interoperability testing between all 7.1.2+.Final releases against latest when it comes to management.
>> But you probably have something else in mind.
>>
>>
>> On Wed, Jan 29, 2014 at 8:43 PM, David M. Lloyd <david.lloyd at redhat.com> wrote:
>> Folks, we need some solution for interoperability testing between
>> WildFly versions.  Something CI-based would be ideal - remember the old
>> jboss-test stuff that could test multiple versions of things?  Something
>> like that but updated for modularity and/or in-container execution and
>> Maven support seems to be indicated.
>>
>> We'd want to test interop between the current release and each previous
>> Final release.  Anyone have any ideas or is willing to tackle such a beast?
>>
>> --
>> - DML
>> _______________________________________________
>> 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
>


-- 
- DML

From smarlow at redhat.com  Wed Jan 29 19:41:25 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 29 Jan 2014 19:41:25 -0500
Subject: [wildfly-dev] Favour jboss-persistence.xml if present
In-Reply-To: <B887B6B1-626C-4C0F-8A28-45E8ECE57BCC@redhat.com>
References: <590E7374D74F224883CB3D49A8899E240CFA198C@EX1.neos-it.local>
	<52E95A2E.4000607@redhat.com> <52E96058.50003@redhat.com>
	<6F814CB3-BC91-471E-AC57-EA2864B45CAA@redhat.com>
	<52E97084.5040807@redhat.com> <52E971A8.7040008@redhat.com>
	<52E973B9.1040303@redhat.com>
	<B887B6B1-626C-4C0F-8A28-45E8ECE57BCC@redhat.com>
Message-ID: <52E99FB5.5040609@redhat.com>

On 01/29/2014 04:51 PM, Jason Greene wrote:
>
>
>> On Jan 29, 2014, at 3:33 PM, Scott Marlow <smarlow at redhat.com> wrote:
>>
>>> On 01/29/2014 04:24 PM, Brian Stansberry wrote:
>>>> On 1/29/14, 3:20 PM, Scott Marlow wrote:
>>>>> On 01/29/2014 03:17 PM, Jason Greene wrote:
>>>>>
>>>>>> On Jan 29, 2014, at 2:11 PM, Scott Marlow <smarlow at redhat.com> wrote:
>>>>>>
>>>>>>> On 01/29/2014 02:44 PM, David M. Lloyd wrote:
>>>>>>>> On 01/29/2014 01:39 PM, Klein, Christopher wrote:
>>>>>>>> Hey guys,
>>>>>>>> I already filled out a feature request in JIRA (https://issues.jboss.org/browse/WFLY-2816).
>>>>>>>>
>>>>>>>> We have the situation that our development environment (currently JBoss AS 7.1.1) differs from the production instance (WebSphere 8.5). Our persistence.xml has to be adjusted for production environment: different jta-data-source, different properties. The dirty solution for this problem would be to generate separate build artifacts for both environments. As you can imagine I don't like the idea of having two binaries just because of a few different settings. Other options (WildFly or WebSphere specific JPA properties; extending Hibernate persistence provider) do not work.
>>>>>>>>
>>>>>>>> A much nicer solution would be: WildFly checks on deployment process for the existence of a jboss-persistence.xml. If it does, the jboss-persistence.xml is used for configuring the JPA subsystem. Otherwise it falls back to the standard persistence.xml. The jboss-persistence.xml would use the XML schema from persistence.xml.
>>>>>>>>
>>>>>>>> I lookup into the WildFly sources and this change should be an easy patch which I would provide.
>>>>>>>>
>>>>>>>> So here are my questsions:
>>>>>>>> 1. Are you generally interested in accepting such a pull request or is it a feature you don't want?
>>>>>>>> 2. Does another solution exists to my problem apart from generating different artifacts which makes this pull request needless?
>>>>>>>
>>>>>>> It sounds like a reasonable idea that actually applies generally.  If I
>>>>>>> recall correctly, we have something of a mix today of descriptors which
>>>>>>> override versus supplementing existing configuration.  But overall the
>>>>>>> unofficial policy for new descriptors has been to add them in to
>>>>>>> jboss-all.xml as subdescriptors, FWIW.
>>>>>>
>>>>>> I'm not sure that jboss-all.xml would be a good place for the
>>>>>> persistence unit definitions.
>>>>>
>>>>> I would agree that this is probably impractical.
>>>>>
>>>>>>
>>>>>> I think that the proposed jboss-persistence.xml (or
>>>>>> wildfly-persistence.xml) could be helpful for anyone that wants to only
>>>>>> develop on WildFly but deploy on other application servers.  I suppose
>>>>>> this could help someone that wants to migrate off of WildFly as well (to
>>>>>> prepare for a switch to something else).  Is that what you mean by the
>>>>>> proposed solution applying generally?
>>>>>
>>>>> It does sound a lot like a vendor specific alt-dd feature. We have some other solutions as well that might be relevant:
>>>>>
>>>>> 1) Deployment overlay feature - This allows you to override the descriptors in a deployment without modifying the deployment. These are added in a separate management op with a match pattern, and preserved outside the lifecycle of the deployment. Available in WildFly 8 and EAP 6.2 (can?t recall if it made EAP 6.1).
>>>>
>>>> I was just reading
>>>> https://docs.jboss.org/author/display/WFLY8/Deployment+Overlays but I'm
>>>> not sure that would help with this use case.  Since the deployment will
>>>> fail due to the persistence.xml targeting WebSphere (persistence unit
>>>> property "hibernate.transaction.manager_lookup_class" is set to
>>>> "org.hibernate.transaction.WebSphereExtendedJTATransactionLookup").
>>>
>>> The persistence.xml that is the deployment overlay would not include
>>> those settings. The deployment overlay feature hides the original
>>> persistence.xml in the deployment archive from the deployment
>>> processors; they only see the overlay.
>>
>> Thanks Brian, I missed that the deployment overlay is created before
>> deploying.  So that could help someone crack open an archive and replace
>> the persistence.xml with one that will work.
>
> Right exactly. The disadvantage is every update to the descriptor requires an updates overlay.
>
> Just thinking out loud that we could do a proprietary alt-dd thing in jboss-all.xml where we allow you to set replacement names. E.g web.xml=other-web.xml etc.
>
> Then we just parse this before anything else and it would apply AFTER overlay.

Being able to use alternative files in the deployment sounds like a nice 
compliment to the deployment overlay feature.  Could this be done 
transparently to the deployment processors or would each processor get 
involved in using the replacement name?

>
>
>>
>>>
>>>> What might help is if we could ignore (or auto-magically remove during
>>>> deployment) certain persistence unit property settings that we know will
>>>> cause the deployment to fail.
>>>>
>>>>>
>>>>> 2) Property Substituion - There is a flag you can optionally enable in standalone/domain.xml that allows descriptors to contain property expressions. However, this only works for this use case if all venders are using the same expression language (unlikely). I just thought I would mention it.
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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 Christopher.Klein at neos-it.de  Thu Jan 30 02:13:05 2014
From: Christopher.Klein at neos-it.de (Klein, Christopher)
Date: Thu, 30 Jan 2014 07:13:05 +0000
Subject: [wildfly-dev] Favour jboss-persistence.xml if present
Message-ID: <590E7374D74F224883CB3D49A8899E240CFA1CDC@EX1.neos-it.local>

> > On Jan 29, 2014, at 3:33 PM, Scott Marlow <smarlow at redhat.com> wrote:
> >
> >> On 01/29/2014 04:24 PM, Brian Stansberry wrote:
> >>> On 1/29/14, 3:20 PM, Scott Marlow wrote:
> >>>> On 01/29/2014 03:17 PM, Jason Greene wrote:
> >>>>
> >>>>> On Jan 29, 2014, at 2:11 PM, Scott Marlow <smarlow at redhat.com>
> wrote:
> >>>>>
> >>>>>> On 01/29/2014 02:44 PM, David M. Lloyd wrote:
> >>>>>>> On 01/29/2014 01:39 PM, Klein, Christopher wrote:
> >>>>>>> Hey guys,
> >>>>>>> I already filled out a feature request in JIRA
> (https://issues.jboss.org/browse/WFLY-2816).
> >>>>>>>
> >>>>>>> We have the situation that our development environment
> (currently JBoss AS 7.1.1) differs from the production instance (WebSphere
> 8.5). Our persistence.xml has to be adjusted for production environment:
> different jta-data-source, different properties. The dirty solution for this
> problem would be to generate separate build artifacts for both
> environments. As you can imagine I don't like the idea of having two binaries
> just because of a few different settings. Other options (WildFly or
> WebSphere specific JPA properties; extending Hibernate persistence
> provider) do not work.
> >>>>>>>
> >>>>>>> A much nicer solution would be: WildFly checks on deployment
> process for the existence of a jboss-persistence.xml. If it does, the jboss-
> persistence.xml is used for configuring the JPA subsystem. Otherwise it falls
> back to the standard persistence.xml. The jboss-persistence.xml would use
> the XML schema from persistence.xml.
> >>>>>>>
> >>>>>>> I lookup into the WildFly sources and this change should be an easy
> patch which I would provide.
> >>>>>>>
> >>>>>>> So here are my questsions:
> >>>>>>> 1. Are you generally interested in accepting such a pull request or is
> it a feature you don't want?
> >>>>>>> 2. Does another solution exists to my problem apart from
> generating different artifacts which makes this pull request needless?
> >>>>>>
> >>>>>> It sounds like a reasonable idea that actually applies generally.
> >>>>>> If I recall correctly, we have something of a mix today of
> >>>>>> descriptors which override versus supplementing existing
> >>>>>> configuration.  But overall the unofficial policy for new
> >>>>>> descriptors has been to add them in to jboss-all.xml as
> subdescriptors, FWIW.
> >>>>>
> >>>>> I'm not sure that jboss-all.xml would be a good place for the
> >>>>> persistence unit definitions.
> >>>>
> >>>> I would agree that this is probably impractical.
> >>>>
> >>>>>
> >>>>> I think that the proposed jboss-persistence.xml (or
> >>>>> wildfly-persistence.xml) could be helpful for anyone that wants to
> >>>>> only develop on WildFly but deploy on other application servers.
> >>>>> I suppose this could help someone that wants to migrate off of
> >>>>> WildFly as well (to prepare for a switch to something else).  Is
> >>>>> that what you mean by the proposed solution applying generally?
> >>>>
> >>>> It does sound a lot like a vendor specific alt-dd feature. We have some
> other solutions as well that might be relevant:
> >>>>
> >>>> 1) Deployment overlay feature - This allows you to override the
> descriptors in a deployment without modifying the deployment. These are
> added in a separate management op with a match pattern, and preserved
> outside the lifecycle of the deployment. Available in WildFly 8 and EAP 6.2
> (can?t recall if it made EAP 6.1).
> >>>
> >>> I was just reading
> >>> https://docs.jboss.org/author/display/WFLY8/Deployment+Overlays
> but
> >>> I'm not sure that would help with this use case.  Since the
> >>> deployment will fail due to the persistence.xml targeting WebSphere
> >>> (persistence unit property
> >>> "hibernate.transaction.manager_lookup_class" is set to
> "org.hibernate.transaction.WebSphereExtendedJTATransactionLookup").
> >>
> >> The persistence.xml that is the deployment overlay would not include
> >> those settings. The deployment overlay feature hides the original
> >> persistence.xml in the deployment archive from the deployment
> >> processors; they only see the overlay.
> >
> > Thanks Brian, I missed that the deployment overlay is created before
> > deploying.  So that could help someone crack open an archive and
> > replace the persistence.xml with one that will work.
> 
> Right exactly. The disadvantage is every update to the descriptor requires an
> updates overlay.
> 
> Just thinking out loud that we could do a proprietary alt-dd thing in jboss-
> all.xml where we allow you to set replacement names. E.g web.xml=other-
> web.xml etc.
> 
> Then we just parse this before anything else and it would apply AFTER
> overlay.

I wasn?t aware of the overlay feature and it would indeed solve my problem, but I think it has the following disadvantages:

-  The write-once-deploy-everywhere concept is a little bit broken. Every time I want to deploy the WAR into a new WildFly server I have to add the overlay command line. 
- As already mentioned, a change in persistence.xml means changing the overlay file in every application server. Just redeploying with a jboss-persistence.xml is much easier.
- As a developer just by looking at the source code I don't get it instantly that the settings in persistence.xml won't be used by WildFly. Having a jbos-persistence.xml in the same directory shows me that WildFly uses other settings without reading the whole documentation. Using the overlay seems to be counterintuitively.

I looked upon the WildFly sources, did a small hack and tested it yesterday - only to showing you what I want to achieve: https://github.com/schakko/wildfly/tree/WLDFLY-2816

> >
> >>
> >>> What might help is if we could ignore (or auto-magically remove
> >>> during
> >>> deployment) certain persistence unit property settings that we know
> >>> will cause the deployment to fail.
> >>>
> >>>>
> >>>> 2) Property Substituion - There is a flag you can optionally enable in
> standalone/domain.xml that allows descriptors to contain property
> expressions. However, this only works for this use case if all venders are
> using the same expression language (unlikely). I just thought I would
> mention it.
+1
During my research how to solve the problem I wrote a very simple persistence provider which extends Hibernate (https://gist.github.com/schakko/8703966). This provider allows you to define properties like 

	<!-- If env var applicationserver.runtime equals jboss, rewrite this setting -->
	<property name="?(applicationserver.runtime=jboss)hibernate.transaction.manager_lookup_class" value="" />

But this hasn't helped me to reference another jta-data-source :-/



From marek.neumann at jestadigital.com  Thu Jan 30 03:50:28 2014
From: marek.neumann at jestadigital.com (Marek Neumann)
Date: Thu, 30 Jan 2014 09:50:28 +0100
Subject: [wildfly-dev] Intercept server shutdown in Wildfly/EAP6.2
In-Reply-To: <590E7374D74F224883CB3D49A8899E240CFA1CDC@EX1.neos-it.local>
References: <590E7374D74F224883CB3D49A8899E240CFA1CDC@EX1.neos-it.local>
Message-ID: <52EA1254.7050503@jestadigital.com>

Hi experts,

what is the appropriate way to intercept the server shutdown and execute 
some "before-stop" business logic?

I saw https://issues.jboss.org/browse/WFLY-407. Is my assumption correct 
that in EAP6.2 there is no common hook available for a soft server 
shutdown (kill) and a managed shutdown (e.g. via CLI)?

In EAP4.3 we just needed to listen for "org.jboss.system.server.stopped" 
notification sent by the shutdown hook.

Thanks a lot for the input,
Marek

From darran.lofthouse at jboss.com  Thu Jan 30 06:58:24 2014
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Thu, 30 Jan 2014 11:58:24 +0000
Subject: [wildfly-dev] Interoperability testing
In-Reply-To: <52E97F61.8000503@redhat.com>
References: <52E959C4.1080302@redhat.com>	<CAMquZP53d1cTWpzLHfCyRFjyqwnYho0o3Zzu_oJxQ0DcpJMEHw@mail.gmail.com>	<7E1A48E6-AADE-44B7-8321-2EF1EDE69CE0@jboss.com>
	<52E97F61.8000503@redhat.com>
Message-ID: <52EA3E60.80005@jboss.com>

On 29/01/14 22:23, David M. Lloyd wrote:
> Yes.  I'm talking not just management interoperability, but also EJB,
> naming, messaging, transactions.  Basically every remotely available
> service.

And not just the services, we should also have the different supported 
protocols and all supported SASL mechanisms and verify these 
permutations are still interoperable.

> On 01/29/2014 04:18 PM, Kabir Khan wrote:
>> Is this something beyond the transformers and mixed-domain tests?
>> On 29 Jan 2014, at 19:49, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
>>
>>> Testing of what exactly do you have in mind?
>>>
>>> we already do interoperability testing between all 7.1.2+.Final releases against latest when it comes to management.
>>> But you probably have something else in mind.
>>>
>>>
>>> On Wed, Jan 29, 2014 at 8:43 PM, David M. Lloyd <david.lloyd at redhat.com> wrote:
>>> Folks, we need some solution for interoperability testing between
>>> WildFly versions.  Something CI-based would be ideal - remember the old
>>> jboss-test stuff that could test multiple versions of things?  Something
>>> like that but updated for modularity and/or in-container execution and
>>> Maven support seems to be indicated.
>>>
>>> We'd want to test interop between the current release and each previous
>>> Final release.  Anyone have any ideas or is willing to tackle such a beast?
>>>
>>> --
>>> - DML
>>> _______________________________________________
>>> 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 david.lloyd at redhat.com  Thu Jan 30 08:48:36 2014
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Thu, 30 Jan 2014 07:48:36 -0600
Subject: [wildfly-dev] Intercept server shutdown in Wildfly/EAP6.2
In-Reply-To: <52EA1254.7050503@jestadigital.com>
References: <590E7374D74F224883CB3D49A8899E240CFA1CDC@EX1.neos-it.local>
	<52EA1254.7050503@jestadigital.com>
Message-ID: <52EA5834.7060803@redhat.com>

On 01/30/2014 02:50 AM, Marek Neumann wrote:
> Hi experts,
>
> what is the appropriate way to intercept the server shutdown and execute
> some "before-stop" business logic?
>
> I saw https://issues.jboss.org/browse/WFLY-407. Is my assumption correct
> that in EAP6.2 there is no common hook available for a soft server
> shutdown (kill) and a managed shutdown (e.g. via CLI)?
>
> In EAP4.3 we just needed to listen for "org.jboss.system.server.stopped"
> notification sent by the shutdown hook.

Off the top of my head, I think the simplest approach would be to just 
have a singleton EJB with a @PreDestroy in it.

If you don't have EJBs, any deployed bean with lifecycle support will do 
- Servlets, MBeans, jboss-beans-style POJOs.

-- 
- DML

From smarlow at redhat.com  Thu Jan 30 15:52:25 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Thu, 30 Jan 2014 15:52:25 -0500
Subject: [wildfly-dev] How to deal with resource refs when deploying JPA
 container managed entity managers (WFLY-2841)
Message-ID: <52EABB89.6080704@redhat.com>

WFLY-2841 reports a deployment failure that occurs when a deployments 
[1] persistence.xml, tries to use a resource reference [2] for the 
datasource [3].  The error [4] mentions an unresolved (DataSource) 
service dependency that is added to the persistence unit service [5], 
instead of resolving the resource reference (and using the underlying 
DataSource).

How should we handle resource references for this case?  Is there a way 
to resolve the resource reference directly from deployers?  Or do we 
represent the resource reference as a service?

Scott

[1] test app is at https://github.com/umartin/wfds/

[2] jboss-web.xml
<jboss-web>
         <context-root>/wfds</context-root>
         <resource-ref>
                 <res-ref-name>jdbc/MyDS</res-ref-name>
                 <res-type>javax.sql.DataSource</res-type>
                 <jndi-name>java:jboss/datasources/ExampleDS</jndi-name>
         </resource-ref>
</jboss-web>

[3] persistence.xml pu def
<persistence-unit name="wfdsPU" transaction-type="JTA">
         <jta-data-source>java:comp/env/MyDS</jta-data-source>
</persistence-unit>

[4] {"JBAS014771: Services with missing/unavailable dependencies" => 
["jboss.persistenceunit.\"wfds-1.0-SNAPSHOT.war#wfdsPU\".__FIRST_PHASE__ 
is missing 
[jboss.naming.context.java.module.\"wfds-1.0-SNAPSHOT\".\"wfds-1.0-SNAPSHOT\".env.MyDS]"]} 


[5] 
https://github.com/wildfly/wildfly/blob/master/jpa/core/src/main/java/org/jboss/as/jpa/processor/PersistenceUnitServiceHandler.java#L358

From david.lloyd at redhat.com  Thu Jan 30 16:15:06 2014
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Thu, 30 Jan 2014 15:15:06 -0600
Subject: [wildfly-dev] Proposal: Availability subsystem
Message-ID: <52EAC0DA.5060005@redhat.com>

I've been sitting on this idea for a while so I thought I'd put it out 
there and get some feedback on it.

Problem: People want things to happen when the container is "up". 
Unfortunately, there really isn't a black-and-white concept for what 
"up" means.  Often times, the user is simply going for "my application 
will function correctly", so they can make a load-balancing decision or 
perform some other monitoring action.

Semantically, the desire would be for some external mechanism to receive 
a notification when the services corresponding to the specifically 
applicable components have completely started or are going to stop.  The 
obvious implementation of such a mechanism is a service which depends on 
the set of component services.

Solution 1: In theory, a user could create a deployment that performs 
availability tasks in a service which depends on all the requisite 
services.  The user needs specific knowledge of service names in this 
case, which may change, or they must use specific technologies (for 
example, use a singleton EJB which @DependsOn each dependency).

Solution 2: Introduce a subsystem which allows definition of different 
availability configurations.  The configuration would enumerate the 
items that are required for the configuration to be considered 
available.  The configuration would be associated with an action.  We 
would use management.next-style extensibility points to let the user 
define add-in items like EJBs, servlets, POJOs, MBeans, CDI beans, etc. 
without the subsystem needing specific knowledge of the service schemes 
for each.

We could make solution 1 work more effectively by providing a more 
uniform deployment-based dependency mechanism, but that seems more 
complex to me than just introducing a subsystem and SPI for this purpose.

With a subsystem we could bundle actions for things like mod_cluster, 
other potential future Undertow- and Remoting-based proxies, simple 
notification schemes like MBean notification or logging, POST 
notification, and so on.

The timeline would not be 8 (obviously), nor 9.  I think having the 
simplified management SPI in place is a definite prerequisite, else the 
effort/reward ratio is far too low to justify doing this.  Otherwise, I 
think this is a simple idea that could be pretty damn useful, so I want 
to put it out here so it's in the back of everyone's mind.
-- 
- DML

From rodakr at gmx.ch  Thu Jan 30 18:54:48 2014
From: rodakr at gmx.ch (Rodakr)
Date: Fri, 31 Jan 2014 00:54:48 +0100
Subject: [wildfly-dev] Proposal: Availability subsystem
In-Reply-To: <52EAC0DA.5060005@redhat.com>
References: <52EAC0DA.5060005@redhat.com>
Message-ID: <B3F79561-F315-4948-9088-5F467DBD24B0@gmx.ch>

Having state machine which set the state from "Starting" to "Running" after all ressources has been initialized, all deployments are finished and server ports are listening could help to define  container "up" mabe. 



Von meinem iPhone gesendet

Am 30.01.2014 um 22:15 schrieb "David M. Lloyd" <david.lloyd at redhat.com>:

> I've been sitting on this idea for a while so I thought I'd put it out 
> there and get some feedback on it.
> 
> Problem: People want things to happen when the container is "up". 
> Unfortunately, there really isn't a black-and-white concept for what 
> "up" means.  Often times, the user is simply going for "my application 
> will function correctly", so they can make a load-balancing decision or 
> perform some other monitoring action.
> 
> Semantically, the desire would be for some external mechanism to receive 
> a notification when the services corresponding to the specifically 
> applicable components have completely started or are going to stop.  The 
> obvious implementation of such a mechanism is a service which depends on 
> the set of component services.
> 
> Solution 1: In theory, a user could create a deployment that performs 
> availability tasks in a service which depends on all the requisite 
> services.  The user needs specific knowledge of service names in this 
> case, which may change, or they must use specific technologies (for 
> example, use a singleton EJB which @DependsOn each dependency).
> 
> Solution 2: Introduce a subsystem which allows definition of different 
> availability configurations.  The configuration would enumerate the 
> items that are required for the configuration to be considered 
> available.  The configuration would be associated with an action.  We 
> would use management.next-style extensibility points to let the user 
> define add-in items like EJBs, servlets, POJOs, MBeans, CDI beans, etc. 
> without the subsystem needing specific knowledge of the service schemes 
> for each.
> 
> We could make solution 1 work more effectively by providing a more 
> uniform deployment-based dependency mechanism, but that seems more 
> complex to me than just introducing a subsystem and SPI for this purpose.
> 
> With a subsystem we could bundle actions for things like mod_cluster, 
> other potential future Undertow- and Remoting-based proxies, simple 
> notification schemes like MBean notification or logging, POST 
> notification, and so on.
> 
> The timeline would not be 8 (obviously), nor 9.  I think having the 
> simplified management SPI in place is a definite prerequisite, else the 
> effort/reward ratio is far too low to justify doing this.  Otherwise, I 
> think this is a simple idea that could be pretty damn useful, so I want 
> to put it out here so it's in the back of everyone's mind.
> -- 
> - DML
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From david.lloyd at redhat.com  Thu Jan 30 19:47:26 2014
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Thu, 30 Jan 2014 18:47:26 -0600
Subject: [wildfly-dev] Proposal: Availability subsystem
In-Reply-To: <B3F79561-F315-4948-9088-5F467DBD24B0@gmx.ch>
References: <52EAC0DA.5060005@redhat.com>
	<B3F79561-F315-4948-9088-5F467DBD24B0@gmx.ch>
Message-ID: <52EAF29E.4040301@redhat.com>

The problem is that deployments may be added and removed at any time, as 
can other server ports and services.  The case that this causes a 
problem is where a server starts up, mistakenly without an essential 
deployment, and the server thinks it's "up" but actually a required part 
is missing, possibly causing the end user to observe a "broken" server.

On 01/30/2014 05:54 PM, Rodakr wrote:
> Having state machine which set the state from "Starting" to "Running" after all ressources has been initialized, all deployments are finished and server ports are listening could help to define  container "up" mabe.
>
>
>
> Von meinem iPhone gesendet
>
> Am 30.01.2014 um 22:15 schrieb "David M. Lloyd" <david.lloyd at redhat.com>:
>
>> I've been sitting on this idea for a while so I thought I'd put it out
>> there and get some feedback on it.
>>
>> Problem: People want things to happen when the container is "up".
>> Unfortunately, there really isn't a black-and-white concept for what
>> "up" means.  Often times, the user is simply going for "my application
>> will function correctly", so they can make a load-balancing decision or
>> perform some other monitoring action.
>>
>> Semantically, the desire would be for some external mechanism to receive
>> a notification when the services corresponding to the specifically
>> applicable components have completely started or are going to stop.  The
>> obvious implementation of such a mechanism is a service which depends on
>> the set of component services.
>>
>> Solution 1: In theory, a user could create a deployment that performs
>> availability tasks in a service which depends on all the requisite
>> services.  The user needs specific knowledge of service names in this
>> case, which may change, or they must use specific technologies (for
>> example, use a singleton EJB which @DependsOn each dependency).
>>
>> Solution 2: Introduce a subsystem which allows definition of different
>> availability configurations.  The configuration would enumerate the
>> items that are required for the configuration to be considered
>> available.  The configuration would be associated with an action.  We
>> would use management.next-style extensibility points to let the user
>> define add-in items like EJBs, servlets, POJOs, MBeans, CDI beans, etc.
>> without the subsystem needing specific knowledge of the service schemes
>> for each.
>>
>> We could make solution 1 work more effectively by providing a more
>> uniform deployment-based dependency mechanism, but that seems more
>> complex to me than just introducing a subsystem and SPI for this purpose.
>>
>> With a subsystem we could bundle actions for things like mod_cluster,
>> other potential future Undertow- and Remoting-based proxies, simple
>> notification schemes like MBean notification or logging, POST
>> notification, and so on.
>>
>> The timeline would not be 8 (obviously), nor 9.  I think having the
>> simplified management SPI in place is a definite prerequisite, else the
>> effort/reward ratio is far too low to justify doing this.  Otherwise, I
>> think this is a simple idea that could be pretty damn useful, so I want
>> to put it out here so it's in the back of everyone's mind.
>> --
>> - DML
>> _______________________________________________
>> 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
>


-- 
- DML

From nickarls at gmail.com  Fri Jan 31 01:37:06 2014
From: nickarls at gmail.com (Nicklas Karlsson)
Date: Fri, 31 Jan 2014 08:37:06 +0200
Subject: [wildfly-dev] Proposal: Availability subsystem
In-Reply-To: <52EAF29E.4040301@redhat.com>
References: <52EAC0DA.5060005@redhat.com>
	<B3F79561-F315-4948-9088-5F467DBD24B0@gmx.ch>
	<52EAF29E.4040301@redhat.com>
Message-ID: <CAFzcPXGLTdk4MPjBSUGq4uKjOtR+kXq4VDqQ9xP9Ci5_gMxCjg@mail.gmail.com>

There is apparently no work going on in any related EE JSR that is covering
this?
One would think most application servers could benefit from this.


On Fri, Jan 31, 2014 at 2:47 AM, David M. Lloyd <david.lloyd at redhat.com>wrote:

> The problem is that deployments may be added and removed at any time, as
> can other server ports and services.  The case that this causes a
> problem is where a server starts up, mistakenly without an essential
> deployment, and the server thinks it's "up" but actually a required part
> is missing, possibly causing the end user to observe a "broken" server.
>
> On 01/30/2014 05:54 PM, Rodakr wrote:
> > Having state machine which set the state from "Starting" to "Running"
> after all ressources has been initialized, all deployments are finished and
> server ports are listening could help to define  container "up" mabe.
> >
> >
> >
> > Von meinem iPhone gesendet
> >
> > Am 30.01.2014 um 22:15 schrieb "David M. Lloyd" <david.lloyd at redhat.com
> >:
> >
> >> I've been sitting on this idea for a while so I thought I'd put it out
> >> there and get some feedback on it.
> >>
> >> Problem: People want things to happen when the container is "up".
> >> Unfortunately, there really isn't a black-and-white concept for what
> >> "up" means.  Often times, the user is simply going for "my application
> >> will function correctly", so they can make a load-balancing decision or
> >> perform some other monitoring action.
> >>
> >> Semantically, the desire would be for some external mechanism to receive
> >> a notification when the services corresponding to the specifically
> >> applicable components have completely started or are going to stop.  The
> >> obvious implementation of such a mechanism is a service which depends on
> >> the set of component services.
> >>
> >> Solution 1: In theory, a user could create a deployment that performs
> >> availability tasks in a service which depends on all the requisite
> >> services.  The user needs specific knowledge of service names in this
> >> case, which may change, or they must use specific technologies (for
> >> example, use a singleton EJB which @DependsOn each dependency).
> >>
> >> Solution 2: Introduce a subsystem which allows definition of different
> >> availability configurations.  The configuration would enumerate the
> >> items that are required for the configuration to be considered
> >> available.  The configuration would be associated with an action.  We
> >> would use management.next-style extensibility points to let the user
> >> define add-in items like EJBs, servlets, POJOs, MBeans, CDI beans, etc.
> >> without the subsystem needing specific knowledge of the service schemes
> >> for each.
> >>
> >> We could make solution 1 work more effectively by providing a more
> >> uniform deployment-based dependency mechanism, but that seems more
> >> complex to me than just introducing a subsystem and SPI for this
> purpose.
> >>
> >> With a subsystem we could bundle actions for things like mod_cluster,
> >> other potential future Undertow- and Remoting-based proxies, simple
> >> notification schemes like MBean notification or logging, POST
> >> notification, and so on.
> >>
> >> The timeline would not be 8 (obviously), nor 9.  I think having the
> >> simplified management SPI in place is a definite prerequisite, else the
> >> effort/reward ratio is far too low to justify doing this.  Otherwise, I
> >> think this is a simple idea that could be pretty damn useful, so I want
> >> to put it out here so it's in the back of everyone's mind.
> >> --
> >> - DML
> >> _______________________________________________
> >> 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
> >
>
>
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>



-- 
Nicklas Karlsson, +358 40 5062266
Vaakunatie 10 as 7, 20780 Kaarina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140131/b39b4573/attachment.html 

From pmuir at redhat.com  Fri Jan 31 02:45:24 2014
From: pmuir at redhat.com (Pete Muir)
Date: Fri, 31 Jan 2014 13:15:24 +0530
Subject: [wildfly-dev] Proposal: Availability subsystem
In-Reply-To: <CAFzcPXGLTdk4MPjBSUGq4uKjOtR+kXq4VDqQ9xP9Ci5_gMxCjg@mail.gmail.com>
References: <52EAC0DA.5060005@redhat.com>
	<B3F79561-F315-4948-9088-5F467DBD24B0@gmx.ch>
	<52EAF29E.4040301@redhat.com>
	<CAFzcPXGLTdk4MPjBSUGq4uKjOtR+kXq4VDqQ9xP9Ci5_gMxCjg@mail.gmail.com>
Message-ID: <483A4AF7-5519-4EDF-A610-8AD463388400@redhat.com>

I have raised this with the Java EE EG before, and there is no desire to standardise something like this.

On 31 Jan 2014, at 12:07, Nicklas Karlsson <nickarls at gmail.com> wrote:

> There is apparently no work going on in any related EE JSR that is covering this? 
> One would think most application servers could benefit from this.
> 
> 
> On Fri, Jan 31, 2014 at 2:47 AM, David M. Lloyd <david.lloyd at redhat.com> wrote:
> The problem is that deployments may be added and removed at any time, as
> can other server ports and services.  The case that this causes a
> problem is where a server starts up, mistakenly without an essential
> deployment, and the server thinks it's "up" but actually a required part
> is missing, possibly causing the end user to observe a "broken" server.
> 
> On 01/30/2014 05:54 PM, Rodakr wrote:
> > Having state machine which set the state from "Starting" to "Running" after all ressources has been initialized, all deployments are finished and server ports are listening could help to define  container "up" mabe.
> >
> >
> >
> > Von meinem iPhone gesendet
> >
> > Am 30.01.2014 um 22:15 schrieb "David M. Lloyd" <david.lloyd at redhat.com>:
> >
> >> I've been sitting on this idea for a while so I thought I'd put it out
> >> there and get some feedback on it.
> >>
> >> Problem: People want things to happen when the container is "up".
> >> Unfortunately, there really isn't a black-and-white concept for what
> >> "up" means.  Often times, the user is simply going for "my application
> >> will function correctly", so they can make a load-balancing decision or
> >> perform some other monitoring action.
> >>
> >> Semantically, the desire would be for some external mechanism to receive
> >> a notification when the services corresponding to the specifically
> >> applicable components have completely started or are going to stop.  The
> >> obvious implementation of such a mechanism is a service which depends on
> >> the set of component services.
> >>
> >> Solution 1: In theory, a user could create a deployment that performs
> >> availability tasks in a service which depends on all the requisite
> >> services.  The user needs specific knowledge of service names in this
> >> case, which may change, or they must use specific technologies (for
> >> example, use a singleton EJB which @DependsOn each dependency).
> >>
> >> Solution 2: Introduce a subsystem which allows definition of different
> >> availability configurations.  The configuration would enumerate the
> >> items that are required for the configuration to be considered
> >> available.  The configuration would be associated with an action.  We
> >> would use management.next-style extensibility points to let the user
> >> define add-in items like EJBs, servlets, POJOs, MBeans, CDI beans, etc.
> >> without the subsystem needing specific knowledge of the service schemes
> >> for each.
> >>
> >> We could make solution 1 work more effectively by providing a more
> >> uniform deployment-based dependency mechanism, but that seems more
> >> complex to me than just introducing a subsystem and SPI for this purpose.
> >>
> >> With a subsystem we could bundle actions for things like mod_cluster,
> >> other potential future Undertow- and Remoting-based proxies, simple
> >> notification schemes like MBean notification or logging, POST
> >> notification, and so on.
> >>
> >> The timeline would not be 8 (obviously), nor 9.  I think having the
> >> simplified management SPI in place is a definite prerequisite, else the
> >> effort/reward ratio is far too low to justify doing this.  Otherwise, I
> >> think this is a simple idea that could be pretty damn useful, so I want
> >> to put it out here so it's in the back of everyone's mind.
> >> --
> >> - DML
> >> _______________________________________________
> >> 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
> >
> 
> 
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> 
> 
> -- 
> Nicklas Karlsson, +358 40 5062266
> Vaakunatie 10 as 7, 20780 Kaarina
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



From saurabh.kumar at techblue.co.uk  Fri Jan 31 03:23:26 2014
From: saurabh.kumar at techblue.co.uk (saurabh)
Date: Fri, 31 Jan 2014 13:53:26 +0530
Subject: [wildfly-dev] No checksum key with wildfly download.
Message-ID: <52EB5D7E.4030501@techblue.co.uk>

Dear all,

First of all I would like to thank this community for building such a 
great open source application.
I am using wildfly since it's beta release and its really amazing.

One thing I wanted to bring in to notice is that there is no 
cryptographic key (md5 or sha1 sum) provided with the download.
If we could provide one it would be very helpful to verify the tampering 
of the file or incomplete download.



Thanks,
Saurabh.

-- 
Saurabh Kumar
RHCVA,RHCSA,RHCE


From rory.odonnell at oracle.com  Fri Jan 31 04:04:17 2014
From: rory.odonnell at oracle.com (Rory O'Donnell Oracle, Dublin Ireland)
Date: Fri, 31 Jan 2014 09:04:17 +0000
Subject: [wildfly-dev] JDK 8 Build 126 & JDK 7 Update 60 build 04 are
	available on java.net
Message-ID: <52EB6711.8010602@oracle.com>

Hi Guys,

JDK 8 Build b126 Early Access Build is now available for download 
<http://jdk8.java.net/download.html> & test.
JDK 7u60 b04 Early Access Build is also available for download 
<https://jdk7.java.net/download.html>& test.

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/20140131/3b56f22d/attachment.html 

From arjan.tijms at gmail.com  Fri Jan 31 06:25:12 2014
From: arjan.tijms at gmail.com (arjan tijms)
Date: Fri, 31 Jan 2014 12:25:12 +0100
Subject: [wildfly-dev] How to deal with resource refs when deploying JPA
 container managed entity managers (WFLY-2841)
In-Reply-To: <52EABB89.6080704@redhat.com>
References: <52EABB89.6080704@redhat.com>
Message-ID: <CAE=-AhAtqZfv51+aNMiLjmixkRfSjhAFNDscXDN=0fKY6+FvOg@mail.gmail.com>

Hi,

I looks like there's one bug in the example.

jboss-web.xml defines jdbc/MyDS

But persistence.xml references java:comp/env/MyDS

Shouldn't the last one be at least java:comp/env/jdbc/MyDS? Regardless,
even with matching names it indeed doesn't work.

Kind regards,
Arjan Tijms









On Thu, Jan 30, 2014 at 9:52 PM, Scott Marlow <smarlow at redhat.com> wrote:

> WFLY-2841 reports a deployment failure that occurs when a deployments
> [1] persistence.xml, tries to use a resource reference [2] for the
> datasource [3].  The error [4] mentions an unresolved (DataSource)
> service dependency that is added to the persistence unit service [5],
> instead of resolving the resource reference (and using the underlying
> DataSource).
>
> How should we handle resource references for this case?  Is there a way
> to resolve the resource reference directly from deployers?  Or do we
> represent the resource reference as a service?
>
> Scott
>
> [1] test app is at https://github.com/umartin/wfds/
>
> [2] jboss-web.xml
> <jboss-web>
>          <context-root>/wfds</context-root>
>          <resource-ref>
>                  <res-ref-name>jdbc/MyDS</res-ref-name>
>                  <res-type>javax.sql.DataSource</res-type>
>                  <jndi-name>java:jboss/datasources/ExampleDS</jndi-name>
>          </resource-ref>
> </jboss-web>
>
> [3] persistence.xml pu def
> <persistence-unit name="wfdsPU" transaction-type="JTA">
>          <jta-data-source>java:comp/env/MyDS</jta-data-source>
> </persistence-unit>
>
> [4] {"JBAS014771: Services with missing/unavailable dependencies" =>
> ["jboss.persistenceunit.\"wfds-1.0-SNAPSHOT.war#wfdsPU\".__FIRST_PHASE__
> is missing
>
> [jboss.naming.context.java.module.\"wfds-1.0-SNAPSHOT\".\"wfds-1.0-SNAPSHOT\".env.MyDS]"]}
>
>
> [5]
>
> https://github.com/wildfly/wildfly/blob/master/jpa/core/src/main/java/org/jboss/as/jpa/processor/PersistenceUnitServiceHandler.java#L358
> _______________________________________________
> 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/20140131/ce95980c/attachment.html 

From martin.andersson at purplescout.se  Fri Jan 31 07:08:17 2014
From: martin.andersson at purplescout.se (Martin Andersson)
Date: Fri, 31 Jan 2014 13:08:17 +0100
Subject: [wildfly-dev] How to deal with resource refs when deploying JPA
 container managed entity managers (WFLY-2841)
In-Reply-To: <CAE=-AhAtqZfv51+aNMiLjmixkRfSjhAFNDscXDN=0fKY6+FvOg@mail.gmail.com>
References: <52EABB89.6080704@redhat.com>
	<CAE=-AhAtqZfv51+aNMiLjmixkRfSjhAFNDscXDN=0fKY6+FvOg@mail.gmail.com>
Message-ID: <CACmAtJvVO5-bVCyyQ3ZVLt2mme9u31B9S0RtASFKbcXi5ejCYw@mail.gmail.com>

Thanks for the quick feedback!

I removed the typo in persistence.xml and updated the code at
https://github.com/umartin/wfds/

But as you say, the deployment still fails.

Br,
Martin Andersson
Java EE developer at www.purplescout.se


On Fri, Jan 31, 2014 at 12:25 PM, arjan tijms <arjan.tijms at gmail.com> wrote:

> Hi,
>
> I looks like there's one bug in the example.
>
> jboss-web.xml defines jdbc/MyDS
>
> But persistence.xml references java:comp/env/MyDS
>
> Shouldn't the last one be at least java:comp/env/jdbc/MyDS? Regardless,
> even with matching names it indeed doesn't work.
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>
>
>
> On Thu, Jan 30, 2014 at 9:52 PM, Scott Marlow <smarlow at redhat.com> wrote:
>
>> WFLY-2841 reports a deployment failure that occurs when a deployments
>> [1] persistence.xml, tries to use a resource reference [2] for the
>> datasource [3].  The error [4] mentions an unresolved (DataSource)
>> service dependency that is added to the persistence unit service [5],
>> instead of resolving the resource reference (and using the underlying
>> DataSource).
>>
>> How should we handle resource references for this case?  Is there a way
>> to resolve the resource reference directly from deployers?  Or do we
>> represent the resource reference as a service?
>>
>> Scott
>>
>> [1] test app is at https://github.com/umartin/wfds/
>>
>> [2] jboss-web.xml
>> <jboss-web>
>>          <context-root>/wfds</context-root>
>>          <resource-ref>
>>                  <res-ref-name>jdbc/MyDS</res-ref-name>
>>                  <res-type>javax.sql.DataSource</res-type>
>>                  <jndi-name>java:jboss/datasources/ExampleDS</jndi-name>
>>          </resource-ref>
>> </jboss-web>
>>
>> [3] persistence.xml pu def
>> <persistence-unit name="wfdsPU" transaction-type="JTA">
>>          <jta-data-source>java:comp/env/MyDS</jta-data-source>
>> </persistence-unit>
>>
>> [4] {"JBAS014771: Services with missing/unavailable dependencies" =>
>> ["jboss.persistenceunit.\"wfds-1.0-SNAPSHOT.war#wfdsPU\".__FIRST_PHASE__
>> is missing
>>
>> [jboss.naming.context.java.module.\"wfds-1.0-SNAPSHOT\".\"wfds-1.0-SNAPSHOT\".env.MyDS]"]}
>>
>>
>> [5]
>>
>> https://github.com/wildfly/wildfly/blob/master/jpa/core/src/main/java/org/jboss/as/jpa/processor/PersistenceUnitServiceHandler.java#L358
>> _______________________________________________
>> 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
>



-- 
H?lsningar,
Martin Andersson
Purple Scout AB
+46 732 05 14 01
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140131/32fa1c1d/attachment.html 

From smarlow at redhat.com  Fri Jan 31 07:55:03 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Fri, 31 Jan 2014 07:55:03 -0500
Subject: [wildfly-dev] How to deal with resource refs when deploying JPA
 container managed entity managers (WFLY-2841)
In-Reply-To: <CAE=-AhAtqZfv51+aNMiLjmixkRfSjhAFNDscXDN=0fKY6+FvOg@mail.gmail.com>
References: <52EABB89.6080704@redhat.com>
	<CAE=-AhAtqZfv51+aNMiLjmixkRfSjhAFNDscXDN=0fKY6+FvOg@mail.gmail.com>
Message-ID: <52EB9D27.3080904@redhat.com>

Hi Arjan,

Great catch!  Your change and adding an persistence unit hint that the 
persistence unit doesn't need to be started early:

   <property name="wildfly.jpa.twophasebootstrap" value="false"/>

Helps the deployment succeed.

It looks like ResourceReferenceProcessor is running during the 
Phase.POST_MODULE deployment phase, so we need to add a hint to the 
persistence.xml, that helps the persistence unit deploy later.

[6] 
https://github.com/wildfly/wildfly/blob/master/ee/src/main/java/org/jboss/as/ee/subsystem/EeSubsystemAdd.java#L194

Scott

On 01/31/2014 06:25 AM, arjan tijms wrote:
> Hi,
>
> I looks like there's one bug in the example.
>
> jboss-web.xml defines jdbc/MyDS
>
> But persistence.xml references java:comp/env/MyDS
>
> Shouldn't the last one be at least java:comp/env/jdbc/MyDS? Regardless,
> even with matching names it indeed doesn't work.
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>
>
>
> On Thu, Jan 30, 2014 at 9:52 PM, Scott Marlow <smarlow at redhat.com
> <mailto:smarlow at redhat.com>> wrote:
>
>     WFLY-2841 reports a deployment failure that occurs when a deployments
>     [1] persistence.xml, tries to use a resource reference [2] for the
>     datasource [3].  The error [4] mentions an unresolved (DataSource)
>     service dependency that is added to the persistence unit service [5],
>     instead of resolving the resource reference (and using the underlying
>     DataSource).
>
>     How should we handle resource references for this case?  Is there a way
>     to resolve the resource reference directly from deployers?  Or do we
>     represent the resource reference as a service?
>
>     Scott
>
>     [1] test app is at https://github.com/umartin/wfds/
>
>     [2] jboss-web.xml
>     <jboss-web>
>               <context-root>/wfds</context-root>
>               <resource-ref>
>                       <res-ref-name>jdbc/MyDS</res-ref-name>
>                       <res-type>javax.sql.DataSource</res-type>
>
>       <jndi-name>java:jboss/datasources/ExampleDS</jndi-name>
>               </resource-ref>
>     </jboss-web>
>
>     [3] persistence.xml pu def
>     <persistence-unit name="wfdsPU" transaction-type="JTA">
>               <jta-data-source>java:comp/env/MyDS</jta-data-source>
>     </persistence-unit>
>
>     [4] {"JBAS014771: Services with missing/unavailable dependencies" =>
>     ["jboss.persistenceunit.\"wfds-1.0-SNAPSHOT.war#wfdsPU\".__FIRST_PHASE__
>     is missing
>     [jboss.naming.context.java.module.\"wfds-1.0-SNAPSHOT\".\"wfds-1.0-SNAPSHOT\".env.MyDS]"]}
>
>
>     [5]
>     https://github.com/wildfly/wildfly/blob/master/jpa/core/src/main/java/org/jboss/as/jpa/processor/PersistenceUnitServiceHandler.java#L358
>     _______________________________________________
>     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
>
>


From martin.andersson at purplescout.se  Fri Jan 31 08:04:06 2014
From: martin.andersson at purplescout.se (Martin Andersson)
Date: Fri, 31 Jan 2014 14:04:06 +0100
Subject: [wildfly-dev] How to deal with resource refs when deploying JPA
 container managed entity managers (WFLY-2841)
In-Reply-To: <52EB9D27.3080904@redhat.com>
References: <52EABB89.6080704@redhat.com>
	<CAE=-AhAtqZfv51+aNMiLjmixkRfSjhAFNDscXDN=0fKY6+FvOg@mail.gmail.com>
	<52EB9D27.3080904@redhat.com>
Message-ID: <CACmAtJs5GXKsaYD6DfW3LT-EbJmOZ_DMZPnDbL70or_mXAqYSQ@mail.gmail.com>

Thanks a lot!

I can confirm that the app works now.

Br,
Martin Andersson
Java EE developer at www.purplescout.se


On Fri, Jan 31, 2014 at 1:55 PM, Scott Marlow <smarlow at redhat.com> wrote:

> Hi Arjan,
>
> Great catch!  Your change and adding an persistence unit hint that the
> persistence unit doesn't need to be started early:
>
>    <property name="wildfly.jpa.twophasebootstrap" value="false"/>
>
> Helps the deployment succeed.
>
> It looks like ResourceReferenceProcessor is running during the
> Phase.POST_MODULE deployment phase, so we need to add a hint to the
> persistence.xml, that helps the persistence unit deploy later.
>
> [6]
>
> https://github.com/wildfly/wildfly/blob/master/ee/src/main/java/org/jboss/as/ee/subsystem/EeSubsystemAdd.java#L194
>
> Scott
>
> On 01/31/2014 06:25 AM, arjan tijms wrote:
> > Hi,
> >
> > I looks like there's one bug in the example.
> >
> > jboss-web.xml defines jdbc/MyDS
> >
> > But persistence.xml references java:comp/env/MyDS
> >
> > Shouldn't the last one be at least java:comp/env/jdbc/MyDS? Regardless,
> > even with matching names it indeed doesn't work.
> >
> > Kind regards,
> > Arjan Tijms
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Thu, Jan 30, 2014 at 9:52 PM, Scott Marlow <smarlow at redhat.com
> > <mailto:smarlow at redhat.com>> wrote:
> >
> >     WFLY-2841 reports a deployment failure that occurs when a deployments
> >     [1] persistence.xml, tries to use a resource reference [2] for the
> >     datasource [3].  The error [4] mentions an unresolved (DataSource)
> >     service dependency that is added to the persistence unit service [5],
> >     instead of resolving the resource reference (and using the underlying
> >     DataSource).
> >
> >     How should we handle resource references for this case?  Is there a
> way
> >     to resolve the resource reference directly from deployers?  Or do we
> >     represent the resource reference as a service?
> >
> >     Scott
> >
> >     [1] test app is at https://github.com/umartin/wfds/
> >
> >     [2] jboss-web.xml
> >     <jboss-web>
> >               <context-root>/wfds</context-root>
> >               <resource-ref>
> >                       <res-ref-name>jdbc/MyDS</res-ref-name>
> >                       <res-type>javax.sql.DataSource</res-type>
> >
> >       <jndi-name>java:jboss/datasources/ExampleDS</jndi-name>
> >               </resource-ref>
> >     </jboss-web>
> >
> >     [3] persistence.xml pu def
> >     <persistence-unit name="wfdsPU" transaction-type="JTA">
> >               <jta-data-source>java:comp/env/MyDS</jta-data-source>
> >     </persistence-unit>
> >
> >     [4] {"JBAS014771: Services with missing/unavailable dependencies" =>
> >
> ["jboss.persistenceunit.\"wfds-1.0-SNAPSHOT.war#wfdsPU\".__FIRST_PHASE__
> >     is missing
> >
> [jboss.naming.context.java.module.\"wfds-1.0-SNAPSHOT\".\"wfds-1.0-SNAPSHOT\".env.MyDS]"]}
> >
> >
> >     [5]
> >
> https://github.com/wildfly/wildfly/blob/master/jpa/core/src/main/java/org/jboss/as/jpa/processor/PersistenceUnitServiceHandler.java#L358
> >     _______________________________________________
> >     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
>



-- 
H?lsningar,
Martin Andersson
Purple Scout AB
+46 732 05 14 01
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140131/791e2cb9/attachment-0001.html 

From smarlow at redhat.com  Fri Jan 31 08:13:30 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Fri, 31 Jan 2014 08:13:30 -0500
Subject: [wildfly-dev] How to deal with resource refs when deploying JPA
 container managed entity managers (WFLY-2841)
In-Reply-To: <CACmAtJs5GXKsaYD6DfW3LT-EbJmOZ_DMZPnDbL70or_mXAqYSQ@mail.gmail.com>
References: <52EABB89.6080704@redhat.com>	<CAE=-AhAtqZfv51+aNMiLjmixkRfSjhAFNDscXDN=0fKY6+FvOg@mail.gmail.com>	<52EB9D27.3080904@redhat.com>
	<CACmAtJs5GXKsaYD6DfW3LT-EbJmOZ_DMZPnDbL70or_mXAqYSQ@mail.gmail.com>
Message-ID: <52EBA17A.5060502@redhat.com>

Great, thanks for reporting the issue Martin!  Great to bring more 
awareness of the deployment problem and workaround.

Scott
On 01/31/2014 08:04 AM, Martin Andersson wrote:
> Thanks a lot!
>
> I can confirm that the app works now.
>
> Br,
> Martin Andersson
> Java EE developer at www.purplescout.se <http://www.purplescout.se>
>
>
> On Fri, Jan 31, 2014 at 1:55 PM, Scott Marlow <smarlow at redhat.com
> <mailto:smarlow at redhat.com>> wrote:
>
>     Hi Arjan,
>
>     Great catch!  Your change and adding an persistence unit hint that the
>     persistence unit doesn't need to be started early:
>
>         <property name="wildfly.jpa.twophasebootstrap" value="false"/>
>
>     Helps the deployment succeed.
>
>     It looks like ResourceReferenceProcessor is running during the
>     Phase.POST_MODULE deployment phase, so we need to add a hint to the
>     persistence.xml, that helps the persistence unit deploy later.
>
>     [6]
>     https://github.com/wildfly/wildfly/blob/master/ee/src/main/java/org/jboss/as/ee/subsystem/EeSubsystemAdd.java#L194
>
>     Scott
>
>     On 01/31/2014 06:25 AM, arjan tijms wrote:
>      > Hi,
>      >
>      > I looks like there's one bug in the example.
>      >
>      > jboss-web.xml defines jdbc/MyDS
>      >
>      > But persistence.xml references java:comp/env/MyDS
>      >
>      > Shouldn't the last one be at least java:comp/env/jdbc/MyDS?
>     Regardless,
>      > even with matching names it indeed doesn't work.
>      >
>      > Kind regards,
>      > Arjan Tijms
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>      > On Thu, Jan 30, 2014 at 9:52 PM, Scott Marlow <smarlow at redhat.com
>     <mailto:smarlow at redhat.com>
>      > <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>> wrote:
>      >
>      >     WFLY-2841 reports a deployment failure that occurs when a
>     deployments
>      >     [1] persistence.xml, tries to use a resource reference [2]
>     for the
>      >     datasource [3].  The error [4] mentions an unresolved
>     (DataSource)
>      >     service dependency that is added to the persistence unit
>     service [5],
>      >     instead of resolving the resource reference (and using the
>     underlying
>      >     DataSource).
>      >
>      >     How should we handle resource references for this case?  Is
>     there a way
>      >     to resolve the resource reference directly from deployers?
>       Or do we
>      >     represent the resource reference as a service?
>      >
>      >     Scott
>      >
>      >     [1] test app is at https://github.com/umartin/wfds/
>      >
>      >     [2] jboss-web.xml
>      >     <jboss-web>
>      >               <context-root>/wfds</context-root>
>      >               <resource-ref>
>      >                       <res-ref-name>jdbc/MyDS</res-ref-name>
>      >                       <res-type>javax.sql.DataSource</res-type>
>      >
>      >       <jndi-name>java:jboss/datasources/ExampleDS</jndi-name>
>      >               </resource-ref>
>      >     </jboss-web>
>      >
>      >     [3] persistence.xml pu def
>      >     <persistence-unit name="wfdsPU" transaction-type="JTA">
>      >               <jta-data-source>java:comp/env/MyDS</jta-data-source>
>      >     </persistence-unit>
>      >
>      >     [4] {"JBAS014771: Services with missing/unavailable
>     dependencies" =>
>      >
>     ["jboss.persistenceunit.\"wfds-1.0-SNAPSHOT.war#wfdsPU\".__FIRST_PHASE__
>      >     is missing
>      >
>     [jboss.naming.context.java.module.\"wfds-1.0-SNAPSHOT\".\"wfds-1.0-SNAPSHOT\".env.MyDS]"]}
>      >
>      >
>      >     [5]
>      >
>     https://github.com/wildfly/wildfly/blob/master/jpa/core/src/main/java/org/jboss/as/jpa/processor/PersistenceUnitServiceHandler.java#L358
>      >     _______________________________________________
>      >     wildfly-dev mailing list
>      > wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     <mailto: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 <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
> --
> H?lsningar,
> Martin Andersson
> Purple Scout AB
> +46 732 05 14 01


From emartins at redhat.com  Fri Jan 31 09:03:48 2014
From: emartins at redhat.com (Eduardo Martins)
Date: Fri, 31 Jan 2014 14:03:48 +0000
Subject: [wildfly-dev] How to deal with resource refs when deploying JPA
	container managed entity managers (WFLY-2841)
In-Reply-To: <52EBA17A.5060502@redhat.com>
References: <52EABB89.6080704@redhat.com>	<CAE=-AhAtqZfv51+aNMiLjmixkRfSjhAFNDscXDN=0fKY6+FvOg@mail.gmail.com>	<52EB9D27.3080904@redhat.com>
	<CACmAtJs5GXKsaYD6DfW3LT-EbJmOZ_DMZPnDbL70or_mXAqYSQ@mail.gmail.com>
	<52EBA17A.5060502@redhat.com>
Message-ID: <3E8BA64D-FE33-467E-91B6-73DF0D8837BF@redhat.com>

IMHO this hint should not be needed, a PU referencing a java:comp or java:module datasource is already a hint that the PU will need a resource bound by another component bundled in same jar/war.

By the way I?m not really a fan of using java:comp in a PU, it sets an dependency on a EE component, and that doesn?t seem right. Wouldn't be preferable to use the original java:jboss/datasources/ExampleDS JNDI name, or use an ear and define a java:app bind  at application.xml, to be shared by all modules and components?

?E


On 31 Jan 2014, at 13:13, Scott Marlow <smarlow at redhat.com> wrote:

> Great, thanks for reporting the issue Martin!  Great to bring more 
> awareness of the deployment problem and workaround.
> 
> Scott
> On 01/31/2014 08:04 AM, Martin Andersson wrote:
>> Thanks a lot!
>> 
>> I can confirm that the app works now.
>> 
>> Br,
>> Martin Andersson
>> Java EE developer at www.purplescout.se <http://www.purplescout.se>
>> 
>> 
>> On Fri, Jan 31, 2014 at 1:55 PM, Scott Marlow <smarlow at redhat.com
>> <mailto:smarlow at redhat.com>> wrote:
>> 
>>    Hi Arjan,
>> 
>>    Great catch!  Your change and adding an persistence unit hint that the
>>    persistence unit doesn't need to be started early:
>> 
>>        <property name="wildfly.jpa.twophasebootstrap" value="false"/>
>> 
>>    Helps the deployment succeed.
>> 
>>    It looks like ResourceReferenceProcessor is running during the
>>    Phase.POST_MODULE deployment phase, so we need to add a hint to the
>>    persistence.xml, that helps the persistence unit deploy later.
>> 
>>    [6]
>>    https://github.com/wildfly/wildfly/blob/master/ee/src/main/java/org/jboss/as/ee/subsystem/EeSubsystemAdd.java#L194
>> 
>>    Scott
>> 
>>    On 01/31/2014 06:25 AM, arjan tijms wrote:
>>> Hi,
>>> 
>>> I looks like there's one bug in the example.
>>> 
>>> jboss-web.xml defines jdbc/MyDS
>>> 
>>> But persistence.xml references java:comp/env/MyDS
>>> 
>>> Shouldn't the last one be at least java:comp/env/jdbc/MyDS?
>>    Regardless,
>>> even with matching names it indeed doesn't work.
>>> 
>>> Kind regards,
>>> Arjan Tijms
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Thu, Jan 30, 2014 at 9:52 PM, Scott Marlow <smarlow at redhat.com
>>    <mailto:smarlow at redhat.com>
>>> <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>> wrote:
>>> 
>>>    WFLY-2841 reports a deployment failure that occurs when a
>>    deployments
>>>    [1] persistence.xml, tries to use a resource reference [2]
>>    for the
>>>    datasource [3].  The error [4] mentions an unresolved
>>    (DataSource)
>>>    service dependency that is added to the persistence unit
>>    service [5],
>>>    instead of resolving the resource reference (and using the
>>    underlying
>>>    DataSource).
>>> 
>>>    How should we handle resource references for this case?  Is
>>    there a way
>>>    to resolve the resource reference directly from deployers?
>>      Or do we
>>>    represent the resource reference as a service?
>>> 
>>>    Scott
>>> 
>>>    [1] test app is at https://github.com/umartin/wfds/
>>> 
>>>    [2] jboss-web.xml
>>>    <jboss-web>
>>>              <context-root>/wfds</context-root>
>>>              <resource-ref>
>>>                      <res-ref-name>jdbc/MyDS</res-ref-name>
>>>                      <res-type>javax.sql.DataSource</res-type>
>>> 
>>>      <jndi-name>java:jboss/datasources/ExampleDS</jndi-name>
>>>              </resource-ref>
>>>    </jboss-web>
>>> 
>>>    [3] persistence.xml pu def
>>>    <persistence-unit name="wfdsPU" transaction-type="JTA">
>>>              <jta-data-source>java:comp/env/MyDS</jta-data-source>
>>>    </persistence-unit>
>>> 
>>>    [4] {"JBAS014771: Services with missing/unavailable
>>    dependencies" =>
>>> 
>>    ["jboss.persistenceunit.\"wfds-1.0-SNAPSHOT.war#wfdsPU\".__FIRST_PHASE__
>>>    is missing
>>> 
>>    [jboss.naming.context.java.module.\"wfds-1.0-SNAPSHOT\".\"wfds-1.0-SNAPSHOT\".env.MyDS]"]}
>>> 
>>> 
>>>    [5]
>>> 
>>    https://github.com/wildfly/wildfly/blob/master/jpa/core/src/main/java/org/jboss/as/jpa/processor/PersistenceUnitServiceHandler.java#L358
>>>    _______________________________________________
>>>    wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>    <mailto: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 <mailto:wildfly-dev at lists.jboss.org>
>>    https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> 
>> 
>> 
>> 
>> --
>> H?lsningar,
>> Martin Andersson
>> Purple Scout AB
>> +46 732 05 14 01
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



From martin.andersson at purplescout.se  Fri Jan 31 09:33:14 2014
From: martin.andersson at purplescout.se (Martin Andersson)
Date: Fri, 31 Jan 2014 15:33:14 +0100
Subject: [wildfly-dev] How to deal with resource refs when deploying JPA
 container managed entity managers (WFLY-2841)
In-Reply-To: <3E8BA64D-FE33-467E-91B6-73DF0D8837BF@redhat.com>
References: <52EABB89.6080704@redhat.com>
	<CAE=-AhAtqZfv51+aNMiLjmixkRfSjhAFNDscXDN=0fKY6+FvOg@mail.gmail.com>
	<52EB9D27.3080904@redhat.com>
	<CACmAtJs5GXKsaYD6DfW3LT-EbJmOZ_DMZPnDbL70or_mXAqYSQ@mail.gmail.com>
	<52EBA17A.5060502@redhat.com>
	<3E8BA64D-FE33-467E-91B6-73DF0D8837BF@redhat.com>
Message-ID: <CACmAtJu=1EmmEnS06g1xD7hLw0_kc2DNpytEqMZOdeufa5aRww@mail.gmail.com>

I agree. I don't think mapping a datasource in jboss-web.xml is such an
exotic use case. I should just work. Also, there is no hint anywere that
there is a property you can set to make it work.

The proprietary jboss namespace is not an option since I want to be vendor
neutral, but ear/java:app is definitely an option.

Br,
Martin Andersson
Java EE developer at www.purplescout.se

On Fri, Jan 31, 2014 at 3:03 PM, Eduardo Martins <emartins at redhat.com>wrote:

> IMHO this hint should not be needed, a PU referencing a java:comp or
> java:module datasource is already a hint that the PU will need a resource
> bound by another component bundled in same jar/war.
>
> By the way I'm not really a fan of using java:comp in a PU, it sets an
> dependency on a EE component, and that doesn't seem right. Wouldn't be
> preferable to use the original java:jboss/datasources/ExampleDS JNDI name,
> or use an ear and define a java:app bind  at application.xml, to be shared
> by all modules and components?
>
> --E
>
>
> On 31 Jan 2014, at 13:13, Scott Marlow <smarlow at redhat.com> wrote:
>
> > Great, thanks for reporting the issue Martin!  Great to bring more
> > awareness of the deployment problem and workaround.
> >
> > Scott
> > On 01/31/2014 08:04 AM, Martin Andersson wrote:
> >> Thanks a lot!
> >>
> >> I can confirm that the app works now.
> >>
> >> Br,
> >> Martin Andersson
> >> Java EE developer at www.purplescout.se <http://www.purplescout.se>
> >>
> >>
> >> On Fri, Jan 31, 2014 at 1:55 PM, Scott Marlow <smarlow at redhat.com
> >> <mailto:smarlow at redhat.com>> wrote:
> >>
> >>    Hi Arjan,
> >>
> >>    Great catch!  Your change and adding an persistence unit hint that
> the
> >>    persistence unit doesn't need to be started early:
> >>
> >>        <property name="wildfly.jpa.twophasebootstrap" value="false"/>
> >>
> >>    Helps the deployment succeed.
> >>
> >>    It looks like ResourceReferenceProcessor is running during the
> >>    Phase.POST_MODULE deployment phase, so we need to add a hint to the
> >>    persistence.xml, that helps the persistence unit deploy later.
> >>
> >>    [6]
> >>
> https://github.com/wildfly/wildfly/blob/master/ee/src/main/java/org/jboss/as/ee/subsystem/EeSubsystemAdd.java#L194
> >>
> >>    Scott
> >>
> >>    On 01/31/2014 06:25 AM, arjan tijms wrote:
> >>> Hi,
> >>>
> >>> I looks like there's one bug in the example.
> >>>
> >>> jboss-web.xml defines jdbc/MyDS
> >>>
> >>> But persistence.xml references java:comp/env/MyDS
> >>>
> >>> Shouldn't the last one be at least java:comp/env/jdbc/MyDS?
> >>    Regardless,
> >>> even with matching names it indeed doesn't work.
> >>>
> >>> Kind regards,
> >>> Arjan Tijms
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Thu, Jan 30, 2014 at 9:52 PM, Scott Marlow <smarlow at redhat.com
> >>    <mailto:smarlow at redhat.com>
> >>> <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>> wrote:
> >>>
> >>>    WFLY-2841 reports a deployment failure that occurs when a
> >>    deployments
> >>>    [1] persistence.xml, tries to use a resource reference [2]
> >>    for the
> >>>    datasource [3].  The error [4] mentions an unresolved
> >>    (DataSource)
> >>>    service dependency that is added to the persistence unit
> >>    service [5],
> >>>    instead of resolving the resource reference (and using the
> >>    underlying
> >>>    DataSource).
> >>>
> >>>    How should we handle resource references for this case?  Is
> >>    there a way
> >>>    to resolve the resource reference directly from deployers?
> >>      Or do we
> >>>    represent the resource reference as a service?
> >>>
> >>>    Scott
> >>>
> >>>    [1] test app is at https://github.com/umartin/wfds/
> >>>
> >>>    [2] jboss-web.xml
> >>>    <jboss-web>
> >>>              <context-root>/wfds</context-root>
> >>>              <resource-ref>
> >>>                      <res-ref-name>jdbc/MyDS</res-ref-name>
> >>>                      <res-type>javax.sql.DataSource</res-type>
> >>>
> >>>      <jndi-name>java:jboss/datasources/ExampleDS</jndi-name>
> >>>              </resource-ref>
> >>>    </jboss-web>
> >>>
> >>>    [3] persistence.xml pu def
> >>>    <persistence-unit name="wfdsPU" transaction-type="JTA">
> >>>              <jta-data-source>java:comp/env/MyDS</jta-data-source>
> >>>    </persistence-unit>
> >>>
> >>>    [4] {"JBAS014771: Services with missing/unavailable
> >>    dependencies" =>
> >>>
> >>
>  ["jboss.persistenceunit.\"wfds-1.0-SNAPSHOT.war#wfdsPU\".__FIRST_PHASE__
> >>>    is missing
> >>>
> >>
>  [jboss.naming.context.java.module.\"wfds-1.0-SNAPSHOT\".\"wfds-1.0-SNAPSHOT\".env.MyDS]"]}
> >>>
> >>>
> >>>    [5]
> >>>
> >>
> https://github.com/wildfly/wildfly/blob/master/jpa/core/src/main/java/org/jboss/as/jpa/processor/PersistenceUnitServiceHandler.java#L358
> >>>    _______________________________________________
> >>>    wildfly-dev mailing list
> >>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
> >>    <mailto: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 <mailto:wildfly-dev at lists.jboss.org>
> >>    https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>
> >>
> >>
> >>
> >> --
> >> H?lsningar,
> >> Martin Andersson
> >> Purple Scout AB
> >> +46 732 05 14 01
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>


-- 
H?lsningar,
Martin Andersson
Purple Scout AB
+46 732 05 14 01
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140131/15459c3b/attachment-0001.html 

From smarlow at redhat.com  Fri Jan 31 10:05:02 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Fri, 31 Jan 2014 10:05:02 -0500
Subject: [wildfly-dev] How to deal with resource refs when deploying JPA
 container managed entity managers (WFLY-2841)
In-Reply-To: <3E8BA64D-FE33-467E-91B6-73DF0D8837BF@redhat.com>
References: <52EABB89.6080704@redhat.com>	<CAE=-AhAtqZfv51+aNMiLjmixkRfSjhAFNDscXDN=0fKY6+FvOg@mail.gmail.com>	<52EB9D27.3080904@redhat.com>
	<CACmAtJs5GXKsaYD6DfW3LT-EbJmOZ_DMZPnDbL70or_mXAqYSQ@mail.gmail.com>
	<52EBA17A.5060502@redhat.com>
	<3E8BA64D-FE33-467E-91B6-73DF0D8837BF@redhat.com>
Message-ID: <52EBBB9E.1080707@redhat.com>

JPA Entity class enhancing/rewriting needs to occur in an early 
deployment phase (before the application classloader is used to load the 
enhanced classes).

If the ResourceReferenceProcessor ran early enough, the hint wouldn't be 
needed as a workaround.  There are other "if only we did things 
differently" involved as well.  For example, when using the Hibernate 
Bootstrap spi to start the persistence unit, if we moved references to 
the datasource to only be in the second deployment phase, that would 
also help (when using Hibernate).

This is not the only case like this.  There is also implicit CDI support 
which uses the application classloader too early (leaving the 
application deployer to choose whether to use CDI in entity listeners or 
JPA class enhancing/rewriting).

@DataSourceDefinition are also not available until Phase.INSTALL, so 
they cannot be used with applications that expect entities to be 
enhanced/rewritten.

IMO, we should address these problems in the standards (EE specs).  If 
we can improve our deployment implementation to better deal with these 
"initialize me first if you want correct behaviour" situations, all the 
better.

On 01/31/2014 09:03 AM, Eduardo Martins wrote:
> IMHO this hint should not be needed, a PU referencing a java:comp or java:module datasource is already a hint that the PU will need a resource bound by another component bundled in same jar/war.
>
> By the way I?m not really a fan of using java:comp in a PU, it sets an dependency on a EE component, and that doesn?t seem right. Wouldn't be preferable to use the original java:jboss/datasources/ExampleDS JNDI name, or use an ear and define a java:app bind  at application.xml, to be shared by all modules and components?
>
> ?E
>
>
> On 31 Jan 2014, at 13:13, Scott Marlow <smarlow at redhat.com> wrote:
>
>> Great, thanks for reporting the issue Martin!  Great to bring more
>> awareness of the deployment problem and workaround.
>>
>> Scott
>> On 01/31/2014 08:04 AM, Martin Andersson wrote:
>>> Thanks a lot!
>>>
>>> I can confirm that the app works now.
>>>
>>> Br,
>>> Martin Andersson
>>> Java EE developer at www.purplescout.se <http://www.purplescout.se>
>>>
>>>
>>> On Fri, Jan 31, 2014 at 1:55 PM, Scott Marlow <smarlow at redhat.com
>>> <mailto:smarlow at redhat.com>> wrote:
>>>
>>>     Hi Arjan,
>>>
>>>     Great catch!  Your change and adding an persistence unit hint that the
>>>     persistence unit doesn't need to be started early:
>>>
>>>         <property name="wildfly.jpa.twophasebootstrap" value="false"/>
>>>
>>>     Helps the deployment succeed.
>>>
>>>     It looks like ResourceReferenceProcessor is running during the
>>>     Phase.POST_MODULE deployment phase, so we need to add a hint to the
>>>     persistence.xml, that helps the persistence unit deploy later.
>>>
>>>     [6]
>>>     https://github.com/wildfly/wildfly/blob/master/ee/src/main/java/org/jboss/as/ee/subsystem/EeSubsystemAdd.java#L194
>>>
>>>     Scott
>>>
>>>     On 01/31/2014 06:25 AM, arjan tijms wrote:
>>>> Hi,
>>>>
>>>> I looks like there's one bug in the example.
>>>>
>>>> jboss-web.xml defines jdbc/MyDS
>>>>
>>>> But persistence.xml references java:comp/env/MyDS
>>>>
>>>> Shouldn't the last one be at least java:comp/env/jdbc/MyDS?
>>>     Regardless,
>>>> even with matching names it indeed doesn't work.
>>>>
>>>> Kind regards,
>>>> Arjan Tijms
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Jan 30, 2014 at 9:52 PM, Scott Marlow <smarlow at redhat.com
>>>     <mailto:smarlow at redhat.com>
>>>> <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>> wrote:
>>>>
>>>>     WFLY-2841 reports a deployment failure that occurs when a
>>>     deployments
>>>>     [1] persistence.xml, tries to use a resource reference [2]
>>>     for the
>>>>     datasource [3].  The error [4] mentions an unresolved
>>>     (DataSource)
>>>>     service dependency that is added to the persistence unit
>>>     service [5],
>>>>     instead of resolving the resource reference (and using the
>>>     underlying
>>>>     DataSource).
>>>>
>>>>     How should we handle resource references for this case?  Is
>>>     there a way
>>>>     to resolve the resource reference directly from deployers?
>>>       Or do we
>>>>     represent the resource reference as a service?
>>>>
>>>>     Scott
>>>>
>>>>     [1] test app is at https://github.com/umartin/wfds/
>>>>
>>>>     [2] jboss-web.xml
>>>>     <jboss-web>
>>>>               <context-root>/wfds</context-root>
>>>>               <resource-ref>
>>>>                       <res-ref-name>jdbc/MyDS</res-ref-name>
>>>>                       <res-type>javax.sql.DataSource</res-type>
>>>>
>>>>       <jndi-name>java:jboss/datasources/ExampleDS</jndi-name>
>>>>               </resource-ref>
>>>>     </jboss-web>
>>>>
>>>>     [3] persistence.xml pu def
>>>>     <persistence-unit name="wfdsPU" transaction-type="JTA">
>>>>               <jta-data-source>java:comp/env/MyDS</jta-data-source>
>>>>     </persistence-unit>
>>>>
>>>>     [4] {"JBAS014771: Services with missing/unavailable
>>>     dependencies" =>
>>>>
>>>     ["jboss.persistenceunit.\"wfds-1.0-SNAPSHOT.war#wfdsPU\".__FIRST_PHASE__
>>>>     is missing
>>>>
>>>     [jboss.naming.context.java.module.\"wfds-1.0-SNAPSHOT\".\"wfds-1.0-SNAPSHOT\".env.MyDS]"]}
>>>>
>>>>
>>>>     [5]
>>>>
>>>     https://github.com/wildfly/wildfly/blob/master/jpa/core/src/main/java/org/jboss/as/jpa/processor/PersistenceUnitServiceHandler.java#L358
>>>>     _______________________________________________
>>>>     wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>     <mailto: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 <mailto:wildfly-dev at lists.jboss.org>
>>>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>>>
>>>
>>> --
>>> H?lsningar,
>>> Martin Andersson
>>> Purple Scout AB
>>> +46 732 05 14 01
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


From arjan.tijms at gmail.com  Fri Jan 31 10:08:55 2014
From: arjan.tijms at gmail.com (arjan tijms)
Date: Fri, 31 Jan 2014 16:08:55 +0100
Subject: [wildfly-dev] How to deal with resource refs when deploying JPA
 container managed entity managers (WFLY-2841)
In-Reply-To: <3E8BA64D-FE33-467E-91B6-73DF0D8837BF@redhat.com>
References: <52EABB89.6080704@redhat.com>
	<CAE=-AhAtqZfv51+aNMiLjmixkRfSjhAFNDscXDN=0fKY6+FvOg@mail.gmail.com>
	<52EB9D27.3080904@redhat.com>
	<CACmAtJs5GXKsaYD6DfW3LT-EbJmOZ_DMZPnDbL70or_mXAqYSQ@mail.gmail.com>
	<52EBA17A.5060502@redhat.com>
	<3E8BA64D-FE33-467E-91B6-73DF0D8837BF@redhat.com>
Message-ID: <CAE=-AhDVzgs3oT34HEBQSF1AQ3_e_-RM0N8SK3892xV1HjUaMg@mail.gmail.com>

Hi,

On Fri, Jan 31, 2014 at 3:03 PM, Eduardo Martins <emartins at redhat.com>wrote:

> or use an ear and define a java:app bind  at application.xml, to be shared
> by all modules and components?
>

If you have just a .war, you can use java:app just as well, can't you? I
don't think there's a specific need to use an ear just for java:app.

Kind regards,
Arjan






>
> --E
>
>
> On 31 Jan 2014, at 13:13, Scott Marlow <smarlow at redhat.com> wrote:
>
> > Great, thanks for reporting the issue Martin!  Great to bring more
> > awareness of the deployment problem and workaround.
> >
> > Scott
> > On 01/31/2014 08:04 AM, Martin Andersson wrote:
> >> Thanks a lot!
> >>
> >> I can confirm that the app works now.
> >>
> >> Br,
> >> Martin Andersson
> >> Java EE developer at www.purplescout.se <http://www.purplescout.se>
> >>
> >>
> >> On Fri, Jan 31, 2014 at 1:55 PM, Scott Marlow <smarlow at redhat.com
> >> <mailto:smarlow at redhat.com>> wrote:
> >>
> >>    Hi Arjan,
> >>
> >>    Great catch!  Your change and adding an persistence unit hint that
> the
> >>    persistence unit doesn't need to be started early:
> >>
> >>        <property name="wildfly.jpa.twophasebootstrap" value="false"/>
> >>
> >>    Helps the deployment succeed.
> >>
> >>    It looks like ResourceReferenceProcessor is running during the
> >>    Phase.POST_MODULE deployment phase, so we need to add a hint to the
> >>    persistence.xml, that helps the persistence unit deploy later.
> >>
> >>    [6]
> >>
> https://github.com/wildfly/wildfly/blob/master/ee/src/main/java/org/jboss/as/ee/subsystem/EeSubsystemAdd.java#L194
> >>
> >>    Scott
> >>
> >>    On 01/31/2014 06:25 AM, arjan tijms wrote:
> >>> Hi,
> >>>
> >>> I looks like there's one bug in the example.
> >>>
> >>> jboss-web.xml defines jdbc/MyDS
> >>>
> >>> But persistence.xml references java:comp/env/MyDS
> >>>
> >>> Shouldn't the last one be at least java:comp/env/jdbc/MyDS?
> >>    Regardless,
> >>> even with matching names it indeed doesn't work.
> >>>
> >>> Kind regards,
> >>> Arjan Tijms
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Thu, Jan 30, 2014 at 9:52 PM, Scott Marlow <smarlow at redhat.com
> >>    <mailto:smarlow at redhat.com>
> >>> <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>> wrote:
> >>>
> >>>    WFLY-2841 reports a deployment failure that occurs when a
> >>    deployments
> >>>    [1] persistence.xml, tries to use a resource reference [2]
> >>    for the
> >>>    datasource [3].  The error [4] mentions an unresolved
> >>    (DataSource)
> >>>    service dependency that is added to the persistence unit
> >>    service [5],
> >>>    instead of resolving the resource reference (and using the
> >>    underlying
> >>>    DataSource).
> >>>
> >>>    How should we handle resource references for this case?  Is
> >>    there a way
> >>>    to resolve the resource reference directly from deployers?
> >>      Or do we
> >>>    represent the resource reference as a service?
> >>>
> >>>    Scott
> >>>
> >>>    [1] test app is at https://github.com/umartin/wfds/
> >>>
> >>>    [2] jboss-web.xml
> >>>    <jboss-web>
> >>>              <context-root>/wfds</context-root>
> >>>              <resource-ref>
> >>>                      <res-ref-name>jdbc/MyDS</res-ref-name>
> >>>                      <res-type>javax.sql.DataSource</res-type>
> >>>
> >>>      <jndi-name>java:jboss/datasources/ExampleDS</jndi-name>
> >>>              </resource-ref>
> >>>    </jboss-web>
> >>>
> >>>    [3] persistence.xml pu def
> >>>    <persistence-unit name="wfdsPU" transaction-type="JTA">
> >>>              <jta-data-source>java:comp/env/MyDS</jta-data-source>
> >>>    </persistence-unit>
> >>>
> >>>    [4] {"JBAS014771: Services with missing/unavailable
> >>    dependencies" =>
> >>>
> >>
>  ["jboss.persistenceunit.\"wfds-1.0-SNAPSHOT.war#wfdsPU\".__FIRST_PHASE__
> >>>    is missing
> >>>
> >>
>  [jboss.naming.context.java.module.\"wfds-1.0-SNAPSHOT\".\"wfds-1.0-SNAPSHOT\".env.MyDS]"]}
> >>>
> >>>
> >>>    [5]
> >>>
> >>
> https://github.com/wildfly/wildfly/blob/master/jpa/core/src/main/java/org/jboss/as/jpa/processor/PersistenceUnitServiceHandler.java#L358
> >>>    _______________________________________________
> >>>    wildfly-dev mailing list
> >>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
> >>    <mailto: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 <mailto:wildfly-dev at lists.jboss.org>
> >>    https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>
> >>
> >>
> >>
> >> --
> >> H?lsningar,
> >> Martin Andersson
> >> Purple Scout AB
> >> +46 732 05 14 01
> >
> > _______________________________________________
> > 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/20140131/105eea35/attachment.html 

From smarlow at redhat.com  Fri Jan 31 10:11:06 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Fri, 31 Jan 2014 10:11:06 -0500
Subject: [wildfly-dev] How to deal with resource refs when deploying JPA
 container managed entity managers (WFLY-2841)
In-Reply-To: <3E8BA64D-FE33-467E-91B6-73DF0D8837BF@redhat.com>
References: <52EABB89.6080704@redhat.com>	<CAE=-AhAtqZfv51+aNMiLjmixkRfSjhAFNDscXDN=0fKY6+FvOg@mail.gmail.com>	<52EB9D27.3080904@redhat.com>
	<CACmAtJs5GXKsaYD6DfW3LT-EbJmOZ_DMZPnDbL70or_mXAqYSQ@mail.gmail.com>
	<52EBA17A.5060502@redhat.com>
	<3E8BA64D-FE33-467E-91B6-73DF0D8837BF@redhat.com>
Message-ID: <52EBBD0A.5030609@redhat.com>

On 01/31/2014 09:03 AM, Eduardo Martins wrote:
> IMHO this hint should not be needed, a PU referencing a java:comp or java:module datasource is already a hint that the PU will need a resource bound by another component bundled in same jar/war.

I suppose that we could notice a reference to the java:comp or 
java:module and give a warning that entity class enhancing/rewriting 
will be disabled, since the deployment will fail otherwise.

What I said before is still true though (about the other situations). 
In this case, we can automatically set the "don't start the persistence 
unit until late as possible" flag (Install phase).

>
> By the way I?m not really a fan of using java:comp in a PU, it sets an dependency on a EE component, and that doesn?t seem right. Wouldn't be preferable to use the original java:jboss/datasources/ExampleDS JNDI name, or use an ear and define a java:app bind  at application.xml, to be shared by all modules and components?
>
> ?E
>
>
> On 31 Jan 2014, at 13:13, Scott Marlow <smarlow at redhat.com> wrote:
>
>> Great, thanks for reporting the issue Martin!  Great to bring more
>> awareness of the deployment problem and workaround.
>>
>> Scott
>> On 01/31/2014 08:04 AM, Martin Andersson wrote:
>>> Thanks a lot!
>>>
>>> I can confirm that the app works now.
>>>
>>> Br,
>>> Martin Andersson
>>> Java EE developer at www.purplescout.se <http://www.purplescout.se>
>>>
>>>
>>> On Fri, Jan 31, 2014 at 1:55 PM, Scott Marlow <smarlow at redhat.com
>>> <mailto:smarlow at redhat.com>> wrote:
>>>
>>>     Hi Arjan,
>>>
>>>     Great catch!  Your change and adding an persistence unit hint that the
>>>     persistence unit doesn't need to be started early:
>>>
>>>         <property name="wildfly.jpa.twophasebootstrap" value="false"/>
>>>
>>>     Helps the deployment succeed.
>>>
>>>     It looks like ResourceReferenceProcessor is running during the
>>>     Phase.POST_MODULE deployment phase, so we need to add a hint to the
>>>     persistence.xml, that helps the persistence unit deploy later.
>>>
>>>     [6]
>>>     https://github.com/wildfly/wildfly/blob/master/ee/src/main/java/org/jboss/as/ee/subsystem/EeSubsystemAdd.java#L194
>>>
>>>     Scott
>>>
>>>     On 01/31/2014 06:25 AM, arjan tijms wrote:
>>>> Hi,
>>>>
>>>> I looks like there's one bug in the example.
>>>>
>>>> jboss-web.xml defines jdbc/MyDS
>>>>
>>>> But persistence.xml references java:comp/env/MyDS
>>>>
>>>> Shouldn't the last one be at least java:comp/env/jdbc/MyDS?
>>>     Regardless,
>>>> even with matching names it indeed doesn't work.
>>>>
>>>> Kind regards,
>>>> Arjan Tijms
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Jan 30, 2014 at 9:52 PM, Scott Marlow <smarlow at redhat.com
>>>     <mailto:smarlow at redhat.com>
>>>> <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>> wrote:
>>>>
>>>>     WFLY-2841 reports a deployment failure that occurs when a
>>>     deployments
>>>>     [1] persistence.xml, tries to use a resource reference [2]
>>>     for the
>>>>     datasource [3].  The error [4] mentions an unresolved
>>>     (DataSource)
>>>>     service dependency that is added to the persistence unit
>>>     service [5],
>>>>     instead of resolving the resource reference (and using the
>>>     underlying
>>>>     DataSource).
>>>>
>>>>     How should we handle resource references for this case?  Is
>>>     there a way
>>>>     to resolve the resource reference directly from deployers?
>>>       Or do we
>>>>     represent the resource reference as a service?
>>>>
>>>>     Scott
>>>>
>>>>     [1] test app is at https://github.com/umartin/wfds/
>>>>
>>>>     [2] jboss-web.xml
>>>>     <jboss-web>
>>>>               <context-root>/wfds</context-root>
>>>>               <resource-ref>
>>>>                       <res-ref-name>jdbc/MyDS</res-ref-name>
>>>>                       <res-type>javax.sql.DataSource</res-type>
>>>>
>>>>       <jndi-name>java:jboss/datasources/ExampleDS</jndi-name>
>>>>               </resource-ref>
>>>>     </jboss-web>
>>>>
>>>>     [3] persistence.xml pu def
>>>>     <persistence-unit name="wfdsPU" transaction-type="JTA">
>>>>               <jta-data-source>java:comp/env/MyDS</jta-data-source>
>>>>     </persistence-unit>
>>>>
>>>>     [4] {"JBAS014771: Services with missing/unavailable
>>>     dependencies" =>
>>>>
>>>     ["jboss.persistenceunit.\"wfds-1.0-SNAPSHOT.war#wfdsPU\".__FIRST_PHASE__
>>>>     is missing
>>>>
>>>     [jboss.naming.context.java.module.\"wfds-1.0-SNAPSHOT\".\"wfds-1.0-SNAPSHOT\".env.MyDS]"]}
>>>>
>>>>
>>>>     [5]
>>>>
>>>     https://github.com/wildfly/wildfly/blob/master/jpa/core/src/main/java/org/jboss/as/jpa/processor/PersistenceUnitServiceHandler.java#L358
>>>>     _______________________________________________
>>>>     wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>     <mailto: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 <mailto:wildfly-dev at lists.jboss.org>
>>>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>>>
>>>
>>> --
>>> H?lsningar,
>>> Martin Andersson
>>> Purple Scout AB
>>> +46 732 05 14 01
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


From smarlow at redhat.com  Fri Jan 31 10:27:02 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Fri, 31 Jan 2014 10:27:02 -0500
Subject: [wildfly-dev] How to deal with resource refs when deploying JPA
 container managed entity managers (WFLY-2841)
In-Reply-To: <CACmAtJu=1EmmEnS06g1xD7hLw0_kc2DNpytEqMZOdeufa5aRww@mail.gmail.com>
References: <52EABB89.6080704@redhat.com>	<CAE=-AhAtqZfv51+aNMiLjmixkRfSjhAFNDscXDN=0fKY6+FvOg@mail.gmail.com>	<52EB9D27.3080904@redhat.com>	<CACmAtJs5GXKsaYD6DfW3LT-EbJmOZ_DMZPnDbL70or_mXAqYSQ@mail.gmail.com>	<52EBA17A.5060502@redhat.com>	<3E8BA64D-FE33-467E-91B6-73DF0D8837BF@redhat.com>
	<CACmAtJu=1EmmEnS06g1xD7hLw0_kc2DNpytEqMZOdeufa5aRww@mail.gmail.com>
Message-ID: <52EBC0C6.20307@redhat.com>

I'm not sure that using java:app would help the need for adding 
deployment hints.  Unless, we detect that java:app (as a hint that 
datasources will not be available early) in the datasource name and 
disable entity enhancing (slowing performance).

On 01/31/2014 09:33 AM, Martin Andersson wrote:
> I agree. I don't think mapping a datasource in jboss-web.xml is such an
> exotic use case. I should just work. Also, there is no hint anywere that
> there is a property you can set to make it work.
>
> The proprietary jboss namespace is not an option since I want to be
> vendor neutral, but ear/java:app is definitely an option.
>
> Br,
> Martin Andersson
> Java EE developer at www.purplescout.se <http://www.purplescout.se>
>
> On Fri, Jan 31, 2014 at 3:03 PM, Eduardo Martins <emartins at redhat.com
> <mailto:emartins at redhat.com>> wrote:
>
>     IMHO this hint should not be needed, a PU referencing a java:comp or
>     java:module datasource is already a hint that the PU will need a
>     resource bound by another component bundled in same jar/war.
>
>     By the way I?m not really a fan of using java:comp in a PU, it sets
>     an dependency on a EE component, and that doesn?t seem right.
>     Wouldn't be preferable to use the original
>     java:jboss/datasources/ExampleDS JNDI name, or use an ear and define
>     a java:app bind  at application.xml, to be shared by all modules and
>     components?
>
>     ?E
>
>
>     On 31 Jan 2014, at 13:13, Scott Marlow <smarlow at redhat.com
>     <mailto:smarlow at redhat.com>> wrote:
>
>      > Great, thanks for reporting the issue Martin!  Great to bring more
>      > awareness of the deployment problem and workaround.
>      >
>      > Scott
>      > On 01/31/2014 08:04 AM, Martin Andersson wrote:
>      >> Thanks a lot!
>      >>
>      >> I can confirm that the app works now.
>      >>
>      >> Br,
>      >> Martin Andersson
>      >> Java EE developer at www.purplescout.se
>     <http://www.purplescout.se> <http://www.purplescout.se>
>      >>
>      >>
>      >> On Fri, Jan 31, 2014 at 1:55 PM, Scott Marlow
>     <smarlow at redhat.com <mailto:smarlow at redhat.com>
>      >> <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>> wrote:
>      >>
>      >>    Hi Arjan,
>      >>
>      >>    Great catch!  Your change and adding an persistence unit hint
>     that the
>      >>    persistence unit doesn't need to be started early:
>      >>
>      >>        <property name="wildfly.jpa.twophasebootstrap"
>     value="false"/>
>      >>
>      >>    Helps the deployment succeed.
>      >>
>      >>    It looks like ResourceReferenceProcessor is running during the
>      >>    Phase.POST_MODULE deployment phase, so we need to add a hint
>     to the
>      >>    persistence.xml, that helps the persistence unit deploy later.
>      >>
>      >>    [6]
>      >>
>     https://github.com/wildfly/wildfly/blob/master/ee/src/main/java/org/jboss/as/ee/subsystem/EeSubsystemAdd.java#L194
>      >>
>      >>    Scott
>      >>
>      >>    On 01/31/2014 06:25 AM, arjan tijms wrote:
>      >>> Hi,
>      >>>
>      >>> I looks like there's one bug in the example.
>      >>>
>      >>> jboss-web.xml defines jdbc/MyDS
>      >>>
>      >>> But persistence.xml references java:comp/env/MyDS
>      >>>
>      >>> Shouldn't the last one be at least java:comp/env/jdbc/MyDS?
>      >>    Regardless,
>      >>> even with matching names it indeed doesn't work.
>      >>>
>      >>> Kind regards,
>      >>> Arjan Tijms
>      >>>
>      >>>
>      >>>
>      >>>
>      >>>
>      >>>
>      >>>
>      >>>
>      >>>
>      >>> On Thu, Jan 30, 2014 at 9:52 PM, Scott Marlow
>     <smarlow at redhat.com <mailto:smarlow at redhat.com>
>      >>    <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>
>      >>> <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>
>     <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>>> wrote:
>      >>>
>      >>>    WFLY-2841 reports a deployment failure that occurs when a
>      >>    deployments
>      >>>    [1] persistence.xml, tries to use a resource reference [2]
>      >>    for the
>      >>>    datasource [3].  The error [4] mentions an unresolved
>      >>    (DataSource)
>      >>>    service dependency that is added to the persistence unit
>      >>    service [5],
>      >>>    instead of resolving the resource reference (and using the
>      >>    underlying
>      >>>    DataSource).
>      >>>
>      >>>    How should we handle resource references for this case?  Is
>      >>    there a way
>      >>>    to resolve the resource reference directly from deployers?
>      >>      Or do we
>      >>>    represent the resource reference as a service?
>      >>>
>      >>>    Scott
>      >>>
>      >>>    [1] test app is at https://github.com/umartin/wfds/
>      >>>
>      >>>    [2] jboss-web.xml
>      >>>    <jboss-web>
>      >>>              <context-root>/wfds</context-root>
>      >>>              <resource-ref>
>      >>>                      <res-ref-name>jdbc/MyDS</res-ref-name>
>      >>>                      <res-type>javax.sql.DataSource</res-type>
>      >>>
>      >>>      <jndi-name>java:jboss/datasources/ExampleDS</jndi-name>
>      >>>              </resource-ref>
>      >>>    </jboss-web>
>      >>>
>      >>>    [3] persistence.xml pu def
>      >>>    <persistence-unit name="wfdsPU" transaction-type="JTA">
>      >>>              <jta-data-source>java:comp/env/MyDS</jta-data-source>
>      >>>    </persistence-unit>
>      >>>
>      >>>    [4] {"JBAS014771: Services with missing/unavailable
>      >>    dependencies" =>
>      >>>
>      >>
>       ["jboss.persistenceunit.\"wfds-1.0-SNAPSHOT.war#wfdsPU\".__FIRST_PHASE__
>      >>>    is missing
>      >>>
>      >>
>       [jboss.naming.context.java.module.\"wfds-1.0-SNAPSHOT\".\"wfds-1.0-SNAPSHOT\".env.MyDS]"]}
>      >>>
>      >>>
>      >>>    [5]
>      >>>
>      >>
>     https://github.com/wildfly/wildfly/blob/master/jpa/core/src/main/java/org/jboss/as/jpa/processor/PersistenceUnitServiceHandler.java#L358
>      >>>    _______________________________________________
>      >>>    wildfly-dev mailing list
>      >>> wildfly-dev at lists.jboss.org
>     <mailto:wildfly-dev at lists.jboss.org>
>     <mailto:wildfly-dev at lists.jboss.org
>     <mailto:wildfly-dev at lists.jboss.org>>
>      >>    <mailto:wildfly-dev at lists.jboss.org
>     <mailto:wildfly-dev at lists.jboss.org>
>      >>    <mailto: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 <mailto:wildfly-dev at lists.jboss.org>
>     <mailto:wildfly-dev at lists.jboss.org
>     <mailto:wildfly-dev at lists.jboss.org>>
>      >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>      >>
>      >>
>      >>
>      >>
>      >> --
>      >> H?lsningar,
>      >> Martin Andersson
>      >> Purple Scout AB
>      >> +46 732 05 14 01 <tel:%2B46%20732%2005%2014%2001>
>      >
>      > _______________________________________________
>      > 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
>
>
>
>
> --
> H?lsningar,
> Martin Andersson
> Purple Scout AB
> +46 732 05 14 01


From emartins at redhat.com  Fri Jan 31 10:31:39 2014
From: emartins at redhat.com (Eduardo Martins)
Date: Fri, 31 Jan 2014 15:31:39 +0000
Subject: [wildfly-dev] How to deal with resource refs when deploying JPA
	container managed entity managers (WFLY-2841)
In-Reply-To: <CACmAtJu=1EmmEnS06g1xD7hLw0_kc2DNpytEqMZOdeufa5aRww@mail.gmail.com>
References: <52EABB89.6080704@redhat.com>
	<CAE=-AhAtqZfv51+aNMiLjmixkRfSjhAFNDscXDN=0fKY6+FvOg@mail.gmail.com>
	<52EB9D27.3080904@redhat.com>
	<CACmAtJs5GXKsaYD6DfW3LT-EbJmOZ_DMZPnDbL70or_mXAqYSQ@mail.gmail.com>
	<52EBA17A.5060502@redhat.com>
	<3E8BA64D-FE33-467E-91B6-73DF0D8837BF@redhat.com>
	<CACmAtJu=1EmmEnS06g1xD7hLw0_kc2DNpytEqMZOdeufa5aRww@mail.gmail.com>
Message-ID: <958C9A28-BF71-4850-B03C-865BD63F6489@redhat.com>

On 31 Jan 2014, at 14:33, Martin Andersson <martin.andersson at purplescout.se> wrote:

> I agree. I don't think mapping a datasource in jboss-web.xml is such an exotic use case. I should just work. Also, there is no hint anywere that there is a property you can set to make it work.
> 
> The proprietary jboss namespace is not an option since I want to be vendor neutral, but ear/java:app is definitely an option.
> 

Well, aren?t you using it already in jboss-web xml?

?E

From emartins at redhat.com  Fri Jan 31 10:37:56 2014
From: emartins at redhat.com (Eduardo Martins)
Date: Fri, 31 Jan 2014 15:37:56 +0000
Subject: [wildfly-dev] How to deal with resource refs when deploying JPA
	container managed entity managers (WFLY-2841)
In-Reply-To: <52EBBB9E.1080707@redhat.com>
References: <52EABB89.6080704@redhat.com>	<CAE=-AhAtqZfv51+aNMiLjmixkRfSjhAFNDscXDN=0fKY6+FvOg@mail.gmail.com>	<52EB9D27.3080904@redhat.com>
	<CACmAtJs5GXKsaYD6DfW3LT-EbJmOZ_DMZPnDbL70or_mXAqYSQ@mail.gmail.com>
	<52EBA17A.5060502@redhat.com>
	<3E8BA64D-FE33-467E-91B6-73DF0D8837BF@redhat.com>
	<52EBBB9E.1080707@redhat.com>
Message-ID: <58F7236C-99D1-477D-A6EF-1294357BDEA0@redhat.com>

Do you need the concrete Datasource resource present in JNDI at that JPA Entity class enhancing/rewriting? If that?s the case, then what if you have a PU pointing to java:comp/env/MyDatasource, inside an EJB jar with 2 EJBs, where each binds java:comp/env/MyDatasource to different concrete Datasource, which concrete Datasource will be used by the PU?

?E

On 31 Jan 2014, at 15:05, Scott Marlow <smarlow at redhat.com> wrote:

> JPA Entity class enhancing/rewriting needs to occur in an early deployment phase (before the application classloader is used to load the enhanced classes).
> 
> If the ResourceReferenceProcessor ran early enough, the hint wouldn't be needed as a workaround.  There are other "if only we did things differently" involved as well.  For example, when using the Hibernate Bootstrap spi to start the persistence unit, if we moved references to the datasource to only be in the second deployment phase, that would also help (when using Hibernate).
> 
> This is not the only case like this.  There is also implicit CDI support which uses the application classloader too early (leaving the application deployer to choose whether to use CDI in entity listeners or JPA class enhancing/rewriting).
> 
> @DataSourceDefinition are also not available until Phase.INSTALL, so they cannot be used with applications that expect entities to be enhanced/rewritten.
> 
> IMO, we should address these problems in the standards (EE specs).  If we can improve our deployment implementation to better deal with these "initialize me first if you want correct behaviour" situations, all the better.
> 
> On 01/31/2014 09:03 AM, Eduardo Martins wrote:
>> IMHO this hint should not be needed, a PU referencing a java:comp or java:module datasource is already a hint that the PU will need a resource bound by another component bundled in same jar/war.
>> 
>> By the way I?m not really a fan of using java:comp in a PU, it sets an dependency on a EE component, and that doesn?t seem right. Wouldn't be preferable to use the original java:jboss/datasources/ExampleDS JNDI name, or use an ear and define a java:app bind  at application.xml, to be shared by all modules and components?
>> 
>> ?E
>> 
>> 
>> On 31 Jan 2014, at 13:13, Scott Marlow <smarlow at redhat.com> wrote:
>> 
>>> Great, thanks for reporting the issue Martin!  Great to bring more
>>> awareness of the deployment problem and workaround.
>>> 
>>> Scott
>>> On 01/31/2014 08:04 AM, Martin Andersson wrote:
>>>> Thanks a lot!
>>>> 
>>>> I can confirm that the app works now.
>>>> 
>>>> Br,
>>>> Martin Andersson
>>>> Java EE developer at www.purplescout.se <http://www.purplescout.se>
>>>> 
>>>> 
>>>> On Fri, Jan 31, 2014 at 1:55 PM, Scott Marlow <smarlow at redhat.com
>>>> <mailto:smarlow at redhat.com>> wrote:
>>>> 
>>>>    Hi Arjan,
>>>> 
>>>>    Great catch!  Your change and adding an persistence unit hint that the
>>>>    persistence unit doesn't need to be started early:
>>>> 
>>>>        <property name="wildfly.jpa.twophasebootstrap" value="false"/>
>>>> 
>>>>    Helps the deployment succeed.
>>>> 
>>>>    It looks like ResourceReferenceProcessor is running during the
>>>>    Phase.POST_MODULE deployment phase, so we need to add a hint to the
>>>>    persistence.xml, that helps the persistence unit deploy later.
>>>> 
>>>>    [6]
>>>>    https://github.com/wildfly/wildfly/blob/master/ee/src/main/java/org/jboss/as/ee/subsystem/EeSubsystemAdd.java#L194
>>>> 
>>>>    Scott
>>>> 
>>>>    On 01/31/2014 06:25 AM, arjan tijms wrote:
>>>>> Hi,
>>>>> 
>>>>> I looks like there's one bug in the example.
>>>>> 
>>>>> jboss-web.xml defines jdbc/MyDS
>>>>> 
>>>>> But persistence.xml references java:comp/env/MyDS
>>>>> 
>>>>> Shouldn't the last one be at least java:comp/env/jdbc/MyDS?
>>>>    Regardless,
>>>>> even with matching names it indeed doesn't work.
>>>>> 
>>>>> Kind regards,
>>>>> Arjan Tijms
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On Thu, Jan 30, 2014 at 9:52 PM, Scott Marlow <smarlow at redhat.com
>>>>    <mailto:smarlow at redhat.com>
>>>>> <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>> wrote:
>>>>> 
>>>>>    WFLY-2841 reports a deployment failure that occurs when a
>>>>    deployments
>>>>>    [1] persistence.xml, tries to use a resource reference [2]
>>>>    for the
>>>>>    datasource [3].  The error [4] mentions an unresolved
>>>>    (DataSource)
>>>>>    service dependency that is added to the persistence unit
>>>>    service [5],
>>>>>    instead of resolving the resource reference (and using the
>>>>    underlying
>>>>>    DataSource).
>>>>> 
>>>>>    How should we handle resource references for this case?  Is
>>>>    there a way
>>>>>    to resolve the resource reference directly from deployers?
>>>>      Or do we
>>>>>    represent the resource reference as a service?
>>>>> 
>>>>>    Scott
>>>>> 
>>>>>    [1] test app is at https://github.com/umartin/wfds/
>>>>> 
>>>>>    [2] jboss-web.xml
>>>>>    <jboss-web>
>>>>>              <context-root>/wfds</context-root>
>>>>>              <resource-ref>
>>>>>                      <res-ref-name>jdbc/MyDS</res-ref-name>
>>>>>                      <res-type>javax.sql.DataSource</res-type>
>>>>> 
>>>>>      <jndi-name>java:jboss/datasources/ExampleDS</jndi-name>
>>>>>              </resource-ref>
>>>>>    </jboss-web>
>>>>> 
>>>>>    [3] persistence.xml pu def
>>>>>    <persistence-unit name="wfdsPU" transaction-type="JTA">
>>>>>              <jta-data-source>java:comp/env/MyDS</jta-data-source>
>>>>>    </persistence-unit>
>>>>> 
>>>>>    [4] {"JBAS014771: Services with missing/unavailable
>>>>    dependencies" =>
>>>>> 
>>>>    ["jboss.persistenceunit.\"wfds-1.0-SNAPSHOT.war#wfdsPU\".__FIRST_PHASE__
>>>>>    is missing
>>>>> 
>>>>    [jboss.naming.context.java.module.\"wfds-1.0-SNAPSHOT\".\"wfds-1.0-SNAPSHOT\".env.MyDS]"]}
>>>>> 
>>>>> 
>>>>>    [5]
>>>>> 
>>>>    https://github.com/wildfly/wildfly/blob/master/jpa/core/src/main/java/org/jboss/as/jpa/processor/PersistenceUnitServiceHandler.java#L358
>>>>>    _______________________________________________
>>>>>    wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>>    <mailto: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 <mailto:wildfly-dev at lists.jboss.org>
>>>>    https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> H?lsningar,
>>>> Martin Andersson
>>>> Purple Scout AB
>>>> +46 732 05 14 01
>>> 
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> 
> 



From emartins at redhat.com  Fri Jan 31 10:45:41 2014
From: emartins at redhat.com (Eduardo Martins)
Date: Fri, 31 Jan 2014 15:45:41 +0000
Subject: [wildfly-dev] How to deal with resource refs when deploying JPA
	container managed entity managers (WFLY-2841)
In-Reply-To: <CAE=-AhDVzgs3oT34HEBQSF1AQ3_e_-RM0N8SK3892xV1HjUaMg@mail.gmail.com>
References: <52EABB89.6080704@redhat.com>
	<CAE=-AhAtqZfv51+aNMiLjmixkRfSjhAFNDscXDN=0fKY6+FvOg@mail.gmail.com>
	<52EB9D27.3080904@redhat.com>
	<CACmAtJs5GXKsaYD6DfW3LT-EbJmOZ_DMZPnDbL70or_mXAqYSQ@mail.gmail.com>
	<52EBA17A.5060502@redhat.com>
	<3E8BA64D-FE33-467E-91B6-73DF0D8837BF@redhat.com>
	<CAE=-AhDVzgs3oT34HEBQSF1AQ3_e_-RM0N8SK3892xV1HjUaMg@mail.gmail.com>
Message-ID: <6414C026-A659-4510-8661-8281EA80B670@redhat.com>

Yes, but design wise this should be done at EAR level, preventing the mistake of multiple components trying to bind same entry in java:app.

?E

On 31 Jan 2014, at 15:08, arjan tijms <arjan.tijms at gmail.com> wrote:

> Hi,
> 
> On Fri, Jan 31, 2014 at 3:03 PM, Eduardo Martins <emartins at redhat.com> wrote:
> or use an ear and define a java:app bind  at application.xml, to be shared by all modules and components?
> 
> If you have just a .war, you can use java:app just as well, can't you? I don't think there's a specific need to use an ear just for java:app.
> 
> Kind regards,
> Arjan
> 
> 
> 
> 
>  
> 
> ?E
> 
> 
> On 31 Jan 2014, at 13:13, Scott Marlow <smarlow at redhat.com> wrote:
> 
> > Great, thanks for reporting the issue Martin!  Great to bring more
> > awareness of the deployment problem and workaround.
> >
> > Scott
> > On 01/31/2014 08:04 AM, Martin Andersson wrote:
> >> Thanks a lot!
> >>
> >> I can confirm that the app works now.
> >>
> >> Br,
> >> Martin Andersson
> >> Java EE developer at www.purplescout.se <http://www.purplescout.se>
> >>
> >>
> >> On Fri, Jan 31, 2014 at 1:55 PM, Scott Marlow <smarlow at redhat.com
> >> <mailto:smarlow at redhat.com>> wrote:
> >>
> >>    Hi Arjan,
> >>
> >>    Great catch!  Your change and adding an persistence unit hint that the
> >>    persistence unit doesn't need to be started early:
> >>
> >>        <property name="wildfly.jpa.twophasebootstrap" value="false"/>
> >>
> >>    Helps the deployment succeed.
> >>
> >>    It looks like ResourceReferenceProcessor is running during the
> >>    Phase.POST_MODULE deployment phase, so we need to add a hint to the
> >>    persistence.xml, that helps the persistence unit deploy later.
> >>
> >>    [6]
> >>    https://github.com/wildfly/wildfly/blob/master/ee/src/main/java/org/jboss/as/ee/subsystem/EeSubsystemAdd.java#L194
> >>
> >>    Scott
> >>
> >>    On 01/31/2014 06:25 AM, arjan tijms wrote:
> >>> Hi,
> >>>
> >>> I looks like there's one bug in the example.
> >>>
> >>> jboss-web.xml defines jdbc/MyDS
> >>>
> >>> But persistence.xml references java:comp/env/MyDS
> >>>
> >>> Shouldn't the last one be at least java:comp/env/jdbc/MyDS?
> >>    Regardless,
> >>> even with matching names it indeed doesn't work.
> >>>
> >>> Kind regards,
> >>> Arjan Tijms
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Thu, Jan 30, 2014 at 9:52 PM, Scott Marlow <smarlow at redhat.com
> >>    <mailto:smarlow at redhat.com>
> >>> <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>> wrote:
> >>>
> >>>    WFLY-2841 reports a deployment failure that occurs when a
> >>    deployments
> >>>    [1] persistence.xml, tries to use a resource reference [2]
> >>    for the
> >>>    datasource [3].  The error [4] mentions an unresolved
> >>    (DataSource)
> >>>    service dependency that is added to the persistence unit
> >>    service [5],
> >>>    instead of resolving the resource reference (and using the
> >>    underlying
> >>>    DataSource).
> >>>
> >>>    How should we handle resource references for this case?  Is
> >>    there a way
> >>>    to resolve the resource reference directly from deployers?
> >>      Or do we
> >>>    represent the resource reference as a service?
> >>>
> >>>    Scott
> >>>
> >>>    [1] test app is at https://github.com/umartin/wfds/
> >>>
> >>>    [2] jboss-web.xml
> >>>    <jboss-web>
> >>>              <context-root>/wfds</context-root>
> >>>              <resource-ref>
> >>>                      <res-ref-name>jdbc/MyDS</res-ref-name>
> >>>                      <res-type>javax.sql.DataSource</res-type>
> >>>
> >>>      <jndi-name>java:jboss/datasources/ExampleDS</jndi-name>
> >>>              </resource-ref>
> >>>    </jboss-web>
> >>>
> >>>    [3] persistence.xml pu def
> >>>    <persistence-unit name="wfdsPU" transaction-type="JTA">
> >>>              <jta-data-source>java:comp/env/MyDS</jta-data-source>
> >>>    </persistence-unit>
> >>>
> >>>    [4] {"JBAS014771: Services with missing/unavailable
> >>    dependencies" =>
> >>>
> >>    ["jboss.persistenceunit.\"wfds-1.0-SNAPSHOT.war#wfdsPU\".__FIRST_PHASE__
> >>>    is missing
> >>>
> >>    [jboss.naming.context.java.module.\"wfds-1.0-SNAPSHOT\".\"wfds-1.0-SNAPSHOT\".env.MyDS]"]}
> >>>
> >>>
> >>>    [5]
> >>>
> >>    https://github.com/wildfly/wildfly/blob/master/jpa/core/src/main/java/org/jboss/as/jpa/processor/PersistenceUnitServiceHandler.java#L358
> >>>    _______________________________________________
> >>>    wildfly-dev mailing list
> >>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
> >>    <mailto: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 <mailto:wildfly-dev at lists.jboss.org>
> >>    https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>
> >>
> >>
> >>
> >> --
> >> H?lsningar,
> >> Martin Andersson
> >> Purple Scout AB
> >> +46 732 05 14 01
> >
> > _______________________________________________
> > 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/20140131/755a83f5/attachment-0001.html 

From emartins at redhat.com  Fri Jan 31 10:52:35 2014
From: emartins at redhat.com (Eduardo Martins)
Date: Fri, 31 Jan 2014 15:52:35 +0000
Subject: [wildfly-dev] How to deal with resource refs when deploying JPA
	container managed entity managers (WFLY-2841)
In-Reply-To: <958C9A28-BF71-4850-B03C-865BD63F6489@redhat.com>
References: <52EABB89.6080704@redhat.com>
	<CAE=-AhAtqZfv51+aNMiLjmixkRfSjhAFNDscXDN=0fKY6+FvOg@mail.gmail.com>
	<52EB9D27.3080904@redhat.com>
	<CACmAtJs5GXKsaYD6DfW3LT-EbJmOZ_DMZPnDbL70or_mXAqYSQ@mail.gmail.com>
	<52EBA17A.5060502@redhat.com>
	<3E8BA64D-FE33-467E-91B6-73DF0D8837BF@redhat.com>
	<CACmAtJu=1EmmEnS06g1xD7hLw0_kc2DNpytEqMZOdeufa5aRww@mail.gmail.com>
	<958C9A28-BF71-4850-B03C-865BD63F6489@redhat.com>
Message-ID: <FADBFF78-0DF7-4E1B-BEA1-5B743D26E5B4@redhat.com>

Also usually you would ref the concrete datasource in the PU, or leave the container to use the default one, and then the web components would ref the PU, not the datasource. Had a look at your code and in fact you?re just testing the datasource in in JNDI, but relying only on the PU for the app logic.

?E

On 31 Jan 2014, at 15:31, Eduardo Martins <emartins at redhat.com> wrote:

> On 31 Jan 2014, at 14:33, Martin Andersson <martin.andersson at purplescout.se> wrote:
> 
>> I agree. I don't think mapping a datasource in jboss-web.xml is such an exotic use case. I should just work. Also, there is no hint anywere that there is a property you can set to make it work.
>> 
>> The proprietary jboss namespace is not an option since I want to be vendor neutral, but ear/java:app is definitely an option.
>> 
> 
> Well, aren?t you using it already in jboss-web xml?
> 
> ?E
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



From smarlow at redhat.com  Fri Jan 31 10:55:17 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Fri, 31 Jan 2014 10:55:17 -0500
Subject: [wildfly-dev] How to deal with resource refs when deploying JPA
 container managed entity managers (WFLY-2841)
In-Reply-To: <58F7236C-99D1-477D-A6EF-1294357BDEA0@redhat.com>
References: <52EABB89.6080704@redhat.com>	<CAE=-AhAtqZfv51+aNMiLjmixkRfSjhAFNDscXDN=0fKY6+FvOg@mail.gmail.com>	<52EB9D27.3080904@redhat.com>
	<CACmAtJs5GXKsaYD6DfW3LT-EbJmOZ_DMZPnDbL70or_mXAqYSQ@mail.gmail.com>
	<52EBA17A.5060502@redhat.com>
	<3E8BA64D-FE33-467E-91B6-73DF0D8837BF@redhat.com>
	<52EBBB9E.1080707@redhat.com>
	<58F7236C-99D1-477D-A6EF-1294357BDEA0@redhat.com>
Message-ID: <52EBC765.2030602@redhat.com>

No, since we aren't doing a JNDI lookup, instead the persistence unit 
service has a dependency on the DataSource.

https://github.com/wildfly/wildfly/blob/master/jpa/core/src/main/java/org/jboss/as/jpa/processor/PersistenceUnitServiceHandler.java#L358 
shows how we use ContextNames.bindInfoForEnvEntry().

On 01/31/2014 10:37 AM, Eduardo Martins wrote:
> Do you need the concrete Datasource resource present in JNDI at that JPA Entity class enhancing/rewriting? If that?s the case, then what if you have a PU pointing to java:comp/env/MyDatasource, inside an EJB jar with 2 EJBs, where each binds java:comp/env/MyDatasource to different concrete Datasource, which concrete Datasource will be used by the PU?
>
> ?E
>
> On 31 Jan 2014, at 15:05, Scott Marlow <smarlow at redhat.com> wrote:
>
>> JPA Entity class enhancing/rewriting needs to occur in an early deployment phase (before the application classloader is used to load the enhanced classes).
>>
>> If the ResourceReferenceProcessor ran early enough, the hint wouldn't be needed as a workaround.  There are other "if only we did things differently" involved as well.  For example, when using the Hibernate Bootstrap spi to start the persistence unit, if we moved references to the datasource to only be in the second deployment phase, that would also help (when using Hibernate).
>>
>> This is not the only case like this.  There is also implicit CDI support which uses the application classloader too early (leaving the application deployer to choose whether to use CDI in entity listeners or JPA class enhancing/rewriting).
>>
>> @DataSourceDefinition are also not available until Phase.INSTALL, so they cannot be used with applications that expect entities to be enhanced/rewritten.
>>
>> IMO, we should address these problems in the standards (EE specs).  If we can improve our deployment implementation to better deal with these "initialize me first if you want correct behaviour" situations, all the better.
>>
>> On 01/31/2014 09:03 AM, Eduardo Martins wrote:
>>> IMHO this hint should not be needed, a PU referencing a java:comp or java:module datasource is already a hint that the PU will need a resource bound by another component bundled in same jar/war.
>>>
>>> By the way I?m not really a fan of using java:comp in a PU, it sets an dependency on a EE component, and that doesn?t seem right. Wouldn't be preferable to use the original java:jboss/datasources/ExampleDS JNDI name, or use an ear and define a java:app bind  at application.xml, to be shared by all modules and components?
>>>
>>> ?E
>>>
>>>
>>> On 31 Jan 2014, at 13:13, Scott Marlow <smarlow at redhat.com> wrote:
>>>
>>>> Great, thanks for reporting the issue Martin!  Great to bring more
>>>> awareness of the deployment problem and workaround.
>>>>
>>>> Scott
>>>> On 01/31/2014 08:04 AM, Martin Andersson wrote:
>>>>> Thanks a lot!
>>>>>
>>>>> I can confirm that the app works now.
>>>>>
>>>>> Br,
>>>>> Martin Andersson
>>>>> Java EE developer at www.purplescout.se <http://www.purplescout.se>
>>>>>
>>>>>
>>>>> On Fri, Jan 31, 2014 at 1:55 PM, Scott Marlow <smarlow at redhat.com
>>>>> <mailto:smarlow at redhat.com>> wrote:
>>>>>
>>>>>     Hi Arjan,
>>>>>
>>>>>     Great catch!  Your change and adding an persistence unit hint that the
>>>>>     persistence unit doesn't need to be started early:
>>>>>
>>>>>         <property name="wildfly.jpa.twophasebootstrap" value="false"/>
>>>>>
>>>>>     Helps the deployment succeed.
>>>>>
>>>>>     It looks like ResourceReferenceProcessor is running during the
>>>>>     Phase.POST_MODULE deployment phase, so we need to add a hint to the
>>>>>     persistence.xml, that helps the persistence unit deploy later.
>>>>>
>>>>>     [6]
>>>>>     https://github.com/wildfly/wildfly/blob/master/ee/src/main/java/org/jboss/as/ee/subsystem/EeSubsystemAdd.java#L194
>>>>>
>>>>>     Scott
>>>>>
>>>>>     On 01/31/2014 06:25 AM, arjan tijms wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I looks like there's one bug in the example.
>>>>>>
>>>>>> jboss-web.xml defines jdbc/MyDS
>>>>>>
>>>>>> But persistence.xml references java:comp/env/MyDS
>>>>>>
>>>>>> Shouldn't the last one be at least java:comp/env/jdbc/MyDS?
>>>>>     Regardless,
>>>>>> even with matching names it indeed doesn't work.
>>>>>>
>>>>>> Kind regards,
>>>>>> Arjan Tijms
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Jan 30, 2014 at 9:52 PM, Scott Marlow <smarlow at redhat.com
>>>>>     <mailto:smarlow at redhat.com>
>>>>>> <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>> wrote:
>>>>>>
>>>>>>     WFLY-2841 reports a deployment failure that occurs when a
>>>>>     deployments
>>>>>>     [1] persistence.xml, tries to use a resource reference [2]
>>>>>     for the
>>>>>>     datasource [3].  The error [4] mentions an unresolved
>>>>>     (DataSource)
>>>>>>     service dependency that is added to the persistence unit
>>>>>     service [5],
>>>>>>     instead of resolving the resource reference (and using the
>>>>>     underlying
>>>>>>     DataSource).
>>>>>>
>>>>>>     How should we handle resource references for this case?  Is
>>>>>     there a way
>>>>>>     to resolve the resource reference directly from deployers?
>>>>>       Or do we
>>>>>>     represent the resource reference as a service?
>>>>>>
>>>>>>     Scott
>>>>>>
>>>>>>     [1] test app is at https://github.com/umartin/wfds/
>>>>>>
>>>>>>     [2] jboss-web.xml
>>>>>>     <jboss-web>
>>>>>>               <context-root>/wfds</context-root>
>>>>>>               <resource-ref>
>>>>>>                       <res-ref-name>jdbc/MyDS</res-ref-name>
>>>>>>                       <res-type>javax.sql.DataSource</res-type>
>>>>>>
>>>>>>       <jndi-name>java:jboss/datasources/ExampleDS</jndi-name>
>>>>>>               </resource-ref>
>>>>>>     </jboss-web>
>>>>>>
>>>>>>     [3] persistence.xml pu def
>>>>>>     <persistence-unit name="wfdsPU" transaction-type="JTA">
>>>>>>               <jta-data-source>java:comp/env/MyDS</jta-data-source>
>>>>>>     </persistence-unit>
>>>>>>
>>>>>>     [4] {"JBAS014771: Services with missing/unavailable
>>>>>     dependencies" =>
>>>>>>
>>>>>     ["jboss.persistenceunit.\"wfds-1.0-SNAPSHOT.war#wfdsPU\".__FIRST_PHASE__
>>>>>>     is missing
>>>>>>
>>>>>     [jboss.naming.context.java.module.\"wfds-1.0-SNAPSHOT\".\"wfds-1.0-SNAPSHOT\".env.MyDS]"]}
>>>>>>
>>>>>>
>>>>>>     [5]
>>>>>>
>>>>>     https://github.com/wildfly/wildfly/blob/master/jpa/core/src/main/java/org/jboss/as/jpa/processor/PersistenceUnitServiceHandler.java#L358
>>>>>>     _______________________________________________
>>>>>>     wildfly-dev mailing list
>>>>>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>>>     <mailto: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 <mailto:wildfly-dev at lists.jboss.org>
>>>>>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> H?lsningar,
>>>>> Martin Andersson
>>>>> Purple Scout AB
>>>>> +46 732 05 14 01
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>


From jason.greene at redhat.com  Fri Jan 31 11:01:42 2014
From: jason.greene at redhat.com (Jason Greene)
Date: Fri, 31 Jan 2014 10:01:42 -0600
Subject: [wildfly-dev] How to deal with resource refs when deploying JPA
	container managed entity managers (WFLY-2841)
In-Reply-To: <52EBBB9E.1080707@redhat.com>
References: <52EABB89.6080704@redhat.com>	<CAE=-AhAtqZfv51+aNMiLjmixkRfSjhAFNDscXDN=0fKY6+FvOg@mail.gmail.com>	<52EB9D27.3080904@redhat.com>
	<CACmAtJs5GXKsaYD6DfW3LT-EbJmOZ_DMZPnDbL70or_mXAqYSQ@mail.gmail.com>
	<52EBA17A.5060502@redhat.com>
	<3E8BA64D-FE33-467E-91B6-73DF0D8837BF@redhat.com>
	<52EBBB9E.1080707@redhat.com>
Message-ID: <C56AB13F-3D51-4EA1-A110-2FD9E9296DD3@redhat.com>


On Jan 31, 2014, at 9:05 AM, Scott Marlow <smarlow at redhat.com> wrote:

> JPA Entity class enhancing/rewriting needs to occur in an early 
> deployment phase (before the application classloader is used to load the 
> enhanced classes).

Yes, but this does not require access to a data source. Instrumentation simply needs to modify a small subset of classes (those marked as entities)

> If the ResourceReferenceProcessor ran early enough, the hint wouldn't be 
> needed as a workaround.  

That?s not possible because @Resource can?t be processed without the final class loader.

> There are other "if only we did things 
> differently" involved as well.  For example, when using the Hibernate 
> Bootstrap spi to start the persistence unit, if we moved references to 
> the datasource to only be in the second deployment phase, that would 
> also help (when using Hibernate).

That seems to be the real solution, and there is really no reason why a JPA provider needs to do anything with a datasource in order to know how to instrument the entity class.

> 
> This is not the only case like this.  There is also implicit CDI support 
> which uses the application classloader too early (leaving the 
> application deployer to choose whether to use CDI in entity listeners or 
> JPA class enhancing/rewriting).

I?m not sure I follow the problems with this one.

> 
> @DataSourceDefinition are also not available until Phase.INSTALL, so 
> they cannot be used with applications that expect entities to be 
> enhanced/rewritten.

That shouldn?t matter if the data source usage was in a later phase.


> 
> IMO, we should address these problems in the standards (EE specs).

I?m not sure what specific spec flaw you are referring to here, this seems to really just be an implementation problem on our side. Unless you mean the JPA SPI with the temp class loading stuff, in which case I totally agree, but we don?t have to use it with our hibernate integration anyway.


>  If 
> we can improve our deployment implementation to better deal with these 
> "initialize me first if you want correct behaviour" situations, all the 
> better.
> 
> On 01/31/2014 09:03 AM, Eduardo Martins wrote:
>> IMHO this hint should not be needed, a PU referencing a java:comp or java:module datasource is already a hint that the PU will need a resource bound by another component bundled in same jar/war.
>> 
>> By the way I?m not really a fan of using java:comp in a PU, it sets an dependency on a EE component, and that doesn?t seem right. Wouldn't be preferable to use the original java:jboss/datasources/ExampleDS JNDI name, or use an ear and define a java:app bind  at application.xml, to be shared by all modules and components?
>> 
>> ?E
>> 
>> 
>> On 31 Jan 2014, at 13:13, Scott Marlow <smarlow at redhat.com> wrote:
>> 
>>> Great, thanks for reporting the issue Martin!  Great to bring more
>>> awareness of the deployment problem and workaround.
>>> 
>>> Scott
>>> On 01/31/2014 08:04 AM, Martin Andersson wrote:
>>>> Thanks a lot!
>>>> 
>>>> I can confirm that the app works now.
>>>> 
>>>> Br,
>>>> Martin Andersson
>>>> Java EE developer at www.purplescout.se <http://www.purplescout.se>
>>>> 
>>>> 
>>>> On Fri, Jan 31, 2014 at 1:55 PM, Scott Marlow <smarlow at redhat.com
>>>> <mailto:smarlow at redhat.com>> wrote:
>>>> 
>>>>    Hi Arjan,
>>>> 
>>>>    Great catch!  Your change and adding an persistence unit hint that the
>>>>    persistence unit doesn't need to be started early:
>>>> 
>>>>        <property name="wildfly.jpa.twophasebootstrap" value="false"/>
>>>> 
>>>>    Helps the deployment succeed.
>>>> 
>>>>    It looks like ResourceReferenceProcessor is running during the
>>>>    Phase.POST_MODULE deployment phase, so we need to add a hint to the
>>>>    persistence.xml, that helps the persistence unit deploy later.
>>>> 
>>>>    [6]
>>>>    https://github.com/wildfly/wildfly/blob/master/ee/src/main/java/org/jboss/as/ee/subsystem/EeSubsystemAdd.java#L194
>>>> 
>>>>    Scott
>>>> 
>>>>    On 01/31/2014 06:25 AM, arjan tijms wrote:
>>>>> Hi,
>>>>> 
>>>>> I looks like there's one bug in the example.
>>>>> 
>>>>> jboss-web.xml defines jdbc/MyDS
>>>>> 
>>>>> But persistence.xml references java:comp/env/MyDS
>>>>> 
>>>>> Shouldn't the last one be at least java:comp/env/jdbc/MyDS?
>>>>    Regardless,
>>>>> even with matching names it indeed doesn't work.
>>>>> 
>>>>> Kind regards,
>>>>> Arjan Tijms
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On Thu, Jan 30, 2014 at 9:52 PM, Scott Marlow <smarlow at redhat.com
>>>>    <mailto:smarlow at redhat.com>
>>>>> <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>> wrote:
>>>>> 
>>>>>    WFLY-2841 reports a deployment failure that occurs when a
>>>>    deployments
>>>>>    [1] persistence.xml, tries to use a resource reference [2]
>>>>    for the
>>>>>    datasource [3].  The error [4] mentions an unresolved
>>>>    (DataSource)
>>>>>    service dependency that is added to the persistence unit
>>>>    service [5],
>>>>>    instead of resolving the resource reference (and using the
>>>>    underlying
>>>>>    DataSource).
>>>>> 
>>>>>    How should we handle resource references for this case?  Is
>>>>    there a way
>>>>>    to resolve the resource reference directly from deployers?
>>>>      Or do we
>>>>>    represent the resource reference as a service?
>>>>> 
>>>>>    Scott
>>>>> 
>>>>>    [1] test app is at https://github.com/umartin/wfds/
>>>>> 
>>>>>    [2] jboss-web.xml
>>>>>    <jboss-web>
>>>>>              <context-root>/wfds</context-root>
>>>>>              <resource-ref>
>>>>>                      <res-ref-name>jdbc/MyDS</res-ref-name>
>>>>>                      <res-type>javax.sql.DataSource</res-type>
>>>>> 
>>>>>      <jndi-name>java:jboss/datasources/ExampleDS</jndi-name>
>>>>>              </resource-ref>
>>>>>    </jboss-web>
>>>>> 
>>>>>    [3] persistence.xml pu def
>>>>>    <persistence-unit name="wfdsPU" transaction-type="JTA">
>>>>>              <jta-data-source>java:comp/env/MyDS</jta-data-source>
>>>>>    </persistence-unit>
>>>>> 
>>>>>    [4] {"JBAS014771: Services with missing/unavailable
>>>>    dependencies" =>
>>>>> 
>>>>    ["jboss.persistenceunit.\"wfds-1.0-SNAPSHOT.war#wfdsPU\".__FIRST_PHASE__
>>>>>    is missing
>>>>> 
>>>>    [jboss.naming.context.java.module.\"wfds-1.0-SNAPSHOT\".\"wfds-1.0-SNAPSHOT\".env.MyDS]"]}
>>>>> 
>>>>> 
>>>>>    [5]
>>>>> 
>>>>    https://github.com/wildfly/wildfly/blob/master/jpa/core/src/main/java/org/jboss/as/jpa/processor/PersistenceUnitServiceHandler.java#L358
>>>>>    _______________________________________________
>>>>>    wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>>    <mailto: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 <mailto:wildfly-dev at lists.jboss.org>
>>>>    https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> H?lsningar,
>>>> Martin Andersson
>>>> Purple Scout AB
>>>> +46 732 05 14 01
>>> 
>>> _______________________________________________
>>> 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

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



From emartins at redhat.com  Fri Jan 31 11:07:09 2014
From: emartins at redhat.com (Eduardo Martins)
Date: Fri, 31 Jan 2014 16:07:09 +0000
Subject: [wildfly-dev] How to deal with resource refs when deploying JPA
	container managed entity managers (WFLY-2841)
In-Reply-To: <52EBC765.2030602@redhat.com>
References: <52EABB89.6080704@redhat.com>	<CAE=-AhAtqZfv51+aNMiLjmixkRfSjhAFNDscXDN=0fKY6+FvOg@mail.gmail.com>	<52EB9D27.3080904@redhat.com>
	<CACmAtJs5GXKsaYD6DfW3LT-EbJmOZ_DMZPnDbL70or_mXAqYSQ@mail.gmail.com>
	<52EBA17A.5060502@redhat.com>
	<3E8BA64D-FE33-467E-91B6-73DF0D8837BF@redhat.com>
	<52EBBB9E.1080707@redhat.com>
	<58F7236C-99D1-477D-A6EF-1294357BDEA0@redhat.com>
	<52EBC765.2030602@redhat.com>
Message-ID: <EF3347C8-5675-40F7-AAF9-420287AF904E@redhat.com>

That is something that should be fixed, since it does not supports JNDI Federation or link refs. A lookup should be done, and this should be achieved by using a LookupResourceInjection, not MSC services directly. But that?s not everything I guess, if we want to support java:comp in PUs properly, then I see no other way than looking up the concrete datasource when the entity manager is provided to the app.

?E

On 31 Jan 2014, at 15:55, Scott Marlow <smarlow at redhat.com> wrote:

> No, since we aren't doing a JNDI lookup, instead the persistence unit service has a dependency on the DataSource.
> 
> https://github.com/wildfly/wildfly/blob/master/jpa/core/src/main/java/org/jboss/as/jpa/processor/PersistenceUnitServiceHandler.java#L358 shows how we use ContextNames.bindInfoForEnvEntry().
> 
> On 01/31/2014 10:37 AM, Eduardo Martins wrote:
>> Do you need the concrete Datasource resource present in JNDI at that JPA Entity class enhancing/rewriting? If that?s the case, then what if you have a PU pointing to java:comp/env/MyDatasource, inside an EJB jar with 2 EJBs, where each binds java:comp/env/MyDatasource to different concrete Datasource, which concrete Datasource will be used by the PU?
>> 
>> ?E
>> 
>> On 31 Jan 2014, at 15:05, Scott Marlow <smarlow at redhat.com> wrote:
>> 
>>> JPA Entity class enhancing/rewriting needs to occur in an early deployment phase (before the application classloader is used to load the enhanced classes).
>>> 
>>> If the ResourceReferenceProcessor ran early enough, the hint wouldn't be needed as a workaround.  There are other "if only we did things differently" involved as well.  For example, when using the Hibernate Bootstrap spi to start the persistence unit, if we moved references to the datasource to only be in the second deployment phase, that would also help (when using Hibernate).
>>> 
>>> This is not the only case like this.  There is also implicit CDI support which uses the application classloader too early (leaving the application deployer to choose whether to use CDI in entity listeners or JPA class enhancing/rewriting).
>>> 
>>> @DataSourceDefinition are also not available until Phase.INSTALL, so they cannot be used with applications that expect entities to be enhanced/rewritten.
>>> 
>>> IMO, we should address these problems in the standards (EE specs).  If we can improve our deployment implementation to better deal with these "initialize me first if you want correct behaviour" situations, all the better.
>>> 
>>> On 01/31/2014 09:03 AM, Eduardo Martins wrote:
>>>> IMHO this hint should not be needed, a PU referencing a java:comp or java:module datasource is already a hint that the PU will need a resource bound by another component bundled in same jar/war.
>>>> 
>>>> By the way I?m not really a fan of using java:comp in a PU, it sets an dependency on a EE component, and that doesn?t seem right. Wouldn't be preferable to use the original java:jboss/datasources/ExampleDS JNDI name, or use an ear and define a java:app bind  at application.xml, to be shared by all modules and components?
>>>> 
>>>> ?E
>>>> 
>>>> 
>>>> On 31 Jan 2014, at 13:13, Scott Marlow <smarlow at redhat.com> wrote:
>>>> 
>>>>> Great, thanks for reporting the issue Martin!  Great to bring more
>>>>> awareness of the deployment problem and workaround.
>>>>> 
>>>>> Scott
>>>>> On 01/31/2014 08:04 AM, Martin Andersson wrote:
>>>>>> Thanks a lot!
>>>>>> 
>>>>>> I can confirm that the app works now.
>>>>>> 
>>>>>> Br,
>>>>>> Martin Andersson
>>>>>> Java EE developer at www.purplescout.se <http://www.purplescout.se>
>>>>>> 
>>>>>> 
>>>>>> On Fri, Jan 31, 2014 at 1:55 PM, Scott Marlow <smarlow at redhat.com
>>>>>> <mailto:smarlow at redhat.com>> wrote:
>>>>>> 
>>>>>>    Hi Arjan,
>>>>>> 
>>>>>>    Great catch!  Your change and adding an persistence unit hint that the
>>>>>>    persistence unit doesn't need to be started early:
>>>>>> 
>>>>>>        <property name="wildfly.jpa.twophasebootstrap" value="false"/>
>>>>>> 
>>>>>>    Helps the deployment succeed.
>>>>>> 
>>>>>>    It looks like ResourceReferenceProcessor is running during the
>>>>>>    Phase.POST_MODULE deployment phase, so we need to add a hint to the
>>>>>>    persistence.xml, that helps the persistence unit deploy later.
>>>>>> 
>>>>>>    [6]
>>>>>>    https://github.com/wildfly/wildfly/blob/master/ee/src/main/java/org/jboss/as/ee/subsystem/EeSubsystemAdd.java#L194
>>>>>> 
>>>>>>    Scott
>>>>>> 
>>>>>>    On 01/31/2014 06:25 AM, arjan tijms wrote:
>>>>>>> Hi,
>>>>>>> 
>>>>>>> I looks like there's one bug in the example.
>>>>>>> 
>>>>>>> jboss-web.xml defines jdbc/MyDS
>>>>>>> 
>>>>>>> But persistence.xml references java:comp/env/MyDS
>>>>>>> 
>>>>>>> Shouldn't the last one be at least java:comp/env/jdbc/MyDS?
>>>>>>    Regardless,
>>>>>>> even with matching names it indeed doesn't work.
>>>>>>> 
>>>>>>> Kind regards,
>>>>>>> Arjan Tijms
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On Thu, Jan 30, 2014 at 9:52 PM, Scott Marlow <smarlow at redhat.com
>>>>>>    <mailto:smarlow at redhat.com>
>>>>>>> <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>> wrote:
>>>>>>> 
>>>>>>>    WFLY-2841 reports a deployment failure that occurs when a
>>>>>>    deployments
>>>>>>>    [1] persistence.xml, tries to use a resource reference [2]
>>>>>>    for the
>>>>>>>    datasource [3].  The error [4] mentions an unresolved
>>>>>>    (DataSource)
>>>>>>>    service dependency that is added to the persistence unit
>>>>>>    service [5],
>>>>>>>    instead of resolving the resource reference (and using the
>>>>>>    underlying
>>>>>>>    DataSource).
>>>>>>> 
>>>>>>>    How should we handle resource references for this case?  Is
>>>>>>    there a way
>>>>>>>    to resolve the resource reference directly from deployers?
>>>>>>      Or do we
>>>>>>>    represent the resource reference as a service?
>>>>>>> 
>>>>>>>    Scott
>>>>>>> 
>>>>>>>    [1] test app is at https://github.com/umartin/wfds/
>>>>>>> 
>>>>>>>    [2] jboss-web.xml
>>>>>>>    <jboss-web>
>>>>>>>              <context-root>/wfds</context-root>
>>>>>>>              <resource-ref>
>>>>>>>                      <res-ref-name>jdbc/MyDS</res-ref-name>
>>>>>>>                      <res-type>javax.sql.DataSource</res-type>
>>>>>>> 
>>>>>>>      <jndi-name>java:jboss/datasources/ExampleDS</jndi-name>
>>>>>>>              </resource-ref>
>>>>>>>    </jboss-web>
>>>>>>> 
>>>>>>>    [3] persistence.xml pu def
>>>>>>>    <persistence-unit name="wfdsPU" transaction-type="JTA">
>>>>>>>              <jta-data-source>java:comp/env/MyDS</jta-data-source>
>>>>>>>    </persistence-unit>
>>>>>>> 
>>>>>>>    [4] {"JBAS014771: Services with missing/unavailable
>>>>>>    dependencies" =>
>>>>>>> 
>>>>>>    ["jboss.persistenceunit.\"wfds-1.0-SNAPSHOT.war#wfdsPU\".__FIRST_PHASE__
>>>>>>>    is missing
>>>>>>> 
>>>>>>    [jboss.naming.context.java.module.\"wfds-1.0-SNAPSHOT\".\"wfds-1.0-SNAPSHOT\".env.MyDS]"]}
>>>>>>> 
>>>>>>> 
>>>>>>>    [5]
>>>>>>> 
>>>>>>    https://github.com/wildfly/wildfly/blob/master/jpa/core/src/main/java/org/jboss/as/jpa/processor/PersistenceUnitServiceHandler.java#L358
>>>>>>>    _______________________________________________
>>>>>>>    wildfly-dev mailing list
>>>>>>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>>>>    <mailto: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 <mailto:wildfly-dev at lists.jboss.org>
>>>>>>    https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> H?lsningar,
>>>>>> Martin Andersson
>>>>>> Purple Scout AB
>>>>>> +46 732 05 14 01
>>>>> 
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>> 
>>> 
>> 
> 



From martin.andersson at purplescout.se  Fri Jan 31 11:11:31 2014
From: martin.andersson at purplescout.se (Martin Andersson)
Date: Fri, 31 Jan 2014 17:11:31 +0100
Subject: [wildfly-dev] How to deal with resource refs when deploying JPA
 container managed entity managers (WFLY-2841)
In-Reply-To: <958C9A28-BF71-4850-B03C-865BD63F6489@redhat.com>
References: <52EABB89.6080704@redhat.com>
	<CAE=-AhAtqZfv51+aNMiLjmixkRfSjhAFNDscXDN=0fKY6+FvOg@mail.gmail.com>
	<52EB9D27.3080904@redhat.com>
	<CACmAtJs5GXKsaYD6DfW3LT-EbJmOZ_DMZPnDbL70or_mXAqYSQ@mail.gmail.com>
	<52EBA17A.5060502@redhat.com>
	<3E8BA64D-FE33-467E-91B6-73DF0D8837BF@redhat.com>
	<CACmAtJu=1EmmEnS06g1xD7hLw0_kc2DNpytEqMZOdeufa5aRww@mail.gmail.com>
	<958C9A28-BF71-4850-B03C-865BD63F6489@redhat.com>
Message-ID: <CACmAtJuYm0Q_4iR5-V5DmjoqOBrachersimrhJd+=jod=99txw@mail.gmail.com>

Yes. But I can add deployment descriptors for other application servers and
have the same binary run in both production and dev setups.

Br,
Martin Andersson
Java EE developer at www.purplescout.se



On Fri, Jan 31, 2014 at 4:31 PM, Eduardo Martins <emartins at redhat.com>wrote:

> On 31 Jan 2014, at 14:33, Martin Andersson <
> martin.andersson at purplescout.se> wrote:
>
> > I agree. I don't think mapping a datasource in jboss-web.xml is such an
> exotic use case. I should just work. Also, there is no hint anywere that
> there is a property you can set to make it work.
> >
> > The proprietary jboss namespace is not an option since I want to be
> vendor neutral, but ear/java:app is definitely an option.
> >
>
> Well, aren't you using it already in jboss-web xml?
>
> --E




-- 
H?lsningar,
Martin Andersson
Purple Scout AB
+46 732 05 14 01
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140131/34000b19/attachment.html 

From arjan.tijms at gmail.com  Fri Jan 31 11:13:42 2014
From: arjan.tijms at gmail.com (arjan tijms)
Date: Fri, 31 Jan 2014 17:13:42 +0100
Subject: [wildfly-dev] How to deal with resource refs when deploying JPA
 container managed entity managers (WFLY-2841)
In-Reply-To: <6414C026-A659-4510-8661-8281EA80B670@redhat.com>
References: <52EABB89.6080704@redhat.com>
	<CAE=-AhAtqZfv51+aNMiLjmixkRfSjhAFNDscXDN=0fKY6+FvOg@mail.gmail.com>
	<52EB9D27.3080904@redhat.com>
	<CACmAtJs5GXKsaYD6DfW3LT-EbJmOZ_DMZPnDbL70or_mXAqYSQ@mail.gmail.com>
	<52EBA17A.5060502@redhat.com>
	<3E8BA64D-FE33-467E-91B6-73DF0D8837BF@redhat.com>
	<CAE=-AhDVzgs3oT34HEBQSF1AQ3_e_-RM0N8SK3892xV1HjUaMg@mail.gmail.com>
	<6414C026-A659-4510-8661-8281EA80B670@redhat.com>
Message-ID: <CAE=-AhA3wS2+G0+eFGB+qOSREWhwrSQ0+igmNmRggmCbi8_rTg@mail.gmail.com>

Hi,

On Fri, Jan 31, 2014 at 4:45 PM, Eduardo Martins <emartins at redhat.com>wrote:

> Yes, but design wise this should be done at EAR level, preventing the
> mistake of multiple components trying to bind same entry in java:app.
>

Is that really true if there only ever is the .war? E.g. in the sense as
mentioned by Adam here:
http://adam-bien.com/roller/abien/entry/is_java_ee_6_war

Also, don't EJBs inside a .war share java:comp with the web module's single
java:comp? So the entire concept of EJB beans having their own component
namespace just goes away then. I think in the modern usage pattern of EJBs
there's not much use for this anyway. If the CDI bean model effectively
replaces the EJB component model in some future Java EE release then all of
this is surely history.

Effectively, in a pure web application (.war, no .ear involved) java:comp
is effectively java:module, which should be more straightforward to
resolve, shouldn't it?


On Fri, Jan 31, 2014 at 4:45 PM, Eduardo Martins <emartins at redhat.com>wrote:

> Yes, but design wise this should be done at EAR level, preventing the
> mistake of multiple components trying to bind same entry in java:app.
>
> --E
>
> On 31 Jan 2014, at 15:08, arjan tijms <arjan.tijms at gmail.com> wrote:
>
> Hi,
>
> On Fri, Jan 31, 2014 at 3:03 PM, Eduardo Martins <emartins at redhat.com>wrote:
>
>> or use an ear and define a java:app bind  at application.xml, to be
>> shared by all modules and components?
>>
>
> If you have just a .war, you can use java:app just as well, can't you? I
> don't think there's a specific need to use an ear just for java:app.
>
> Kind regards,
> Arjan
>
>
>
>
>
>
>>
>> --E
>>
>>
>> On 31 Jan 2014, at 13:13, Scott Marlow <smarlow at redhat.com> wrote:
>>
>> > Great, thanks for reporting the issue Martin!  Great to bring more
>> > awareness of the deployment problem and workaround.
>> >
>> > Scott
>> > On 01/31/2014 08:04 AM, Martin Andersson wrote:
>> >> Thanks a lot!
>> >>
>> >> I can confirm that the app works now.
>> >>
>> >> Br,
>> >> Martin Andersson
>> >> Java EE developer at www.purplescout.se <http://www.purplescout.se>
>> >>
>> >>
>> >> On Fri, Jan 31, 2014 at 1:55 PM, Scott Marlow <smarlow at redhat.com
>> >> <mailto:smarlow at redhat.com>> wrote:
>> >>
>> >>    Hi Arjan,
>> >>
>> >>    Great catch!  Your change and adding an persistence unit hint that
>> the
>> >>    persistence unit doesn't need to be started early:
>> >>
>> >>        <property name="wildfly.jpa.twophasebootstrap" value="false"/>
>> >>
>> >>    Helps the deployment succeed.
>> >>
>> >>    It looks like ResourceReferenceProcessor is running during the
>> >>    Phase.POST_MODULE deployment phase, so we need to add a hint to the
>> >>    persistence.xml, that helps the persistence unit deploy later.
>> >>
>> >>    [6]
>> >>
>> https://github.com/wildfly/wildfly/blob/master/ee/src/main/java/org/jboss/as/ee/subsystem/EeSubsystemAdd.java#L194
>> >>
>> >>    Scott
>> >>
>> >>    On 01/31/2014 06:25 AM, arjan tijms wrote:
>> >>> Hi,
>> >>>
>> >>> I looks like there's one bug in the example.
>> >>>
>> >>> jboss-web.xml defines jdbc/MyDS
>> >>>
>> >>> But persistence.xml references java:comp/env/MyDS
>> >>>
>> >>> Shouldn't the last one be at least java:comp/env/jdbc/MyDS?
>> >>    Regardless,
>> >>> even with matching names it indeed doesn't work.
>> >>>
>> >>> Kind regards,
>> >>> Arjan Tijms
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On Thu, Jan 30, 2014 at 9:52 PM, Scott Marlow <smarlow at redhat.com
>> >>    <mailto:smarlow at redhat.com>
>> >>> <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>> wrote:
>> >>>
>> >>>    WFLY-2841 reports a deployment failure that occurs when a
>> >>    deployments
>> >>>    [1] persistence.xml, tries to use a resource reference [2]
>> >>    for the
>> >>>    datasource [3].  The error [4] mentions an unresolved
>> >>    (DataSource)
>> >>>    service dependency that is added to the persistence unit
>> >>    service [5],
>> >>>    instead of resolving the resource reference (and using the
>> >>    underlying
>> >>>    DataSource).
>> >>>
>> >>>    How should we handle resource references for this case?  Is
>> >>    there a way
>> >>>    to resolve the resource reference directly from deployers?
>> >>      Or do we
>> >>>    represent the resource reference as a service?
>> >>>
>> >>>    Scott
>> >>>
>> >>>    [1] test app is at https://github.com/umartin/wfds/
>> >>>
>> >>>    [2] jboss-web.xml
>> >>>    <jboss-web>
>> >>>              <context-root>/wfds</context-root>
>> >>>              <resource-ref>
>> >>>                      <res-ref-name>jdbc/MyDS</res-ref-name>
>> >>>                      <res-type>javax.sql.DataSource</res-type>
>> >>>
>> >>>      <jndi-name>java:jboss/datasources/ExampleDS</jndi-name>
>> >>>              </resource-ref>
>> >>>    </jboss-web>
>> >>>
>> >>>    [3] persistence.xml pu def
>> >>>    <persistence-unit name="wfdsPU" transaction-type="JTA">
>> >>>              <jta-data-source>java:comp/env/MyDS</jta-data-source>
>> >>>    </persistence-unit>
>> >>>
>> >>>    [4] {"JBAS014771: Services with missing/unavailable
>> >>    dependencies" =>
>> >>>
>> >>
>>  ["jboss.persistenceunit.\"wfds-1.0-SNAPSHOT.war#wfdsPU\".__FIRST_PHASE__
>> >>>    is missing
>> >>>
>> >>
>>  [jboss.naming.context.java.module.\"wfds-1.0-SNAPSHOT\".\"wfds-1.0-SNAPSHOT\".env.MyDS]"]}
>> >>>
>> >>>
>> >>>    [5]
>> >>>
>> >>
>> https://github.com/wildfly/wildfly/blob/master/jpa/core/src/main/java/org/jboss/as/jpa/processor/PersistenceUnitServiceHandler.java#L358
>> >>>    _______________________________________________
>> >>>    wildfly-dev mailing list
>> >>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>> >>    <mailto: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 <mailto:wildfly-dev at lists.jboss.org>
>> >>    https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> H?lsningar,
>> >> Martin Andersson
>> >> Purple Scout AB
>> >> +46 732 05 14 01
>> >
>> > _______________________________________________
>> > 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/20140131/26779097/attachment.html 

From emartins at redhat.com  Fri Jan 31 11:16:58 2014
From: emartins at redhat.com (Eduardo Martins)
Date: Fri, 31 Jan 2014 16:16:58 +0000
Subject: [wildfly-dev] How to deal with resource refs when deploying JPA
	container managed entity managers (WFLY-2841)
In-Reply-To: <CACmAtJuYm0Q_4iR5-V5DmjoqOBrachersimrhJd+=jod=99txw@mail.gmail.com>
References: <52EABB89.6080704@redhat.com>
	<CAE=-AhAtqZfv51+aNMiLjmixkRfSjhAFNDscXDN=0fKY6+FvOg@mail.gmail.com>
	<52EB9D27.3080904@redhat.com>
	<CACmAtJs5GXKsaYD6DfW3LT-EbJmOZ_DMZPnDbL70or_mXAqYSQ@mail.gmail.com>
	<52EBA17A.5060502@redhat.com>
	<3E8BA64D-FE33-467E-91B6-73DF0D8837BF@redhat.com>
	<CACmAtJu=1EmmEnS06g1xD7hLw0_kc2DNpytEqMZOdeufa5aRww@mail.gmail.com>
	<958C9A28-BF71-4850-B03C-865BD63F6489@redhat.com>
	<CACmAtJuYm0Q_4iR5-V5DmjoqOBrachersimrhJd+=jod=99txw@mail.gmail.com>
Message-ID: <BB04B1CE-109D-4F22-B134-3B11B81D1C9B@redhat.com>

Sounds a bit like an old school java ee hack, wouldn?t be better to just bind the datasource at a java:global entry?

?E

On 31 Jan 2014, at 16:11, Martin Andersson <martin.andersson at purplescout.se> wrote:

> Yes. But I can add deployment descriptors for other application servers and have the same binary run in both production and dev setups.
> Br,
> Martin Andersson
> Java EE developer at www.purplescout.se
> 
> 
> On Fri, Jan 31, 2014 at 4:31 PM, Eduardo Martins <emartins at redhat.com> wrote:
> On 31 Jan 2014, at 14:33, Martin Andersson <martin.andersson at purplescout.se> wrote:
> 
> > I agree. I don't think mapping a datasource in jboss-web.xml is such an exotic use case. I should just work. Also, there is no hint anywere that there is a property you can set to make it work.
> >
> > The proprietary jboss namespace is not an option since I want to be vendor neutral, but ear/java:app is definitely an option.
> >
> 
> Well, aren?t you using it already in jboss-web xml?
> 
> ?E
> 
> 
> 
> -- 
> H?lsningar,
> Martin Andersson
> Purple Scout AB
> +46 732 05 14 01

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

From arjan.tijms at gmail.com  Fri Jan 31 11:17:22 2014
From: arjan.tijms at gmail.com (arjan tijms)
Date: Fri, 31 Jan 2014 17:17:22 +0100
Subject: [wildfly-dev] How to deal with resource refs when deploying JPA
 container managed entity managers (WFLY-2841)
In-Reply-To: <AFC5DA87-4CBD-4BD7-AAC9-74727DE096EB@redhat.com>
References: <52EABB89.6080704@redhat.com>
	<CAE=-AhAtqZfv51+aNMiLjmixkRfSjhAFNDscXDN=0fKY6+FvOg@mail.gmail.com>
	<52EB9D27.3080904@redhat.com>
	<CACmAtJs5GXKsaYD6DfW3LT-EbJmOZ_DMZPnDbL70or_mXAqYSQ@mail.gmail.com>
	<52EBA17A.5060502@redhat.com>
	<3E8BA64D-FE33-467E-91B6-73DF0D8837BF@redhat.com>
	<CAE=-AhDVzgs3oT34HEBQSF1AQ3_e_-RM0N8SK3892xV1HjUaMg@mail.gmail.com>
	<6414C026-A659-4510-8661-8281EA80B670@redhat.com>
	<CAE=-AhAGoGmrOeXk-98Gwd-dM6dreJ9Z-uYQv6O-tKVFHSB7gA@mail.gmail.com>
	<AFC5DA87-4CBD-4BD7-AAC9-74727DE096EB@redhat.com>
Message-ID: <CAE=-AhB3RScRWGZwR2YO-cxY5Eaeq-7jXZHGfxMDMb0CicDtBw@mail.gmail.com>

On Fri, Jan 31, 2014 at 5:11 PM, Eduardo Martins <emartins at redhat.com>wrote:

> Sure, all you said is correct, I just said that ideally java:app bindings
> should be done at app level, and provide the reasoning behind that.
>

Indeed, but then if there's only ever a war then web.xml is at the app
level, and java:app bindings can be set without architectural concerns in
web.xml, can't they?





>
> --E
>
> On 31 Jan 2014, at 15:58, arjan tijms <arjan.tijms at gmail.com> wrote:
>
> Hi,
>
> On Fri, Jan 31, 2014 at 4:45 PM, Eduardo Martins <emartins at redhat.com>wrote:
>
>> Yes, but design wise this should be done at EAR level, preventing the
>> mistake of multiple components trying to bind same entry in java:app.
>>
>
> Is that really true if there only ever is the .war? E.g. in the sense as
> mentioned by Adam here:
> http://adam-bien.com/roller/abien/entry/is_java_ee_6_war
>
> Also, don't EJBs inside a .war share java:comp with the web module's
> single java:comp? So the entire concept of EJB beans having their own
> component namespace just goes away then. I think in the modern usage
> pattern of EJBs there's not much use for this anyway. If the CDI bean model
> effectively replaces the EJB component model in some future Java EE release
> then all of this is surely history.
>
> Effectively, in a pure web application (.war, no .ear involved) java:comp
> is effectively java:module, which should be more straightforward to
> resolve, shouldn't it?
>
>
>
>
>
>
>
>>
>> --E
>>
>> On 31 Jan 2014, at 15:08, arjan tijms <arjan.tijms at gmail.com> wrote:
>>
>> Hi,
>>
>> On Fri, Jan 31, 2014 at 3:03 PM, Eduardo Martins <emartins at redhat.com>wrote:
>>
>>> or use an ear and define a java:app bind  at application.xml, to be
>>> shared by all modules and components?
>>>
>>
>> If you have just a .war, you can use java:app just as well, can't you? I
>> don't think there's a specific need to use an ear just for java:app.
>>
>> Kind regards,
>> Arjan
>>
>>
>>
>>
>>
>>
>>>
>>> --E
>>>
>>>
>>> On 31 Jan 2014, at 13:13, Scott Marlow <smarlow at redhat.com> wrote:
>>>
>>> > Great, thanks for reporting the issue Martin!  Great to bring more
>>> > awareness of the deployment problem and workaround.
>>> >
>>> > Scott
>>> > On 01/31/2014 08:04 AM, Martin Andersson wrote:
>>> >> Thanks a lot!
>>> >>
>>> >> I can confirm that the app works now.
>>> >>
>>> >> Br,
>>> >> Martin Andersson
>>> >> Java EE developer at www.purplescout.se <http://www.purplescout.se>
>>> >>
>>> >>
>>> >> On Fri, Jan 31, 2014 at 1:55 PM, Scott Marlow <smarlow at redhat.com
>>> >> <mailto:smarlow at redhat.com>> wrote:
>>> >>
>>> >>    Hi Arjan,
>>> >>
>>> >>    Great catch!  Your change and adding an persistence unit hint that
>>> the
>>> >>    persistence unit doesn't need to be started early:
>>> >>
>>> >>        <property name="wildfly.jpa.twophasebootstrap" value="false"/>
>>> >>
>>> >>    Helps the deployment succeed.
>>> >>
>>> >>    It looks like ResourceReferenceProcessor is running during the
>>> >>    Phase.POST_MODULE deployment phase, so we need to add a hint to the
>>> >>    persistence.xml, that helps the persistence unit deploy later.
>>> >>
>>> >>    [6]
>>> >>
>>> https://github.com/wildfly/wildfly/blob/master/ee/src/main/java/org/jboss/as/ee/subsystem/EeSubsystemAdd.java#L194
>>> >>
>>> >>    Scott
>>> >>
>>> >>    On 01/31/2014 06:25 AM, arjan tijms wrote:
>>> >>> Hi,
>>> >>>
>>> >>> I looks like there's one bug in the example.
>>> >>>
>>> >>> jboss-web.xml defines jdbc/MyDS
>>> >>>
>>> >>> But persistence.xml references java:comp/env/MyDS
>>> >>>
>>> >>> Shouldn't the last one be at least java:comp/env/jdbc/MyDS?
>>> >>    Regardless,
>>> >>> even with matching names it indeed doesn't work.
>>> >>>
>>> >>> Kind regards,
>>> >>> Arjan Tijms
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Thu, Jan 30, 2014 at 9:52 PM, Scott Marlow <smarlow at redhat.com
>>> >>    <mailto:smarlow at redhat.com>
>>> >>> <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>> wrote:
>>> >>>
>>> >>>    WFLY-2841 reports a deployment failure that occurs when a
>>> >>    deployments
>>> >>>    [1] persistence.xml, tries to use a resource reference [2]
>>> >>    for the
>>> >>>    datasource [3].  The error [4] mentions an unresolved
>>> >>    (DataSource)
>>> >>>    service dependency that is added to the persistence unit
>>> >>    service [5],
>>> >>>    instead of resolving the resource reference (and using the
>>> >>    underlying
>>> >>>    DataSource).
>>> >>>
>>> >>>    How should we handle resource references for this case?  Is
>>> >>    there a way
>>> >>>    to resolve the resource reference directly from deployers?
>>> >>      Or do we
>>> >>>    represent the resource reference as a service?
>>> >>>
>>> >>>    Scott
>>> >>>
>>> >>>    [1] test app is at https://github.com/umartin/wfds/
>>> >>>
>>> >>>    [2] jboss-web.xml
>>> >>>    <jboss-web>
>>> >>>              <context-root>/wfds</context-root>
>>> >>>              <resource-ref>
>>> >>>                      <res-ref-name>jdbc/MyDS</res-ref-name>
>>> >>>                      <res-type>javax.sql.DataSource</res-type>
>>> >>>
>>> >>>      <jndi-name>java:jboss/datasources/ExampleDS</jndi-name>
>>> >>>              </resource-ref>
>>> >>>    </jboss-web>
>>> >>>
>>> >>>    [3] persistence.xml pu def
>>> >>>    <persistence-unit name="wfdsPU" transaction-type="JTA">
>>> >>>              <jta-data-source>java:comp/env/MyDS</jta-data-source>
>>> >>>    </persistence-unit>
>>> >>>
>>> >>>    [4] {"JBAS014771: Services with missing/unavailable
>>> >>    dependencies" =>
>>> >>>
>>> >>
>>>  ["jboss.persistenceunit.\"wfds-1.0-SNAPSHOT.war#wfdsPU\".__FIRST_PHASE__
>>> >>>    is missing
>>> >>>
>>> >>
>>>  [jboss.naming.context.java.module.\"wfds-1.0-SNAPSHOT\".\"wfds-1.0-SNAPSHOT\".env.MyDS]"]}
>>> >>>
>>> >>>
>>> >>>    [5]
>>> >>>
>>> >>
>>> https://github.com/wildfly/wildfly/blob/master/jpa/core/src/main/java/org/jboss/as/jpa/processor/PersistenceUnitServiceHandler.java#L358
>>> >>>    _______________________________________________
>>> >>>    wildfly-dev mailing list
>>> >>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>> >>    <mailto: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 <mailto:wildfly-dev at lists.jboss.org>
>>> >>    https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> H?lsningar,
>>> >> Martin Andersson
>>> >> Purple Scout AB
>>> >> +46 732 05 14 01
>>> >
>>> > _______________________________________________
>>> > 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/20140131/d6b243bc/attachment.html 

From emartins at redhat.com  Fri Jan 31 11:20:24 2014
From: emartins at redhat.com (Eduardo Martins)
Date: Fri, 31 Jan 2014 16:20:24 +0000
Subject: [wildfly-dev] How to deal with resource refs when deploying JPA
	container managed entity managers (WFLY-2841)
In-Reply-To: <CAE=-AhB3RScRWGZwR2YO-cxY5Eaeq-7jXZHGfxMDMb0CicDtBw@mail.gmail.com>
References: <52EABB89.6080704@redhat.com>
	<CAE=-AhAtqZfv51+aNMiLjmixkRfSjhAFNDscXDN=0fKY6+FvOg@mail.gmail.com>
	<52EB9D27.3080904@redhat.com>
	<CACmAtJs5GXKsaYD6DfW3LT-EbJmOZ_DMZPnDbL70or_mXAqYSQ@mail.gmail.com>
	<52EBA17A.5060502@redhat.com>
	<3E8BA64D-FE33-467E-91B6-73DF0D8837BF@redhat.com>
	<CAE=-AhDVzgs3oT34HEBQSF1AQ3_e_-RM0N8SK3892xV1HjUaMg@mail.gmail.com>
	<6414C026-A659-4510-8661-8281EA80B670@redhat.com>
	<CAE=-AhAGoGmrOeXk-98Gwd-dM6dreJ9Z-uYQv6O-tKVFHSB7gA@mail.gmail.com>
	<AFC5DA87-4CBD-4BD7-AAC9-74727DE096EB@redhat.com>
	<CAE=-AhB3RScRWGZwR2YO-cxY5Eaeq-7jXZHGfxMDMb0CicDtBw@mail.gmail.com>
Message-ID: <391E3D2F-F1C2-4609-BFAA-621EB338057D@redhat.com>

I think in that case you should use java:module, what if you later put that war in a ear with other modules? IMHO you should use the proper scope of each standard JNDI context.

?E

On 31 Jan 2014, at 16:17, arjan tijms <arjan.tijms at gmail.com> wrote:

> 
> On Fri, Jan 31, 2014 at 5:11 PM, Eduardo Martins <emartins at redhat.com> wrote:
> Sure, all you said is correct, I just said that ideally java:app bindings should be done at app level, and provide the reasoning behind that.
> 
> Indeed, but then if there's only ever a war then web.xml is at the app level, and java:app bindings can be set without architectural concerns in web.xml, can't they?
> 
> 
> 
>  
> 
> ?E  
> 
> On 31 Jan 2014, at 15:58, arjan tijms <arjan.tijms at gmail.com> wrote:
> 
>> Hi,
>> 
>> On Fri, Jan 31, 2014 at 4:45 PM, Eduardo Martins <emartins at redhat.com> wrote:
>> Yes, but design wise this should be done at EAR level, preventing the mistake of multiple components trying to bind same entry in java:app.
>> 
>> Is that really true if there only ever is the .war? E.g. in the sense as mentioned by Adam here: http://adam-bien.com/roller/abien/entry/is_java_ee_6_war
>> 
>> Also, don't EJBs inside a .war share java:comp with the web module's single java:comp? So the entire concept of EJB beans having their own component namespace just goes away then. I think in the modern usage pattern of EJBs there's not much use for this anyway. If the CDI bean model effectively replaces the EJB component model in some future Java EE release then all of this is surely history.
>> 
>> Effectively, in a pure web application (.war, no .ear involved) java:comp is effectively java:module, which should be more straightforward to resolve, shouldn't it?
>> 
>> 
>> 
>> 
>> 
>>  
>> 
>> ?E
>> 
>> On 31 Jan 2014, at 15:08, arjan tijms <arjan.tijms at gmail.com> wrote:
>> 
>>> Hi,
>>> 
>>> On Fri, Jan 31, 2014 at 3:03 PM, Eduardo Martins <emartins at redhat.com> wrote:
>>> or use an ear and define a java:app bind  at application.xml, to be shared by all modules and components?
>>> 
>>> If you have just a .war, you can use java:app just as well, can't you? I don't think there's a specific need to use an ear just for java:app.
>>> 
>>> Kind regards,
>>> Arjan
>>> 
>>> 
>>> 
>>> 
>>>  
>>> 
>>> ?E
>>> 
>>> 
>>> On 31 Jan 2014, at 13:13, Scott Marlow <smarlow at redhat.com> wrote:
>>> 
>>> > Great, thanks for reporting the issue Martin!  Great to bring more
>>> > awareness of the deployment problem and workaround.
>>> >
>>> > Scott
>>> > On 01/31/2014 08:04 AM, Martin Andersson wrote:
>>> >> Thanks a lot!
>>> >>
>>> >> I can confirm that the app works now.
>>> >>
>>> >> Br,
>>> >> Martin Andersson
>>> >> Java EE developer at www.purplescout.se <http://www.purplescout.se>
>>> >>
>>> >>
>>> >> On Fri, Jan 31, 2014 at 1:55 PM, Scott Marlow <smarlow at redhat.com
>>> >> <mailto:smarlow at redhat.com>> wrote:
>>> >>
>>> >>    Hi Arjan,
>>> >>
>>> >>    Great catch!  Your change and adding an persistence unit hint that the
>>> >>    persistence unit doesn't need to be started early:
>>> >>
>>> >>        <property name="wildfly.jpa.twophasebootstrap" value="false"/>
>>> >>
>>> >>    Helps the deployment succeed.
>>> >>
>>> >>    It looks like ResourceReferenceProcessor is running during the
>>> >>    Phase.POST_MODULE deployment phase, so we need to add a hint to the
>>> >>    persistence.xml, that helps the persistence unit deploy later.
>>> >>
>>> >>    [6]
>>> >>    https://github.com/wildfly/wildfly/blob/master/ee/src/main/java/org/jboss/as/ee/subsystem/EeSubsystemAdd.java#L194
>>> >>
>>> >>    Scott
>>> >>
>>> >>    On 01/31/2014 06:25 AM, arjan tijms wrote:
>>> >>> Hi,
>>> >>>
>>> >>> I looks like there's one bug in the example.
>>> >>>
>>> >>> jboss-web.xml defines jdbc/MyDS
>>> >>>
>>> >>> But persistence.xml references java:comp/env/MyDS
>>> >>>
>>> >>> Shouldn't the last one be at least java:comp/env/jdbc/MyDS?
>>> >>    Regardless,
>>> >>> even with matching names it indeed doesn't work.
>>> >>>
>>> >>> Kind regards,
>>> >>> Arjan Tijms
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Thu, Jan 30, 2014 at 9:52 PM, Scott Marlow <smarlow at redhat.com
>>> >>    <mailto:smarlow at redhat.com>
>>> >>> <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>> wrote:
>>> >>>
>>> >>>    WFLY-2841 reports a deployment failure that occurs when a
>>> >>    deployments
>>> >>>    [1] persistence.xml, tries to use a resource reference [2]
>>> >>    for the
>>> >>>    datasource [3].  The error [4] mentions an unresolved
>>> >>    (DataSource)
>>> >>>    service dependency that is added to the persistence unit
>>> >>    service [5],
>>> >>>    instead of resolving the resource reference (and using the
>>> >>    underlying
>>> >>>    DataSource).
>>> >>>
>>> >>>    How should we handle resource references for this case?  Is
>>> >>    there a way
>>> >>>    to resolve the resource reference directly from deployers?
>>> >>      Or do we
>>> >>>    represent the resource reference as a service?
>>> >>>
>>> >>>    Scott
>>> >>>
>>> >>>    [1] test app is at https://github.com/umartin/wfds/
>>> >>>
>>> >>>    [2] jboss-web.xml
>>> >>>    <jboss-web>
>>> >>>              <context-root>/wfds</context-root>
>>> >>>              <resource-ref>
>>> >>>                      <res-ref-name>jdbc/MyDS</res-ref-name>
>>> >>>                      <res-type>javax.sql.DataSource</res-type>
>>> >>>
>>> >>>      <jndi-name>java:jboss/datasources/ExampleDS</jndi-name>
>>> >>>              </resource-ref>
>>> >>>    </jboss-web>
>>> >>>
>>> >>>    [3] persistence.xml pu def
>>> >>>    <persistence-unit name="wfdsPU" transaction-type="JTA">
>>> >>>              <jta-data-source>java:comp/env/MyDS</jta-data-source>
>>> >>>    </persistence-unit>
>>> >>>
>>> >>>    [4] {"JBAS014771: Services with missing/unavailable
>>> >>    dependencies" =>
>>> >>>
>>> >>    ["jboss.persistenceunit.\"wfds-1.0-SNAPSHOT.war#wfdsPU\".__FIRST_PHASE__
>>> >>>    is missing
>>> >>>
>>> >>    [jboss.naming.context.java.module.\"wfds-1.0-SNAPSHOT\".\"wfds-1.0-SNAPSHOT\".env.MyDS]"]}
>>> >>>
>>> >>>
>>> >>>    [5]
>>> >>>
>>> >>    https://github.com/wildfly/wildfly/blob/master/jpa/core/src/main/java/org/jboss/as/jpa/processor/PersistenceUnitServiceHandler.java#L358
>>> >>>    _______________________________________________
>>> >>>    wildfly-dev mailing list
>>> >>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>> >>    <mailto: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 <mailto:wildfly-dev at lists.jboss.org>
>>> >>    https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> H?lsningar,
>>> >> Martin Andersson
>>> >> Purple Scout AB
>>> >> +46 732 05 14 01
>>> >
>>> > _______________________________________________
>>> > 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/20140131/0d4c70de/attachment-0001.html 

From smarlow at redhat.com  Fri Jan 31 11:30:48 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Fri, 31 Jan 2014 11:30:48 -0500
Subject: [wildfly-dev] How to deal with resource refs when deploying JPA
 container managed entity managers (WFLY-2841)
In-Reply-To: <EF3347C8-5675-40F7-AAF9-420287AF904E@redhat.com>
References: <52EABB89.6080704@redhat.com>	<CAE=-AhAtqZfv51+aNMiLjmixkRfSjhAFNDscXDN=0fKY6+FvOg@mail.gmail.com>	<52EB9D27.3080904@redhat.com>
	<CACmAtJs5GXKsaYD6DfW3LT-EbJmOZ_DMZPnDbL70or_mXAqYSQ@mail.gmail.com>
	<52EBA17A.5060502@redhat.com>
	<3E8BA64D-FE33-467E-91B6-73DF0D8837BF@redhat.com>
	<52EBBB9E.1080707@redhat.com>
	<58F7236C-99D1-477D-A6EF-1294357BDEA0@redhat.com>
	<52EBC765.2030602@redhat.com>
	<EF3347C8-5675-40F7-AAF9-420287AF904E@redhat.com>
Message-ID: <52EBCFB8.8010504@redhat.com>

We tried that initially (few years ago now) and the JNDI lookup didn't 
work as the DataSource service was not started.  Will the java:comp jndi 
lookup work in the FIRST_MODULE_USE phase?

On 01/31/2014 11:07 AM, Eduardo Martins wrote:
> That is something that should be fixed, since it does not supports JNDI Federation or link refs. A lookup should be done, and this should be achieved by using a LookupResourceInjection, not MSC services directly. But that?s not everything I guess, if we want to support java:comp in PUs properly, then I see no other way than looking up the concrete datasource when the entity manager is provided to the app.
>
> ?E
>
> On 31 Jan 2014, at 15:55, Scott Marlow <smarlow at redhat.com> wrote:
>
>> No, since we aren't doing a JNDI lookup, instead the persistence unit service has a dependency on the DataSource.
>>
>> https://github.com/wildfly/wildfly/blob/master/jpa/core/src/main/java/org/jboss/as/jpa/processor/PersistenceUnitServiceHandler.java#L358 shows how we use ContextNames.bindInfoForEnvEntry().
>>
>> On 01/31/2014 10:37 AM, Eduardo Martins wrote:
>>> Do you need the concrete Datasource resource present in JNDI at that JPA Entity class enhancing/rewriting? If that?s the case, then what if you have a PU pointing to java:comp/env/MyDatasource, inside an EJB jar with 2 EJBs, where each binds java:comp/env/MyDatasource to different concrete Datasource, which concrete Datasource will be used by the PU?
>>>
>>> ?E
>>>
>>> On 31 Jan 2014, at 15:05, Scott Marlow <smarlow at redhat.com> wrote:
>>>
>>>> JPA Entity class enhancing/rewriting needs to occur in an early deployment phase (before the application classloader is used to load the enhanced classes).
>>>>
>>>> If the ResourceReferenceProcessor ran early enough, the hint wouldn't be needed as a workaround.  There are other "if only we did things differently" involved as well.  For example, when using the Hibernate Bootstrap spi to start the persistence unit, if we moved references to the datasource to only be in the second deployment phase, that would also help (when using Hibernate).
>>>>
>>>> This is not the only case like this.  There is also implicit CDI support which uses the application classloader too early (leaving the application deployer to choose whether to use CDI in entity listeners or JPA class enhancing/rewriting).
>>>>
>>>> @DataSourceDefinition are also not available until Phase.INSTALL, so they cannot be used with applications that expect entities to be enhanced/rewritten.
>>>>
>>>> IMO, we should address these problems in the standards (EE specs).  If we can improve our deployment implementation to better deal with these "initialize me first if you want correct behaviour" situations, all the better.
>>>>
>>>> On 01/31/2014 09:03 AM, Eduardo Martins wrote:
>>>>> IMHO this hint should not be needed, a PU referencing a java:comp or java:module datasource is already a hint that the PU will need a resource bound by another component bundled in same jar/war.
>>>>>
>>>>> By the way I?m not really a fan of using java:comp in a PU, it sets an dependency on a EE component, and that doesn?t seem right. Wouldn't be preferable to use the original java:jboss/datasources/ExampleDS JNDI name, or use an ear and define a java:app bind  at application.xml, to be shared by all modules and components?
>>>>>
>>>>> ?E
>>>>>
>>>>>
>>>>> On 31 Jan 2014, at 13:13, Scott Marlow <smarlow at redhat.com> wrote:
>>>>>
>>>>>> Great, thanks for reporting the issue Martin!  Great to bring more
>>>>>> awareness of the deployment problem and workaround.
>>>>>>
>>>>>> Scott
>>>>>> On 01/31/2014 08:04 AM, Martin Andersson wrote:
>>>>>>> Thanks a lot!
>>>>>>>
>>>>>>> I can confirm that the app works now.
>>>>>>>
>>>>>>> Br,
>>>>>>> Martin Andersson
>>>>>>> Java EE developer at www.purplescout.se <http://www.purplescout.se>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jan 31, 2014 at 1:55 PM, Scott Marlow <smarlow at redhat.com
>>>>>>> <mailto:smarlow at redhat.com>> wrote:
>>>>>>>
>>>>>>>     Hi Arjan,
>>>>>>>
>>>>>>>     Great catch!  Your change and adding an persistence unit hint that the
>>>>>>>     persistence unit doesn't need to be started early:
>>>>>>>
>>>>>>>         <property name="wildfly.jpa.twophasebootstrap" value="false"/>
>>>>>>>
>>>>>>>     Helps the deployment succeed.
>>>>>>>
>>>>>>>     It looks like ResourceReferenceProcessor is running during the
>>>>>>>     Phase.POST_MODULE deployment phase, so we need to add a hint to the
>>>>>>>     persistence.xml, that helps the persistence unit deploy later.
>>>>>>>
>>>>>>>     [6]
>>>>>>>     https://github.com/wildfly/wildfly/blob/master/ee/src/main/java/org/jboss/as/ee/subsystem/EeSubsystemAdd.java#L194
>>>>>>>
>>>>>>>     Scott
>>>>>>>
>>>>>>>     On 01/31/2014 06:25 AM, arjan tijms wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I looks like there's one bug in the example.
>>>>>>>>
>>>>>>>> jboss-web.xml defines jdbc/MyDS
>>>>>>>>
>>>>>>>> But persistence.xml references java:comp/env/MyDS
>>>>>>>>
>>>>>>>> Shouldn't the last one be at least java:comp/env/jdbc/MyDS?
>>>>>>>     Regardless,
>>>>>>>> even with matching names it indeed doesn't work.
>>>>>>>>
>>>>>>>> Kind regards,
>>>>>>>> Arjan Tijms
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Jan 30, 2014 at 9:52 PM, Scott Marlow <smarlow at redhat.com
>>>>>>>     <mailto:smarlow at redhat.com>
>>>>>>>> <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>> wrote:
>>>>>>>>
>>>>>>>>     WFLY-2841 reports a deployment failure that occurs when a
>>>>>>>     deployments
>>>>>>>>     [1] persistence.xml, tries to use a resource reference [2]
>>>>>>>     for the
>>>>>>>>     datasource [3].  The error [4] mentions an unresolved
>>>>>>>     (DataSource)
>>>>>>>>     service dependency that is added to the persistence unit
>>>>>>>     service [5],
>>>>>>>>     instead of resolving the resource reference (and using the
>>>>>>>     underlying
>>>>>>>>     DataSource).
>>>>>>>>
>>>>>>>>     How should we handle resource references for this case?  Is
>>>>>>>     there a way
>>>>>>>>     to resolve the resource reference directly from deployers?
>>>>>>>       Or do we
>>>>>>>>     represent the resource reference as a service?
>>>>>>>>
>>>>>>>>     Scott
>>>>>>>>
>>>>>>>>     [1] test app is at https://github.com/umartin/wfds/
>>>>>>>>
>>>>>>>>     [2] jboss-web.xml
>>>>>>>>     <jboss-web>
>>>>>>>>               <context-root>/wfds</context-root>
>>>>>>>>               <resource-ref>
>>>>>>>>                       <res-ref-name>jdbc/MyDS</res-ref-name>
>>>>>>>>                       <res-type>javax.sql.DataSource</res-type>
>>>>>>>>
>>>>>>>>       <jndi-name>java:jboss/datasources/ExampleDS</jndi-name>
>>>>>>>>               </resource-ref>
>>>>>>>>     </jboss-web>
>>>>>>>>
>>>>>>>>     [3] persistence.xml pu def
>>>>>>>>     <persistence-unit name="wfdsPU" transaction-type="JTA">
>>>>>>>>               <jta-data-source>java:comp/env/MyDS</jta-data-source>
>>>>>>>>     </persistence-unit>
>>>>>>>>
>>>>>>>>     [4] {"JBAS014771: Services with missing/unavailable
>>>>>>>     dependencies" =>
>>>>>>>>
>>>>>>>     ["jboss.persistenceunit.\"wfds-1.0-SNAPSHOT.war#wfdsPU\".__FIRST_PHASE__
>>>>>>>>     is missing
>>>>>>>>
>>>>>>>     [jboss.naming.context.java.module.\"wfds-1.0-SNAPSHOT\".\"wfds-1.0-SNAPSHOT\".env.MyDS]"]}
>>>>>>>>
>>>>>>>>
>>>>>>>>     [5]
>>>>>>>>
>>>>>>>     https://github.com/wildfly/wildfly/blob/master/jpa/core/src/main/java/org/jboss/as/jpa/processor/PersistenceUnitServiceHandler.java#L358
>>>>>>>>     _______________________________________________
>>>>>>>>     wildfly-dev mailing list
>>>>>>>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>>>>>     <mailto: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 <mailto:wildfly-dev at lists.jboss.org>
>>>>>>>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> H?lsningar,
>>>>>>> Martin Andersson
>>>>>>> Purple Scout AB
>>>>>>> +46 732 05 14 01
>>>>>>
>>>>>> _______________________________________________
>>>>>> wildfly-dev mailing list
>>>>>> wildfly-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>
>>>
>>
>


From arjan.tijms at gmail.com  Fri Jan 31 11:33:33 2014
From: arjan.tijms at gmail.com (arjan tijms)
Date: Fri, 31 Jan 2014 17:33:33 +0100
Subject: [wildfly-dev] How to deal with resource refs when deploying JPA
 container managed entity managers (WFLY-2841)
In-Reply-To: <391E3D2F-F1C2-4609-BFAA-621EB338057D@redhat.com>
References: <52EABB89.6080704@redhat.com>
	<CAE=-AhAtqZfv51+aNMiLjmixkRfSjhAFNDscXDN=0fKY6+FvOg@mail.gmail.com>
	<52EB9D27.3080904@redhat.com>
	<CACmAtJs5GXKsaYD6DfW3LT-EbJmOZ_DMZPnDbL70or_mXAqYSQ@mail.gmail.com>
	<52EBA17A.5060502@redhat.com>
	<3E8BA64D-FE33-467E-91B6-73DF0D8837BF@redhat.com>
	<CAE=-AhDVzgs3oT34HEBQSF1AQ3_e_-RM0N8SK3892xV1HjUaMg@mail.gmail.com>
	<6414C026-A659-4510-8661-8281EA80B670@redhat.com>
	<CAE=-AhAGoGmrOeXk-98Gwd-dM6dreJ9Z-uYQv6O-tKVFHSB7gA@mail.gmail.com>
	<AFC5DA87-4CBD-4BD7-AAC9-74727DE096EB@redhat.com>
	<CAE=-AhB3RScRWGZwR2YO-cxY5Eaeq-7jXZHGfxMDMb0CicDtBw@mail.gmail.com>
	<391E3D2F-F1C2-4609-BFAA-621EB338057D@redhat.com>
Message-ID: <CAE=-AhDXsPKcYveTpLBx1ZzfzX2ZEQd5nSEJr=sgJQE9B+o+EA@mail.gmail.com>

On Fri, Jan 31, 2014 at 5:20 PM, Eduardo Martins <emartins at redhat.com>wrote:

> I think in that case you should use java:module, what if you later put
> that war in a ear with other modules? IMHO you should use the proper scope
> of each standard JNDI context.
>

It may depend strongly on the architecture of the module. If the .war in
question was very strictly designed following the "war is the new ear"
paradigm (so to speak), then it may be clear that it won't ever be put into
an ear later.

I practice I found it to be relatively rare that an application is designed
as a war one, then later put inside an ear with some other modules and that
you just expect everything to work. Things like @ApplicationScoped and CDI
extensions unfortunately don't play well here. The concept of what
constitutes an "application" is not entirely consistently defined in Java
EE.

IMHO you design an *application* as either war or ear, and if you want to
put an application implemented as a war inside an ear later on there's
likely some refactoring to take into account. Occasionally you may design
something as being a web *module* from the start, even when not yet
embedded into an ear, but as said from personal experience I found this to
be relatively rare.



>
> --E
>
>
> On 31 Jan 2014, at 16:17, arjan tijms <arjan.tijms at gmail.com> wrote:
>
>
> On Fri, Jan 31, 2014 at 5:11 PM, Eduardo Martins <emartins at redhat.com>wrote:
>
>> Sure, all you said is correct, I just said that ideally java:app bindings
>> should be done at app level, and provide the reasoning behind that.
>>
>
> Indeed, but then if there's only ever a war then web.xml is at the app
> level, and java:app bindings can be set without architectural concerns in
> web.xml, can't they?
>
>
>
>
>
>>
>> --E
>>
>> On 31 Jan 2014, at 15:58, arjan tijms <arjan.tijms at gmail.com> wrote:
>>
>> Hi,
>>
>> On Fri, Jan 31, 2014 at 4:45 PM, Eduardo Martins <emartins at redhat.com>wrote:
>>
>>> Yes, but design wise this should be done at EAR level, preventing the
>>> mistake of multiple components trying to bind same entry in java:app.
>>>
>>
>> Is that really true if there only ever is the .war? E.g. in the sense as
>> mentioned by Adam here:
>> http://adam-bien.com/roller/abien/entry/is_java_ee_6_war
>>
>> Also, don't EJBs inside a .war share java:comp with the web module's
>> single java:comp? So the entire concept of EJB beans having their own
>> component namespace just goes away then. I think in the modern usage
>> pattern of EJBs there's not much use for this anyway. If the CDI bean model
>> effectively replaces the EJB component model in some future Java EE release
>> then all of this is surely history.
>>
>> Effectively, in a pure web application (.war, no .ear involved) java:comp
>> is effectively java:module, which should be more straightforward to
>> resolve, shouldn't it?
>>
>>
>>
>>
>>
>>
>>
>>>
>>> --E
>>>
>>> On 31 Jan 2014, at 15:08, arjan tijms <arjan.tijms at gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> On Fri, Jan 31, 2014 at 3:03 PM, Eduardo Martins <emartins at redhat.com>wrote:
>>>
>>>> or use an ear and define a java:app bind  at application.xml, to be
>>>> shared by all modules and components?
>>>>
>>>
>>> If you have just a .war, you can use java:app just as well, can't you? I
>>> don't think there's a specific need to use an ear just for java:app.
>>>
>>> Kind regards,
>>> Arjan
>>>
>>>
>>>
>>>
>>>
>>>
>>>>
>>>> --E
>>>>
>>>>
>>>> On 31 Jan 2014, at 13:13, Scott Marlow <smarlow at redhat.com> wrote:
>>>>
>>>> > Great, thanks for reporting the issue Martin!  Great to bring more
>>>> > awareness of the deployment problem and workaround.
>>>> >
>>>> > Scott
>>>> > On 01/31/2014 08:04 AM, Martin Andersson wrote:
>>>> >> Thanks a lot!
>>>> >>
>>>> >> I can confirm that the app works now.
>>>> >>
>>>> >> Br,
>>>> >> Martin Andersson
>>>> >> Java EE developer at www.purplescout.se <http://www.purplescout.se>
>>>> >>
>>>> >>
>>>> >> On Fri, Jan 31, 2014 at 1:55 PM, Scott Marlow <smarlow at redhat.com
>>>> >> <mailto:smarlow at redhat.com>> wrote:
>>>> >>
>>>> >>    Hi Arjan,
>>>> >>
>>>> >>    Great catch!  Your change and adding an persistence unit hint
>>>> that the
>>>> >>    persistence unit doesn't need to be started early:
>>>> >>
>>>> >>        <property name="wildfly.jpa.twophasebootstrap" value="false"/>
>>>> >>
>>>> >>    Helps the deployment succeed.
>>>> >>
>>>> >>    It looks like ResourceReferenceProcessor is running during the
>>>> >>    Phase.POST_MODULE deployment phase, so we need to add a hint to
>>>> the
>>>> >>    persistence.xml, that helps the persistence unit deploy later.
>>>> >>
>>>> >>    [6]
>>>> >>
>>>> https://github.com/wildfly/wildfly/blob/master/ee/src/main/java/org/jboss/as/ee/subsystem/EeSubsystemAdd.java#L194
>>>> >>
>>>> >>    Scott
>>>> >>
>>>> >>    On 01/31/2014 06:25 AM, arjan tijms wrote:
>>>> >>> Hi,
>>>> >>>
>>>> >>> I looks like there's one bug in the example.
>>>> >>>
>>>> >>> jboss-web.xml defines jdbc/MyDS
>>>> >>>
>>>> >>> But persistence.xml references java:comp/env/MyDS
>>>> >>>
>>>> >>> Shouldn't the last one be at least java:comp/env/jdbc/MyDS?
>>>> >>    Regardless,
>>>> >>> even with matching names it indeed doesn't work.
>>>> >>>
>>>> >>> Kind regards,
>>>> >>> Arjan Tijms
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> On Thu, Jan 30, 2014 at 9:52 PM, Scott Marlow <smarlow at redhat.com
>>>> >>    <mailto:smarlow at redhat.com>
>>>> >>> <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>> wrote:
>>>> >>>
>>>> >>>    WFLY-2841 reports a deployment failure that occurs when a
>>>> >>    deployments
>>>> >>>    [1] persistence.xml, tries to use a resource reference [2]
>>>> >>    for the
>>>> >>>    datasource [3].  The error [4] mentions an unresolved
>>>> >>    (DataSource)
>>>> >>>    service dependency that is added to the persistence unit
>>>> >>    service [5],
>>>> >>>    instead of resolving the resource reference (and using the
>>>> >>    underlying
>>>> >>>    DataSource).
>>>> >>>
>>>> >>>    How should we handle resource references for this case?  Is
>>>> >>    there a way
>>>> >>>    to resolve the resource reference directly from deployers?
>>>> >>      Or do we
>>>> >>>    represent the resource reference as a service?
>>>> >>>
>>>> >>>    Scott
>>>> >>>
>>>> >>>    [1] test app is at https://github.com/umartin/wfds/
>>>> >>>
>>>> >>>    [2] jboss-web.xml
>>>> >>>    <jboss-web>
>>>> >>>              <context-root>/wfds</context-root>
>>>> >>>              <resource-ref>
>>>> >>>                      <res-ref-name>jdbc/MyDS</res-ref-name>
>>>> >>>                      <res-type>javax.sql.DataSource</res-type>
>>>> >>>
>>>> >>>      <jndi-name>java:jboss/datasources/ExampleDS</jndi-name>
>>>> >>>              </resource-ref>
>>>> >>>    </jboss-web>
>>>> >>>
>>>> >>>    [3] persistence.xml pu def
>>>> >>>    <persistence-unit name="wfdsPU" transaction-type="JTA">
>>>> >>>              <jta-data-source>java:comp/env/MyDS</jta-data-source>
>>>> >>>    </persistence-unit>
>>>> >>>
>>>> >>>    [4] {"JBAS014771: Services with missing/unavailable
>>>> >>    dependencies" =>
>>>> >>>
>>>> >>
>>>>  ["jboss.persistenceunit.\"wfds-1.0-SNAPSHOT.war#wfdsPU\".__FIRST_PHASE__
>>>> >>>    is missing
>>>> >>>
>>>> >>
>>>>  [jboss.naming.context.java.module.\"wfds-1.0-SNAPSHOT\".\"wfds-1.0-SNAPSHOT\".env.MyDS]"]}
>>>> >>>
>>>> >>>
>>>> >>>    [5]
>>>> >>>
>>>> >>
>>>> https://github.com/wildfly/wildfly/blob/master/jpa/core/src/main/java/org/jboss/as/jpa/processor/PersistenceUnitServiceHandler.java#L358
>>>> >>>    _______________________________________________
>>>> >>>    wildfly-dev mailing list
>>>> >>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>> >>    <mailto: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 <mailto:wildfly-dev at lists.jboss.org>
>>>> >>    https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> --
>>>> >> H?lsningar,
>>>> >> Martin Andersson
>>>> >> Purple Scout AB
>>>> >> +46 732 05 14 01
>>>> >
>>>> > _______________________________________________
>>>> > 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/20140131/494e3a6c/attachment-0001.html 

From jason.greene at redhat.com  Fri Jan 31 11:39:15 2014
From: jason.greene at redhat.com (Jason Greene)
Date: Fri, 31 Jan 2014 10:39:15 -0600
Subject: [wildfly-dev] How to deal with resource refs when deploying JPA
	container managed entity managers (WFLY-2841)
In-Reply-To: <CACmAtJu=1EmmEnS06g1xD7hLw0_kc2DNpytEqMZOdeufa5aRww@mail.gmail.com>
References: <52EABB89.6080704@redhat.com>
	<CAE=-AhAtqZfv51+aNMiLjmixkRfSjhAFNDscXDN=0fKY6+FvOg@mail.gmail.com>
	<52EB9D27.3080904@redhat.com>
	<CACmAtJs5GXKsaYD6DfW3LT-EbJmOZ_DMZPnDbL70or_mXAqYSQ@mail.gmail.com>
	<52EBA17A.5060502@redhat.com>
	<3E8BA64D-FE33-467E-91B6-73DF0D8837BF@redhat.com>
	<CACmAtJu=1EmmEnS06g1xD7hLw0_kc2DNpytEqMZOdeufa5aRww@mail.gmail.com>
Message-ID: <9E806186-CE64-4B0C-981A-5BAE9A426B06@redhat.com>


On Jan 31, 2014, at 8:33 AM, Martin Andersson <martin.andersson at purplescout.se> wrote:

> I agree. I don't think mapping a datasource in jboss-web.xml is such an exotic use case. I should just work.

It?s not, it?s actually implied by the standard, as you can define them in web.xml as well. It?s a lifecycle problem we need to solve. 

> Also, there is no hint anywere that there is a property you can set to make it work.
> 
> The proprietary jboss namespace is not an option since I want to be vendor neutral, but ear/java:app is definitely an option.

Another solution specific to EE7 is you can leave the jta-data-source undefined in persistence.xml which will use the platforms default data source. We allow you to point that anywhere. However, that limits you to one, so not really a complete solution.

A more complete solution is to use a common global name, and define an alias to your deployment in our naming subsystem like so:

<bindings>
   <lookup name="java:global/env/FooDS" lookup="java:jboss/datasources/ExampleDS"/>
</bindings>

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



From smarlow at redhat.com  Fri Jan 31 11:46:30 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Fri, 31 Jan 2014 11:46:30 -0500
Subject: [wildfly-dev] How to deal with resource refs when deploying JPA
 container managed entity managers (WFLY-2841)
In-Reply-To: <C56AB13F-3D51-4EA1-A110-2FD9E9296DD3@redhat.com>
References: <52EABB89.6080704@redhat.com>	<CAE=-AhAtqZfv51+aNMiLjmixkRfSjhAFNDscXDN=0fKY6+FvOg@mail.gmail.com>	<52EB9D27.3080904@redhat.com>
	<CACmAtJs5GXKsaYD6DfW3LT-EbJmOZ_DMZPnDbL70or_mXAqYSQ@mail.gmail.com>
	<52EBA17A.5060502@redhat.com>
	<3E8BA64D-FE33-467E-91B6-73DF0D8837BF@redhat.com>
	<52EBBB9E.1080707@redhat.com>
	<C56AB13F-3D51-4EA1-A110-2FD9E9296DD3@redhat.com>
Message-ID: <52EBD366.7010409@redhat.com>

On 01/31/2014 11:01 AM, Jason Greene wrote:
>
> On Jan 31, 2014, at 9:05 AM, Scott Marlow <smarlow at redhat.com> wrote:
>
>> JPA Entity class enhancing/rewriting needs to occur in an early
>> deployment phase (before the application classloader is used to load the
>> enhanced classes).
>
> Yes, but this does not require access to a data source. Instrumentation simply needs to modify a small subset of classes (those marked as entities)
>
>> If the ResourceReferenceProcessor ran early enough, the hint wouldn't be
>> needed as a workaround.
>
> That?s not possible because @Resource can?t be processed without the final class loader.
>
>> There are other "if only we did things
>> differently" involved as well.  For example, when using the Hibernate
>> Bootstrap spi to start the persistence unit, if we moved references to
>> the datasource to only be in the second deployment phase, that would
>> also help (when using Hibernate).
>
> That seems to be the real solution, and there is really no reason why a JPA provider needs to do anything with a datasource in order to know how to instrument the entity class.

This will definitely help, I think its also a big change in Hibernate 
that hasn't happened yet.  From a spec point of view, we had some 
discussion about wanting to bring the two phase bootstrap into JPA and I 
think we would push for only referencing the datasource during the 
second phase (which we run during our INSTALL deployment phase).

>
>>
>> This is not the only case like this.  There is also implicit CDI support
>> which uses the application classloader too early (leaving the
>> application deployer to choose whether to use CDI in entity listeners or
>> JPA class enhancing/rewriting).
>
> I?m not sure I follow the problems with this one.

This is one that we can also address in Hibernate (by moving the entity 
listener registration to occur later) but just haven't yet.  This 
doesn't help us when we are using third party persistence providers. 
I'm hoping to see this addressed in the future (got some positive 
feedback on the JPA EG but will see what happens when the next JPA spec 
revision is discussed).

>
>>
>> @DataSourceDefinition are also not available until Phase.INSTALL, so
>> they cannot be used with applications that expect entities to be
>> enhanced/rewritten.
>
> That shouldn?t matter if the data source usage was in a later phase.

Yes, I agree and will push for the 3rd party persistence providers to 
also do that (in future JPA spec discussions).

>
>
>>
>> IMO, we should address these problems in the standards (EE specs).
>
> I?m not sure what specific spec flaw you are referring to here, this seems to really just be an implementation problem on our side. Unless you mean the JPA SPI with the temp class loading stuff, in which case I totally agree, but we don?t have to use it with our hibernate integration anyway.

We might be able to work around the issues in our Hibernate 
implementation (by moving datasource/entitylistener registration to a 
later phase) but we still need to work with 3rd party persistence 
providers that do not have a two phase persistence unit bootstrap (since 
we haven't agreed on how that will be done or if it will be part of the 
standard).

>
>
>>   If
>> we can improve our deployment implementation to better deal with these
>> "initialize me first if you want correct behaviour" situations, all the
>> better.
>>
>> On 01/31/2014 09:03 AM, Eduardo Martins wrote:
>>> IMHO this hint should not be needed, a PU referencing a java:comp or java:module datasource is already a hint that the PU will need a resource bound by another component bundled in same jar/war.
>>>
>>> By the way I?m not really a fan of using java:comp in a PU, it sets an dependency on a EE component, and that doesn?t seem right. Wouldn't be preferable to use the original java:jboss/datasources/ExampleDS JNDI name, or use an ear and define a java:app bind  at application.xml, to be shared by all modules and components?
>>>
>>> ?E
>>>
>>>
>>> On 31 Jan 2014, at 13:13, Scott Marlow <smarlow at redhat.com> wrote:
>>>
>>>> Great, thanks for reporting the issue Martin!  Great to bring more
>>>> awareness of the deployment problem and workaround.
>>>>
>>>> Scott
>>>> On 01/31/2014 08:04 AM, Martin Andersson wrote:
>>>>> Thanks a lot!
>>>>>
>>>>> I can confirm that the app works now.
>>>>>
>>>>> Br,
>>>>> Martin Andersson
>>>>> Java EE developer at www.purplescout.se <http://www.purplescout.se>
>>>>>
>>>>>
>>>>> On Fri, Jan 31, 2014 at 1:55 PM, Scott Marlow <smarlow at redhat.com
>>>>> <mailto:smarlow at redhat.com>> wrote:
>>>>>
>>>>>     Hi Arjan,
>>>>>
>>>>>     Great catch!  Your change and adding an persistence unit hint that the
>>>>>     persistence unit doesn't need to be started early:
>>>>>
>>>>>         <property name="wildfly.jpa.twophasebootstrap" value="false"/>
>>>>>
>>>>>     Helps the deployment succeed.
>>>>>
>>>>>     It looks like ResourceReferenceProcessor is running during the
>>>>>     Phase.POST_MODULE deployment phase, so we need to add a hint to the
>>>>>     persistence.xml, that helps the persistence unit deploy later.
>>>>>
>>>>>     [6]
>>>>>     https://github.com/wildfly/wildfly/blob/master/ee/src/main/java/org/jboss/as/ee/subsystem/EeSubsystemAdd.java#L194
>>>>>
>>>>>     Scott
>>>>>
>>>>>     On 01/31/2014 06:25 AM, arjan tijms wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I looks like there's one bug in the example.
>>>>>>
>>>>>> jboss-web.xml defines jdbc/MyDS
>>>>>>
>>>>>> But persistence.xml references java:comp/env/MyDS
>>>>>>
>>>>>> Shouldn't the last one be at least java:comp/env/jdbc/MyDS?
>>>>>     Regardless,
>>>>>> even with matching names it indeed doesn't work.
>>>>>>
>>>>>> Kind regards,
>>>>>> Arjan Tijms
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Jan 30, 2014 at 9:52 PM, Scott Marlow <smarlow at redhat.com
>>>>>     <mailto:smarlow at redhat.com>
>>>>>> <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>> wrote:
>>>>>>
>>>>>>     WFLY-2841 reports a deployment failure that occurs when a
>>>>>     deployments
>>>>>>     [1] persistence.xml, tries to use a resource reference [2]
>>>>>     for the
>>>>>>     datasource [3].  The error [4] mentions an unresolved
>>>>>     (DataSource)
>>>>>>     service dependency that is added to the persistence unit
>>>>>     service [5],
>>>>>>     instead of resolving the resource reference (and using the
>>>>>     underlying
>>>>>>     DataSource).
>>>>>>
>>>>>>     How should we handle resource references for this case?  Is
>>>>>     there a way
>>>>>>     to resolve the resource reference directly from deployers?
>>>>>       Or do we
>>>>>>     represent the resource reference as a service?
>>>>>>
>>>>>>     Scott
>>>>>>
>>>>>>     [1] test app is at https://github.com/umartin/wfds/
>>>>>>
>>>>>>     [2] jboss-web.xml
>>>>>>     <jboss-web>
>>>>>>               <context-root>/wfds</context-root>
>>>>>>               <resource-ref>
>>>>>>                       <res-ref-name>jdbc/MyDS</res-ref-name>
>>>>>>                       <res-type>javax.sql.DataSource</res-type>
>>>>>>
>>>>>>       <jndi-name>java:jboss/datasources/ExampleDS</jndi-name>
>>>>>>               </resource-ref>
>>>>>>     </jboss-web>
>>>>>>
>>>>>>     [3] persistence.xml pu def
>>>>>>     <persistence-unit name="wfdsPU" transaction-type="JTA">
>>>>>>               <jta-data-source>java:comp/env/MyDS</jta-data-source>
>>>>>>     </persistence-unit>
>>>>>>
>>>>>>     [4] {"JBAS014771: Services with missing/unavailable
>>>>>     dependencies" =>
>>>>>>
>>>>>     ["jboss.persistenceunit.\"wfds-1.0-SNAPSHOT.war#wfdsPU\".__FIRST_PHASE__
>>>>>>     is missing
>>>>>>
>>>>>     [jboss.naming.context.java.module.\"wfds-1.0-SNAPSHOT\".\"wfds-1.0-SNAPSHOT\".env.MyDS]"]}
>>>>>>
>>>>>>
>>>>>>     [5]
>>>>>>
>>>>>     https://github.com/wildfly/wildfly/blob/master/jpa/core/src/main/java/org/jboss/as/jpa/processor/PersistenceUnitServiceHandler.java#L358
>>>>>>     _______________________________________________
>>>>>>     wildfly-dev mailing list
>>>>>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>>>     <mailto: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 <mailto:wildfly-dev at lists.jboss.org>
>>>>>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> H?lsningar,
>>>>> Martin Andersson
>>>>> Purple Scout AB
>>>>> +46 732 05 14 01
>>>>
>>>> _______________________________________________
>>>> 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
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>


From jason.greene at redhat.com  Fri Jan 31 11:47:41 2014
From: jason.greene at redhat.com (Jason Greene)
Date: Fri, 31 Jan 2014 10:47:41 -0600
Subject: [wildfly-dev] How to deal with resource refs when deploying JPA
	container managed entity managers (WFLY-2841)
In-Reply-To: <52EBD366.7010409@redhat.com>
References: <52EABB89.6080704@redhat.com>	<CAE=-AhAtqZfv51+aNMiLjmixkRfSjhAFNDscXDN=0fKY6+FvOg@mail.gmail.com>	<52EB9D27.3080904@redhat.com>
	<CACmAtJs5GXKsaYD6DfW3LT-EbJmOZ_DMZPnDbL70or_mXAqYSQ@mail.gmail.com>
	<52EBA17A.5060502@redhat.com>
	<3E8BA64D-FE33-467E-91B6-73DF0D8837BF@redhat.com>
	<52EBBB9E.1080707@redhat.com>
	<C56AB13F-3D51-4EA1-A110-2FD9E9296DD3@redhat.com>
	<52EBD366.7010409@redhat.com>
Message-ID: <E7CC006D-FA51-4BFE-AB09-3AC6E29DEAD7@redhat.com>


On Jan 31, 2014, at 10:46 AM, Scott Marlow <smarlow at redhat.com> wrote:

> On 01/31/2014 11:01 AM, Jason Greene wrote:
>> 
>> On Jan 31, 2014, at 9:05 AM, Scott Marlow <smarlow at redhat.com> wrote:
>> 
>>> JPA Entity class enhancing/rewriting needs to occur in an early
>>> deployment phase (before the application classloader is used to load the
>>> enhanced classes).
>> 
>> Yes, but this does not require access to a data source. Instrumentation simply needs to modify a small subset of classes (those marked as entities)
>> 
>>> If the ResourceReferenceProcessor ran early enough, the hint wouldn't be
>>> needed as a workaround.
>> 
>> That?s not possible because @Resource can?t be processed without the final class loader.
>> 
>>> There are other "if only we did things
>>> differently" involved as well.  For example, when using the Hibernate
>>> Bootstrap spi to start the persistence unit, if we moved references to
>>> the datasource to only be in the second deployment phase, that would
>>> also help (when using Hibernate).
>> 
>> That seems to be the real solution, and there is really no reason why a JPA provider needs to do anything with a datasource in order to know how to instrument the entity class.
> 
> This will definitely help, I think its also a big change in Hibernate that hasn't happened yet.  From a spec point of view, we had some discussion about wanting to bring the two phase bootstrap into JPA and I think we would push for only referencing the datasource during the second phase (which we run during our INSTALL deployment phase).

This really has nothing to do with the spec though. Our phases are broken and we need to fix them.

> 
>> 
>>> 
>>> This is not the only case like this.  There is also implicit CDI support
>>> which uses the application classloader too early (leaving the
>>> application deployer to choose whether to use CDI in entity listeners or
>>> JPA class enhancing/rewriting).
>> 
>> I?m not sure I follow the problems with this one.
> 
> This is one that we can also address in Hibernate (by moving the entity listener registration to occur later) but just haven't yet.  This doesn't help us when we are using third party persistence providers. I'm hoping to see this addressed in the future (got some positive feedback on the JPA EG but will see what happens when the next JPA spec revision is discussed).
> 
>> 
>>> 
>>> @DataSourceDefinition are also not available until Phase.INSTALL, so
>>> they cannot be used with applications that expect entities to be
>>> enhanced/rewritten.
>> 
>> That shouldn?t matter if the data source usage was in a later phase.
> 
> Yes, I agree and will push for the 3rd party persistence providers to also do that (in future JPA spec discussions).
> 
>> 
>> 
>>> 
>>> IMO, we should address these problems in the standards (EE specs).
>> 
>> I?m not sure what specific spec flaw you are referring to here, this seems to really just be an implementation problem on our side. Unless you mean the JPA SPI with the temp class loading stuff, in which case I totally agree, but we don?t have to use it with our hibernate integration anyway.
> 
> We might be able to work around the issues in our Hibernate implementation (by moving datasource/entitylistener registration to a later phase) but we still need to work with 3rd party persistence providers that do not have a two phase persistence unit bootstrap (since we haven't agreed on how that will be done or if it will be part of the standard).
> 
>> 
>> 
>>>  If
>>> we can improve our deployment implementation to better deal with these
>>> "initialize me first if you want correct behaviour" situations, all the
>>> better.
>>> 
>>> On 01/31/2014 09:03 AM, Eduardo Martins wrote:
>>>> IMHO this hint should not be needed, a PU referencing a java:comp or java:module datasource is already a hint that the PU will need a resource bound by another component bundled in same jar/war.
>>>> 
>>>> By the way I?m not really a fan of using java:comp in a PU, it sets an dependency on a EE component, and that doesn?t seem right. Wouldn't be preferable to use the original java:jboss/datasources/ExampleDS JNDI name, or use an ear and define a java:app bind  at application.xml, to be shared by all modules and components?
>>>> 
>>>> ?E
>>>> 
>>>> 
>>>> On 31 Jan 2014, at 13:13, Scott Marlow <smarlow at redhat.com> wrote:
>>>> 
>>>>> Great, thanks for reporting the issue Martin!  Great to bring more
>>>>> awareness of the deployment problem and workaround.
>>>>> 
>>>>> Scott
>>>>> On 01/31/2014 08:04 AM, Martin Andersson wrote:
>>>>>> Thanks a lot!
>>>>>> 
>>>>>> I can confirm that the app works now.
>>>>>> 
>>>>>> Br,
>>>>>> Martin Andersson
>>>>>> Java EE developer at www.purplescout.se <http://www.purplescout.se>
>>>>>> 
>>>>>> 
>>>>>> On Fri, Jan 31, 2014 at 1:55 PM, Scott Marlow <smarlow at redhat.com
>>>>>> <mailto:smarlow at redhat.com>> wrote:
>>>>>> 
>>>>>>    Hi Arjan,
>>>>>> 
>>>>>>    Great catch!  Your change and adding an persistence unit hint that the
>>>>>>    persistence unit doesn't need to be started early:
>>>>>> 
>>>>>>        <property name="wildfly.jpa.twophasebootstrap" value="false"/>
>>>>>> 
>>>>>>    Helps the deployment succeed.
>>>>>> 
>>>>>>    It looks like ResourceReferenceProcessor is running during the
>>>>>>    Phase.POST_MODULE deployment phase, so we need to add a hint to the
>>>>>>    persistence.xml, that helps the persistence unit deploy later.
>>>>>> 
>>>>>>    [6]
>>>>>>    https://github.com/wildfly/wildfly/blob/master/ee/src/main/java/org/jboss/as/ee/subsystem/EeSubsystemAdd.java#L194
>>>>>> 
>>>>>>    Scott
>>>>>> 
>>>>>>    On 01/31/2014 06:25 AM, arjan tijms wrote:
>>>>>>> Hi,
>>>>>>> 
>>>>>>> I looks like there's one bug in the example.
>>>>>>> 
>>>>>>> jboss-web.xml defines jdbc/MyDS
>>>>>>> 
>>>>>>> But persistence.xml references java:comp/env/MyDS
>>>>>>> 
>>>>>>> Shouldn't the last one be at least java:comp/env/jdbc/MyDS?
>>>>>>    Regardless,
>>>>>>> even with matching names it indeed doesn't work.
>>>>>>> 
>>>>>>> Kind regards,
>>>>>>> Arjan Tijms
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On Thu, Jan 30, 2014 at 9:52 PM, Scott Marlow <smarlow at redhat.com
>>>>>>    <mailto:smarlow at redhat.com>
>>>>>>> <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>> wrote:
>>>>>>> 
>>>>>>>    WFLY-2841 reports a deployment failure that occurs when a
>>>>>>    deployments
>>>>>>>    [1] persistence.xml, tries to use a resource reference [2]
>>>>>>    for the
>>>>>>>    datasource [3].  The error [4] mentions an unresolved
>>>>>>    (DataSource)
>>>>>>>    service dependency that is added to the persistence unit
>>>>>>    service [5],
>>>>>>>    instead of resolving the resource reference (and using the
>>>>>>    underlying
>>>>>>>    DataSource).
>>>>>>> 
>>>>>>>    How should we handle resource references for this case?  Is
>>>>>>    there a way
>>>>>>>    to resolve the resource reference directly from deployers?
>>>>>>      Or do we
>>>>>>>    represent the resource reference as a service?
>>>>>>> 
>>>>>>>    Scott
>>>>>>> 
>>>>>>>    [1] test app is at https://github.com/umartin/wfds/
>>>>>>> 
>>>>>>>    [2] jboss-web.xml
>>>>>>>    <jboss-web>
>>>>>>>              <context-root>/wfds</context-root>
>>>>>>>              <resource-ref>
>>>>>>>                      <res-ref-name>jdbc/MyDS</res-ref-name>
>>>>>>>                      <res-type>javax.sql.DataSource</res-type>
>>>>>>> 
>>>>>>>      <jndi-name>java:jboss/datasources/ExampleDS</jndi-name>
>>>>>>>              </resource-ref>
>>>>>>>    </jboss-web>
>>>>>>> 
>>>>>>>    [3] persistence.xml pu def
>>>>>>>    <persistence-unit name="wfdsPU" transaction-type="JTA">
>>>>>>>              <jta-data-source>java:comp/env/MyDS</jta-data-source>
>>>>>>>    </persistence-unit>
>>>>>>> 
>>>>>>>    [4] {"JBAS014771: Services with missing/unavailable
>>>>>>    dependencies" =>
>>>>>>> 
>>>>>>    ["jboss.persistenceunit.\"wfds-1.0-SNAPSHOT.war#wfdsPU\".__FIRST_PHASE__
>>>>>>>    is missing
>>>>>>> 
>>>>>>    [jboss.naming.context.java.module.\"wfds-1.0-SNAPSHOT\".\"wfds-1.0-SNAPSHOT\".env.MyDS]"]}
>>>>>>> 
>>>>>>> 
>>>>>>>    [5]
>>>>>>> 
>>>>>>    https://github.com/wildfly/wildfly/blob/master/jpa/core/src/main/java/org/jboss/as/jpa/processor/PersistenceUnitServiceHandler.java#L358
>>>>>>>    _______________________________________________
>>>>>>>    wildfly-dev mailing list
>>>>>>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>>>>    <mailto: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 <mailto:wildfly-dev at lists.jboss.org>
>>>>>>    https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> H?lsningar,
>>>>>> Martin Andersson
>>>>>> Purple Scout AB
>>>>>> +46 732 05 14 01
>>>>> 
>>>>> _______________________________________________
>>>>> 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
>> 
>> --
>> 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 jason.greene at redhat.com  Fri Jan 31 11:56:27 2014
From: jason.greene at redhat.com (Jason Greene)
Date: Fri, 31 Jan 2014 10:56:27 -0600
Subject: [wildfly-dev] How to deal with resource refs when deploying JPA
	container managed entity managers (WFLY-2841)
In-Reply-To: <9E806186-CE64-4B0C-981A-5BAE9A426B06@redhat.com>
References: <52EABB89.6080704@redhat.com>
	<CAE=-AhAtqZfv51+aNMiLjmixkRfSjhAFNDscXDN=0fKY6+FvOg@mail.gmail.com>
	<52EB9D27.3080904@redhat.com>
	<CACmAtJs5GXKsaYD6DfW3LT-EbJmOZ_DMZPnDbL70or_mXAqYSQ@mail.gmail.com>
	<52EBA17A.5060502@redhat.com>
	<3E8BA64D-FE33-467E-91B6-73DF0D8837BF@redhat.com>
	<CACmAtJu=1EmmEnS06g1xD7hLw0_kc2DNpytEqMZOdeufa5aRww@mail.gmail.com>
	<9E806186-CE64-4B0C-981A-5BAE9A426B06@redhat.com>
Message-ID: <ACE1C0FC-A80C-439C-8934-783C78E22871@redhat.com>


On Jan 31, 2014, at 10:39 AM, Jason Greene <jason.greene at redhat.com> wrote:

> 
> On Jan 31, 2014, at 8:33 AM, Martin Andersson <martin.andersson at purplescout.se> wrote:
> 
>> I agree. I don't think mapping a datasource in jboss-web.xml is such an exotic use case. I should just work.
> 
> It?s not, it?s actually implied by the standard, as you can define them in web.xml as well. It?s a lifecycle problem we need to solve. 
> 
>> Also, there is no hint anywere that there is a property you can set to make it work.
>> 
>> The proprietary jboss namespace is not an option since I want to be vendor neutral, but ear/java:app is definitely an option.
> 
> Another solution specific to EE7 is you can leave the jta-data-source undefined in persistence.xml which will use the platforms default data source. We allow you to point that anywhere. However, that limits you to one, so not really a complete solution.
> 
> A more complete solution is to use a common global name, and define an alias to your deployment in our naming subsystem like so:
> 
> <bindings>
>   <lookup name="java:global/env/FooDS" lookup="java:jboss/datasources/ExampleDS"/>
> </bindings>
> 

Actually don?t waste your time on this alias option. PeristenceUnitServiceHandler?s approach to names will prevent it from working.

?

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



From martin.andersson at purplescout.se  Fri Jan 31 12:03:05 2014
From: martin.andersson at purplescout.se (Martin Andersson)
Date: Fri, 31 Jan 2014 18:03:05 +0100
Subject: [wildfly-dev] How to deal with resource refs when deploying JPA
 container managed entity managers (WFLY-2841)
In-Reply-To: <ACE1C0FC-A80C-439C-8934-783C78E22871@redhat.com>
References: <52EABB89.6080704@redhat.com>
	<CAE=-AhAtqZfv51+aNMiLjmixkRfSjhAFNDscXDN=0fKY6+FvOg@mail.gmail.com>
	<52EB9D27.3080904@redhat.com>
	<CACmAtJs5GXKsaYD6DfW3LT-EbJmOZ_DMZPnDbL70or_mXAqYSQ@mail.gmail.com>
	<52EBA17A.5060502@redhat.com>
	<3E8BA64D-FE33-467E-91B6-73DF0D8837BF@redhat.com>
	<CACmAtJu=1EmmEnS06g1xD7hLw0_kc2DNpytEqMZOdeufa5aRww@mail.gmail.com>
	<9E806186-CE64-4B0C-981A-5BAE9A426B06@redhat.com>
	<ACE1C0FC-A80C-439C-8934-783C78E22871@redhat.com>
Message-ID: <CACmAtJtGMzxRfZOXNxGiyCpd-HXsehwMwvY8aFoEJiVeV4giPQ@mail.gmail.com>

Thanks for your input!

The alias and global naming does actually work!

Br,
Martin Andersson
Java EE developer at www.purplescout.se



On Fri, Jan 31, 2014 at 5:56 PM, Jason Greene <jason.greene at redhat.com>wrote:

>
> On Jan 31, 2014, at 10:39 AM, Jason Greene <jason.greene at redhat.com>
> wrote:
>
> >
> > On Jan 31, 2014, at 8:33 AM, Martin Andersson <
> martin.andersson at purplescout.se> wrote:
> >
> >> I agree. I don't think mapping a datasource in jboss-web.xml is such an
> exotic use case. I should just work.
> >
> > It's not, it's actually implied by the standard, as you can define them
> in web.xml as well. It's a lifecycle problem we need to solve.
> >
> >> Also, there is no hint anywere that there is a property you can set to
> make it work.
> >>
> >> The proprietary jboss namespace is not an option since I want to be
> vendor neutral, but ear/java:app is definitely an option.
> >
> > Another solution specific to EE7 is you can leave the jta-data-source
> undefined in persistence.xml which will use the platforms default data
> source. We allow you to point that anywhere. However, that limits you to
> one, so not really a complete solution.
> >
> > A more complete solution is to use a common global name, and define an
> alias to your deployment in our naming subsystem like so:
> >
> > <bindings>
> >   <lookup name="java:global/env/FooDS"
> lookup="java:jboss/datasources/ExampleDS"/>
> > </bindings>
> >
>
> Actually don't waste your time on this alias option.
> PeristenceUnitServiceHandler's approach to names will prevent it from
> working.
>
> --
>
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>


-- 
H?lsningar,
Martin Andersson
Purple Scout AB
+46 732 05 14 01
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140131/17b71937/attachment.html 

From jason.greene at redhat.com  Fri Jan 31 12:34:16 2014
From: jason.greene at redhat.com (Jason Greene)
Date: Fri, 31 Jan 2014 11:34:16 -0600
Subject: [wildfly-dev] How to deal with resource refs when deploying JPA
	container managed entity managers (WFLY-2841)
In-Reply-To: <CACmAtJtGMzxRfZOXNxGiyCpd-HXsehwMwvY8aFoEJiVeV4giPQ@mail.gmail.com>
References: <52EABB89.6080704@redhat.com>
	<CAE=-AhAtqZfv51+aNMiLjmixkRfSjhAFNDscXDN=0fKY6+FvOg@mail.gmail.com>
	<52EB9D27.3080904@redhat.com>
	<CACmAtJs5GXKsaYD6DfW3LT-EbJmOZ_DMZPnDbL70or_mXAqYSQ@mail.gmail.com>
	<52EBA17A.5060502@redhat.com>
	<3E8BA64D-FE33-467E-91B6-73DF0D8837BF@redhat.com>
	<CACmAtJu=1EmmEnS06g1xD7hLw0_kc2DNpytEqMZOdeufa5aRww@mail.gmail.com>
	<9E806186-CE64-4B0C-981A-5BAE9A426B06@redhat.com>
	<ACE1C0FC-A80C-439C-8934-783C78E22871@redhat.com>
	<CACmAtJtGMzxRfZOXNxGiyCpd-HXsehwMwvY8aFoEJiVeV4giPQ@mail.gmail.com>
Message-ID: <4EAAB570-7945-4890-86AF-52EB237FDAB4@redhat.com>

Ah yes it does use ManagedReferenceFactory so is reliable, I just misinterpreted the earlier conversation about there being a hard dep on the data source.

On Jan 31, 2014, at 11:03 AM, Martin Andersson <martin.andersson at purplescout.se> wrote:

> Thanks for your input!
> 
> The alias and global naming does actually work!
> 
> Br,
> Martin Andersson
> Java EE developer at www.purplescout.se
> 
> 
> 
> On Fri, Jan 31, 2014 at 5:56 PM, Jason Greene <jason.greene at redhat.com> wrote:
> 
> On Jan 31, 2014, at 10:39 AM, Jason Greene <jason.greene at redhat.com> wrote:
> 
> >
> > On Jan 31, 2014, at 8:33 AM, Martin Andersson <martin.andersson at purplescout.se> wrote:
> >
> >> I agree. I don't think mapping a datasource in jboss-web.xml is such an exotic use case. I should just work.
> >
> > It?s not, it?s actually implied by the standard, as you can define them in web.xml as well. It?s a lifecycle problem we need to solve.
> >
> >> Also, there is no hint anywere that there is a property you can set to make it work.
> >>
> >> The proprietary jboss namespace is not an option since I want to be vendor neutral, but ear/java:app is definitely an option.
> >
> > Another solution specific to EE7 is you can leave the jta-data-source undefined in persistence.xml which will use the platforms default data source. We allow you to point that anywhere. However, that limits you to one, so not really a complete solution.
> >
> > A more complete solution is to use a common global name, and define an alias to your deployment in our naming subsystem like so:
> >
> > <bindings>
> >   <lookup name="java:global/env/FooDS" lookup="java:jboss/datasources/ExampleDS"/>
> > </bindings>
> >
> 
> Actually don?t waste your time on this alias option. PeristenceUnitServiceHandler?s approach to names will prevent it from working.
> 
> ?
> 
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
> 
> 
> 
> 
> -- 
> H?lsningar,
> Martin Andersson
> Purple Scout AB
> +46 732 05 14 01

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



From emartins at redhat.com  Fri Jan 31 12:47:07 2014
From: emartins at redhat.com (Eduardo Martins)
Date: Fri, 31 Jan 2014 17:47:07 +0000
Subject: [wildfly-dev] How to deal with resource refs when deploying JPA
	container managed entity managers (WFLY-2841)
In-Reply-To: <4EAAB570-7945-4890-86AF-52EB237FDAB4@redhat.com>
References: <52EABB89.6080704@redhat.com>
	<CAE=-AhAtqZfv51+aNMiLjmixkRfSjhAFNDscXDN=0fKY6+FvOg@mail.gmail.com>
	<52EB9D27.3080904@redhat.com>
	<CACmAtJs5GXKsaYD6DfW3LT-EbJmOZ_DMZPnDbL70or_mXAqYSQ@mail.gmail.com>
	<52EBA17A.5060502@redhat.com>
	<3E8BA64D-FE33-467E-91B6-73DF0D8837BF@redhat.com>
	<CACmAtJu=1EmmEnS06g1xD7hLw0_kc2DNpytEqMZOdeufa5aRww@mail.gmail.com>
	<9E806186-CE64-4B0C-981A-5BAE9A426B06@redhat.com>
	<ACE1C0FC-A80C-439C-8934-783C78E22871@redhat.com>
	<CACmAtJtGMzxRfZOXNxGiyCpd-HXsehwMwvY8aFoEJiVeV4giPQ@mail.gmail.com>
	<4EAAB570-7945-4890-86AF-52EB237FDAB4@redhat.com>
Message-ID: <0813555A-4A39-44A9-9C04-193D3BED2359@redhat.com>

It works when the MSC binder service?s ManagedReferenceFactory has the datasource, but it won?t work for external contexts (jndi federation) or link refs (which we don?t officially support). We should fix that by replacing the bind service dependency, with an injection using a LookupInjectionSource.

?E

On 31 Jan 2014, at 17:34, Jason Greene <jason.greene at redhat.com> wrote:

> Ah yes it does use ManagedReferenceFactory so is reliable, I just misinterpreted the earlier conversation about there being a hard dep on the data source.
> 
> On Jan 31, 2014, at 11:03 AM, Martin Andersson <martin.andersson at purplescout.se> wrote:
> 
>> Thanks for your input!
>> 
>> The alias and global naming does actually work!
>> 
>> Br,
>> Martin Andersson
>> Java EE developer at www.purplescout.se
>> 
>> 
>> 
>> On Fri, Jan 31, 2014 at 5:56 PM, Jason Greene <jason.greene at redhat.com> wrote:
>> 
>> On Jan 31, 2014, at 10:39 AM, Jason Greene <jason.greene at redhat.com> wrote:
>> 
>>> 
>>> On Jan 31, 2014, at 8:33 AM, Martin Andersson <martin.andersson at purplescout.se> wrote:
>>> 
>>>> I agree. I don't think mapping a datasource in jboss-web.xml is such an exotic use case. I should just work.
>>> 
>>> It?s not, it?s actually implied by the standard, as you can define them in web.xml as well. It?s a lifecycle problem we need to solve.
>>> 
>>>> Also, there is no hint anywere that there is a property you can set to make it work.
>>>> 
>>>> The proprietary jboss namespace is not an option since I want to be vendor neutral, but ear/java:app is definitely an option.
>>> 
>>> Another solution specific to EE7 is you can leave the jta-data-source undefined in persistence.xml which will use the platforms default data source. We allow you to point that anywhere. However, that limits you to one, so not really a complete solution.
>>> 
>>> A more complete solution is to use a common global name, and define an alias to your deployment in our naming subsystem like so:
>>> 
>>> <bindings>
>>>  <lookup name="java:global/env/FooDS" lookup="java:jboss/datasources/ExampleDS"/>
>>> </bindings>
>>> 
>> 
>> Actually don?t waste your time on this alias option. PeristenceUnitServiceHandler?s approach to names will prevent it from working.
>> 
>> ?
>> 
>> Jason T. Greene
>> WildFly Lead / JBoss EAP Platform Architect
>> JBoss, a division of Red Hat
>> 
>> 
>> 
>> 
>> -- 
>> H?lsningar,
>> Martin Andersson
>> Purple Scout AB
>> +46 732 05 14 01
> 
> --
> 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/20140131/ec6461a9/attachment.html 

From cfang at redhat.com  Fri Jan 31 13:07:11 2014
From: cfang at redhat.com (Cheng Fang)
Date: Fri, 31 Jan 2014 13:07:11 -0500
Subject: [wildfly-dev] "It's The Final Countdown!"
In-Reply-To: <C380E806-0FAD-4A87-A2C0-90F357BFF9F7@redhat.com>
References: <C380E806-0FAD-4A87-A2C0-90F357BFF9F7@redhat.com>
Message-ID: <52EBE64F.1060508@redhat.com>

For batch subsystem, James and I are working on a couple of issues user 
just reported this week.  We hope to include these fixes into the 
Final.  We should be able to release jberet 1.0.0.Final early next week.

Cheng

On 1/21/14, 2:00 PM, Jason Greene wrote:
> No this isn?t the Europe song (Sorry to disappoint!).
>
> It is however the countdown to WildFly 8 Final release!
>
> The key things that remain are:
>
> 1) Final Components - We need PRs upgrading to ?Final? for all outstanding
> subcomponents[1]. If you own one of them, then please make this a high priority.
> The sooner the better.
>
> 2) Identify Blockers - We need to identify all remaining blockers that have been
> reported against CR1. I?m hoping everyone can look through the forms for likely
> blockers and convert them to JIRAs. As a reminder a blocker is anything that is
> mass user effecting and severe in nature. Examples include: hangs, crashes,
> memory leaks, vulnerabilities, and data corruption.
>
> 3) JASPIC Acceptance - A few of you on this list have noted issues. We need to
> ensure that the Final release has addressed the outstanding issues.
>
> Thanks!
>
> [1] Outstanding components.
>
> io.undertow 1.0.0.Beta30
> io.undertow.jastow 1.0.0.CR1
> org.glassfish.javax.el 3.0-b07
> org.hibernate.search 4.5.0.Alpha2 *exception*
> org.infinispan.protostream 1.0.0.CR1
> org.jberet 1.0.0.CR1
> org.jboss.ejb-client 2.0.0.Beta5
> org.jboss.narayana 5.0.0.CR2
> org.jboss.jsfunit 2.0.0.Beta1
> org.jboss.logging.jboss-logging-tools 1.2.0.Beta1
> org.jboss.metadata 8.0.0.CR1
> org.jboss.mod_cluster 1.3.0.Alpha1
> org.jboss.msc.jboss-msc 1.2.0.CR1
> org.jboss.xnio.netty.netty-xnio-transport 0.1.1.CR2
> org.jboss.remote-naming 2.0.0.Beta2
> org.jboss.remoting 4.0.0.Beta3
> org.jboss.remotingjmx.remoting-jmx 2.0.0.CR4
> org.jboss.sasl 1.0.4.CR1
> org.jboss.spec.javax.el.jboss-el-api_3.0_spec 1.0.0.Beta1
> org.jboss.spec.javax.security.auth.message.jboss-jaspi-api_1.1_spec 1.0.0.Alpha1
> org.jboss.spec.javax.security.jacc.jboss-jacc-api_1.5_spec 1.0.0.Beta1
> org.jboss.spec.javax.servlet.jsp.jboss-jsp-api_2.3_spec 1.0.0.Beta1
> org.jboss.spec.javax.servlet.jstl.jboss-jstl-api_1.2_spec 1.0.4.Beta1
> org.jboss.xnio 3.2.0.Beta4
> org.picketbox 4.0.20.Beta4
> org.wildfly.security.manager 1.0.0.Beta3
>
>
>
> --
> 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  Fri Jan 31 15:27:34 2014
From: jason.greene at redhat.com (Jason Greene)
Date: Fri, 31 Jan 2014 14:27:34 -0600
Subject: [wildfly-dev] "It's The Final Countdown!"
In-Reply-To: <52EBE64F.1060508@redhat.com>
References: <C380E806-0FAD-4A87-A2C0-90F357BFF9F7@redhat.com>
	<52EBE64F.1060508@redhat.com>
Message-ID: <4EA3B84E-3CDE-4418-A060-DCB86313047D@redhat.com>

Ok. We are hoping to release next week, so please get it out as soon as you can.

On Jan 31, 2014, at 12:07 PM, Cheng Fang <cfang at redhat.com> wrote:

> For batch subsystem, James and I are working on a couple of issues user 
> just reported this week.  We hope to include these fixes into the 
> Final.  We should be able to release jberet 1.0.0.Final early next week.
> 
> Cheng
> 
> On 1/21/14, 2:00 PM, Jason Greene wrote:
>> No this isn?t the Europe song (Sorry to disappoint!).
>> 
>> It is however the countdown to WildFly 8 Final release!
>> 
>> The key things that remain are:
>> 
>> 1) Final Components - We need PRs upgrading to ?Final? for all outstanding
>> subcomponents[1]. If you own one of them, then please make this a high priority.
>> The sooner the better.
>> 
>> 2) Identify Blockers - We need to identify all remaining blockers that have been
>> reported against CR1. I?m hoping everyone can look through the forms for likely
>> blockers and convert them to JIRAs. As a reminder a blocker is anything that is
>> mass user effecting and severe in nature. Examples include: hangs, crashes,
>> memory leaks, vulnerabilities, and data corruption.
>> 
>> 3) JASPIC Acceptance - A few of you on this list have noted issues. We need to
>> ensure that the Final release has addressed the outstanding issues.
>> 
>> Thanks!
>> 
>> [1] Outstanding components.
>> 
>> io.undertow 1.0.0.Beta30
>> io.undertow.jastow 1.0.0.CR1
>> org.glassfish.javax.el 3.0-b07
>> org.hibernate.search 4.5.0.Alpha2 *exception*
>> org.infinispan.protostream 1.0.0.CR1
>> org.jberet 1.0.0.CR1
>> org.jboss.ejb-client 2.0.0.Beta5
>> org.jboss.narayana 5.0.0.CR2
>> org.jboss.jsfunit 2.0.0.Beta1
>> org.jboss.logging.jboss-logging-tools 1.2.0.Beta1
>> org.jboss.metadata 8.0.0.CR1
>> org.jboss.mod_cluster 1.3.0.Alpha1
>> org.jboss.msc.jboss-msc 1.2.0.CR1
>> org.jboss.xnio.netty.netty-xnio-transport 0.1.1.CR2
>> org.jboss.remote-naming 2.0.0.Beta2
>> org.jboss.remoting 4.0.0.Beta3
>> org.jboss.remotingjmx.remoting-jmx 2.0.0.CR4
>> org.jboss.sasl 1.0.4.CR1
>> org.jboss.spec.javax.el.jboss-el-api_3.0_spec 1.0.0.Beta1
>> org.jboss.spec.javax.security.auth.message.jboss-jaspi-api_1.1_spec 1.0.0.Alpha1
>> org.jboss.spec.javax.security.jacc.jboss-jacc-api_1.5_spec 1.0.0.Beta1
>> org.jboss.spec.javax.servlet.jsp.jboss-jsp-api_2.3_spec 1.0.0.Beta1
>> org.jboss.spec.javax.servlet.jstl.jboss-jstl-api_1.2_spec 1.0.4.Beta1
>> org.jboss.xnio 3.2.0.Beta4
>> org.picketbox 4.0.20.Beta4
>> org.wildfly.security.manager 1.0.0.Beta3
>> 
>> 
>> 
>> --
>> 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

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



From jason.greene at redhat.com  Fri Jan 31 15:48:14 2014
From: jason.greene at redhat.com (Jason Greene)
Date: Fri, 31 Jan 2014 14:48:14 -0600
Subject: [wildfly-dev] Wildfly Quickstarts
In-Reply-To: <B63E885B-C986-4AC6-A873-2CD95345C0F9@redhat.com>
References: <D9408698-B803-4966-9098-CBA9DC56F5FC@redhat.com>
	<CAMquZP4ye11m=T6mO7ON7KyMaF7cxQ9pO_2EPjXpcRo+Ab8DaQ@mail.gmail.com>
	<B63E885B-C986-4AC6-A873-2CD95345C0F9@redhat.com>
Message-ID: <DCCEBDA4-27DD-4E7E-B808-9A6F876D0762@redhat.com>

They will likely evolve outside of the fork we created which is fine. I think our priority should be ensuring these are ported and run as is. Then after that I would suggest just updating the most common ones to use EE7 APIs.


On Jan 29, 2014, at 8:31 AM, Eduardo Martins <emartins at redhat.com> wrote:

> Those are the ones I?m working with, but afaik the JDF EAP ones are the same.
> 
> ?E
> 
> On 28 Jan 2014, at 22:38, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
> 
>> Aren't we updating quick starts here https://github.com/wildfly/quickstart ?
>> I thought that jdf ones ware mostly for EAP...
>> 
>> --
>> tomaz
>> 
>> 
>> On Tue, Jan 28, 2014 at 2:06 PM, Eduardo Martins <emartins at redhat.com> wrote:
>> I have been updating Wildfly Quickstarts, for now mostly reworking Maven POMs to use the updated dependencies, but it?s a long way to go, there are a lot of quickstarts, and no way all of these will be ready for primetime when WFLY 8 is out. So I was thinking in changing my strategy, and define a list with quickstarts of highest priority to be ready very soon.
>> 
>> The quickstarts list can be seen at http://www.jboss.org/jdf/quickstarts/get-started/
>> 
>> May a person related to each Java EE spec/technology go through that list and help my build the priority list? My guess is that first priority is to have the ones that show off Java EE and Wildfly 8 features only, leaving the ones that show integration with other JBoss projects for a second release, but still this will be a big list so I definitely need help.
>> 
>> Also, we will need new Batch quickstart(s).
>> 
>> Thanks in advance.
>> 
>> ?E
>> 
>> 
>> _______________________________________________
>> 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

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



From tomaz.cerar at gmail.com  Fri Jan 31 20:19:00 2014
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Sat, 1 Feb 2014 02:19:00 +0100
Subject: [wildfly-dev] JDK 8 Build 126 & JDK 7 Update 60 build 04 are
	available on java.net
In-Reply-To: <52EB6711.8010602@oracle.com>
References: <52EB6711.8010602@oracle.com>
Message-ID: <CAMquZP6z-8s8C7Vnq=mw7ZbT+9+NJWHjJCcLfQ-_HNr9CE8pKw@mail.gmail.com>

Hey Rory,

I get quite clean run of full WildFly testsuite on JDK8 lately, one of last
issues was https://bugs.openjdk.java.net/browse/JDK-8024935
but we fixed that by upgrading to 4.3.1 of ecj.

We have few small issues here and there but I am quite confident that our
WildFly 8 works fine with JDK8.

--
tomaz


On Fri, Jan 31, 2014 at 10:04 AM, Rory O'Donnell Oracle, Dublin Ireland <
rory.odonnell at oracle.com> wrote:

>  Hi Guys,
>
> JDK 8 Build b126 Early Access Build is now available for download<http://jdk8.java.net/download.html>& test.
> JDK 7u60 b04 Early Access Build is also available for download
> <https://jdk7.java.net/download.html>& test.
>
> 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/20140201/44296de4/attachment.html