From sanne at hibernate.org  Mon Aug  1 06:22:20 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 1 Aug 2016 11:22:20 +0100
Subject: [wildfly-dev] 10.1.0.CR1 is available! Try it out!
In-Reply-To: <EC275E4B-9D86-43C5-9525-AAA630BE1F01@redhat.com>
References: <EC275E4B-9D86-43C5-9525-AAA630BE1F01@redhat.com>
Message-ID: <CAFm4XO1ccUE=7iqNjzdcY2y1p3fR2=79m3ChXvCq1kd3onvx4Q@mail.gmail.com>

Thanks and congratulations!

One very minor issue, I see that the following issue is included in
the release notes, however this wasn't actually done:
 - https://issues.jboss.org/browse/WFLY-6682 - Upgrade Hibernate to 5.2.0

Thanks,
Sanne


On 29 July 2016 at 21:12, Jason Greene <jason.greene at redhat.com> wrote:
> Some of you may have noticed that 10.1.0.CR1 was released yesterday:
> http://wildfly.org/downloads/
>
> Please give it a try and report any major issues. Provided nothing critical comes up, we will release Final next week.
>
> Major new features include:
> - Out of the box HTTP/2 support
> - TLS cert auto-generation
> - Load-balancing profile is now in our default domain.xml config
> - Support for clustering node discovery on Azure (jgroups AZURE_PING)
>
> Overall there are 308 issues resolved in this release:
> https://issues.jboss.org/secure/ReleaseNote.jspa?version=12329499&styleName=Html&projectId=12313721
>
> Thanks again!
> --
> 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 ssilvert at redhat.com  Wed Aug  3 09:53:48 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 03 Aug 2016 09:53:48 -0400
Subject: [wildfly-dev] Need write to standalone.xml after parsing
Message-ID: <57A1F76C.7070209@redhat.com>

The Keycloak server is currently configured via a keycloak-server.json 
file.  We are converting this to configuration through 
standalone.xml/domain.xml.

To automatically upgrade, I need to read keycloak-server.json and write 
back to standalone.xml.  I can easily add the operations to do this at 
parse time.  The parser has this method:

@Override
public void readElement(final XMLExtendedStreamReader reader, final 
List<ModelNode> list) throws XMLStreamException

So one way to do this is to parse keycloak-server.json at this time and 
add operations to the list.

That puts everything into the management model.  But nothing will be 
written to standalone.xml unless someone manually does a write operation 
from CLI.

So my question is, what is the best way to accomplish this?  Is there a 
good, safe way to manually trigger a flush to standalone.xml at this 
point or at some later point during startup?

Stan

From ropalka at redhat.com  Wed Aug  3 12:31:37 2016
From: ropalka at redhat.com (Richard Opalka)
Date: Wed, 3 Aug 2016 18:31:37 +0200
Subject: [wildfly-dev] Is it proper time to remove JBoss VFS?
Message-ID: <cc5046a0-316c-96a7-1976-4e8cff80eefe@redhat.com>

Hi all,


I'm wondering if it makes sense for 
https://github.com/wildfly/wildfly-core/pull/1261

to be considered for integration with upstream now when we have

wildfly / 10.x and wildfly-core / 2.x branches in place?


Or is EAP 7.1 going to be based on WildFly 11 and it is still not a good 
time?


Regards,

Rio

From ken at zaptillion.net  Wed Aug  3 15:07:54 2016
From: ken at zaptillion.net (Ken Wills)
Date: Wed, 3 Aug 2016 14:07:54 -0500
Subject: [wildfly-dev] Need write to standalone.xml after parsing
In-Reply-To: <57A23FD0.5000305@redhat.com>
References: <57A1F76C.7070209@redhat.com>
	<CADJSdWpOdZoeobZjk7DyK4Fp+WjgYdH1+mZ6qkmw=o9mwmoadw@mail.gmail.com>
	<57A23FD0.5000305@redhat.com>
Message-ID: <CADJSdWpT2A+kcLi0+QEqBTsydwHc=4ean_gqPKXgoK0wwmVp+Q@mail.gmail.com>

On Wed, Aug 3, 2016 at 2:02 PM, Stan Silvert <ssilvert at redhat.com> wrote:

> On 8/3/2016 2:49 PM, Ken Wills wrote:
>
> On Wed, Aug 3, 2016 at 8:53 AM, Stan Silvert <ssilvert at redhat.com> wrote:
>
>> The Keycloak server is currently configured via a keycloak-server.json
>> file.  We are converting this to configuration through
>> standalone.xml/domain.xml.
>>
>> To automatically upgrade, I need to read keycloak-server.json and write
>> back to standalone.xml.  I can easily add the operations to do this at
>> parse time.  The parser has this method:
>>
>> @Override
>> public void readElement(final XMLExtendedStreamReader reader, final
>> List<ModelNode> list) throws XMLStreamException
>>
>> So one way to do this is to parse keycloak-server.json at this time and
>> add operations to the list.
>>
>> That puts everything into the management model.  But nothing will be
>> written to standalone.xml unless someone manually does a write operation
>> from CLI.
>>
>>
> Not sure if this is exactly what you're looking for, but subsystems /
> extensions usually register an XMLElementWriter for themselves to handle
> this, see for exmaple:
>
>
> https://github.com/wildfly/wildfly/blob/9de9217e0106da10c7d05228bcf0559c81b6042c/clustering/infinispan/extension/src/main/java/org/jboss/as/clustering/infinispan/subsystem/InfinispanExtension.java#L52
>
> Ken
>
> My problem is that the XMLElementWriter is never called during startup.
> I would like it to be called after the management model is read from
> standalone.xml but before deployments are handled.
>

Hmm. Not sure about that one, I"ll have a look.

PS: Sorry for replying only to you, I mean't to include the list too. [cc:
wildfly-dev added back.]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160803/aba35d07/attachment.html 

From jperkins at redhat.com  Wed Aug  3 15:58:20 2016
From: jperkins at redhat.com (James Perkins)
Date: Wed, 3 Aug 2016 12:58:20 -0700
Subject: [wildfly-dev] Need write to standalone.xml after parsing
In-Reply-To: <57A1F76C.7070209@redhat.com>
References: <57A1F76C.7070209@redhat.com>
Message-ID: <CADGwLpj5azm=HVEoiFur739e8aeW5eOsKdE4OKEoos=krYVfOg@mail.gmail.com>

On Wed, Aug 3, 2016 at 6:53 AM, Stan Silvert <ssilvert at redhat.com> wrote:

> The Keycloak server is currently configured via a keycloak-server.json
> file.  We are converting this to configuration through
> standalone.xml/domain.xml.
>
> To automatically upgrade, I need to read keycloak-server.json and write
> back to standalone.xml.  I can easily add the operations to do this at
> parse time.  The parser has this method:
>
> @Override
> public void readElement(final XMLExtendedStreamReader reader, final
> List<ModelNode> list) throws XMLStreamException
>

Reading an external resource from the subsystem parsing doesn't feel right
to me. Is the goal to move away from the keycloak-server.json to using the
management model?

If that is the goal then a better solution might be to have some sort of
migration operation that would read the file and create the subsystem
model. Then after that the keycloak-server.json is ignored and the *.xml
file will be used.


>
> So one way to do this is to parse keycloak-server.json at this time and
> add operations to the list.
>
> That puts everything into the management model.  But nothing will be
> written to standalone.xml unless someone manually does a write operation
> from CLI.
>

A write will be triggered if you make a change to the management model.


>
> So my question is, what is the best way to accomplish this?  Is there a
> good, safe way to manually trigger a flush to standalone.xml at this
> point or at some later point during startup?
>

Not really an answer, but I hope there is not a way to trigger a write :)


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



-- 
James R. Perkins
JBoss by Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160803/1234826f/attachment.html 

From jperkins at redhat.com  Wed Aug  3 16:22:26 2016
From: jperkins at redhat.com (James Perkins)
Date: Wed, 3 Aug 2016 13:22:26 -0700
Subject: [wildfly-dev] Need write to standalone.xml after parsing
In-Reply-To: <CADGwLpj5azm=HVEoiFur739e8aeW5eOsKdE4OKEoos=krYVfOg@mail.gmail.com>
References: <57A1F76C.7070209@redhat.com>
	<CADGwLpj5azm=HVEoiFur739e8aeW5eOsKdE4OKEoos=krYVfOg@mail.gmail.com>
Message-ID: <CADGwLph--+JddbwHPYbOZAf=HeqjXz3z7roj-Ynots4Qybh3ZQ@mail.gmail.com>

On Wed, Aug 3, 2016 at 12:58 PM, James Perkins <jperkins at redhat.com> wrote:

>
>
> On Wed, Aug 3, 2016 at 6:53 AM, Stan Silvert <ssilvert at redhat.com> wrote:
>
>> The Keycloak server is currently configured via a keycloak-server.json
>> file.  We are converting this to configuration through
>> standalone.xml/domain.xml.
>>
>> To automatically upgrade, I need to read keycloak-server.json and write
>> back to standalone.xml.  I can easily add the operations to do this at
>> parse time.  The parser has this method:
>>
>> @Override
>> public void readElement(final XMLExtendedStreamReader reader, final
>> List<ModelNode> list) throws XMLStreamException
>>
>
> Reading an external resource from the subsystem parsing doesn't feel right
> to me. Is the goal to move away from the keycloak-server.json to using the
> management model?
>
> If that is the goal then a better solution might be to have some sort of
> migration operation that would read the file and create the subsystem
> model. Then after that the keycloak-server.json is ignored and the *.xml
> file will be used.
>
>
>>
>> So one way to do this is to parse keycloak-server.json at this time and
>> add operations to the list.
>>
>> That puts everything into the management model.  But nothing will be
>> written to standalone.xml unless someone manually does a write operation
>> from CLI.
>>
>
> A write will be triggered if you make a change to the management model.
>

I need to correct myself here. Persistence won't happen during a boot. So
when I say the management model needs to change what I mean is after boot
it needs to change for the write to persistent storage will be invoked.


>
>
>>
>> So my question is, what is the best way to accomplish this?  Is there a
>> good, safe way to manually trigger a flush to standalone.xml at this
>> point or at some later point during startup?
>>
>
> Not really an answer, but I hope there is not a way to trigger a write :)
>
>
>>
>> Stan
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
>
> --
> James R. Perkins
> JBoss by Red Hat
>



-- 
James R. Perkins
JBoss by Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160803/3fc2c6fd/attachment-0001.html 

From bburke at redhat.com  Wed Aug  3 18:08:53 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 3 Aug 2016 18:08:53 -0400
Subject: [wildfly-dev] enhancement: layers.conf can use maven artifacts
Message-ID: <fc5f573c-b4e7-67c2-f571-33de0aab6df5@redhat.com>

I was thinking about how installation, patching, and distribution could 
be made easier and more flexible.  What if layers.conf could reference a 
maven artifact?


layers=org.keycloak:keycloak-modules:1.5

The module layer of keycloak could be stored in a maven repo. 
Upgrading/patching could be just bump the version in layers.conf. If 
layers.conf also honored the list as a priority list, listed layers 
could override previously listed layers.

If module layer the module defs also reference their jars as maven 
artifacts, patches are really small as they are just module.xml files.

Bill


From stuart.w.douglas at gmail.com  Wed Aug  3 22:06:25 2016
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Thu, 4 Aug 2016 12:06:25 +1000
Subject: [wildfly-dev] enhancement: layers.conf can use maven artifacts
In-Reply-To: <fc5f573c-b4e7-67c2-f571-33de0aab6df5@redhat.com>
References: <fc5f573c-b4e7-67c2-f571-33de0aab6df5@redhat.com>
Message-ID: <CAAoo=c58BOTdE37JdgZLN9etfb6jVFoFnrd9oWhAS7KgOYirLQ@mail.gmail.com>

We have actually been talking about something kinda similar to this, but
based on a redesign of the provisioning system rather than using
layers.conf. The notes from the meeting we had about it are here:

https://github.com/stuartwdouglas/wildfly-provisioning/blob/master/docs/src/main/asciidoc/design-doc.asciidoc

Basically it allows servers to be provisioned/patched in a manner kind of
similar to what you describe.

Stuart

On Thu, Aug 4, 2016 at 8:08 AM, Bill Burke <bburke at redhat.com> wrote:

> I was thinking about how installation, patching, and distribution could
> be made easier and more flexible.  What if layers.conf could reference a
> maven artifact?
>
>
> layers=org.keycloak:keycloak-modules:1.5
>
> The module layer of keycloak could be stored in a maven repo.
> Upgrading/patching could be just bump the version in layers.conf. If
> layers.conf also honored the list as a priority list, listed layers
> could override previously listed layers.
>
> If module layer the module defs also reference their jars as maven
> artifacts, patches are really small as they are just module.xml files.
>
> Bill
>
> _______________________________________________
> 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/20160804/c8d81ff7/attachment.html 

From ssilvert at redhat.com  Thu Aug  4 07:22:36 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 04 Aug 2016 07:22:36 -0400
Subject: [wildfly-dev] Need write to standalone.xml after parsing
In-Reply-To: <CADGwLpj5azm=HVEoiFur739e8aeW5eOsKdE4OKEoos=krYVfOg@mail.gmail.com>
References: <57A1F76C.7070209@redhat.com>
	<CADGwLpj5azm=HVEoiFur739e8aeW5eOsKdE4OKEoos=krYVfOg@mail.gmail.com>
Message-ID: <57A3257C.6050802@redhat.com>

On 8/3/2016 3:58 PM, James Perkins wrote:
>
>
> On Wed, Aug 3, 2016 at 6:53 AM, Stan Silvert <ssilvert at redhat.com 
> <mailto:ssilvert at redhat.com>> wrote:
>
>     The Keycloak server is currently configured via a keycloak-server.json
>     file.  We are converting this to configuration through
>     standalone.xml/domain.xml.
>
>     To automatically upgrade, I need to read keycloak-server.json and
>     write
>     back to standalone.xml.  I can easily add the operations to do this at
>     parse time.  The parser has this method:
>
>     @Override
>     public void readElement(final XMLExtendedStreamReader reader, final
>     List<ModelNode> list) throws XMLStreamException
>
>
> Reading an external resource from the subsystem parsing doesn't feel 
> right to me. Is the goal to move away from the keycloak-server.json to 
> using the management model?
Yes, that's the goal.  I'd like it to happen automatically when the 
server is upgraded to a new version of the Keycloak subsystem.  So we 
need to read keyclaok-server.json and write to standalone.xml/domain.xml.
>
> If that is the goal then a better solution might be to have some sort 
> of migration operation that would read the file and create the 
> subsystem model. Then after that the keycloak-server.json is ignored 
> and the *.xml file will be used.
That's exactly what I am trying to accomplish.  I can create the 
subsystem model easily.  But a write to standalone.xml doesn't happen 
during server startup.
>
>
>     So one way to do this is to parse keycloak-server.json at this
>     time and
>     add operations to the list.
>
>     That puts everything into the management model.  But nothing will be
>     written to standalone.xml unless someone manually does a write
>     operation
>     from CLI.
>
>
> A write will be triggered if you make a change to the management model.
>
>
>     So my question is, what is the best way to accomplish this?  Is
>     there a
>     good, safe way to manually trigger a flush to standalone.xml at this
>     point or at some later point during startup?
>
>
> Not really an answer, but I hope there is not a way to trigger a write :)
This could be done without harm as long as it is managed properly.

If there is no way to do it then I'll have to make it a separate 
operation that the administrator has to run using offline CLI. That's 
far from ideal as I would rather it happen automatically as part of the 
upgrade.
>
>
>     Stan
>     _______________________________________________
>     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
>
>
>
>
> -- 
> James R. Perkins
> JBoss by Red Hat

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

From jperkins at redhat.com  Thu Aug  4 13:49:23 2016
From: jperkins at redhat.com (James Perkins)
Date: Thu, 4 Aug 2016 10:49:23 -0700
Subject: [wildfly-dev] Need write to standalone.xml after parsing
In-Reply-To: <57A3257C.6050802@redhat.com>
References: <57A1F76C.7070209@redhat.com>
	<CADGwLpj5azm=HVEoiFur739e8aeW5eOsKdE4OKEoos=krYVfOg@mail.gmail.com>
	<57A3257C.6050802@redhat.com>
Message-ID: <CADGwLpgmwCyDxYDB2460XE5yoG7KJzcFadgJeWSricFFQB=5Hw@mail.gmail.com>

On Thu, Aug 4, 2016 at 4:22 AM, Stan Silvert <ssilvert at redhat.com> wrote:

> On 8/3/2016 3:58 PM, James Perkins wrote:
>
>
>
> On Wed, Aug 3, 2016 at 6:53 AM, Stan Silvert <ssilvert at redhat.com> wrote:
>
>> The Keycloak server is currently configured via a keycloak-server.json
>> file.  We are converting this to configuration through
>> standalone.xml/domain.xml.
>>
>> To automatically upgrade, I need to read keycloak-server.json and write
>> back to standalone.xml.  I can easily add the operations to do this at
>> parse time.  The parser has this method:
>>
>> @Override
>> public void readElement(final XMLExtendedStreamReader reader, final
>> List<ModelNode> list) throws XMLStreamException
>>
>
> Reading an external resource from the subsystem parsing doesn't feel right
> to me. Is the goal to move away from the keycloak-server.json to using the
> management model?
>
> Yes, that's the goal.  I'd like it to happen automatically when the server
> is upgraded to a new version of the Keycloak subsystem.  So we need to read
> keyclaok-server.json and write to standalone.xml/domain.xml.
>
>
> If that is the goal then a better solution might be to have some sort of
> migration operation that would read the file and create the subsystem
> model. Then after that the keycloak-server.json is ignored and the *.xml
> file will be used.
>
> That's exactly what I am trying to accomplish.  I can create the subsystem
> model easily.  But a write to standalone.xml doesn't happen during server
> startup.
>

It's designed to never write at startup because during boot the the
configuration is read and we shouldn't modify without the user
acknowledging there is going to be a change. That's why a migration
operation would be preferred as it's explicit.


>
>
>
>>
>> So one way to do this is to parse keycloak-server.json at this time and
>> add operations to the list.
>>
>> That puts everything into the management model.  But nothing will be
>> written to standalone.xml unless someone manually does a write operation
>> from CLI.
>>
>
> A write will be triggered if you make a change to the management model.
>
>
>>
>> So my question is, what is the best way to accomplish this?  Is there a
>> good, safe way to manually trigger a flush to standalone.xml at this
>> point or at some later point during startup?
>>
>
> Not really an answer, but I hope there is not a way to trigger a write :)
>
> This could be done without harm as long as it is managed properly.
>

The only time this would ever be needed is during a boot. I really think
it's a bad idea to modify persistent configuration during a boot. The user
has no idea this is being done.


>
>
> If there is no way to do it then I'll have to make it a separate operation
> that the administrator has to run using offline CLI.  That's far from ideal
> as I would rather it happen automatically as part of the upgrade.
>

IMO an upgrade or patch is an explicit action. It requires some kind of
interaction and expecting a user to execute an operation after a component
upgrade doesn't seem unreasonable to me.

An option for the future will be to use the new provisioning [1].

[1]:
https://github.com/stuartwdouglas/wildfly-provisioning/blob/master/docs/src/main/asciidoc/design-doc.asciidoc


>
>
>
>>
>> Stan
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
>
> --
> James R. Perkins
> JBoss by Red Hat
>
>
>


-- 
James R. Perkins
JBoss by Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160804/fd254592/attachment-0001.html 

From stuart.w.douglas at gmail.com  Thu Aug  4 20:22:56 2016
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Fri, 5 Aug 2016 10:22:56 +1000
Subject: [wildfly-dev] Need write to standalone.xml after parsing
In-Reply-To: <57A3257C.6050802@redhat.com>
References: <57A1F76C.7070209@redhat.com>
	<CADGwLpj5azm=HVEoiFur739e8aeW5eOsKdE4OKEoos=krYVfOg@mail.gmail.com>
	<57A3257C.6050802@redhat.com>
Message-ID: <CAAoo=c7rhPWJ3GHmthLrh2JqQVDahbKPzkVJAjvna-ATPQ2xWw@mail.gmail.com>

Longer term we have started looking at a provisioning system that should
(hopefully) handle the problem of making management model changes on
upgrade.

I don't really understand why you need this functionality anyway, as you
will already have to issue management ops to actually add the new subsystem
to the server. Whatever is responsible for this could already read the json
file and issue the appropriate management operations.

Stuart

On Thu, Aug 4, 2016 at 9:22 PM, Stan Silvert <ssilvert at redhat.com> wrote:

> On 8/3/2016 3:58 PM, James Perkins wrote:
>
>
>
> On Wed, Aug 3, 2016 at 6:53 AM, Stan Silvert <ssilvert at redhat.com> wrote:
>
>> The Keycloak server is currently configured via a keycloak-server.json
>> file.  We are converting this to configuration through
>> standalone.xml/domain.xml.
>>
>> To automatically upgrade, I need to read keycloak-server.json and write
>> back to standalone.xml.  I can easily add the operations to do this at
>> parse time.  The parser has this method:
>>
>> @Override
>> public void readElement(final XMLExtendedStreamReader reader, final
>> List<ModelNode> list) throws XMLStreamException
>>
>
> Reading an external resource from the subsystem parsing doesn't feel right
> to me. Is the goal to move away from the keycloak-server.json to using the
> management model?
>
> Yes, that's the goal.  I'd like it to happen automatically when the server
> is upgraded to a new version of the Keycloak subsystem.  So we need to read
> keyclaok-server.json and write to standalone.xml/domain.xml.
>
>
> If that is the goal then a better solution might be to have some sort of
> migration operation that would read the file and create the subsystem
> model. Then after that the keycloak-server.json is ignored and the *.xml
> file will be used.
>
> That's exactly what I am trying to accomplish.  I can create the subsystem
> model easily.  But a write to standalone.xml doesn't happen during server
> startup.
>
>
>
>>
>> So one way to do this is to parse keycloak-server.json at this time and
>> add operations to the list.
>>
>> That puts everything into the management model.  But nothing will be
>> written to standalone.xml unless someone manually does a write operation
>> from CLI.
>>
>
> A write will be triggered if you make a change to the management model.
>
>
>>
>> So my question is, what is the best way to accomplish this?  Is there a
>> good, safe way to manually trigger a flush to standalone.xml at this
>> point or at some later point during startup?
>>
>
> Not really an answer, but I hope there is not a way to trigger a write :)
>
> This could be done without harm as long as it is managed properly.
>
> If there is no way to do it then I'll have to make it a separate operation
> that the administrator has to run using offline CLI.  That's far from ideal
> as I would rather it happen automatically as part of the upgrade.
>
>
>
>>
>> Stan
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
>
> --
> James R. Perkins
> JBoss by 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/20160805/5c5318fe/attachment.html 

From ssilvert at redhat.com  Fri Aug  5 07:16:26 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 05 Aug 2016 07:16:26 -0400
Subject: [wildfly-dev] Need write to standalone.xml after parsing
In-Reply-To: <CAAoo=c7rhPWJ3GHmthLrh2JqQVDahbKPzkVJAjvna-ATPQ2xWw@mail.gmail.com>
References: <57A1F76C.7070209@redhat.com>
	<CADGwLpj5azm=HVEoiFur739e8aeW5eOsKdE4OKEoos=krYVfOg@mail.gmail.com>
	<57A3257C.6050802@redhat.com>
	<CAAoo=c7rhPWJ3GHmthLrh2JqQVDahbKPzkVJAjvna-ATPQ2xWw@mail.gmail.com>
Message-ID: <57A4758A.8020100@redhat.com>

On 8/4/2016 8:22 PM, Stuart Douglas wrote:
> Longer term we have started looking at a provisioning system that 
> should (hopefully) handle the problem of making management model 
> changes on upgrade.
>
> I don't really understand why you need this functionality anyway, as 
> you will already have to issue management ops to actually add the new 
> subsystem to the server. Whatever is responsible for this could 
> already read the json file and issue the appropriate management 
> operations.
The subsystem already exists, but we are adding lots of attributes and 
resources to it.  I can add the management operations at parse time, but 
the new attributes and resources will not be persisted to standalone.xml.
>
> Stuart
>
> On Thu, Aug 4, 2016 at 9:22 PM, Stan Silvert <ssilvert at redhat.com 
> <mailto:ssilvert at redhat.com>> wrote:
>
>     On 8/3/2016 3:58 PM, James Perkins wrote:
>>
>>
>>     On Wed, Aug 3, 2016 at 6:53 AM, Stan Silvert <ssilvert at redhat.com
>>     <mailto:ssilvert at redhat.com>> wrote:
>>
>>         The Keycloak server is currently configured via a
>>         keycloak-server.json
>>         file.  We are converting this to configuration through
>>         standalone.xml/domain.xml.
>>
>>         To automatically upgrade, I need to read keycloak-server.json
>>         and write
>>         back to standalone.xml.  I can easily add the operations to
>>         do this at
>>         parse time.  The parser has this method:
>>
>>         @Override
>>         public void readElement(final XMLExtendedStreamReader reader,
>>         final
>>         List<ModelNode> list) throws XMLStreamException
>>
>>
>>     Reading an external resource from the subsystem parsing doesn't
>>     feel right to me. Is the goal to move away from the
>>     keycloak-server.json to using the management model?
>     Yes, that's the goal.  I'd like it to happen automatically when
>     the server is upgraded to a new version of the Keycloak
>     subsystem.  So we need to read keyclaok-server.json and write to
>     standalone.xml/domain.xml.
>>
>>     If that is the goal then a better solution might be to have some
>>     sort of migration operation that would read the file and create
>>     the subsystem model. Then after that the keycloak-server.json is
>>     ignored and the *.xml file will be used.
>     That's exactly what I am trying to accomplish.  I can create the
>     subsystem model easily.  But a write to standalone.xml doesn't
>     happen during server startup.
>>
>>
>>         So one way to do this is to parse keycloak-server.json at
>>         this time and
>>         add operations to the list.
>>
>>         That puts everything into the management model.  But nothing
>>         will be
>>         written to standalone.xml unless someone manually does a
>>         write operation
>>         from CLI.
>>
>>
>>     A write will be triggered if you make a change to the management
>>     model.
>>
>>
>>         So my question is, what is the best way to accomplish this? 
>>         Is there a
>>         good, safe way to manually trigger a flush to standalone.xml
>>         at this
>>         point or at some later point during startup?
>>
>>
>>     Not really an answer, but I hope there is not a way to trigger a
>>     write :)
>     This could be done without harm as long as it is managed properly.
>
>     If there is no way to do it then I'll have to make it a separate
>     operation that the administrator has to run using offline CLI. 
>     That's far from ideal as I would rather it happen automatically as
>     part of the upgrade.
>>
>>
>>         Stan
>>         _______________________________________________
>>         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
>>         <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>>
>>
>>
>>
>>     -- 
>>     James R. Perkins
>>     JBoss by Red Hat
>
>
>     _______________________________________________
>     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
>     <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>
>

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

From darran.lofthouse at jboss.com  Fri Aug  5 07:24:14 2016
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Fri, 5 Aug 2016 12:24:14 +0100
Subject: [wildfly-dev] Need write to standalone.xml after parsing
In-Reply-To: <57A4758A.8020100@redhat.com>
References: <57A1F76C.7070209@redhat.com>
	<CADGwLpj5azm=HVEoiFur739e8aeW5eOsKdE4OKEoos=krYVfOg@mail.gmail.com>
	<57A3257C.6050802@redhat.com>
	<CAAoo=c7rhPWJ3GHmthLrh2JqQVDahbKPzkVJAjvna-ATPQ2xWw@mail.gmail.com>
	<57A4758A.8020100@redhat.com>
Message-ID: <a6b452f6-1f46-258b-fdf5-752ae904c768@jboss.com>

But maybe that could be fine, on the next boot if no modifications were 
made to the config you could go through the same boot process and read 
the json again - if something triggered the save then the json reading 
can be skipped.  I assume you already have something in place to detect 
is parsing of the json is required?

There are also a group of users out there that want their configuration 
to be read only so this would cover those as well.

Darran.

On 05/08/16 12:16, Stan Silvert wrote:
> On 8/4/2016 8:22 PM, Stuart Douglas wrote:
>> Longer term we have started looking at a provisioning system that
>> should (hopefully) handle the problem of making management model
>> changes on upgrade.
>>
>> I don't really understand why you need this functionality anyway, as
>> you will already have to issue management ops to actually add the new
>> subsystem to the server. Whatever is responsible for this could
>> already read the json file and issue the appropriate management
>> operations.
> The subsystem already exists, but we are adding lots of attributes and
> resources to it.  I can add the management operations at parse time, but
> the new attributes and resources will not be persisted to standalone.xml.
>>
>> Stuart
>>
>> On Thu, Aug 4, 2016 at 9:22 PM, Stan Silvert <ssilvert at redhat.com
>> <mailto:ssilvert at redhat.com>> wrote:
>>
>>     On 8/3/2016 3:58 PM, James Perkins wrote:
>>>
>>>
>>>     On Wed, Aug 3, 2016 at 6:53 AM, Stan Silvert <ssilvert at redhat.com
>>>     <mailto:ssilvert at redhat.com>> wrote:
>>>
>>>         The Keycloak server is currently configured via a
>>>         keycloak-server.json
>>>         file.  We are converting this to configuration through
>>>         standalone.xml/domain.xml.
>>>
>>>         To automatically upgrade, I need to read keycloak-server.json
>>>         and write
>>>         back to standalone.xml.  I can easily add the operations to
>>>         do this at
>>>         parse time.  The parser has this method:
>>>
>>>         @Override
>>>         public void readElement(final XMLExtendedStreamReader reader,
>>>         final
>>>         List<ModelNode> list) throws XMLStreamException
>>>
>>>
>>>     Reading an external resource from the subsystem parsing doesn't
>>>     feel right to me. Is the goal to move away from the
>>>     keycloak-server.json to using the management model?
>>     Yes, that's the goal.  I'd like it to happen automatically when
>>     the server is upgraded to a new version of the Keycloak
>>     subsystem.  So we need to read keyclaok-server.json and write to
>>     standalone.xml/domain.xml.
>>>
>>>     If that is the goal then a better solution might be to have some
>>>     sort of migration operation that would read the file and create
>>>     the subsystem model. Then after that the keycloak-server.json is
>>>     ignored and the *.xml file will be used.
>>     That's exactly what I am trying to accomplish.  I can create the
>>     subsystem model easily.  But a write to standalone.xml doesn't
>>     happen during server startup.
>>>
>>>
>>>
>>>         So one way to do this is to parse keycloak-server.json at
>>>         this time and
>>>         add operations to the list.
>>>
>>>         That puts everything into the management model.  But nothing
>>>         will be
>>>         written to standalone.xml unless someone manually does a
>>>         write operation
>>>         from CLI.
>>>
>>>
>>>     A write will be triggered if you make a change to the management
>>>     model.
>>>
>>>
>>>
>>>         So my question is, what is the best way to accomplish this?
>>>         Is there a
>>>         good, safe way to manually trigger a flush to standalone.xml
>>>         at this
>>>         point or at some later point during startup?
>>>
>>>
>>>     Not really an answer, but I hope there is not a way to trigger a
>>>     write :)
>>     This could be done without harm as long as it is managed properly.
>>
>>     If there is no way to do it then I'll have to make it a separate
>>     operation that the administrator has to run using offline CLI.
>>     That's far from ideal as I would rather it happen automatically as
>>     part of the upgrade.
>>>
>>>
>>>
>>>         Stan
>>>         _______________________________________________
>>>         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
>>>         <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>>>
>>>
>>>
>>>
>>>     --
>>>     James R. Perkins
>>>     JBoss by Red Hat
>>
>>
>>     _______________________________________________
>>     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
>>     <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 rory.odonnell at oracle.com  Mon Aug  8 04:27:02 2016
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Mon, 8 Aug 2016 09:27:02 +0100
Subject: [wildfly-dev] Early Access builds of JDK 8u112 b04,
 JDK 9 b130 are available on java.net
Message-ID: <4128b9ed-48ee-a2e8-b3fe-b217ed35e224@oracle.com>


Hi Jason/Tomaz,


Early Access b130 <https://jdk9.java.net/download/> for JDK 9 is 
available on java.net, summary of  changes are listed here 
<http://download.java.net/java/jdk9/changes/jdk-9+130.html>.

Early Access b129 <https://jdk9.java.net/jigsaw/> (#5332) for JDK 9 with 
Project Jigsaw is available on java.net, summary of changes are listed 
here 
<http://download.java.net/java/jigsaw/archive/129/binaries/jdk-9+129.html>

Early Access b04 <https://jdk8.java.net/download.html> for JDK 8u112 is 
available on java.net, summary of  changes are listed here 
<http://download.java.net/java/jdk8u112/changes/jdk8u112-b04.html>


Rgds,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/20160808/c0ac2858/attachment.html 

From arjan.tijms at gmail.com  Mon Aug  8 09:11:11 2016
From: arjan.tijms at gmail.com (arjan tijms)
Date: Mon, 8 Aug 2016 15:11:11 +0200
Subject: [wildfly-dev] Set descriptor property replacement setting in
	jboss-web.xml?
Message-ID: <CAE=-AhDuP501-3utzcvWihgNGE9_C-BvsSpvtQ9q3+CtzXVW_w@mail.gmail.com>

Hi,

I wonder if it would make sense to be able to set the
"spec-descriptor-property-replacement" from standalone.xml in jboss-web.xml
(or other jboss specific files for e.g. a .ear)?

This is one of the few settings that we always need to change and it
prevents devs using a stock JBoss/WildFly to deploy most of our
applications to. Would be really great if this could be switched from
within the application archive.

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

From tomaz.cerar at gmail.com  Mon Aug  8 09:26:21 2016
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Mon, 8 Aug 2016 15:26:21 +0200
Subject: [wildfly-dev] Set descriptor property replacement setting in
	jboss-web.xml?
In-Reply-To: <CAE=-AhDuP501-3utzcvWihgNGE9_C-BvsSpvtQ9q3+CtzXVW_w@mail.gmail.com>
References: <CAE=-AhDuP501-3utzcvWihgNGE9_C-BvsSpvtQ9q3+CtzXVW_w@mail.gmail.com>
Message-ID: <CAMquZP7zSM=5BGubZO0qRYROdwDRtfJ43AxOR0UrYC6MjqWHig@mail.gmail.com>

That is more of an chicken and egg problem.

Descriptors such as jboss-web.xml / jboss-deployment-structure.xml /
jboss-all.xml /...
get parsed differently based on how spec-descriptor-property-replacment /
jboss-descriptor-property-replacement are configured.
So to enable that as part of such descriptor would kinda defy the whole
purpose of it.

what is your most common use case of what are you replacing in spec
descriptors?

--
tomaz

On Mon, Aug 8, 2016 at 3:11 PM, arjan tijms <arjan.tijms at gmail.com> wrote:

> Hi,
>
> I wonder if it would make sense to be able to set the
> "spec-descriptor-property-replacement" from standalone.xml in
> jboss-web.xml (or other jboss specific files for e.g. a .ear)?
>
> This is one of the few settings that we always need to change and it
> prevents devs using a stock JBoss/WildFly to deploy most of our
> applications to. Would be really great if this could be switched from
> within the application archive.
>
> Kind regards,
> Arjan Tijms
>
>
>
> _______________________________________________
> 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/20160808/9b6dcdcb/attachment.html 

From arjan.tijms at gmail.com  Mon Aug  8 09:49:11 2016
From: arjan.tijms at gmail.com (arjan tijms)
Date: Mon, 8 Aug 2016 15:49:11 +0200
Subject: [wildfly-dev] Set descriptor property replacement setting in
	jboss-web.xml?
In-Reply-To: <CAMquZP7zSM=5BGubZO0qRYROdwDRtfJ43AxOR0UrYC6MjqWHig@mail.gmail.com>
References: <CAE=-AhDuP501-3utzcvWihgNGE9_C-BvsSpvtQ9q3+CtzXVW_w@mail.gmail.com>
	<CAMquZP7zSM=5BGubZO0qRYROdwDRtfJ43AxOR0UrYC6MjqWHig@mail.gmail.com>
Message-ID: <CAE=-AhAE-xhS7g+XYim55XD8yTdG4-5niXsdYUN7PQi=Mr1toA@mail.gmail.com>

Hi,

I wouldn't expect in this case that jboss-web.xml /
jboss-deployment-structure.xml / jboss-all.xml /...  get parsed
differently, just the actual spec descriptors like web.xml, persistence.xml
etc.

The most common use case for this is a couple of context-params in web.xml,
e.g.

<context-param>
   <param-name>javax.faces.FACELETS_REFRESH_PERIOD</param-name>
   <param-value>${facelets.refresh:-1}</param-value>
</context-param>

<context-param>
   <param-name>javax.faces.PROJECT_STAGE</param-name>
   <param-value>${project.stage:Production}</param-value>
</context-param>

And a couple of properties in persistence.xml, e.g.

<property name="hibernate.show_sql" value="${hibernate.show.sql:false}" />
<property name="hibernate.format_sql" value="${hibernate.format.sql:false}"
/>
<property name="hibernate.use_sql_comments"
value="${hibernate.comment.sql:true}" />

There are a few more things depending on the project, but this is what
nearly every one of them uses.

Kind regards,
Arjan Tijms




On Mon, Aug 8, 2016 at 3:26 PM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:

> That is more of an chicken and egg problem.
>
> Descriptors such as jboss-web.xml / jboss-deployment-structure.xml /
> jboss-all.xml /...
> get parsed differently based on how spec-descriptor-property-replacment /
> jboss-descriptor-property-replacement are configured.
> So to enable that as part of such descriptor would kinda defy the whole
> purpose of it.
>
> what is your most common use case of what are you replacing in spec
> descriptors?
>
> --
> tomaz
>
> On Mon, Aug 8, 2016 at 3:11 PM, arjan tijms <arjan.tijms at gmail.com> wrote:
>
>> Hi,
>>
>> I wonder if it would make sense to be able to set the
>> "spec-descriptor-property-replacement" from standalone.xml in
>> jboss-web.xml (or other jboss specific files for e.g. a .ear)?
>>
>> This is one of the few settings that we always need to change and it
>> prevents devs using a stock JBoss/WildFly to deploy most of our
>> applications to. Would be really great if this could be switched from
>> within the application archive.
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>> _______________________________________________
>> 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/20160808/6ac21469/attachment-0001.html 

From stuart.w.douglas at gmail.com  Mon Aug  8 18:41:19 2016
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Tue, 9 Aug 2016 08:41:19 +1000
Subject: [wildfly-dev] Set descriptor property replacement setting in
	jboss-web.xml?
In-Reply-To: <CAE=-AhDuP501-3utzcvWihgNGE9_C-BvsSpvtQ9q3+CtzXVW_w@mail.gmail.com>
References: <CAE=-AhDuP501-3utzcvWihgNGE9_C-BvsSpvtQ9q3+CtzXVW_w@mail.gmail.com>
Message-ID: <CAAoo=c7SBbP4oczqjewUMxcwS2cKV24-=kHHcKCM+NzuXPtH8w@mail.gmail.com>

Adding it to jboss-web.xml would not really work, however this could
probably be made to work as an attribute (or two attributes) on the root
element of jboss-all.xml.

Otherwise it would probably have to be some kind of separate file, as the
current code base expects this to be known before any descriptors are
actually parsed.

Stuart

On Mon, Aug 8, 2016 at 11:11 PM, arjan tijms <arjan.tijms at gmail.com> wrote:

> Hi,
>
> I wonder if it would make sense to be able to set the
> "spec-descriptor-property-replacement" from standalone.xml in
> jboss-web.xml (or other jboss specific files for e.g. a .ear)?
>
> This is one of the few settings that we always need to change and it
> prevents devs using a stock JBoss/WildFly to deploy most of our
> applications to. Would be really great if this could be switched from
> within the application archive.
>
> Kind regards,
> Arjan Tijms
>
>
>
> _______________________________________________
> 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/20160809/bfc5994b/attachment.html 

From tcrawley at redhat.com  Tue Aug  9 16:13:05 2016
From: tcrawley at redhat.com (Toby Crawley)
Date: Tue, 9 Aug 2016 16:13:05 -0400
Subject: [wildfly-dev] Pretty-printing XML validation errors
In-Reply-To: <CADHijTSoUQ7Vy5jUDJbgLu0ooNqLX0WncoWF_xZrG+or1Zg+=g@mail.gmail.com>
References: <CADHijTRSvduUikNTr90RM0=+BfFDvn-DXOChAWF-+wLQWUxAAg@mail.gmail.com>
	<175112BC-84C9-4A61-802F-A5978729D96F@redhat.com>
	<CADHijTQvRxysqwRgpDZkMi82PgNVZu6X0iVZ6yu8X76HUKAVAg@mail.gmail.com>
	<F551CB68-1E99-4547-B5B9-22F86FA19367@redhat.com>
	<CADHijTSoUQ7Vy5jUDJbgLu0ooNqLX0WncoWF_xZrG+or1Zg+=g@mail.gmail.com>
Message-ID: <CADHijTTE69q2F7tLfRy0iGEaVE2WiaApxaH6FTL6UqQRv_ciYg@mail.gmail.com>

I've done some more work on VDX, and have addressed most of the
technical concerns about it from this thread, namely:

* I18N - VDX is now i18n ready, but currently just has a default
  message set in english.
* Displaying the default message with code - the original message is
  now displayed as part of the output, see
  https://gist.github.com/tobias/ec2846a13b6ff656d8e47cbc85071cb1 for
  an example.
* Handling errors that aren't created by ParseUtils - For any
  XMLStreamExceptions that don't get wrapped by ParseUtils, VDX now
  shows that error the best it can. This still doesn't handle errors
  that aren't XMLStreamExceptions, but is progress. This should also
  handle errors thrown from AttributeDefinitions, since they are
  XMLStreamExceptions.
https://gist.github.com/tobias/551e712892b9326096ecc80bb78bc132
  is an example of handling a non-wrapped exception thrown by the
  reader.
* Size of dependencies - VDX now has no dependencies, and is currently
  61K. Removing the dependencies on Apache XMLSchema and Apache
  Commons Lang reduces the total size by 552K.

Existing issues:

* I18N - though it is set up for i18n, it doesn't yet have any
  translations. How many/what languages do we support for WildFly
  currently? What is the process for getting translations done?
* non-XMLStreamException errors - it's currently possible to trigger
  errors that aren't XMLStreamExceptions when parsing
  standalone.xml. A couple of examples are:

  - adding a duplicate extension under server > extensions causes an
    IllegalStateException that occurs when trying to generate the
    XMLStreamException
    (https://gist.github.com/tobias/59d155afe0c88e268b83cb75734353eb)
  - Creating a file-handler with no attributes under server >
    management > audit-log > handlers results in an error about there
    being no add operation at address [], with no other context
    (https://gist.github.com/tobias/34b7d7791e20148004d883238adf16ac). If
    you add a name attribute, you get a different, more helpful
    management operation error
    (https://gist.github.com/tobias/6d47539aa40de90ec45cfaaec83ea15e),
    but neither error points to the xml configuration as the problem.

  Nothing can really be done with VDX to help with these issues, but I
  would be happy to provide PR's to fix them as I find them if there
  is interest.

The question now is - should I keep working on this? Is there enough
interest in this for me to continue it to the point where it can be
used by wildfly-core?

Is there interest in seeing this applied to xml that is provided as
part of a deployment (web.xml, jboss-web.xml,
jboss-deployment-structure.xml, etc) in addition to (or instead of
standalone.xml)? I haven't yet looked at what that would take.

For reference, the source for VDX is available at
https://github.com/projectodd/vdx, and my changes so far to
wildfly-core are in this commit:
https://github.com/tobias/wildfly-core/commit/2654406bfcfed7cbf255db819f094749487e2d10

- Toby

On Tue, Jul 19, 2016 at 7:28 PM, Toby Crawley <tcrawley at redhat.com> wrote:
> On Tue, Jul 19, 2016 at 4:07 PM, Brian Stansberry
> <brian.stansberry at redhat.com> wrote:
>> Comments in-line, except for something I just thought of.
>>
>> All exception and log messages produced will likely need to follow
>> WildFly?s/EAP's i18n standards. Message prefixed with a code, text produced
>> in a way in an i18n manner with a reasonable way to get localized text into
>> the software.
>
> Ah, good point. It shouldn't be difficult to add localized text to the
> output, the biggest cost there would be the time to translate the
> messages, but I'm not familiar with how i18n is done in our projects.
> For the message code, we could print the original exception message at
> the bottom or top of the validation block. That would then use the
> same code as we provide now, and would provide the same message we use
> now with every error. Would that satisfy the message code requirement?
>
>>>
>>> On Jul 19, 2016, at 2:38 PM, Toby Crawley <tcrawley at redhat.com> wrote:
>>>
>>>> On Tue, Jul 19, 2016 at 3:15 PM, Brian Stansberry
>>>> <brian.stansberry at redhat.com> wrote:
>>>>
>>>> The only big concern I have about this is that we?ll get this behavior for
>>>> some failures but not all. And I don?t want to go down the path of trying to
>>>> force every parser to work in a manner such that we consistently get this.
>>>>
>>>
>>> I haven't looked at it too deeply, but it may be straightforward to
>>> alter staxmapper to allow providing an exception generator that would
>>> allow catching more of the cases that the parsers miss.
>>>
>>
>> I?m not sure how big of a problem staxmapper-thrown exceptions are. (I
>> haven?t really thought.)
>
> That's just the first place I saw errors from outside of ParseUtils,
> but I haven't yet started playing with attribute values.
>
>>
>> What I was thinking more about when I wrote my previous post was parsers not
>> using ParseUtils, or sometimes not using it.
>>
>> Also, a lot of XmlStreamException cases are generated from implementations
>> of org.jboss.as.controller.AttributeDefinition, e.g.
>>
>> https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/java/org/jboss/as/controller/SimpleAttributeDefinition.java#L140
>>
>> Parsers are encouraged to invoke methods on AttributeDefinition to validate
>> attribute values. Perhaps though those are better left alone, as the
>> validators are meant to produce useful exception messages.
>>
>
> If we let these fall back to just pointing out the error location with
> the original message, this may be ok (assuming by "the alidators are
> meant to produce useful exception messages" you mean the messages
> produced by the AttributeDefinitions).
>
> <snip>
>
>>>> A minor concern is how big the added dependencies are. (I don?t know.) We
>>>> want to keep WildFly Core small in footprint.
>>>>
>>>
>>> Right now, the only dependencies vdx (31k) has are commons-lang (which
>>> is already a module in WildFly, but not core-feature-pack),
>>> xmlschema-walker (100k), and xmlschema-core (168k). For the rest of
>>> the work, I don't currently see needing any more dependencies.
>>>
>>
>> Thanks. So about 583K including 284K for commons-lang. The current
>> wildly-core-dist-3.0.0.Alpha3.zip is about 16.9MB, so this is fairly
>> substantial.
>>
>
> I'm only using commons-lang for a Levenshtein distance implementation
> - that could certainly be pulled in, and we could drop the 284k for
> commons-lang. It certainly would be nice to keep core under 17MB
> though.
>
> - Toby


From dennis at gesker.com  Thu Aug 11 16:35:23 2016
From: dennis at gesker.com (Dennis Gesker)
Date: Thu, 11 Aug 2016 14:35:23 -0600
Subject: [wildfly-dev] Monitor
Message-ID: <CAJRXDBMRaYZZx+x20+GWomDy2WLYr_x5LXMDuax5k6yqJ=bcSQ@mail.gmail.com>

Hello Wildfly-Dev:

On my server I use a nice little utility called pgbadger that is triggered
in my crontab to send me reports each morning on how my postgresql database
has been performing; essentially log analysis.

Is there a similar or generally recommended utility for WildFly? A command
I can add a few switches to to send me reports on how WildFly has been
behaving?

Just curious.

Also, I joined a list called jboss-user but don't see much activity. Has
this list discontinued or been supplanted by another?

Cordially,
Dennis


-- 
[image: LinkedIn] <https://www.linkedin.com/in/gesker>
<https://www.facebook.com/gesker>[image: Wordpress]
<https://gesker.wordpress.com/>[image: Facebook][image: Twitter]
<https://twitter.com/gesker> <https://gesker.wordpress.com/>
<http://www.gesker.com> <https://google.com/+DennisGesker>[image: Family
Home Page][image: Public Encryption Key]
<https://pgp.mit.edu/pks/lookup?search=dennis%40gesker.com&op=index>[image:
dennis at gesker.com] <dennis at gesker.com>
?Be without fear in the face of your enemies. Be brave and upright that God
may love thee. Speak the truth always, even if it leads to your death.
Safeguard the helpless and do no wrong ? that is your oath.?* -The Knight?s
Oath (Kingdom of Heaven)*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160811/d725bb4a/attachment.html 

From claudio at claudius.com.br  Thu Aug 11 17:45:19 2016
From: claudio at claudius.com.br (Claudio Miranda)
Date: Thu, 11 Aug 2016 18:45:19 -0300
Subject: [wildfly-dev] Monitor
In-Reply-To: <CAJRXDBMRaYZZx+x20+GWomDy2WLYr_x5LXMDuax5k6yqJ=bcSQ@mail.gmail.com>
References: <CAJRXDBMRaYZZx+x20+GWomDy2WLYr_x5LXMDuax5k6yqJ=bcSQ@mail.gmail.com>
Message-ID: <CALbD--qq4z-p=rHEkU21yb4rKxZz43yDE08CmFhVBej=AaRv+w@mail.gmail.com>

On Thu, Aug 11, 2016 at 5:35 PM, Dennis Gesker <dennis at gesker.com> wrote:
>
> Is there a similar or generally recommended utility for WildFly? A command I can add a few switches to to send me reports on how WildFly has been behaving?

There is $WILDFLY_HOME/jboss-cli.sh where you can issue commands to
manage and monitor wildfly resources

https://docs.jboss.org/author/display/WFLY/CLI+Recipes

To retrieve statistics values for subsystem, you must enable it first.
For example, to retrieve statistics for datasources
/subsystem=datasources/data-source=ExampleDS/statistics=pool:read-resource(include-runtime=true)

Memory usage
/core-service=platform-mbean/type=memory:read-resource(include-runtime=true,recursive=true)


-- 
  Claudio Miranda

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

From mazz at redhat.com  Thu Aug 11 19:33:18 2016
From: mazz at redhat.com (John Mazzitelli)
Date: Thu, 11 Aug 2016 19:33:18 -0400 (EDT)
Subject: [wildfly-dev] Monitor
In-Reply-To: <CALbD--qq4z-p=rHEkU21yb4rKxZz43yDE08CmFhVBej=AaRv+w@mail.gmail.com>
References: <CAJRXDBMRaYZZx+x20+GWomDy2WLYr_x5LXMDuax5k6yqJ=bcSQ@mail.gmail.com>
	<CALbD--qq4z-p=rHEkU21yb4rKxZz43yDE08CmFhVBej=AaRv+w@mail.gmail.com>
Message-ID: <474687890.1953891.1470958398351.JavaMail.zimbra@redhat.com>

----- Original Message -----
> On Thu, Aug 11, 2016 at 5:35 PM, Dennis Gesker <dennis at gesker.com> wrote:
> >
> > Is there a similar or generally recommended utility for WildFly? A command
> > I can add a few switches to to send me reports on how WildFly has been
> > behaving?
> 
> There is $WILDFLY_HOME/jboss-cli.sh where you can issue commands to
> manage and monitor wildfly resources


Currently under development is also the Hawkular WildFly Agent [1] - a subsystem you can install in a WildFly server and configure it to collect any number of statistics and store them in Hawkular-Metrics (our new metric database, currently in production in OpenShift and soon to be part of the new middleware management stuff). This is all under the umbrella of the Hawkular project [2].

[1] https://github.com/hawkular/hawkular-agent
[2] http://www.hawkular.org

From anmiller at redhat.com  Fri Aug 12 11:44:42 2016
From: anmiller at redhat.com (Andrig Miller)
Date: Fri, 12 Aug 2016 09:44:42 -0600
Subject: [wildfly-dev] Monitor
In-Reply-To: <474687890.1953891.1470958398351.JavaMail.zimbra@redhat.com>
References: <CAJRXDBMRaYZZx+x20+GWomDy2WLYr_x5LXMDuax5k6yqJ=bcSQ@mail.gmail.com>
	<CALbD--qq4z-p=rHEkU21yb4rKxZz43yDE08CmFhVBej=AaRv+w@mail.gmail.com>
	<474687890.1953891.1470958398351.JavaMail.zimbra@redhat.com>
Message-ID: <CAF1-sp6d1oVMSCv4Pzks-iEKi9St=PAGEj1J=TDzYJxEWFcdsg@mail.gmail.com>

Keep in mind that there is a performance penalty you pay for turning on
runtime statistics, so be careful about what you turn on, and make sure you
are still getting or meeting your performance needs.

Andy

On Thu, Aug 11, 2016 at 5:33 PM, John Mazzitelli <mazz at redhat.com> wrote:

> ----- Original Message -----
> > On Thu, Aug 11, 2016 at 5:35 PM, Dennis Gesker <dennis at gesker.com>
> wrote:
> > >
> > > Is there a similar or generally recommended utility for WildFly? A
> command
> > > I can add a few switches to to send me reports on how WildFly has been
> > > behaving?
> >
> > There is $WILDFLY_HOME/jboss-cli.sh where you can issue commands to
> > manage and monitor wildfly resources
>
>
> Currently under development is also the Hawkular WildFly Agent [1] - a
> subsystem you can install in a WildFly server and configure it to collect
> any number of statistics and store them in Hawkular-Metrics (our new metric
> database, currently in production in OpenShift and soon to be part of the
> new middleware management stuff). This is all under the umbrella of the
> Hawkular project [2].
>
> [1] https://github.com/hawkular/hawkular-agent
> [2] http://www.hawkular.org
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>



-- 
Andrig (Andy) T. Miller
Global Platform Director, Middleware
Red Hat, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160812/8dbdaee4/attachment-0001.html 

From brian.stansberry at redhat.com  Mon Aug 15 20:08:18 2016
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 15 Aug 2016 19:08:18 -0500
Subject: [wildfly-dev] Pretty-printing XML validation errors
In-Reply-To: <CADHijTTE69q2F7tLfRy0iGEaVE2WiaApxaH6FTL6UqQRv_ciYg@mail.gmail.com>
References: <CADHijTRSvduUikNTr90RM0=+BfFDvn-DXOChAWF-+wLQWUxAAg@mail.gmail.com>
	<175112BC-84C9-4A61-802F-A5978729D96F@redhat.com>
	<CADHijTQvRxysqwRgpDZkMi82PgNVZu6X0iVZ6yu8X76HUKAVAg@mail.gmail.com>
	<F551CB68-1E99-4547-B5B9-22F86FA19367@redhat.com>
	<CADHijTSoUQ7Vy5jUDJbgLu0ooNqLX0WncoWF_xZrG+or1Zg+=g@mail.gmail.com>
	<CADHijTTE69q2F7tLfRy0iGEaVE2WiaApxaH6FTL6UqQRv_ciYg@mail.gmail.com>
Message-ID: <BC3BCAC3-3774-4F59-9D7D-9E946650F441@redhat.com>

Hi Toby,

Sorry for the delay. People I wanted to talk to have been traveling and on vacation etc.

I?ll reply in-line. Bottom line is it looks like you?ve made good progress and this seems worth pursuing. Thanks for digging into it!

> On Aug 9, 2016, at 3:13 PM, Toby Crawley <tcrawley at redhat.com> wrote:
> 
> I've done some more work on VDX, and have addressed most of the
> technical concerns about it from this thread, namely:
> 
> * I18N - VDX is now i18n ready, but currently just has a default
>  message set in english.
> * Displaying the default message with code - the original message is
>  now displayed as part of the output, see
>  https://gist.github.com/tobias/ec2846a13b6ff656d8e47cbc85071cb1 for
>  an example.
> * Handling errors that aren't created by ParseUtils - For any
>  XMLStreamExceptions that don't get wrapped by ParseUtils, VDX now
>  shows that error the best it can. This still doesn't handle errors
>  that aren't XMLStreamExceptions, but is progress. This should also
>  handle errors thrown from AttributeDefinitions, since they are
>  XMLStreamExceptions.

What does the failure message look like when AttributeDefinition rejects an attribute? I want to make sure this is helping, not obscuring.

A simple test would be to change the ?port? attribute in a socket-binding element to -1.

> https://gist.github.com/tobias/551e712892b9326096ecc80bb78bc132
>  is an example of handling a non-wrapped exception thrown by the
>  reader.
> * Size of dependencies - VDX now has no dependencies, and is currently
>  61K. Removing the dependencies on Apache XMLSchema and Apache
>  Commons Lang reduces the total size by 552K.
> 

Great!

> Existing issues:
> 
> * I18N - though it is set up for i18n, it doesn't yet have any
>  translations. How many/what languages do we support for WildFly
>  currently? What is the process for getting translations done?

For WildFly itself, English is fine. But for things that end up in EAP (which this would) we need the ability for the Red Hat localization team to do translations and get the properties files into VDX source. We do this via a tool called Zanata, available at https://translate.jboss.org, with integration via a maven plugin. We can help you get this set up once things are near done. The biggest thing is that your code is i18n which means it can be done.

> * non-XMLStreamException errors - it's currently possible to trigger
>  errors that aren't XMLStreamExceptions when parsing
>  standalone.xml. A couple of examples are:
> 
>  - adding a duplicate extension under server > extensions causes an
>    IllegalStateException that occurs when trying to generate the
>    XMLStreamException
>    (https://gist.github.com/tobias/59d155afe0c88e268b83cb75734353eb)

This one looks to be the parser author (aka me) being lazy and incorrectly using a util method instead of throwing a more custom exception.

I filed https://issues.jboss.org/browse/WFCORE-1717 for this and listed you as the reporter. Thanks!

>  - Creating a file-handler with no attributes under server >
>    management > audit-log > handlers results in an error about there
>    being no add operation at address [], with no other context
>    (https://gist.github.com/tobias/34b7d7791e20148004d883238adf16ac). If
>    you add a name attribute, you get a different, more helpful
>    management operation error
>    (https://gist.github.com/tobias/6d47539aa40de90ec45cfaaec83ea15e),
>    but neither error points to the xml configuration as the problem.
> 

This sounds like the parser not doing validation that it could, and deferring to the management op handling.

>  Nothing can really be done with VDX to help with these issues, but I
>  would be happy to provide PR's to fix them as I find them if there
>  is interest.
> 

Parser improvements are welcome. Somewhat. ;) This gets back a bit to something I said in my first post in this thread:

"Personally I think it?s ok to have this for only some failures. Others may disagree though and start filing bug reports, leading to demands that we fix said ?bugs?, leading to a shift of resource away from other tasks.?

So if we get some simple, no risk patches, great, thank you! I just don?t want to start having people insist that we beef up the level of validation in our parsers so we can get pretty reports. But then not contributing the parser improvements.

WFCORE-1717 is different; there the parser is just wrong.

> The question now is - should I keep working on this? Is there enough
> interest in this for me to continue it to the point where it can be
> used by wildfly-core?
> 
> Is there interest in seeing this applied to xml that is provided as
> part of a deployment (web.xml, jboss-web.xml,
> jboss-deployment-structure.xml, etc) in addition to (or instead of
> standalone.xml)? I haven't yet looked at what that would take.
> 
> For reference, the source for VDX is available at
> https://github.com/projectodd/vdx, and my changes so far to
> wildfly-core are in this commit:
> https://github.com/tobias/wildfly-core/commit/2654406bfcfed7cbf255db819f094749487e2d10
> 
> - Toby
> 
> On Tue, Jul 19, 2016 at 7:28 PM, Toby Crawley <tcrawley at redhat.com> wrote:
>> On Tue, Jul 19, 2016 at 4:07 PM, Brian Stansberry
>> <brian.stansberry at redhat.com> wrote:
>>> Comments in-line, except for something I just thought of.
>>> 
>>> All exception and log messages produced will likely need to follow
>>> WildFly?s/EAP's i18n standards. Message prefixed with a code, text produced
>>> in a way in an i18n manner with a reasonable way to get localized text into
>>> the software.
>> 
>> Ah, good point. It shouldn't be difficult to add localized text to the
>> output, the biggest cost there would be the time to translate the
>> messages, but I'm not familiar with how i18n is done in our projects.
>> For the message code, we could print the original exception message at
>> the bottom or top of the validation block. That would then use the
>> same code as we provide now, and would provide the same message we use
>> now with every error. Would that satisfy the message code requirement?
>> 
>>>> 
>>>> On Jul 19, 2016, at 2:38 PM, Toby Crawley <tcrawley at redhat.com> wrote:
>>>> 
>>>>> On Tue, Jul 19, 2016 at 3:15 PM, Brian Stansberry
>>>>> <brian.stansberry at redhat.com> wrote:
>>>>> 
>>>>> The only big concern I have about this is that we?ll get this behavior for
>>>>> some failures but not all. And I don?t want to go down the path of trying to
>>>>> force every parser to work in a manner such that we consistently get this.
>>>>> 
>>>> 
>>>> I haven't looked at it too deeply, but it may be straightforward to
>>>> alter staxmapper to allow providing an exception generator that would
>>>> allow catching more of the cases that the parsers miss.
>>>> 
>>> 
>>> I?m not sure how big of a problem staxmapper-thrown exceptions are. (I
>>> haven?t really thought.)
>> 
>> That's just the first place I saw errors from outside of ParseUtils,
>> but I haven't yet started playing with attribute values.
>> 
>>> 
>>> What I was thinking more about when I wrote my previous post was parsers not
>>> using ParseUtils, or sometimes not using it.
>>> 
>>> Also, a lot of XmlStreamException cases are generated from implementations
>>> of org.jboss.as.controller.AttributeDefinition, e.g.
>>> 
>>> https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/java/org/jboss/as/controller/SimpleAttributeDefinition.java#L140
>>> 
>>> Parsers are encouraged to invoke methods on AttributeDefinition to validate
>>> attribute values. Perhaps though those are better left alone, as the
>>> validators are meant to produce useful exception messages.
>>> 
>> 
>> If we let these fall back to just pointing out the error location with
>> the original message, this may be ok (assuming by "the alidators are
>> meant to produce useful exception messages" you mean the messages
>> produced by the AttributeDefinitions).
>> 
>> <snip>
>> 
>>>>> A minor concern is how big the added dependencies are. (I don?t know.) We
>>>>> want to keep WildFly Core small in footprint.
>>>>> 
>>>> 
>>>> Right now, the only dependencies vdx (31k) has are commons-lang (which
>>>> is already a module in WildFly, but not core-feature-pack),
>>>> xmlschema-walker (100k), and xmlschema-core (168k). For the rest of
>>>> the work, I don't currently see needing any more dependencies.
>>>> 
>>> 
>>> Thanks. So about 583K including 284K for commons-lang. The current
>>> wildly-core-dist-3.0.0.Alpha3.zip is about 16.9MB, so this is fairly
>>> substantial.
>>> 
>> 
>> I'm only using commons-lang for a Levenshtein distance implementation
>> - that could certainly be pulled in, and we could drop the 284k for
>> commons-lang. It certainly would be nice to keep core under 17MB
>> though.
>> 
>> - Toby

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





From jan-willem at youngmediaexperts.nl  Tue Aug 16 03:55:59 2016
From: jan-willem at youngmediaexperts.nl (Jan-Willem Gmelig Meyling)
Date: Tue, 16 Aug 2016 09:55:59 +0200
Subject: [wildfly-dev] Wildfly JAAS HttpServletRequest.login does not keep
 logged in for subsequent requests
Message-ID: <62C1F940-149E-49AC-B18E-744E6C40F6DA@youngmediaexperts.nl>

Hi everyone,

I encountered some problems when trying to use the Servlet 3.0 login method in Wildfly 10.  After logging in using `HttpServletRequest.login(String, String)`, using the code below, on successive requests I still get a Basic Authentication prompt.

I have also found the same issue on the JBoss developer forum in a post that goes back to september 2015: developer.jboss.org/thread/262640?start=0&tstart=0 <http://developer.jboss.org/thread/262640?start=0&tstart=0> . 

Why is the `login` function not working in my configuration?


My endpoint:


    @POST
    @Path("login")
    @Consumes(MediaType.APPLICATION_JSON)
    public void login(@Valid LoginRequest loginRequest) {
        try {
            User user = userController.findUserByUsername(loginRequest.getUsername()).orElseThrow(NotFoundException::new);
            httpServletRequest.login(loginRequest.getUsername(), loginRequest.getPassword());
            log.info(securityContext); // not null now!
        }
        catch (ServletException e) {
            throw new NotAuthorizedException(e.getMessage(), e, AuthenticationHeaderFilter.CHALLENGE);
        }
    }


And my `jboss-web.xml`

      <?xml version="1.0" encoding="UTF-8"?>
      <jboss-web xmlns="http://www.jboss.com/xml/ns/javaee"
                 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                 xsi:schemaLocation="
            http://www.jboss.com/xml/ns/javaee
            http://www.jboss.org/j2ee/schema/jboss-web_5_1.xsd">
        <security-domain>MyRealm</security-domain>
      </jboss-web>

And my `web.xml`:

    <login-config>
        <auth-method>BASIC</auth-method>
        <realm-name>MyRealm</realm-name>
    </login-config>

    <security-role>
        <role-name>admin</role-name>
    </security-role>

    <security-role>
        <role-name>user</role-name>
    </security-role>

    <security-constraint>
        <display-name>Authenticated content</display-name>
        <web-resource-collection>
            <web-resource-name>Authentication required</web-resource-name>
            <url-pattern>/api/*</url-pattern>
        </web-resource-collection>
        <auth-constraint>
            <role-name>user</role-name>
        </auth-constraint>
    </security-constraint>

    <security-constraint>
        <display-name>Anonymous content</display-name>
        <web-resource-collection>
            <web-resource-name>Exclude from Security</web-resource-name>
            <url-pattern>/api/me/login</url-pattern>
        </web-resource-collection>
    </security-constraint>


Furthermore, I declared my security domain as follows in standalone.xml

                <security-domain name="MyRealm" cache-type="default">
                    <authentication>
                        <login-module code="Database" flag="required">
                            <module-option name="dsJndiName" value="java:jboss/MysqlXADS"/>
                            <module-option name="principalsQuery" value="SELECT password AS Password FROM user WHERE username = ?"/>
                            <module-option name="rolesQuery" value="select 'user' as Role, 'Roles' as RoleGroup union select 'admin' as Role, 'Roles' AS RoleGroup from user where admin is true and username = ?"/>
                        </login-module>
                    </authentication>
                </security-domain>


I have also posted the question on Stackoverflow, so any answer posted there will receive the bounty points: http://stackoverflow.com/questions/38896538/httpservletrequest-login-does-not-keep-logged-in-for-subsequent-requests <http://stackoverflow.com/questions/38896538/httpservletrequest-login-does-not-keep-logged-in-for-subsequent-requests>

Thanks in advance!

Jan-Willem Gmelig Meyling




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

From arjan.tijms at gmail.com  Tue Aug 16 07:12:22 2016
From: arjan.tijms at gmail.com (arjan tijms)
Date: Tue, 16 Aug 2016 13:12:22 +0200
Subject: [wildfly-dev] ConcurrentAccessTimeoutException using producer in
	stateful bean
Message-ID: <CAE=-AhCXd3zyJ3yuwNfwd3tL1WY3WiJb+5K977ktZ=G8OvqVCA@mail.gmail.com>

Hi,

I came across a situation where a ConcurrentAccessTimeoutException is
thrown on WildFly 10.0.0 and 10.1cr1 when an @Stateful @ViewScoped bean
contains a CDI producer.

In short, there are 3 beans all @Stateful @ViewScoped. Beans 1 and 2 are
injected in bean 3.

Bean 1 contains a CDI producer.
Bean 2 is injected with a type from said producer.

The following causes a ConcurrentAccessTimeoutException to be thrown:

bean3.somemethod:
    tx start
    access stateful bean 1
    access stateful bean 2
(from statefull bean 2): access injected type that causes producer from
bean 1 to be called
    tx end

If the call to stateful bean 1 is omitted, the producer is called normally
when bean 2 accesses the injected type.

If bean 2 is injected directly with bean 1, then bean 1 can be accessed
without any ConcurrentAccessTimeoutException being thrown.

The code runs fine on WildFly 8.2.

I'll do some further digging, but wonder if this problem rings any bells.
Could it be that CDI obtains a reference to the stateful bean in such a way
that the implicit EJB interceptor doesn't see it's still within the same
TX? But since there's no call to bean 1 in progress at that point, should
this even matter?

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

From tremes at redhat.com  Tue Aug 16 07:26:01 2016
From: tremes at redhat.com (Tomas Remes)
Date: Tue, 16 Aug 2016 07:26:01 -0400 (EDT)
Subject: [wildfly-dev] ConcurrentAccessTimeoutException using producer
 in	stateful bean
In-Reply-To: <CAE=-AhCXd3zyJ3yuwNfwd3tL1WY3WiJb+5K977ktZ=G8OvqVCA@mail.gmail.com>
References: <CAE=-AhCXd3zyJ3yuwNfwd3tL1WY3WiJb+5K977ktZ=G8OvqVCA@mail.gmail.com>
Message-ID: <598186956.3174167.1471346761474.JavaMail.zimbra@redhat.com>


Hi Arjan,

Can you please share some reproducer app? It would be helpful.

Thanks
Tom

----- Original Message -----
From: "arjan tijms" <arjan.tijms at gmail.com>
To: "WildFly Dev" <wildfly-dev at lists.jboss.org>
Sent: Tuesday, August 16, 2016 1:12:22 PM
Subject: [wildfly-dev] ConcurrentAccessTimeoutException using producer in	stateful bean

Hi, 

I came across a situation where a ConcurrentAccessTimeoutException is thrown on WildFly 10.0.0 and 10.1cr1 when an @Stateful @ViewScoped bean contains a CDI producer. 

In short, there are 3 beans all @Stateful @ViewScoped. Beans 1 and 2 are injected in bean 3. 

Bean 1 contains a CDI producer. 
Bean 2 is injected with a type from said producer. 

The following causes a ConcurrentAccessTimeoutException to be thrown: 

bean3.somemethod: 
tx start 
access stateful bean 1 
access stateful bean 2 
(from statefull bean 2): access injected type that causes producer from bean 1 to be called 
tx end 

If the call to stateful bean 1 is omitted, the producer is called normally when bean 2 accesses the injected type. 

If bean 2 is injected directly with bean 1, then bean 1 can be accessed without any ConcurrentAccessTimeoutException being thrown. 

The code runs fine on WildFly 8.2. 

I'll do some further digging, but wonder if this problem rings any bells. Could it be that CDI obtains a reference to the stateful bean in such a way that the implicit EJB interceptor doesn't see it's still within the same TX? But since there's no call to bean 1 in progress at that point, should this even matter? 

Kind regards, 
Arjan Tijms 

_______________________________________________
wildfly-dev mailing list
wildfly-dev at lists.jboss.org




From arjan.tijms at gmail.com  Tue Aug 16 07:47:56 2016
From: arjan.tijms at gmail.com (arjan tijms)
Date: Tue, 16 Aug 2016 13:47:56 +0200
Subject: [wildfly-dev] ConcurrentAccessTimeoutException using producer
 in stateful bean
In-Reply-To: <598186956.3174167.1471346761474.JavaMail.zimbra@redhat.com>
References: <CAE=-AhCXd3zyJ3yuwNfwd3tL1WY3WiJb+5K977ktZ=G8OvqVCA@mail.gmail.com>
	<598186956.3174167.1471346761474.JavaMail.zimbra@redhat.com>
Message-ID: <CAE=-AhDcAdsSVzEP40MEzB2Qi8EL-NnB6NN5KS3JGS0qudz6ww@mail.gmail.com>

Hi,

Sure, I've created one using the request scope now (to rule out any issues
with JSF's view scope).

package test;

import javax.ejb.Stateful;
import javax.enterprise.context.RequestScoped;
import javax.enterprise.inject.Produces;

@Stateful
@RequestScoped
public class Bean1 {
@Produces
public String produceString() {
return "a string";
}

public void foo() {
}
}



package test;

import javax.ejb.Stateful;
import javax.enterprise.context.RequestScoped;
import javax.inject.Inject;

@Stateful
@RequestScoped
public class Bean2 {

@Inject
private String string;
public void foo() {
}
}





package test;

import javax.ejb.Stateful;
import javax.enterprise.context.RequestScoped;
import javax.inject.Inject;

@Stateful
@RequestScoped
public class Bean3 {
@Inject
private Bean1 bean1;
@Inject
private Bean2 bean2;
public void test() {
bean1.foo();
bean2.foo();
}

}



package test;

import java.io.IOException;

import javax.inject.Inject;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

@WebServlet(urlPatterns = "/test")
public class TestServlet extends HttpServlet {

private static final long serialVersionUID = 1L;

@Inject
private Bean3 bean3;

@Override
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {

response.getWriter().write("testing");

bean3.test();

}

}

Relevant part of the stack trace:

Caused by: javax.ejb.ConcurrentAccessTimeoutException: WFLYEJB0228: EJB 3.1
FR 4.3.14.1 concurrent access timeout on Bean1 - could not obtain lock
within 5000 MILLISECONDS
at
org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:86)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
at
org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
at
org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at
org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
at
org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
at
org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
at
org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
at
org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
at
org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at
org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
at test.Bean1$$$view1.produceString(Unknown Source)


If needed I can later today put this in a Maven project as well, but the
above should be enough to get you started I hope.

Kind regards,
Arjan Tijms







On Tue, Aug 16, 2016 at 1:26 PM, Tomas Remes <tremes at redhat.com> wrote:

>
> Hi Arjan,
>
> Can you please share some reproducer app? It would be helpful.
>
> Thanks
> Tom
>
> ----- Original Message -----
> From: "arjan tijms" <arjan.tijms at gmail.com>
> To: "WildFly Dev" <wildfly-dev at lists.jboss.org>
> Sent: Tuesday, August 16, 2016 1:12:22 PM
> Subject: [wildfly-dev] ConcurrentAccessTimeoutException using producer
> in       stateful bean
>
> Hi,
>
> I came across a situation where a ConcurrentAccessTimeoutException is
> thrown on WildFly 10.0.0 and 10.1cr1 when an @Stateful @ViewScoped bean
> contains a CDI producer.
>
> In short, there are 3 beans all @Stateful @ViewScoped. Beans 1 and 2 are
> injected in bean 3.
>
> Bean 1 contains a CDI producer.
> Bean 2 is injected with a type from said producer.
>
> The following causes a ConcurrentAccessTimeoutException to be thrown:
>
> bean3.somemethod:
> tx start
> access stateful bean 1
> access stateful bean 2
> (from statefull bean 2): access injected type that causes producer from
> bean 1 to be called
> tx end
>
> If the call to stateful bean 1 is omitted, the producer is called normally
> when bean 2 accesses the injected type.
>
> If bean 2 is injected directly with bean 1, then bean 1 can be accessed
> without any ConcurrentAccessTimeoutException being thrown.
>
> The code runs fine on WildFly 8.2.
>
> I'll do some further digging, but wonder if this problem rings any bells.
> Could it be that CDI obtains a reference to the stateful bean in such a way
> that the implicit EJB interceptor doesn't see it's still within the same
> TX? But since there's no call to bean 1 in progress at that point, should
> this even matter?
>
> Kind regards,
> Arjan Tijms
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160816/8c32b950/attachment-0001.html 

From tremes at redhat.com  Tue Aug 16 09:04:04 2016
From: tremes at redhat.com (Tomas Remes)
Date: Tue, 16 Aug 2016 09:04:04 -0400 (EDT)
Subject: [wildfly-dev] ConcurrentAccessTimeoutException using producer
 in stateful bean
In-Reply-To: <CAE=-AhDcAdsSVzEP40MEzB2Qi8EL-NnB6NN5KS3JGS0qudz6ww@mail.gmail.com>
References: <CAE=-AhCXd3zyJ3yuwNfwd3tL1WY3WiJb+5K977ktZ=G8OvqVCA@mail.gmail.com>
	<598186956.3174167.1471346761474.JavaMail.zimbra@redhat.com>
	<CAE=-AhDcAdsSVzEP40MEzB2Qi8EL-NnB6NN5KS3JGS0qudz6ww@mail.gmail.com>
Message-ID: <1229274883.3195505.1471352644681.JavaMail.zimbra@redhat.com>


Thanks. I think it's a bug. I created https://issues.jboss.org/browse/WFLY-6960.

Tom

----- Original Message -----
From: "arjan tijms" <arjan.tijms at gmail.com>
To: "Tomas Remes" <tremes at redhat.com>
Cc: "WildFly Dev" <wildfly-dev at lists.jboss.org>
Sent: Tuesday, August 16, 2016 1:47:56 PM
Subject: Re: [wildfly-dev] ConcurrentAccessTimeoutException using producer in stateful bean

Hi,

Sure, I've created one using the request scope now (to rule out any issues
with JSF's view scope).

package test;

import javax.ejb.Stateful;
import javax.enterprise.context.RequestScoped;
import javax.enterprise.inject.Produces;

@Stateful
@RequestScoped
public class Bean1 {
@Produces
public String produceString() {
return "a string";
}

public void foo() {
}
}



package test;

import javax.ejb.Stateful;
import javax.enterprise.context.RequestScoped;
import javax.inject.Inject;

@Stateful
@RequestScoped
public class Bean2 {

@Inject
private String string;
public void foo() {
}
}





package test;

import javax.ejb.Stateful;
import javax.enterprise.context.RequestScoped;
import javax.inject.Inject;

@Stateful
@RequestScoped
public class Bean3 {
@Inject
private Bean1 bean1;
@Inject
private Bean2 bean2;
public void test() {
bean1.foo();
bean2.foo();
}

}



package test;

import java.io.IOException;

import javax.inject.Inject;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

@WebServlet(urlPatterns = "/test")
public class TestServlet extends HttpServlet {

private static final long serialVersionUID = 1L;

@Inject
private Bean3 bean3;

@Override
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {

response.getWriter().write("testing");

bean3.test();

}

}

Relevant part of the stack trace:

Caused by: javax.ejb.ConcurrentAccessTimeoutException: WFLYEJB0228: EJB 3.1
FR 4.3.14.1 concurrent access timeout on Bean1 - could not obtain lock
within 5000 MILLISECONDS
at
org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:86)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
at
org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
at
org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at
org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
at
org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
at
org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
at
org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
at
org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
at
org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at
org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
at test.Bean1$$$view1.produceString(Unknown Source)


If needed I can later today put this in a Maven project as well, but the
above should be enough to get you started I hope.

Kind regards,
Arjan Tijms







On Tue, Aug 16, 2016 at 1:26 PM, Tomas Remes <tremes at redhat.com> wrote:

>
> Hi Arjan,
>
> Can you please share some reproducer app? It would be helpful.
>
> Thanks
> Tom
>
> ----- Original Message -----
> From: "arjan tijms" <arjan.tijms at gmail.com>
> To: "WildFly Dev" <wildfly-dev at lists.jboss.org>
> Sent: Tuesday, August 16, 2016 1:12:22 PM
> Subject: [wildfly-dev] ConcurrentAccessTimeoutException using producer
> in       stateful bean
>
> Hi,
>
> I came across a situation where a ConcurrentAccessTimeoutException is
> thrown on WildFly 10.0.0 and 10.1cr1 when an @Stateful @ViewScoped bean
> contains a CDI producer.
>
> In short, there are 3 beans all @Stateful @ViewScoped. Beans 1 and 2 are
> injected in bean 3.
>
> Bean 1 contains a CDI producer.
> Bean 2 is injected with a type from said producer.
>
> The following causes a ConcurrentAccessTimeoutException to be thrown:
>
> bean3.somemethod:
> tx start
> access stateful bean 1
> access stateful bean 2
> (from statefull bean 2): access injected type that causes producer from
> bean 1 to be called
> tx end
>
> If the call to stateful bean 1 is omitted, the producer is called normally
> when bean 2 accesses the injected type.
>
> If bean 2 is injected directly with bean 1, then bean 1 can be accessed
> without any ConcurrentAccessTimeoutException being thrown.
>
> The code runs fine on WildFly 8.2.
>
> I'll do some further digging, but wonder if this problem rings any bells.
> Could it be that CDI obtains a reference to the stateful bean in such a way
> that the implicit EJB interceptor doesn't see it's still within the same
> TX? But since there's no call to bean 1 in progress at that point, should
> this even matter?
>
> Kind regards,
> Arjan Tijms
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
>
>
>
>



From arjan.tijms at gmail.com  Tue Aug 16 09:15:17 2016
From: arjan.tijms at gmail.com (arjan tijms)
Date: Tue, 16 Aug 2016 15:15:17 +0200
Subject: [wildfly-dev] ConcurrentAccessTimeoutException using producer
 in stateful bean
In-Reply-To: <1229274883.3195505.1471352644681.JavaMail.zimbra@redhat.com>
References: <CAE=-AhCXd3zyJ3yuwNfwd3tL1WY3WiJb+5K977ktZ=G8OvqVCA@mail.gmail.com>
	<598186956.3174167.1471346761474.JavaMail.zimbra@redhat.com>
	<CAE=-AhDcAdsSVzEP40MEzB2Qi8EL-NnB6NN5KS3JGS0qudz6ww@mail.gmail.com>
	<1229274883.3195505.1471352644681.JavaMail.zimbra@redhat.com>
Message-ID: <CAE=-AhBD5=sT0xiRvdDufXQKRqwyvuTYf4XU+5Ppt5yeYceMsA@mail.gmail.com>

Hi,

Great, thanks for the swift action. Let me know if any further help is
required.

Kind regards,
Arjan Tijms

On Tue, Aug 16, 2016 at 3:04 PM, Tomas Remes <tremes at redhat.com> wrote:

>
> Thanks. I think it's a bug. I created https://issues.jboss.org/
> browse/WFLY-6960.
>
> Tom
>
> ----- Original Message -----
> From: "arjan tijms" <arjan.tijms at gmail.com>
> To: "Tomas Remes" <tremes at redhat.com>
> Cc: "WildFly Dev" <wildfly-dev at lists.jboss.org>
> Sent: Tuesday, August 16, 2016 1:47:56 PM
> Subject: Re: [wildfly-dev] ConcurrentAccessTimeoutException using
> producer in stateful bean
>
> Hi,
>
> Sure, I've created one using the request scope now (to rule out any issues
> with JSF's view scope).
>
> package test;
>
> import javax.ejb.Stateful;
> import javax.enterprise.context.RequestScoped;
> import javax.enterprise.inject.Produces;
>
> @Stateful
> @RequestScoped
> public class Bean1 {
> @Produces
> public String produceString() {
> return "a string";
> }
>
> public void foo() {
> }
> }
>
>
>
> package test;
>
> import javax.ejb.Stateful;
> import javax.enterprise.context.RequestScoped;
> import javax.inject.Inject;
>
> @Stateful
> @RequestScoped
> public class Bean2 {
>
> @Inject
> private String string;
> public void foo() {
> }
> }
>
>
>
>
>
> package test;
>
> import javax.ejb.Stateful;
> import javax.enterprise.context.RequestScoped;
> import javax.inject.Inject;
>
> @Stateful
> @RequestScoped
> public class Bean3 {
> @Inject
> private Bean1 bean1;
> @Inject
> private Bean2 bean2;
> public void test() {
> bean1.foo();
> bean2.foo();
> }
>
> }
>
>
>
> package test;
>
> import java.io.IOException;
>
> import javax.inject.Inject;
> import javax.servlet.ServletException;
> import javax.servlet.annotation.WebServlet;
> import javax.servlet.http.HttpServlet;
> import javax.servlet.http.HttpServletRequest;
> import javax.servlet.http.HttpServletResponse;
>
> @WebServlet(urlPatterns = "/test")
> public class TestServlet extends HttpServlet {
>
> private static final long serialVersionUID = 1L;
>
> @Inject
> private Bean3 bean3;
>
> @Override
> public void doGet(HttpServletRequest request, HttpServletResponse response)
> throws ServletException, IOException {
>
> response.getWriter().write("testing");
>
> bean3.test();
>
> }
>
> }
>
> Relevant part of the stack trace:
>
> Caused by: javax.ejb.ConcurrentAccessTimeoutException: WFLYEJB0228: EJB
> 3.1
> FR 4.3.14.1 concurrent access timeout on Bean1 - could not obtain lock
> within 5000 MILLISECONDS
> at
> org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronization
> Interceptor.processInvocation(StatefulSessionSynchronization
> Interceptor.java:86)
> at
> org.jboss.invocation.InterceptorContext.proceed(
> InterceptorContext.java:340)
> at
> org.jboss.invocation.InterceptorContext$Invocation.
> proceed(InterceptorContext.java:437)
> at
> org.jboss.weld.ejb.AbstractEJBRequestScopeActivat
> ionInterceptor.aroundInvoke(AbstractEJBRequestScopeActivat
> ionInterceptor.java:64)
> at
> org.jboss.as.weld.ejb.EjbRequestScopeActivationInter
> ceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> at
> org.jboss.invocation.InterceptorContext.proceed(
> InterceptorContext.java:340)
> at
> org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(
> ConcurrentContextInterceptor.java:45)
> at
> org.jboss.invocation.InterceptorContext.proceed(
> InterceptorContext.java:340)
> at
> org.jboss.invocation.InitialInterceptor.processInvocation(
> InitialInterceptor.java:21)
> at
> org.jboss.invocation.InterceptorContext.proceed(
> InterceptorContext.java:340)
> at
> org.jboss.invocation.ChainedInterceptor.processInvocation(
> ChainedInterceptor.java:61)
> at
> org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor
> .processInvocation(ComponentDispatcherInterceptor.java:52)
> at
> org.jboss.invocation.InterceptorContext.proceed(
> InterceptorContext.java:340)
> at
> org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInter
> ceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65)
> at
> org.jboss.invocation.InterceptorContext.proceed(
> InterceptorContext.java:340)
> at
> org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(
> CMTTxInterceptor.java:275)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(
> CMTTxInterceptor.java:327)
> at
> org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(
> CMTTxInterceptor.java:239)
> at
> org.jboss.invocation.InterceptorContext.proceed(
> InterceptorContext.java:340)
> at
> org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterc
> eptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at
> org.jboss.invocation.InterceptorContext.proceed(
> InterceptorContext.java:340)
> at
> org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.
> processInvocation(WaitTimeInterceptor.java:43)
> at
> org.jboss.invocation.InterceptorContext.proceed(
> InterceptorContext.java:340)
> at
> org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(
> SecurityContextInterceptor.java:100)
> at
> org.jboss.invocation.InterceptorContext.proceed(
> InterceptorContext.java:340)
> at
> org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.
> processInvocation(ShutDownInterceptorFactory.java:64)
> at
> org.jboss.invocation.InterceptorContext.proceed(
> InterceptorContext.java:340)
> at
> org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.
> processInvocation(LoggingInterceptor.java:66)
> at
> org.jboss.invocation.InterceptorContext.proceed(
> InterceptorContext.java:340)
> at
> org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(
> NamespaceContextInterceptor.java:50)
> at
> org.jboss.invocation.InterceptorContext.proceed(
> InterceptorContext.java:340)
> at
> org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.
> processInvocation(AdditionalSetupInterceptor.java:54)
> at
> org.jboss.invocation.InterceptorContext.proceed(
> InterceptorContext.java:340)
> at
> org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(
> ContextClassLoaderInterceptor.java:64)
> at
> org.jboss.invocation.InterceptorContext.proceed(
> InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(
> InterceptorContext.java:356)
> at
> org.wildfly.security.manager.WildFlySecurityManager.doChecked(
> WildFlySecurityManager.java:636)
> at
> org.jboss.invocation.AccessCheckingInterceptor.processInvocation(
> AccessCheckingInterceptor.java:61)
> at
> org.jboss.invocation.InterceptorContext.proceed(
> InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(
> InterceptorContext.java:356)
> at
> org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(
> PrivilegedWithCombinerInterceptor.java:80)
> at
> org.jboss.invocation.InterceptorContext.proceed(
> InterceptorContext.java:340)
> at
> org.jboss.invocation.ChainedInterceptor.processInvocation(
> ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> at
> org.jboss.as.ee.component.ViewDescription$1.processInvocation(
> ViewDescription.java:185)
> at
> org.jboss.invocation.InterceptorContext.proceed(
> InterceptorContext.java:340)
> at
> org.jboss.invocation.ChainedInterceptor.processInvocation(
> ChainedInterceptor.java:61)
> at
> org.jboss.as.ee.component.ProxyInvocationHandler.invoke(
> ProxyInvocationHandler.java:73)
> at test.Bean1$$$view1.produceString(Unknown Source)
>
>
> If needed I can later today put this in a Maven project as well, but the
> above should be enough to get you started I hope.
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>
> On Tue, Aug 16, 2016 at 1:26 PM, Tomas Remes <tremes at redhat.com> wrote:
>
> >
> > Hi Arjan,
> >
> > Can you please share some reproducer app? It would be helpful.
> >
> > Thanks
> > Tom
> >
> > ----- Original Message -----
> > From: "arjan tijms" <arjan.tijms at gmail.com>
> > To: "WildFly Dev" <wildfly-dev at lists.jboss.org>
> > Sent: Tuesday, August 16, 2016 1:12:22 PM
> > Subject: [wildfly-dev] ConcurrentAccessTimeoutException using producer
> > in       stateful bean
> >
> > Hi,
> >
> > I came across a situation where a ConcurrentAccessTimeoutException is
> > thrown on WildFly 10.0.0 and 10.1cr1 when an @Stateful @ViewScoped bean
> > contains a CDI producer.
> >
> > In short, there are 3 beans all @Stateful @ViewScoped. Beans 1 and 2 are
> > injected in bean 3.
> >
> > Bean 1 contains a CDI producer.
> > Bean 2 is injected with a type from said producer.
> >
> > The following causes a ConcurrentAccessTimeoutException to be thrown:
> >
> > bean3.somemethod:
> > tx start
> > access stateful bean 1
> > access stateful bean 2
> > (from statefull bean 2): access injected type that causes producer from
> > bean 1 to be called
> > tx end
> >
> > If the call to stateful bean 1 is omitted, the producer is called
> normally
> > when bean 2 accesses the injected type.
> >
> > If bean 2 is injected directly with bean 1, then bean 1 can be accessed
> > without any ConcurrentAccessTimeoutException being thrown.
> >
> > The code runs fine on WildFly 8.2.
> >
> > I'll do some further digging, but wonder if this problem rings any bells.
> > Could it be that CDI obtains a reference to the stateful bean in such a
> way
> > that the implicit EJB interceptor doesn't see it's still within the same
> > TX? But since there's no call to bean 1 in progress at that point, should
> > this even matter?
> >
> > Kind regards,
> > Arjan Tijms
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> >
> >
> >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160816/496df311/attachment-0001.html 

From claudio at claudius.com.br  Tue Aug 16 11:25:59 2016
From: claudio at claudius.com.br (Claudio Miranda)
Date: Tue, 16 Aug 2016 12:25:59 -0300
Subject: [wildfly-dev] Wildfly JAAS HttpServletRequest.login does not
 keep logged in for subsequent requests
In-Reply-To: <62C1F940-149E-49AC-B18E-744E6C40F6DA@youngmediaexperts.nl>
References: <62C1F940-149E-49AC-B18E-744E6C40F6DA@youngmediaexperts.nl>
Message-ID: <CALbD--r3UYqbxEpMk=HEOW3uDDiB2Dc0KcnhhdPO-_zEoFtSYw@mail.gmail.com>

On Tue, Aug 16, 2016 at 4:55 AM, Jan-Willem Gmelig Meyling
<jan-willem at youngmediaexperts.nl> wrote:
> And my `web.xml`:
>
>     <login-config>
>         <auth-method>BASIC</auth-method>
>         <realm-name>MyRealm</realm-name>
>     </login-config>

As you want programmatic authentication, there is no need of <login-config>





-- 
  Claudio Miranda

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

From jan-willem at youngmediaexperts.nl  Wed Aug 17 06:15:24 2016
From: jan-willem at youngmediaexperts.nl (Jan-Willem Gmelig Meyling)
Date: Wed, 17 Aug 2016 12:15:24 +0200
Subject: [wildfly-dev] Wildfly JAAS HttpServletRequest.login does not
 keep logged in for subsequent requests
In-Reply-To: <CALbD--r3UYqbxEpMk=HEOW3uDDiB2Dc0KcnhhdPO-_zEoFtSYw@mail.gmail.com>
References: <62C1F940-149E-49AC-B18E-744E6C40F6DA@youngmediaexperts.nl>
	<CALbD--r3UYqbxEpMk=HEOW3uDDiB2Dc0KcnhhdPO-_zEoFtSYw@mail.gmail.com>
Message-ID: <2C21749B-7F6B-4410-9EED-D63015AA576E@youngmediaexperts.nl>

Hi Claudio,

Thanks for your comment, I have upvoted it on my Stackoverflow thread. Arjan wrote the answer I have accepted, which can be found at http://stackoverflow.com/a/38976889/2104280 <http://stackoverflow.com/a/38976889/2104280> .

Turns out the session behaviour for the login call is not really defined in Servlet 3.0 and may be improved in JSR 375.

Thanks for your answers!

Jan-Willem


> On 16 Aug 2016, at 17:25, Claudio Miranda <claudio at claudius.com.br> wrote:
> 
> On Tue, Aug 16, 2016 at 4:55 AM, Jan-Willem Gmelig Meyling
> <jan-willem at youngmediaexperts.nl> wrote:
>> And my `web.xml`:
>> 
>>    <login-config>
>>        <auth-method>BASIC</auth-method>
>>        <realm-name>MyRealm</realm-name>
>>    </login-config>
> 
> As you want programmatic authentication, there is no need of <login-config>
> 
> 
> 
> 
> 
> --
>  Claudio Miranda
> 
> claudio at claudius.com.br
> http://www.claudius.com.br

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160817/4d07af2a/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160817/4d07af2a/attachment.bin 

From tcrawley at redhat.com  Wed Aug 17 12:50:33 2016
From: tcrawley at redhat.com (Toby Crawley)
Date: Wed, 17 Aug 2016 12:50:33 -0400
Subject: [wildfly-dev] Pretty-printing XML validation errors
In-Reply-To: <BC3BCAC3-3774-4F59-9D7D-9E946650F441@redhat.com>
References: <CADHijTRSvduUikNTr90RM0=+BfFDvn-DXOChAWF-+wLQWUxAAg@mail.gmail.com>
	<175112BC-84C9-4A61-802F-A5978729D96F@redhat.com>
	<CADHijTQvRxysqwRgpDZkMi82PgNVZu6X0iVZ6yu8X76HUKAVAg@mail.gmail.com>
	<F551CB68-1E99-4547-B5B9-22F86FA19367@redhat.com>
	<CADHijTSoUQ7Vy5jUDJbgLu0ooNqLX0WncoWF_xZrG+or1Zg+=g@mail.gmail.com>
	<CADHijTTE69q2F7tLfRy0iGEaVE2WiaApxaH6FTL6UqQRv_ciYg@mail.gmail.com>
	<BC3BCAC3-3774-4F59-9D7D-9E946650F441@redhat.com>
Message-ID: <CADHijTTOXL9JeMUqdhWGqbk9zF9Uup8V28m7Y+MT-xjZwcaJvQ@mail.gmail.com>

Responses inline.

On Mon, Aug 15, 2016 at 8:08 PM, Brian Stansberry
<brian.stansberry at redhat.com> wrote:
> Hi Toby,
>
> Sorry for the delay. People I wanted to talk to have been traveling and on vacation etc.
>
> I?ll reply in-line. Bottom line is it looks like you?ve made good progress and this seems worth pursuing. Thanks for digging into it!

Great, thanks! I'll continue to work on the remaining VDX issues
(https://github.com/projectodd/vdx/issues) and get out a real release
I can use it in a PR to wildfly-core to get that conversation started.

>
>> On Aug 9, 2016, at 3:13 PM, Toby Crawley <tcrawley at redhat.com> wrote:
>>
>> I've done some more work on VDX, and have addressed most of the
>> technical concerns about it from this thread, namely:
>>
>> * I18N - VDX is now i18n ready, but currently just has a default
>>  message set in english.
>> * Displaying the default message with code - the original message is
>>  now displayed as part of the output, see
>>  https://gist.github.com/tobias/ec2846a13b6ff656d8e47cbc85071cb1 for
>>  an example.
>> * Handling errors that aren't created by ParseUtils - For any
>>  XMLStreamExceptions that don't get wrapped by ParseUtils, VDX now
>>  shows that error the best it can. This still doesn't handle errors
>>  that aren't XMLStreamExceptions, but is progress. This should also
>>  handle errors thrown from AttributeDefinitions, since they are
>>  XMLStreamExceptions.
>
> What does the failure message look like when AttributeDefinition rejects an attribute? I want to make sure this is helping, not obscuring.
>
> A simple test would be to change the ?port? attribute in a socket-binding element to -1.

That failure generates
https://gist.github.com/tobias/dbf1fc6bb1e264273c0c96453eb9295d. Since
VDX doesn't have further context about the error, it can't point
directly to the offending attribute; it just uses the provided
[row,col] from the error. Any XMLStreamExceptions that don't come from
ParseUtils should look the same.

>
>> https://gist.github.com/tobias/551e712892b9326096ecc80bb78bc132
>>  is an example of handling a non-wrapped exception thrown by the
>>  reader.
>> * Size of dependencies - VDX now has no dependencies, and is currently
>>  61K. Removing the dependencies on Apache XMLSchema and Apache
>>  Commons Lang reduces the total size by 552K.
>>
>
> Great!
>
>> Existing issues:
>>
>> * I18N - though it is set up for i18n, it doesn't yet have any
>>  translations. How many/what languages do we support for WildFly
>>  currently? What is the process for getting translations done?
>
> For WildFly itself, English is fine. But for things that end up in EAP (which this would) we need the ability for the Red Hat localization team to do translations and get the properties files into VDX source. We do this via a tool called Zanata, available at https://translate.jboss.org, with integration via a maven plugin. We can help you get this set up once things are near done. The biggest thing is that your code is i18n which means it can be done.

Good news, thanks.
>
>> * non-XMLStreamException errors - it's currently possible to trigger
>>  errors that aren't XMLStreamExceptions when parsing
>>  standalone.xml. A couple of examples are:
>>
>>  - adding a duplicate extension under server > extensions causes an
>>    IllegalStateException that occurs when trying to generate the
>>    XMLStreamException
>>    (https://gist.github.com/tobias/59d155afe0c88e268b83cb75734353eb)
>
> This one looks to be the parser author (aka me) being lazy and incorrectly using a util method instead of throwing a more custom exception.
>
> I filed https://issues.jboss.org/browse/WFCORE-1717 for this and listed you as the reporter. Thanks!
>
>>  - Creating a file-handler with no attributes under server >
>>    management > audit-log > handlers results in an error about there
>>    being no add operation at address [], with no other context
>>    (https://gist.github.com/tobias/34b7d7791e20148004d883238adf16ac). If
>>    you add a name attribute, you get a different, more helpful
>>    management operation error
>>    (https://gist.github.com/tobias/6d47539aa40de90ec45cfaaec83ea15e),
>>    but neither error points to the xml configuration as the problem.
>>
>
> This sounds like the parser not doing validation that it could, and deferring to the management op handling.
>
>>  Nothing can really be done with VDX to help with these issues, but I
>>  would be happy to provide PR's to fix them as I find them if there
>>  is interest.
>>
>
> Parser improvements are welcome. Somewhat. ;) This gets back a bit to something I said in my first post in this thread:
>
> "Personally I think it?s ok to have this for only some failures. Others may disagree though and start filing bug reports, leading to demands that we fix said ?bugs?, leading to a shift of resource away from other tasks.?
>
> So if we get some simple, no risk patches, great, thank you! I just don?t want to start having people insist that we beef up the level of validation in our parsers so we can get pretty reports. But then not contributing the parser improvements.

That makes sense to me - I definitely want to remain sensitive to the
team's time, and will be mindful of the value of any parser
improvements I propose.

>
> WFCORE-1717 is different; there the parser is just wrong.
>
>> The question now is - should I keep working on this? Is there enough
>> interest in this for me to continue it to the point where it can be
>> used by wildfly-core?
>>
>> Is there interest in seeing this applied to xml that is provided as
>> part of a deployment (web.xml, jboss-web.xml,
>> jboss-deployment-structure.xml, etc) in addition to (or instead of
>> standalone.xml)? I haven't yet looked at what that would take.
>>
>> For reference, the source for VDX is available at
>> https://github.com/projectodd/vdx, and my changes so far to
>> wildfly-core are in this commit:
>> https://github.com/tobias/wildfly-core/commit/2654406bfcfed7cbf255db819f094749487e2d10
>>
>> - Toby
>>
>> On Tue, Jul 19, 2016 at 7:28 PM, Toby Crawley <tcrawley at redhat.com> wrote:
>>> On Tue, Jul 19, 2016 at 4:07 PM, Brian Stansberry
>>> <brian.stansberry at redhat.com> wrote:
>>>> Comments in-line, except for something I just thought of.
>>>>
>>>> All exception and log messages produced will likely need to follow
>>>> WildFly?s/EAP's i18n standards. Message prefixed with a code, text produced
>>>> in a way in an i18n manner with a reasonable way to get localized text into
>>>> the software.
>>>
>>> Ah, good point. It shouldn't be difficult to add localized text to the
>>> output, the biggest cost there would be the time to translate the
>>> messages, but I'm not familiar with how i18n is done in our projects.
>>> For the message code, we could print the original exception message at
>>> the bottom or top of the validation block. That would then use the
>>> same code as we provide now, and would provide the same message we use
>>> now with every error. Would that satisfy the message code requirement?
>>>
>>>>>
>>>>> On Jul 19, 2016, at 2:38 PM, Toby Crawley <tcrawley at redhat.com> wrote:
>>>>>
>>>>>> On Tue, Jul 19, 2016 at 3:15 PM, Brian Stansberry
>>>>>> <brian.stansberry at redhat.com> wrote:
>>>>>>
>>>>>> The only big concern I have about this is that we?ll get this behavior for
>>>>>> some failures but not all. And I don?t want to go down the path of trying to
>>>>>> force every parser to work in a manner such that we consistently get this.
>>>>>>
>>>>>
>>>>> I haven't looked at it too deeply, but it may be straightforward to
>>>>> alter staxmapper to allow providing an exception generator that would
>>>>> allow catching more of the cases that the parsers miss.
>>>>>
>>>>
>>>> I?m not sure how big of a problem staxmapper-thrown exceptions are. (I
>>>> haven?t really thought.)
>>>
>>> That's just the first place I saw errors from outside of ParseUtils,
>>> but I haven't yet started playing with attribute values.
>>>
>>>>
>>>> What I was thinking more about when I wrote my previous post was parsers not
>>>> using ParseUtils, or sometimes not using it.
>>>>
>>>> Also, a lot of XmlStreamException cases are generated from implementations
>>>> of org.jboss.as.controller.AttributeDefinition, e.g.
>>>>
>>>> https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/java/org/jboss/as/controller/SimpleAttributeDefinition.java#L140
>>>>
>>>> Parsers are encouraged to invoke methods on AttributeDefinition to validate
>>>> attribute values. Perhaps though those are better left alone, as the
>>>> validators are meant to produce useful exception messages.
>>>>
>>>
>>> If we let these fall back to just pointing out the error location with
>>> the original message, this may be ok (assuming by "the alidators are
>>> meant to produce useful exception messages" you mean the messages
>>> produced by the AttributeDefinitions).
>>>
>>> <snip>
>>>
>>>>>> A minor concern is how big the added dependencies are. (I don?t know.) We
>>>>>> want to keep WildFly Core small in footprint.
>>>>>>
>>>>>
>>>>> Right now, the only dependencies vdx (31k) has are commons-lang (which
>>>>> is already a module in WildFly, but not core-feature-pack),
>>>>> xmlschema-walker (100k), and xmlschema-core (168k). For the rest of
>>>>> the work, I don't currently see needing any more dependencies.
>>>>>
>>>>
>>>> Thanks. So about 583K including 284K for commons-lang. The current
>>>> wildly-core-dist-3.0.0.Alpha3.zip is about 16.9MB, so this is fairly
>>>> substantial.
>>>>
>>>
>>> I'm only using commons-lang for a Levenshtein distance implementation
>>> - that could certainly be pulled in, and we could drop the 284k for
>>> commons-lang. It certainly would be nice to keep core under 17MB
>>> though.
>>>
>>> - Toby
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> JBoss by Red Hat
>
>
>


From brian.stansberry at redhat.com  Wed Aug 17 13:06:28 2016
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 17 Aug 2016 12:06:28 -0500
Subject: [wildfly-dev] Pretty-printing XML validation errors
In-Reply-To: <CADHijTTOXL9JeMUqdhWGqbk9zF9Uup8V28m7Y+MT-xjZwcaJvQ@mail.gmail.com>
References: <CADHijTRSvduUikNTr90RM0=+BfFDvn-DXOChAWF-+wLQWUxAAg@mail.gmail.com>
	<175112BC-84C9-4A61-802F-A5978729D96F@redhat.com>
	<CADHijTQvRxysqwRgpDZkMi82PgNVZu6X0iVZ6yu8X76HUKAVAg@mail.gmail.com>
	<F551CB68-1E99-4547-B5B9-22F86FA19367@redhat.com>
	<CADHijTSoUQ7Vy5jUDJbgLu0ooNqLX0WncoWF_xZrG+or1Zg+=g@mail.gmail.com>
	<CADHijTTE69q2F7tLfRy0iGEaVE2WiaApxaH6FTL6UqQRv_ciYg@mail.gmail.com>
	<BC3BCAC3-3774-4F59-9D7D-9E946650F441@redhat.com>
	<CADHijTTOXL9JeMUqdhWGqbk9zF9Uup8V28m7Y+MT-xjZwcaJvQ@mail.gmail.com>
Message-ID: <DAF8E0A9-E7BC-4ACB-A9C7-9D30232680F6@redhat.com>


> On Aug 17, 2016, at 11:50 AM, Toby Crawley <tcrawley at redhat.com> wrote:
> On Mon, Aug 15, 2016 at 8:08 PM, Brian Stansberry
> <brian.stansberry at redhat.com> wrote:
>> 
>>> On Aug 9, 2016, at 3:13 PM, Toby Crawley <tcrawley at redhat.com> wrote:
>>> * Handling errors that aren't created by ParseUtils - For any
>>> XMLStreamExceptions that don't get wrapped by ParseUtils, VDX now
>>> shows that error the best it can. This still doesn't handle errors
>>> that aren't XMLStreamExceptions, but is progress. This should also
>>> handle errors thrown from AttributeDefinitions, since they are
>>> XMLStreamExceptions.
>> 
>> What does the failure message look like when AttributeDefinition rejects an attribute? I want to make sure this is helping, not obscuring.
>> 
>> A simple test would be to change the ?port? attribute in a socket-binding element to -1.
> 
> That failure generates
> https://gist.github.com/tobias/dbf1fc6bb1e264273c0c96453eb9295d. Since
> VDX doesn't have further context about the error, it can't point
> directly to the offending attribute; it just uses the provided
> [row,col] from the error. Any XMLStreamExceptions that don't come from
> ParseUtils should look the same.

I think this looks ok. The WFLYCTL0117 error code is gone, but that?s fine. It looks better in the ?pretty? part of the report to not have it and it?s still shown later, making it avaiable if it is needed.

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





From gunnar at hibernate.org  Thu Aug 18 03:59:43 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 18 Aug 2016 09:59:43 +0200
Subject: [wildfly-dev] Deploying JSR 352 job as a module
Message-ID: <CADGJaX-GEFY0HmWF0c56MdA6q7WNwc8C2x_+vYZFDf_A=ALPUQ@mail.gmail.com>

Hi,

Is there any example which shows how to deploy a JSR 352 batch job via a
module added to WildFly rather than through a deployed application? This
batch job should then be usable from applications which declare a
dependency to that module.

Trying this, I'm getting an error saying that the batch job's XML
descriptor cannot be found [1]. I.e. the module with the batch job is
visible to the deployed application (as the MassIndexer class can be
accessed), but then JBeret cannot "see" the job XML descriptor within that
module.

Is there anything I can configure in the module.xml of the batch job's
module for exposing its contents to JBeret?

The use case is Hibernate Search where a GSoC student is working on a JSR
352 batch job for re-indexing entities. This job eventually should be part
of Hibernate Search's modules, allowing users to run it if Hibernate Search
is enabled for their application.

Thanks for any pointers,

--Gunnar

[1] Exception: javax.batch.operations.JobStartException: JBERET000601:
Failed to get job xml file for job mass-index.xml
    at
org.jberet.creation.ArchiveXmlLoader.getJobXml(ArchiveXmlLoader.java:129)
    at
org.jberet.creation.ArchiveXmlLoader.loadJobXml(ArchiveXmlLoader.java:91)
    at org.jberet.operations.JobOperatorImpl.start(JobOperatorImpl.java:102)
    at org.hibernate.search.jsr352.MassIndexer.start(MassIndexer.java:90)
    at
org.hibernate.search.jsr352.PerformanceIT.testNewMassIndexer(PerformanceIT.java:167)
    ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160818/7230b8ed/attachment-0001.html 

From jmartisk at redhat.com  Thu Aug 18 07:05:56 2016
From: jmartisk at redhat.com (=?UTF-8?Q?Jan_Marti=C5=A1ka?=)
Date: Thu, 18 Aug 2016 13:05:56 +0200
Subject: [wildfly-dev] Deploying JSR 352 job as a module
In-Reply-To: <CADGJaX-GEFY0HmWF0c56MdA6q7WNwc8C2x_+vYZFDf_A=ALPUQ@mail.gmail.com>
References: <CADGJaX-GEFY0HmWF0c56MdA6q7WNwc8C2x_+vYZFDf_A=ALPUQ@mail.gmail.com>
Message-ID: <CAD8__OE0a-2uTOtCY-MvJeussoG+aAp6_ujfGGUGaDm2fic1RQ@mail.gmail.com>

Does the dependency on the module include a dependency on its META-INF
directory? AFAIK, META-INF contents are by default not visible to
applications' classloaders. I think you need a "meta-inf=import" attribute
or so in jboss-deployment-structure.xml, or the "meta-inf" flag if you are
declaring the dependency in MANIFEST.MF.

Jan

On Thu, Aug 18, 2016 at 9:59 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> Hi,
>
> Is there any example which shows how to deploy a JSR 352 batch job via a
> module added to WildFly rather than through a deployed application? This
> batch job should then be usable from applications which declare a
> dependency to that module.
>
> Trying this, I'm getting an error saying that the batch job's XML
> descriptor cannot be found [1]. I.e. the module with the batch job is
> visible to the deployed application (as the MassIndexer class can be
> accessed), but then JBeret cannot "see" the job XML descriptor within that
> module.
>
> Is there anything I can configure in the module.xml of the batch job's
> module for exposing its contents to JBeret?
>
> The use case is Hibernate Search where a GSoC student is working on a JSR
> 352 batch job for re-indexing entities. This job eventually should be part
> of Hibernate Search's modules, allowing users to run it if Hibernate Search
> is enabled for their application.
>
> Thanks for any pointers,
>
> --Gunnar
>
> [1] Exception: javax.batch.operations.JobStartException: JBERET000601:
> Failed to get job xml file for job mass-index.xml
>     at org.jberet.creation.ArchiveXmlLoader.getJobXml(
> ArchiveXmlLoader.java:129)
>     at org.jberet.creation.ArchiveXmlLoader.loadJobXml(
> ArchiveXmlLoader.java:91)
>     at org.jberet.operations.JobOperatorImpl.start(
> JobOperatorImpl.java:102)
>     at org.hibernate.search.jsr352.MassIndexer.start(MassIndexer.java:90)
>     at org.hibernate.search.jsr352.PerformanceIT.testNewMassIndexer(
> PerformanceIT.java:167)
>     ...
>
> _______________________________________________
> 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/20160818/83ad154d/attachment.html 

From jperkins at redhat.com  Thu Aug 18 12:32:41 2016
From: jperkins at redhat.com (James Perkins)
Date: Thu, 18 Aug 2016 09:32:41 -0700
Subject: [wildfly-dev] Deploying JSR 352 job as a module
In-Reply-To: <CADGJaX-GEFY0HmWF0c56MdA6q7WNwc8C2x_+vYZFDf_A=ALPUQ@mail.gmail.com>
References: <CADGJaX-GEFY0HmWF0c56MdA6q7WNwc8C2x_+vYZFDf_A=ALPUQ@mail.gmail.com>
Message-ID: <CADGwLpjAKOpV7G6BA5JHV88xewVD6dWY6z=ngz8qQkT319+BTA@mail.gmail.com>

You might need to implement an SPI [1] that would expose the job XML.
WildFly will look for SPI's and use those to validate and get the job XML
data.

[1]:
https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/java/org/jberet/spi/JobXmlResolver.java
[2]:
https://github.com/wildfly/wildfly/blob/master/batch/extension-jberet/src/main/java/org/wildfly/extension/batch/jberet/deployment/WildFlyJobXmlResolver.java#L154-L160

On Thu, Aug 18, 2016 at 12:59 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> Hi,
>
> Is there any example which shows how to deploy a JSR 352 batch job via a
> module added to WildFly rather than through a deployed application? This
> batch job should then be usable from applications which declare a
> dependency to that module.
>
> Trying this, I'm getting an error saying that the batch job's XML
> descriptor cannot be found [1]. I.e. the module with the batch job is
> visible to the deployed application (as the MassIndexer class can be
> accessed), but then JBeret cannot "see" the job XML descriptor within that
> module.
>
> Is there anything I can configure in the module.xml of the batch job's
> module for exposing its contents to JBeret?
>
> The use case is Hibernate Search where a GSoC student is working on a JSR
> 352 batch job for re-indexing entities. This job eventually should be part
> of Hibernate Search's modules, allowing users to run it if Hibernate Search
> is enabled for their application.
>
> Thanks for any pointers,
>
> --Gunnar
>
> [1] Exception: javax.batch.operations.JobStartException: JBERET000601:
> Failed to get job xml file for job mass-index.xml
>     at org.jberet.creation.ArchiveXmlLoader.getJobXml(
> ArchiveXmlLoader.java:129)
>     at org.jberet.creation.ArchiveXmlLoader.loadJobXml(
> ArchiveXmlLoader.java:91)
>     at org.jberet.operations.JobOperatorImpl.start(
> JobOperatorImpl.java:102)
>     at org.hibernate.search.jsr352.MassIndexer.start(MassIndexer.java:90)
>     at org.hibernate.search.jsr352.PerformanceIT.testNewMassIndexer(
> PerformanceIT.java:167)
>     ...
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>



-- 
James R. Perkins
JBoss by Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160818/9b9cf02e/attachment.html 

From gunnar at hibernate.org  Fri Aug 19 04:24:31 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 19 Aug 2016 10:24:31 +0200
Subject: [wildfly-dev] Deploying JSR 352 job as a module
In-Reply-To: <CADGwLpjAKOpV7G6BA5JHV88xewVD6dWY6z=ngz8qQkT319+BTA@mail.gmail.com>
References: <CADGJaX-GEFY0HmWF0c56MdA6q7WNwc8C2x_+vYZFDf_A=ALPUQ@mail.gmail.com>
	<CADGwLpjAKOpV7G6BA5JHV88xewVD6dWY6z=ngz8qQkT319+BTA@mail.gmail.com>
Message-ID: <CADGJaX-CozvCAtY_x_UgCDj8zraiHSCzF8BP9-zET-mCHhFG4Q@mail.gmail.com>

Jan, James,

Thanks for your help, that looks promising. Mincong, the GSoC student, will
give your proposals a try tonight.

--Gunnar


2016-08-18 18:32 GMT+02:00 James Perkins <jperkins at redhat.com>:

> You might need to implement an SPI [1] that would expose the job XML.
> WildFly will look for SPI's and use those to validate and get the job XML
> data.
>
> [1]: https://github.com/jberet/jsr352/blob/master/
> jberet-core/src/main/java/org/jberet/spi/JobXmlResolver.java
> [2]: https://github.com/wildfly/wildfly/blob/master/
> batch/extension-jberet/src/main/java/org/wildfly/extension/batch/jberet/
> deployment/WildFlyJobXmlResolver.java#L154-L160
>
> On Thu, Aug 18, 2016 at 12:59 AM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> Hi,
>>
>> Is there any example which shows how to deploy a JSR 352 batch job via a
>> module added to WildFly rather than through a deployed application? This
>> batch job should then be usable from applications which declare a
>> dependency to that module.
>>
>> Trying this, I'm getting an error saying that the batch job's XML
>> descriptor cannot be found [1]. I.e. the module with the batch job is
>> visible to the deployed application (as the MassIndexer class can be
>> accessed), but then JBeret cannot "see" the job XML descriptor within that
>> module.
>>
>> Is there anything I can configure in the module.xml of the batch job's
>> module for exposing its contents to JBeret?
>>
>> The use case is Hibernate Search where a GSoC student is working on a JSR
>> 352 batch job for re-indexing entities. This job eventually should be part
>> of Hibernate Search's modules, allowing users to run it if Hibernate Search
>> is enabled for their application.
>>
>> Thanks for any pointers,
>>
>> --Gunnar
>>
>> [1] Exception: javax.batch.operations.JobStartException: JBERET000601:
>> Failed to get job xml file for job mass-index.xml
>>     at org.jberet.creation.ArchiveXmlLoader.getJobXml(ArchiveXmlLoa
>> der.java:129)
>>     at org.jberet.creation.ArchiveXmlLoader.loadJobXml(ArchiveXmlLo
>> ader.java:91)
>>     at org.jberet.operations.JobOperatorImpl.start(JobOperatorImpl.
>> java:102)
>>     at org.hibernate.search.jsr352.MassIndexer.start(MassIndexer.java:90)
>>     at org.hibernate.search.jsr352.PerformanceIT.testNewMassIndexer
>> (PerformanceIT.java:167)
>>     ...
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
>
> --
> James R. Perkins
> JBoss by Red Hat
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160819/85882a62/attachment.html 

From arjan.tijms at gmail.com  Fri Aug 19 04:50:55 2016
From: arjan.tijms at gmail.com (arjan tijms)
Date: Fri, 19 Aug 2016 10:50:55 +0200
Subject: [wildfly-dev] Authorization manager configurable in jboss-web.xml?
Message-ID: <CAE=-AhDWQjwvHfyEXPTtk+rnB2WdJ+WbuBWr+srUb0OvOC7HpQ@mail.gmail.com>

Hi,

In org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.handleJACCAuthorization
I found the following comment:

  // TODO make the authorization manager implementation configurable in
Undertow or jboss-web.xml

Wonder if that TODO is still on the radar.

Would be quite an improvement if an application could declare itself that
it wanted to use the Java EE authorization module (JACC), which would hold
for either the default JACC module that JBoss/WildFly ships (and
initializes) or a user provide one.

Thoughts?

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

From psilva at redhat.com  Fri Aug 19 10:03:43 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 19 Aug 2016 10:03:43 -0400 (EDT)
Subject: [wildfly-dev] Remove PL from WFLY
In-Reply-To: <1216624997.6100331.1471614566720.JavaMail.zimbra@redhat.com>
Message-ID: <784052583.6109990.1471615423872.JavaMail.zimbra@redhat.com>

Hi,

    On the last few days I've been discussing with Tomaz about the possibility to remove PL from WFLY.

    The reasons for that are:

        - PicketLink was deprecated in favor of Keycloak. See [1] and [2].
        - Fixes are only being done to product version by GSS/SEG teams.
        - Most PL IdM and Federation capabilities such as SAML (plus a plenty of other things) are now available from Keycloak.

    I think we can still provide an installer (we already have that) that could be used to enable PL to a WFLY installation. That would help people using PL to continue with their designs. But for PL Federation and Subsystem, Keycloak should be the best way to go.

    Any comments ?

Regards.
Pedro Igor

[1] http://picketlink.org/news/2015/03/10/PicketLink-and-Keycloak-project-merge/
[2] http://picketlink.org/keycloak-merge-faq/

From tomaz.cerar at gmail.com  Fri Aug 19 10:11:27 2016
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Fri, 19 Aug 2016 16:11:27 +0200
Subject: [wildfly-dev] Remove PL from WFLY
In-Reply-To: <784052583.6109990.1471615423872.JavaMail.zimbra@redhat.com>
References: <1216624997.6100331.1471614566720.JavaMail.zimbra@redhat.com>
	<784052583.6109990.1471615423872.JavaMail.zimbra@redhat.com>
Message-ID: <CAMquZP6TPH=O2ph0UfZ0XfRmz4-QWEwNKA-UbMfkMTnOSkxomQ@mail.gmail.com>

There have also be complains from community why we downgraded the
PicketLink in WF10
and now there is a migration problem from WF9 --> 10. [1]

If we remove it, we would just keep the mgmt stub so we can still manage
mixed-domain with older versions.
Similarly as we did with osgi & friends back in the day.
It was already deprecated in 10, so we could remove it in 11 or later.

--
tomaz

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


On Fri, Aug 19, 2016 at 4:03 PM, Pedro Igor Silva <psilva at redhat.com> wrote:

> Hi,
>
>     On the last few days I've been discussing with Tomaz about the
> possibility to remove PL from WFLY.
>
>     The reasons for that are:
>
>         - PicketLink was deprecated in favor of Keycloak. See [1] and [2].
>         - Fixes are only being done to product version by GSS/SEG teams.
>         - Most PL IdM and Federation capabilities such as SAML (plus a
> plenty of other things) are now available from Keycloak.
>
>     I think we can still provide an installer (we already have that) that
> could be used to enable PL to a WFLY installation. That would help people
> using PL to continue with their designs. But for PL Federation and
> Subsystem, Keycloak should be the best way to go.
>
>     Any comments ?
>
> Regards.
> Pedro Igor
>
> [1] http://picketlink.org/news/2015/03/10/PicketLink-and-
> Keycloak-project-merge/
> [2] http://picketlink.org/keycloak-merge-faq/
> _______________________________________________
> 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/20160819/4aac91ed/attachment.html 

From stuart.w.douglas at gmail.com  Fri Aug 19 18:35:40 2016
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Sat, 20 Aug 2016 08:35:40 +1000
Subject: [wildfly-dev] Authorization manager configurable in
	jboss-web.xml?
In-Reply-To: <CAE=-AhDWQjwvHfyEXPTtk+rnB2WdJ+WbuBWr+srUb0OvOC7HpQ@mail.gmail.com>
References: <CAE=-AhDWQjwvHfyEXPTtk+rnB2WdJ+WbuBWr+srUb0OvOC7HpQ@mail.gmail.com>
Message-ID: <CAAoo=c6=8RAj+oZbXFbCOybTZeHSh9Ky_FxeFeRi-66aRzPoDQ@mail.gmail.com>

I think you should be able to modify it programmatically using a
ServletExtension and changing

io.undertow.servlet.api.DeploymentInfo.authorizationManager from the
default.

Stuart

On Fri, Aug 19, 2016 at 6:50 PM, arjan tijms <arjan.tijms at gmail.com> wrote:

> Hi,
>
> In org.wildfly.extension.undertow.deployment.
> UndertowDeploymentInfoService.handleJACCAuthorization I found the
> following comment:
>
>   // TODO make the authorization manager implementation configurable in
> Undertow or jboss-web.xml
>
> Wonder if that TODO is still on the radar.
>
> Would be quite an improvement if an application could declare itself that
> it wanted to use the Java EE authorization module (JACC), which would hold
> for either the default JACC module that JBoss/WildFly ships (and
> initializes) or a user provide one.
>
> Thoughts?
>
> Kind regards,
> Arjan Tijms
>
>
>
> _______________________________________________
> 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/20160820/4a82e50f/attachment.html 

From arjan.tijms at gmail.com  Fri Aug 19 18:42:35 2016
From: arjan.tijms at gmail.com (arjan tijms)
Date: Sat, 20 Aug 2016 00:42:35 +0200
Subject: [wildfly-dev] Authorization manager configurable in
	jboss-web.xml?
In-Reply-To: <CAAoo=c6=8RAj+oZbXFbCOybTZeHSh9Ky_FxeFeRi-66aRzPoDQ@mail.gmail.com>
References: <CAE=-AhDWQjwvHfyEXPTtk+rnB2WdJ+WbuBWr+srUb0OvOC7HpQ@mail.gmail.com>
	<CAAoo=c6=8RAj+oZbXFbCOybTZeHSh9Ky_FxeFeRi-66aRzPoDQ@mail.gmail.com>
Message-ID: <CAE=-AhA2Z5WmAhO==kDmTWy87Xi75GVfL6nRxL3=WuYJeZLobQ@mail.gmail.com>

Hi,

I guess that should work and for some situations it's even the better
solution. Still, a jboss-web.xml option would be quite a bit easier.

Kind regards,
Arjan Tijms


On Sat, Aug 20, 2016 at 12:35 AM, Stuart Douglas <stuart.w.douglas at gmail.com
> wrote:

> I think you should be able to modify it programmatically using a
> ServletExtension and changing
>
> io.undertow.servlet.api.DeploymentInfo.authorizationManager from the
> default.
>
> Stuart
>
> On Fri, Aug 19, 2016 at 6:50 PM, arjan tijms <arjan.tijms at gmail.com>
> wrote:
>
>> Hi,
>>
>> In org.wildfly.extension.undertow.deployment.UndertowDeploym
>> entInfoService.handleJACCAuthorization I found the following comment:
>>
>>   // TODO make the authorization manager implementation configurable in
>> Undertow or jboss-web.xml
>>
>> Wonder if that TODO is still on the radar.
>>
>> Would be quite an improvement if an application could declare itself that
>> it wanted to use the Java EE authorization module (JACC), which would hold
>> for either the default JACC module that JBoss/WildFly ships (and
>> initializes) or a user provide one.
>>
>> Thoughts?
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>> _______________________________________________
>> 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/20160820/88be7bfe/attachment.html 

From arjan.tijms at gmail.com  Fri Aug 19 19:04:19 2016
From: arjan.tijms at gmail.com (arjan tijms)
Date: Sat, 20 Aug 2016 01:04:19 +0200
Subject: [wildfly-dev] JACCAuthorizationManager only passes roles or caller
 (not both) to JACC module
Message-ID: <CAE=-AhCTZcGqJF5MLoqRVwjqeV9kjpm=vsUjqNxK3OxQ06NWNQ@mail.gmail.com>

Hi,

I noticed that JBoss' JACCAuthorizationManager only passes the role
principals (if any) into a JACC module, as per the following code:

// create a protection domain with the user roles (or account principal if
no roles are found)
        final Map<String, Set<String>> principalVersusRolesMap =
deployment.getDeploymentInfo().getPrincipalVersusRolesMap();
        final Principal[] principals = this.getPrincipals(account,
principalVersusRolesMap);
        final CodeSource codeSource =
servletInfo.getServletClass().getProtectionDomain().getCodeSource();
        final ProtectionDomain protectionDomain = new
ProtectionDomain(codeSource, null, null, principals);

If there happen to be no roles, then and only then is the caller principal
passed to the JACC module.

I wonder if there was any specific idea here. The comment explicitly
indicates this, so it doesn't just seem a bug. But this is quite, unusual,
and also a bit confusing for a JACC module to work with.

As far as I know, no other server does this (at least GF, Payara, Geronimo,
JEUS and TomEE don't do this). You always see all the principals from the
Subject being passed in.

A JACC module can work around this by obtaining the subject directly using
"PolicyContext.getContext("javax.security.auth.Subject.container")", but
still wondering why JBoss doesn't just pass all principals here.

Any insight would be appreciated.

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

From anilsaldhana at gmail.com  Fri Aug 19 22:37:31 2016
From: anilsaldhana at gmail.com (Anil Saldanha)
Date: Fri, 19 Aug 2016 21:37:31 -0500
Subject: [wildfly-dev] Remove PL from WFLY
In-Reply-To: <CAMquZP6TPH=O2ph0UfZ0XfRmz4-QWEwNKA-UbMfkMTnOSkxomQ@mail.gmail.com>
References: <1216624997.6100331.1471614566720.JavaMail.zimbra@redhat.com>
	<784052583.6109990.1471615423872.JavaMail.zimbra@redhat.com>
	<CAMquZP6TPH=O2ph0UfZ0XfRmz4-QWEwNKA-UbMfkMTnOSkxomQ@mail.gmail.com>
Message-ID: <D0234AEE-AC5E-4718-8D88-4CEAE0CAA510@gmail.com>

IMO after seven years in existence - all software needs to be rewritten or adapted or retired.

Time to retire PicketBox and PicketLink from WildFly. Better alternatives exist hopefully.

> On Aug 19, 2016, at 9:11 AM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
> 
> There have also be complains from community why we downgraded the PicketLink in WF10
> and now there is a migration problem from WF9 --> 10. [1]
> 
> If we remove it, we would just keep the mgmt stub so we can still manage mixed-domain with older versions.
> Similarly as we did with osgi & friends back in the day.
> It was already deprecated in 10, so we could remove it in 11 or later.
> 
> --
> tomaz
> 
> [1] https://issues.jboss.org/browse/WFLY-5196
> 
> 
>> On Fri, Aug 19, 2016 at 4:03 PM, Pedro Igor Silva <psilva at redhat.com> wrote:
>> Hi,
>> 
>>     On the last few days I've been discussing with Tomaz about the possibility to remove PL from WFLY.
>> 
>>     The reasons for that are:
>> 
>>         - PicketLink was deprecated in favor of Keycloak. See [1] and [2].
>>         - Fixes are only being done to product version by GSS/SEG teams.
>>         - Most PL IdM and Federation capabilities such as SAML (plus a plenty of other things) are now available from Keycloak.
>> 
>>     I think we can still provide an installer (we already have that) that could be used to enable PL to a WFLY installation. That would help people using PL to continue with their designs. But for PL Federation and Subsystem, Keycloak should be the best way to go.
>> 
>>     Any comments ?
>> 
>> Regards.
>> Pedro Igor
>> 
>> [1] http://picketlink.org/news/2015/03/10/PicketLink-and-Keycloak-project-merge/
>> [2] http://picketlink.org/keycloak-merge-faq/
>> _______________________________________________
>> 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/20160819/e8ed81b8/attachment-0001.html 

From arjan.tijms at gmail.com  Sat Aug 20 06:08:33 2016
From: arjan.tijms at gmail.com (arjan tijms)
Date: Sat, 20 Aug 2016 12:08:33 +0200
Subject: [wildfly-dev] Remove PL from WFLY
In-Reply-To: <D0234AEE-AC5E-4718-8D88-4CEAE0CAA510@gmail.com>
References: <1216624997.6100331.1471614566720.JavaMail.zimbra@redhat.com>
	<784052583.6109990.1471615423872.JavaMail.zimbra@redhat.com>
	<CAMquZP6TPH=O2ph0UfZ0XfRmz4-QWEwNKA-UbMfkMTnOSkxomQ@mail.gmail.com>
	<D0234AEE-AC5E-4718-8D88-4CEAE0CAA510@gmail.com>
Message-ID: <CAE=-AhB-Pnc2OoVvnVCO8uMSZXDXyR8skLN4stZe=5p8gSVYQA@mail.gmail.com>

Hi,

Practically speaking, would the replacement allow JASPIC to be
automatically activated (based on whether the developer registered a SAM
from within the application)?

If I'm not mistaken, this was one of the things made difficult by
PicketLink and the current way JBoss/WildFly sets up security.

One question; what's the relation between Elytron and Keycloak as
replacements or new security systems here?

Kind regards,
Arjan Tijms


On Sat, Aug 20, 2016 at 4:37 AM, Anil Saldanha <anilsaldhana at gmail.com>
wrote:

> IMO after seven years in existence - all software needs to be rewritten or
> adapted or retired.
>
> Time to retire PicketBox and PicketLink from WildFly. Better alternatives
> exist hopefully.
>
> On Aug 19, 2016, at 9:11 AM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
>
> There have also be complains from community why we downgraded the
> PicketLink in WF10
> and now there is a migration problem from WF9 --> 10. [1]
>
> If we remove it, we would just keep the mgmt stub so we can still manage
> mixed-domain with older versions.
> Similarly as we did with osgi & friends back in the day.
> It was already deprecated in 10, so we could remove it in 11 or later.
>
> --
> tomaz
>
> [1] https://issues.jboss.org/browse/WFLY-5196
>
>
> On Fri, Aug 19, 2016 at 4:03 PM, Pedro Igor Silva <psilva at redhat.com>
> wrote:
>
>> Hi,
>>
>>     On the last few days I've been discussing with Tomaz about the
>> possibility to remove PL from WFLY.
>>
>>     The reasons for that are:
>>
>>         - PicketLink was deprecated in favor of Keycloak. See [1] and [2].
>>         - Fixes are only being done to product version by GSS/SEG teams.
>>         - Most PL IdM and Federation capabilities such as SAML (plus a
>> plenty of other things) are now available from Keycloak.
>>
>>     I think we can still provide an installer (we already have that) that
>> could be used to enable PL to a WFLY installation. That would help people
>> using PL to continue with their designs. But for PL Federation and
>> Subsystem, Keycloak should be the best way to go.
>>
>>     Any comments ?
>>
>> Regards.
>> Pedro Igor
>>
>> [1] http://picketlink.org/news/2015/03/10/PicketLink-and-Keycloa
>> k-project-merge/
>> [2] http://picketlink.org/keycloak-merge-faq/
>> _______________________________________________
>> 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/20160820/ebfffcae/attachment.html 

From gunnar at hibernate.org  Mon Aug 22 06:26:46 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 22 Aug 2016 12:26:46 +0200
Subject: [wildfly-dev] Starting/monitoring JSR 352 batch job through
	admin console
In-Reply-To: <CALbD--o_LieMSfNs56LZZC6gpPvwbR60nN9+dg=SwJpzNy1XuQ@mail.gmail.com>
References: <CADGJaX9YWcfBrvzdwuRHMrUwtS3QyL074dyvtJi-yBpcmguxOw@mail.gmail.com>
	<364315C6-E65B-4F72-AF9E-50666E4ED38E@redhat.com>
	<CABM4dPTTKz3XEfnPCPqdf+uYEXwUAHBnCAaXWEsbE7wVBpG86g@mail.gmail.com>
	<CADGwLpg_gYmZiARC_aPd9u2RWpPRWcvgV_w3QxZ0tG1Vv8Ud=g@mail.gmail.com>
	<CALbD--o_LieMSfNs56LZZC6gpPvwbR60nN9+dg=SwJpzNy1XuQ@mail.gmail.com>
Message-ID: <CADGJaX-HRETZ0YCC+ap5hwOjQgndswwDK5sNQSwi6a0Y6h60_w@mail.gmail.com>

Hi,

Is this part of the recently released WF 10.1?

Thanks,

--Gunnar


2016-05-28 17:09 GMT+02:00 Claudio Miranda <claudio at claudius.com.br>:

> On Fri, May 27, 2016 at 2:33 PM, James Perkins <jperkins at redhat.com>
> wrote:
> > I'm not sure on the JIRA, but I know Claudio in CC is working on it now.
>
> I am working on it, it should be merged in master next week.
>
> https://issues.jboss.org/browse/HAL-1104
>
>
> --
>   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/20160822/436cc70b/attachment.html 

From jason.greene at redhat.com  Mon Aug 22 09:39:47 2016
From: jason.greene at redhat.com (Jason Greene)
Date: Mon, 22 Aug 2016 08:39:47 -0500
Subject: [wildfly-dev] Remove PL from WFLY
In-Reply-To: <784052583.6109990.1471615423872.JavaMail.zimbra@redhat.com>
References: <784052583.6109990.1471615423872.JavaMail.zimbra@redhat.com>
Message-ID: <2188392C-841D-41B7-AB4C-47DCF14608BB@redhat.com>


> On Aug 19, 2016, at 9:03 AM, Pedro Igor Silva <psilva at redhat.com> wrote:
> 
> Hi,
> 
>    On the last few days I've been discussing with Tomaz about the possibility to remove PL from WFLY.
> 
>    The reasons for that are:
> 
>        - PicketLink was deprecated in favor of Keycloak. See [1] and [2].
>        - Fixes are only being done to product version by GSS/SEG teams.
>        - Most PL IdM and Federation capabilities such as SAML (plus a plenty of other things) are now available from Keycloak.
> 
>    I think we can still provide an installer (we already have that) that could be used to enable PL to a WFLY installation. That would help people using PL to continue with their designs. But for PL Federation and Subsystem, Keycloak should be the best way to go.
> 
>    Any comments ?

When the provisioning infrastructure for WildFly exists we could relocate it to an optional module that is not included in the default feature pack.  

As it is now though, the best we can do is just not put it in our default config, which is already the case.

We could remove it from WF11, but there are two major negatives:

1. Might break users that rely on it 
2. Since it?s necessary in EAP 7.1 we would have to add it back in again. 

It seems easier to just leave it be for now.

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



From jason.greene at redhat.com  Mon Aug 22 09:43:09 2016
From: jason.greene at redhat.com (Jason Greene)
Date: Mon, 22 Aug 2016 08:43:09 -0500
Subject: [wildfly-dev] 10.1.0.CR1 is available! Try it out!
In-Reply-To: <1469916878.28969.13.camel@muerte.net>
References: <EC275E4B-9D86-43C5-9525-AAA630BE1F01@redhat.com>
	<1469916878.28969.13.camel@muerte.net>
Message-ID: <FEED8EBE-3DB3-4813-A998-2B732D227743@redhat.com>


> On Jul 30, 2016, at 5:14 PM, Harold Campbell <hcamp at muerte.net> wrote:
> 
> On Fri, 2016-07-29 at 15:12 -0500, Jason Greene wrote:
>> Some of you may have noticed that 10.1.0.CR1 was released yesterday:
>> http://wildfly.org/downloads/
>> 
>> Please give it a try and report any major issues. Provided nothing
>> critical comes up, we will release Final next week.
>> 
> 
> 
> This is a showstopper for me.
> 
> https://issues.jboss.org/browse/WFLY-6898
> 

Thanks for the report. I have good news. We just cut 10.1.0.Final late last week, and it contains a fix for this issue.

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



From anmiller at redhat.com  Mon Aug 22 09:44:31 2016
From: anmiller at redhat.com (Andrig Miller)
Date: Mon, 22 Aug 2016 07:44:31 -0600
Subject: [wildfly-dev] Remove PL from WFLY
In-Reply-To: <2188392C-841D-41B7-AB4C-47DCF14608BB@redhat.com>
References: <784052583.6109990.1471615423872.JavaMail.zimbra@redhat.com>
	<2188392C-841D-41B7-AB4C-47DCF14608BB@redhat.com>
Message-ID: <CAF1-sp6NVLwNdbPRBkH4LOMxZX0W7RELbL01Ef09roKf_NqeBw@mail.gmail.com>

On Mon, Aug 22, 2016 at 7:39 AM, Jason Greene <jason.greene at redhat.com>
wrote:

>
> > On Aug 19, 2016, at 9:03 AM, Pedro Igor Silva <psilva at redhat.com> wrote:
> >
> > Hi,
> >
> >    On the last few days I've been discussing with Tomaz about the
> possibility to remove PL from WFLY.
> >
> >    The reasons for that are:
> >
> >        - PicketLink was deprecated in favor of Keycloak. See [1] and [2].
> >        - Fixes are only being done to product version by GSS/SEG teams.
> >        - Most PL IdM and Federation capabilities such as SAML (plus a
> plenty of other things) are now available from Keycloak.
> >
> >    I think we can still provide an installer (we already have that) that
> could be used to enable PL to a WFLY installation. That would help people
> using PL to continue with their designs. But for PL Federation and
> Subsystem, Keycloak should be the best way to go.
> >
> >    Any comments ?
>
> When the provisioning infrastructure for WildFly exists we could relocate
> it to an optional module that is not included in the default feature pack.
>
> As it is now though, the best we can do is just not put it in our default
> config, which is already the case.
>
> We could remove it from WF11, but there are two major negatives:
>
> 1. Might break users that rely on it
>

?Of course it is deprecated, and this has been the case since EAP 6.4.  I
wonder what PM thinks on this.  EAP 7.1, would be two releases past the
deprecation.  Maybe its early, but perhaps not.
?


> 2. Since it?s necessary in EAP 7.1 we would have to add it back in again.
>

?Is this a hard requirement for EAP 7.1, that we continue to have the
deprecated components?
?


>
> It seems easier to just leave it be for now.
>
> --
> 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
>



-- 
Andrig (Andy) T. Miller
Global Platform Director, Middleware
Red Hat, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160822/4dbf4905/attachment-0001.html 

From hpehl at redhat.com  Mon Aug 22 09:47:03 2016
From: hpehl at redhat.com (Harald Pehl)
Date: Mon, 22 Aug 2016 15:47:03 +0200
Subject: [wildfly-dev] Starting/monitoring JSR 352 batch job through
	admin console
In-Reply-To: <CADGJaX-HRETZ0YCC+ap5hwOjQgndswwDK5sNQSwi6a0Y6h60_w@mail.gmail.com>
References: <CADGJaX9YWcfBrvzdwuRHMrUwtS3QyL074dyvtJi-yBpcmguxOw@mail.gmail.com>
	<364315C6-E65B-4F72-AF9E-50666E4ED38E@redhat.com>
	<CABM4dPTTKz3XEfnPCPqdf+uYEXwUAHBnCAaXWEsbE7wVBpG86g@mail.gmail.com>
	<CADGwLpg_gYmZiARC_aPd9u2RWpPRWcvgV_w3QxZ0tG1Vv8Ud=g@mail.gmail.com>
	<CALbD--o_LieMSfNs56LZZC6gpPvwbR60nN9+dg=SwJpzNy1XuQ@mail.gmail.com>
	<CADGJaX-HRETZ0YCC+ap5hwOjQgndswwDK5sNQSwi6a0Y6h60_w@mail.gmail.com>
Message-ID: <DAB90541-0399-4373-A693-595BA5E4193A@redhat.com>

Hi Gunnar, 

no it?s not part of WF 10.1. The scope is WF 11. 

.: Harald

> On 22 Aug 2016, at 12:26, Gunnar Morling <gunnar at hibernate.org> wrote:
> 
> Hi,
> 
> Is this part of the recently released WF 10.1? 
> 
> Thanks,
> 
> --Gunnar
> 
> 
> 2016-05-28 17:09 GMT+02:00 Claudio Miranda <claudio at claudius.com.br <mailto:claudio at claudius.com.br>>:
> On Fri, May 27, 2016 at 2:33 PM, James Perkins <jperkins at redhat.com <mailto:jperkins at redhat.com>> wrote:
> > I'm not sure on the JIRA, but I know Claudio in CC is working on it now.
> 
> I am working on it, it should be merged in master next week.
> 
> https://issues.jboss.org/browse/HAL-1104 <https://issues.jboss.org/browse/HAL-1104>
> 
> 
> --
>   Claudio Miranda
> 
> claudio at claudius.com.br <mailto:claudio at claudius.com.br>
> http://www.claudius.com.br <http://www.claudius.com.br/>
> _______________________________________________
> 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 <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/20160822/c153b6b8/attachment.html 

From gunnar at hibernate.org  Mon Aug 22 09:48:24 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 22 Aug 2016 15:48:24 +0200
Subject: [wildfly-dev] Starting/monitoring JSR 352 batch job through
	admin console
In-Reply-To: <DAB90541-0399-4373-A693-595BA5E4193A@redhat.com>
References: <CADGJaX9YWcfBrvzdwuRHMrUwtS3QyL074dyvtJi-yBpcmguxOw@mail.gmail.com>
	<364315C6-E65B-4F72-AF9E-50666E4ED38E@redhat.com>
	<CABM4dPTTKz3XEfnPCPqdf+uYEXwUAHBnCAaXWEsbE7wVBpG86g@mail.gmail.com>
	<CADGwLpg_gYmZiARC_aPd9u2RWpPRWcvgV_w3QxZ0tG1Vv8Ud=g@mail.gmail.com>
	<CALbD--o_LieMSfNs56LZZC6gpPvwbR60nN9+dg=SwJpzNy1XuQ@mail.gmail.com>
	<CADGJaX-HRETZ0YCC+ap5hwOjQgndswwDK5sNQSwi6a0Y6h60_w@mail.gmail.com>
	<DAB90541-0399-4373-A693-595BA5E4193A@redhat.com>
Message-ID: <CADGJaX--pPFAnYMOt9at_X9gE8N0bCW2ndMX+EwDEBuTrf42FA@mail.gmail.com>

Ok, thanks for the clarification. Looking forward to that feature!

2016-08-22 15:47 GMT+02:00 Harald Pehl <hpehl at redhat.com>:

> Hi Gunnar,
>
> no it?s not part of WF 10.1. The scope is WF 11.
>
> .: Harald
>
> On 22 Aug 2016, at 12:26, Gunnar Morling <gunnar at hibernate.org> wrote:
>
> Hi,
>
> Is this part of the recently released WF 10.1?
>
> Thanks,
>
> --Gunnar
>
>
> 2016-05-28 17:09 GMT+02:00 Claudio Miranda <claudio at claudius.com.br>:
>
>> On Fri, May 27, 2016 at 2:33 PM, James Perkins <jperkins at redhat.com>
>> wrote:
>> > I'm not sure on the JIRA, but I know Claudio in CC is working on it now.
>>
>> I am working on it, it should be merged in master next week.
>>
>> https://issues.jboss.org/browse/HAL-1104
>>
>>
>> --
>>   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
>>
>
> _______________________________________________
> 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/20160822/41614042/attachment.html 

From jason.greene at redhat.com  Mon Aug 22 09:59:33 2016
From: jason.greene at redhat.com (Jason Greene)
Date: Mon, 22 Aug 2016 08:59:33 -0500
Subject: [wildfly-dev] Remove PL from WFLY
In-Reply-To: <CAF1-sp6NVLwNdbPRBkH4LOMxZX0W7RELbL01Ef09roKf_NqeBw@mail.gmail.com>
References: <784052583.6109990.1471615423872.JavaMail.zimbra@redhat.com>
	<2188392C-841D-41B7-AB4C-47DCF14608BB@redhat.com>
	<CAF1-sp6NVLwNdbPRBkH4LOMxZX0W7RELbL01Ef09roKf_NqeBw@mail.gmail.com>
Message-ID: <EB80BE87-DC33-45D0-8B96-046FD5DFBC6D@redhat.com>


> On Aug 22, 2016, at 8:44 AM, Andrig Miller <anmiller at redhat.com> wrote:
> 
> 
> 
> On Mon, Aug 22, 2016 at 7:39 AM, Jason Greene <jason.greene at redhat.com <mailto:jason.greene at redhat.com>> wrote:
> 
> > On Aug 19, 2016, at 9:03 AM, Pedro Igor Silva <psilva at redhat.com <mailto:psilva at redhat.com>> wrote:
> >
> > Hi,
> >
> >    On the last few days I've been discussing with Tomaz about the possibility to remove PL from WFLY.
> >
> >    The reasons for that are:
> >
> >        - PicketLink was deprecated in favor of Keycloak. See [1] and [2].
> >        - Fixes are only being done to product version by GSS/SEG teams.
> >        - Most PL IdM and Federation capabilities such as SAML (plus a plenty of other things) are now available from Keycloak.
> >
> >    I think we can still provide an installer (we already have that) that could be used to enable PL to a WFLY installation. That would help people using PL to continue with their designs. But for PL Federation and Subsystem, Keycloak should be the best way to go.
> >
> >    Any comments ?
> 
> When the provisioning infrastructure for WildFly exists we could relocate it to an optional module that is not included in the default feature pack.
> 
> As it is now though, the best we can do is just not put it in our default config, which is already the case.
> 
> We could remove it from WF11, but there are two major negatives:
> 
> 1. Might break users that rely on it
> 
> ?Of course it is deprecated, and this has been the case since EAP 6.4.  I wonder what PM thinks on this.  EAP 7.1, would be two releases past the deprecation.  Maybe its early, but perhaps not.

That?s a good point. Perhaps its better even if we keep it in 7.1 to drop it from community even if we have to add it back again because they could always manually include it, and it would perhaps encourage earlier feedback on keycloak migrations.

> ? 
> 2. Since it?s necessary in EAP 7.1 we would have to add it back in again.
> 
> ?Is this a hard requirement for EAP 7.1, that we continue to have the deprecated components?

No deprecations at this stage can definitely be dropped. I think my recollection is faulty that we were keeping it around a bit longer.  

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

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

From jason.greene at redhat.com  Mon Aug 22 10:02:22 2016
From: jason.greene at redhat.com (Jason Greene)
Date: Mon, 22 Aug 2016 09:02:22 -0500
Subject: [wildfly-dev] Remove PL from WFLY
In-Reply-To: <CAMquZP6TPH=O2ph0UfZ0XfRmz4-QWEwNKA-UbMfkMTnOSkxomQ@mail.gmail.com>
References: <1216624997.6100331.1471614566720.JavaMail.zimbra@redhat.com>
	<784052583.6109990.1471615423872.JavaMail.zimbra@redhat.com>
	<CAMquZP6TPH=O2ph0UfZ0XfRmz4-QWEwNKA-UbMfkMTnOSkxomQ@mail.gmail.com>
Message-ID: <8115B373-BAF8-4443-B79B-68F2A033D4D1@redhat.com>


> On Aug 19, 2016, at 9:11 AM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
> 
> There have also be complains from community why we downgraded the PicketLink in WF10
> and now there is a migration problem from WF9 --> 10. [1]
> 
> If we remove it, we would just keep the mgmt stub so we can still manage mixed-domain with older versions.
> Similarly as we did with osgi & friends back in the day.
> It was already deprecated in 10, so we could remove it in 11 or later.
> 
> --
> tomaz
> 
> [1] https://issues.jboss.org/browse/WFLY-5196 <https://issues.jboss.org/browse/WFLY-5196>
This is a pretty strong reason to remove it, if on top of deprecation, most of its users in community want a different version 

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

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

From hcamp at muerte.net  Tue Aug 23 18:12:44 2016
From: hcamp at muerte.net (Harold Campbell)
Date: Tue, 23 Aug 2016 17:12:44 -0500
Subject: [wildfly-dev] 10.1.0.CR1 is available! Try it out!
In-Reply-To: <FEED8EBE-3DB3-4813-A998-2B732D227743@redhat.com>
References: <EC275E4B-9D86-43C5-9525-AAA630BE1F01@redhat.com>
	<1469916878.28969.13.camel@muerte.net>
	<FEED8EBE-3DB3-4813-A998-2B732D227743@redhat.com>
Message-ID: <1471990364.11180.15.camel@muerte.net>

On Mon, 2016-08-22 at 08:43 -0500, Jason Greene wrote:
> >?
> > This is a showstopper for me.
> > 
> > https://issues.jboss.org/browse/WFLY-6898
> > 
> 
> Thanks for the report. I have good news. We just cut 10.1.0.Final
> late last week, and it contains a fix for this issue.
> 

Ah, excellent! The problem does seem to be resolved.

-- 
Harold Campbell <hcamp at muerte.net>

Uh-oh -- WHY am I suddenly thinking of a VENERABLE religious leader
frolicking on a FORT LAUDERDALE weekend?

From smarlow at redhat.com  Thu Aug 25 08:49:50 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Thu, 25 Aug 2016 08:49:50 -0400
Subject: [wildfly-dev] Hacking on a fix for the JPA/CDI (WFLY-2387)
 injection problem but now hit a new maven cycle between wildfly-jpa +
 wildfly-weld when WeldPortableExtensions is used from wildfly-jpa...
Message-ID: <f27f217c-a3a1-e53d-e74f-f696c966d6ea@redhat.com>

If I have the WildFly JPA subsystem depend on org.jboss.as.weld 
(org.jboss.as.weld static module), that introduces a cycle that maven 
complains about [1], since wildfly-weld depends on wildfly-jpa already.

I pushed my test branch to github [2], which builds on the proposed 
upgrade to use Hibernate ORM 5.1 in WF 11.

Should we switch to use the "Capabilities" hammer to expose the 
org.jboss.as.weld.deployment.WeldPortableExtensions class that the JPA 
subsystem needs access to?  Or should we work around this minor 
difficulty by exposing WeldPortableExtensions via an additional module 
that the wildfly-jpa can access?

Scott

[1] The projects in the reactor contain a cyclic reference:

Edge between 
'Vertex{label='org.wildfly:wildfly-weld:11.0.0.Alpha1-SNAPSHOT  '}' and 
'Vertex{label='org.wildfly:wildfly-jpa:11.0.0.Alpha1-SNAPSHOT'}' 
introduces to cycle in the graph 
org.wildfly:wildfly-jpa:11.0.0.Alpha1-SNAPSHOT --> 
org.wildfly:wildfly-weld:11.0.0.Alpha1-SNAPSHOT --> 
org.wildfly:wildfly-jpa:11.0.0.Alpha1-SNAPSHOT

[2] 
https://github.com/scottmarlow/wildfly/tree/WFLY-2387_ORM51_CDI_INJECTION

[3] 
https://docs.jboss.org/author/display/WFLY10/Working+with+WildFly+Capabilities

From mkouba at redhat.com  Thu Aug 25 09:26:11 2016
From: mkouba at redhat.com (Martin Kouba)
Date: Thu, 25 Aug 2016 15:26:11 +0200
Subject: [wildfly-dev] Hacking on a fix for the JPA/CDI (WFLY-2387)
 injection problem but now hit a new maven cycle between wildfly-jpa +
 wildfly-weld when WeldPortableExtensions is used from wildfly-jpa...
In-Reply-To: <f27f217c-a3a1-e53d-e74f-f696c966d6ea@redhat.com>
References: <f27f217c-a3a1-e53d-e74f-f696c966d6ea@redhat.com>
Message-ID: <e8867c85-5499-98cd-1077-9d2722d17d8d@redhat.com>

Hi Scott,

FYI I'm working on WFLY-6941 [1] to split Weld subsystem into several 
modules. So it shouln't be a problem to add one more module for 
WeldPortableExtensions and similar stuff.

I don't know much about Capabilities but to me it looks like overkill 
for this specific problem.

Martin

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

Dne 25.8.2016 v 14:49 Scott Marlow napsal(a):
> If I have the WildFly JPA subsystem depend on org.jboss.as.weld
> (org.jboss.as.weld static module), that introduces a cycle that maven
> complains about [1], since wildfly-weld depends on wildfly-jpa already.
>
> I pushed my test branch to github [2], which builds on the proposed
> upgrade to use Hibernate ORM 5.1 in WF 11.
>
> Should we switch to use the "Capabilities" hammer to expose the
> org.jboss.as.weld.deployment.WeldPortableExtensions class that the JPA
> subsystem needs access to?  Or should we work around this minor
> difficulty by exposing WeldPortableExtensions via an additional module
> that the wildfly-jpa can access?
>
> Scott
>
> [1] The projects in the reactor contain a cyclic reference:
>
> Edge between
> 'Vertex{label='org.wildfly:wildfly-weld:11.0.0.Alpha1-SNAPSHOT  '}' and
> 'Vertex{label='org.wildfly:wildfly-jpa:11.0.0.Alpha1-SNAPSHOT'}'
> introduces to cycle in the graph
> org.wildfly:wildfly-jpa:11.0.0.Alpha1-SNAPSHOT -->
> org.wildfly:wildfly-weld:11.0.0.Alpha1-SNAPSHOT -->
> org.wildfly:wildfly-jpa:11.0.0.Alpha1-SNAPSHOT
>
> [2]
> https://github.com/scottmarlow/wildfly/tree/WFLY-2387_ORM51_CDI_INJECTION
>
> [3]
> https://docs.jboss.org/author/display/WFLY10/Working+with+WildFly+Capabilities
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From smarlow at redhat.com  Thu Aug 25 10:02:41 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Thu, 25 Aug 2016 10:02:41 -0400
Subject: [wildfly-dev] Hacking on a fix for the JPA/CDI (WFLY-2387)
 injection problem but now hit a new maven cycle between wildfly-jpa +
 wildfly-weld when WeldPortableExtensions is used from wildfly-jpa...
In-Reply-To: <e8867c85-5499-98cd-1077-9d2722d17d8d@redhat.com>
References: <f27f217c-a3a1-e53d-e74f-f696c966d6ea@redhat.com>
	<e8867c85-5499-98cd-1077-9d2722d17d8d@redhat.com>
Message-ID: <bba731cc-4db9-255a-bf96-fe27e7904c54@redhat.com>



On 08/25/2016 09:26 AM, Martin Kouba wrote:
> Hi Scott,
>
> FYI I'm working on WFLY-6941 [1] to split Weld subsystem into several
> modules. So it shouln't be a problem to add one more module for
> WeldPortableExtensions and similar stuff.

Thanks Martin, I'll link WFLY-2387 to WFLY-6941.

>
> I don't know much about Capabilities but to me it looks like overkill
> for this specific problem.
>
> Martin
>
> [1]
> https://issues.jboss.org/browse/WFLY-6941
>
> Dne 25.8.2016 v 14:49 Scott Marlow napsal(a):
>> If I have the WildFly JPA subsystem depend on org.jboss.as.weld
>> (org.jboss.as.weld static module), that introduces a cycle that maven
>> complains about [1], since wildfly-weld depends on wildfly-jpa already.
>>
>> I pushed my test branch to github [2], which builds on the proposed
>> upgrade to use Hibernate ORM 5.1 in WF 11.
>>
>> Should we switch to use the "Capabilities" hammer to expose the
>> org.jboss.as.weld.deployment.WeldPortableExtensions class that the JPA
>> subsystem needs access to?  Or should we work around this minor
>> difficulty by exposing WeldPortableExtensions via an additional module
>> that the wildfly-jpa can access?
>>
>> Scott
>>
>> [1] The projects in the reactor contain a cyclic reference:
>>
>> Edge between
>> 'Vertex{label='org.wildfly:wildfly-weld:11.0.0.Alpha1-SNAPSHOT  '}' and
>> 'Vertex{label='org.wildfly:wildfly-jpa:11.0.0.Alpha1-SNAPSHOT'}'
>> introduces to cycle in the graph
>> org.wildfly:wildfly-jpa:11.0.0.Alpha1-SNAPSHOT -->
>> org.wildfly:wildfly-weld:11.0.0.Alpha1-SNAPSHOT -->
>> org.wildfly:wildfly-jpa:11.0.0.Alpha1-SNAPSHOT
>>
>> [2]
>> https://github.com/scottmarlow/wildfly/tree/WFLY-2387_ORM51_CDI_INJECTION
>>
>> [3]
>> https://docs.jboss.org/author/display/WFLY10/Working+with+WildFly+Capabilities
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>

From ceharris414 at me.com  Sun Aug 28 06:40:25 2016
From: ceharris414 at me.com (Carl Harris)
Date: Sun, 28 Aug 2016 06:40:25 -0400
Subject: [wildfly-dev] use EL in wildfly module
Message-ID: <4B9476CE-182D-45F2-B429-532B386D5BC8@me.com>

This may not be the right place to ask this question -- feel free to redirect me as appropriate.

I have a CDI extension packaged as a Wildfly module. The extension evaluates some EL expressions. In order to evaluate the expressions it calls javax.el.ExpressionFactory.newInstance() to get an ExpressionFactory. However, when calling this method an exception is thrown:

Caused by: javax.el.ELException: Provider com.sun.el.ExpressionFactoryImpl not found
	at javax.el.FactoryFinder.newInstance(FactoryFinder.java:102)
	at javax.el.FactoryFinder.find(FactoryFinder.java:186)
	at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:197)
	at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:168)
	at javax.el.ELUtil.<clinit>(ELUtil.java:99)
	... 50 more
Caused by: java.lang.ClassNotFoundException: com.sun.el.ExpressionFactoryImpl from [Module \"javax.el.api:main\" from local module loader @18ef96 (finder: local module finder @6956de9 (roots: /tmp/wildfly-10.0.0.Final/modules,/tmp/wildfly-10.0.0.Final/modules/system/layers/base))]


I *think* the module descriptor has the right dependencies, but evidently I?m missing something. 

<module xmlns="urn:jboss:module:1.0" name="org.soulwing.pinject" slot="main">
  <resources>
    <resource-root path="pinject-extension-1.2.0-SNAPSHOT.jar" />
  </resources>

  <dependencies>
    <module name="org.soulwing.pinject.api" />
    <module name="org.glassfish.javax.el" />
    <module name="javax.inject.api" />
    <module name="javax.enterprise.api"/>
    <module name="javax.mail.api" />
    <module name="javax.el.api" />
    <module name="javax.api" />
  </dependencies>

</module>

I?ve looked at some other Wildfly modules that use EL (e.g. Hibernate Validator), but I haven?t been able to discern what they?re doing differently. 

carl



From stuart.w.douglas at gmail.com  Tue Aug 30 00:05:23 2016
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Tue, 30 Aug 2016 14:05:23 +1000
Subject: [wildfly-dev] use EL in wildfly module
In-Reply-To: <4B9476CE-182D-45F2-B429-532B386D5BC8@me.com>
References: <4B9476CE-182D-45F2-B429-532B386D5BC8@me.com>
Message-ID: <CAAoo=c6UzkAEYPZSi+e=YSsCM2izDUbbajNDKHVGnomFBdBQhw@mail.gmail.com>

You probably need to import services:

    <module name="org.glassfish.javax.el" services="import" />

Stuart

On Sun, Aug 28, 2016 at 8:40 PM, Carl Harris <ceharris414 at me.com> wrote:

> This may not be the right place to ask this question -- feel free to
> redirect me as appropriate.
>
> I have a CDI extension packaged as a Wildfly module. The extension
> evaluates some EL expressions. In order to evaluate the expressions it
> calls javax.el.ExpressionFactory.newInstance() to get an
> ExpressionFactory. However, when calling this method an exception is thrown:
>
> Caused by: javax.el.ELException: Provider com.sun.el.ExpressionFactoryImpl
> not found
>         at javax.el.FactoryFinder.newInstance(FactoryFinder.java:102)
>         at javax.el.FactoryFinder.find(FactoryFinder.java:186)
>         at javax.el.ExpressionFactory.newInstance(ExpressionFactory.
> java:197)
>         at javax.el.ExpressionFactory.newInstance(ExpressionFactory.
> java:168)
>         at javax.el.ELUtil.<clinit>(ELUtil.java:99)
>         ... 50 more
> Caused by: java.lang.ClassNotFoundException: com.sun.el.ExpressionFactoryImpl
> from [Module \"javax.el.api:main\" from local module loader @18ef96
> (finder: local module finder @6956de9 (roots: /tmp/wildfly-10.0.0.Final/
> modules,/tmp/wildfly-10.0.0.Final/modules/system/layers/base))]
>
>
> I *think* the module descriptor has the right dependencies, but evidently
> I?m missing something.
>
> <module xmlns="urn:jboss:module:1.0" name="org.soulwing.pinject"
> slot="main">
>   <resources>
>     <resource-root path="pinject-extension-1.2.0-SNAPSHOT.jar" />
>   </resources>
>
>   <dependencies>
>     <module name="org.soulwing.pinject.api" />
>     <module name="org.glassfish.javax.el" />
>     <module name="javax.inject.api" />
>     <module name="javax.enterprise.api"/>
>     <module name="javax.mail.api" />
>     <module name="javax.el.api" />
>     <module name="javax.api" />
>   </dependencies>
>
> </module>
>
> I?ve looked at some other Wildfly modules that use EL (e.g. Hibernate
> Validator), but I haven?t been able to discern what they?re doing
> differently.
>
> carl
>
>
> _______________________________________________
> 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/20160830/d0f4a4a9/attachment.html 

From mstefank at redhat.com  Tue Aug 30 03:01:09 2016
From: mstefank at redhat.com (Martin Stefanko)
Date: Tue, 30 Aug 2016 09:01:09 +0200
Subject: [wildfly-dev] Fwd: ContainerStateMonitor
In-Reply-To: <CAEEDSKXLmKQMx4G56bET4fv=CY8RiOSpa=JLmPP2=kqkVAOC2w@mail.gmail.com>
References: <CAEEDSKXLmKQMx4G56bET4fv=CY8RiOSpa=JLmPP2=kqkVAOC2w@mail.gmail.com>
Message-ID: <CAEEDSKXnNgdqqYmO7W=XFqn13QDv4La8pA8ZnuKzPzhHRypedQ@mail.gmail.com>

Forwarding to the mailing list.

---------- Forwarded message ----------
From: Martin Stefanko <mstefank at redhat.com>
Date: Thu, Aug 25, 2016 at 1:07 PM
Subject: ContainerStateMonitor
To: david.lloyd at redhat.com



Hello David,

For my issue [1] I need to propagate log massage from
the ContainerStateMonitor [2] to the HAL console. As I have no experience
with the wildfly-core may I ask if there is some easy way to this? What I
see in HAL we are using operations directly on CLI. I would like to use
something in style of events and listeners if it is possible.

Thank you.


[1] https://issues.jboss.org/browse/JBEAP-5036
[2] https://github.com/xstefank/wildfly-core/blob/
master/controller/src/main/java/org/jboss/as/controller/
ContainerStateMonitor.java#L72

Martin Stefanko

Associate Software Engineer
JBoss Sustaining Engineering Team
Red Hat Czech s.r.o.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160830/d3e5b5d9/attachment-0001.html 

From ceharris414 at me.com  Tue Aug 30 05:22:00 2016
From: ceharris414 at me.com (Carl Harris)
Date: Tue, 30 Aug 2016 05:22:00 -0400
Subject: [wildfly-dev] use EL in wildfly module
In-Reply-To: <CAAoo=c6UzkAEYPZSi+e=YSsCM2izDUbbajNDKHVGnomFBdBQhw@mail.gmail.com>
References: <4B9476CE-182D-45F2-B429-532B386D5BC8@me.com>
	<CAAoo=c6UzkAEYPZSi+e=YSsCM2izDUbbajNDKHVGnomFBdBQhw@mail.gmail.com>
Message-ID: <C085A1D5-CE9C-40CC-8755-A313994F8C9E@me.com>


> On Aug 30, 2016, at 12:05 AM, Stuart Douglas <stuart.w.douglas at gmail.com> wrote:
> 
> You probably need to import services: 
> 
>     <module name="org.glassfish.javax.el" services="import" />

Doesn?t seem to make a difference. Interestingly, there doesn?t seem to be a META-INF/services entry of any kind in the module.

After doing some more investigating I think I?ve sorted it out.

My CDI extension creates an ExpressionFactory lazily, during a CDI ProcessInjectionPoint event callback.

In Wildfly 10, when my CDI extension?s ProcessInjectionPoint event observers are being called, the TCCL is not set. 

In Wildfly 9, the TCCL was set to the deployment class loader. Looking at the source for the Glassfish EL implementation, it seems to want to use the TCCL to locate the ExpressionFactory implementation.

I?m thinking that my extension worked in Wildfly 9 only because there was an EL provider on the deployment class loader (since that?s the TCCL) ? it really didn?t matter whether my module declared a dependency on the EL provider, since the module?s class loader wasn?t involved. 

I changed my extension so that it sets the TCCL to the module class loader before creating the EL ExpressionFactory. Now it uses the correct class loader and it doesn?t matter whether a deployment has an EL provider on its class loader; the declared dependency on the Glassfish EL provider in my module descriptor is all that?s needed.

carl

From brian.stansberry at redhat.com  Tue Aug 30 10:10:11 2016
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 30 Aug 2016 09:10:11 -0500
Subject: [wildfly-dev] Fwd: ContainerStateMonitor
In-Reply-To: <CAEEDSKXnNgdqqYmO7W=XFqn13QDv4La8pA8ZnuKzPzhHRypedQ@mail.gmail.com>
References: <CAEEDSKXLmKQMx4G56bET4fv=CY8RiOSpa=JLmPP2=kqkVAOC2w@mail.gmail.com>
	<CAEEDSKXnNgdqqYmO7W=XFqn13QDv4La8pA8ZnuKzPzhHRypedQ@mail.gmail.com>
Message-ID: <E9750071-AE2D-47B9-958E-F5935C7F67D9@redhat.com>

There?s no easy way to do that.

>From a design point of view it doesn?t sound right to try to hook into that message on the client. For the console to make use of that it would need to correlate some async notification from the server with the deployment request so it could inform the user of the negative effect of that request. And if we can do that in the console it makes more sense to do it server side in the operation handling and fail the operation with an error message.

So the thing to do is better understand why the missing dependency is not triggering rollback of the deployment operation and see if that can be improved. I believe the ContainerStateMonitor is running due to execution of the operation so it should be possible.

> On Aug 30, 2016, at 2:01 AM, Martin Stefanko <mstefank at redhat.com> wrote:
> 
> Forwarding to the mailing list.
> 
> ---------- Forwarded message ----------
> From: Martin Stefanko <mstefank at redhat.com>
> Date: Thu, Aug 25, 2016 at 1:07 PM
> Subject: ContainerStateMonitor
> To: david.lloyd at redhat.com
> 
> 
> 
> Hello David,
> 
> For my issue [1] I need to propagate log massage from the ContainerStateMonitor [2] to the HAL console. As I have no experience with the wildfly-core may I ask if there is some easy way to this? What I see in HAL we are using operations directly on CLI. I would like to use something in style of events and listeners if it is possible.
> 
> Thank you.
> 
> 
> [1] https://issues.jboss.org/browse/JBEAP-5036
> [2] https://github.com/xstefank/wildfly-core/blob/master/controller/src/main/java/org/jboss/as/controller/ContainerStateMonitor.java#L72
> 
> Martin Stefanko
> 
> Associate Software Engineer
> JBoss Sustaining Engineering Team
> Red Hat Czech s.r.o.
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

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





From rsearls at redhat.com  Tue Aug 30 12:15:05 2016
From: rsearls at redhat.com (Rebecca Searls)
Date: Tue, 30 Aug 2016 12:15:05 -0400 (EDT)
Subject: [wildfly-dev] question 2 sec boot time of WISE
Message-ID: <392730097.7474774.1472573705630.JavaMail.zimbra@redhat.com>


Wise was pulled from wfly because it was adding 2 sec to boot time.??
Wise is a utility with a GWT interface.  It was added to wfly as an extension.  
It is provided as a WAR file.

Is there any more detail of the boot of this app?

Here are a few options we have thought of.  
What would be the best way to address this so that the user can have access to this tool?

1. lazy deployment of the utility
2. Only provide it in standalone-full.xml
3. Handle it the way xts subsystem was with a standalone-xts conf



From jason.greene at redhat.com  Wed Aug 31 14:51:29 2016
From: jason.greene at redhat.com (Jason Greene)
Date: Wed, 31 Aug 2016 13:51:29 -0500
Subject: [wildfly-dev] question 2 sec boot time of WISE
In-Reply-To: <392730097.7474774.1472573705630.JavaMail.zimbra@redhat.com>
References: <392730097.7474774.1472573705630.JavaMail.zimbra@redhat.com>
Message-ID: <55BA9ADA-21C3-4B6B-98E6-3E349AB59B2F@redhat.com>


> On Aug 30, 2016, at 11:15 AM, Rebecca Searls <rsearls at redhat.com> wrote:
> 
> 
> Wise was pulled from wfly because it was adding 2 sec to boot time.??
> Wise is a utility with a GWT interface.  It was added to wfly as an extension.  
> It is provided as a WAR file.
> 
> Is there any more detail of the boot of this app?

Right, so the big issue is we have had a long standing policy to:

a) Avoid adding any significant time to boot, as that was a major goal of AS7+
b) To not include shipped app server functionality in deployments. This is partly because of (a), since scanning and discovery and deployment chain processing has a cost that is unnecessary for code that is part of the server itself. However, it?s also because solutions that require deployments limit the integration quality of the system. 

Some examples of (b) include

1) EJB is required, but there is likely no error indicating that EJB isn?t present, the annotated class will just be ignored.

2) The deployment being listed in the user?s view of deployments, which is only supposed to represent what the user interacts with

3) A mandatory port hand-off in the UI flow

> 
> 
> Here are a few options we have thought of.  
> What would be the best way to address this so that the user can have access to this tool?
> 

Another option to throw out there, is we could keep this as-is and put it into wildfly-extras.

> 1. lazy deployment of the utility

What did you have in mind? This sounds tricky. You could perhaps have the subsystem register an http handler that dynamically installs the server, but if you are going that far it?s best to just register the components directly as part of the subsystem than in a deployment.

> 2. Only provide it in standalone-full.xml

That would add 63% to the boot time so not really a good option.

> 3. Handle it the way xts subsystem was with a standalone-xis conf

That might be acceptable.

However, is there a reason it?s a deployment in the first place? I mean I can understand keeping it as a deployment to decouple it from the server, but once you are making it part of the server itself, why not integrate it that way. For example the GWT app could be mostly client side, with no GWT-RPC, and the backend debugging facilities could be extra components registered during web service deployment.

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



From anmiller at redhat.com  Wed Aug 31 16:09:30 2016
From: anmiller at redhat.com (Andrig Miller)
Date: Wed, 31 Aug 2016 14:09:30 -0600
Subject: [wildfly-dev] question 2 sec boot time of WISE
In-Reply-To: <55BA9ADA-21C3-4B6B-98E6-3E349AB59B2F@redhat.com>
References: <392730097.7474774.1472573705630.JavaMail.zimbra@redhat.com>
	<55BA9ADA-21C3-4B6B-98E6-3E349AB59B2F@redhat.com>
Message-ID: <CAF1-sp631vkG25pU1VFzFaEd3_tu7V+NDnSQik96EPheT+c3pw@mail.gmail.com>

Another point that I would like to add here, is that one of the options
really flies in the face of another goal we have, which is not having many
configuration files, like we used to.  I'm a little concerned over things
like *.conf files being added.

Andy

On Wed, Aug 31, 2016 at 12:51 PM, Jason Greene <jason.greene at redhat.com>
wrote:

>
> > On Aug 30, 2016, at 11:15 AM, Rebecca Searls <rsearls at redhat.com> wrote:
> >
> >
> > Wise was pulled from wfly because it was adding 2 sec to boot time.
> > Wise is a utility with a GWT interface.  It was added to wfly as an
> extension.
> > It is provided as a WAR file.
> >
> > Is there any more detail of the boot of this app?
>
> Right, so the big issue is we have had a long standing policy to:
>
> a) Avoid adding any significant time to boot, as that was a major goal of
> AS7+
> b) To not include shipped app server functionality in deployments. This is
> partly because of (a), since scanning and discovery and deployment chain
> processing has a cost that is unnecessary for code that is part of the
> server itself. However, it?s also because solutions that require
> deployments limit the integration quality of the system.
>
> Some examples of (b) include
>
> 1) EJB is required, but there is likely no error indicating that EJB isn?t
> present, the annotated class will just be ignored.
>
> 2) The deployment being listed in the user?s view of deployments, which is
> only supposed to represent what the user interacts with
>
> 3) A mandatory port hand-off in the UI flow
>
> >
> >
> > Here are a few options we have thought of.
> > What would be the best way to address this so that the user can have
> access to this tool?
> >
>
> Another option to throw out there, is we could keep this as-is and put it
> into wildfly-extras.
>
> > 1. lazy deployment of the utility
>
> What did you have in mind? This sounds tricky. You could perhaps have the
> subsystem register an http handler that dynamically installs the server,
> but if you are going that far it?s best to just register the components
> directly as part of the subsystem than in a deployment.
>
> > 2. Only provide it in standalone-full.xml
>
> That would add 63% to the boot time so not really a good option.
>
> > 3. Handle it the way xts subsystem was with a standalone-xis conf
>
> That might be acceptable.
>
> However, is there a reason it?s a deployment in the first place? I mean I
> can understand keeping it as a deployment to decouple it from the server,
> but once you are making it part of the server itself, why not integrate it
> that way. For example the GWT app could be mostly client side, with no
> GWT-RPC, and the backend debugging facilities could be extra components
> registered during web service deployment.
>
> --
> 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
>



-- 
Andrig (Andy) T. Miller
Global Platform Director, Middleware
Red Hat, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160831/85854283/attachment.html 

From brian.stansberry at redhat.com  Wed Aug 31 16:24:32 2016
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 31 Aug 2016 15:24:32 -0500
Subject: [wildfly-dev] question 2 sec boot time of WISE
In-Reply-To: <CAF1-sp631vkG25pU1VFzFaEd3_tu7V+NDnSQik96EPheT+c3pw@mail.gmail.com>
References: <392730097.7474774.1472573705630.JavaMail.zimbra@redhat.com>
	<55BA9ADA-21C3-4B6B-98E6-3E349AB59B2F@redhat.com>
	<CAF1-sp631vkG25pU1VFzFaEd3_tu7V+NDnSQik96EPheT+c3pw@mail.gmail.com>
Message-ID: <1FBBB644-85AD-49BB-87AE-DD7BE6EB71BA@redhat.com>

For that one I don?t think the intent was any kind of *.conf. I read it more as ?a standalone.xml variant like the existing docs/examples/configs/standalone-xts.xml used to show usage of the xts subsystem?.

> On Aug 31, 2016, at 3:09 PM, Andrig Miller <anmiller at redhat.com> wrote:
> 
> Another point that I would like to add here, is that one of the options really flies in the face of another goal we have, which is not having many configuration files, like we used to.  I'm a little concerned over things like *.conf files being added.
> 
> Andy
> 
> On Wed, Aug 31, 2016 at 12:51 PM, Jason Greene <jason.greene at redhat.com> wrote:
> 
> > On Aug 30, 2016, at 11:15 AM, Rebecca Searls <rsearls at redhat.com> wrote:
> >
> >
> > Wise was pulled from wfly because it was adding 2 sec to boot time.??
> > Wise is a utility with a GWT interface.  It was added to wfly as an extension.
> > It is provided as a WAR file.
> >
> > Is there any more detail of the boot of this app?
> 
> Right, so the big issue is we have had a long standing policy to:
> 
> a) Avoid adding any significant time to boot, as that was a major goal of AS7+
> b) To not include shipped app server functionality in deployments. This is partly because of (a), since scanning and discovery and deployment chain processing has a cost that is unnecessary for code that is part of the server itself. However, it?s also because solutions that require deployments limit the integration quality of the system.
> 
> Some examples of (b) include
> 
> 1) EJB is required, but there is likely no error indicating that EJB isn?t present, the annotated class will just be ignored.
> 
> 2) The deployment being listed in the user?s view of deployments, which is only supposed to represent what the user interacts with
> 
> 3) A mandatory port hand-off in the UI flow
> 
> >
> >
> > Here are a few options we have thought of.
> > What would be the best way to address this so that the user can have access to this tool?
> >
> 
> Another option to throw out there, is we could keep this as-is and put it into wildfly-extras.
> 
> > 1. lazy deployment of the utility
> 
> What did you have in mind? This sounds tricky. You could perhaps have the subsystem register an http handler that dynamically installs the server, but if you are going that far it?s best to just register the components directly as part of the subsystem than in a deployment.
> 
> > 2. Only provide it in standalone-full.xml
> 
> That would add 63% to the boot time so not really a good option.
> 
> > 3. Handle it the way xts subsystem was with a standalone-xis conf
> 
> That might be acceptable.
> 
> However, is there a reason it?s a deployment in the first place? I mean I can understand keeping it as a deployment to decouple it from the server, but once you are making it part of the server itself, why not integrate it that way. For example the GWT app could be mostly client side, with no GWT-RPC, and the backend debugging facilities could be extra components registered during web service deployment.
> 
> --
> 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
> 
> 
> 
> -- 
> Andrig (Andy) T. Miller
> Global Platform Director, Middleware
> Red Hat, Inc.
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

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





From brian.stansberry at redhat.com  Wed Aug 31 17:51:17 2016
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 31 Aug 2016 16:51:17 -0500
Subject: [wildfly-dev] question 2 sec boot time of WISE
In-Reply-To: <55BA9ADA-21C3-4B6B-98E6-3E349AB59B2F@redhat.com>
References: <392730097.7474774.1472573705630.JavaMail.zimbra@redhat.com>
	<55BA9ADA-21C3-4B6B-98E6-3E349AB59B2F@redhat.com>
Message-ID: <95646C88-7FAF-4AF4-8A2A-023ABAE2E421@redhat.com>

Jason, I?m going to cut-and-paste parts of your post and respond to them that way as it helps me have a logical flow.

> For example the GWT app could be mostly client side, with no GWT-RPC

That part is still involves a deployment though, right? Even if it?s just like HAL and just static files, making it downloadable means either a deployment or some custom integration into the undertow subsystem. The alternative is to make it a special context on the management http interace like we do for the HAL console. Or one way or the other make it part of HAL. But my impression of this app is despite the bit of integration into HAL, it?s not really a ?management? app and is meant to be usable outside of HAL. A "dev-ops" admin may use it, hence the integration with HAL, or a ?dev" may use it, but a classic ?ops? admin is not going to use it and we don?t want to force the ?dev? user to be given admin permissions in order to use it.

If the downloadable part is a deployment but also an patchable official part of the software we for sure don?t want it deployed via the deployments/ folder.

> 
> 2) The deployment being listed in the user?s view of deployments, which is only supposed to represent what the user interacts with

Agreed. If we keep it as a deployment installed by a subsystem we need a proper notion of a system-deployment or something like that. Roughly

a) separate tree in the management model; looks like the deployment tree in terms of child resources, e.g. /sysystem-deployment=foo.war/subsystem=undertow etc but it?s not mixed in with the normal deployments
b) Any API to add/remove/deploy/undeploy is private, not published in the read-resource-description output. Meant for internal use.
c) Handled in terms of deployment processing like a normal deployment, but the DeploymentUnit has a flag or attachment so DUPs can know it?s a system deployment. So, for example we don?t complain about use of private/unsupported/deprecated modules. The first integration of wise resulted in a bunch of log warns that for sure would need to be made to go away.

> 
> 1) EJB is required, but there is likely no error indicating that EJB isn?t present, the annotated class will just be ignored.

This can be mitigated with good use of capabilities and requirements; the resource that makes something available is a capability and it requires other things it needs.

I say ?mitigated? not ?solved? because it?s still possible that the detailed configs of required capabilitiles would not be compatible with the deployment?s needs.

> 
> 3) A mandatory port hand-off in the UI flow

Yeah, that?s kind of ugly. I think it?s the result of trying to integrate a more ?dev? tool into a more ?admin? tool.

> On Aug 31, 2016, at 1:51 PM, Jason Greene <jason.greene at redhat.com> wrote:
> 
> 
>> On Aug 30, 2016, at 11:15 AM, Rebecca Searls <rsearls at redhat.com> wrote:
>> 
>> 
>> Wise was pulled from wfly because it was adding 2 sec to boot time.??
>> Wise is a utility with a GWT interface.  It was added to wfly as an extension.  
>> It is provided as a WAR file.
>> 
>> Is there any more detail of the boot of this app?
> 
> Right, so the big issue is we have had a long standing policy to:
> 
> a) Avoid adding any significant time to boot, as that was a major goal of AS7+
> b) To not include shipped app server functionality in deployments. This is partly because of (a), since scanning and discovery and deployment chain processing has a cost that is unnecessary for code that is part of the server itself. However, it?s also because solutions that require deployments limit the integration quality of the system. 
> 
> Some examples of (b) include
> 
> 1) EJB is required, but there is likely no error indicating that EJB isn?t present, the annotated class will just be ignored.
> 
> 2) The deployment being listed in the user?s view of deployments, which is only supposed to represent what the user interacts with
> 
> 3) A mandatory port hand-off in the UI flow
> 
>> 
>> 
>> Here are a few options we have thought of.  
>> What would be the best way to address this so that the user can have access to this tool?
>> 
> 
> Another option to throw out there, is we could keep this as-is and put it into wildfly-extras.
> 
>> 1. lazy deployment of the utility
> 
> What did you have in mind? This sounds tricky. You could perhaps have the subsystem register an http handler that dynamically installs the server, but if you are going that far it?s best to just register the components directly as part of the subsystem than in a deployment.
> 
>> 2. Only provide it in standalone-full.xml
> 
> That would add 63% to the boot time so not really a good option.
> 
>> 3. Handle it the way xts subsystem was with a standalone-xis conf
> 
> That might be acceptable.
> 
> However, is there a reason it?s a deployment in the first place? I mean I can understand keeping it as a deployment to decouple it from the server, but once you are making it part of the server itself, why not integrate it that way. For example the GWT app could be mostly client side, with no GWT-RPC, and the backend debugging facilities could be extra components registered during web service deployment.
> 
> --
> 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
Manager, Senior Principal Software Engineer
JBoss by Red Hat





From anmiller at redhat.com  Wed Aug 31 18:11:39 2016
From: anmiller at redhat.com (Andrig Miller)
Date: Wed, 31 Aug 2016 16:11:39 -0600
Subject: [wildfly-dev] question 2 sec boot time of WISE
In-Reply-To: <1FBBB644-85AD-49BB-87AE-DD7BE6EB71BA@redhat.com>
References: <392730097.7474774.1472573705630.JavaMail.zimbra@redhat.com>
	<55BA9ADA-21C3-4B6B-98E6-3E349AB59B2F@redhat.com>
	<CAF1-sp631vkG25pU1VFzFaEd3_tu7V+NDnSQik96EPheT+c3pw@mail.gmail.com>
	<1FBBB644-85AD-49BB-87AE-DD7BE6EB71BA@redhat.com>
Message-ID: <CAF1-sp7F+JhxB2KNYkb45MJXzuvt0p47gnqEv6DxGgufc1aeqw@mail.gmail.com>

Okay, good.

Thanks Brian.

Andy

On Wed, Aug 31, 2016 at 2:24 PM, Brian Stansberry <
brian.stansberry at redhat.com> wrote:

> For that one I don?t think the intent was any kind of *.conf. I read it
> more as ?a standalone.xml variant like the existing docs/examples/configs/standalone-xts.xml
> used to show usage of the xts subsystem?.
>
> > On Aug 31, 2016, at 3:09 PM, Andrig Miller <anmiller at redhat.com> wrote:
> >
> > Another point that I would like to add here, is that one of the options
> really flies in the face of another goal we have, which is not having many
> configuration files, like we used to.  I'm a little concerned over things
> like *.conf files being added.
> >
> > Andy
> >
> > On Wed, Aug 31, 2016 at 12:51 PM, Jason Greene <jason.greene at redhat.com>
> wrote:
> >
> > > On Aug 30, 2016, at 11:15 AM, Rebecca Searls <rsearls at redhat.com>
> wrote:
> > >
> > >
> > > Wise was pulled from wfly because it was adding 2 sec to boot time.
> > > Wise is a utility with a GWT interface.  It was added to wfly as an
> extension.
> > > It is provided as a WAR file.
> > >
> > > Is there any more detail of the boot of this app?
> >
> > Right, so the big issue is we have had a long standing policy to:
> >
> > a) Avoid adding any significant time to boot, as that was a major goal
> of AS7+
> > b) To not include shipped app server functionality in deployments. This
> is partly because of (a), since scanning and discovery and deployment chain
> processing has a cost that is unnecessary for code that is part of the
> server itself. However, it?s also because solutions that require
> deployments limit the integration quality of the system.
> >
> > Some examples of (b) include
> >
> > 1) EJB is required, but there is likely no error indicating that EJB
> isn?t present, the annotated class will just be ignored.
> >
> > 2) The deployment being listed in the user?s view of deployments, which
> is only supposed to represent what the user interacts with
> >
> > 3) A mandatory port hand-off in the UI flow
> >
> > >
> > >
> > > Here are a few options we have thought of.
> > > What would be the best way to address this so that the user can have
> access to this tool?
> > >
> >
> > Another option to throw out there, is we could keep this as-is and put
> it into wildfly-extras.
> >
> > > 1. lazy deployment of the utility
> >
> > What did you have in mind? This sounds tricky. You could perhaps have
> the subsystem register an http handler that dynamically installs the
> server, but if you are going that far it?s best to just register the
> components directly as part of the subsystem than in a deployment.
> >
> > > 2. Only provide it in standalone-full.xml
> >
> > That would add 63% to the boot time so not really a good option.
> >
> > > 3. Handle it the way xts subsystem was with a standalone-xis conf
> >
> > That might be acceptable.
> >
> > However, is there a reason it?s a deployment in the first place? I mean
> I can understand keeping it as a deployment to decouple it from the server,
> but once you are making it part of the server itself, why not integrate it
> that way. For example the GWT app could be mostly client side, with no
> GWT-RPC, and the backend debugging facilities could be extra components
> registered during web service deployment.
> >
> > --
> > 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
> >
> >
> >
> > --
> > Andrig (Andy) T. Miller
> > Global Platform Director, Middleware
> > Red Hat, Inc.
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> JBoss by Red Hat
>
>
>
>


-- 
Andrig (Andy) T. Miller
Global Platform Director, Middleware
Red Hat, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160831/99a0d7a5/attachment.html 

From jason.greene at redhat.com  Wed Aug 31 19:12:13 2016
From: jason.greene at redhat.com (Jason T. Greene)
Date: Wed, 31 Aug 2016 19:12:13 -0400 (EDT)
Subject: [wildfly-dev] question 2 sec boot time of WISE
In-Reply-To: <95646C88-7FAF-4AF4-8A2A-023ABAE2E421@redhat.com>
References: <392730097.7474774.1472573705630.JavaMail.zimbra@redhat.com>
	<55BA9ADA-21C3-4B6B-98E6-3E349AB59B2F@redhat.com>
	<95646C88-7FAF-4AF4-8A2A-023ABAE2E421@redhat.com>
Message-ID: <7379543D-09EE-40DD-A5F3-0E052F88A89B@redhat.com>



> On Aug 31, 2016, at 4:51 PM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> 
> 
>> For example the GWT app could be mostly client side, with no GWT-RPC
> 
> That part is still involves a deployment though, right? Even if it?s just like HAL and just static files, making it downloadable means either a deployment or some custom integration into the undertow subsystem. The alternative is to make it a special context on the management http interace like we do for the HAL console. Or one way or the other make it part of HAL. But my impression of this app is despite the bit of integration into HAL, it?s not really a ?management? app and is meant to be usable outside of HAL. A "dev-ops" admin may use it, hence the integration with HAL, or a ?dev" may use it, but a classic ?ops? admin is not going to use it and we don?t want to force the ?dev? user to be given admin permissions in order to use it.
> 
> If the downloadable part is a deployment but also an patchable official part of the software we for sure don?t want it deployed via the deployments/ folder.

By deployment I was referring to going through the deployment process, and registered as a deployment node, in order to start. With client side JS it's just static files and trivial to install wherever is desired. For example, the subsystem could register a handler as part of the server, or the web services subsystem could register a handler as part of a *user* deployment (a special opt in sub URL) or it could be a direct HAL plugin, or yet another app on 9990 and thus usable on a DC. 

As to roles, sure I doubt a standard admin would do much with this. I could maybe see  an operator perhaps verifying service functionality, or perhaps troubleshooting. It definitely seems more of a development use case. In a pure client side solution you aren't really introducing the need for a permission per se because it runs straight from the client browser, with no management API interaction other than discovering the port. 

On the other hand i suspect this relies on CXF to generate the client side messages, so perhaps it would be a complex transition.

-Jason



From brian.stansberry at redhat.com  Wed Aug 31 20:23:43 2016
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 31 Aug 2016 19:23:43 -0500
Subject: [wildfly-dev] question 2 sec boot time of WISE
In-Reply-To: <7379543D-09EE-40DD-A5F3-0E052F88A89B@redhat.com>
References: <392730097.7474774.1472573705630.JavaMail.zimbra@redhat.com>
	<55BA9ADA-21C3-4B6B-98E6-3E349AB59B2F@redhat.com>
	<95646C88-7FAF-4AF4-8A2A-023ABAE2E421@redhat.com>
	<7379543D-09EE-40DD-A5F3-0E052F88A89B@redhat.com>
Message-ID: <077E4783-07B9-45BB-A2AA-B40EC889DD9E@redhat.com>


> On Aug 31, 2016, at 6:12 PM, Jason T. Greene <jason.greene at redhat.com> wrote:
> 
> 
> 
>> On Aug 31, 2016, at 4:51 PM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>> 
>> 
>>> For example the GWT app could be mostly client side, with no GWT-RPC
>> 
>> That part is still involves a deployment though, right? Even if it?s just like HAL and just static files, making it downloadable means either a deployment or some custom integration into the undertow subsystem. The alternative is to make it a special context on the management http interace like we do for the HAL console. Or one way or the other make it part of HAL. But my impression of this app is despite the bit of integration into HAL, it?s not really a ?management? app and is meant to be usable outside of HAL. A "dev-ops" admin may use it, hence the integration with HAL, or a ?dev" may use it, but a classic ?ops? admin is not going to use it and we don?t want to force the ?dev? user to be given admin permissions in order to use it.
>> 
>> If the downloadable part is a deployment but also an patchable official part of the software we for sure don?t want it deployed via the deployments/ folder.
> 
> By deployment I was referring to going through the deployment process, and registered as a deployment node, in order to start. With client side JS it's just static files and trivial to install wherever is desired. For example, the subsystem could register a handler as part of the server, or the web services subsystem could register a handler as part of a *user* deployment (a special opt in sub URL) or it could be a direct HAL plugin, or yet another app on 9990 and thus usable on a DC. 
> 
Yes. I went to dinner before getting a chance to reply to myself saying I didn?t want to distract from your main point about how to integrate, since I realized that if all the ?deployment? part was was serving static files, having the subsystem integrate a simple handler into the webserver is a perfectly good approach.

> As to roles, sure I doubt a standard admin would do much with this. I could maybe see  an operator perhaps verifying service functionality, or perhaps troubleshooting. It definitely seems more of a development use case. In a pure client side solution you aren't really introducing the need for a permission per se because it runs straight from the client browser, with no management API interaction other than discovering the port. 
> 

True. We?d need to restructure how the ?9090? interface is set up though. Now it?s the ?http management? interface with a single security realm. If it became something more general purpose with different security policies for different contexts that would require a different config style

> On the other hand i suspect this relies on CXF to generate the client side messages, so perhaps it would be a complex transition.
> 
> -Jason
> 

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