From lazylland at gmail.com  Sun May  1 18:18:01 2016
From: lazylland at gmail.com (Miles Teg)
Date: Mon, 2 May 2016 00:18:01 +0200
Subject: [wildfly-dev] Refactoring process ?
Message-ID: <CAPnKvDViba9+s-Fxapnx519wGLUr1Rtss4LnZHOr8XjWKkT7qA@mail.gmail.com>

Hello Everyone,

I'm part of a team trying to analyse the effects of refactoring on large
codebases. In this regard, we are analysing the Wildlfy project and the
JIRA tickets.

We would like to know:
i) Do you follow a particular conventions for changes that are
refactorings: e.g. special ticket type or commit messages
ii) Are there specific tickets that are examples of large-scale
refactorings that were done with the intention of improving maintainability.

Would appreciate any pointers in this regard :)

Thank you in advance,
Miles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160502/f264b52d/attachment.html 

From hbraun at redhat.com  Mon May  2 06:03:44 2016
From: hbraun at redhat.com (Heiko Braun)
Date: Mon, 2 May 2016 12:03:44 +0200
Subject: [wildfly-dev] Speed Up Deployment
Message-ID: <9183EF05-D698-43F0-9252-03AA6E2310E9@redhat.com>


Are there any recommendations for making the deployment faster on WF? One thing I was wondering about is whether certain subsystem support precomputed jandex indexes? 

Regards, Heiko

From stuart.w.douglas at gmail.com  Mon May  2 06:33:18 2016
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Mon, 02 May 2016 10:33:18 +0000
Subject: [wildfly-dev] Speed Up Deployment
In-Reply-To: <9183EF05-D698-43F0-9252-03AA6E2310E9@redhat.com>
References: <9183EF05-D698-43F0-9252-03AA6E2310E9@redhat.com>
Message-ID: <CAAoo=c6NejT_s9vy0VE3rLAsk8=MO-5f0dstxKdciiywCCwiYg@mail.gmail.com>

If you have a META-INF/jandex.idx file in a jar it will be used instead of
indexing the jar. Unless you have a huge deployment I think you are
unlikely to measure any differences though.

Stuart

On Mon, 2 May 2016 at 20:03 Heiko Braun <hbraun at redhat.com> wrote:

>
> Are there any recommendations for making the deployment faster on WF? One
> thing I was wondering about is whether certain subsystem support
> precomputed jandex indexes?
>
> Regards, Heiko
> _______________________________________________
> 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/20160502/e071d5d9/attachment.html 

From hbraun at redhat.com  Mon May  2 06:52:41 2016
From: hbraun at redhat.com (Heiko Braun)
Date: Mon, 2 May 2016 12:52:41 +0200
Subject: [wildfly-dev] Speed Up Deployment
In-Reply-To: <CAAoo=c6NejT_s9vy0VE3rLAsk8=MO-5f0dstxKdciiywCCwiYg@mail.gmail.com>
References: <9183EF05-D698-43F0-9252-03AA6E2310E9@redhat.com>
	<CAAoo=c6NejT_s9vy0VE3rLAsk8=MO-5f0dstxKdciiywCCwiYg@mail.gmail.com>
Message-ID: <3B04C95C-795A-40A0-9B6E-78E83DE211A4@redhat.com>

Thanks, I?ll try that and let you know if I find notable differences.

Regards, Heiko

> On 02 May 2016, at 12:33, Stuart Douglas <stuart.w.douglas at gmail.com> wrote:
> 
> If you have a META-INF/jandex.idx file in a jar it will be used instead of indexing the jar. Unless you have a huge deployment I think you are unlikely to measure any differences though.
> 
> Stuart
> 
> On Mon, 2 May 2016 at 20:03 Heiko Braun <hbraun at redhat.com <mailto:hbraun at redhat.com>> wrote:
> 
> Are there any recommendations for making the deployment faster on WF? One thing I was wondering about is whether certain subsystem support precomputed jandex indexes?
> 
> Regards, Heiko
> _______________________________________________
> 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/20160502/b03824f0/attachment.html 

From jcosta at redhat.com  Mon May  2 10:35:40 2016
From: jcosta at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=)
Date: Mon, 2 May 2016 16:35:40 +0200
Subject: [wildfly-dev] Feature pack provisioning
In-Reply-To: <031C9ABB-1162-49A2-84D4-1E88A292C641@redhat.com>
References: <930099469.16650706.1436450574022.JavaMail.zimbra@redhat.com>
	<031C9ABB-1162-49A2-84D4-1E88A292C641@redhat.com>
Message-ID: <1b707ee4-2541-499b-2237-610d4cf2a46a@redhat.com>

On 16.07.2015 00:11, Jason Greene wrote:
> As to #3, the notion of a runtime provisioning system similar to something like a yum tool is a long term goal, which I totally agree we need, but its going to be a while before we can get there (Definitely not 10 nor 11). Alexey has been assembling requirements for it, and has some ideas around the packaging format. We really want to get it right, so the plan is to let it grow organically until its proven to be a solid system, and only then switch to it.
>
>> On Jul 9, 2015, at 9:02 AM, Marko Strukelj <mstrukel at redhat.com> wrote:
>>
>> 3) provision into existing Wildfly server detecting version mismatches, and configuring existing and additional subsystems for Keycloak to run properly.

Is there any up-to-date information about this feature, such as plans, 
roadmap, branches with PoC for testing, ...?

While the document on [1] is very useful in outlining the idea, I 
couldn't find out if there's any branch I could use for testing or if 
it's already being planned for a specific WF release.

Similar to Keycloak, Hawkular might benefit from a feature like this.

1 - 
https://developer.jboss.org/wiki/LayeredDistributionsAndModulePathOrganization

- Juca.

From brian.stansberry at redhat.com  Mon May  2 12:39:34 2016
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 2 May 2016 11:39:34 -0500
Subject: [wildfly-dev] Feature pack provisioning
In-Reply-To: <1b707ee4-2541-499b-2237-610d4cf2a46a@redhat.com>
References: <930099469.16650706.1436450574022.JavaMail.zimbra@redhat.com>
	<031C9ABB-1162-49A2-84D4-1E88A292C641@redhat.com>
	<1b707ee4-2541-499b-2237-610d4cf2a46a@redhat.com>
Message-ID: <f6232f2e-39fd-c3a5-8732-e694a5db4ba5@redhat.com>

On 5/2/16 9:35 AM, Juraci Paix?o Kr?hling wrote:
> On 16.07.2015 00:11, Jason Greene wrote:
>> As to #3, the notion of a runtime provisioning system similar to something like a yum tool is a long term goal, which I totally agree we need, but its going to be a while before we can get there (Definitely not 10 nor 11). Alexey has been assembling requirements for it, and has some ideas around the packaging format. We really want to get it right, so the plan is to let it grow organically until its proven to be a solid system, and only then switch to it.
>>
>>> On Jul 9, 2015, at 9:02 AM, Marko Strukelj <mstrukel at redhat.com> wrote:
>>>
>>> 3) provision into existing Wildfly server detecting version mismatches, and configuring existing and additional subsystems for Keycloak to run properly.
>
> Is there any up-to-date information about this feature, such as plans,
> roadmap, branches with PoC for testing, ...?
>
> While the document on [1] is very useful in outlining the idea, I
> couldn't find out if there's any branch I could use for testing or if
> it's already being planned for a specific WF release.
>
> Similar to Keycloak, Hawkular might benefit from a feature like this.
>
> 1 -
> https://developer.jboss.org/wiki/LayeredDistributionsAndModulePathOrganization
>

I'll defer to Alexey to respond re: current status, but I just wanted to 
point out that wiki page is not really a design doc for this. That 
describes how layering currently works, since EAP 6.2.

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

From mazz at redhat.com  Mon May  2 13:58:28 2016
From: mazz at redhat.com (John Mazzitelli)
Date: Mon, 2 May 2016 13:58:28 -0400 (EDT)
Subject: [wildfly-dev] can we get host controllers to push out subsystem
 extension modules?
In-Reply-To: <1623923033.243510.1462210891688.JavaMail.zimbra@redhat.com>
Message-ID: <1161059982.250538.1462211908367.JavaMail.zimbra@redhat.com>

<TL;DR>
If I define my own subsystem configuration in one of the domain controller's profiles, can the DC/HC push out my subsystem extension module to the managed standalone servers just like it pushes out deployments to them?
</TL;DR>


In WildFly's Domain Operating Mode you can define Server Groups in your Domain Controller configuration [1]. In these Server Groups you say what deployments should be deployed on which servers, like this:

<server-group name="main" profile="default">
    <deployments>
        <deployment name="foo.war" runtime-name="foo.war" />
    </deployments>
</server-group>

The DC and HC will do their thing to ensure those deployments are installed on the managed standalone servers. [3]

Additionally in your Domain Controller configuration, you can define profiles with different subsystems [2] (so presumably some managed standalone servers can have some subsystems, where others in different profiles don't have to have them - or at least could be configured differently). For example:

<profiles>
    <profile name="default">
        <subsystem xmlns="urn:jboss:domain:web:1.0">
            <connector name="http" scheme="http" protocol="HTTP/1.1" socket-binding="http"/>
            [...]
        </subsystem>
        <subsystem xmlns="urn:jboss:domain:fictional-example:1.0">
            <socket-to-use name="unique-to-bigger"/>
        </subsystem>
        [...]
    </profile>
</profiles>

My question is - does the DC and HC manage that "fictional-example" subsystem extension module just like they handle deployments? In other words, will that subsystem's module get pushed out to the managed standalone servers (in the same way the DC/HC ensures the deployments are pushed out to the managed standalone servers?) If so, where do you put the module directory? On the DC, like deployments [3]? If not, how does this "fictional-example" subsystem that is defined in the profile make its way to the managed standalone server?

Thanks,
John Mazz

[1] https://docs.jboss.org/author/display/WFLY10/Operating+modes
[2] https://docs.jboss.org/author/display/WFLY10/Domain+Setup
[3] https://docs.jboss.org/author/display/WFLY8/Application+deployment

From brian.stansberry at redhat.com  Mon May  2 14:13:58 2016
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 2 May 2016 13:13:58 -0500
Subject: [wildfly-dev] can we get host controllers to push out subsystem
 extension modules?
In-Reply-To: <1161059982.250538.1462211908367.JavaMail.zimbra@redhat.com>
References: <1161059982.250538.1462211908367.JavaMail.zimbra@redhat.com>
Message-ID: <a6def4d3-bdba-7968-cd2f-6cc446953e4d@redhat.com>

No, the only content types we propagate are deployments and rollout 
plans; the stuff that goes in the content repo. Way back at the 
beginning of AS 7, we decided provisioning was out of scope for the 
server and was a JON function. We've considered expanding beyond that 
from time to time, but have never had time. Considered it primarily 
people requesting that modules get pushed around the domain, 
particularly datasource drivers. This is basically a request for module 
propagation.

It is a slightly easier variant of that request though. A key 
requirement with a general module propagation thing is we have to track 
what's available so newly joining hosts can request any necessary 
missing content. That basically means referring to those modules in the 
domain.xml config. With extensions though we already have that reference 
in place.

On 5/2/16 12:58 PM, John Mazzitelli wrote:
> <TL;DR>
> If I define my own subsystem configuration in one of the domain controller's profiles, can the DC/HC push out my subsystem extension module to the managed standalone servers just like it pushes out deployments to them?
> </TL;DR>
>
>
> In WildFly's Domain Operating Mode you can define Server Groups in your Domain Controller configuration [1]. In these Server Groups you say what deployments should be deployed on which servers, like this:
>
> <server-group name="main" profile="default">
>     <deployments>
>         <deployment name="foo.war" runtime-name="foo.war" />
>     </deployments>
> </server-group>
>
> The DC and HC will do their thing to ensure those deployments are installed on the managed standalone servers. [3]
>
> Additionally in your Domain Controller configuration, you can define profiles with different subsystems [2] (so presumably some managed standalone servers can have some subsystems, where others in different profiles don't have to have them - or at least could be configured differently). For example:
>
> <profiles>
>     <profile name="default">
>         <subsystem xmlns="urn:jboss:domain:web:1.0">
>             <connector name="http" scheme="http" protocol="HTTP/1.1" socket-binding="http"/>
>             [...]
>         </subsystem>
>         <subsystem xmlns="urn:jboss:domain:fictional-example:1.0">
>             <socket-to-use name="unique-to-bigger"/>
>         </subsystem>
>         [...]
>     </profile>
> </profiles>
>
> My question is - does the DC and HC manage that "fictional-example" subsystem extension module just like they handle deployments? In other words, will that subsystem's module get pushed out to the managed standalone servers (in the same way the DC/HC ensures the deployments are pushed out to the managed standalone servers?) If so, where do you put the module directory? On the DC, like deployments [3]? If not, how does this "fictional-example" subsystem that is defined in the profile make its way to the managed standalone server?
>
> Thanks,
> John Mazz
>
> [1] https://docs.jboss.org/author/display/WFLY10/Operating+modes
> [2] https://docs.jboss.org/author/display/WFLY10/Domain+Setup
> [3] https://docs.jboss.org/author/display/WFLY8/Application+deployment
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


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

From brian.stansberry at redhat.com  Mon May  2 14:39:09 2016
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 2 May 2016 13:39:09 -0500
Subject: [wildfly-dev] can we get host controllers to push out subsystem
 extension modules?
In-Reply-To: <a6def4d3-bdba-7968-cd2f-6cc446953e4d@redhat.com>
References: <1161059982.250538.1462211908367.JavaMail.zimbra@redhat.com>
	<a6def4d3-bdba-7968-cd2f-6cc446953e4d@redhat.com>
Message-ID: <a8e077e5-e1b9-ff87-c398-36f12d45e275@redhat.com>

On 5/2/16 1:13 PM, Brian Stansberry wrote:
> No, the only content types we propagate are deployments and rollout
> plans; the stuff that goes in the content repo. Way back at the
> beginning of AS 7, we decided provisioning was out of scope for the
> server and was a JON function. We've considered expanding beyond that
> from time to time, but have never had time. Considered it primarily
> people requesting that modules get pushed around the domain,
> particularly datasource drivers. This is basically a request for module
> propagation.
>
> It is a slightly easier variant of that request though. A key
> requirement with a general module propagation thing is we have to track
> what's available so newly joining hosts can request any necessary
> missing content. That basically means referring to those modules in the
> domain.xml config. With extensions though we already have that reference
> in place.
>

BTW, I was brainstorming a bit in that last paragraph, forgetting that 
I'm talking to someone who works on something that is a proper 
layer/add-on on top of WildFly, not an end user writing their own 
extensions. Proper layers/add-ons need to patchable, which adds another 
whole set of requirements beyond just needing to get bits replicated.

> On 5/2/16 12:58 PM, John Mazzitelli wrote:
>> <TL;DR>
>> If I define my own subsystem configuration in one of the domain controller's profiles, can the DC/HC push out my subsystem extension module to the managed standalone servers just like it pushes out deployments to them?
>> </TL;DR>
>>
>>
>> In WildFly's Domain Operating Mode you can define Server Groups in your Domain Controller configuration [1]. In these Server Groups you say what deployments should be deployed on which servers, like this:
>>
>> <server-group name="main" profile="default">
>>     <deployments>
>>         <deployment name="foo.war" runtime-name="foo.war" />
>>     </deployments>
>> </server-group>
>>
>> The DC and HC will do their thing to ensure those deployments are installed on the managed standalone servers. [3]
>>
>> Additionally in your Domain Controller configuration, you can define profiles with different subsystems [2] (so presumably some managed standalone servers can have some subsystems, where others in different profiles don't have to have them - or at least could be configured differently). For example:
>>
>> <profiles>
>>     <profile name="default">
>>         <subsystem xmlns="urn:jboss:domain:web:1.0">
>>             <connector name="http" scheme="http" protocol="HTTP/1.1" socket-binding="http"/>
>>             [...]
>>         </subsystem>
>>         <subsystem xmlns="urn:jboss:domain:fictional-example:1.0">
>>             <socket-to-use name="unique-to-bigger"/>
>>         </subsystem>
>>         [...]
>>     </profile>
>> </profiles>
>>
>> My question is - does the DC and HC manage that "fictional-example" subsystem extension module just like they handle deployments? In other words, will that subsystem's module get pushed out to the managed standalone servers (in the same way the DC/HC ensures the deployments are pushed out to the managed standalone servers?) If so, where do you put the module directory? On the DC, like deployments [3]? If not, how does this "fictional-example" subsystem that is defined in the profile make its way to the managed standalone server?
>>
>> Thanks,
>> John Mazz
>>
>> [1] https://docs.jboss.org/author/display/WFLY10/Operating+modes
>> [2] https://docs.jboss.org/author/display/WFLY10/Domain+Setup
>> [3] https://docs.jboss.org/author/display/WFLY8/Application+deployment
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>


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

From mazz at redhat.com  Mon May  2 15:16:35 2016
From: mazz at redhat.com (John Mazzitelli)
Date: Mon, 2 May 2016 15:16:35 -0400 (EDT)
Subject: [wildfly-dev] can we get host controllers to push out subsystem
 extension modules?
In-Reply-To: <a8e077e5-e1b9-ff87-c398-36f12d45e275@redhat.com>
References: <1161059982.250538.1462211908367.JavaMail.zimbra@redhat.com>
	<a6def4d3-bdba-7968-cd2f-6cc446953e4d@redhat.com>
	<a8e077e5-e1b9-ff87-c398-36f12d45e275@redhat.com>
Message-ID: <1913968088.265978.1462216595101.JavaMail.zimbra@redhat.com>

> BTW, I was brainstorming a bit in that last paragraph, forgetting that
> I'm talking to someone who works on something that is a proper
> layer/add-on on top of WildFly, not an end user writing their own
> extensions. Proper layers/add-ons need to patchable, which adds another
> whole set of requirements beyond just needing to get bits replicated.

My whole email was a brainstorming session :) I don't think we'll need that feature - but I was wondering if it did exist. If it did, might have been something to be considered for something, but since it doesn't exist, that makes it easy. ;)

From brian.stansberry at redhat.com  Mon May  2 15:30:35 2016
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 2 May 2016 14:30:35 -0500
Subject: [wildfly-dev] can we get host controllers to push out subsystem
 extension modules?
In-Reply-To: <1913968088.265978.1462216595101.JavaMail.zimbra@redhat.com>
References: <1161059982.250538.1462211908367.JavaMail.zimbra@redhat.com>
	<a6def4d3-bdba-7968-cd2f-6cc446953e4d@redhat.com>
	<a8e077e5-e1b9-ff87-c398-36f12d45e275@redhat.com>
	<1913968088.265978.1462216595101.JavaMail.zimbra@redhat.com>
Message-ID: <271d2d55-008b-d1b3-e634-585bd8835264@redhat.com>

On 5/2/16 2:16 PM, John Mazzitelli wrote:
>> BTW, I was brainstorming a bit in that last paragraph, forgetting that
>> I'm talking to someone who works on something that is a proper
>> layer/add-on on top of WildFly, not an end user writing their own
>> extensions. Proper layers/add-ons need to patchable, which adds another
>> whole set of requirements beyond just needing to get bits replicated.
>
> My whole email was a brainstorming session :) I don't think we'll need that feature - but I was wondering if it did exist. If it did, might have been something to be considered for something, but since it doesn't exist, that makes it easy. ;)

Cool; brainstorming is good. The bit about how extension modules are 
already clearly referenced in the config model got me thinking a bit 
about other possible similar patterns. Basically any config attribute 
whose value is a module name could be annotated by the attribute author 
as such and that could perhaps drive module propagation around the domain.

But my vague instinct is there needs to be a distinction of some sort 
between stuff that's controlled by provisioning software (like 
layers/add-ons) vs end user stuff where we are being asked to help the 
user provision their own stuff.

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


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

From jcosta at redhat.com  Tue May  3 08:45:59 2016
From: jcosta at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=)
Date: Tue, 3 May 2016 14:45:59 +0200
Subject: [wildfly-dev] Feature pack provisioning
In-Reply-To: <f6232f2e-39fd-c3a5-8732-e694a5db4ba5@redhat.com>
References: <930099469.16650706.1436450574022.JavaMail.zimbra@redhat.com>
	<031C9ABB-1162-49A2-84D4-1E88A292C641@redhat.com>
	<1b707ee4-2541-499b-2237-610d4cf2a46a@redhat.com>
	<f6232f2e-39fd-c3a5-8732-e694a5db4ba5@redhat.com>
Message-ID: <890b506d-009a-c158-a7e4-745ba92882c9@redhat.com>

On 02.05.2016 18:39, Brian Stansberry wrote:
> I'll defer to Alexey to respond re: current status, but I just wanted to
> point out that wiki page is not really a design doc for this. That
> describes how layering currently works, since EAP 6.2.

Indeed. We actually use some of the features described there in 
Hawkular, but it seems I missed some key parts on my initial request for 
information :)

The problem I'm trying to solve is around RPMs, so that Hawkular could 
benefit from the base that Wildfly/EAP gives. Everything seems to be in 
place, except for the custom snippets we need on standalone.xml (like 
system properties, queues/topics, ...) . All of that is doable with 
workarounds, but it would be nice if the layering technique would allow 
us to adjust the main standalone.xml .

- Juca.

From stuart.w.douglas at gmail.com  Wed May  4 01:50:22 2016
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Wed, 4 May 2016 15:50:22 +1000
Subject: [wildfly-dev] EJB over HTTP
Message-ID: <CAAoo=c5=Wa_vJVbad9Mb2K-n1U1Ue9pq_jM5J9m=i4YfLACVbw@mail.gmail.com>

Hi everyone,

I have started looking into support for service invocation over HTTP.
Unlike our existing HTTP upgrade support this will map EJB
requests/responses directly to HTTP requests and responses, which should
allow it to be used behind existing load balancers.

I have started an initial description of the protocol at:
https://github.com/stuartwdouglas/wildfly-http-client/blob/master/docs/wire-spec-v1.asciidoc

The intention is to follow HTTP semantics as closely as possible.
Clustering will be provided in a similar manner to web clustering (i.e. it
will require a load balancer, and work in a similar manner to web
clustering).

There is still plenty work that needs to be done (especially around
security), so if anyone has any feedback let me know.

Stuart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160504/0062f554/attachment.html 

From ghoully at rambler.ru  Wed May  4 05:45:38 2016
From: ghoully at rambler.ru (gh)
Date: Wed, 04 May 2016 13:45:38 +0400
Subject: [wildfly-dev] EJB over HTTP
In-Reply-To: <CAAoo=c5=Wa_vJVbad9Mb2K-n1U1Ue9pq_jM5J9m=i4YfLACVbw@mail.gmail.com>
References: <CAAoo=c5=Wa_vJVbad9Mb2K-n1U1Ue9pq_jM5J9m=i4YfLACVbw@mail.gmail.com>
Message-ID: <5243604.nHp4kplNH5@localhost.localdomain>

Hi Im newbie at wildfly-dev, i know Java (we use JBOSS EAP for our internal project at 
my work) and C++11 and want to participate, may be even in this task. What i have to 
do? Fork->pull request? Our may be you will attach someone of a real dev group to 
me. 

Thank you all.
Alexey, Moscow.


On Wednesday, May 04, 2016 03:50:22 PM Stuart Douglas wrote:


Hi everyone,



I have started looking into support for service invocation over HTTP. Unlike our existing 
HTTP upgrade support this will map EJB requests/responses directly to HTTP requests 
and responses, which should allow it to be used behind existing load balancers.



I have started an initial description of the protocol at: 
https://github.com/stuartwdouglas/wildfly-http-client/blob/master/docs/wire-spec-v1.asciidoc[1]

The intention is to follow HTTP semantics as closely as possible. Clustering will be 
provided in a similar manner to web clustering (i.e. it will require a load balancer, and 
work in a similar manner to web clustering). 



There is still plenty work that needs to be done (especially around security), so if 
anyone has any feedback let me know.




Stuart







--------
[1] https://github.com/stuartwdouglas/wildfly-http-client/blob/master/docs/wire-spec-v1.asciidoc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160504/92d42eff/attachment.html 

From darran.lofthouse at jboss.com  Wed May  4 05:47:44 2016
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Wed, 4 May 2016 10:47:44 +0100
Subject: [wildfly-dev] EJB over HTTP
In-Reply-To: <CAAoo=c5=Wa_vJVbad9Mb2K-n1U1Ue9pq_jM5J9m=i4YfLACVbw@mail.gmail.com>
References: <CAAoo=c5=Wa_vJVbad9Mb2K-n1U1Ue9pq_jM5J9m=i4YfLACVbw@mail.gmail.com>
Message-ID: <14fa16f0-e089-3979-2565-00412b0a1d6a@jboss.com>

I wonder how much this should be integrated with the new client that 
David is currently working on, if the two were closely integrated it 
would make it much easier for clients to switch between the two as well 
as taking advantage of all of the new shared configuration.

Server side Elytron will have a full set of HTTP mechanisms so all the 
mechanisms you list will be available going forward.  Would this be used 
for server to server as well or just client to client?  We may end up 
with additional requirements that we already have for native calls 
regarding clients running with multiple identities and the propagation 
of identities from server to server.

Regards,
Darran Lofthouse.


On 04/05/16 06:50, Stuart Douglas wrote:
> Hi everyone,
>
> I have started looking into support for service invocation over HTTP.
> Unlike our existing HTTP upgrade support this will map EJB
> requests/responses directly to HTTP requests and responses, which should
> allow it to be used behind existing load balancers.
>
> I have started an initial description of the protocol at:
> https://github.com/stuartwdouglas/wildfly-http-client/blob/master/docs/wire-spec-v1.asciidoc
>
> The intention is to follow HTTP semantics as closely as possible.
> Clustering will be provided in a similar manner to web clustering (i.e.
> it will require a load balancer, and work in a similar manner to web
> clustering).
>
> There is still plenty work that needs to be done (especially around
> security), so if anyone has any feedback let me know.
>
> Stuart
>
>

From tomaz.cerar at gmail.com  Wed May  4 05:53:58 2016
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Wed, 4 May 2016 11:53:58 +0200
Subject: [wildfly-dev] EJB over HTTP
In-Reply-To: <5243604.nHp4kplNH5@localhost.localdomain>
References: <CAAoo=c5=Wa_vJVbad9Mb2K-n1U1Ue9pq_jM5J9m=i4YfLACVbw@mail.gmail.com>
	<5243604.nHp4kplNH5@localhost.localdomain>
Message-ID: <CAMquZP5Ji7Hzzu-pgMuFUE3s_EE=oVnmPpeg4mPnCuUgnEgx2w@mail.gmail.com>

On Wed, May 4, 2016 at 11:45 AM, gh <ghoully at rambler.ru> wrote:

> Hi Im newbie at wildfly-dev, i know Java (we use JBOSS EAP for our
> internal project at my work) and C++11 and want to participate, may be even
> in this task. What i have to do? Fork->pull request? Our may be you will
> attach someone of a real dev group to me.



this should get you started
https://developer.jboss.org/wiki/HackingOnWildFly
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160504/4ae31115/attachment-0001.html 

From nickarls at gmail.com  Wed May  4 05:55:54 2016
From: nickarls at gmail.com (Nicklas Karlsson)
Date: Wed, 4 May 2016 12:55:54 +0300
Subject: [wildfly-dev] EJB over HTTP
In-Reply-To: <CAAoo=c5=Wa_vJVbad9Mb2K-n1U1Ue9pq_jM5J9m=i4YfLACVbw@mail.gmail.com>
References: <CAAoo=c5=Wa_vJVbad9Mb2K-n1U1Ue9pq_jM5J9m=i4YfLACVbw@mail.gmail.com>
Message-ID: <CAFzcPXEJkcM7ZmkYc06Gfu+XzpqgZQ1gKgLvRkP+TJtrO6aXSg@mail.gmail.com>

So this will be sort of REST with the exception of the state, transactions
etc? ;-)

(oops, previous post had wrong distribution)

On Wed, May 4, 2016 at 8:50 AM, Stuart Douglas <stuart.w.douglas at gmail.com>
wrote:

> Hi everyone,
>
> I have started looking into support for service invocation over HTTP.
> Unlike our existing HTTP upgrade support this will map EJB
> requests/responses directly to HTTP requests and responses, which should
> allow it to be used behind existing load balancers.
>
> I have started an initial description of the protocol at:
> https://github.com/stuartwdouglas/wildfly-http-client/blob/master/docs/wire-spec-v1.asciidoc
>
> The intention is to follow HTTP semantics as closely as possible.
> Clustering will be provided in a similar manner to web clustering (i.e. it
> will require a load balancer, and work in a similar manner to web
> clustering).
>
> There is still plenty work that needs to be done (especially around
> security), so if anyone has any feedback let me know.
>
> Stuart
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>



-- 
Nicklas Karlsson, +358 40 5062266
Vaakunatie 10 as 7, 20780 Kaarina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160504/4888da67/attachment.html 

From tomaz.cerar at gmail.com  Wed May  4 05:56:53 2016
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Wed, 4 May 2016 11:56:53 +0200
Subject: [wildfly-dev] EJB over HTTP
In-Reply-To: <CAAoo=c5=Wa_vJVbad9Mb2K-n1U1Ue9pq_jM5J9m=i4YfLACVbw@mail.gmail.com>
References: <CAAoo=c5=Wa_vJVbad9Mb2K-n1U1Ue9pq_jM5J9m=i4YfLACVbw@mail.gmail.com>
Message-ID: <CAMquZP5hpVxdtXKObJb0bLwDjH3Op7Ea9gPwBbcG3GMJGJ1zRg@mail.gmail.com>

One thing that seems somewhat odd to me is the usage of JSESSIONID for
tracking session state.
That cookie/param is used for servlet http sessions and given that this is
pure EJB without any servlets
it would be bit confusing to require it. Or will this rely on session
tracking from undertow-servlet?

--
tomaz

On Wed, May 4, 2016 at 7:50 AM, Stuart Douglas <stuart.w.douglas at gmail.com>
wrote:

> Hi everyone,
>
> I have started looking into support for service invocation over HTTP.
> Unlike our existing HTTP upgrade support this will map EJB
> requests/responses directly to HTTP requests and responses, which should
> allow it to be used behind existing load balancers.
>
> I have started an initial description of the protocol at:
> https://github.com/stuartwdouglas/wildfly-http-client/blob/master/docs/wire-spec-v1.asciidoc
>
> The intention is to follow HTTP semantics as closely as possible.
> Clustering will be provided in a similar manner to web clustering (i.e. it
> will require a load balancer, and work in a similar manner to web
> clustering).
>
> There is still plenty work that needs to be done (especially around
> security), so if anyone has any feedback let me know.
>
> Stuart
>
>
>
> _______________________________________________
> 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/20160504/1612089f/attachment.html 

From stuart.w.douglas at gmail.com  Wed May  4 06:36:16 2016
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Wed, 4 May 2016 20:36:16 +1000
Subject: [wildfly-dev] EJB over HTTP
In-Reply-To: <CAMquZP5hpVxdtXKObJb0bLwDjH3Op7Ea9gPwBbcG3GMJGJ1zRg@mail.gmail.com>
References: <CAAoo=c5=Wa_vJVbad9Mb2K-n1U1Ue9pq_jM5J9m=i4YfLACVbw@mail.gmail.com>
	<CAMquZP5hpVxdtXKObJb0bLwDjH3Op7Ea9gPwBbcG3GMJGJ1zRg@mail.gmail.com>
Message-ID: <CAAoo=c7nwpzt_Px0PerB5MPd3csRmAOhWvT+J31TboxPEw=7ww@mail.gmail.com>

The purpose is to enable load balancer based clustering to work. Basically
even though there is no underlying web session the JSESSIONID cookie will
make sure that the load balancer delivers the request to the correct
backend server.

Basically existing load balancers already support sticky sessions, and we
are just piggy backing on that, as the primary customer use case for this
is allowing EJB calls through a HTTP load balancer.

Stuart

On Wed, May 4, 2016 at 7:56 PM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:

> One thing that seems somewhat odd to me is the usage of JSESSIONID for
> tracking session state.
> That cookie/param is used for servlet http sessions and given that this is
> pure EJB without any servlets
> it would be bit confusing to require it. Or will this rely on session
> tracking from undertow-servlet?
>
> --
> tomaz
>
> On Wed, May 4, 2016 at 7:50 AM, Stuart Douglas <stuart.w.douglas at gmail.com
> > wrote:
>
>> Hi everyone,
>>
>> I have started looking into support for service invocation over HTTP.
>> Unlike our existing HTTP upgrade support this will map EJB
>> requests/responses directly to HTTP requests and responses, which should
>> allow it to be used behind existing load balancers.
>>
>> I have started an initial description of the protocol at:
>> https://github.com/stuartwdouglas/wildfly-http-client/blob/master/docs/wire-spec-v1.asciidoc
>>
>> The intention is to follow HTTP semantics as closely as possible.
>> Clustering will be provided in a similar manner to web clustering (i.e. it
>> will require a load balancer, and work in a similar manner to web
>> clustering).
>>
>> There is still plenty work that needs to be done (especially around
>> security), so if anyone has any feedback let me know.
>>
>> Stuart
>>
>>
>>
>> _______________________________________________
>> 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/20160504/cb71aef1/attachment.html 

From stuart.w.douglas at gmail.com  Wed May  4 06:38:54 2016
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Wed, 4 May 2016 20:38:54 +1000
Subject: [wildfly-dev] EJB over HTTP
In-Reply-To: <CAFzcPXEJkcM7ZmkYc06Gfu+XzpqgZQ1gKgLvRkP+TJtrO6aXSg@mail.gmail.com>
References: <CAAoo=c5=Wa_vJVbad9Mb2K-n1U1Ue9pq_jM5J9m=i4YfLACVbw@mail.gmail.com>
	<CAFzcPXEJkcM7ZmkYc06Gfu+XzpqgZQ1gKgLvRkP+TJtrO6aXSg@mail.gmail.com>
Message-ID: <CAAoo=c6DzkdMWgALU=iQDwZ+iftZ9BVG7=BP+MV_B+t=Wr9zjw@mail.gmail.com>

Sort of. The intention is not to make a REST API (as JAX-RS already does
that), but because we are going to try and map to 'correct' HTTP semantics
as much as possible it should be very similar to a REST based API, although
the use of JBoss Marshaling means that it can only be used by JDK based
clients.

Stuart

On Wed, May 4, 2016 at 7:55 PM, Nicklas Karlsson <nickarls at gmail.com> wrote:

>
> So this will be sort of REST with the exception of the state, transactions
> etc? ;-)
>
> (oops, previous post had wrong distribution)
>
> On Wed, May 4, 2016 at 8:50 AM, Stuart Douglas <stuart.w.douglas at gmail.com
> > wrote:
>
>> Hi everyone,
>>
>> I have started looking into support for service invocation over HTTP.
>> Unlike our existing HTTP upgrade support this will map EJB
>> requests/responses directly to HTTP requests and responses, which should
>> allow it to be used behind existing load balancers.
>>
>> I have started an initial description of the protocol at:
>> https://github.com/stuartwdouglas/wildfly-http-client/blob/master/docs/wire-spec-v1.asciidoc
>>
>> The intention is to follow HTTP semantics as closely as possible.
>> Clustering will be provided in a similar manner to web clustering (i.e. it
>> will require a load balancer, and work in a similar manner to web
>> clustering).
>>
>> There is still plenty work that needs to be done (especially around
>> security), so if anyone has any feedback let me know.
>>
>> Stuart
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
>
> --
> Nicklas Karlsson, +358 40 5062266
> Vaakunatie 10 as 7, 20780 Kaarina
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160504/c31bc304/attachment-0001.html 

From stuart.w.douglas at gmail.com  Wed May  4 06:42:49 2016
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Wed, 4 May 2016 20:42:49 +1000
Subject: [wildfly-dev] EJB over HTTP
In-Reply-To: <14fa16f0-e089-3979-2565-00412b0a1d6a@jboss.com>
References: <CAAoo=c5=Wa_vJVbad9Mb2K-n1U1Ue9pq_jM5J9m=i4YfLACVbw@mail.gmail.com>
	<14fa16f0-e089-3979-2565-00412b0a1d6a@jboss.com>
Message-ID: <CAAoo=c4K6VzxoxC_GV4dzt4ddg=NbqQSAGa1M2O=EHf3b8Yr9g@mail.gmail.com>

On Wed, May 4, 2016 at 7:47 PM, Darran Lofthouse <darran.lofthouse at jboss.com
> wrote:

> I wonder how much this should be integrated with the new client that David
> is currently working on, if the two were closely integrated it would make
> it much easier for clients to switch between the two as well as taking
> advantage of all of the new shared configuration.
>

This should be implemented as a transport provider for the HTTP Client, one
of the goals is to be able to use this in place of remoting basically
transparently (just a configuration change).


>
> Server side Elytron will have a full set of HTTP mechanisms so all the
> mechanisms you list will be available going forward.  Would this be used
> for server to server as well or just client to client?  We may end up with
> additional requirements that we already have for native calls regarding
> clients running with multiple identities and the propagation of identities
> from server to server.
>

It could be used for server -> server and client -> server. I think auth
should be based on existing HTTP mechanisms, but I am not sure if something
as simple as hooking up our existing HTTP mechanisms to this will meet all
the use cases.

Stuart


>
> Regards,
> Darran Lofthouse.
>
>
>
> On 04/05/16 06:50, Stuart Douglas wrote:
>
>> Hi everyone,
>>
>> I have started looking into support for service invocation over HTTP.
>> Unlike our existing HTTP upgrade support this will map EJB
>> requests/responses directly to HTTP requests and responses, which should
>> allow it to be used behind existing load balancers.
>>
>> I have started an initial description of the protocol at:
>>
>> https://github.com/stuartwdouglas/wildfly-http-client/blob/master/docs/wire-spec-v1.asciidoc
>>
>> The intention is to follow HTTP semantics as closely as possible.
>> Clustering will be provided in a similar manner to web clustering (i.e.
>> it will require a load balancer, and work in a similar manner to web
>> clustering).
>>
>> There is still plenty work that needs to be done (especially around
>> security), so if anyone has any feedback let me know.
>>
>> Stuart
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160504/a58db62b/attachment.html 

From darran.lofthouse at jboss.com  Wed May  4 07:14:29 2016
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Wed, 4 May 2016 12:14:29 +0100
Subject: [wildfly-dev] EJB over HTTP
In-Reply-To: <CAAoo=c4K6VzxoxC_GV4dzt4ddg=NbqQSAGa1M2O=EHf3b8Yr9g@mail.gmail.com>
References: <CAAoo=c5=Wa_vJVbad9Mb2K-n1U1Ue9pq_jM5J9m=i4YfLACVbw@mail.gmail.com>
	<14fa16f0-e089-3979-2565-00412b0a1d6a@jboss.com>
	<CAAoo=c4K6VzxoxC_GV4dzt4ddg=NbqQSAGa1M2O=EHf3b8Yr9g@mail.gmail.com>
Message-ID: <189ba829-1ae4-4864-d55c-193217ffdfcb@jboss.com>

On 04/05/16 11:42, Stuart Douglas wrote:
>
> On Wed, May 4, 2016 at 7:47 PM, Darran Lofthouse
> <darran.lofthouse at jboss.com <mailto:darran.lofthouse at jboss.com>> wrote:
>
>     I wonder how much this should be integrated with the new client that
>     David is currently working on, if the two were closely integrated it
>     would make it much easier for clients to switch between the two as
>     well as taking advantage of all of the new shared configuration.
>
> This should be implemented as a transport provider for the HTTP Client,
> one of the goals is to be able to use this in place of remoting
> basically transparently (just a configuration change).
>
>     Server side Elytron will have a full set of HTTP mechanisms so all
>     the mechanisms you list will be available going forward.  Would this
>     be used for server to server as well or just client to client?  We
>     may end up with additional requirements that we already have for
>     native calls regarding clients running with multiple identities and
>     the propagation of identities from server to server.
>
>
> It could be used for server -> server and client -> server. I think auth
> should be based on existing HTTP mechanisms, but I am not sure if
> something as simple as hooking up our existing HTTP mechanisms to this
> will meet all the use cases.

TBH it should be possible to secure a new context with either old or new 
- once new is used it will give us an established Elytron identity to 
inflow into the EJB container also backed by Elytron.  This will cover 
the same case we have for Remoting calls where we have an authenticated 
identity for the entry to the server and inflow this identity to the 
domain used to secure the EJB deployment.

The server to server case is probably going to be the most problematic 
though as that will have the same demands for identity propagation we 
are solving with the Remoting case.


>
> Stuart
>
>
>
>     Regards,
>     Darran Lofthouse.
>
>
>
>     On 04/05/16 06:50, Stuart Douglas wrote:
>
>         Hi everyone,
>
>         I have started looking into support for service invocation over
>         HTTP.
>         Unlike our existing HTTP upgrade support this will map EJB
>         requests/responses directly to HTTP requests and responses,
>         which should
>         allow it to be used behind existing load balancers.
>
>         I have started an initial description of the protocol at:
>         https://github.com/stuartwdouglas/wildfly-http-client/blob/master/docs/wire-spec-v1.asciidoc
>
>         The intention is to follow HTTP semantics as closely as possible.
>         Clustering will be provided in a similar manner to web
>         clustering (i.e.
>         it will require a load balancer, and work in a similar manner to web
>         clustering).
>
>         There is still plenty work that needs to be done (especially around
>         security), so if anyone has any feedback let me know.
>
>         Stuart
>
>
>

From sanne at hibernate.org  Wed May  4 07:49:18 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 4 May 2016 12:49:18 +0100
Subject: [wildfly-dev] Module aliases and deprecation
Message-ID: <CAFm4XO2Bn9J_ZsPLfOUco1x-N_zci6HGZWGwCBNh3WUB_-mDKA@mail.gmail.com>

Hello,

I'm renaming some modules intended for WildFly users. To minimize
impact on existing users, I'm including module-aliases using the old
name, to resolve to the new module ids.

Is there a way to mark such an alias as "deprecated" to encourage
people moving to the new naming scheme?

Thanks,
Sanne

From tomaz.cerar at gmail.com  Wed May  4 08:08:41 2016
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Wed, 4 May 2016 14:08:41 +0200
Subject: [wildfly-dev] Module aliases and deprecation
In-Reply-To: <CAFm4XO2Bn9J_ZsPLfOUco1x-N_zci6HGZWGwCBNh3WUB_-mDKA@mail.gmail.com>
References: <CAFm4XO2Bn9J_ZsPLfOUco1x-N_zci6HGZWGwCBNh3WUB_-mDKA@mail.gmail.com>
Message-ID: <CAMquZP4777edhiS0ULt4K0i8X8fET4Ym0FFYotTHBKZHjC7csg@mail.gmail.com>

add extra properties to module.xml

for deprecated

<properties>
    <property name="jboss.api" value="deprecated"/>
</properties>


should do it.


On Wed, May 4, 2016 at 1:49 PM, Sanne Grinovero <sanne at hibernate.org> wrote:

> Hello,
>
> I'm renaming some modules intended for WildFly users. To minimize
> impact on existing users, I'm including module-aliases using the old
> name, to resolve to the new module ids.
>
> Is there a way to mark such an alias as "deprecated" to encourage
> people moving to the new naming scheme?
>
> Thanks,
> Sanne
> _______________________________________________
> 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/20160504/379523aa/attachment.html 

From sanne at hibernate.org  Wed May  4 08:19:51 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 4 May 2016 13:19:51 +0100
Subject: [wildfly-dev] Module aliases and deprecation
In-Reply-To: <CAMquZP4777edhiS0ULt4K0i8X8fET4Ym0FFYotTHBKZHjC7csg@mail.gmail.com>
References: <CAFm4XO2Bn9J_ZsPLfOUco1x-N_zci6HGZWGwCBNh3WUB_-mDKA@mail.gmail.com>
	<CAMquZP4777edhiS0ULt4K0i8X8fET4Ym0FFYotTHBKZHjC7csg@mail.gmail.com>
Message-ID: <CAFm4XO27WQyYdsrjSanr9MyWZQutkCnfCrPt4fyq70ZhBTj+kw@mail.gmail.com>

Hi Tomaz,
the module is not deprecated: the module-alias is.

In other words, I wish to deprecate the "old name" only.

Thanks,
Sanne


On 4 May 2016 at 13:08, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
> add extra properties to module.xml
>
> for deprecated
>
> <properties>
>     <property name="jboss.api" value="deprecated"/>
> </properties>
>
>
> should do it.
>
>
> On Wed, May 4, 2016 at 1:49 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> Hello,
>>
>> I'm renaming some modules intended for WildFly users. To minimize
>> impact on existing users, I'm including module-aliases using the old
>> name, to resolve to the new module ids.
>>
>> Is there a way to mark such an alias as "deprecated" to encourage
>> people moving to the new naming scheme?
>>
>> Thanks,
>> Sanne
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>


From tomaz.cerar at gmail.com  Wed May  4 08:32:00 2016
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Wed, 4 May 2016 14:32:00 +0200
Subject: [wildfly-dev] Module aliases and deprecation
In-Reply-To: <CAFm4XO27WQyYdsrjSanr9MyWZQutkCnfCrPt4fyq70ZhBTj+kw@mail.gmail.com>
References: <CAFm4XO2Bn9J_ZsPLfOUco1x-N_zci6HGZWGwCBNh3WUB_-mDKA@mail.gmail.com>
	<CAMquZP4777edhiS0ULt4K0i8X8fET4Ym0FFYotTHBKZHjC7csg@mail.gmail.com>
	<CAFm4XO27WQyYdsrjSanr9MyWZQutkCnfCrPt4fyq70ZhBTj+kw@mail.gmail.com>
Message-ID: <CAMquZP7aLC_hGZXEL0+jprZMoX9QHFMTc1su3pXwLhU421roOQ@mail.gmail.com>

I understand that, so just add that property to alias module.

But I think that adding that metadata to alias will *not* result in WARN
message at boot time if anyone is using the module.
AFAIR doing ModuleLoader.loadModule(aliasModule)
will return the module to which alias is pointing to, as result we cannot
read metadata of the alias directly.
David can correct me about this.

On Wed, May 4, 2016 at 2:19 PM, Sanne Grinovero <sanne at hibernate.org> wrote:

> Hi Tomaz,
> the module is not deprecated: the module-alias is.
>
> In other words, I wish to deprecate the "old name" only.
>
> Thanks,
> Sanne
>
>
> On 4 May 2016 at 13:08, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
> > add extra properties to module.xml
> >
> > for deprecated
> >
> > <properties>
> >     <property name="jboss.api" value="deprecated"/>
> > </properties>
> >
> >
> > should do it.
> >
> >
> > On Wed, May 4, 2016 at 1:49 PM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
> >>
> >> Hello,
> >>
> >> I'm renaming some modules intended for WildFly users. To minimize
> >> impact on existing users, I'm including module-aliases using the old
> >> name, to resolve to the new module ids.
> >>
> >> Is there a way to mark such an alias as "deprecated" to encourage
> >> people moving to the new naming scheme?
> >>
> >> Thanks,
> >> Sanne
> >> _______________________________________________
> >> 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/20160504/bfa90bbd/attachment-0001.html 

From sanne at hibernate.org  Wed May  4 08:43:04 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 4 May 2016 13:43:04 +0100
Subject: [wildfly-dev] Module aliases and deprecation
In-Reply-To: <CAMquZP7aLC_hGZXEL0+jprZMoX9QHFMTc1su3pXwLhU421roOQ@mail.gmail.com>
References: <CAFm4XO2Bn9J_ZsPLfOUco1x-N_zci6HGZWGwCBNh3WUB_-mDKA@mail.gmail.com>
	<CAMquZP4777edhiS0ULt4K0i8X8fET4Ym0FFYotTHBKZHjC7csg@mail.gmail.com>
	<CAFm4XO27WQyYdsrjSanr9MyWZQutkCnfCrPt4fyq70ZhBTj+kw@mail.gmail.com>
	<CAMquZP7aLC_hGZXEL0+jprZMoX9QHFMTc1su3pXwLhU421roOQ@mail.gmail.com>
Message-ID: <CAFm4XO3gZxnCQXB653YiQkmmddpf4pbL-y3WYi0WtmLR5nn_LQ@mail.gmail.com>

On 4 May 2016 at 13:32, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
> I understand that, so just add that property to alias module.

Ok, I tried that but then it fails parsing the alias module.
Apparently the schema for a module-alias doesn't allow properties.

> But I think that adding that metadata to alias will *not* result in WARN
> message at boot time if anyone is using the module.
> AFAIR doing ModuleLoader.loadModule(aliasModule)
> will return the module to which alias is pointing to, as result we cannot
> read metadata of the alias directly.
> David can correct me about this.

Our need is only short lived, so no big deal to not have such a thing.

Although I would think others might need such a mechanism too?

Let me know if it's worth opening a feature request.

Thanks,
Sanne

>
> On Wed, May 4, 2016 at 2:19 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> Hi Tomaz,
>> the module is not deprecated: the module-alias is.
>>
>> In other words, I wish to deprecate the "old name" only.
>>
>> Thanks,
>> Sanne
>>
>>
>> On 4 May 2016 at 13:08, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
>> > add extra properties to module.xml
>> >
>> > for deprecated
>> >
>> > <properties>
>> >     <property name="jboss.api" value="deprecated"/>
>> > </properties>
>> >
>> >
>> > should do it.
>> >
>> >
>> > On Wed, May 4, 2016 at 1:49 PM, Sanne Grinovero <sanne at hibernate.org>
>> > wrote:
>> >>
>> >> Hello,
>> >>
>> >> I'm renaming some modules intended for WildFly users. To minimize
>> >> impact on existing users, I'm including module-aliases using the old
>> >> name, to resolve to the new module ids.
>> >>
>> >> Is there a way to mark such an alias as "deprecated" to encourage
>> >> people moving to the new naming scheme?
>> >>
>> >> Thanks,
>> >> Sanne
>> >> _______________________________________________
>> >> wildfly-dev mailing list
>> >> wildfly-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >
>> >
>
>


From david.lloyd at redhat.com  Wed May  4 08:44:49 2016
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Wed, 4 May 2016 07:44:49 -0500
Subject: [wildfly-dev] Module aliases and deprecation
In-Reply-To: <CAMquZP7aLC_hGZXEL0+jprZMoX9QHFMTc1su3pXwLhU421roOQ@mail.gmail.com>
References: <CAFm4XO2Bn9J_ZsPLfOUco1x-N_zci6HGZWGwCBNh3WUB_-mDKA@mail.gmail.com>
	<CAMquZP4777edhiS0ULt4K0i8X8fET4Ym0FFYotTHBKZHjC7csg@mail.gmail.com>
	<CAFm4XO27WQyYdsrjSanr9MyWZQutkCnfCrPt4fyq70ZhBTj+kw@mail.gmail.com>
	<CAMquZP7aLC_hGZXEL0+jprZMoX9QHFMTc1su3pXwLhU421roOQ@mail.gmail.com>
Message-ID: <5729EEC1.2010505@redhat.com>

You can't add properties to alias modules IIRC.

If you want to have deprecated/unsupported/etc. for a module, then 
instead of an alias, create an empty module with the old name that 
imports and re-exports the desired target module.  Then put the 
properties on this empty module.

On 05/04/2016 07:32 AM, Toma? Cerar wrote:
> I understand that, so just add that property to alias module.
>
> But I think that adding that metadata to alias will *not* result in WARN
> message at boot time if anyone is using the module.
> AFAIR doing ModuleLoader.loadModule(aliasModule)
> will return the module to which alias is pointing to, as result we
> cannot read metadata of the alias directly.
> David can correct me about this.
>
> On Wed, May 4, 2016 at 2:19 PM, Sanne Grinovero <sanne at hibernate.org
> <mailto:sanne at hibernate.org>> wrote:
>
>     Hi Tomaz,
>     the module is not deprecated: the module-alias is.
>
>     In other words, I wish to deprecate the "old name" only.
>
>     Thanks,
>     Sanne
>
>
>     On 4 May 2016 at 13:08, Toma? Cerar <tomaz.cerar at gmail.com
>     <mailto:tomaz.cerar at gmail.com>> wrote:
>     > add extra properties to module.xml
>     >
>     > for deprecated
>     >
>     > <properties>
>     >     <property name="jboss.api" value="deprecated"/>
>     > </properties>
>     >
>     >
>     > should do it.
>     >
>     >
>     > On Wed, May 4, 2016 at 1:49 PM, Sanne Grinovero <sanne at hibernate.org <mailto:sanne at hibernate.org>> wrote:
>     >>
>     >> Hello,
>     >>
>     >> I'm renaming some modules intended for WildFly users. To minimize
>     >> impact on existing users, I'm including module-aliases using the old
>     >> name, to resolve to the new module ids.
>     >>
>     >> Is there a way to mark such an alias as "deprecated" to encourage
>     >> people moving to the new naming scheme?
>     >>
>     >> Thanks,
>     >> Sanne
>     >> _______________________________________________
>     >> wildfly-dev mailing list
>     >>wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     >>https://lists.jboss.org/mailman/listinfo/wildfly-dev
>     >
>     >
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

-- 
- DML

From david.lloyd at redhat.com  Wed May  4 09:03:45 2016
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Wed, 4 May 2016 08:03:45 -0500
Subject: [wildfly-dev] EJB over HTTP
In-Reply-To: <CAAoo=c7nwpzt_Px0PerB5MPd3csRmAOhWvT+J31TboxPEw=7ww@mail.gmail.com>
References: <CAAoo=c5=Wa_vJVbad9Mb2K-n1U1Ue9pq_jM5J9m=i4YfLACVbw@mail.gmail.com>
	<CAMquZP5hpVxdtXKObJb0bLwDjH3Op7Ea9gPwBbcG3GMJGJ1zRg@mail.gmail.com>
	<CAAoo=c7nwpzt_Px0PerB5MPd3csRmAOhWvT+J31TboxPEw=7ww@mail.gmail.com>
Message-ID: <5729F331.5050203@redhat.com>

Getting transactions and SFSB to share a load-balancing behavior will 
hopefully be possible though.  I guess it'll require some thought to 
make it easy to avoid situations where (for example) two SFSB are spread 
to different nodes and then you try to create a UserTransaction which 
includes both.

On 05/04/2016 05:36 AM, Stuart Douglas wrote:
> The purpose is to enable load balancer based clustering to work.
> Basically even though there is no underlying web session the JSESSIONID
> cookie will make sure that the load balancer delivers the request to the
> correct backend server.
>
> Basically existing load balancers already support sticky sessions, and
> we are just piggy backing on that, as the primary customer use case for
> this is allowing EJB calls through a HTTP load balancer.
>
> Stuart
>
> On Wed, May 4, 2016 at 7:56 PM, Toma? Cerar <tomaz.cerar at gmail.com
> <mailto:tomaz.cerar at gmail.com>> wrote:
>
>     One thing that seems somewhat odd to me is the usage of JSESSIONID
>     for tracking session state.
>     That cookie/param is used for servlet http sessions and given that
>     this is pure EJB without any servlets
>     it would be bit confusing to require it. Or will this rely on
>     session tracking from undertow-servlet?
>
>     --
>     tomaz
>
>     On Wed, May 4, 2016 at 7:50 AM, Stuart Douglas
>     <stuart.w.douglas at gmail.com <mailto:stuart.w.douglas at gmail.com>> wrote:
>
>         Hi everyone,
>
>         I have started looking into support for service invocation over
>         HTTP. Unlike our existing HTTP upgrade support this will map EJB
>         requests/responses directly to HTTP requests and responses,
>         which should allow it to be used behind existing load balancers.
>
>         I have started an initial description of the protocol at:
>         https://github.com/stuartwdouglas/wildfly-http-client/blob/master/docs/wire-spec-v1.asciidoc
>
>         The intention is to follow HTTP semantics as closely as
>         possible. Clustering will be provided in a similar manner to web
>         clustering (i.e. it will require a load balancer, and work in a
>         similar manner to web clustering).
>
>         There is still plenty work that needs to be done (especially
>         around security), so if anyone has any feedback let me know.
>
>         Stuart
>
>
>
>         _______________________________________________
>         wildfly-dev mailing list
>         wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

-- 
- DML

From david.lloyd at redhat.com  Wed May  4 09:11:05 2016
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Wed, 4 May 2016 08:11:05 -0500
Subject: [wildfly-dev] EJB over HTTP
In-Reply-To: <CAAoo=c5=Wa_vJVbad9Mb2K-n1U1Ue9pq_jM5J9m=i4YfLACVbw@mail.gmail.com>
References: <CAAoo=c5=Wa_vJVbad9Mb2K-n1U1Ue9pq_jM5J9m=i4YfLACVbw@mail.gmail.com>
Message-ID: <5729F4E9.70900@redhat.com>

On 05/04/2016 12:50 AM, Stuart Douglas wrote:
> Hi everyone,
>
> I have started looking into support for service invocation over HTTP.
> Unlike our existing HTTP upgrade support this will map EJB
> requests/responses directly to HTTP requests and responses, which should
> allow it to be used behind existing load balancers.
>
> I have started an initial description of the protocol at:
> https://github.com/stuartwdouglas/wildfly-http-client/blob/master/docs/wire-spec-v1.asciidoc
>
> The intention is to follow HTTP semantics as closely as possible.
> Clustering will be provided in a similar manner to web clustering (i.e.
> it will require a load balancer, and work in a similar manner to web
> clustering).
>
> There is still plenty work that needs to be done (especially around
> security), so if anyone has any feedback let me know.

One thing I was thinking was that we could possibly support multiple 
marshalling strategies in the future by way of content-type, since that 
header has a useful negotiation strategy already defined.

It could even be done using the defined types e.g. 
application/x-ejb-invocation;version=2;m=protobuf or whatever. 
Something to think about for the future...
-- 
- DML

From stuart.w.douglas at gmail.com  Wed May  4 09:12:10 2016
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Wed, 4 May 2016 23:12:10 +1000
Subject: [wildfly-dev] EJB over HTTP
In-Reply-To: <5729F331.5050203@redhat.com>
References: <CAAoo=c5=Wa_vJVbad9Mb2K-n1U1Ue9pq_jM5J9m=i4YfLACVbw@mail.gmail.com>
	<CAMquZP5hpVxdtXKObJb0bLwDjH3Op7Ea9gPwBbcG3GMJGJ1zRg@mail.gmail.com>
	<CAAoo=c7nwpzt_Px0PerB5MPd3csRmAOhWvT+J31TboxPEw=7ww@mail.gmail.com>
	<5729F331.5050203@redhat.com>
Message-ID: <CAAoo=c69+SzZiMqu2_K08BJRyDkrf=N_wPvwr7LCHMbg2BAMTg@mail.gmail.com>

On Wed, May 4, 2016 at 11:03 PM, David M. Lloyd <david.lloyd at redhat.com>
wrote:

> Getting transactions and SFSB to share a load-balancing behavior will
> hopefully be possible though.  I guess it'll require some thought to
> make it easy to avoid situations where (for example) two SFSB are spread
> to different nodes and then you try to create a UserTransaction which
> includes both.
>

Once you start using a SFSB or a Transaction you should get a session
cookie, which should give you affinity to the relevant node (based on the
assumption the load balancer supports sticky sessions).

Stuart


>
> On 05/04/2016 05:36 AM, Stuart Douglas wrote:
> > The purpose is to enable load balancer based clustering to work.
> > Basically even though there is no underlying web session the JSESSIONID
> > cookie will make sure that the load balancer delivers the request to the
> > correct backend server.
> >
> > Basically existing load balancers already support sticky sessions, and
> > we are just piggy backing on that, as the primary customer use case for
> > this is allowing EJB calls through a HTTP load balancer.
> >
> > Stuart
> >
> > On Wed, May 4, 2016 at 7:56 PM, Toma? Cerar <tomaz.cerar at gmail.com
> > <mailto:tomaz.cerar at gmail.com>> wrote:
> >
> >     One thing that seems somewhat odd to me is the usage of JSESSIONID
> >     for tracking session state.
> >     That cookie/param is used for servlet http sessions and given that
> >     this is pure EJB without any servlets
> >     it would be bit confusing to require it. Or will this rely on
> >     session tracking from undertow-servlet?
> >
> >     --
> >     tomaz
> >
> >     On Wed, May 4, 2016 at 7:50 AM, Stuart Douglas
> >     <stuart.w.douglas at gmail.com <mailto:stuart.w.douglas at gmail.com>>
> wrote:
> >
> >         Hi everyone,
> >
> >         I have started looking into support for service invocation over
> >         HTTP. Unlike our existing HTTP upgrade support this will map EJB
> >         requests/responses directly to HTTP requests and responses,
> >         which should allow it to be used behind existing load balancers.
> >
> >         I have started an initial description of the protocol at:
> >
> https://github.com/stuartwdouglas/wildfly-http-client/blob/master/docs/wire-spec-v1.asciidoc
> >
> >         The intention is to follow HTTP semantics as closely as
> >         possible. Clustering will be provided in a similar manner to web
> >         clustering (i.e. it will require a load balancer, and work in a
> >         similar manner to web clustering).
> >
> >         There is still plenty work that needs to be done (especially
> >         around security), so if anyone has any feedback let me know.
> >
> >         Stuart
> >
> >
> >
> >         _______________________________________________
> >         wildfly-dev mailing list
> >         wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
> >         https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> >
> >
> >
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
>
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160504/500169a6/attachment-0001.html 

From david.lloyd at redhat.com  Wed May  4 09:15:52 2016
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Wed, 4 May 2016 08:15:52 -0500
Subject: [wildfly-dev] EJB over HTTP
In-Reply-To: <CAAoo=c69+SzZiMqu2_K08BJRyDkrf=N_wPvwr7LCHMbg2BAMTg@mail.gmail.com>
References: <CAAoo=c5=Wa_vJVbad9Mb2K-n1U1Ue9pq_jM5J9m=i4YfLACVbw@mail.gmail.com>
	<CAMquZP5hpVxdtXKObJb0bLwDjH3Op7Ea9gPwBbcG3GMJGJ1zRg@mail.gmail.com>
	<CAAoo=c7nwpzt_Px0PerB5MPd3csRmAOhWvT+J31TboxPEw=7ww@mail.gmail.com>
	<5729F331.5050203@redhat.com>
	<CAAoo=c69+SzZiMqu2_K08BJRyDkrf=N_wPvwr7LCHMbg2BAMTg@mail.gmail.com>
Message-ID: <5729F608.3030001@redhat.com>

On 05/04/2016 08:12 AM, Stuart Douglas wrote:
>
>
> On Wed, May 4, 2016 at 11:03 PM, David M. Lloyd <david.lloyd at redhat.com
> <mailto:david.lloyd at redhat.com>> wrote:
>
>     Getting transactions and SFSB to share a load-balancing behavior will
>     hopefully be possible though.  I guess it'll require some thought to
>     make it easy to avoid situations where (for example) two SFSB are spread
>     to different nodes and then you try to create a UserTransaction which
>     includes both.
>
>
> Once you start using a SFSB or a Transaction you should get a session
> cookie, which should give you affinity to the relevant node (based on
> the assumption the load balancer supports sticky sessions).

Yeah I was just thinking though: does that ID apply to all future 
invocations across all EJBs pointing at the node URL, or just EJB 
invocations on that SFSB/transaction for its lifetime?  It seems like 
you are suggesting that all invocations then get that session ID (which 
is probably OK, I just like to play devil's advocate whenever possible).

Also, there is an edge case where separate threads create SFSBs 
simultaneously which we'd want to ensure works as expected, in either case.

>
> Stuart
>
>
>     On 05/04/2016 05:36 AM, Stuart Douglas wrote:
>     > The purpose is to enable load balancer based clustering to work.
>     > Basically even though there is no underlying web session the JSESSIONID
>     > cookie will make sure that the load balancer delivers the request to the
>     > correct backend server.
>     >
>     > Basically existing load balancers already support sticky sessions, and
>     > we are just piggy backing on that, as the primary customer use case for
>     > this is allowing EJB calls through a HTTP load balancer.
>     >
>     > Stuart
>     >
>     > On Wed, May 4, 2016 at 7:56 PM, Toma? Cerar <tomaz.cerar at gmail.com <mailto:tomaz.cerar at gmail.com>
>     > <mailto:tomaz.cerar at gmail.com <mailto:tomaz.cerar at gmail.com>>> wrote:
>     >
>     >     One thing that seems somewhat odd to me is the usage of JSESSIONID
>     >     for tracking session state.
>     >     That cookie/param is used for servlet http sessions and given that
>     >     this is pure EJB without any servlets
>     >     it would be bit confusing to require it. Or will this rely on
>     >     session tracking from undertow-servlet?
>     >
>     >     --
>     >     tomaz
>     >
>     >     On Wed, May 4, 2016 at 7:50 AM, Stuart Douglas
>     >     <stuart.w.douglas at gmail.com <mailto:stuart.w.douglas at gmail.com>
>     <mailto:stuart.w.douglas at gmail.com
>     <mailto:stuart.w.douglas at gmail.com>>> wrote:
>     >
>     >         Hi everyone,
>     >
>     >         I have started looking into support for service invocation over
>     >         HTTP. Unlike our existing HTTP upgrade support this will map EJB
>     >         requests/responses directly to HTTP requests and responses,
>     >         which should allow it to be used behind existing load balancers.
>     >
>     >         I have started an initial description of the protocol at:
>     >https://github.com/stuartwdouglas/wildfly-http-client/blob/master/docs/wire-spec-v1.asciidoc
>     >
>     >         The intention is to follow HTTP semantics as closely as
>     >         possible. Clustering will be provided in a similar manner to web
>     >         clustering (i.e. it will require a load balancer, and work in a
>     >         similar manner to web clustering).
>     >
>     >         There is still plenty work that needs to be done (especially
>     >         around security), so if anyone has any feedback let me know.
>     >
>     >         Stuart
>     >
>     >
>     >
>     >         _______________________________________________
>     >         wildfly-dev mailing list
>     >wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     <mailto:wildfly-dev at lists.jboss.org
>     <mailto:wildfly-dev at lists.jboss.org>>
>     >https://lists.jboss.org/mailman/listinfo/wildfly-dev
>     >
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > wildfly-dev mailing list
>     >wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     >https://lists.jboss.org/mailman/listinfo/wildfly-dev
>     >
>
>     --
>     - DML
>     _______________________________________________
>     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
>
>

-- 
- DML

From david.lloyd at redhat.com  Wed May  4 10:11:06 2016
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Wed, 4 May 2016 09:11:06 -0500
Subject: [wildfly-dev] EJB over HTTP
In-Reply-To: <CAAoo=c5=Wa_vJVbad9Mb2K-n1U1Ue9pq_jM5J9m=i4YfLACVbw@mail.gmail.com>
References: <CAAoo=c5=Wa_vJVbad9Mb2K-n1U1Ue9pq_jM5J9m=i4YfLACVbw@mail.gmail.com>
Message-ID: <572A02FA.30006@redhat.com>

On 05/04/2016 12:50 AM, Stuart Douglas wrote:
> Hi everyone,
>
> I have started looking into support for service invocation over HTTP.
> Unlike our existing HTTP upgrade support this will map EJB
> requests/responses directly to HTTP requests and responses, which should
> allow it to be used behind existing load balancers.
>
> I have started an initial description of the protocol at:
> https://github.com/stuartwdouglas/wildfly-http-client/blob/master/docs/wire-spec-v1.asciidoc
>
> The intention is to follow HTTP semantics as closely as possible.
> Clustering will be provided in a similar manner to web clustering (i.e.
> it will require a load balancer, and work in a similar manner to web
> clustering).
>
> There is still plenty work that needs to be done (especially around
> security), so if anyone has any feedback let me know.

One thing I noticed is that you went a different way with async 
invocations and cancellation support.

The way I originally proposed was that the request/response works as per 
normal, but a 1xx header is used to send the client a cancellation token 
which can be POSTed back to the server to cancel the invocation.  I 
understand that this approach requires 1xx support which some clients 
might not have.

In your proposal, the async EJB request always returns immediately and 
uses an invocation ID which can later be retrieved.  I rejected this 
approach because it requires the server to maintain state outside of the 
request - something that is sure to fail.  Also the client doesn't 
really have any notion as to when it can GET the response: it would have 
to do it more or less immediately to avoid a late response (or when 
Future.get() is called), meaning you need two round trips in the common 
case, which is not so good.

I think that the best compromise solution is to treat async invocations 
identically to regular invocations, and instead let the *client* give a 
cancellation ID to the server, which it can later POST to the server as 
I described in my original document.  If the server receives the 
client's ID (maybe also matching the client's IP address) then the 
request can be canceled if it is still running.

Failing this I still prefer the 1xx approach where the server gives a 
cancellation ID at the beginning of the request, as this avoids problems 
where the server has to maintain large object state for indefinite 
amounts of time.  Either of these two options means only one server 
round trip for async invocation, and no server-side caching of responses.

-- 
- DML

From jason.greene at redhat.com  Wed May  4 13:30:13 2016
From: jason.greene at redhat.com (Jason Greene)
Date: Wed, 4 May 2016 12:30:13 -0500
Subject: [wildfly-dev] EJB over HTTP
In-Reply-To: <5729F4E9.70900@redhat.com>
References: <CAAoo=c5=Wa_vJVbad9Mb2K-n1U1Ue9pq_jM5J9m=i4YfLACVbw@mail.gmail.com>
	<5729F4E9.70900@redhat.com>
Message-ID: <8A53144A-E4C3-4634-9ED4-55A8B080B8FC@redhat.com>


> On May 4, 2016, at 8:11 AM, David M. Lloyd <david.lloyd at redhat.com> wrote:
> 
> On 05/04/2016 12:50 AM, Stuart Douglas wrote:
>> Hi everyone,
>> 
>> I have started looking into support for service invocation over HTTP.
>> Unlike our existing HTTP upgrade support this will map EJB
>> requests/responses directly to HTTP requests and responses, which should
>> allow it to be used behind existing load balancers.
>> 
>> I have started an initial description of the protocol at:
>> https://github.com/stuartwdouglas/wildfly-http-client/blob/master/docs/wire-spec-v1.asciidoc
>> 
>> The intention is to follow HTTP semantics as closely as possible.
>> Clustering will be provided in a similar manner to web clustering (i.e.
>> it will require a load balancer, and work in a similar manner to web
>> clustering).
>> 
>> There is still plenty work that needs to be done (especially around
>> security), so if anyone has any feedback let me know.
> 
> One thing I was thinking was that we could possibly support multiple 
> marshalling strategies in the future by way of content-type, since that 
> header has a useful negotiation strategy already defined.
> 
> It could even be done using the defined types e.g. 
> application/x-ejb-invocation;version=2;m=protobuf or whatever. 
> Something to think about for the future?

I think pluggable encoding types is essential. IMO I think we should aim for protobufs and marshaling for the first impl. While this isn?t intended as a JAX-RS replacement, we should allow for the possibility of non Java clients to directly trigger EJB invocations. 

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



From jason.greene at redhat.com  Wed May  4 13:51:41 2016
From: jason.greene at redhat.com (Jason Greene)
Date: Wed, 4 May 2016 12:51:41 -0500
Subject: [wildfly-dev] EJB over HTTP
In-Reply-To: <572A02FA.30006@redhat.com>
References: <CAAoo=c5=Wa_vJVbad9Mb2K-n1U1Ue9pq_jM5J9m=i4YfLACVbw@mail.gmail.com>
	<572A02FA.30006@redhat.com>
Message-ID: <E18DB6F4-4415-434C-989B-6978CECB5E32@redhat.com>


> On May 4, 2016, at 9:11 AM, David M. Lloyd <david.lloyd at redhat.com> wrote:
> 
> One thing I noticed is that you went a different way with async 
> invocations and cancellation support.
> 
> The way I originally proposed was that the request/response works as per 
> normal, but a 1xx header is used to send the client a cancellation token 
> which can be POSTed back to the server to cancel the invocation.  I 
> understand that this approach requires 1xx support which some clients 
> might not have.
> 
> In your proposal, the async EJB request always returns immediately and 
> uses an invocation ID which can later be retrieved.  I rejected this 
> approach because it requires the server to maintain state outside of the 
> request - something that is sure to fail.

I don?t think this is too big of a deal, I mean you just have a data structure with a built-in automated expiration mechanism. However, it does have a negative in the its naturally racy, which I guess is your concern?

>  Also the client doesn't 
> really have any notion as to when it can GET the response: it would have 
> to do it more or less immediately to avoid a late response (or when 
> Future.get() is called), meaning you need two round trips in the common 
> case, which is not so good.

Yeah I think a key aspect of this is the client has to be able to say it wants blocking behavior, even if the server side is mapped asynchronously.

> 
> I think that the best compromise solution is to treat async invocations 
> identically to regular invocations, and instead let the *client* give a 
> cancellation ID to the server, which it can later POST to the server as 
> I described in my original document.  If the server receives the 
> client's ID (maybe also matching the client's IP address) then the 
> request can be canceled if it is still running.

I think thats a reasonable way to do it, provided the ID is sufficiently unique to not be repeated. Actually with HTTP 2, we could just hang-up the stream for cancellation, as the stream-id is an effective invocation id. However, it?s perhaps best to keep consistent semantics between h1 and h2.

I think a key question, which I don?t have the answer for, is if we need to support more concurrent long-running invocations than connections(h1)/streams(h2). If the answer is yes then long polling is bad. I am also slightly worried about HTTP intermediaries imposing timeouts for long running operations.

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



From david.lloyd at redhat.com  Wed May  4 14:12:17 2016
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Wed, 4 May 2016 13:12:17 -0500
Subject: [wildfly-dev] EJB over HTTP
In-Reply-To: <E18DB6F4-4415-434C-989B-6978CECB5E32@redhat.com>
References: <CAAoo=c5=Wa_vJVbad9Mb2K-n1U1Ue9pq_jM5J9m=i4YfLACVbw@mail.gmail.com>
	<572A02FA.30006@redhat.com>
	<E18DB6F4-4415-434C-989B-6978CECB5E32@redhat.com>
Message-ID: <572A3B81.2030208@redhat.com>

On 05/04/2016 12:51 PM, Jason Greene wrote:
>
>> On May 4, 2016, at 9:11 AM, David M. Lloyd <david.lloyd at redhat.com> wrote:
>>
>> One thing I noticed is that you went a different way with async
>> invocations and cancellation support.
>>
>> The way I originally proposed was that the request/response works as per
>> normal, but a 1xx header is used to send the client a cancellation token
>> which can be POSTed back to the server to cancel the invocation.  I
>> understand that this approach requires 1xx support which some clients
>> might not have.
>>
>> In your proposal, the async EJB request always returns immediately and
>> uses an invocation ID which can later be retrieved.  I rejected this
>> approach because it requires the server to maintain state outside of the
>> request - something that is sure to fail.
>
> I don?t think this is too big of a deal, I mean you just have a data structure with a built-in automated expiration mechanism. However, it does have a negative in the its naturally racy, which I guess is your concern?

I know it's "just" have a data structure, but it's overhead and 
complexity that the server doesn't need and shouldn't have, and it's one 
more knob for users to screw around with to trade off between memory 
usage and error behavior.  I'd prefer any approach that doesn't have 
state maintained by a timeout and can never fail due to misconfiguration 
of the server, and has deterministic cleanup properties.

Cancellation is always naturally racy but both of my proposals also 
address this: cancellation is idempotent and unrecognized IDs are 
ignored.  The cancellation result is sent back on the original request: 
it either receives a 200 or 204 indicating success (with or without a 
response body), or it receives a 408 indicating that the request was 
cancelled cleanly.  The client can ping the server with cancellation 
POSTs as much as it wants without mucking up the state of the 
invocation, prior cancel requests, or future cancel requests.

>>   Also the client doesn't
>> really have any notion as to when it can GET the response: it would have
>> to do it more or less immediately to avoid a late response (or when
>> Future.get() is called), meaning you need two round trips in the common
>> case, which is not so good.
>
> Yeah I think a key aspect of this is the client has to be able to say it wants blocking behavior, even if the server side is mapped asynchronously.

I think this misses the complete picture, see below.

>>
>> I think that the best compromise solution is to treat async invocations
>> identically to regular invocations, and instead let the *client* give a
>> cancellation ID to the server, which it can later POST to the server as
>> I described in my original document.  If the server receives the
>> client's ID (maybe also matching the client's IP address) then the
>> request can be canceled if it is still running.
>
> I think thats a reasonable way to do it, provided the ID is sufficiently unique to not be repeated. Actually with HTTP 2, we could just hang-up the stream for cancellation, as the stream-id is an effective invocation id. However, it?s perhaps best to keep consistent semantics between h1 and h2.
>
> I think a key question, which I don?t have the answer for, is if we need to support more concurrent long-running invocations than connections(h1)/streams(h2). If the answer is yes then long polling is bad. I am also slightly worried about HTTP intermediaries imposing timeouts for long running operations.

To me this is a configuration concern: the same issues arise for 
REST-ish things.  It's not really long polling per se (which usually 
corresponds to using potentially infinitely long connections to 
accommodate asynchronous requests or messages from server to client, 
something we do not do), just a (possibly) long request (but no longer 
than any typical REST request on a potentially slow resource).  We don't 
want or need a special one-off solution to this (general, long-standing) 
issue in the context of EJB; any solution to this problem should be 
general to all long requests.

The point of my proposals are that there is absolutely no need to 
conflate the HTTP request lifecycle with EJB asynchronous invocation 
semantics, and in fact doing so is actively harmful.  All EJB request 
types - sync and async - have a request and reply and conceptually could 
be cancellable (even in the sync case the client may invoke 
asynchronously or be cancelled), except for one-way invocations which 
would immediately return a 202 status anyway.  The only difference is in 
whether the client thread directly waits for the response or whether it 
waits via a Future, which the client can independently determine based 
on information it already has locally.  By the time the invocation gets 
to the transport provider, the asynchronicity of the request has lost 
its relevance; the transport provider is merely responsible for 
conveyance of the request and response and possibly the cancel request 
message.

So really this is just about how we handle cancellation, and 
cancellation is not a common case so we should optimize for requests 
which aren't cancelled, which means one HTTP request and response per 
EJB invocation with cancellation being somehow out-of-band.

-- 
- DML

From smarlow at redhat.com  Wed May  4 14:16:31 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 4 May 2016 14:16:31 -0400
Subject: [wildfly-dev] update on WildFly NoSQL prototype integration...
Message-ID: <bf184686-ccbb-f6bf-3ce5-db00cb54bf6c@redhat.com>

Hi,

Below is an update on the WildFly NoSQL integration project.  The goal 
is for deployed applications to have access to NoSQL databases (via 
Hibernate OGM or native APIs).  Items 1-4, should be finished in our 
first pass, with as much of the others items as we can do as well.

1. connection management will deal with obtaining NoSQL connections for 
application use.

  - borrow/share Hibernate OGM connection configuration setup code
  - authentication integration
  - support transport level security

2. CDI programming simplifications will make it easy to inject NoSQL 
data into your application classes.

  - https://github.com/antoinesd/javaee-nosql is initial idea

3. You will easily get a native NoSQL connection from the specified 
NoSQL profile and use the native NOSQL (Cassandra/MongoDB/other) API in 
your application.

4. You will also be able to easily use Hibernate OGM with the defined 
NoSQL profiles (exactly how is TBD but will be awesome :-).
  - Hibernate OGM static module is included.
  - need to align with OGM dependencies (e.g. Hibernate ORM + other 
dependencies).
  - as mentioned above, OGM already has some connection setup code, 
which might be good to share for WildFly + standalone NoSQL use.
  - once WildFly has a common NoSQLSource (not a DataSource) that OGM 
can use, OGM will be enhanced to use it.

5. How best for the WildFly NoSQL subsystem to be optional?
  - Is it enough to not run the wildfly/testsuite/nosql tests by default?
  - Or do we need to start a separate https://github.com/wildfly/nosql 
project for the NoSQL subsystems?

6. transaction enlistment

7. compensating transactions

8. runtime application monitoring

9. How soon can we make an evaluation distribution available for use on 
OpenStack/OpenShift?
  - Would be great if we could do some load testing with all NoSQL 
components.
  - Would be great if we could enable others to also test.

10. Are there any problems with our WildFly NoSQL subsystem injecting 
MongoDatabase connections via:

    @Resource(lookup = "java:jboss/mongodb/test") MongoDatabase db;

  - No @Resource support expected for standalone Java, TBD is whether a 
runtime library can be used.
  - Any problems expected on other EE application servers if this 
approach becomes popular?

11. WIP topic branch is at 
https://github.com/scottmarlow/wildfly/tree/nosql-dev9.  Note that every 
once in a while, commits are squashed and pushed to nosql-devN+1.

12. Add proper unit tests
  - multi-threaded NoSQL access to show that works at all.
  - use NoSQL from different EE components (e.g. JAX-RS).
  - other use cases that represent how NoSQL could be used from WildFly.

Feedback/help is welcome!

Thanks,
Scott

From jason.greene at redhat.com  Wed May  4 14:40:17 2016
From: jason.greene at redhat.com (Jason Greene)
Date: Wed, 4 May 2016 13:40:17 -0500
Subject: [wildfly-dev] EJB over HTTP
In-Reply-To: <572A3B81.2030208@redhat.com>
References: <CAAoo=c5=Wa_vJVbad9Mb2K-n1U1Ue9pq_jM5J9m=i4YfLACVbw@mail.gmail.com>
	<572A02FA.30006@redhat.com>
	<E18DB6F4-4415-434C-989B-6978CECB5E32@redhat.com>
	<572A3B81.2030208@redhat.com>
Message-ID: <AC5C032E-C37E-4DCE-9FD1-5C9D766EF3FC@redhat.com>


> On May 4, 2016, at 1:12 PM, David M. Lloyd <david.lloyd at redhat.com> wrote:
> 
> On 05/04/2016 12:51 PM, Jason Greene wrote:
> 
> To me this is a configuration concern: the same issues arise for 
> REST-ish things.  It's not really long polling per se (which usually 
> corresponds to using potentially infinitely long connections to 
> accommodate asynchronous requests or messages from server to client, 
> something we do not do), just a (possibly) long request (but no longer 
> than any typical REST request on a potentially slow resource).  We don't 
> want or need a special one-off solution to this (general, long-standing) 
> issue in the context of EJB; any solution to this problem should be 
> general to all long requests.
> 
> The point of my proposals are that there is absolutely no need to 
> conflate the HTTP request lifecycle with EJB asynchronous invocation 
> semantics, and in fact doing so is actively harmful.  All EJB request 
> types - sync and async - have a request and reply and conceptually could 
> be cancellable (even in the sync case the client may invoke 
> asynchronously or be cancelled), except for one-way invocations which 
> would immediately return a 202 status anyway.  The only difference is in 
> whether the client thread directly waits for the response or whether it 
> waits via a Future, which the client can independently determine based 
> on information it already has locally.  By the time the invocation gets 
> to the transport provider, the asynchronicity of the request has lost 
> its relevance; the transport provider is merely responsible for 
> conveyance of the request and response and possibly the cancel request 
> message.
> 
> So really this is just about how we handle cancellation, and 
> cancellation is not a common case so we should optimize for requests 
> which aren't cancelled, which means one HTTP request and response per 
> EJB invocation with cancellation being somehow out-of-band.

I agree with you on this last point here for sure, with the added note that there are arguably better ways to handle long running tasks than an async ejb method invocation.

That said there are certainly some interesting benefits to handling long running invocations without holding a connection open. For example, if you have a transient connection (like say a mobile network), you gain the benefit of never losing the response. However, the necessity to limit resource overhead likely means a transient connection will be unable to retrieve the response anyway, so again we are back to their are better ways to handle long running tasks than an async ejb invocation.

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



From stuart.w.douglas at gmail.com  Wed May  4 18:42:08 2016
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Thu, 5 May 2016 08:42:08 +1000
Subject: [wildfly-dev] EJB over HTTP
In-Reply-To: <5729F608.3030001@redhat.com>
References: <CAAoo=c5=Wa_vJVbad9Mb2K-n1U1Ue9pq_jM5J9m=i4YfLACVbw@mail.gmail.com>
	<CAMquZP5hpVxdtXKObJb0bLwDjH3Op7Ea9gPwBbcG3GMJGJ1zRg@mail.gmail.com>
	<CAAoo=c7nwpzt_Px0PerB5MPd3csRmAOhWvT+J31TboxPEw=7ww@mail.gmail.com>
	<5729F331.5050203@redhat.com>
	<CAAoo=c69+SzZiMqu2_K08BJRyDkrf=N_wPvwr7LCHMbg2BAMTg@mail.gmail.com>
	<5729F608.3030001@redhat.com>
Message-ID: <CAAoo=c5N52VkUK6T=XCquiRMDpdJXm89=HWKBM_0mhm59-yhNg@mail.gmail.com>

On Wed, May 4, 2016 at 11:15 PM, David M. Lloyd <david.lloyd at redhat.com>
wrote:

> On 05/04/2016 08:12 AM, Stuart Douglas wrote:
> >
> >
> > On Wed, May 4, 2016 at 11:03 PM, David M. Lloyd <david.lloyd at redhat.com
> > <mailto:david.lloyd at redhat.com>> wrote:
> >
> >     Getting transactions and SFSB to share a load-balancing behavior will
> >     hopefully be possible though.  I guess it'll require some thought to
> >     make it easy to avoid situations where (for example) two SFSB are
> spread
> >     to different nodes and then you try to create a UserTransaction which
> >     includes both.
> >
> >
> > Once you start using a SFSB or a Transaction you should get a session
> > cookie, which should give you affinity to the relevant node (based on
> > the assumption the load balancer supports sticky sessions).
>
> Yeah I was just thinking though: does that ID apply to all future
> invocations across all EJBs pointing at the node URL, or just EJB
> invocations on that SFSB/transaction for its lifetime?  It seems like
> you are suggesting that all invocations then get that session ID (which
> is probably OK, I just like to play devil's advocate whenever possible).
>

I am not 100% sure the best way to handle it. When a transaction or SFSB
session is open this makes sense, although once all sessions/transactions
has been closed there is no real reason to keep using the same session id
(at the moment there is no real way for the client to know that a SFSB is
gone though, maybe we need a response header to let a client know a
specified session is no longer valid).


>
> Also, there is an edge case where separate threads create SFSBs
> simultaneously which we'd want to ensure works as expected, in either case.
>

Yes, it should be possible to make this work as expected.

Stuart


>
> >
> > Stuart
> >
> >
> >     On 05/04/2016 05:36 AM, Stuart Douglas wrote:
> >     > The purpose is to enable load balancer based clustering to work.
> >     > Basically even though there is no underlying web session the
> JSESSIONID
> >     > cookie will make sure that the load balancer delivers the request
> to the
> >     > correct backend server.
> >     >
> >     > Basically existing load balancers already support sticky sessions,
> and
> >     > we are just piggy backing on that, as the primary customer use
> case for
> >     > this is allowing EJB calls through a HTTP load balancer.
> >     >
> >     > Stuart
> >     >
> >     > On Wed, May 4, 2016 at 7:56 PM, Toma? Cerar <tomaz.cerar at gmail.com
> <mailto:tomaz.cerar at gmail.com>
> >     > <mailto:tomaz.cerar at gmail.com <mailto:tomaz.cerar at gmail.com>>>
> wrote:
> >     >
> >     >     One thing that seems somewhat odd to me is the usage of
> JSESSIONID
> >     >     for tracking session state.
> >     >     That cookie/param is used for servlet http sessions and given
> that
> >     >     this is pure EJB without any servlets
> >     >     it would be bit confusing to require it. Or will this rely on
> >     >     session tracking from undertow-servlet?
> >     >
> >     >     --
> >     >     tomaz
> >     >
> >     >     On Wed, May 4, 2016 at 7:50 AM, Stuart Douglas
> >     >     <stuart.w.douglas at gmail.com <mailto:stuart.w.douglas at gmail.com
> >
> >     <mailto:stuart.w.douglas at gmail.com
> >     <mailto:stuart.w.douglas at gmail.com>>> wrote:
> >     >
> >     >         Hi everyone,
> >     >
> >     >         I have started looking into support for service invocation
> over
> >     >         HTTP. Unlike our existing HTTP upgrade support this will
> map EJB
> >     >         requests/responses directly to HTTP requests and responses,
> >     >         which should allow it to be used behind existing load
> balancers.
> >     >
> >     >         I have started an initial description of the protocol at:
> >     >
> https://github.com/stuartwdouglas/wildfly-http-client/blob/master/docs/wire-spec-v1.asciidoc
> >     >
> >     >         The intention is to follow HTTP semantics as closely as
> >     >         possible. Clustering will be provided in a similar manner
> to web
> >     >         clustering (i.e. it will require a load balancer, and work
> in a
> >     >         similar manner to web clustering).
> >     >
> >     >         There is still plenty work that needs to be done
> (especially
> >     >         around security), so if anyone has any feedback let me
> know.
> >     >
> >     >         Stuart
> >     >
> >     >
> >     >
> >     >         _______________________________________________
> >     >         wildfly-dev mailing list
> >     >wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
> >     <mailto:wildfly-dev at lists.jboss.org
> >     <mailto:wildfly-dev at lists.jboss.org>>
> >     >https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >     >
> >     >
> >     >
> >     >
> >     >
> >     > _______________________________________________
> >     > wildfly-dev mailing list
> >     >wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
> >     >https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >     >
> >
> >     --
> >     - DML
> >     _______________________________________________
> >     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
> >
> >
>
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160505/99b43b46/attachment.html 

From stuart.w.douglas at gmail.com  Wed May  4 18:55:23 2016
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Thu, 5 May 2016 08:55:23 +1000
Subject: [wildfly-dev] EJB over HTTP
In-Reply-To: <572A02FA.30006@redhat.com>
References: <CAAoo=c5=Wa_vJVbad9Mb2K-n1U1Ue9pq_jM5J9m=i4YfLACVbw@mail.gmail.com>
	<572A02FA.30006@redhat.com>
Message-ID: <CAAoo=c45NRi-S4DfwMjZ1+TSoKf+8gHh=xqG1KsVB4p=QRRbsg@mail.gmail.com>

There are two problems with client generated ID's, and the main one is that
you can't guarantee that the cancellation message will go to the same
server as the original invocation. With my current design the initial
request will send back a JSESSIONID that allows the cancel request to be
targeted at the correct server (of course if we already have affinity then
this is not a problem, but we can't guarantee that).

The other problem is that there is no easy way to guarantee there will not
be conflicts, although I guess you could send back a 409 and force the
client to retry with a new cancellation id if a conflict happens. You can't
really tie this to IP because it may be behind a load balancer, and
something like a GUID may be expensive to generate for every invocation.

With the 1xx approach I am worried that not all load balancers/proxies will
properly support it. As this is not really used outside of 'Expect:
100-continue' I would be surprised if this works correctly without
problems, even though it is valid according to the spec.

Another potentially yucky way to do this would be to have the client use
chunked encoding and keep the request open, allowing it to send some kind
of cancellation token at any time. This feels really hacky though.

Basically all the options suck, the one I put in the doc was that one that
I thought sucked the least when dealing with load balancers.

Stuart

On Thu, May 5, 2016 at 12:11 AM, David M. Lloyd <david.lloyd at redhat.com>
wrote:

> On 05/04/2016 12:50 AM, Stuart Douglas wrote:
> > Hi everyone,
> >
> > I have started looking into support for service invocation over HTTP.
> > Unlike our existing HTTP upgrade support this will map EJB
> > requests/responses directly to HTTP requests and responses, which should
> > allow it to be used behind existing load balancers.
> >
> > I have started an initial description of the protocol at:
> >
> https://github.com/stuartwdouglas/wildfly-http-client/blob/master/docs/wire-spec-v1.asciidoc
> >
> > The intention is to follow HTTP semantics as closely as possible.
> > Clustering will be provided in a similar manner to web clustering (i.e.
> > it will require a load balancer, and work in a similar manner to web
> > clustering).
> >
> > There is still plenty work that needs to be done (especially around
> > security), so if anyone has any feedback let me know.
>
> One thing I noticed is that you went a different way with async
> invocations and cancellation support.
>
> The way I originally proposed was that the request/response works as per
> normal, but a 1xx header is used to send the client a cancellation token
> which can be POSTed back to the server to cancel the invocation.  I
> understand that this approach requires 1xx support which some clients
> might not have.
>
> In your proposal, the async EJB request always returns immediately and
> uses an invocation ID which can later be retrieved.  I rejected this
> approach because it requires the server to maintain state outside of the
> request - something that is sure to fail.  Also the client doesn't
> really have any notion as to when it can GET the response: it would have
> to do it more or less immediately to avoid a late response (or when
> Future.get() is called), meaning you need two round trips in the common
> case, which is not so good.
>
> I think that the best compromise solution is to treat async invocations
> identically to regular invocations, and instead let the *client* give a
> cancellation ID to the server, which it can later POST to the server as
> I described in my original document.  If the server receives the
> client's ID (maybe also matching the client's IP address) then the
> request can be canceled if it is still running.
>
> Failing this I still prefer the 1xx approach where the server gives a
> cancellation ID at the beginning of the request, as this avoids problems
> where the server has to maintain large object state for indefinite
> amounts of time.  Either of these two options means only one server
> round trip for async invocation, and no server-side caching of responses.
>
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160505/7976be2a/attachment-0001.html 

From stuart.w.douglas at gmail.com  Wed May  4 20:03:00 2016
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Thu, 5 May 2016 10:03:00 +1000
Subject: [wildfly-dev] EJB over HTTP
In-Reply-To: <CAAoo=c45NRi-S4DfwMjZ1+TSoKf+8gHh=xqG1KsVB4p=QRRbsg@mail.gmail.com>
References: <CAAoo=c5=Wa_vJVbad9Mb2K-n1U1Ue9pq_jM5J9m=i4YfLACVbw@mail.gmail.com>
	<572A02FA.30006@redhat.com>
	<CAAoo=c45NRi-S4DfwMjZ1+TSoKf+8gHh=xqG1KsVB4p=QRRbsg@mail.gmail.com>
Message-ID: <CAAoo=c6S896gERuTGaSv7hwDqT9A=isCHP1N5n8ay0rfJ6tgCA@mail.gmail.com>

On Thu, May 5, 2016 at 8:55 AM, Stuart Douglas <stuart.w.douglas at gmail.com>
wrote:

> There are two problems with client generated ID's, and the main one is
> that you can't guarantee that the cancellation message will go to the same
> server as the original invocation. With my current design the initial
> request will send back a JSESSIONID that allows the cancel request to be
> targeted at the correct server (of course if we already have affinity then
> this is not a problem, but we can't guarantee that).
>
> The other problem is that there is no easy way to guarantee there will not
> be conflicts, although I guess you could send back a 409 and force the
> client to retry with a new cancellation id if a conflict happens. You can't
> really tie this to IP because it may be behind a load balancer, and
> something like a GUID may be expensive to generate for every invocation.
>

I just thought of a way to get around this. If we require the use of an
existing JSESSIONID for cancellable invocations both these problems are
resolved. The sticky session makes sure the correct node is targeted, and
the server can use the session id + invocation id as a unique key.

The only overhead of this is that we could need some kind of 'affinity'
request message that has no other purpose than generating a session id if
the client does not already have one (although this would only need to be
executed once).

Stuart



>
> With the 1xx approach I am worried that not all load balancers/proxies
> will properly support it. As this is not really used outside of 'Expect:
> 100-continue' I would be surprised if this works correctly without
> problems, even though it is valid according to the spec.
>
> Another potentially yucky way to do this would be to have the client use
> chunked encoding and keep the request open, allowing it to send some kind
> of cancellation token at any time. This feels really hacky though.
>
> Basically all the options suck, the one I put in the doc was that one that
> I thought sucked the least when dealing with load balancers.
>
> Stuart
>
> On Thu, May 5, 2016 at 12:11 AM, David M. Lloyd <david.lloyd at redhat.com>
> wrote:
>
>> On 05/04/2016 12:50 AM, Stuart Douglas wrote:
>> > Hi everyone,
>> >
>> > I have started looking into support for service invocation over HTTP.
>> > Unlike our existing HTTP upgrade support this will map EJB
>> > requests/responses directly to HTTP requests and responses, which should
>> > allow it to be used behind existing load balancers.
>> >
>> > I have started an initial description of the protocol at:
>> >
>> https://github.com/stuartwdouglas/wildfly-http-client/blob/master/docs/wire-spec-v1.asciidoc
>> >
>> > The intention is to follow HTTP semantics as closely as possible.
>> > Clustering will be provided in a similar manner to web clustering (i.e.
>> > it will require a load balancer, and work in a similar manner to web
>> > clustering).
>> >
>> > There is still plenty work that needs to be done (especially around
>> > security), so if anyone has any feedback let me know.
>>
>> One thing I noticed is that you went a different way with async
>> invocations and cancellation support.
>>
>> The way I originally proposed was that the request/response works as per
>> normal, but a 1xx header is used to send the client a cancellation token
>> which can be POSTed back to the server to cancel the invocation.  I
>> understand that this approach requires 1xx support which some clients
>> might not have.
>>
>> In your proposal, the async EJB request always returns immediately and
>> uses an invocation ID which can later be retrieved.  I rejected this
>> approach because it requires the server to maintain state outside of the
>> request - something that is sure to fail.  Also the client doesn't
>> really have any notion as to when it can GET the response: it would have
>> to do it more or less immediately to avoid a late response (or when
>> Future.get() is called), meaning you need two round trips in the common
>> case, which is not so good.
>>
>> I think that the best compromise solution is to treat async invocations
>> identically to regular invocations, and instead let the *client* give a
>> cancellation ID to the server, which it can later POST to the server as
>> I described in my original document.  If the server receives the
>> client's ID (maybe also matching the client's IP address) then the
>> request can be canceled if it is still running.
>>
>> Failing this I still prefer the 1xx approach where the server gives a
>> cancellation ID at the beginning of the request, as this avoids problems
>> where the server has to maintain large object state for indefinite
>> amounts of time.  Either of these two options means only one server
>> round trip for async invocation, and no server-side caching of responses.
>>
>> --
>> - DML
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160505/70861f74/attachment.html 

From stuart.w.douglas at gmail.com  Wed May  4 22:59:33 2016
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Thu, 5 May 2016 12:59:33 +1000
Subject: [wildfly-dev] EJB over HTTP
In-Reply-To: <CAAoo=c6S896gERuTGaSv7hwDqT9A=isCHP1N5n8ay0rfJ6tgCA@mail.gmail.com>
References: <CAAoo=c5=Wa_vJVbad9Mb2K-n1U1Ue9pq_jM5J9m=i4YfLACVbw@mail.gmail.com>
	<572A02FA.30006@redhat.com>
	<CAAoo=c45NRi-S4DfwMjZ1+TSoKf+8gHh=xqG1KsVB4p=QRRbsg@mail.gmail.com>
	<CAAoo=c6S896gERuTGaSv7hwDqT9A=isCHP1N5n8ay0rfJ6tgCA@mail.gmail.com>
Message-ID: <CAAoo=c4VpomvhNjXFb5j90kfMBkj_3UFqkxK4XJeUK-PKnW_KA@mail.gmail.com>

I have updated the spec doc to now use client side generated id that is
paired with a session cookie to ensure uniqueness and node affinity.

If the client does not already have a session id it can request one with an
affinity message.

Stuart

On Thu, May 5, 2016 at 10:03 AM, Stuart Douglas <stuart.w.douglas at gmail.com>
wrote:

>
>
> On Thu, May 5, 2016 at 8:55 AM, Stuart Douglas <stuart.w.douglas at gmail.com
> > wrote:
>
>> There are two problems with client generated ID's, and the main one is
>> that you can't guarantee that the cancellation message will go to the same
>> server as the original invocation. With my current design the initial
>> request will send back a JSESSIONID that allows the cancel request to be
>> targeted at the correct server (of course if we already have affinity then
>> this is not a problem, but we can't guarantee that).
>>
>> The other problem is that there is no easy way to guarantee there will
>> not be conflicts, although I guess you could send back a 409 and force the
>> client to retry with a new cancellation id if a conflict happens. You can't
>> really tie this to IP because it may be behind a load balancer, and
>> something like a GUID may be expensive to generate for every invocation.
>>
>
> I just thought of a way to get around this. If we require the use of an
> existing JSESSIONID for cancellable invocations both these problems are
> resolved. The sticky session makes sure the correct node is targeted, and
> the server can use the session id + invocation id as a unique key.
>
> The only overhead of this is that we could need some kind of 'affinity'
> request message that has no other purpose than generating a session id if
> the client does not already have one (although this would only need to be
> executed once).
>
> Stuart
>
>
>
>>
>> With the 1xx approach I am worried that not all load balancers/proxies
>> will properly support it. As this is not really used outside of 'Expect:
>> 100-continue' I would be surprised if this works correctly without
>> problems, even though it is valid according to the spec.
>>
>> Another potentially yucky way to do this would be to have the client use
>> chunked encoding and keep the request open, allowing it to send some kind
>> of cancellation token at any time. This feels really hacky though.
>>
>> Basically all the options suck, the one I put in the doc was that one
>> that I thought sucked the least when dealing with load balancers.
>>
>> Stuart
>>
>> On Thu, May 5, 2016 at 12:11 AM, David M. Lloyd <david.lloyd at redhat.com>
>> wrote:
>>
>>> On 05/04/2016 12:50 AM, Stuart Douglas wrote:
>>> > Hi everyone,
>>> >
>>> > I have started looking into support for service invocation over HTTP.
>>> > Unlike our existing HTTP upgrade support this will map EJB
>>> > requests/responses directly to HTTP requests and responses, which
>>> should
>>> > allow it to be used behind existing load balancers.
>>> >
>>> > I have started an initial description of the protocol at:
>>> >
>>> https://github.com/stuartwdouglas/wildfly-http-client/blob/master/docs/wire-spec-v1.asciidoc
>>> >
>>> > The intention is to follow HTTP semantics as closely as possible.
>>> > Clustering will be provided in a similar manner to web clustering (i.e.
>>> > it will require a load balancer, and work in a similar manner to web
>>> > clustering).
>>> >
>>> > There is still plenty work that needs to be done (especially around
>>> > security), so if anyone has any feedback let me know.
>>>
>>> One thing I noticed is that you went a different way with async
>>> invocations and cancellation support.
>>>
>>> The way I originally proposed was that the request/response works as per
>>> normal, but a 1xx header is used to send the client a cancellation token
>>> which can be POSTed back to the server to cancel the invocation.  I
>>> understand that this approach requires 1xx support which some clients
>>> might not have.
>>>
>>> In your proposal, the async EJB request always returns immediately and
>>> uses an invocation ID which can later be retrieved.  I rejected this
>>> approach because it requires the server to maintain state outside of the
>>> request - something that is sure to fail.  Also the client doesn't
>>> really have any notion as to when it can GET the response: it would have
>>> to do it more or less immediately to avoid a late response (or when
>>> Future.get() is called), meaning you need two round trips in the common
>>> case, which is not so good.
>>>
>>> I think that the best compromise solution is to treat async invocations
>>> identically to regular invocations, and instead let the *client* give a
>>> cancellation ID to the server, which it can later POST to the server as
>>> I described in my original document.  If the server receives the
>>> client's ID (maybe also matching the client's IP address) then the
>>> request can be canceled if it is still running.
>>>
>>> Failing this I still prefer the 1xx approach where the server gives a
>>> cancellation ID at the beginning of the request, as this avoids problems
>>> where the server has to maintain large object state for indefinite
>>> amounts of time.  Either of these two options means only one server
>>> round trip for async invocation, and no server-side caching of responses.
>>>
>>> --
>>> - DML
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160505/f9629557/attachment-0001.html 

From david.lloyd at redhat.com  Thu May  5 08:50:18 2016
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Thu, 5 May 2016 07:50:18 -0500
Subject: [wildfly-dev] EJB over HTTP
In-Reply-To: <CAAoo=c4VpomvhNjXFb5j90kfMBkj_3UFqkxK4XJeUK-PKnW_KA@mail.gmail.com>
References: <CAAoo=c5=Wa_vJVbad9Mb2K-n1U1Ue9pq_jM5J9m=i4YfLACVbw@mail.gmail.com>
	<572A02FA.30006@redhat.com>
	<CAAoo=c45NRi-S4DfwMjZ1+TSoKf+8gHh=xqG1KsVB4p=QRRbsg@mail.gmail.com>
	<CAAoo=c6S896gERuTGaSv7hwDqT9A=isCHP1N5n8ay0rfJ6tgCA@mail.gmail.com>
	<CAAoo=c4VpomvhNjXFb5j90kfMBkj_3UFqkxK4XJeUK-PKnW_KA@mail.gmail.com>
Message-ID: <572B418A.2090707@redhat.com>

I think this is a good idea.  Allowing the user to acquire a session ID 
could also allow for session-based authentication mechanisms to 
function.  And it could be optional, in the event that a user wants to 
(for example) rapid-fire stateless or one-way requests to a large number 
of balanced nodes.  It could also be expanded to cover the 
transaction/SFSB case we discussed, in that creation or acquisition of 
these things would reuse or create a new ID based on whether one was 
provided.

On 05/04/2016 09:59 PM, Stuart Douglas wrote:
> I have updated the spec doc to now use client side generated id that is
> paired with a session cookie to ensure uniqueness and node affinity.
>
> If the client does not already have a session id it can request one with
> an affinity message.
>
> Stuart
>
> On Thu, May 5, 2016 at 10:03 AM, Stuart Douglas
> <stuart.w.douglas at gmail.com <mailto:stuart.w.douglas at gmail.com>> wrote:
>
>
>
>     On Thu, May 5, 2016 at 8:55 AM, Stuart Douglas
>     <stuart.w.douglas at gmail.com <mailto:stuart.w.douglas at gmail.com>> wrote:
>
>         There are two problems with client generated ID's, and the main
>         one is that you can't guarantee that the cancellation message
>         will go to the same server as the original invocation. With my
>         current design the initial request will send back a JSESSIONID
>         that allows the cancel request to be targeted at the correct
>         server (of course if we already have affinity then this is not a
>         problem, but we can't guarantee that).
>
>         The other problem is that there is no easy way to guarantee
>         there will not be conflicts, although I guess you could send
>         back a 409 and force the client to retry with a new cancellation
>         id if a conflict happens. You can't really tie this to IP
>         because it may be behind a load balancer, and something like a
>         GUID may be expensive to generate for every invocation.
>
>
>     I just thought of a way to get around this. If we require the use of
>     an existing JSESSIONID for cancellable invocations both these
>     problems are resolved. The sticky session makes sure the correct
>     node is targeted, and the server can use the session id + invocation
>     id as a unique key.
>
>     The only overhead of this is that we could need some kind of
>     'affinity' request message that has no other purpose than generating
>     a session id if the client does not already have one (although this
>     would only need to be executed once).
>
>     Stuart
>
>
>         With the 1xx approach I am worried that not all load
>         balancers/proxies will properly support it. As this is not
>         really used outside of 'Expect: 100-continue' I would be
>         surprised if this works correctly without problems, even though
>         it is valid according to the spec.
>
>         Another potentially yucky way to do this would be to have the
>         client use chunked encoding and keep the request open, allowing
>         it to send some kind of cancellation token at any time. This
>         feels really hacky though.
>
>         Basically all the options suck, the one I put in the doc was
>         that one that I thought sucked the least when dealing with load
>         balancers.
>
>         Stuart
>
>         On Thu, May 5, 2016 at 12:11 AM, David M. Lloyd
>         <david.lloyd at redhat.com <mailto:david.lloyd at redhat.com>> wrote:
>
>             On 05/04/2016 12:50 AM, Stuart Douglas wrote:
>             > Hi everyone,
>             >
>             > I have started looking into support for service invocation over HTTP.
>             > Unlike our existing HTTP upgrade support this will map EJB
>             > requests/responses directly to HTTP requests and responses, which should
>             > allow it to be used behind existing load balancers.
>             >
>             > I have started an initial description of the protocol at:
>             >https://github.com/stuartwdouglas/wildfly-http-client/blob/master/docs/wire-spec-v1.asciidoc
>             >
>             > The intention is to follow HTTP semantics as closely as possible.
>             > Clustering will be provided in a similar manner to web clustering (i.e.
>             > it will require a load balancer, and work in a similar manner to web
>             > clustering).
>             >
>             > There is still plenty work that needs to be done (especially around
>             > security), so if anyone has any feedback let me know.
>
>             One thing I noticed is that you went a different way with async
>             invocations and cancellation support.
>
>             The way I originally proposed was that the request/response
>             works as per
>             normal, but a 1xx header is used to send the client a
>             cancellation token
>             which can be POSTed back to the server to cancel the
>             invocation.  I
>             understand that this approach requires 1xx support which
>             some clients
>             might not have.
>
>             In your proposal, the async EJB request always returns
>             immediately and
>             uses an invocation ID which can later be retrieved.  I
>             rejected this
>             approach because it requires the server to maintain state
>             outside of the
>             request - something that is sure to fail.  Also the client
>             doesn't
>             really have any notion as to when it can GET the response:
>             it would have
>             to do it more or less immediately to avoid a late response
>             (or when
>             Future.get() is called), meaning you need two round trips in
>             the common
>             case, which is not so good.
>
>             I think that the best compromise solution is to treat async
>             invocations
>             identically to regular invocations, and instead let the
>             *client* give a
>             cancellation ID to the server, which it can later POST to
>             the server as
>             I described in my original document.  If the server receives the
>             client's ID (maybe also matching the client's IP address)
>             then the
>             request can be canceled if it is still running.
>
>             Failing this I still prefer the 1xx approach where the
>             server gives a
>             cancellation ID at the beginning of the request, as this
>             avoids problems
>             where the server has to maintain large object state for
>             indefinite
>             amounts of time.  Either of these two options means only one
>             server
>             round trip for async invocation, and no server-side caching
>             of responses.
>
>             --
>             - DML
>             _______________________________________________
>             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
>
>
>
>

-- 
- DML

From jesper.pedersen at redhat.com  Thu May  5 13:48:12 2016
From: jesper.pedersen at redhat.com (Jesper Pedersen)
Date: Thu, 5 May 2016 13:48:12 -0400
Subject: [wildfly-dev] update on WildFly NoSQL prototype integration...
In-Reply-To: <bf184686-ccbb-f6bf-3ce5-db00cb54bf6c@redhat.com>
References: <bf184686-ccbb-f6bf-3ce5-db00cb54bf6c@redhat.com>
Message-ID: <572B875C.20903@redhat.com>

Hi,

On 05/04/2016 02:16 PM, Scott Marlow wrote:
> Below is an update on the WildFly NoSQL integration project.  The goal
> is for deployed applications to have access to NoSQL databases (via
> Hibernate OGM or native APIs).  Items 1-4, should be finished in our
> first pass, with as much of the others items as we can do as well.
>

Some general comments:

- Good start :)
- Maybe refactor from org.jboss.as to org.wildfly
- I think you can leave out the "subsystem" part of the package name
- Maybe use version identifiers in the package name since NoSQL APIs 
change a lot
- Add some additional asserts to the test cases to verify input / output 
from the stores

> 1. connection management will deal with obtaining NoSQL connections for
> application use.
>
>    - borrow/share Hibernate OGM connection configuration setup code
>    - authentication integration
>    - support transport level security
>

Connection management is a huge area to tackle. I think it is best to 
start with what each NoSQL implementation offer.

The big question is if the connections should be truly managed which 
would give the option to no-op dangerous API calls out. There aren't any 
spec requirements for this, so it is really a matter of how the APIs 
should be presented.

You may have to proxy some of the classes in order to pass the security 
information into the stores. I think people would expect to use WildFly 
security domains for this (SubjectFactory/Subject).

> 2. CDI programming simplifications will make it easy to inject NoSQL
> data into your application classes.
>
>    - https://github.com/antoinesd/javaee-nosql is initial idea
>
> 3. You will easily get a native NoSQL connection from the specified
> NoSQL profile and use the native NOSQL (Cassandra/MongoDB/other) API in
> your application.
>

I think this is key, as the APIs change almost per release.

> 4. You will also be able to easily use Hibernate OGM with the defined
> NoSQL profiles (exactly how is TBD but will be awesome :-).
>    - Hibernate OGM static module is included.
>    - need to align with OGM dependencies (e.g. Hibernate ORM + other
> dependencies).
>    - as mentioned above, OGM already has some connection setup code,
> which might be good to share for WildFly + standalone NoSQL use.
>    - once WildFly has a common NoSQLSource (not a DataSource) that OGM
> can use, OGM will be enhanced to use it.
>
> 5. How best for the WildFly NoSQL subsystem to be optional?
>    - Is it enough to not run the wildfly/testsuite/nosql tests by default?
>    - Or do we need to start a separate https://github.com/wildfly/nosql
> project for the NoSQL subsystems?
>
> 6. transaction enlistment
>

This will vary for each store, and there are many loopholes that you may 
want to plug, f.ex. sharing a connection between 2 transactions.

For 1-phase, you will have to insert a LocalXAResource instance into the 
transaction when the "connection" is obtained, and return it on the 
boundary (afterCompletion). Same deal for 2-phase basically.

The LocalXAResource implementation will of course be different for each 
store.

You may want a transaction option for the stores that supports this such 
that people can choose the "level" of enlistment (ala jta="false").

One task I see is that people will have access to the transactional 
methods in the API, and you don't want them to call these methods in 
their apps unless the transaction setting allows this.

I think you can leave out the corner-cases in the 1st iteration, like 
deferred enlistment (get connection, start transaction).

> 7. compensating transactions
>

Another huge area.

I would let the use-cases from WildFly/Swarm drive this.

A simple way to start is to have a SPI that apps can implement in case 
the transaction is MARKED_FOR_ROLLBACK (hooks to an enlisted XAResource).

> 8. runtime application monitoring
>

As each store is different I would only look into what the subsystem can 
expose, plus whatever the store can display.

> 9. How soon can we make an evaluation distribution available for use on
> OpenStack/OpenShift?
>    - Would be great if we could do some load testing with all NoSQL
> components.
>    - Would be great if we could enable others to also test.
>
> 10. Are there any problems with our WildFly NoSQL subsystem injecting
> MongoDatabase connections via:
>
>      @Resource(lookup = "java:jboss/mongodb/test") MongoDatabase db;
>
>    - No @Resource support expected for standalone Java, TBD is whether a
> runtime library can be used.
>    - Any problems expected on other EE application servers if this
> approach becomes popular?
>

This ties into connection management. I like what you have now for the 
1st pass.

> 11. WIP topic branch is at
> https://github.com/scottmarlow/wildfly/tree/nosql-dev9.  Note that every
> once in a while, commits are squashed and pushed to nosql-devN+1.
>
> 12. Add proper unit tests
>    - multi-threaded NoSQL access to show that works at all.
>    - use NoSQL from different EE components (e.g. JAX-RS).
>    - other use cases that represent how NoSQL could be used from WildFly.
>

I think you can look at test cases for EE components that support @Resource.

Best regards,
  Jesper


From tomaz.cerar at gmail.com  Thu May  5 18:42:20 2016
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Fri, 6 May 2016 00:42:20 +0200
Subject: [wildfly-dev] update on WildFly NoSQL prototype integration...
In-Reply-To: <572B875C.20903@redhat.com>
References: <bf184686-ccbb-f6bf-3ce5-db00cb54bf6c@redhat.com>
	<572B875C.20903@redhat.com>
Message-ID: <CAMquZP7jvfWCH_nn5xv=_6NXThVUKUP+OaB3Fc+Bc9bg9puRqw@mail.gmail.com>

On Thu, May 5, 2016 at 7:48 PM, Jesper Pedersen <jesper.pedersen at redhat.com>
wrote:

> - Maybe refactor from org.jboss.as to org.wildfly
> - I think you can leave out the "subsystem" part of the package name
>

not really, proper name of would be org.wildfly.extension.name-of-extension
for more see https://developer.jboss.org/wiki/WildFlyNamingPolicy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160506/5d75a030/attachment.html 

From smaestri at redhat.com  Tue May 10 05:26:32 2016
From: smaestri at redhat.com (Stefano Maestri)
Date: Tue, 10 May 2016 11:26:32 +0200
Subject: [wildfly-dev] update on WildFly NoSQL prototype integration...
In-Reply-To: <572B875C.20903@redhat.com>
References: <bf184686-ccbb-f6bf-3ce5-db00cb54bf6c@redhat.com>
	<572B875C.20903@redhat.com>
Message-ID: <CAMrRDdwWQecKAd+9g+syeFqzDkF=ECuGy6nqqfAzG0gUJra_WA@mail.gmail.com>

On Thu, May 5, 2016 at 7:48 PM, Jesper Pedersen <jesper.pedersen at redhat.com>
 wrote:

> Hi,
>
> On 05/04/2016 02:16 PM, Scott Marlow wrote:
> > Below is an update on the WildFly NoSQL integration project.  The goal
> > is for deployed applications to have access to NoSQL databases (via
> > Hibernate OGM or native APIs).  Items 1-4, should be finished in our
> > first pass, with as much of the others items as we can do as well.
> >
>
> Some general comments:
>
> - Good start :)
> - Maybe refactor from org.jboss.as to org.wildfly
>

+1


> - Maybe use version identifiers in the package name since NoSQL APIs
> change a lot
>

Well even if it is different we had bad experience on this w/ IJ and
removed those version identifier from package name. I think package name
should not have version ids, even if it could be acceptable in this first
phase we should try to hide this kind of infos to users of OURS API even if
APIs from NoSQL impl would be dependents from specific release.


> - Add some additional asserts to the test cases to verify input / output
> from the stores
>
> > 1. connection management will deal with obtaining NoSQL connections for
> > application use.
> >
> >    - borrow/share Hibernate OGM connection configuration setup code
> >    - authentication integration
> >    - support transport level security
> >
>
> Connection management is a huge area to tackle. I think it is best to
> start with what each NoSQL implementation offer.
>

Yup it would be a good start, even if the other question is "why a user
should use WF integration instead of direct use of various
implementation?". One of the possible answer could be "to have a common
connection management" for sure. So the (final) effort should be to have a
common connection management.


>
> The big question is if the connections should be truly managed which
> would give the option to no-op dangerous API calls out. There aren't any
> spec requirements for this, so it is really a matter of how the APIs
> should be presented.
>

Yup exactly.


>
> You may have to proxy some of the classes in order to pass the security
> information into the stores. I think people would expect to use WildFly
> security domains for this (SubjectFactory/Subject).
>

Yes it's another possible question to "why use WF integration?"


>
> > 2. CDI programming simplifications will make it easy to inject NoSQL
> > data into your application classes.
> >
> >    - https://github.com/antoinesd/javaee-nosql is initial idea
> >
> > 3. You will easily get a native NoSQL connection from the specified
> > NoSQL profile and use the native NOSQL (Cassandra/MongoDB/other) API in
> > your application.
> >
>
> I think this is key, as the APIs change almost per release.
>

Agree 100%. And it gives us also another requirement: should be easily to
upgrade this Wildfly subsystem (or at least underlying NoSQL
implementations) because NoSQL users would expect to use latest "cool"
features of their NoSQL impl and don't want to wait for WildFLy (or EAP)
release cycle.



>
> > 4. You will also be able to easily use Hibernate OGM with the defined
> > NoSQL profiles (exactly how is TBD but will be awesome :-).
> >    - Hibernate OGM static module is included.
> >    - need to align with OGM dependencies (e.g. Hibernate ORM + other
> > dependencies).
> >    - as mentioned above, OGM already has some connection setup code,
> > which might be good to share for WildFly + standalone NoSQL use.
> >    - once WildFly has a common NoSQLSource (not a DataSource) that OGM
> > can use, OGM will be enhanced to use it.
> >
> > 5. How best for the WildFly NoSQL subsystem to be optional?
> >    - Is it enough to not run the wildfly/testsuite/nosql tests by
> default?
> >    - Or do we need to start a separate https://github.com/wildfly/nosql
> > project for the NoSQL subsystems?
> >
> > 6. transaction enlistment
> >
>
> This will vary for each store, and there are many loopholes that you may
> want to plug, f.ex. sharing a connection between 2 transactions.
>
> For 1-phase, you will have to insert a LocalXAResource instance into the
> transaction when the "connection" is obtained, and return it on the
> boundary (afterCompletion). Same deal for 2-phase basically.
>
> The LocalXAResource implementation will of course be different for each
> store.
>
> You may want a transaction option for the stores that supports this such
> that people can choose the "level" of enlistment (ala jta="false").
>
> One task I see is that people will have access to the transactional
> methods in the API, and you don't want them to call these methods in
> their apps unless the transaction setting allows this.
>
> I think you can leave out the corner-cases in the 1st iteration, like
> deferred enlistment (get connection, start transaction).
>
> > 7. compensating transactions
> >
>
> Another huge area.
>
> I would let the use-cases from WildFly/Swarm drive this.
>
> A simple way to start is to have a SPI that apps can implement in case
> the transaction is MARKED_FOR_ROLLBACK (hooks to an enlisted XAResource).
>

We implemented those in IJ (even if in much more standard JCA environment),
and maybe we could share and eventually copy/paste some code.



>
> > 8. runtime application monitoring
> >
>
> As each store is different I would only look into what the subsystem can
> expose, plus whatever the store can display.
>

Maybe a plugin approach could be taken as we did for datasource and RA
subsystems reading statistics available during deployment and runtime and
exposing them as pure runtime metrics in DMR.

Just my 2 cents.

Best regards
S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160510/1a308527/attachment-0001.html 

From gunnar at hibernate.org  Tue May 10 06:34:40 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 10 May 2016 12:34:40 +0200
Subject: [wildfly-dev] update on WildFly NoSQL prototype integration...
In-Reply-To: <bf184686-ccbb-f6bf-3ce5-db00cb54bf6c@redhat.com>
References: <bf184686-ccbb-f6bf-3ce5-db00cb54bf6c@redhat.com>
Message-ID: <CADGJaX9JiiEZw+8XqzsZjU2q5jcp3cnnx_7U3G_g4PgT86qQUw@mail.gmail.com>

Hi Scott,

Thanks for driving this initiative!

Some comments/questions inline.

2016-05-04 20:16 GMT+02:00 Scott Marlow <smarlow at redhat.com>:

> Hi,
>
> Below is an update on the WildFly NoSQL integration project.  The goal
> is for deployed applications to have access to NoSQL databases (via
> Hibernate OGM or native APIs).  Items 1-4, should be finished in our
> first pass, with as much of the others items as we can do as well.
>
> 1. connection management will deal with obtaining NoSQL connections for
> application use.
>
>   - borrow/share Hibernate OGM connection configuration setup code
>   - authentication integration
>   - support transport level security
>

Any ideas how this code sharing could look like?

Hibernate OGM should still be usable without WF; So maybe there should be a
separate project/repo which defines an SPI to obtain/manage connections and
implementations for different NoSQL stores?

I think it'd be beneficial to define some sort of connection URL syntax
which can be used in NoSQL datasource definitions:

    nosql:mongodb://192.168.1.100:27017
[,another-host:another-port]/some_db?customParam1=xyz&customParam2=abc&...

This common syntax might do for most cases, for others it might be needed
to support specialized schemes handled by store-specific SPI
implementations.

Regarding pooling, many NoSQL drivers do it in one way or another, so maybe
leave that to drivers, at least in the first iteration?

2. CDI programming simplifications will make it easy to inject NoSQL
> data into your application classes.
>
>   - https://github.com/antoinesd/javaee-nosql is initial idea
>

+1 Sounds nice.

>
> 3. You will easily get a native NoSQL connection from the specified
> NoSQL profile and use the native NOSQL (Cassandra/MongoDB/other) API in
> your application.
>

Would you take measures to e.g. prevent closing a connection in application
code?

4. You will also be able to easily use Hibernate OGM with the defined
> NoSQL profiles (exactly how is TBD but will be awesome :-).
>   - Hibernate OGM static module is included.
>

WDYM by "static module"? The Hibernate OGM Core module?

How would people add the OGM backend module for the NoSQL store of their
choice? I suppose you don't mean to add all the backends we have to WF by
default (as this would increase size quite a bit), so would people still
use the module ZIP we provide?


>   - need to align with OGM dependencies (e.g. Hibernate ORM + other
> dependencies).
>

Note we aim at the ORM version part of WF at a given time. But there are
times where we need a newer ORM version for a new OGM release (when using
new SPIs not part in the ORM version coming with the currently released
WF), so there should be a way to achieve that.


>   - as mentioned above, OGM already has some connection setup code,
> which might be good to share for WildFly + standalone NoSQL use.
>

I'm not sure how re-usable this is. It's geared towards OGM's needs, I feel
having a separate SPI dealing just with connections would be more useful.


>   - once WildFly has a common NoSQLSource (not a DataSource) that OGM
> can use, OGM will be enhanced to use it.
>

+1

5. How best for the WildFly NoSQL subsystem to be optional?
>   - Is it enough to not run the wildfly/testsuite/nosql tests by default?
>   - Or do we need to start a separate https://github.com/wildfly/nosql
> project for the NoSQL subsystems?
>

Would there be one OGM sub-system? Or one per NoSQL store? And how would
people add them (see above)? As said before in this thread, there should be
a way to update modules of specific stores to get the latest and greatest.

6. transaction enlistment
>
> 7. compensating transactions
>
> 8. runtime application monitoring
>
> 9. How soon can we make an evaluation distribution available for use on
> OpenStack/OpenShift?
>   - Would be great if we could do some load testing with all NoSQL
> components.
>   - Would be great if we could enable others to also test.
>
> 10. Are there any problems with our WildFly NoSQL subsystem injecting
> MongoDatabase connections via:
>
>     @Resource(lookup = "java:jboss/mongodb/test") MongoDatabase db;
>
>   - No @Resource support expected for standalone Java, TBD is whether a
> runtime library can be used.
>   - Any problems expected on other EE application servers if this
> approach becomes popular?
>
> 11. WIP topic branch is at
> https://github.com/scottmarlow/wildfly/tree/nosql-dev9.  Note that every
> once in a while, commits are squashed and pushed to nosql-devN+1.
>

Any pointers where to start looking to see what's working already?

12. Add proper unit tests
>   - multi-threaded NoSQL access to show that works at all.
>   - use NoSQL from different EE components (e.g. JAX-RS).
>   - other use cases that represent how NoSQL could be used from WildFly.
>
> Feedback/help is welcome!
>
> Thanks,
> Scott
> _______________________________________________
> 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/20160510/9cee0a97/attachment.html 

From smarlow at redhat.com  Tue May 10 09:27:31 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 10 May 2016 09:27:31 -0400
Subject: [wildfly-dev] update on WildFly NoSQL prototype integration...
In-Reply-To: <CAMquZP7jvfWCH_nn5xv=_6NXThVUKUP+OaB3Fc+Bc9bg9puRqw@mail.gmail.com>
References: <bf184686-ccbb-f6bf-3ce5-db00cb54bf6c@redhat.com>
	<572B875C.20903@redhat.com>
	<CAMquZP7jvfWCH_nn5xv=_6NXThVUKUP+OaB3Fc+Bc9bg9puRqw@mail.gmail.com>
Message-ID: <56710014-88f0-e0f4-e82b-bd683fb90eac@redhat.com>



On 05/05/2016 06:42 PM, Toma? Cerar wrote:
>
> On Thu, May 5, 2016 at 7:48 PM, Jesper Pedersen
> <jesper.pedersen at redhat.com <mailto:jesper.pedersen at redhat.com>> wrote:
>
>     - Maybe refactor from org.jboss.as <http://org.jboss.as> to org.wildfly
>     - I think you can leave out the "subsystem" part of the package name
>
>
> not really, proper name of would be org.wildfly.extension.name-of-extension
> for more see https://developer.jboss.org/wiki/WildFlyNamingPolicy

Thanks, I mostly followed the WildFlyNamingPolicy but didn't change the 
maven artifacts yet (I think we are okay with the current artifact names 
but if not, we can change them also).

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

From smarlow at redhat.com  Tue May 10 09:58:55 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 10 May 2016 09:58:55 -0400
Subject: [wildfly-dev] update on WildFly NoSQL prototype integration...
In-Reply-To: <572B875C.20903@redhat.com>
References: <bf184686-ccbb-f6bf-3ce5-db00cb54bf6c@redhat.com>
	<572B875C.20903@redhat.com>
Message-ID: <bc71154d-f17e-62f8-9cc1-b9a6d50c0cb0@redhat.com>



On 05/05/2016 01:48 PM, Jesper Pedersen wrote:
> Hi,
>
> On 05/04/2016 02:16 PM, Scott Marlow wrote:
>> Below is an update on the WildFly NoSQL integration project.  The goal
>> is for deployed applications to have access to NoSQL databases (via
>> Hibernate OGM or native APIs).  Items 1-4, should be finished in our
>> first pass, with as much of the others items as we can do as well.
>>
>
> Some general comments:
>
> - Good start :)
> - Maybe refactor from org.jboss.as to org.wildfly
Done.

> - I think you can leave out the "subsystem" part of the package name
Done.

> - Maybe use version identifiers in the package name since NoSQL APIs
> change a lot
I'm not yet sure about versioning and about life cycle as well.

> - Add some additional asserts to the test cases to verify input / output
> from the stores

Will do.

>
>> 1. connection management will deal with obtaining NoSQL connections for
>> application use.
>>
>>    - borrow/share Hibernate OGM connection configuration setup code
>>    - authentication integration
>>    - support transport level security
>>
>
> Connection management is a huge area to tackle. I think it is best to
> start with what each NoSQL implementation offer.

It could be interesting to ping the various NoSQL communities to get 
some dialog going on how to do platform level connection management.

>
> The big question is if the connections should be truly managed which
> would give the option to no-op dangerous API calls out. There aren't any
> spec requirements for this, so it is really a matter of how the APIs
> should be presented.
>
> You may have to proxy some of the classes in order to pass the security
> information into the stores. I think people would expect to use WildFly
> security domains for this (SubjectFactory/Subject).

Good point, users will want to use WildFly security.

>
>> 2. CDI programming simplifications will make it easy to inject NoSQL
>> data into your application classes.
>>
>>    - https://github.com/antoinesd/javaee-nosql is initial idea
>>
>> 3. You will easily get a native NoSQL connection from the specified
>> NoSQL profile and use the native NOSQL (Cassandra/MongoDB/other) API in
>> your application.
>>
>
> I think this is key, as the APIs change almost per release.
>
>> 4. You will also be able to easily use Hibernate OGM with the defined
>> NoSQL profiles (exactly how is TBD but will be awesome :-).
>>    - Hibernate OGM static module is included.
>>    - need to align with OGM dependencies (e.g. Hibernate ORM + other
>> dependencies).
>>    - as mentioned above, OGM already has some connection setup code,
>> which might be good to share for WildFly + standalone NoSQL use.
>>    - once WildFly has a common NoSQLSource (not a DataSource) that OGM
>> can use, OGM will be enhanced to use it.
>>
>> 5. How best for the WildFly NoSQL subsystem to be optional?
>>    - Is it enough to not run the wildfly/testsuite/nosql tests by default?
>>    - Or do we need to start a separate https://github.com/wildfly/nosql
>> project for the NoSQL subsystems?
>>
>> 6. transaction enlistment
>>
>
> This will vary for each store, and there are many loopholes that you may
> want to plug, f.ex. sharing a connection between 2 transactions.
>
> For 1-phase, you will have to insert a LocalXAResource instance into the
> transaction when the "connection" is obtained, and return it on the
> boundary (afterCompletion). Same deal for 2-phase basically.
>
> The LocalXAResource implementation will of course be different for each
> store.

Any links to existing IronJacamar code to share here?  I think that we 
could prototype new transaction enlistment handling code, based on what 
we currently have.

>
> You may want a transaction option for the stores that supports this such
> that people can choose the "level" of enlistment (ala jta="false").
>
> One task I see is that people will have access to the transactional
> methods in the API, and you don't want them to call these methods in
> their apps unless the transaction setting allows this.
>
> I think you can leave out the corner-cases in the 1st iteration, like
> deferred enlistment (get connection, start transaction).
>
>> 7. compensating transactions
>>
>
> Another huge area.
>
> I would let the use-cases from WildFly/Swarm drive this.
>
> A simple way to start is to have a SPI that apps can implement in case
> the transaction is MARKED_FOR_ROLLBACK (hooks to an enlisted XAResource).
>
>> 8. runtime application monitoring
>>
>
> As each store is different I would only look into what the subsystem can
> expose, plus whatever the store can display.
>
>> 9. How soon can we make an evaluation distribution available for use on
>> OpenStack/OpenShift?
>>    - Would be great if we could do some load testing with all NoSQL
>> components.
>>    - Would be great if we could enable others to also test.
>>
>> 10. Are there any problems with our WildFly NoSQL subsystem injecting
>> MongoDatabase connections via:
>>
>>      @Resource(lookup = "java:jboss/mongodb/test") MongoDatabase db;
>>
>>    - No @Resource support expected for standalone Java, TBD is whether a
>> runtime library can be used.
>>    - Any problems expected on other EE application servers if this
>> approach becomes popular?
>>
>
> This ties into connection management. I like what you have now for the
> 1st pass.
>
>> 11. WIP topic branch is at
>> https://github.com/scottmarlow/wildfly/tree/nosql-dev9.  Note that every
>> once in a while, commits are squashed and pushed to nosql-devN+1.
>>
>> 12. Add proper unit tests
>>    - multi-threaded NoSQL access to show that works at all.
>>    - use NoSQL from different EE components (e.g. JAX-RS).
>>    - other use cases that represent how NoSQL could be used from WildFly.
>>
>
> I think you can look at test cases for EE components that support @Resource.

Using @Inject may be another way, once we have 
https://github.com/antoinesd/javaee-nosql going.  Will see which way 
survives the prototype stage to what is merged into WildFly. :-)

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

From emmanuel at hibernate.org  Tue May 10 10:01:42 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 10 May 2016 16:01:42 +0200
Subject: [wildfly-dev] update on WildFly NoSQL prototype integration...
In-Reply-To: <bf184686-ccbb-f6bf-3ce5-db00cb54bf6c@redhat.com>
References: <bf184686-ccbb-f6bf-3ce5-db00cb54bf6c@redhat.com>
Message-ID: <20160510140142.GZ60839@hibernate.org>

That reminds me that we wanted to make the connection to JDG as simple
as MongoDB and the like. (i.e. a URL scheme more or less).
I'm talking about JDG remote here even though local would be a nice to
have.

How hard would that be?

Emmanuel

On Wed 2016-05-04 14:16, Scott Marlow wrote:
> Hi,
> 
> Below is an update on the WildFly NoSQL integration project.  The goal 
> is for deployed applications to have access to NoSQL databases (via 
> Hibernate OGM or native APIs).  Items 1-4, should be finished in our 
> first pass, with as much of the others items as we can do as well.
> 
> 1. connection management will deal with obtaining NoSQL connections for 
> application use.
> 
>   - borrow/share Hibernate OGM connection configuration setup code
>   - authentication integration
>   - support transport level security
> 
> 2. CDI programming simplifications will make it easy to inject NoSQL 
> data into your application classes.
> 
>   - https://github.com/antoinesd/javaee-nosql is initial idea
> 
> 3. You will easily get a native NoSQL connection from the specified 
> NoSQL profile and use the native NOSQL (Cassandra/MongoDB/other) API in 
> your application.
> 
> 4. You will also be able to easily use Hibernate OGM with the defined 
> NoSQL profiles (exactly how is TBD but will be awesome :-).
>   - Hibernate OGM static module is included.
>   - need to align with OGM dependencies (e.g. Hibernate ORM + other 
> dependencies).
>   - as mentioned above, OGM already has some connection setup code, 
> which might be good to share for WildFly + standalone NoSQL use.
>   - once WildFly has a common NoSQLSource (not a DataSource) that OGM 
> can use, OGM will be enhanced to use it.
> 
> 5. How best for the WildFly NoSQL subsystem to be optional?
>   - Is it enough to not run the wildfly/testsuite/nosql tests by default?
>   - Or do we need to start a separate https://github.com/wildfly/nosql 
> project for the NoSQL subsystems?
> 
> 6. transaction enlistment
> 
> 7. compensating transactions
> 
> 8. runtime application monitoring
> 
> 9. How soon can we make an evaluation distribution available for use on 
> OpenStack/OpenShift?
>   - Would be great if we could do some load testing with all NoSQL 
> components.
>   - Would be great if we could enable others to also test.
> 
> 10. Are there any problems with our WildFly NoSQL subsystem injecting 
> MongoDatabase connections via:
> 
>     @Resource(lookup = "java:jboss/mongodb/test") MongoDatabase db;
> 
>   - No @Resource support expected for standalone Java, TBD is whether a 
> runtime library can be used.
>   - Any problems expected on other EE application servers if this 
> approach becomes popular?
> 
> 11. WIP topic branch is at 
> https://github.com/scottmarlow/wildfly/tree/nosql-dev9.  Note that every 
> once in a while, commits are squashed and pushed to nosql-devN+1.
> 
> 12. Add proper unit tests
>   - multi-threaded NoSQL access to show that works at all.
>   - use NoSQL from different EE components (e.g. JAX-RS).
>   - other use cases that represent how NoSQL could be used from WildFly.
> 
> Feedback/help is welcome!
> 
> Thanks,
> Scott
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

From smarlow at redhat.com  Tue May 10 10:17:33 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 10 May 2016 10:17:33 -0400
Subject: [wildfly-dev] update on WildFly NoSQL prototype integration...
In-Reply-To: <CAMrRDdwWQecKAd+9g+syeFqzDkF=ECuGy6nqqfAzG0gUJra_WA@mail.gmail.com>
References: <bf184686-ccbb-f6bf-3ce5-db00cb54bf6c@redhat.com>
	<572B875C.20903@redhat.com>
	<CAMrRDdwWQecKAd+9g+syeFqzDkF=ECuGy6nqqfAzG0gUJra_WA@mail.gmail.com>
Message-ID: <5ae66735-16b6-fc9a-9be3-ab85fd0ccac7@redhat.com>



On 05/10/2016 05:26 AM, Stefano Maestri wrote:
>
>
> On Thu, May 5, 2016 at 7:48 PM, Jesper
> Pedersen <jesper.pedersen at redhat.com
> <mailto:jesper.pedersen at redhat.com>> wrote:
>
>     Hi,
>
>     On 05/04/2016 02:16 PM, Scott Marlow wrote:
>     > Below is an update on the WildFly NoSQL integration project.  The goal
>     > is for deployed applications to have access to NoSQL databases (via
>     > Hibernate OGM or native APIs).  Items 1-4, should be finished in our
>     > first pass, with as much of the others items as we can do as well.
>     >
>
>     Some general comments:
>
>     - Good start :)
>     - Maybe refactor from org.jboss.as <http://org.jboss.as/> to org.wildfly
>
>
> +1
>
>
>     - Maybe use version identifiers in the package name since NoSQL APIs
>     change a lot
>
>
> Well even if it is different we had bad experience on this w/ IJ and
> removed those version identifier from package name. I think package name
> should not have version ids, even if it could be acceptable in this
> first phase we should try to hide this kind of infos to users of OURS
> API even if APIs from NoSQL impl would be dependents from specific release.
>
>
>     - Add some additional asserts to the test cases to verify input / output
>     from the stores
>
>     > 1. connection management will deal with obtaining NoSQL connections for
>     > application use.
>     >
>     >    - borrow/share Hibernate OGM connection configuration setup code
>     >    - authentication integration
>     >    - support transport level security
>     >
>
>     Connection management is a huge area to tackle. I think it is best to
>     start with what each NoSQL implementation offer.
>
>
> Yup it would be a good start, even if the other question is "why a user
> should use WF integration instead of direct use of various
> implementation?". One of the possible answer could be "to have a common
> connection management" for sure. So the (final) effort should be to have
> a common connection management.

I wonder if any of the NoSQL database development communities would be 
interested in establishing a common connection management client API.

>
>
>
>     The big question is if the connections should be truly managed which
>     would give the option to no-op dangerous API calls out. There aren't any
>     spec requirements for this, so it is really a matter of how the APIs
>     should be presented.
>
>
> Yup exactly.
>
>
>
>     You may have to proxy some of the classes in order to pass the security
>     information into the stores. I think people would expect to use WildFly
>     security domains for this (SubjectFactory/Subject).
>
>
> Yes it's another possible question to "why use WF integration?"
>
>
>
>     > 2. CDI programming simplifications will make it easy to inject NoSQL
>     > data into your application classes.
>     >
>     >    - https://github.com/antoinesd/javaee-nosql is initial idea
>     >
>     > 3. You will easily get a native NoSQL connection from the specified
>     > NoSQL profile and use the native NOSQL (Cassandra/MongoDB/other) API in
>     > your application.
>     >
>
>     I think this is key, as the APIs change almost per release.
>
>
> Agree 100%. And it gives us also another requirement: should be easily
> to upgrade this Wildfly subsystem (or at least underlying NoSQL
> implementations) because NoSQL users would expect to use latest "cool"
> features of their NoSQL impl and don't want to wait for WildFLy (or EAP)
> release cycle.
>
>
>
>
>     > 4. You will also be able to easily use Hibernate OGM with the defined
>     > NoSQL profiles (exactly how is TBD but will be awesome :-).
>     >    - Hibernate OGM static module is included.
>     >    - need to align with OGM dependencies (e.g. Hibernate ORM + other
>     > dependencies).
>     >    - as mentioned above, OGM already has some connection setup code,
>     > which might be good to share for WildFly + standalone NoSQL use.
>     >    - once WildFly has a common NoSQLSource (not a DataSource) that OGM
>     > can use, OGM will be enhanced to use it.
>     >
>     > 5. How best for the WildFly NoSQL subsystem to be optional?
>     >    - Is it enough to not run the wildfly/testsuite/nosql tests by default?
>     >    - Or do we need to start a separate https://github.com/wildfly/nosql
>     > project for the NoSQL subsystems?
>     >
>     > 6. transaction enlistment
>     >
>
>     This will vary for each store, and there are many loopholes that you may
>     want to plug, f.ex. sharing a connection between 2 transactions.
>
>     For 1-phase, you will have to insert a LocalXAResource instance into the
>     transaction when the "connection" is obtained, and return it on the
>     boundary (afterCompletion). Same deal for 2-phase basically.
>
>     The LocalXAResource implementation will of course be different for each
>     store.
>
>     You may want a transaction option for the stores that supports this such
>     that people can choose the "level" of enlistment (ala jta="false").
>
>     One task I see is that people will have access to the transactional
>     methods in the API, and you don't want them to call these methods in
>     their apps unless the transaction setting allows this.
>
>     I think you can leave out the corner-cases in the 1st iteration, like
>     deferred enlistment (get connection, start transaction).
>
>     > 7. compensating transactions
>     >
>
>     Another huge area.
>
>     I would let the use-cases from WildFly/Swarm drive this.
>
>     A simple way to start is to have a SPI that apps can implement in case
>     the transaction is MARKED_FOR_ROLLBACK (hooks to an enlisted
>     XAResource).
>
>
> We implemented those in IJ (even if in much more standard JCA
> environment), and maybe we could share and eventually copy/paste some
> code.

Check out "MongoDB integration test with compensating transactions"
https://github.com/scottmarlow/wildfly/commit/9bd67964a9259416add73cac47328cec5127d25c, 
which is a good start.  We can work forward from what we have and ideas 
from IJ.

>
>
>
>
>     > 8. runtime application monitoring
>     >
>
>     As each store is different I would only look into what the subsystem can
>     expose, plus whatever the store can display.
>
>
> Maybe a plugin approach could be taken as we did for datasource and RA
> subsystems reading statistics available during deployment and runtime
> and exposing them as pure runtime metrics in DMR.

Great idea and great examples.

>
> Just my 2 cents.
>
> Best regards
> S.
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From david.lloyd at redhat.com  Tue May 10 10:26:01 2016
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Tue, 10 May 2016 09:26:01 -0500
Subject: [wildfly-dev] EJB over HTTP
In-Reply-To: <CAAoo=c5=Wa_vJVbad9Mb2K-n1U1Ue9pq_jM5J9m=i4YfLACVbw@mail.gmail.com>
References: <CAAoo=c5=Wa_vJVbad9Mb2K-n1U1Ue9pq_jM5J9m=i4YfLACVbw@mail.gmail.com>
Message-ID: <5731EF79.7070006@redhat.com>

On 05/04/2016 12:50 AM, Stuart Douglas wrote:
> Hi everyone,
>
> I have started looking into support for service invocation over HTTP.
> Unlike our existing HTTP upgrade support this will map EJB
> requests/responses directly to HTTP requests and responses, which should
> allow it to be used behind existing load balancers.
>
> I have started an initial description of the protocol at:
> https://github.com/stuartwdouglas/wildfly-http-client/blob/master/docs/wire-spec-v1.asciidoc
>
> The intention is to follow HTTP semantics as closely as possible.
> Clustering will be provided in a similar manner to web clustering (i.e. it
> will require a load balancer, and work in a similar manner to web
> clustering).
>
> There is still plenty work that needs to be done (especially around
> security), so if anyone has any feedback let me know.

I noticed the responses are not coupled with the requests in the 
document, which was a bit confusing at first.

I have a question though, why have the "EJB new session" response return 
a nonstandard header for the session ID rather than a REST-ish 201 
message that has a Location: header with the SFSB URI in it?  Was it 
just message size you were worried about?  Also having a content-type 
with no body is a little weird.

The EJB request payload has to include the "weak affinity" value in 
order to be compatible with the existing protocol.  But I think maybe 
the affinity concept should be nuked from orbit in general, as it turns 
out to be kinda broken; we can discuss this separately.

On the topic of security... The original draft design doc was written 
before we really bit into HTTP authentication in Elytron.  Now that we 
have, I think we can safely rely solely on HTTP authentication 
mechanisms to cover all cases for HTTP, including more complex 
mechanisms like Kerberos, OAuth2 and other SSO technologies, 
session-based authentication, and so forth; we don't need any separated 
authentication service over HTTP for any reason that I can think of.

We may however want to consider adding a custom cookie-based 
authentication mechanism to allow for HTTP-level authentication results 
(for mechanisms like DIGEST or SCRAM or whatever) to be "tagged"; this 
way it would be possible to toggle between more than one identity 
without requiring every request to repeat the authentication, and 
without overloading JSESSIONID for this purpose (allowing multiple 
identities to be used for a given SFSB and/or transaction).

-- 
- DML

From smarlow at redhat.com  Tue May 10 10:45:54 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 10 May 2016 10:45:54 -0400
Subject: [wildfly-dev] update on WildFly NoSQL prototype integration...
In-Reply-To: <20160510140142.GZ60839@hibernate.org>
References: <bf184686-ccbb-f6bf-3ce5-db00cb54bf6c@redhat.com>
	<20160510140142.GZ60839@hibernate.org>
Message-ID: <b761d6cc-10f4-b8b4-2f20-790ac851fb76@redhat.com>



On 05/10/2016 10:01 AM, Emmanuel Bernard wrote:
> That reminds me that we wanted to make the connection to JDG as simple
> as MongoDB and the like. (i.e. a URL scheme more or less).
> I'm talking about JDG remote here even though local would be a nice to
> have.
>
> How hard would that be?

I think that org.wildfly.clustering.dispatcher.CommandDispatcher is for 
invoking nodes on the WildFly cluster but I'm not sure of the API for 
invoking JDG remote and whether that is planned to be part of WildFly 
already, as part of our clustering effort.

Could/should JDG access fall into NoSQL integration?

>
> Emmanuel
>
> On Wed 2016-05-04 14:16, Scott Marlow wrote:
>> Hi,
>>
>> Below is an update on the WildFly NoSQL integration project.  The goal
>> is for deployed applications to have access to NoSQL databases (via
>> Hibernate OGM or native APIs).  Items 1-4, should be finished in our
>> first pass, with as much of the others items as we can do as well.
>>
>> 1. connection management will deal with obtaining NoSQL connections for
>> application use.
>>
>>   - borrow/share Hibernate OGM connection configuration setup code
>>   - authentication integration
>>   - support transport level security
>>
>> 2. CDI programming simplifications will make it easy to inject NoSQL
>> data into your application classes.
>>
>>   - https://github.com/antoinesd/javaee-nosql is initial idea
>>
>> 3. You will easily get a native NoSQL connection from the specified
>> NoSQL profile and use the native NOSQL (Cassandra/MongoDB/other) API in
>> your application.
>>
>> 4. You will also be able to easily use Hibernate OGM with the defined
>> NoSQL profiles (exactly how is TBD but will be awesome :-).
>>   - Hibernate OGM static module is included.
>>   - need to align with OGM dependencies (e.g. Hibernate ORM + other
>> dependencies).
>>   - as mentioned above, OGM already has some connection setup code,
>> which might be good to share for WildFly + standalone NoSQL use.
>>   - once WildFly has a common NoSQLSource (not a DataSource) that OGM
>> can use, OGM will be enhanced to use it.
>>
>> 5. How best for the WildFly NoSQL subsystem to be optional?
>>   - Is it enough to not run the wildfly/testsuite/nosql tests by default?
>>   - Or do we need to start a separate https://github.com/wildfly/nosql
>> project for the NoSQL subsystems?
>>
>> 6. transaction enlistment
>>
>> 7. compensating transactions
>>
>> 8. runtime application monitoring
>>
>> 9. How soon can we make an evaluation distribution available for use on
>> OpenStack/OpenShift?
>>   - Would be great if we could do some load testing with all NoSQL
>> components.
>>   - Would be great if we could enable others to also test.
>>
>> 10. Are there any problems with our WildFly NoSQL subsystem injecting
>> MongoDatabase connections via:
>>
>>     @Resource(lookup = "java:jboss/mongodb/test") MongoDatabase db;
>>
>>   - No @Resource support expected for standalone Java, TBD is whether a
>> runtime library can be used.
>>   - Any problems expected on other EE application servers if this
>> approach becomes popular?
>>
>> 11. WIP topic branch is at
>> https://github.com/scottmarlow/wildfly/tree/nosql-dev9.  Note that every
>> once in a while, commits are squashed and pushed to nosql-devN+1.
>>
>> 12. Add proper unit tests
>>   - multi-threaded NoSQL access to show that works at all.
>>   - use NoSQL from different EE components (e.g. JAX-RS).
>>   - other use cases that represent how NoSQL could be used from WildFly.
>>
>> Feedback/help is welcome!
>>
>> Thanks,
>> Scott
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev

From jesper.pedersen at redhat.com  Tue May 10 11:06:13 2016
From: jesper.pedersen at redhat.com (Jesper Pedersen)
Date: Tue, 10 May 2016 11:06:13 -0400
Subject: [wildfly-dev] update on WildFly NoSQL prototype integration...
In-Reply-To: <bc71154d-f17e-62f8-9cc1-b9a6d50c0cb0@redhat.com>
References: <bf184686-ccbb-f6bf-3ce5-db00cb54bf6c@redhat.com>
	<572B875C.20903@redhat.com>
	<bc71154d-f17e-62f8-9cc1-b9a6d50c0cb0@redhat.com>
Message-ID: <5731F8E5.7030609@redhat.com>

Hi,

On 05/10/2016 09:58 AM, Scott Marlow wrote:
> On 05/05/2016 01:48 PM, Jesper Pedersen wrote:
>>> 6. transaction enlistment
>>>
>>
>> This will vary for each store, and there are many loopholes that you may
>> want to plug, f.ex. sharing a connection between 2 transactions.
>>
>> For 1-phase, you will have to insert a LocalXAResource instance into the
>> transaction when the "connection" is obtained, and return it on the
>> boundary (afterCompletion). Same deal for 2-phase basically.
>>
>> The LocalXAResource implementation will of course be different for each
>> store.
>
> Any links to existing IronJacamar code to share here?  I think that we
> could prototype new transaction enlistment handling code, based on what
> we currently have.
>

The IronJacamar code is here for Narayana:

https://github.com/ironjacamar/ironjacamar/tree/master/core/src/main/java/org/ironjacamar/core/tx/narayana

However, that is based on the Java EE Connector Architecture 
specification, so we have a *much* easier job.

Lets take an example from the NoSQL world using Neo4J:

http://neo4j.com/docs/api/java-driver/current/org/neo4j/driver/v1/Driver.html

...neo4j.LocalXAResource implements XAResource, org.jboss.tm.LastResource

  public void start(Xid xid, int flags) throws XAException {
    tx = session.beginTransaction();
  }

  public void commit(Xid xid, boolean onePhase) throws XAException {
    tx.success();
  }

  public void rollback(Xid xid) throws XAException {
    tx.failure();
  }

And the app, f.ex. in a SLSB method

public class MySLSB ...

   @Resource(mappedName="java:jboss/nosql/neo4j")
   private Driver neo4j;

   public void myMethod() {
#1   Session s = neo4j.createSession();
      s.run( "CREATE (n {name:'Bob'})" );

#2   Transaction tx = s.beginTransaction();
      tx.run( "CREATE (n {name:'Alice'})" );
      tx.run( "CREATE (n {name:'Tina'})" );

#3   tx.success();

#4   tx.close();
#5   s.close();
#6   neo4j.close();
   }

However, as you can see there are a number of hidden things going on 
here if ".../neo4j" is deployed as "transaction=1phase".

#1: Here you have to intercept the call, create the LocalXAResource 
instance and enlist it in the active transaction

#2: Here you have to a delegator instance that only executes the run() calls

#3: No-op call, happens upon EE transaction completion

#4: No-op call. happens upon EE transaction completion

#5: No-op call, happens in an enlisted Synchronization instance 
(afterCompletion) (done in #1 too)

#6: No-op call, handled by subsystem

The value-add is that #3 is tied into the overall EE transaction.

If ".../neo4j" is deployed as "transaction=none", then all calls are on 
the "real" Neo4J objects.

As you can see it isn't as simple as it may appear, and application flow 
could be different from what the developer expects, as #3 could be a 
real tx.failure() call in case of MARKED_FOR_ROLLBACK.

There are def pros/cons of doing tx enlistment for this area...

>>
>> You may want a transaction option for the stores that supports this such
>> that people can choose the "level" of enlistment (ala jta="false").
>>
>> One task I see is that people will have access to the transactional
>> methods in the API, and you don't want them to call these methods in
>> their apps unless the transaction setting allows this.
>>
>> I think you can leave out the corner-cases in the 1st iteration, like
>> deferred enlistment (get connection, start transaction).

Best regards,
  Jesper


From darran.lofthouse at jboss.com  Tue May 10 11:10:17 2016
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Tue, 10 May 2016 16:10:17 +0100
Subject: [wildfly-dev] EJB over HTTP
In-Reply-To: <5731EF79.7070006@redhat.com>
References: <CAAoo=c5=Wa_vJVbad9Mb2K-n1U1Ue9pq_jM5J9m=i4YfLACVbw@mail.gmail.com>
	<5731EF79.7070006@redhat.com>
Message-ID: <9d63f816-fce4-8a51-d1b6-256db03b4de7@jboss.com>



On 10/05/16 15:26, David M. Lloyd wrote:
> On 05/04/2016 12:50 AM, Stuart Douglas wrote:
>> Hi everyone,
>>
>> I have started looking into support for service invocation over HTTP.
>> Unlike our existing HTTP upgrade support this will map EJB
>> requests/responses directly to HTTP requests and responses, which should
>> allow it to be used behind existing load balancers.
>>
>> I have started an initial description of the protocol at:
>> https://github.com/stuartwdouglas/wildfly-http-client/blob/master/docs/wire-spec-v1.asciidoc
>>
>> The intention is to follow HTTP semantics as closely as possible.
>> Clustering will be provided in a similar manner to web clustering (i.e. it
>> will require a load balancer, and work in a similar manner to web
>> clustering).
>>
>> There is still plenty work that needs to be done (especially around
>> security), so if anyone has any feedback let me know.
>
> I noticed the responses are not coupled with the requests in the
> document, which was a bit confusing at first.
>
> I have a question though, why have the "EJB new session" response return
> a nonstandard header for the session ID rather than a REST-ish 201
> message that has a Location: header with the SFSB URI in it?  Was it
> just message size you were worried about?  Also having a content-type
> with no body is a little weird.
>
> The EJB request payload has to include the "weak affinity" value in
> order to be compatible with the existing protocol.  But I think maybe
> the affinity concept should be nuked from orbit in general, as it turns
> out to be kinda broken; we can discuss this separately.
>
> On the topic of security... The original draft design doc was written
> before we really bit into HTTP authentication in Elytron.  Now that we
> have, I think we can safely rely solely on HTTP authentication
> mechanisms to cover all cases for HTTP, including more complex
> mechanisms like Kerberos, OAuth2 and other SSO technologies,
> session-based authentication, and so forth; we don't need any separated
> authentication service over HTTP for any reason that I can think of.
>
> We may however want to consider adding a custom cookie-based
> authentication mechanism to allow for HTTP-level authentication results
> (for mechanisms like DIGEST or SCRAM or whatever) to be "tagged"; this
> way it would be possible to toggle between more than one identity
> without requiring every request to repeat the authentication, and
> without overloading JSESSIONID for this purpose (allowing multiple
> identities to be used for a given SFSB and/or transaction).

We would have to be very careful with that one though - for the identity 
switching in Remoting we have the ability to use a long running 
connection to associate the identity with - if we are not careful cookie 
based tracking immediately adds somethign that can be used for replay 
unless TLS is mandated as well.

>

From david.lloyd at redhat.com  Tue May 10 11:13:53 2016
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Tue, 10 May 2016 10:13:53 -0500
Subject: [wildfly-dev] EJB over HTTP
In-Reply-To: <9d63f816-fce4-8a51-d1b6-256db03b4de7@jboss.com>
References: <CAAoo=c5=Wa_vJVbad9Mb2K-n1U1Ue9pq_jM5J9m=i4YfLACVbw@mail.gmail.com>
	<5731EF79.7070006@redhat.com>
	<9d63f816-fce4-8a51-d1b6-256db03b4de7@jboss.com>
Message-ID: <5731FAB1.50105@redhat.com>

On 05/10/2016 10:10 AM, Darran Lofthouse wrote:
>
>
> On 10/05/16 15:26, David M. Lloyd wrote:
>> On 05/04/2016 12:50 AM, Stuart Douglas wrote:
>>> Hi everyone,
>>>
>>> I have started looking into support for service invocation over HTTP.
>>> Unlike our existing HTTP upgrade support this will map EJB
>>> requests/responses directly to HTTP requests and responses, which should
>>> allow it to be used behind existing load balancers.
>>>
>>> I have started an initial description of the protocol at:
>>> https://github.com/stuartwdouglas/wildfly-http-client/blob/master/docs/wire-spec-v1.asciidoc
>>>
>>> The intention is to follow HTTP semantics as closely as possible.
>>> Clustering will be provided in a similar manner to web clustering (i.e. it
>>> will require a load balancer, and work in a similar manner to web
>>> clustering).
>>>
>>> There is still plenty work that needs to be done (especially around
>>> security), so if anyone has any feedback let me know.
>>
>> I noticed the responses are not coupled with the requests in the
>> document, which was a bit confusing at first.
>>
>> I have a question though, why have the "EJB new session" response return
>> a nonstandard header for the session ID rather than a REST-ish 201
>> message that has a Location: header with the SFSB URI in it?  Was it
>> just message size you were worried about?  Also having a content-type
>> with no body is a little weird.
>>
>> The EJB request payload has to include the "weak affinity" value in
>> order to be compatible with the existing protocol.  But I think maybe
>> the affinity concept should be nuked from orbit in general, as it turns
>> out to be kinda broken; we can discuss this separately.
>>
>> On the topic of security... The original draft design doc was written
>> before we really bit into HTTP authentication in Elytron.  Now that we
>> have, I think we can safely rely solely on HTTP authentication
>> mechanisms to cover all cases for HTTP, including more complex
>> mechanisms like Kerberos, OAuth2 and other SSO technologies,
>> session-based authentication, and so forth; we don't need any separated
>> authentication service over HTTP for any reason that I can think of.
>>
>> We may however want to consider adding a custom cookie-based
>> authentication mechanism to allow for HTTP-level authentication results
>> (for mechanisms like DIGEST or SCRAM or whatever) to be "tagged"; this
>> way it would be possible to toggle between more than one identity
>> without requiring every request to repeat the authentication, and
>> without overloading JSESSIONID for this purpose (allowing multiple
>> identities to be used for a given SFSB and/or transaction).
>
> We would have to be very careful with that one though - for the identity
> switching in Remoting we have the ability to use a long running
> connection to associate the identity with - if we are not careful cookie
> based tracking immediately adds somethign that can be used for replay
> unless TLS is mandated as well.

Yeah it'd have to be checked against the session at the very least, 
meaning a session may have multiple identities but an identity may not 
cross sessions.  If there's no session, each request would be required 
to re-authenticate.

Alternatively, it could be bound to a TLS session, though how that fits 
into the protocol model is a bit more nebulous.
-- 
- DML

From emmanuel at hibernate.org  Tue May 10 11:39:39 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 10 May 2016 17:39:39 +0200
Subject: [wildfly-dev] update on WildFly NoSQL prototype integration...
In-Reply-To: <b761d6cc-10f4-b8b4-2f20-790ac851fb76@redhat.com>
References: <bf184686-ccbb-f6bf-3ce5-db00cb54bf6c@redhat.com>
	<20160510140142.GZ60839@hibernate.org>
	<b761d6cc-10f4-b8b4-2f20-790ac851fb76@redhat.com>
Message-ID: <0DF529F3-2059-4BBF-9F25-0F2CBF60C428@hibernate.org>


> On 10 May 2016, at 16:45, Scott Marlow <smarlow at redhat.com> wrote:
> 
>> That reminds me that we wanted to make the connection to JDG as simple
>> as MongoDB and the like. (i.e. a URL scheme more or less).
>> I'm talking about JDG remote here even though local would be a nice to
>> have.
>> 
>> How hard would that be?
> 
> I think that org.wildfly.clustering.dispatcher.CommandDispatcher is for invoking nodes on the WildFly cluster but I'm not sure of the API for invoking JDG remote and whether that is planned to be part of WildFly already, as part of our clustering effort.
> 
> Could/should JDG access fall into NoSQL integration?

Yes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160510/686f103e/attachment.html 

From darran.lofthouse at jboss.com  Tue May 10 12:23:49 2016
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Tue, 10 May 2016 17:23:49 +0100
Subject: [wildfly-dev] EJB over HTTP
In-Reply-To: <5731FAB1.50105@redhat.com>
References: <CAAoo=c5=Wa_vJVbad9Mb2K-n1U1Ue9pq_jM5J9m=i4YfLACVbw@mail.gmail.com>
	<5731EF79.7070006@redhat.com>
	<9d63f816-fce4-8a51-d1b6-256db03b4de7@jboss.com>
	<5731FAB1.50105@redhat.com>
Message-ID: <3c3b5fed-5292-3b1c-a7d1-7dd80f151e70@jboss.com>


On 10/05/16 16:13, David M. Lloyd wrote:
> On 05/10/2016 10:10 AM, Darran Lofthouse wrote:
>>
>>
>> On 10/05/16 15:26, David M. Lloyd wrote:
>>> On 05/04/2016 12:50 AM, Stuart Douglas wrote:
>>>> Hi everyone,
>>>>
>>>> I have started looking into support for service invocation over HTTP.
>>>> Unlike our existing HTTP upgrade support this will map EJB
>>>> requests/responses directly to HTTP requests and responses, which should
>>>> allow it to be used behind existing load balancers.
>>>>
>>>> I have started an initial description of the protocol at:
>>>> https://github.com/stuartwdouglas/wildfly-http-client/blob/master/docs/wire-spec-v1.asciidoc
>>>>
>>>> The intention is to follow HTTP semantics as closely as possible.
>>>> Clustering will be provided in a similar manner to web clustering (i.e. it
>>>> will require a load balancer, and work in a similar manner to web
>>>> clustering).
>>>>
>>>> There is still plenty work that needs to be done (especially around
>>>> security), so if anyone has any feedback let me know.
>>>
>>> I noticed the responses are not coupled with the requests in the
>>> document, which was a bit confusing at first.
>>>
>>> I have a question though, why have the "EJB new session" response return
>>> a nonstandard header for the session ID rather than a REST-ish 201
>>> message that has a Location: header with the SFSB URI in it?  Was it
>>> just message size you were worried about?  Also having a content-type
>>> with no body is a little weird.
>>>
>>> The EJB request payload has to include the "weak affinity" value in
>>> order to be compatible with the existing protocol.  But I think maybe
>>> the affinity concept should be nuked from orbit in general, as it turns
>>> out to be kinda broken; we can discuss this separately.
>>>
>>> On the topic of security... The original draft design doc was written
>>> before we really bit into HTTP authentication in Elytron.  Now that we
>>> have, I think we can safely rely solely on HTTP authentication
>>> mechanisms to cover all cases for HTTP, including more complex
>>> mechanisms like Kerberos, OAuth2 and other SSO technologies,
>>> session-based authentication, and so forth; we don't need any separated
>>> authentication service over HTTP for any reason that I can think of.
>>>
>>> We may however want to consider adding a custom cookie-based
>>> authentication mechanism to allow for HTTP-level authentication results
>>> (for mechanisms like DIGEST or SCRAM or whatever) to be "tagged"; this
>>> way it would be possible to toggle between more than one identity
>>> without requiring every request to repeat the authentication, and
>>> without overloading JSESSIONID for this purpose (allowing multiple
>>> identities to be used for a given SFSB and/or transaction).
>>
>> We would have to be very careful with that one though - for the identity
>> switching in Remoting we have the ability to use a long running
>> connection to associate the identity with - if we are not careful cookie
>> based tracking immediately adds somethign that can be used for replay
>> unless TLS is mandated as well.
>
> Yeah it'd have to be checked against the session at the very least,
> meaning a session may have multiple identities but an identity may not
> cross sessions.  If there's no session, each request would be required
> to re-authenticate.
>
> Alternatively, it could be bound to a TLS session, though how that fits
> into the protocol model is a bit more nebulous.

Yeah it would really need to be the TLS session it is bound to, even 
HTTP sessions are weak if someone manages to obtain the session ID.

>


From david.lloyd at redhat.com  Tue May 10 12:32:44 2016
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Tue, 10 May 2016 11:32:44 -0500
Subject: [wildfly-dev] EJB over HTTP
In-Reply-To: <3c3b5fed-5292-3b1c-a7d1-7dd80f151e70@jboss.com>
References: <CAAoo=c5=Wa_vJVbad9Mb2K-n1U1Ue9pq_jM5J9m=i4YfLACVbw@mail.gmail.com>
	<5731EF79.7070006@redhat.com>
	<9d63f816-fce4-8a51-d1b6-256db03b4de7@jboss.com>
	<5731FAB1.50105@redhat.com>
	<3c3b5fed-5292-3b1c-a7d1-7dd80f151e70@jboss.com>
Message-ID: <57320D2C.9090200@redhat.com>

On 05/10/2016 11:23 AM, Darran Lofthouse wrote:
>
> On 10/05/16 16:13, David M. Lloyd wrote:
>> On 05/10/2016 10:10 AM, Darran Lofthouse wrote:
>>>
>>>
>>> On 10/05/16 15:26, David M. Lloyd wrote:
>>>> On 05/04/2016 12:50 AM, Stuart Douglas wrote:
>>>>> Hi everyone,
>>>>>
>>>>> I have started looking into support for service invocation over HTTP.
>>>>> Unlike our existing HTTP upgrade support this will map EJB
>>>>> requests/responses directly to HTTP requests and responses, which should
>>>>> allow it to be used behind existing load balancers.
>>>>>
>>>>> I have started an initial description of the protocol at:
>>>>> https://github.com/stuartwdouglas/wildfly-http-client/blob/master/docs/wire-spec-v1.asciidoc
>>>>>
>>>>> The intention is to follow HTTP semantics as closely as possible.
>>>>> Clustering will be provided in a similar manner to web clustering (i.e. it
>>>>> will require a load balancer, and work in a similar manner to web
>>>>> clustering).
>>>>>
>>>>> There is still plenty work that needs to be done (especially around
>>>>> security), so if anyone has any feedback let me know.
>>>>
>>>> I noticed the responses are not coupled with the requests in the
>>>> document, which was a bit confusing at first.
>>>>
>>>> I have a question though, why have the "EJB new session" response return
>>>> a nonstandard header for the session ID rather than a REST-ish 201
>>>> message that has a Location: header with the SFSB URI in it?  Was it
>>>> just message size you were worried about?  Also having a content-type
>>>> with no body is a little weird.
>>>>
>>>> The EJB request payload has to include the "weak affinity" value in
>>>> order to be compatible with the existing protocol.  But I think maybe
>>>> the affinity concept should be nuked from orbit in general, as it turns
>>>> out to be kinda broken; we can discuss this separately.
>>>>
>>>> On the topic of security... The original draft design doc was written
>>>> before we really bit into HTTP authentication in Elytron.  Now that we
>>>> have, I think we can safely rely solely on HTTP authentication
>>>> mechanisms to cover all cases for HTTP, including more complex
>>>> mechanisms like Kerberos, OAuth2 and other SSO technologies,
>>>> session-based authentication, and so forth; we don't need any separated
>>>> authentication service over HTTP for any reason that I can think of.
>>>>
>>>> We may however want to consider adding a custom cookie-based
>>>> authentication mechanism to allow for HTTP-level authentication results
>>>> (for mechanisms like DIGEST or SCRAM or whatever) to be "tagged"; this
>>>> way it would be possible to toggle between more than one identity
>>>> without requiring every request to repeat the authentication, and
>>>> without overloading JSESSIONID for this purpose (allowing multiple
>>>> identities to be used for a given SFSB and/or transaction).
>>>
>>> We would have to be very careful with that one though - for the identity
>>> switching in Remoting we have the ability to use a long running
>>> connection to associate the identity with - if we are not careful cookie
>>> based tracking immediately adds somethign that can be used for replay
>>> unless TLS is mandated as well.
>>
>> Yeah it'd have to be checked against the session at the very least,
>> meaning a session may have multiple identities but an identity may not
>> cross sessions.  If there's no session, each request would be required
>> to re-authenticate.
>>
>> Alternatively, it could be bound to a TLS session, though how that fits
>> into the protocol model is a bit more nebulous.
>
> Yeah it would really need to be the TLS session it is bound to, even
> HTTP sessions are weak if someone manages to obtain the session ID.

Of course; however this is an existing problem.  Form authentication for 
example also relies on the HTTP session to hold the authentication 
information.  Protection against session hijacking is going to have to 
be the responsibility of the user (and not just for authentication but 
also for privacy of transactions, SFSB session instances, etc.). They 
could use protocol level transport security (TLS) or they may rely on 
(for example) physical security, or even IP address verification if the 
situation allows for it.


-- 
- DML

From david.lloyd at redhat.com  Tue May 10 12:40:34 2016
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Tue, 10 May 2016 11:40:34 -0500
Subject: [wildfly-dev] EJB over HTTP
In-Reply-To: <5731EF79.7070006@redhat.com>
References: <CAAoo=c5=Wa_vJVbad9Mb2K-n1U1Ue9pq_jM5J9m=i4YfLACVbw@mail.gmail.com>
	<5731EF79.7070006@redhat.com>
Message-ID: <57320F02.5070900@redhat.com>

On 05/10/2016 09:26 AM, David M. Lloyd wrote:
> On 05/04/2016 12:50 AM, Stuart Douglas wrote:
>> Hi everyone,
>>
>> I have started looking into support for service invocation over HTTP.
>> Unlike our existing HTTP upgrade support this will map EJB
>> requests/responses directly to HTTP requests and responses, which should
>> allow it to be used behind existing load balancers.
>>
>> I have started an initial description of the protocol at:
>> https://github.com/stuartwdouglas/wildfly-http-client/blob/master/docs/wire-spec-v1.asciidoc
>>
>> The intention is to follow HTTP semantics as closely as possible.
>> Clustering will be provided in a similar manner to web clustering (i.e. it
>> will require a load balancer, and work in a similar manner to web
>> clustering).
>>
>> There is still plenty work that needs to be done (especially around
>> security), so if anyone has any feedback let me know.
> [..]
> I have a question though, why have the "EJB new session" response return
> a nonstandard header for the session ID rather than a REST-ish 201
> message that has a Location: header with the SFSB URI in it?  Was it
> just message size you were worried about?  Also having a content-type
> with no body is a little weird.

Looking at the JNDI part, it seems like you are using the content type 
to establish the operation that is to be performed, even when there is 
no actual content.  In the draft, the Accept: type was used to establish 
what kind of result was requested (for JNDI it could be the actual 
binding, or it could be a list of bindings in a couple of forms for 
subcontexts).  The request method determined the operation, and query 
parameters applied behavioral variations.

You did (rightly, IMO) change the lookup operations from GET to POST, 
but I think that response type and query parameters would still suffice 
to get the result, and I'm not sure that using the request content type 
to identify the operation is really appropriate in any event.

-- 
- DML

From sanne at hibernate.org  Wed May 11 09:31:18 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 11 May 2016 14:31:18 +0100
Subject: [wildfly-dev] Speed Up Deployment
In-Reply-To: <3B04C95C-795A-40A0-9B6E-78E83DE211A4@redhat.com>
References: <9183EF05-D698-43F0-9252-03AA6E2310E9@redhat.com>
	<CAAoo=c6NejT_s9vy0VE3rLAsk8=MO-5f0dstxKdciiywCCwiYg@mail.gmail.com>
	<3B04C95C-795A-40A0-9B6E-78E83DE211A4@redhat.com>
Message-ID: <CAFm4XO3RyQ02p1Hpoe1V94B5EOi03FPp=reUQBFR_6fcZwUzOA@mail.gmail.com>

Would you expect it to be beneficial to include an empty jandex.idx
file in popular libraries which we expect to be visible to user
deployments?

(i.e. hibernate-core.jar and similar cases).

I guess I could measure it, but I'm assuming that I'll need to apply
this to many jars to see any measurable benefit.

Thanks,
Sanne


On 2 May 2016 at 11:52, Heiko Braun <hbraun at redhat.com> wrote:
> Thanks, I?ll try that and let you know if I find notable differences.
>
> Regards, Heiko
>
> On 02 May 2016, at 12:33, Stuart Douglas <stuart.w.douglas at gmail.com> wrote:
>
> If you have a META-INF/jandex.idx file in a jar it will be used instead of
> indexing the jar. Unless you have a huge deployment I think you are unlikely
> to measure any differences though.
>
> Stuart
>
> On Mon, 2 May 2016 at 20:03 Heiko Braun <hbraun at redhat.com> wrote:
>>
>>
>> Are there any recommendations for making the deployment faster on WF? One
>> thing I was wondering about is whether certain subsystem support precomputed
>> jandex indexes?
>>
>> Regards, Heiko
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From jason.greene at redhat.com  Wed May 11 09:45:59 2016
From: jason.greene at redhat.com (Jason T. Greene)
Date: Wed, 11 May 2016 09:45:59 -0400 (EDT)
Subject: [wildfly-dev] Speed Up Deployment
In-Reply-To: <CAFm4XO3RyQ02p1Hpoe1V94B5EOi03FPp=reUQBFR_6fcZwUzOA@mail.gmail.com>
References: <9183EF05-D698-43F0-9252-03AA6E2310E9@redhat.com>
	<CAAoo=c6NejT_s9vy0VE3rLAsk8=MO-5f0dstxKdciiywCCwiYg@mail.gmail.com>
	<3B04C95C-795A-40A0-9B6E-78E83DE211A4@redhat.com>
	<CAFm4XO3RyQ02p1Hpoe1V94B5EOi03FPp=reUQBFR_6fcZwUzOA@mail.gmail.com>
Message-ID: <3BFDDD12-C8ED-4761-AD8D-4C88E2DF0816@redhat.com>

The only things that are indexed are classes within a deployment and classes that belong to specially tagged modules (very few fall into this category).

> On May 11, 2016, at 8:32 AM, Sanne Grinovero <sanne at hibernate.org> wrote:
> 
> Would you expect it to be beneficial to include an empty jandex.idx
> file in popular libraries which we expect to be visible to user
> deployments?
> 
> (i.e. hibernate-core.jar and similar cases).
> 
> I guess I could measure it, but I'm assuming that I'll need to apply
> this to many jars to see any measurable benefit.
> 
> Thanks,
> Sanne
> 
> 
>> On 2 May 2016 at 11:52, Heiko Braun <hbraun at redhat.com> wrote:
>> Thanks, I?ll try that and let you know if I find notable differences.
>> 
>> Regards, Heiko
>> 
>> On 02 May 2016, at 12:33, Stuart Douglas <stuart.w.douglas at gmail.com> wrote:
>> 
>> If you have a META-INF/jandex.idx file in a jar it will be used instead of
>> indexing the jar. Unless you have a huge deployment I think you are unlikely
>> to measure any differences though.
>> 
>> Stuart
>> 
>>> On Mon, 2 May 2016 at 20:03 Heiko Braun <hbraun at redhat.com> wrote:
>>> 
>>> 
>>> Are there any recommendations for making the deployment faster on WF? One
>>> thing I was wondering about is whether certain subsystem support precomputed
>>> jandex indexes?
>>> 
>>> Regards, Heiko
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> 
>> 
>> 
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From smarlow at redhat.com  Wed May 11 10:02:44 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 11 May 2016 10:02:44 -0400
Subject: [wildfly-dev] update on WildFly NoSQL prototype integration...
In-Reply-To: <CADGJaX9JiiEZw+8XqzsZjU2q5jcp3cnnx_7U3G_g4PgT86qQUw@mail.gmail.com>
References: <bf184686-ccbb-f6bf-3ce5-db00cb54bf6c@redhat.com>
	<CADGJaX9JiiEZw+8XqzsZjU2q5jcp3cnnx_7U3G_g4PgT86qQUw@mail.gmail.com>
Message-ID: <ad804aed-782b-272e-7cde-afbd1598107a@redhat.com>



On 05/10/2016 06:34 AM, Gunnar Morling wrote:
> Hi Scott,
>
> Thanks for driving this initiative!
>
> Some comments/questions inline.
>
> 2016-05-04 20:16 GMT+02:00 Scott Marlow <smarlow at redhat.com
> <mailto:smarlow at redhat.com>>:
>
>     Hi,
>
>     Below is an update on the WildFly NoSQL integration project.  The goal
>     is for deployed applications to have access to NoSQL databases (via
>     Hibernate OGM or native APIs).  Items 1-4, should be finished in our
>     first pass, with as much of the others items as we can do as well.
>
>     1. connection management will deal with obtaining NoSQL connections for
>     application use.
>
>       - borrow/share Hibernate OGM connection configuration setup code
>       - authentication integration
>       - support transport level security
>
>
> Any ideas how this code sharing could look like?
>
> Hibernate OGM should still be usable without WF; So maybe there should
> be a separate project/repo which defines an SPI to obtain/manage
> connections and implementations for different NoSQL stores?

Excellent suggestion,  perhaps the SPI could be under 
https://github.com/jboss, which is a common area for sharing.  Possible 
locations for creating the per NoSQL store implementations could be 
https://github.com/jboss or https://github.com/hibernate or 
https://github.com/wildfly.

>
> I think it'd be beneficial to define some sort of connection URL syntax
> which can be used in NoSQL datasource definitions:
>
>
> nosql:mongodb://192.168.1.100:27017[,another-host:another-port]/some_db?customParam1=xyz&customParam2=abc&...

The WildFly NoSQL subsystem configuration, would likely need separate 
fields for NoSQL datasource profiles/definition, instead of one long 
URL.  Internally, the WildFly subsystem could build a connection URL, if 
that becomes our common format.

>
> This common syntax might do for most cases, for others it might be
> needed to support specialized schemes handled by store-specific SPI
> implementations.

What are some examples that might need specialized schemes?  Would an 
embedded or in-process Infinispan/Cassandra be considered one of the 
specialized schemes because there are no remote connections?

>
> Regarding pooling, many NoSQL drivers do it in one way or another, so
> maybe leave that to drivers, at least in the first iteration?
>
>     2. CDI programming simplifications will make it easy to inject NoSQL
>     data into your application classes.
>
>       - https://github.com/antoinesd/javaee-nosql is initial idea
>
>
> +1 Sounds nice.
>
>
>     3. You will easily get a native NoSQL connection from the specified
>     NoSQL profile and use the native NOSQL (Cassandra/MongoDB/other) API in
>     your application.
>
>
> Would you take measures to e.g. prevent closing a connection in
> application code?

I think that this should be on the wish list, just not sure that we 
should always introduce the overhead of wrapping/proxying NoSQL 
connections to allow the check if the application.  Perhaps a "platform 
level" listener in the native NoSQL client code, that allows the 
platform to prevent applications from closing connections in some way.

>
>     4. You will also be able to easily use Hibernate OGM with the defined
>     NoSQL profiles (exactly how is TBD but will be awesome :-).
>       - Hibernate OGM static module is included.
>
>
> WDYM by "static module"? The Hibernate OGM Core module?

By "static module", I meant what we add to wildfly/modules/*.  Excellent 
question about which OGM modules, I meant any OGM that depends on 
Hibernate ORM, which I think is currently OGM Core.

>
> How would people add the OGM backend module for the NoSQL store of their
> choice? I suppose you don't mean to add all the backends we have to WF
> by default (as this would increase size quite a bit), so would people
> still use the module ZIP we provide?

If we use the OGM module ZIP, that should be extracted into a different 
folder than wildfly/modules/system/layers, to avoid confusing the EAP 
patch tool.  Having said that, I'm not sure how we will patch the OGM 
modules, if they are not all included in WildFly.  Perhaps, we might 
decide to include only certain ones.

Just for reference, my local 
hibernate-ogm-modules-wildfly10-5.0.0-SNAPSHOT.zip is 53mb (including 
OGM core).

>
>
>       - need to align with OGM dependencies (e.g. Hibernate ORM + other
>     dependencies).
>
>
> Note we aim at the ORM version part of WF at a given time. But there are
> times where we need a newer ORM version for a new OGM release (when
> using new SPIs not part in the ORM version coming with the currently
> released WF), so there should be a way to achieve that.

Are you thinking of the current Hibernate ORM master or the ORM 5.1 
branch?  Or perhaps a new branch based on 5.1, that doesn't have all of 
the ORM master branch changes?

>
>
>       - as mentioned above, OGM already has some connection setup code,
>     which might be good to share for WildFly + standalone NoSQL use.
>
>
> I'm not sure how re-usable this is. It's geared towards OGM's needs, I
> feel having a separate SPI dealing just with connections would be more
> useful.

+1

>
>
>       - once WildFly has a common NoSQLSource (not a DataSource) that OGM
>     can use, OGM will be enhanced to use it.
>
>
> +1
>
>     5. How best for the WildFly NoSQL subsystem to be optional?
>       - Is it enough to not run the wildfly/testsuite/nosql tests by
>     default?
>       - Or do we need to start a separate https://github.com/wildfly/nosql
>     project for the NoSQL subsystems?
>
>
> Would there be one OGM sub-system? Or one per NoSQL store?

I don't yet see a need for an OGM sub-system (I don't think OGM needs a 
separate WildFly deployment processer).  I think that some of the OGM 
deployment hacks will be done in Jipijapa (assuming we can change the 
JPA deployer to allow that).  I'm not exactly sure what your asking here 
with regard to question #5, about one OGM sub-system or one per NosQL 
store.  Do you mean "static module" instead of sub-system?

I think that there will be one WildFly sub-system per NoSQL store but 
that is based on the current prototype and the discussion so far.

> And how would
> people add them (see above)? As said before in this thread, there should
> be a way to update modules of specific stores to get the latest and
> greatest.

Not sure yet, maybe with-in minor releases it will be possible.

>
>     6. transaction enlistment
>
>     7. compensating transactions
>
>     8. runtime application monitoring
>
>     9. How soon can we make an evaluation distribution available for use on
>     OpenStack/OpenShift?
>       - Would be great if we could do some load testing with all NoSQL
>     components.
>       - Would be great if we could enable others to also test.
>
>     10. Are there any problems with our WildFly NoSQL subsystem injecting
>     MongoDatabase connections via:
>
>         @Resource(lookup = "java:jboss/mongodb/test") MongoDatabase db;
>
>       - No @Resource support expected for standalone Java, TBD is whether a
>     runtime library can be used.
>       - Any problems expected on other EE application servers if this
>     approach becomes popular?
>
>     11. WIP topic branch is at
>     https://github.com/scottmarlow/wildfly/tree/nosql-dev9.  Note that every
>     once in a while, commits are squashed and pushed to nosql-devN+1.
>
>
> Any pointers where to start looking to see what's working already?

https://github.com/scottmarlow/wildfly/tree/nosql-dev9 is still active. :)


>
>     12. Add proper unit tests
>       - multi-threaded NoSQL access to show that works at all.
>       - use NoSQL from different EE components (e.g. JAX-RS).
>       - other use cases that represent how NoSQL could be used from WildFly.
>
>     Feedback/help is welcome!
>
>     Thanks,
>     Scott
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>

From smarlow at redhat.com  Wed May 11 10:48:56 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 11 May 2016 10:48:56 -0400
Subject: [wildfly-dev] update on WildFly NoSQL prototype integration...
In-Reply-To: <5ae66735-16b6-fc9a-9be3-ab85fd0ccac7@redhat.com>
References: <bf184686-ccbb-f6bf-3ce5-db00cb54bf6c@redhat.com>
	<572B875C.20903@redhat.com>
	<CAMrRDdwWQecKAd+9g+syeFqzDkF=ECuGy6nqqfAzG0gUJra_WA@mail.gmail.com>
	<5ae66735-16b6-fc9a-9be3-ab85fd0ccac7@redhat.com>
Message-ID: <e81d6325-4a0a-4292-22d5-4e81e3e2671f@redhat.com>


>>     > 7. compensating transactions
>>     >
>>
>>     Another huge area.
>>
>>     I would let the use-cases from WildFly/Swarm drive this.
>>
>>     A simple way to start is to have a SPI that apps can implement in case
>>     the transaction is MARKED_FOR_ROLLBACK (hooks to an enlisted
>>     XAResource).
>>
>>
>> We implemented those in IJ (even if in much more standard JCA
>> environment), and maybe we could share and eventually copy/paste some
>> code.
>
> Check out "MongoDB integration test with compensating transactions"
> https://github.com/scottmarlow/wildfly/commit/9bd67964a9259416add73cac47328cec5127d25c,
> which is a good start.  We can work forward from what we have and ideas
> from IJ.
>

Stefano, Could you please post github links to some of the IJ 
compensating code?  It would be great to express the idea of what is 
being accomplished in IJ (with regard to compensating transactions), as 
well.

Thanks,
Scott

From smaestri at redhat.com  Thu May 12 03:36:54 2016
From: smaestri at redhat.com (Stefano Maestri)
Date: Thu, 12 May 2016 09:36:54 +0200
Subject: [wildfly-dev] update on WildFly NoSQL prototype integration...
In-Reply-To: <e81d6325-4a0a-4292-22d5-4e81e3e2671f@redhat.com>
References: <bf184686-ccbb-f6bf-3ce5-db00cb54bf6c@redhat.com>
	<572B875C.20903@redhat.com>
	<CAMrRDdwWQecKAd+9g+syeFqzDkF=ECuGy6nqqfAzG0gUJra_WA@mail.gmail.com>
	<5ae66735-16b6-fc9a-9be3-ab85fd0ccac7@redhat.com>
	<e81d6325-4a0a-4292-22d5-4e81e3e2671f@redhat.com>
Message-ID: <CAMrRDdybpA-5LNJgLL+yyawshE9XL_COG72DZUKdjf-co3q+iw@mail.gmail.com>

On Wed, May 11, 2016 at 4:48 PM, Scott Marlow <smarlow at redhat.com> wrote:

>
> >>     > 7. compensating transactions
> >>     >
> >>
> >>     Another huge area.
> >>
> >>     I would let the use-cases from WildFly/Swarm drive this.
> >>
> >>     A simple way to start is to have a SPI that apps can implement in
> case
> >>     the transaction is MARKED_FOR_ROLLBACK (hooks to an enlisted
> >>     XAResource).
> >>
> >>
> >> We implemented those in IJ (even if in much more standard JCA
> >> environment), and maybe we could share and eventually copy/paste some
> >> code.
> >
> > Check out "MongoDB integration test with compensating transactions"
> >
> https://github.com/scottmarlow/wildfly/commit/9bd67964a9259416add73cac47328cec5127d25c
> ,
> > which is a good start.  We can work forward from what we have and ideas
> > from IJ.
> >
>
> Stefano, Could you please post github links to some of the IJ
> compensating code?  It would be great to express the idea of what is
> being accomplished in IJ (with regard to compensating transactions), as
> well.
>
>

Hi Scott,
I take a mistake inserting my comment in previous mail. My comment was
referring on your point 6 (for which Jesper already provided code)....sorry
I'm not yet used to this Gmail collapse long quoted text "feature".....
Regarding point 7, I agree use-cases from WildFly/Swarm are a good start.

regards
S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160512/2622fa97/attachment.html 

From emmanuel at hibernate.org  Thu May 12 07:24:34 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 12 May 2016 13:24:34 +0200
Subject: [wildfly-dev] update on WildFly NoSQL prototype integration...
In-Reply-To: <ad804aed-782b-272e-7cde-afbd1598107a@redhat.com>
References: <bf184686-ccbb-f6bf-3ce5-db00cb54bf6c@redhat.com>
	<CADGJaX9JiiEZw+8XqzsZjU2q5jcp3cnnx_7U3G_g4PgT86qQUw@mail.gmail.com>
	<ad804aed-782b-272e-7cde-afbd1598107a@redhat.com>
Message-ID: <4E9D7BDF-2D04-42AA-9D53-649A63CF66F0@hibernate.org>



On 11 mai 2016, at 16:02, Scott Marlow <smarlow at redhat.com> wrote:

>> Hibernate OGM should still be usable without WF; So maybe there should
>> be a separate project/repo which defines an SPI to obtain/manage
>> connections and implementations for different NoSQL stores?
> 
> Excellent suggestion,  perhaps the SPI could be under 
> https://github.com/jboss, which is a common area for sharing.  Possible 
> locations for creating the per NoSQL store implementations could be 
> https://github.com/jboss or https://github.com/hibernate or 
> https://github.com/wildfly.

I'm starting to think that this might be way overkill. If we are creating a sub project just to share between 20 and 50 lines of code per provider and the overhead code to abstract property configuration to plus OGM and WF ones, we are losing more than gaining. 

Thoughts ?


From gunnar at hibernate.org  Thu May 12 08:13:46 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 12 May 2016 14:13:46 +0200
Subject: [wildfly-dev] update on WildFly NoSQL prototype integration...
In-Reply-To: <4E9D7BDF-2D04-42AA-9D53-649A63CF66F0@hibernate.org>
References: <bf184686-ccbb-f6bf-3ce5-db00cb54bf6c@redhat.com>
	<CADGJaX9JiiEZw+8XqzsZjU2q5jcp3cnnx_7U3G_g4PgT86qQUw@mail.gmail.com>
	<ad804aed-782b-272e-7cde-afbd1598107a@redhat.com>
	<4E9D7BDF-2D04-42AA-9D53-649A63CF66F0@hibernate.org>
Message-ID: <CADGJaX_7Agt2H1j+e3af61TxL2bMLsGBNAYdhMtZi_wCH2PAQw@mail.gmail.com>

If OGM should be able to work with connections managed by the container,
some sort of "neutral" SPI is needed IMO. Otherwise we'd have to create
some sort of abstraction *in* OGM to ensure it still can be used in other
environments than WF.

I think best would be to start with a PoC and see things are going to look
like. Then we still can decide where it'd be best located or whether it's
better to avoid re-use and accept some duplication.




2016-05-12 13:24 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:

>
>
> On 11 mai 2016, at 16:02, Scott Marlow <smarlow at redhat.com> wrote:
>
> >> Hibernate OGM should still be usable without WF; So maybe there should
> >> be a separate project/repo which defines an SPI to obtain/manage
> >> connections and implementations for different NoSQL stores?
> >
> > Excellent suggestion,  perhaps the SPI could be under
> > https://github.com/jboss, which is a common area for sharing.  Possible
> > locations for creating the per NoSQL store implementations could be
> > https://github.com/jboss or https://github.com/hibernate or
> > https://github.com/wildfly.
>
> I'm starting to think that this might be way overkill. If we are creating
> a sub project just to share between 20 and 50 lines of code per provider
> and the overhead code to abstract property configuration to plus OGM and WF
> ones, we are losing more than gaining.
>
> Thoughts ?
>
> _______________________________________________
> 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/20160512/1d160488/attachment-0001.html 

From sanne at hibernate.org  Thu May 12 08:34:30 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 12 May 2016 13:34:30 +0100
Subject: [wildfly-dev] Speed Up Deployment
In-Reply-To: <3BFDDD12-C8ED-4761-AD8D-4C88E2DF0816@redhat.com>
References: <9183EF05-D698-43F0-9252-03AA6E2310E9@redhat.com>
	<CAAoo=c6NejT_s9vy0VE3rLAsk8=MO-5f0dstxKdciiywCCwiYg@mail.gmail.com>
	<3B04C95C-795A-40A0-9B6E-78E83DE211A4@redhat.com>
	<CAFm4XO3RyQ02p1Hpoe1V94B5EOi03FPp=reUQBFR_6fcZwUzOA@mail.gmail.com>
	<3BFDDD12-C8ED-4761-AD8D-4C88E2DF0816@redhat.com>
Message-ID: <CAFm4XO1jWRhTP-dCUW1ODChYtQ5ZBmxpZGQP4fsAgLY+UWV94Q@mail.gmail.com>

On 11 May 2016 at 14:45, Jason T. Greene <jason.greene at redhat.com> wrote:
> The only things that are indexed are classes within a deployment and classes that belong to specially tagged modules (very few fall into this category).

Thanks for pointing that out, I'll not waste time on trying it then :)

Thanks,
Sanne

>
>> On May 11, 2016, at 8:32 AM, Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> Would you expect it to be beneficial to include an empty jandex.idx
>> file in popular libraries which we expect to be visible to user
>> deployments?
>>
>> (i.e. hibernate-core.jar and similar cases).
>>
>> I guess I could measure it, but I'm assuming that I'll need to apply
>> this to many jars to see any measurable benefit.
>>
>> Thanks,
>> Sanne
>>
>>
>>> On 2 May 2016 at 11:52, Heiko Braun <hbraun at redhat.com> wrote:
>>> Thanks, I?ll try that and let you know if I find notable differences.
>>>
>>> Regards, Heiko
>>>
>>> On 02 May 2016, at 12:33, Stuart Douglas <stuart.w.douglas at gmail.com> wrote:
>>>
>>> If you have a META-INF/jandex.idx file in a jar it will be used instead of
>>> indexing the jar. Unless you have a huge deployment I think you are unlikely
>>> to measure any differences though.
>>>
>>> Stuart
>>>
>>>> On Mon, 2 May 2016 at 20:03 Heiko Braun <hbraun at redhat.com> wrote:
>>>>
>>>>
>>>> Are there any recommendations for making the deployment faster on WF? One
>>>> thing I was wondering about is whether certain subsystem support precomputed
>>>> jandex indexes?
>>>>
>>>> Regards, Heiko
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From sanne at hibernate.org  Thu May 12 08:41:41 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 12 May 2016 13:41:41 +0100
Subject: [wildfly-dev] update on WildFly NoSQL prototype integration...
In-Reply-To: <4E9D7BDF-2D04-42AA-9D53-649A63CF66F0@hibernate.org>
References: <bf184686-ccbb-f6bf-3ce5-db00cb54bf6c@redhat.com>
	<CADGJaX9JiiEZw+8XqzsZjU2q5jcp3cnnx_7U3G_g4PgT86qQUw@mail.gmail.com>
	<ad804aed-782b-272e-7cde-afbd1598107a@redhat.com>
	<4E9D7BDF-2D04-42AA-9D53-649A63CF66F0@hibernate.org>
Message-ID: <CAFm4XO38HRFSzwhbgZX0bxDPJq=BaHgW9JbtgaR=rz3VF5-ezA@mail.gmail.com>

On 12 May 2016 at 12:24, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>
>
> On 11 mai 2016, at 16:02, Scott Marlow <smarlow at redhat.com> wrote:
>
>>> Hibernate OGM should still be usable without WF; So maybe there should
>>> be a separate project/repo which defines an SPI to obtain/manage
>>> connections and implementations for different NoSQL stores?
>>
>> Excellent suggestion,  perhaps the SPI could be under
>> https://github.com/jboss, which is a common area for sharing.  Possible
>> locations for creating the per NoSQL store implementations could be
>> https://github.com/jboss or https://github.com/hibernate or
>> https://github.com/wildfly.
>
> I'm starting to think that this might be way overkill. If we are creating a sub project just to share between 20 and 50 lines of code per provider and the overhead code to abstract property configuration to plus OGM and WF ones, we are losing more than gaining.
>
> Thoughts ?

I agree it's overkill, and have an alternative proposal:

Hibernate OGM should define an interface which is appropriate for its
own consumption; the Wildfly NoSQL subssystem can have its own
interface so to not depend on OGM, but they would be somewhat similar
for each given NoSQL technology we intend to support in this way.

Then JipiJapa can inject an adaptor into the OGM boostrap phase,
delegating from one to the other. So only the OGM specific JipiJapa
module would need to depend on both interfaces.
If this dependency is not desirable either, then I think we can live
with a non-typesafe generic provider of things.

Thanks,
Sanne


From smarlow at redhat.com  Thu May 12 09:31:37 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Thu, 12 May 2016 09:31:37 -0400
Subject: [wildfly-dev] update on WildFly NoSQL prototype integration...
In-Reply-To: <4E9D7BDF-2D04-42AA-9D53-649A63CF66F0@hibernate.org>
References: <bf184686-ccbb-f6bf-3ce5-db00cb54bf6c@redhat.com>
	<CADGJaX9JiiEZw+8XqzsZjU2q5jcp3cnnx_7U3G_g4PgT86qQUw@mail.gmail.com>
	<ad804aed-782b-272e-7cde-afbd1598107a@redhat.com>
	<4E9D7BDF-2D04-42AA-9D53-649A63CF66F0@hibernate.org>
Message-ID: <e7ddaf7e-4031-cd18-9632-3d36864e1055@redhat.com>



On 05/12/2016 07:24 AM, Emmanuel Bernard wrote:
>
>
> On 11 mai 2016, at 16:02, Scott Marlow <smarlow at redhat.com> wrote:
>
>>> Hibernate OGM should still be usable without WF; So maybe there should
>>> be a separate project/repo which defines an SPI to obtain/manage
>>> connections and implementations for different NoSQL stores?
>>
>> Excellent suggestion,  perhaps the SPI could be under
>> https://github.com/jboss, which is a common area for sharing.  Possible
>> locations for creating the per NoSQL store implementations could be
>> https://github.com/jboss or https://github.com/hibernate or
>> https://github.com/wildfly.
>
> I'm starting to think that this might be way overkill. If we are creating a sub project just to share between 20 and 50 lines of code per provider and the overhead code to abstract property configuration to plus OGM and WF ones, we are losing more than gaining.
>
> Thoughts ?
>

It could be overkill.  Mostly, I was noticing that OGM is already 
abstracting some connection setup and my initial impression was that we 
might like to do something similar in each WildFly NoSQL subsystem. 
Then, I was thinking about whether to duplicate the code or not.  Since, 
this is purely internal only, we can probably start with duplicating the 
connection setup and later consider if we can (attempt) sharing some of 
the connection setup.


From smarlow at redhat.com  Thu May 12 09:32:21 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Thu, 12 May 2016 09:32:21 -0400
Subject: [wildfly-dev] update on WildFly NoSQL prototype integration...
In-Reply-To: <CADGJaX_7Agt2H1j+e3af61TxL2bMLsGBNAYdhMtZi_wCH2PAQw@mail.gmail.com>
References: <bf184686-ccbb-f6bf-3ce5-db00cb54bf6c@redhat.com>
	<CADGJaX9JiiEZw+8XqzsZjU2q5jcp3cnnx_7U3G_g4PgT86qQUw@mail.gmail.com>
	<ad804aed-782b-272e-7cde-afbd1598107a@redhat.com>
	<4E9D7BDF-2D04-42AA-9D53-649A63CF66F0@hibernate.org>
	<CADGJaX_7Agt2H1j+e3af61TxL2bMLsGBNAYdhMtZi_wCH2PAQw@mail.gmail.com>
Message-ID: <21dc0570-0a84-1e96-d458-1e689fb5bfc0@redhat.com>



On 05/12/2016 08:13 AM, Gunnar Morling wrote:
> If OGM should be able to work with connections managed by the container,
> some sort of "neutral" SPI is needed IMO. Otherwise we'd have to create
> some sort of abstraction *in* OGM to ensure it still can be used in
> other environments than WF.

This makes sense, thanks!

>
> I think best would be to start with a PoC and see things are going to
> look like. Then we still can decide where it'd be best located or
> whether it's better to avoid re-use and accept some duplication.

+1

>
>
>
>
> 2016-05-12 13:24 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org
> <mailto:emmanuel at hibernate.org>>:
>
>
>
>     On 11 mai 2016, at 16:02, Scott Marlow <smarlow at redhat.com
>     <mailto:smarlow at redhat.com>> wrote:
>
>     >> Hibernate OGM should still be usable without WF; So maybe there should
>     >> be a separate project/repo which defines an SPI to obtain/manage
>     >> connections and implementations for different NoSQL stores?
>     >
>     > Excellent suggestion,  perhaps the SPI could be under
>     > https://github.com/jboss, which is a common area for sharing.  Possible
>     > locations for creating the per NoSQL store implementations could be
>     > https://github.com/jboss or https://github.com/hibernate or
>     > https://github.com/wildfly.
>
>     I'm starting to think that this might be way overkill. If we are
>     creating a sub project just to share between 20 and 50 lines of code
>     per provider and the overhead code to abstract property
>     configuration to plus OGM and WF ones, we are losing more than gaining.
>
>     Thoughts ?
>
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>

From davide at hibernate.org  Thu May 12 09:35:31 2016
From: davide at hibernate.org (Davide D'Alto)
Date: Thu, 12 May 2016 14:35:31 +0100
Subject: [wildfly-dev] update on WildFly NoSQL prototype integration...
In-Reply-To: <CAFm4XO38HRFSzwhbgZX0bxDPJq=BaHgW9JbtgaR=rz3VF5-ezA@mail.gmail.com>
References: <bf184686-ccbb-f6bf-3ce5-db00cb54bf6c@redhat.com>
	<CADGJaX9JiiEZw+8XqzsZjU2q5jcp3cnnx_7U3G_g4PgT86qQUw@mail.gmail.com>
	<ad804aed-782b-272e-7cde-afbd1598107a@redhat.com>
	<4E9D7BDF-2D04-42AA-9D53-649A63CF66F0@hibernate.org>
	<CAFm4XO38HRFSzwhbgZX0bxDPJq=BaHgW9JbtgaR=rz3VF5-ezA@mail.gmail.com>
Message-ID: <CANoTJYMnn2vN6TWuE-hOQLrfhMNh32M3Uv9yTjJypQemtm8pUQ@mail.gmail.com>

> Hibernate OGM should define an interface which is appropriate for its
> own consumption; the Wildfly NoSQL subssystem can have its own
> interface so to not depend on OGM, but they would be somewhat similar
> for each given NoSQL technology we intend to support in this way.

> Then JipiJapa can inject an adaptor into the OGM boostrap phase,
> delegating from one to the other. So only the OGM specific JipiJapa
> module would need to depend on both interfaces.
> If this dependency is not desirable either, then I think we can live
> with a non-typesafe generic provider of things.

+1
This looks like a nice trade-off.
It will allow us to create a POC that can eventually evolve into a separate
project.



On Thu, May 12, 2016 at 1:41 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> On 12 May 2016 at 12:24, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> >
> >
> > On 11 mai 2016, at 16:02, Scott Marlow <smarlow at redhat.com> wrote:
> >
> >>> Hibernate OGM should still be usable without WF; So maybe there should
> >>> be a separate project/repo which defines an SPI to obtain/manage
> >>> connections and implementations for different NoSQL stores?
> >>
> >> Excellent suggestion,  perhaps the SPI could be under
> >> https://github.com/jboss, which is a common area for sharing.  Possible
> >> locations for creating the per NoSQL store implementations could be
> >> https://github.com/jboss or https://github.com/hibernate or
> >> https://github.com/wildfly.
> >
> > I'm starting to think that this might be way overkill. If we are
> creating a sub project just to share between 20 and 50 lines of code per
> provider and the overhead code to abstract property configuration to plus
> OGM and WF ones, we are losing more than gaining.
> >
> > Thoughts ?
>
> I agree it's overkill, and have an alternative proposal:
>
> Hibernate OGM should define an interface which is appropriate for its
> own consumption; the Wildfly NoSQL subssystem can have its own
> interface so to not depend on OGM, but they would be somewhat similar
> for each given NoSQL technology we intend to support in this way.
>
> Then JipiJapa can inject an adaptor into the OGM boostrap phase,
> delegating from one to the other. So only the OGM specific JipiJapa
> module would need to depend on both interfaces.
> If this dependency is not desirable either, then I think we can live
> with a non-typesafe generic provider of things.
>
> Thanks,
> Sanne
>
> _______________________________________________
> 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/20160512/40249dbe/attachment-0001.html 

From smarlow at redhat.com  Thu May 12 09:50:44 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Thu, 12 May 2016 09:50:44 -0400
Subject: [wildfly-dev] update on WildFly NoSQL prototype integration...
In-Reply-To: <CAFm4XO38HRFSzwhbgZX0bxDPJq=BaHgW9JbtgaR=rz3VF5-ezA@mail.gmail.com>
References: <bf184686-ccbb-f6bf-3ce5-db00cb54bf6c@redhat.com>
	<CADGJaX9JiiEZw+8XqzsZjU2q5jcp3cnnx_7U3G_g4PgT86qQUw@mail.gmail.com>
	<ad804aed-782b-272e-7cde-afbd1598107a@redhat.com>
	<4E9D7BDF-2D04-42AA-9D53-649A63CF66F0@hibernate.org>
	<CAFm4XO38HRFSzwhbgZX0bxDPJq=BaHgW9JbtgaR=rz3VF5-ezA@mail.gmail.com>
Message-ID: <fb884efb-02b3-657b-85a8-1331611e6f29@redhat.com>



On 05/12/2016 08:41 AM, Sanne Grinovero wrote:
> On 12 May 2016 at 12:24, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>>
>>
>> On 11 mai 2016, at 16:02, Scott Marlow <smarlow at redhat.com> wrote:
>>
>>>> Hibernate OGM should still be usable without WF; So maybe there should
>>>> be a separate project/repo which defines an SPI to obtain/manage
>>>> connections and implementations for different NoSQL stores?
>>>
>>> Excellent suggestion,  perhaps the SPI could be under
>>> https://github.com/jboss, which is a common area for sharing.  Possible
>>> locations for creating the per NoSQL store implementations could be
>>> https://github.com/jboss or https://github.com/hibernate or
>>> https://github.com/wildfly.
>>
>> I'm starting to think that this might be way overkill. If we are creating a sub project just to share between 20 and 50 lines of code per provider and the overhead code to abstract property configuration to plus OGM and WF ones, we are losing more than gaining.
>>
>> Thoughts ?
>
> I agree it's overkill, and have an alternative proposal:
>
> Hibernate OGM should define an interface which is appropriate for its
> own consumption; the Wildfly NoSQL subssystem can have its own
> interface so to not depend on OGM, but they would be somewhat similar
> for each given NoSQL technology we intend to support in this way.

Just to clarify what we were discussing.  The idea for sharing 
connection setup, would of involved extracting that code from OGM, into 
a separate jar that OGM + WildFly NoSQL could depend on.

>
> Then JipiJapa can inject an adaptor into the OGM boostrap phase,
> delegating from one to the other. So only the OGM specific JipiJapa
> module would need to depend on both interfaces.
> If this dependency is not desirable either, then I think we can live
> with a non-typesafe generic provider of things.

I'm not exactly sure of what you mean here about JipiJapa injecting an 
adaptor into the OGM bootstrap phase.  Are you talking about how we want 
to have a JipiJapa adapter for OGM, that (magically) leaks native NoSQL 
dependencies into application deployments, depending on which NoSQL 
backend store is targeted?  That may be different than what we are 
talking about here but that also needs a SPI, so the JipiJapa adapter 
can ask the JPA PersistenceProvider what the backend store is (or 
something like that).

[1] talks about some of the (OGM/ORM related) dependency issues that are 
also important to solve.  I'm not really sure of the best way to address 
the [1] dependency issues that involve WildFly Clustering, WildFly JPA 
container, WildFly JipiJapa adapters for Hibernate ORM, 
Hibernate-Infinispan, Infinispan.

I agree with Gunnar, that we should continue with POC coding but also 
really love the feedback/discussion going on here.  I'd like to ping 
some additional teams as well soon (Infinispan dev, native NoSQL store 
teams, others that may need to extend the WildFly NoSQL infrastructure).

Scott

[1] https://github.com/jboss/jboss-nosql/issues/3
>
> Thanks,
> Sanne
>

From jperkins at redhat.com  Thu May 12 23:32:58 2016
From: jperkins at redhat.com (James Perkins)
Date: Thu, 12 May 2016 20:32:58 -0700
Subject: [wildfly-dev] One Doc to Rule Them All
Message-ID: <CADGwLph3Rw5B6b_uWFQz4V0ZoCRpOxVEoEpqtjQjzt_FT+Htmw@mail.gmail.com>

I've been reading the WildFly documentation [1] quite a bit lately and
noticing a lot of issues. Sometimes it references WildFly 8 in the WildFly
10 (or 9) documentation. Sometimes it references JBoss AS 7. Links take you
to old documentation, e.g. a WFLY10 doc takes you to a page for WFLY8.
Sometimes documentation is just plain out of date referencing behavior that
has possibly been removed or replaced by something better.

This has happened because we keep copying the documentation over each time
we have a new version. Overall this makes sense as a lot of it doesn't need
to be changed. However it leaves reading the documentation confusing.
Reading documentation for WildFly 10 and seeing WildFly 8 in the text with
a link for AS72 isn't very user friendly as I'm sure we can all agree.

There's a few different ways we could go with this.

Approach 1:
One, probably the easiest, is to use a single confluence project. We'd need
to remove the version numbers from the text, which I think we should do
anyway. Instead of referencing WildFly 10 we just reference it as WildFly.

An issue I can think of with this approach is some how annotating or
referencing that parts of the documentation only work with ${version}. For
example new features would have to be noted they only work with ${version}+.


Approach 2:
Essentially he same as approach 1 only do allow different Confluence
projects for the different Java EE target version. So WIldFly 8, 9 and 10
would all be documented under something like WFLYEE7.

Approach 3
Switch to using something like asciidoc which can use variables and
generate links to the correct content. While this approach is probably
takes the most work up front, it seems like like it would be easier to
maintain between releases.

Any other suggestions are welcome.

[1]: https://docs.jboss.org/author/display/WFLY10/Documentation

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

From nickarls at gmail.com  Fri May 13 00:26:13 2016
From: nickarls at gmail.com (Nicklas Karlsson)
Date: Fri, 13 May 2016 07:26:13 +0300
Subject: [wildfly-dev] One Doc to Rule Them All
In-Reply-To: <CADGwLph3Rw5B6b_uWFQz4V0ZoCRpOxVEoEpqtjQjzt_FT+Htmw@mail.gmail.com>
References: <CADGwLph3Rw5B6b_uWFQz4V0ZoCRpOxVEoEpqtjQjzt_FT+Htmw@mail.gmail.com>
Message-ID: <CAFzcPXGt8uMVd_bq2a36pCPD4gShmV--TwP2n2ARnPTb6Fpz2A@mail.gmail.com>

I can confirm this exists even outside documentation. One example is
http://www.jboss.org/get-involved/ where the reference list says "WildFly
8". Understandable since the interview was made in the age of WF8 but there
are plenty of other examples around.

On Fri, May 13, 2016 at 6:32 AM, James Perkins <jperkins at redhat.com> wrote:

> I've been reading the WildFly documentation [1] quite a bit lately and
> noticing a lot of issues. Sometimes it references WildFly 8 in the WildFly
> 10 (or 9) documentation. Sometimes it references JBoss AS 7. Links take you
> to old documentation, e.g. a WFLY10 doc takes you to a page for WFLY8.
> Sometimes documentation is just plain out of date referencing behavior that
> has possibly been removed or replaced by something better.
>
> This has happened because we keep copying the documentation over each time
> we have a new version. Overall this makes sense as a lot of it doesn't need
> to be changed. However it leaves reading the documentation confusing.
> Reading documentation for WildFly 10 and seeing WildFly 8 in the text with
> a link for AS72 isn't very user friendly as I'm sure we can all agree.
>
> There's a few different ways we could go with this.
>
> Approach 1:
> One, probably the easiest, is to use a single confluence project. We'd
> need to remove the version numbers from the text, which I think we should
> do anyway. Instead of referencing WildFly 10 we just reference it as
> WildFly.
>
> An issue I can think of with this approach is some how annotating or
> referencing that parts of the documentation only work with ${version}. For
> example new features would have to be noted they only work with ${version}+.
>
>
> Approach 2:
> Essentially he same as approach 1 only do allow different Confluence
> projects for the different Java EE target version. So WIldFly 8, 9 and 10
> would all be documented under something like WFLYEE7.
>
> Approach 3
> Switch to using something like asciidoc which can use variables and
> generate links to the correct content. While this approach is probably
> takes the most work up front, it seems like like it would be easier to
> maintain between releases.
>
> Any other suggestions are welcome.
>
> [1]: https://docs.jboss.org/author/display/WFLY10/Documentation
>
> --
> 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
>



-- 
Nicklas Karlsson, +358 40 5062266
Vaakunatie 10 as 7, 20780 Kaarina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160513/47821207/attachment.html 

From david.lloyd at redhat.com  Fri May 13 09:12:53 2016
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Fri, 13 May 2016 08:12:53 -0500
Subject: [wildfly-dev] One Doc to Rule Them All
In-Reply-To: <CADGwLph3Rw5B6b_uWFQz4V0ZoCRpOxVEoEpqtjQjzt_FT+Htmw@mail.gmail.com>
References: <CADGwLph3Rw5B6b_uWFQz4V0ZoCRpOxVEoEpqtjQjzt_FT+Htmw@mail.gmail.com>
Message-ID: <5735D2D5.1070808@redhat.com>

I like approach 3, assuming that it'll move in to e.g. GitHub.  If 
there's an update to a doc, it's a lot easier to backport using git than 
Confluence.  Less chance of old docs getting abandoned, and easier for 
users to contribute fixes and updates if they can just open a PR for 
each affected version.  We're already reasonably well-trained to deal 
with old branches.

I don't know how we'd organize it though; I've never done multi-document 
things using asciidoc, and also we'd have to publish it somehow 
(preferably in an automated manner).

On 05/12/2016 10:32 PM, James Perkins wrote:
> I've been reading the WildFly documentation [1] quite a bit lately and
> noticing a lot of issues. Sometimes it references WildFly 8 in the
> WildFly 10 (or 9) documentation. Sometimes it references JBoss AS 7.
> Links take you to old documentation, e.g. a WFLY10 doc takes you to a
> page for WFLY8. Sometimes documentation is just plain out of date
> referencing behavior that has possibly been removed or replaced by
> something better.
>
> This has happened because we keep copying the documentation over each
> time we have a new version. Overall this makes sense as a lot of it
> doesn't need to be changed. However it leaves reading the documentation
> confusing. Reading documentation for WildFly 10 and seeing WildFly 8 in
> the text with a link for AS72 isn't very user friendly as I'm sure we
> can all agree.
>
> There's a few different ways we could go with this.
>
> Approach 1:
> One, probably the easiest, is to use a single confluence project. We'd
> need to remove the version numbers from the text, which I think we
> should do anyway. Instead of referencing WildFly 10 we just reference it
> as WildFly.
>
> An issue I can think of with this approach is some how annotating or
> referencing that parts of the documentation only work with ${version}.
> For example new features would have to be noted they only work with
> ${version}+.
>
>
> Approach 2:
> Essentially he same as approach 1 only do allow different Confluence
> projects for the different Java EE target version. So WIldFly 8, 9 and
> 10 would all be documented under something like WFLYEE7.
>
> Approach 3
> Switch to using something like asciidoc which can use variables and
> generate links to the correct content. While this approach is probably
> takes the most work up front, it seems like like it would be easier to
> maintain between releases.
>
> Any other suggestions are welcome.
>
> [1]: https://docs.jboss.org/author/display/WFLY10/Documentation
>
> --
> 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
>

-- 
- DML

From hrupp at redhat.com  Fri May 13 09:54:07 2016
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 13 May 2016 15:54:07 +0200
Subject: [wildfly-dev] One Doc to Rule Them All
In-Reply-To: <5735D2D5.1070808@redhat.com>
References: <CADGwLph3Rw5B6b_uWFQz4V0ZoCRpOxVEoEpqtjQjzt_FT+Htmw@mail.gmail.com>
	<5735D2D5.1070808@redhat.com>
Message-ID: <07BF8E48-F7C0-4606-8887-853C63186BBF@redhat.com>

On 13 May 2016, at 15:12, David M. Lloyd wrote:

> I don't know how we'd organize it though; I've never done multi-document
> things using asciidoc, and also we'd have to publish it somehow
> (preferably in an automated manner).

We have a build pipeline for the hawkular.org website, where the
input is the pages branch of https://github.com/hawkular/hawkular.github.io

If interested talk to Jirka (in cc)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160513/462527ed/attachment.bin 

From jperkins at redhat.com  Fri May 13 11:46:54 2016
From: jperkins at redhat.com (James Perkins)
Date: Fri, 13 May 2016 08:46:54 -0700
Subject: [wildfly-dev] One Doc to Rule Them All
In-Reply-To: <5735D2D5.1070808@redhat.com>
References: <CADGwLph3Rw5B6b_uWFQz4V0ZoCRpOxVEoEpqtjQjzt_FT+Htmw@mail.gmail.com>
	<5735D2D5.1070808@redhat.com>
Message-ID: <CADGwLpgPP6u5CC5BBWv5R2C-sJubQnuHY88NCPBqq_sf=Rvueg@mail.gmail.com>

Yeah I think I prefer approach 3 myself. It just might be a lot of work to
get there.

I was thinking we could either use the gh-pages/github.io approach or even
just make it part of the wildfly.org [1] repo in a docs subdirectory. I see
it being nice in some ways having it on http://wildfly.org.

[1]: https://github.com/wildfly/wildfly.org

On Fri, May 13, 2016 at 6:12 AM, David M. Lloyd <david.lloyd at redhat.com>
wrote:

> I like approach 3, assuming that it'll move in to e.g. GitHub.  If
> there's an update to a doc, it's a lot easier to backport using git than
> Confluence.  Less chance of old docs getting abandoned, and easier for
> users to contribute fixes and updates if they can just open a PR for
> each affected version.  We're already reasonably well-trained to deal
> with old branches.
>
> I don't know how we'd organize it though; I've never done multi-document
> things using asciidoc, and also we'd have to publish it somehow
> (preferably in an automated manner).
>
> On 05/12/2016 10:32 PM, James Perkins wrote:
> > I've been reading the WildFly documentation [1] quite a bit lately and
> > noticing a lot of issues. Sometimes it references WildFly 8 in the
> > WildFly 10 (or 9) documentation. Sometimes it references JBoss AS 7.
> > Links take you to old documentation, e.g. a WFLY10 doc takes you to a
> > page for WFLY8. Sometimes documentation is just plain out of date
> > referencing behavior that has possibly been removed or replaced by
> > something better.
> >
> > This has happened because we keep copying the documentation over each
> > time we have a new version. Overall this makes sense as a lot of it
> > doesn't need to be changed. However it leaves reading the documentation
> > confusing. Reading documentation for WildFly 10 and seeing WildFly 8 in
> > the text with a link for AS72 isn't very user friendly as I'm sure we
> > can all agree.
> >
> > There's a few different ways we could go with this.
> >
> > Approach 1:
> > One, probably the easiest, is to use a single confluence project. We'd
> > need to remove the version numbers from the text, which I think we
> > should do anyway. Instead of referencing WildFly 10 we just reference it
> > as WildFly.
> >
> > An issue I can think of with this approach is some how annotating or
> > referencing that parts of the documentation only work with ${version}.
> > For example new features would have to be noted they only work with
> > ${version}+.
> >
> >
> > Approach 2:
> > Essentially he same as approach 1 only do allow different Confluence
> > projects for the different Java EE target version. So WIldFly 8, 9 and
> > 10 would all be documented under something like WFLYEE7.
> >
> > Approach 3
> > Switch to using something like asciidoc which can use variables and
> > generate links to the correct content. While this approach is probably
> > takes the most work up front, it seems like like it would be easier to
> > maintain between releases.
> >
> > Any other suggestions are welcome.
> >
> > [1]: https://docs.jboss.org/author/display/WFLY10/Documentation
> >
> > --
> > 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
> >
>
> --
> - DML
> _______________________________________________
> 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/20160513/8809ef11/attachment-0001.html 

From jperkins at redhat.com  Fri May 13 11:56:27 2016
From: jperkins at redhat.com (James Perkins)
Date: Fri, 13 May 2016 08:56:27 -0700
Subject: [wildfly-dev] One Doc to Rule Them All
In-Reply-To: <07BF8E48-F7C0-4606-8887-853C63186BBF@redhat.com>
References: <CADGwLph3Rw5B6b_uWFQz4V0ZoCRpOxVEoEpqtjQjzt_FT+Htmw@mail.gmail.com>
	<5735D2D5.1070808@redhat.com>
	<07BF8E48-F7C0-4606-8887-853C63186BBF@redhat.com>
Message-ID: <CADGwLpigGeHoT7uhDkMSx2=1=AP8JQ5A0HSr8Ogi3wP9MmpJmQ@mail.gmail.com>

Excellent. I'll have a look at how that works. Thanks!

On Fri, May 13, 2016 at 6:54 AM, Heiko W.Rupp <hrupp at redhat.com> wrote:

> On 13 May 2016, at 15:12, David M. Lloyd wrote:
>
> > I don't know how we'd organize it though; I've never done multi-document
> > things using asciidoc, and also we'd have to publish it somehow
> > (preferably in an automated manner).
>
> We have a build pipeline for the hawkular.org website, where the
> input is the pages branch of
> https://github.com/hawkular/hawkular.github.io
>
> If interested talk to Jirka (in cc)
> _______________________________________________
> 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/20160513/5858d262/attachment.html 

From jperkins at redhat.com  Fri May 13 12:00:43 2016
From: jperkins at redhat.com (James Perkins)
Date: Fri, 13 May 2016 09:00:43 -0700
Subject: [wildfly-dev] One Doc to Rule Them All
In-Reply-To: <5735D2D5.1070808@redhat.com>
References: <CADGwLph3Rw5B6b_uWFQz4V0ZoCRpOxVEoEpqtjQjzt_FT+Htmw@mail.gmail.com>
	<5735D2D5.1070808@redhat.com>
Message-ID: <CADGwLpjz74fBnRpeOYJYz3JqS-vWS7e5N2-+PMm0HG8NDpH8QQ@mail.gmail.com>

On Fri, May 13, 2016 at 6:12 AM, David M. Lloyd <david.lloyd at redhat.com>
wrote:

> I like approach 3, assuming that it'll move in to e.g. GitHub.  If
> there's an update to a doc, it's a lot easier to backport using git than
> Confluence.  Less chance of old docs getting abandoned, and easier for
> users to contribute fixes and updates if they can just open a PR for
> each affected version.  We're already reasonably well-trained to deal
> with old branches.
>
> I don't know how we'd organize it though; I've never done multi-document
> things using asciidoc, and also we'd have to publish it somehow
> (preferably in an automated manner).


Actually it does look like there is an include:: option. My guess though is
the reason there's a lot of combining asciidoc with awestruct is to build
these multi-page sites.

[1]: http://www.methods.co.nz/asciidoc/userguide.html#X63


>
>
> --
> - DML
> _______________________________________________
> 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/20160513/60b79dd7/attachment.html 

From jason.greene at redhat.com  Fri May 13 13:50:37 2016
From: jason.greene at redhat.com (Jason T. Greene)
Date: Fri, 13 May 2016 13:50:37 -0400 (EDT)
Subject: [wildfly-dev] One Doc to Rule Them All
In-Reply-To: <CADGwLph3Rw5B6b_uWFQz4V0ZoCRpOxVEoEpqtjQjzt_FT+Htmw@mail.gmail.com>
References: <CADGwLph3Rw5B6b_uWFQz4V0ZoCRpOxVEoEpqtjQjzt_FT+Htmw@mail.gmail.com>
Message-ID: <E094E5C7-956D-4451-A358-C41FA8324138@redhat.com>

Just as a general note, no matter how we generate our documentation we can always qualify versions. For example we can say "Since version X.y, blah". 

In general software tends to be additive until you hit a major rearchitecture. Currently I think we are forking the documentation too much. 

> On May 12, 2016, at 10:33 PM, James Perkins <jperkins at redhat.com> wrote:
> 
> I've been reading the WildFly documentation [1] quite a bit lately and noticing a lot of issues. Sometimes it references WildFly 8 in the WildFly 10 (or 9) documentation. Sometimes it references JBoss AS 7. Links take you to old documentation, e.g. a WFLY10 doc takes you to a page for WFLY8. Sometimes documentation is just plain out of date referencing behavior that has possibly been removed or replaced by something better.
> 
> This has happened because we keep copying the documentation over each time we have a new version. Overall this makes sense as a lot of it doesn't need to be changed. However it leaves reading the documentation confusing. Reading documentation for WildFly 10 and seeing WildFly 8 in the text with a link for AS72 isn't very user friendly as I'm sure we can all agree.
> 
> There's a few different ways we could go with this.
> 
> Approach 1:
> One, probably the easiest, is to use a single confluence project. We'd need to remove the version numbers from the text, which I think we should do anyway. Instead of referencing WildFly 10 we just reference it as WildFly.
> 
> An issue I can think of with this approach is some how annotating or referencing that parts of the documentation only work with ${version}. For example new features would have to be noted they only work with ${version}+.
> 
> 
> Approach 2:
> Essentially he same as approach 1 only do allow different Confluence projects for the different Java EE target version. So WIldFly 8, 9 and 10 would all be documented under something like WFLYEE7.
> 
> Approach 3
> Switch to using something like asciidoc which can use variables and generate links to the correct content. While this approach is probably takes the most work up front, it seems like like it would be easier to maintain between releases.
> 
> Any other suggestions are welcome.
> 
> [1]: https://docs.jboss.org/author/display/WFLY10/Documentation
> 
> -- 
> 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/20160513/00c33259/attachment.html 

From jason.greene at redhat.com  Fri May 13 13:53:10 2016
From: jason.greene at redhat.com (Jason T. Greene)
Date: Fri, 13 May 2016 13:53:10 -0400 (EDT)
Subject: [wildfly-dev] One Doc to Rule Them All
In-Reply-To: <E094E5C7-956D-4451-A358-C41FA8324138@redhat.com>
References: <CADGwLph3Rw5B6b_uWFQz4V0ZoCRpOxVEoEpqtjQjzt_FT+Htmw@mail.gmail.com>
	<E094E5C7-956D-4451-A358-C41FA8324138@redhat.com>
Message-ID: <87890115-F7FA-4F57-8AE1-75AB8E268567@redhat.com>

Also, I think it's far more likely developers will update the current documentation than fix old docs. By having a living doc for all versions you ensure that users always have the most accurate information at their disposal.

> On May 13, 2016, at 12:50 PM, Jason T. Greene <jason.greene at redhat.com> wrote:
> 
> Just as a general note, no matter how we generate our documentation we can always qualify versions. For example we can say "Since version X.y, blah". 
> 
> In general software tends to be additive until you hit a major rearchitecture. Currently I think we are forking the documentation too much. 
> 
>> On May 12, 2016, at 10:33 PM, James Perkins <jperkins at redhat.com> wrote:
>> 
>> I've been reading the WildFly documentation [1] quite a bit lately and noticing a lot of issues. Sometimes it references WildFly 8 in the WildFly 10 (or 9) documentation. Sometimes it references JBoss AS 7. Links take you to old documentation, e.g. a WFLY10 doc takes you to a page for WFLY8. Sometimes documentation is just plain out of date referencing behavior that has possibly been removed or replaced by something better.
>> 
>> This has happened because we keep copying the documentation over each time we have a new version. Overall this makes sense as a lot of it doesn't need to be changed. However it leaves reading the documentation confusing. Reading documentation for WildFly 10 and seeing WildFly 8 in the text with a link for AS72 isn't very user friendly as I'm sure we can all agree.
>> 
>> There's a few different ways we could go with this.
>> 
>> Approach 1:
>> One, probably the easiest, is to use a single confluence project. We'd need to remove the version numbers from the text, which I think we should do anyway. Instead of referencing WildFly 10 we just reference it as WildFly.
>> 
>> An issue I can think of with this approach is some how annotating or referencing that parts of the documentation only work with ${version}. For example new features would have to be noted they only work with ${version}+.
>> 
>> 
>> Approach 2:
>> Essentially he same as approach 1 only do allow different Confluence projects for the different Java EE target version. So WIldFly 8, 9 and 10 would all be documented under something like WFLYEE7.
>> 
>> Approach 3
>> Switch to using something like asciidoc which can use variables and generate links to the correct content. While this approach is probably takes the most work up front, it seems like like it would be easier to maintain between releases.
>> 
>> Any other suggestions are welcome.
>> 
>> [1]: https://docs.jboss.org/author/display/WFLY10/Documentation
>> 
>> -- 
>> 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/20160513/7217c3e8/attachment-0001.html 

From jperkins at redhat.com  Fri May 13 13:57:57 2016
From: jperkins at redhat.com (James Perkins)
Date: Fri, 13 May 2016 10:57:57 -0700
Subject: [wildfly-dev] One Doc to Rule Them All
In-Reply-To: <87890115-F7FA-4F57-8AE1-75AB8E268567@redhat.com>
References: <CADGwLph3Rw5B6b_uWFQz4V0ZoCRpOxVEoEpqtjQjzt_FT+Htmw@mail.gmail.com>
	<E094E5C7-956D-4451-A358-C41FA8324138@redhat.com>
	<87890115-F7FA-4F57-8AE1-75AB8E268567@redhat.com>
Message-ID: <CADGwLpieTF3G=6VGMkF+cFmuMEFX+JeKM9Hf-y-NN-Lu2T8t4g@mail.gmail.com>

Yes I agree on both counts that we fork too often and we're likely to
update new documentation only. This kind of goes with my first option where
we keep it more generic e.g. use WildFly rather than WildFly ${version}.

On Fri, May 13, 2016 at 10:53 AM, Jason T. Greene <jason.greene at redhat.com>
wrote:

> Also, I think it's far more likely developers will update the current
> documentation than fix old docs. By having a living doc for all versions
> you ensure that users always have the most accurate information at their
> disposal.
>
> On May 13, 2016, at 12:50 PM, Jason T. Greene <jason.greene at redhat.com>
> wrote:
>
> Just as a general note, no matter how we generate our documentation we can
> always qualify versions. For example we can say "Since version X.y, blah".
>
> In general software tends to be additive until you hit a major
> rearchitecture. Currently I think we are forking the documentation too
> much.
>
> On May 12, 2016, at 10:33 PM, James Perkins <jperkins at redhat.com> wrote:
>
> I've been reading the WildFly documentation [1] quite a bit lately and
> noticing a lot of issues. Sometimes it references WildFly 8 in the WildFly
> 10 (or 9) documentation. Sometimes it references JBoss AS 7. Links take you
> to old documentation, e.g. a WFLY10 doc takes you to a page for WFLY8.
> Sometimes documentation is just plain out of date referencing behavior that
> has possibly been removed or replaced by something better.
>
> This has happened because we keep copying the documentation over each time
> we have a new version. Overall this makes sense as a lot of it doesn't need
> to be changed. However it leaves reading the documentation confusing.
> Reading documentation for WildFly 10 and seeing WildFly 8 in the text with
> a link for AS72 isn't very user friendly as I'm sure we can all agree.
>
> There's a few different ways we could go with this.
>
> Approach 1:
> One, probably the easiest, is to use a single confluence project. We'd
> need to remove the version numbers from the text, which I think we should
> do anyway. Instead of referencing WildFly 10 we just reference it as
> WildFly.
>
> An issue I can think of with this approach is some how annotating or
> referencing that parts of the documentation only work with ${version}. For
> example new features would have to be noted they only work with ${version}+.
>
>
> Approach 2:
> Essentially he same as approach 1 only do allow different Confluence
> projects for the different Java EE target version. So WIldFly 8, 9 and 10
> would all be documented under something like WFLYEE7.
>
> Approach 3
> Switch to using something like asciidoc which can use variables and
> generate links to the correct content. While this approach is probably
> takes the most work up front, it seems like like it would be easier to
> maintain between releases.
>
> Any other suggestions are welcome.
>
> [1]: https://docs.jboss.org/author/display/WFLY10/Documentation
>
> --
> 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
>
>


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

From jason.greene at redhat.com  Fri May 13 14:12:08 2016
From: jason.greene at redhat.com (Jason Greene)
Date: Fri, 13 May 2016 13:12:08 -0500
Subject: [wildfly-dev] One Doc to Rule Them All
In-Reply-To: <CADGwLpieTF3G=6VGMkF+cFmuMEFX+JeKM9Hf-y-NN-Lu2T8t4g@mail.gmail.com>
References: <CADGwLph3Rw5B6b_uWFQz4V0ZoCRpOxVEoEpqtjQjzt_FT+Htmw@mail.gmail.com>
	<E094E5C7-956D-4451-A358-C41FA8324138@redhat.com>
	<87890115-F7FA-4F57-8AE1-75AB8E268567@redhat.com>
	<CADGwLpieTF3G=6VGMkF+cFmuMEFX+JeKM9Hf-y-NN-Lu2T8t4g@mail.gmail.com>
Message-ID: <7DCE4C97-B47F-4D04-8AB5-50FFA8E58D5A@redhat.com>

Right well basically what I am saying is that instead of forking at a specific point in time, which is really what option 2 is about, we just fork when it really becomes necessary, which is likely a major re-architecture.

While it does sound like I am advocating 1, 3 could meet this as well. We can have one link for ?WildFly docs? which is always the most current, and if we were using asciidoc, we could have ?archived docs?, which are not maintained but there for reference if need be.


> On May 13, 2016, at 12:57 PM, James Perkins <jperkins at redhat.com> wrote:
> 
> Yes I agree on both counts that we fork too often and we're likely to update new documentation only. This kind of goes with my first option where we keep it more generic e.g. use WildFly rather than WildFly ${version}.
> 
> On Fri, May 13, 2016 at 10:53 AM, Jason T. Greene <jason.greene at redhat.com <mailto:jason.greene at redhat.com>> wrote:
> Also, I think it's far more likely developers will update the current documentation than fix old docs. By having a living doc for all versions you ensure that users always have the most accurate information at their disposal.
> 
> On May 13, 2016, at 12:50 PM, Jason T. Greene <jason.greene at redhat.com <mailto:jason.greene at redhat.com>> wrote:
> 
>> Just as a general note, no matter how we generate our documentation we can always qualify versions. For example we can say "Since version X.y, blah". 
>> 
>> In general software tends to be additive until you hit a major rearchitecture. Currently I think we are forking the documentation too much. 
>> 
>> On May 12, 2016, at 10:33 PM, James Perkins <jperkins at redhat.com <mailto:jperkins at redhat.com>> wrote:
>> 
>>> I've been reading the WildFly documentation [1] quite a bit lately and noticing a lot of issues. Sometimes it references WildFly 8 in the WildFly 10 (or 9) documentation. Sometimes it references JBoss AS 7. Links take you to old documentation, e.g. a WFLY10 doc takes you to a page for WFLY8. Sometimes documentation is just plain out of date referencing behavior that has possibly been removed or replaced by something better.
>>> 
>>> This has happened because we keep copying the documentation over each time we have a new version. Overall this makes sense as a lot of it doesn't need to be changed. However it leaves reading the documentation confusing. Reading documentation for WildFly 10 and seeing WildFly 8 in the text with a link for AS72 isn't very user friendly as I'm sure we can all agree.
>>> 
>>> There's a few different ways we could go with this.
>>> 
>>> Approach 1:
>>> One, probably the easiest, is to use a single confluence project. We'd need to remove the version numbers from the text, which I think we should do anyway. Instead of referencing WildFly 10 we just reference it as WildFly.
>>> 
>>> An issue I can think of with this approach is some how annotating or referencing that parts of the documentation only work with ${version}. For example new features would have to be noted they only work with ${version}+.
>>> 
>>> 
>>> Approach 2:
>>> Essentially he same as approach 1 only do allow different Confluence projects for the different Java EE target version. So WIldFly 8, 9 and 10 would all be documented under something like WFLYEE7.
>>> 
>>> Approach 3
>>> Switch to using something like asciidoc which can use variables and generate links to the correct content. While this approach is probably takes the most work up front, it seems like like it would be easier to maintain between releases.
>>> 
>>> Any other suggestions are welcome.
>>> 
>>> [1]: https://docs.jboss.org/author/display/WFLY10/Documentation <https://docs.jboss.org/author/display/WFLY10/Documentation>
>>> 
>>> -- 
>>> 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>
> 
> 
> -- 
> 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

--
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/20160513/a33d82c5/attachment.html 

From smarlow at redhat.com  Fri May 13 14:15:20 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Fri, 13 May 2016 14:15:20 -0400
Subject: [wildfly-dev] One Doc to Rule Them All
In-Reply-To: <E094E5C7-956D-4451-A358-C41FA8324138@redhat.com>
References: <CADGwLph3Rw5B6b_uWFQz4V0ZoCRpOxVEoEpqtjQjzt_FT+Htmw@mail.gmail.com>
	<E094E5C7-956D-4451-A358-C41FA8324138@redhat.com>
Message-ID: <c04138f3-a800-b4e8-9ac6-183f5a5995fa@redhat.com>



On 05/13/2016 01:50 PM, Jason T. Greene wrote:
> Just as a general note, no matter how we generate our documentation we
> can always qualify versions. For example we can say "Since version X.y,
> blah".

This worked well enough in the old JBoss wiki, except it sometimes got 
long (from what I remember).

>
> In general software tends to be additive until you hit a major
> rearchitecture. Currently I think we are forking the documentation too
> much.
>
> On May 12, 2016, at 10:33 PM, James Perkins <jperkins at redhat.com
> <mailto:jperkins at redhat.com>> wrote:
>
>> I've been reading the WildFly documentation [1] quite a bit lately and
>> noticing a lot of issues. Sometimes it references WildFly 8 in the
>> WildFly 10 (or 9) documentation. Sometimes it references JBoss AS 7.
>> Links take you to old documentation, e.g. a WFLY10 doc takes you to a
>> page for WFLY8. Sometimes documentation is just plain out of date
>> referencing behavior that has possibly been removed or replaced by
>> something better.
>>
>> This has happened because we keep copying the documentation over each
>> time we have a new version. Overall this makes sense as a lot of it
>> doesn't need to be changed. However it leaves reading the
>> documentation confusing. Reading documentation for WildFly 10 and
>> seeing WildFly 8 in the text with a link for AS72 isn't very user
>> friendly as I'm sure we can all agree.
>>
>> There's a few different ways we could go with this.
>>
>> Approach 1:
>> One, probably the easiest, is to use a single confluence project. We'd
>> need to remove the version numbers from the text, which I think we
>> should do anyway. Instead of referencing WildFly 10 we just reference
>> it as WildFly.
>>
>> An issue I can think of with this approach is some how annotating or
>> referencing that parts of the documentation only work with ${version}.
>> For example new features would have to be noted they only work with
>> ${version}+.
>>
>>
>> Approach 2:
>> Essentially he same as approach 1 only do allow different Confluence
>> projects for the different Java EE target version. So WIldFly 8, 9 and
>> 10 would all be documented under something like WFLYEE7.
>>
>> Approach 3
>> Switch to using something like asciidoc which can use variables and
>> generate links to the correct content. While this approach is probably
>> takes the most work up front, it seems like like it would be easier to
>> maintain between releases.
>>
>> Any other suggestions are welcome.
>>
>> [1]: https://docs.jboss.org/author/display/WFLY10/Documentation
>>
>> --
>> 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
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From jperkins at redhat.com  Fri May 13 14:20:12 2016
From: jperkins at redhat.com (James Perkins)
Date: Fri, 13 May 2016 11:20:12 -0700
Subject: [wildfly-dev] One Doc to Rule Them All
In-Reply-To: <7DCE4C97-B47F-4D04-8AB5-50FFA8E58D5A@redhat.com>
References: <CADGwLph3Rw5B6b_uWFQz4V0ZoCRpOxVEoEpqtjQjzt_FT+Htmw@mail.gmail.com>
	<E094E5C7-956D-4451-A358-C41FA8324138@redhat.com>
	<87890115-F7FA-4F57-8AE1-75AB8E268567@redhat.com>
	<CADGwLpieTF3G=6VGMkF+cFmuMEFX+JeKM9Hf-y-NN-Lu2T8t4g@mail.gmail.com>
	<7DCE4C97-B47F-4D04-8AB5-50FFA8E58D5A@redhat.com>
Message-ID: <CADGwLpjvmn==BeetdFRpnO3J7r6CCuQTJ9qD_P_U=ZGt4D=99Q@mail.gmail.com>

As David stated one thing I do see as a positive for asciidoc is we could
do PR's. So if we have some big new feature come in we could also request
the submitter to add a docs PR too. That might be asking too much, but it's
nice in theory at least :)

On Fri, May 13, 2016 at 11:12 AM, Jason Greene <jason.greene at redhat.com>
wrote:

> Right well basically what I am saying is that instead of forking at a
> specific point in time, which is really what option 2 is about, we just
> fork when it really becomes necessary, which is likely a major
> re-architecture.
>
> While it does sound like I am advocating 1, 3 could meet this as well. We
> can have one link for ?WildFly docs? which is always the most current, and
> if we were using asciidoc, we could have ?archived docs?, which are not
> maintained but there for reference if need be.
>
>
> On May 13, 2016, at 12:57 PM, James Perkins <jperkins at redhat.com> wrote:
>
> Yes I agree on both counts that we fork too often and we're likely to
> update new documentation only. This kind of goes with my first option where
> we keep it more generic e.g. use WildFly rather than WildFly ${version}.
>
> On Fri, May 13, 2016 at 10:53 AM, Jason T. Greene <jason.greene at redhat.com
> > wrote:
>
>> Also, I think it's far more likely developers will update the current
>> documentation than fix old docs. By having a living doc for all versions
>> you ensure that users always have the most accurate information at their
>> disposal.
>>
>> On May 13, 2016, at 12:50 PM, Jason T. Greene <jason.greene at redhat.com>
>> wrote:
>>
>> Just as a general note, no matter how we generate our documentation we
>> can always qualify versions. For example we can say "Since version X.y,
>> blah".
>>
>> In general software tends to be additive until you hit a major
>> rearchitecture. Currently I think we are forking the documentation too
>> much.
>>
>> On May 12, 2016, at 10:33 PM, James Perkins <jperkins at redhat.com> wrote:
>>
>> I've been reading the WildFly documentation [1] quite a bit lately and
>> noticing a lot of issues. Sometimes it references WildFly 8 in the WildFly
>> 10 (or 9) documentation. Sometimes it references JBoss AS 7. Links take you
>> to old documentation, e.g. a WFLY10 doc takes you to a page for WFLY8.
>> Sometimes documentation is just plain out of date referencing behavior that
>> has possibly been removed or replaced by something better.
>>
>> This has happened because we keep copying the documentation over each
>> time we have a new version. Overall this makes sense as a lot of it doesn't
>> need to be changed. However it leaves reading the documentation confusing.
>> Reading documentation for WildFly 10 and seeing WildFly 8 in the text with
>> a link for AS72 isn't very user friendly as I'm sure we can all agree.
>>
>> There's a few different ways we could go with this.
>>
>> Approach 1:
>> One, probably the easiest, is to use a single confluence project. We'd
>> need to remove the version numbers from the text, which I think we should
>> do anyway. Instead of referencing WildFly 10 we just reference it as
>> WildFly.
>>
>> An issue I can think of with this approach is some how annotating or
>> referencing that parts of the documentation only work with ${version}. For
>> example new features would have to be noted they only work with ${version}+.
>>
>>
>> Approach 2:
>> Essentially he same as approach 1 only do allow different Confluence
>> projects for the different Java EE target version. So WIldFly 8, 9 and 10
>> would all be documented under something like WFLYEE7.
>>
>> Approach 3
>> Switch to using something like asciidoc which can use variables and
>> generate links to the correct content. While this approach is probably
>> takes the most work up front, it seems like like it would be easier to
>> maintain between releases.
>>
>> Any other suggestions are welcome.
>>
>> [1]: https://docs.jboss.org/author/display/WFLY10/Documentation
>>
>> --
>> 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
>>
>>
>
>
> --
> 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
>
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of 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/20160513/2411654b/attachment.html 

From smarlow at redhat.com  Fri May 13 14:45:29 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Fri, 13 May 2016 14:45:29 -0400
Subject: [wildfly-dev] One Doc to Rule Them All
In-Reply-To: <CADGwLpjvmn==BeetdFRpnO3J7r6CCuQTJ9qD_P_U=ZGt4D=99Q@mail.gmail.com>
References: <CADGwLph3Rw5B6b_uWFQz4V0ZoCRpOxVEoEpqtjQjzt_FT+Htmw@mail.gmail.com>
	<E094E5C7-956D-4451-A358-C41FA8324138@redhat.com>
	<87890115-F7FA-4F57-8AE1-75AB8E268567@redhat.com>
	<CADGwLpieTF3G=6VGMkF+cFmuMEFX+JeKM9Hf-y-NN-Lu2T8t4g@mail.gmail.com>
	<7DCE4C97-B47F-4D04-8AB5-50FFA8E58D5A@redhat.com>
	<CADGwLpjvmn==BeetdFRpnO3J7r6CCuQTJ9qD_P_U=ZGt4D=99Q@mail.gmail.com>
Message-ID: <5bf2478b-8732-cc93-cf04-4b8a3ffed6ce@redhat.com>

IMO, it would probably be nicer if the GIT repo is open.  Requiring a PR 
for every doc change, might discourage contributions.

We probably did fork the documentation too often, as contributions 
slowed down over time.  If developers are less interested in 
contributing documentation, we might want to fork less but also keep it 
easy to make changes (e.g. use a wiki/confluence or other online editor).

On 05/13/2016 02:20 PM, James Perkins wrote:
> As David stated one thing I do see as a positive for asciidoc is we
> could do PR's. So if we have some big new feature come in we could also
> request the submitter to add a docs PR too. That might be asking too
> much, but it's nice in theory at least :)
>
> On Fri, May 13, 2016 at 11:12 AM, Jason Greene <jason.greene at redhat.com
> <mailto:jason.greene at redhat.com>> wrote:
>
>     Right well basically what I am saying is that instead of forking at
>     a specific point in time, which is really what option 2 is about, we
>     just fork when it really becomes necessary, which is likely a major
>     re-architecture.
>
>     While it does sound like I am advocating 1, 3 could meet this as
>     well. We can have one link for ?WildFly docs? which is always the
>     most current, and if we were using asciidoc, we could have ?archived
>     docs?, which are not maintained but there for reference if need be.
>
>
>>     On May 13, 2016, at 12:57 PM, James Perkins <jperkins at redhat.com
>>     <mailto:jperkins at redhat.com>> wrote:
>>
>>     Yes I agree on both counts that we fork too often and we're likely
>>     to update new documentation only. This kind of goes with my first
>>     option where we keep it more generic e.g. use WildFly rather than
>>     WildFly ${version}.
>>
>>     On Fri, May 13, 2016 at 10:53 AM, Jason T. Greene
>>     <jason.greene at redhat.com <mailto:jason.greene at redhat.com>> wrote:
>>
>>         Also, I think it's far more likely developers will update the
>>         current documentation than fix old docs. By having a living
>>         doc for all versions you ensure that users always have the
>>         most accurate information at their disposal.
>>
>>         On May 13, 2016, at 12:50 PM, Jason T. Greene
>>         <jason.greene at redhat.com <mailto:jason.greene at redhat.com>> wrote:
>>
>>>         Just as a general note, no matter how we generate our
>>>         documentation we can always qualify versions. For example we
>>>         can say "Since version X.y, blah".
>>>
>>>         In general software tends to be additive until you hit a
>>>         major rearchitecture. Currently I think we are forking the
>>>         documentation too much.
>>>
>>>         On May 12, 2016, at 10:33 PM, James Perkins
>>>         <jperkins at redhat.com <mailto:jperkins at redhat.com>> wrote:
>>>
>>>>         I've been reading the WildFly documentation [1] quite a bit
>>>>         lately and noticing a lot of issues. Sometimes it references
>>>>         WildFly 8 in the WildFly 10 (or 9) documentation. Sometimes
>>>>         it references JBoss AS 7. Links take you to old
>>>>         documentation, e.g. a WFLY10 doc takes you to a page for
>>>>         WFLY8. Sometimes documentation is just plain out of date
>>>>         referencing behavior that has possibly been removed or
>>>>         replaced by something better.
>>>>
>>>>         This has happened because we keep copying the documentation
>>>>         over each time we have a new version. Overall this makes
>>>>         sense as a lot of it doesn't need to be changed. However it
>>>>         leaves reading the documentation confusing. Reading
>>>>         documentation for WildFly 10 and seeing WildFly 8 in the
>>>>         text with a link for AS72 isn't very user friendly as I'm
>>>>         sure we can all agree.
>>>>
>>>>         There's a few different ways we could go with this.
>>>>
>>>>         Approach 1:
>>>>         One, probably the easiest, is to use a single confluence
>>>>         project. We'd need to remove the version numbers from the
>>>>         text, which I think we should do anyway. Instead of
>>>>         referencing WildFly 10 we just reference it as WildFly.
>>>>
>>>>         An issue I can think of with this approach is some how
>>>>         annotating or referencing that parts of the documentation
>>>>         only work with ${version}. For example new features would
>>>>         have to be noted they only work with ${version}+.
>>>>
>>>>
>>>>         Approach 2:
>>>>         Essentially he same as approach 1 only do allow different
>>>>         Confluence projects for the different Java EE target
>>>>         version. So WIldFly 8, 9 and 10 would all be documented
>>>>         under something like WFLYEE7.
>>>>
>>>>         Approach 3
>>>>         Switch to using something like asciidoc which can use
>>>>         variables and generate links to the correct content. While
>>>>         this approach is probably takes the most work up front, it
>>>>         seems like like it would be easier to maintain between releases.
>>>>
>>>>         Any other suggestions are welcome.
>>>>
>>>>         [1]: https://docs.jboss.org/author/display/WFLY10/Documentation
>>>>
>>>>         --
>>>>         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
>>
>>
>>
>>
>>     --
>>     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
>
>     --
>     Jason T. Greene
>     WildFly Lead / JBoss EAP Platform Architect
>     JBoss, a division of Red Hat
>
>
>
>
> --
> 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
>

From david.lloyd at redhat.com  Fri May 13 16:01:48 2016
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Fri, 13 May 2016 15:01:48 -0500
Subject: [wildfly-dev] One Doc to Rule Them All
In-Reply-To: <5bf2478b-8732-cc93-cf04-4b8a3ffed6ce@redhat.com>
References: <CADGwLph3Rw5B6b_uWFQz4V0ZoCRpOxVEoEpqtjQjzt_FT+Htmw@mail.gmail.com>
	<E094E5C7-956D-4451-A358-C41FA8324138@redhat.com>
	<87890115-F7FA-4F57-8AE1-75AB8E268567@redhat.com>
	<CADGwLpieTF3G=6VGMkF+cFmuMEFX+JeKM9Hf-y-NN-Lu2T8t4g@mail.gmail.com>
	<7DCE4C97-B47F-4D04-8AB5-50FFA8E58D5A@redhat.com>
	<CADGwLpjvmn==BeetdFRpnO3J7r6CCuQTJ9qD_P_U=ZGt4D=99Q@mail.gmail.com>
	<5bf2478b-8732-cc93-cf04-4b8a3ffed6ce@redhat.com>
Message-ID: <573632AC.5040302@redhat.com>

One thing you can do on GitHub is, edit a page in-place, and it will 
automatically create a PR for you.  This can give the "feel" of a wiki 
without sacrificing the control that we need.

On 05/13/2016 01:45 PM, Scott Marlow wrote:
> IMO, it would probably be nicer if the GIT repo is open.  Requiring a PR
> for every doc change, might discourage contributions.
>
> We probably did fork the documentation too often, as contributions
> slowed down over time.  If developers are less interested in
> contributing documentation, we might want to fork less but also keep it
> easy to make changes (e.g. use a wiki/confluence or other online editor).
>
> On 05/13/2016 02:20 PM, James Perkins wrote:
>> As David stated one thing I do see as a positive for asciidoc is we
>> could do PR's. So if we have some big new feature come in we could also
>> request the submitter to add a docs PR too. That might be asking too
>> much, but it's nice in theory at least :)
>>
>> On Fri, May 13, 2016 at 11:12 AM, Jason Greene <jason.greene at redhat.com
>> <mailto:jason.greene at redhat.com>> wrote:
>>
>>      Right well basically what I am saying is that instead of forking at
>>      a specific point in time, which is really what option 2 is about, we
>>      just fork when it really becomes necessary, which is likely a major
>>      re-architecture.
>>
>>      While it does sound like I am advocating 1, 3 could meet this as
>>      well. We can have one link for ?WildFly docs? which is always the
>>      most current, and if we were using asciidoc, we could have ?archived
>>      docs?, which are not maintained but there for reference if need be.
>>
>>
>>>      On May 13, 2016, at 12:57 PM, James Perkins <jperkins at redhat.com
>>>      <mailto:jperkins at redhat.com>> wrote:
>>>
>>>      Yes I agree on both counts that we fork too often and we're likely
>>>      to update new documentation only. This kind of goes with my first
>>>      option where we keep it more generic e.g. use WildFly rather than
>>>      WildFly ${version}.
>>>
>>>      On Fri, May 13, 2016 at 10:53 AM, Jason T. Greene
>>>      <jason.greene at redhat.com <mailto:jason.greene at redhat.com>> wrote:
>>>
>>>          Also, I think it's far more likely developers will update the
>>>          current documentation than fix old docs. By having a living
>>>          doc for all versions you ensure that users always have the
>>>          most accurate information at their disposal.
>>>
>>>          On May 13, 2016, at 12:50 PM, Jason T. Greene
>>>          <jason.greene at redhat.com <mailto:jason.greene at redhat.com>> wrote:
>>>
>>>>          Just as a general note, no matter how we generate our
>>>>          documentation we can always qualify versions. For example we
>>>>          can say "Since version X.y, blah".
>>>>
>>>>          In general software tends to be additive until you hit a
>>>>          major rearchitecture. Currently I think we are forking the
>>>>          documentation too much.
>>>>
>>>>          On May 12, 2016, at 10:33 PM, James Perkins
>>>>          <jperkins at redhat.com <mailto:jperkins at redhat.com>> wrote:
>>>>
>>>>>          I've been reading the WildFly documentation [1] quite a bit
>>>>>          lately and noticing a lot of issues. Sometimes it references
>>>>>          WildFly 8 in the WildFly 10 (or 9) documentation. Sometimes
>>>>>          it references JBoss AS 7. Links take you to old
>>>>>          documentation, e.g. a WFLY10 doc takes you to a page for
>>>>>          WFLY8. Sometimes documentation is just plain out of date
>>>>>          referencing behavior that has possibly been removed or
>>>>>          replaced by something better.
>>>>>
>>>>>          This has happened because we keep copying the documentation
>>>>>          over each time we have a new version. Overall this makes
>>>>>          sense as a lot of it doesn't need to be changed. However it
>>>>>          leaves reading the documentation confusing. Reading
>>>>>          documentation for WildFly 10 and seeing WildFly 8 in the
>>>>>          text with a link for AS72 isn't very user friendly as I'm
>>>>>          sure we can all agree.
>>>>>
>>>>>          There's a few different ways we could go with this.
>>>>>
>>>>>          Approach 1:
>>>>>          One, probably the easiest, is to use a single confluence
>>>>>          project. We'd need to remove the version numbers from the
>>>>>          text, which I think we should do anyway. Instead of
>>>>>          referencing WildFly 10 we just reference it as WildFly.
>>>>>
>>>>>          An issue I can think of with this approach is some how
>>>>>          annotating or referencing that parts of the documentation
>>>>>          only work with ${version}. For example new features would
>>>>>          have to be noted they only work with ${version}+.
>>>>>
>>>>>
>>>>>          Approach 2:
>>>>>          Essentially he same as approach 1 only do allow different
>>>>>          Confluence projects for the different Java EE target
>>>>>          version. So WIldFly 8, 9 and 10 would all be documented
>>>>>          under something like WFLYEE7.
>>>>>
>>>>>          Approach 3
>>>>>          Switch to using something like asciidoc which can use
>>>>>          variables and generate links to the correct content. While
>>>>>          this approach is probably takes the most work up front, it
>>>>>          seems like like it would be easier to maintain between releases.
>>>>>
>>>>>          Any other suggestions are welcome.
>>>>>
>>>>>          [1]: https://docs.jboss.org/author/display/WFLY10/Documentation
>>>>>
>>>>>          --
>>>>>          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
>>>
>>>
>>>
>>>
>>>      --
>>>      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
>>
>>      --
>>      Jason T. Greene
>>      WildFly Lead / JBoss EAP Platform Architect
>>      JBoss, a division of Red Hat
>>
>>
>>
>>
>> --
>> 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
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

-- 
- DML

From brian.stansberry at redhat.com  Fri May 13 16:26:44 2016
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Fri, 13 May 2016 15:26:44 -0500
Subject: [wildfly-dev] One Doc to Rule Them All
In-Reply-To: <CADGwLpgPP6u5CC5BBWv5R2C-sJubQnuHY88NCPBqq_sf=Rvueg@mail.gmail.com>
References: <CADGwLph3Rw5B6b_uWFQz4V0ZoCRpOxVEoEpqtjQjzt_FT+Htmw@mail.gmail.com>
	<5735D2D5.1070808@redhat.com>
	<CADGwLpgPP6u5CC5BBWv5R2C-sJubQnuHY88NCPBqq_sf=Rvueg@mail.gmail.com>
Message-ID: <577fedeb-8ea2-3ca2-fd6c-800220be71a1@redhat.com>

Has anyone used a good docbook to asciidoc converter, e.g. the docbookrx 
discussed at [1] or the O'Reilly thing at [2]?

If we can't have some sort of reasonable conversion it's hard to imagine 
us making the move.

[1] 
https://blogs.gnome.org/pmkovar/2015/10/27/converting-docbook-into-asciidoc/

[2] https://github.com/oreillymedia/docbook2asciidoc

On 5/13/16 10:46 AM, James Perkins wrote:
> Yeah I think I prefer approach 3 myself. It just might be a lot of work
> to get there.
>
> I was thinking we could either use the gh-pages/github.io
> <http://github.io> approach or even just make it part of the wildfly.org
> <http://wildfly.org> [1] repo in a docs subdirectory. I see it being
> nice in some ways having it on http://wildfly.org.
>
> [1]: https://github.com/wildfly/wildfly.org
>
> On Fri, May 13, 2016 at 6:12 AM, David M. Lloyd <david.lloyd at redhat.com
> <mailto:david.lloyd at redhat.com>> wrote:
>
>     I like approach 3, assuming that it'll move in to e.g. GitHub.  If
>     there's an update to a doc, it's a lot easier to backport using git than
>     Confluence.  Less chance of old docs getting abandoned, and easier for
>     users to contribute fixes and updates if they can just open a PR for
>     each affected version.  We're already reasonably well-trained to deal
>     with old branches.
>
>     I don't know how we'd organize it though; I've never done multi-document
>     things using asciidoc, and also we'd have to publish it somehow
>     (preferably in an automated manner).
>
>     On 05/12/2016 10:32 PM, James Perkins wrote:
>     > I've been reading the WildFly documentation [1] quite a bit lately and
>     > noticing a lot of issues. Sometimes it references WildFly 8 in the
>     > WildFly 10 (or 9) documentation. Sometimes it references JBoss AS 7.
>     > Links take you to old documentation, e.g. a WFLY10 doc takes you to a
>     > page for WFLY8. Sometimes documentation is just plain out of date
>     > referencing behavior that has possibly been removed or replaced by
>     > something better.
>     >
>     > This has happened because we keep copying the documentation over each
>     > time we have a new version. Overall this makes sense as a lot of it
>     > doesn't need to be changed. However it leaves reading the
>     documentation
>     > confusing. Reading documentation for WildFly 10 and seeing WildFly
>     8 in
>     > the text with a link for AS72 isn't very user friendly as I'm sure we
>     > can all agree.
>     >
>     > There's a few different ways we could go with this.
>     >
>     > Approach 1:
>     > One, probably the easiest, is to use a single confluence project. We'd
>     > need to remove the version numbers from the text, which I think we
>     > should do anyway. Instead of referencing WildFly 10 we just
>     reference it
>     > as WildFly.
>     >
>     > An issue I can think of with this approach is some how annotating or
>     > referencing that parts of the documentation only work with ${version}.
>     > For example new features would have to be noted they only work with
>     > ${version}+.
>     >
>     >
>     > Approach 2:
>     > Essentially he same as approach 1 only do allow different Confluence
>     > projects for the different Java EE target version. So WIldFly 8, 9 and
>     > 10 would all be documented under something like WFLYEE7.
>     >
>     > Approach 3
>     > Switch to using something like asciidoc which can use variables and
>     > generate links to the correct content. While this approach is probably
>     > takes the most work up front, it seems like like it would be easier to
>     > maintain between releases.
>     >
>     > Any other suggestions are welcome.
>     >
>     > [1]: https://docs.jboss.org/author/display/WFLY10/Documentation
>     >
>     > --
>     > 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
>     >
>
>     --
>     - DML
>     _______________________________________________
>     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
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


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

From jperkins at redhat.com  Fri May 13 17:28:52 2016
From: jperkins at redhat.com (James Perkins)
Date: Fri, 13 May 2016 14:28:52 -0700
Subject: [wildfly-dev] One Doc to Rule Them All
In-Reply-To: <577fedeb-8ea2-3ca2-fd6c-800220be71a1@redhat.com>
References: <CADGwLph3Rw5B6b_uWFQz4V0ZoCRpOxVEoEpqtjQjzt_FT+Htmw@mail.gmail.com>
	<5735D2D5.1070808@redhat.com>
	<CADGwLpgPP6u5CC5BBWv5R2C-sJubQnuHY88NCPBqq_sf=Rvueg@mail.gmail.com>
	<577fedeb-8ea2-3ca2-fd6c-800220be71a1@redhat.com>
Message-ID: <CADGwLphMZfEUTR9GnVOR31OZZPA-FvH1R-QzinXF58JvBhT0-A@mail.gmail.com>

I've looked for a few tools, but hadn't seen this one yet. Looks kind of
promising though. If I could figure out how to export the docs to DocBook
I'd test it :)

On Fri, May 13, 2016 at 1:26 PM, Brian Stansberry <
brian.stansberry at redhat.com> wrote:

> Has anyone used a good docbook to asciidoc converter, e.g. the docbookrx
> discussed at [1] or the O'Reilly thing at [2]?
>
> If we can't have some sort of reasonable conversion it's hard to imagine
> us making the move.
>
> [1]
>
> https://blogs.gnome.org/pmkovar/2015/10/27/converting-docbook-into-asciidoc/
>
> [2] https://github.com/oreillymedia/docbook2asciidoc
>
> On 5/13/16 10:46 AM, James Perkins wrote:
> > Yeah I think I prefer approach 3 myself. It just might be a lot of work
> > to get there.
> >
> > I was thinking we could either use the gh-pages/github.io
> > <http://github.io> approach or even just make it part of the wildfly.org
> > <http://wildfly.org> [1] repo in a docs subdirectory. I see it being
> > nice in some ways having it on http://wildfly.org.
> >
> > [1]: https://github.com/wildfly/wildfly.org
> >
> > On Fri, May 13, 2016 at 6:12 AM, David M. Lloyd <david.lloyd at redhat.com
> > <mailto:david.lloyd at redhat.com>> wrote:
> >
> >     I like approach 3, assuming that it'll move in to e.g. GitHub.  If
> >     there's an update to a doc, it's a lot easier to backport using git
> than
> >     Confluence.  Less chance of old docs getting abandoned, and easier
> for
> >     users to contribute fixes and updates if they can just open a PR for
> >     each affected version.  We're already reasonably well-trained to deal
> >     with old branches.
> >
> >     I don't know how we'd organize it though; I've never done
> multi-document
> >     things using asciidoc, and also we'd have to publish it somehow
> >     (preferably in an automated manner).
> >
> >     On 05/12/2016 10:32 PM, James Perkins wrote:
> >     > I've been reading the WildFly documentation [1] quite a bit lately
> and
> >     > noticing a lot of issues. Sometimes it references WildFly 8 in the
> >     > WildFly 10 (or 9) documentation. Sometimes it references JBoss AS
> 7.
> >     > Links take you to old documentation, e.g. a WFLY10 doc takes you
> to a
> >     > page for WFLY8. Sometimes documentation is just plain out of date
> >     > referencing behavior that has possibly been removed or replaced by
> >     > something better.
> >     >
> >     > This has happened because we keep copying the documentation over
> each
> >     > time we have a new version. Overall this makes sense as a lot of it
> >     > doesn't need to be changed. However it leaves reading the
> >     documentation
> >     > confusing. Reading documentation for WildFly 10 and seeing WildFly
> >     8 in
> >     > the text with a link for AS72 isn't very user friendly as I'm sure
> we
> >     > can all agree.
> >     >
> >     > There's a few different ways we could go with this.
> >     >
> >     > Approach 1:
> >     > One, probably the easiest, is to use a single confluence project.
> We'd
> >     > need to remove the version numbers from the text, which I think we
> >     > should do anyway. Instead of referencing WildFly 10 we just
> >     reference it
> >     > as WildFly.
> >     >
> >     > An issue I can think of with this approach is some how annotating
> or
> >     > referencing that parts of the documentation only work with
> ${version}.
> >     > For example new features would have to be noted they only work with
> >     > ${version}+.
> >     >
> >     >
> >     > Approach 2:
> >     > Essentially he same as approach 1 only do allow different
> Confluence
> >     > projects for the different Java EE target version. So WIldFly 8, 9
> and
> >     > 10 would all be documented under something like WFLYEE7.
> >     >
> >     > Approach 3
> >     > Switch to using something like asciidoc which can use variables and
> >     > generate links to the correct content. While this approach is
> probably
> >     > takes the most work up front, it seems like like it would be
> easier to
> >     > maintain between releases.
> >     >
> >     > Any other suggestions are welcome.
> >     >
> >     > [1]: https://docs.jboss.org/author/display/WFLY10/Documentation
> >     >
> >     > --
> >     > 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
> >     >
> >
> >     --
> >     - DML
> >     _______________________________________________
> >     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
> >
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
>
>
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> 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/20160513/ccea60fc/attachment.html 

From rsvoboda at redhat.com  Sat May 14 05:08:57 2016
From: rsvoboda at redhat.com (Rostislav Svoboda)
Date: Sat, 14 May 2016 05:08:57 -0400 (EDT)
Subject: [wildfly-dev] One Doc to Rule Them All
In-Reply-To: <CADGwLphMZfEUTR9GnVOR31OZZPA-FvH1R-QzinXF58JvBhT0-A@mail.gmail.com>
References: <CADGwLph3Rw5B6b_uWFQz4V0ZoCRpOxVEoEpqtjQjzt_FT+Htmw@mail.gmail.com>
	<5735D2D5.1070808@redhat.com>
	<CADGwLpgPP6u5CC5BBWv5R2C-sJubQnuHY88NCPBqq_sf=Rvueg@mail.gmail.com>
	<577fedeb-8ea2-3ca2-fd6c-800220be71a1@redhat.com>
	<CADGwLphMZfEUTR9GnVOR31OZZPA-FvH1R-QzinXF58JvBhT0-A@mail.gmail.com>
Message-ID: <823974625.2737010.1463216937655.JavaMail.zimbra@redhat.com>

I like approach used in JBossWS project

Latest documentation on Confluence - https://docs.jboss.org/author/display/JBWS/
Older documentation available on http://docs.jboss.org/jbossws/ - e.g. http://docs.jboss.org/jbossws/5.1.0.Final/ 

Rostislav

----- Original Message -----
> I've looked for a few tools, but hadn't seen this one yet. Looks kind of
> promising though. If I could figure out how to export the docs to DocBook
> I'd test it :)
> 
> On Fri, May 13, 2016 at 1:26 PM, Brian Stansberry <
> brian.stansberry at redhat.com > wrote:
> 
> 
> Has anyone used a good docbook to asciidoc converter, e.g. the docbookrx
> discussed at [1] or the O'Reilly thing at [2]?
> 
> If we can't have some sort of reasonable conversion it's hard to imagine
> us making the move.
> 
> [1]
> https://blogs.gnome.org/pmkovar/2015/10/27/converting-docbook-into-asciidoc/
> 
> [2] https://github.com/oreillymedia/docbook2asciidoc
> 
> On 5/13/16 10:46 AM, James Perkins wrote:
> > Yeah I think I prefer approach 3 myself. It just might be a lot of work
> > to get there.
> > 
> > I was thinking we could either use the gh-pages/ github.io
> > < http://github.io > approach or even just make it part of the wildfly.org
> > < http://wildfly.org > [1] repo in a docs subdirectory. I see it being
> > nice in some ways having it on http://wildfly.org .
> > 
> > [1]: https://github.com/wildfly/wildfly.org
> > 
> > On Fri, May 13, 2016 at 6:12 AM, David M. Lloyd < david.lloyd at redhat.com
> > <mailto: david.lloyd at redhat.com >> wrote:
> > 
> > I like approach 3, assuming that it'll move in to e.g. GitHub. If
> > there's an update to a doc, it's a lot easier to backport using git than
> > Confluence. Less chance of old docs getting abandoned, and easier for
> > users to contribute fixes and updates if they can just open a PR for
> > each affected version. We're already reasonably well-trained to deal
> > with old branches.
> > 
> > I don't know how we'd organize it though; I've never done multi-document
> > things using asciidoc, and also we'd have to publish it somehow
> > (preferably in an automated manner).
> > 
> > On 05/12/2016 10:32 PM, James Perkins wrote:
> > > I've been reading the WildFly documentation [1] quite a bit lately and
> > > noticing a lot of issues. Sometimes it references WildFly 8 in the
> > > WildFly 10 (or 9) documentation. Sometimes it references JBoss AS 7.
> > > Links take you to old documentation, e.g. a WFLY10 doc takes you to a
> > > page for WFLY8. Sometimes documentation is just plain out of date
> > > referencing behavior that has possibly been removed or replaced by
> > > something better.
> > > 
> > > This has happened because we keep copying the documentation over each
> > > time we have a new version. Overall this makes sense as a lot of it
> > > doesn't need to be changed. However it leaves reading the
> > documentation
> > > confusing. Reading documentation for WildFly 10 and seeing WildFly
> > 8 in
> > > the text with a link for AS72 isn't very user friendly as I'm sure we
> > > can all agree.
> > > 
> > > There's a few different ways we could go with this.
> > > 
> > > Approach 1:
> > > One, probably the easiest, is to use a single confluence project. We'd
> > > need to remove the version numbers from the text, which I think we
> > > should do anyway. Instead of referencing WildFly 10 we just
> > reference it
> > > as WildFly.
> > > 
> > > An issue I can think of with this approach is some how annotating or
> > > referencing that parts of the documentation only work with ${version}.
> > > For example new features would have to be noted they only work with
> > > ${version}+.
> > > 
> > > 
> > > Approach 2:
> > > Essentially he same as approach 1 only do allow different Confluence
> > > projects for the different Java EE target version. So WIldFly 8, 9 and
> > > 10 would all be documented under something like WFLYEE7.
> > > 
> > > Approach 3
> > > Switch to using something like asciidoc which can use variables and
> > > generate links to the correct content. While this approach is probably
> > > takes the most work up front, it seems like like it would be easier to
> > > maintain between releases.
> > > 
> > > Any other suggestions are welcome.
> > > 
> > > [1]: https://docs.jboss.org/author/display/WFLY10/Documentation
> > > 
> > > --
> > > 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
> > > 
> > 
> > --
> > - DML
> > _______________________________________________
> > 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
> > 
> > 
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> > 
> 
> 
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> 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

From sanne at hibernate.org  Sun May 15 19:12:12 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 16 May 2016 00:12:12 +0100
Subject: [wildfly-dev] update on WildFly NoSQL prototype integration...
In-Reply-To: <fb884efb-02b3-657b-85a8-1331611e6f29@redhat.com>
References: <bf184686-ccbb-f6bf-3ce5-db00cb54bf6c@redhat.com>
	<CADGJaX9JiiEZw+8XqzsZjU2q5jcp3cnnx_7U3G_g4PgT86qQUw@mail.gmail.com>
	<ad804aed-782b-272e-7cde-afbd1598107a@redhat.com>
	<4E9D7BDF-2D04-42AA-9D53-649A63CF66F0@hibernate.org>
	<CAFm4XO38HRFSzwhbgZX0bxDPJq=BaHgW9JbtgaR=rz3VF5-ezA@mail.gmail.com>
	<fb884efb-02b3-657b-85a8-1331611e6f29@redhat.com>
Message-ID: <CAFm4XO2rOhwfn11UwnuHuPWyxnpO3ZA5vqxsX7+wkpyfip5R1Q@mail.gmail.com>

On 12 May 2016 at 14:50, Scott Marlow <smarlow at redhat.com> wrote:
>
>
> On 05/12/2016 08:41 AM, Sanne Grinovero wrote:
>>
>> On 12 May 2016 at 12:24, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>>>
>>>
>>>
>>> On 11 mai 2016, at 16:02, Scott Marlow <smarlow at redhat.com> wrote:
>>>
>>>>> Hibernate OGM should still be usable without WF; So maybe there should
>>>>> be a separate project/repo which defines an SPI to obtain/manage
>>>>> connections and implementations for different NoSQL stores?
>>>>
>>>>
>>>> Excellent suggestion,  perhaps the SPI could be under
>>>> https://github.com/jboss, which is a common area for sharing.  Possible
>>>> locations for creating the per NoSQL store implementations could be
>>>> https://github.com/jboss or https://github.com/hibernate or
>>>> https://github.com/wildfly.
>>>
>>>
>>> I'm starting to think that this might be way overkill. If we are creating
>>> a sub project just to share between 20 and 50 lines of code per provider and
>>> the overhead code to abstract property configuration to plus OGM and WF
>>> ones, we are losing more than gaining.
>>>
>>> Thoughts ?
>>
>>
>> I agree it's overkill, and have an alternative proposal:
>>
>> Hibernate OGM should define an interface which is appropriate for its
>> own consumption; the Wildfly NoSQL subssystem can have its own
>> interface so to not depend on OGM, but they would be somewhat similar
>> for each given NoSQL technology we intend to support in this way.
>
>
> Just to clarify what we were discussing.  The idea for sharing connection
> setup, would of involved extracting that code from OGM, into a separate jar
> that OGM + WildFly NoSQL could depend on.

My impression is that the code to setup these connections trivial, so
there is no much benefit in sharing code.
Hibernate and WildFly generally read configuration setting in
different ways (and conventions) so it might even be preferable to
avoid sharing anything.

I'd aim at injecting the WildFly representation of "NoSQL connection
provider" into Hibernate: in this case all what we need to agree on is
an interface.

Hibernate OGM will also be able to interpret its own configuration
properties as an alternative.
This conceptually maps to the existing case of Hibernate ORM, in which
two different approaches can be used:
 - use a Datasource (managed by the app server)
 - configure all JDBC settings explicitly, and optionally connection
pooling settings.

In the WildFly case, what OGM needs is for you to inject a "NoSQL datasource".


>> Then JipiJapa can inject an adaptor into the OGM boostrap phase,
>> delegating from one to the other. So only the OGM specific JipiJapa
>> module would need to depend on both interfaces.
>> If this dependency is not desirable either, then I think we can live
>> with a non-typesafe generic provider of things.
>
>
> I'm not exactly sure of what you mean here about JipiJapa injecting an
> adaptor into the OGM bootstrap phase.  Are you talking about how we want to
> have a JipiJapa adapter for OGM, that (magically) leaks native NoSQL
> dependencies into application deployments, depending on which NoSQL backend
> store is targeted?  That may be different than what we are talking about
> here but that also needs a SPI, so the JipiJapa adapter can ask the JPA
> PersistenceProvider what the backend store is (or something like that).

Ideally JipiJapa should work similarly to how it does with a JTA
DataSource: some identification string, like an URL or a JNDI name,
will be listed in the persistence.xml and this needs to match the
configuration of some NoSQL datasource.

By "adaptor" I was merely referring to the fact that whatever JipiJapa
will give to Hibernate OGM, this should implement an interface from
OGM so that this can be consumed.

>
> [1] talks about some of the (OGM/ORM related) dependency issues that are
> also important to solve.  I'm not really sure of the best way to address the
> [1] dependency issues that involve WildFly Clustering, WildFly JPA
> container, WildFly JipiJapa adapters for Hibernate ORM,
> Hibernate-Infinispan, Infinispan.
>
> I agree with Gunnar, that we should continue with POC coding but also really
> love the feedback/discussion going on here.  I'd like to ping some
> additional teams as well soon (Infinispan dev, native NoSQL store teams,
> others that may need to extend the WildFly NoSQL infrastructure).
>
> Scott
>
> [1] https://github.com/jboss/jboss-nosql/issues/3
>>
>>
>> Thanks,
>> Sanne
>>
>

From sanne at hibernate.org  Mon May 16 04:36:24 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 16 May 2016 09:36:24 +0100
Subject: [wildfly-dev] Module aliases and deprecation
In-Reply-To: <5729EEC1.2010505@redhat.com>
References: <CAFm4XO2Bn9J_ZsPLfOUco1x-N_zci6HGZWGwCBNh3WUB_-mDKA@mail.gmail.com>
	<CAMquZP4777edhiS0ULt4K0i8X8fET4Ym0FFYotTHBKZHjC7csg@mail.gmail.com>
	<CAFm4XO27WQyYdsrjSanr9MyWZQutkCnfCrPt4fyq70ZhBTj+kw@mail.gmail.com>
	<CAMquZP7aLC_hGZXEL0+jprZMoX9QHFMTc1su3pXwLhU421roOQ@mail.gmail.com>
	<5729EEC1.2010505@redhat.com>
Message-ID: <CAFm4XO1iJ7cdN1vL4XCS1UinXSng4MX7ygNms33=7Ju8ujMMTw@mail.gmail.com>

On 4 May 2016 at 13:44, David M. Lloyd <david.lloyd at redhat.com> wrote:
> You can't add properties to alias modules IIRC.
>
> If you want to have deprecated/unsupported/etc. for a module, then
> instead of an alias, create an empty module with the old name that
> imports and re-exports the desired target module.  Then put the
> properties on this empty module.

Thanks David, that was very helpful!

> On 05/04/2016 07:32 AM, Toma? Cerar wrote:
>> I understand that, so just add that property to alias module.
>>
>> But I think that adding that metadata to alias will *not* result in WARN
>> message at boot time if anyone is using the module.
>> AFAIR doing ModuleLoader.loadModule(aliasModule)
>> will return the module to which alias is pointing to, as result we
>> cannot read metadata of the alias directly.
>> David can correct me about this.
>>
>> On Wed, May 4, 2016 at 2:19 PM, Sanne Grinovero <sanne at hibernate.org
>> <mailto:sanne at hibernate.org>> wrote:
>>
>>     Hi Tomaz,
>>     the module is not deprecated: the module-alias is.
>>
>>     In other words, I wish to deprecate the "old name" only.
>>
>>     Thanks,
>>     Sanne
>>
>>
>>     On 4 May 2016 at 13:08, Toma? Cerar <tomaz.cerar at gmail.com
>>     <mailto:tomaz.cerar at gmail.com>> wrote:
>>     > add extra properties to module.xml
>>     >
>>     > for deprecated
>>     >
>>     > <properties>
>>     >     <property name="jboss.api" value="deprecated"/>
>>     > </properties>
>>     >
>>     >
>>     > should do it.
>>     >
>>     >
>>     > On Wed, May 4, 2016 at 1:49 PM, Sanne Grinovero <sanne at hibernate.org <mailto:sanne at hibernate.org>> wrote:
>>     >>
>>     >> Hello,
>>     >>
>>     >> I'm renaming some modules intended for WildFly users. To minimize
>>     >> impact on existing users, I'm including module-aliases using the old
>>     >> name, to resolve to the new module ids.
>>     >>
>>     >> Is there a way to mark such an alias as "deprecated" to encourage
>>     >> people moving to the new naming scheme?
>>     >>
>>     >> Thanks,
>>     >> Sanne
>>     >> _______________________________________________
>>     >> wildfly-dev mailing list
>>     >>wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>     >>https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>     >
>>     >
>>
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From sanne at hibernate.org  Mon May 16 13:45:00 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 16 May 2016 18:45:00 +0100
Subject: [wildfly-dev] One Doc to Rule Them All
In-Reply-To: <823974625.2737010.1463216937655.JavaMail.zimbra@redhat.com>
References: <CADGwLph3Rw5B6b_uWFQz4V0ZoCRpOxVEoEpqtjQjzt_FT+Htmw@mail.gmail.com>
	<5735D2D5.1070808@redhat.com>
	<CADGwLpgPP6u5CC5BBWv5R2C-sJubQnuHY88NCPBqq_sf=Rvueg@mail.gmail.com>
	<577fedeb-8ea2-3ca2-fd6c-800220be71a1@redhat.com>
	<CADGwLphMZfEUTR9GnVOR31OZZPA-FvH1R-QzinXF58JvBhT0-A@mail.gmail.com>
	<823974625.2737010.1463216937655.JavaMail.zimbra@redhat.com>
Message-ID: <CAFm4XO2A4g7Hfng1rryoWbc_Ny2g676uEQjjZaf9_-y_Q2Qn4g@mail.gmail.com>

Hi all,
at Hibernate we publish both the blog in.relation.to and the website
hibernate.org by pushing  asciidoc changes to github.com.

Documentation of each project is built from asciidoc during the project
build, and uploaded as part of each release.

A push - including merging a PR - to website or blog will trigger a CI job
which updates the websites. We have a "production" and a "staging" branch.

We also converted all our documentation from docbook, and some of our
project still convert the asciidoc documentation into docbook during each
release automatically to produce the old style PDF (among other formats).

Documentation is indeed broken up in multiple files, then using includes
and variables.. It's particularly nice to inject variable values defined as
properties in Maven, we can for example print out versions of dependencies
and have them rendered correctly at release time.

The website and the blog use Bob's http://awestruct.org

Have a look at our ci.hibernate.org jobs, or ask us more specific questions
we're happy to point to examples of each piece of the puzzle.

It works quite nicely, BUT:
- sometimes I envy your wiki, takes less time to get stuff done. Lower
quality though... :P
- rebuilding our blog takes like 15 minutes on good day. That's not great
when then you notice yet another typo and have to re-trigger it..
- the gem dependencies for awestruct tend to have weird system dependencies
and break often on Fedora... use Docker.

Sanne
On 14 May 2016 10:09, "Rostislav Svoboda" <rsvoboda at redhat.com> wrote:

> I like approach used in JBossWS project
>
> Latest documentation on Confluence -
> https://docs.jboss.org/author/display/JBWS/
> Older documentation available on http://docs.jboss.org/jbossws/ - e.g.
> http://docs.jboss.org/jbossws/5.1.0.Final/
>
> Rostislav
>
> ----- Original Message -----
> > I've looked for a few tools, but hadn't seen this one yet. Looks kind of
> > promising though. If I could figure out how to export the docs to DocBook
> > I'd test it :)
> >
> > On Fri, May 13, 2016 at 1:26 PM, Brian Stansberry <
> > brian.stansberry at redhat.com > wrote:
> >
> >
> > Has anyone used a good docbook to asciidoc converter, e.g. the docbookrx
> > discussed at [1] or the O'Reilly thing at [2]?
> >
> > If we can't have some sort of reasonable conversion it's hard to imagine
> > us making the move.
> >
> > [1]
> >
> https://blogs.gnome.org/pmkovar/2015/10/27/converting-docbook-into-asciidoc/
> >
> > [2] https://github.com/oreillymedia/docbook2asciidoc
> >
> > On 5/13/16 10:46 AM, James Perkins wrote:
> > > Yeah I think I prefer approach 3 myself. It just might be a lot of work
> > > to get there.
> > >
> > > I was thinking we could either use the gh-pages/ github.io
> > > < http://github.io > approach or even just make it part of the
> wildfly.org
> > > < http://wildfly.org > [1] repo in a docs subdirectory. I see it being
> > > nice in some ways having it on http://wildfly.org .
> > >
> > > [1]: https://github.com/wildfly/wildfly.org
> > >
> > > On Fri, May 13, 2016 at 6:12 AM, David M. Lloyd <
> david.lloyd at redhat.com
> > > <mailto: david.lloyd at redhat.com >> wrote:
> > >
> > > I like approach 3, assuming that it'll move in to e.g. GitHub. If
> > > there's an update to a doc, it's a lot easier to backport using git
> than
> > > Confluence. Less chance of old docs getting abandoned, and easier for
> > > users to contribute fixes and updates if they can just open a PR for
> > > each affected version. We're already reasonably well-trained to deal
> > > with old branches.
> > >
> > > I don't know how we'd organize it though; I've never done
> multi-document
> > > things using asciidoc, and also we'd have to publish it somehow
> > > (preferably in an automated manner).
> > >
> > > On 05/12/2016 10:32 PM, James Perkins wrote:
> > > > I've been reading the WildFly documentation [1] quite a bit lately
> and
> > > > noticing a lot of issues. Sometimes it references WildFly 8 in the
> > > > WildFly 10 (or 9) documentation. Sometimes it references JBoss AS 7.
> > > > Links take you to old documentation, e.g. a WFLY10 doc takes you to a
> > > > page for WFLY8. Sometimes documentation is just plain out of date
> > > > referencing behavior that has possibly been removed or replaced by
> > > > something better.
> > > >
> > > > This has happened because we keep copying the documentation over each
> > > > time we have a new version. Overall this makes sense as a lot of it
> > > > doesn't need to be changed. However it leaves reading the
> > > documentation
> > > > confusing. Reading documentation for WildFly 10 and seeing WildFly
> > > 8 in
> > > > the text with a link for AS72 isn't very user friendly as I'm sure we
> > > > can all agree.
> > > >
> > > > There's a few different ways we could go with this.
> > > >
> > > > Approach 1:
> > > > One, probably the easiest, is to use a single confluence project.
> We'd
> > > > need to remove the version numbers from the text, which I think we
> > > > should do anyway. Instead of referencing WildFly 10 we just
> > > reference it
> > > > as WildFly.
> > > >
> > > > An issue I can think of with this approach is some how annotating or
> > > > referencing that parts of the documentation only work with
> ${version}.
> > > > For example new features would have to be noted they only work with
> > > > ${version}+.
> > > >
> > > >
> > > > Approach 2:
> > > > Essentially he same as approach 1 only do allow different Confluence
> > > > projects for the different Java EE target version. So WIldFly 8, 9
> and
> > > > 10 would all be documented under something like WFLYEE7.
> > > >
> > > > Approach 3
> > > > Switch to using something like asciidoc which can use variables and
> > > > generate links to the correct content. While this approach is
> probably
> > > > takes the most work up front, it seems like like it would be easier
> to
> > > > maintain between releases.
> > > >
> > > > Any other suggestions are welcome.
> > > >
> > > > [1]: https://docs.jboss.org/author/display/WFLY10/Documentation
> > > >
> > > > --
> > > > 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
> > > >
> > >
> > > --
> > > - DML
> > > _______________________________________________
> > > 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
> > >
> > >
> > > _______________________________________________
> > > wildfly-dev mailing list
> > > wildfly-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> > >
> >
> >
> > --
> > Brian Stansberry
> > Senior Principal Software Engineer
> > JBoss by Red Hat
> > _______________________________________________
> > 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
> _______________________________________________
> 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/20160516/6b324643/attachment-0001.html 

From lgao at redhat.com  Mon May 16 22:23:25 2016
From: lgao at redhat.com (Lin Gao)
Date: Mon, 16 May 2016 22:23:25 -0400 (EDT)
Subject: [wildfly-dev] Specify algorithm and key-size for password vault in
	WildFly?
In-Reply-To: <1899108867.14970506.1463450871011.JavaMail.zimbra@redhat.com>
Message-ID: <1737787944.14975772.1463451805048.JavaMail.zimbra@redhat.com>

Hi,

There is a Jira: WFLY-6569[1] open about password vault, which asks for specifying KEY_SIZE to encrypt the sensitive data in vault data file.

The key size is bound up with the algorithm it uses, currently the vault.sh|.bat only allows AES(no place to specify other algorithm) to encrypt sensitive data, and uses key size of 128. 

Alougth we can specify the key size after doing some fix, it needs extra set-up work for some JDKs(like Oracle JDKs) to be able to use key size of 192 and 256 for AES. This leads to that only specifying the key size is not so worthy.

Maybe we should specify both algorithm and key size to encrypt the vault data?

[1] https://issues.jboss.org/browse/WFLY-6569
--
Lin Gao
Software Engineer
JBoss by Red Hat

From darran.lofthouse at jboss.com  Tue May 17 05:54:50 2016
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Tue, 17 May 2016 10:54:50 +0100
Subject: [wildfly-dev] Specify algorithm and key-size for password vault
 in WildFly?
In-Reply-To: <1737787944.14975772.1463451805048.JavaMail.zimbra@redhat.com>
References: <1737787944.14975772.1463451805048.JavaMail.zimbra@redhat.com>
Message-ID: <6f2975f8-1336-d779-95b6-d4a0078409c7@jboss.com>

If this issue is not critical I think we should leave it as is - this is 
all being superseded by Elytron.

Regards,
Darran Lofthouse.


On 17/05/16 03:23, Lin Gao wrote:
> Hi,
>
> There is a Jira: WFLY-6569[1] open about password vault, which asks for specifying KEY_SIZE to encrypt the sensitive data in vault data file.
>
> The key size is bound up with the algorithm it uses, currently the vault.sh|.bat only allows AES(no place to specify other algorithm) to encrypt sensitive data, and uses key size of 128.
>
> Alougth we can specify the key size after doing some fix, it needs extra set-up work for some JDKs(like Oracle JDKs) to be able to use key size of 192 and 256 for AES. This leads to that only specifying the key size is not so worthy.
>
> Maybe we should specify both algorithm and key size to encrypt the vault data?
>
> [1] https://issues.jboss.org/browse/WFLY-6569
> --
> Lin Gao
> Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From lgao at redhat.com  Tue May 17 20:44:01 2016
From: lgao at redhat.com (Lin Gao)
Date: Tue, 17 May 2016 20:44:01 -0400 (EDT)
Subject: [wildfly-dev] Specify algorithm and key-size for password vault
 in WildFly?
In-Reply-To: <6f2975f8-1336-d779-95b6-d4a0078409c7@jboss.com>
References: <1737787944.14975772.1463451805048.JavaMail.zimbra@redhat.com>
	<6f2975f8-1336-d779-95b6-d4a0078409c7@jboss.com>
Message-ID: <96257880.15373443.1463532241930.JavaMail.zimbra@redhat.com>

Hi,

----- Original Message -----
> From: "Darran Lofthouse" <darran.lofthouse at jboss.com>
> To: wildfly-dev at lists.jboss.org
> Sent: Tuesday, May 17, 2016 5:54:50 PM
> Subject: Re: [wildfly-dev] Specify algorithm and key-size for password vault in WildFly?
> 
> If this issue is not critical I think we should leave it as is - this is
> all being superseded by Elytron.

Sure, I will add a comment on the issue. Thanks.

Best Regards
--
Lin Gao
Software Engineer
JBoss by Red Hat


> Regards,
> Darran Lofthouse.
> 
> 
> On 17/05/16 03:23, Lin Gao wrote:
> > Hi,
> >
> > There is a Jira: WFLY-6569[1] open about password vault, which asks for
> > specifying KEY_SIZE to encrypt the sensitive data in vault data file.
> >
> > The key size is bound up with the algorithm it uses, currently the
> > vault.sh|.bat only allows AES(no place to specify other algorithm) to
> > encrypt sensitive data, and uses key size of 128.
> >
> > Alougth we can specify the key size after doing some fix, it needs extra
> > set-up work for some JDKs(like Oracle JDKs) to be able to use key size of
> > 192 and 256 for AES. This leads to that only specifying the key size is
> > not so worthy.
> >
> > Maybe we should specify both algorithm and key size to encrypt the vault
> > data?
> >
> > [1] https://issues.jboss.org/browse/WFLY-6569
> > --
> > Lin Gao
> > Software Engineer
> > JBoss by Red Hat
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 

From rory.odonnell at oracle.com  Wed May 18 04:44:46 2016
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Wed, 18 May 2016 09:44:46 +0100
Subject: [wildfly-dev] Early Access builds of JDK 9 b118 & JDK 9 with
 Project Jigsaw, b118 (#4987) are available on java.net
Message-ID: <4db0b90d-167e-6f0b-dc73-ab6904022fd2@oracle.com>


Hi Jason/Tomaz,

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

Early Access b118 <https://jdk9.java.net/jigsaw/> (#4913) for JDK 9 with 
Project Jigsaw is available on java.net.

JDK 9 Build 118 includes a refresh of the module system.

There are several changes in this update, JDK 9 b118 has the updated 
policy for root modules described
in JEP 261 [1]. This means that java.corba and the 6 EE modules aren't 
resolved by default and so it will
look "as if" the types in these modules have been removed. More info on 
the JDK 9 dev mailing list [2].

A change that went into JDK 9 b102 is worth mentioning:
JDK9: Remove stopThread RuntimePermission  from the default java.policy 
In previous releases, untrusted
code had the "stopThread" RuntimePermission granted by default. This 
permission allows untrusted code
to call Thread.stop(), initiating an asynchronous ThreadDeath Error, on 
threads in the same thread group.
Having a ThreadDeath Error thrown asynchronously is not something that 
trusted code should be expected
to handle gracefully. The permission is no longer granted by default.

Rgds,Rory


[1] http://openjdk.java.net/jeps/261
[2] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-May/004309.html

-- 
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/20160518/7e6a7389/attachment.html 

From jason.greene at redhat.com  Fri May 20 17:45:55 2016
From: jason.greene at redhat.com (Jason Greene)
Date: Fri, 20 May 2016 16:45:55 -0500
Subject: [wildfly-dev] 10.1 Thoughts and Call for Ready Features
Message-ID: <532FC001-347F-438D-AFA2-612E052C72AE@redhat.com>

Hello Everyone,

I?d like to cut a 10.1 fairly soon, preferably in the next 2-3 weeks. My thinking is to take everything that is not explicitly tagged as 11.x and merge it ASAP. Really this should just be anything that doesn?t add instability, or introduces a half-finished API that we then have to support (the obvious exception is experimental capabilities that we denote as such). This is a bit of a departure from what I was suggesting earlier, where we we would cherry-pick major items into a separate branch, so if you have any concerns now is the time to raise them. 

This release would be a good opportunity to include features that are ready to go (suitable for a final release in 2-3 weeks) but didn?t make 10.0 (I have a feeling Sanne has been itching for some updates to search!). If you have something then send a PR (noting that you want it in 10.1) or raise your figurative hand :)..  

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



From arjan.tijms at gmail.com  Fri May 20 18:05:41 2016
From: arjan.tijms at gmail.com (arjan tijms)
Date: Sat, 21 May 2016 00:05:41 +0200
Subject: [wildfly-dev] 10.1 Thoughts and Call for Ready Features
In-Reply-To: <532FC001-347F-438D-AFA2-612E052C72AE@redhat.com>
References: <532FC001-347F-438D-AFA2-612E052C72AE@redhat.com>
Message-ID: <CAE=-AhC+ySGahMeVHjxQZfT_DmR=siF=O5K+XcYUqyFc+Yteeg@mail.gmail.com>

Hi Jason,

Just wondering, but will WildFly 10.1 be the basis for a future EAP 8, or
for a future EAP 7.x?

How are the WildFly and EAP branches related to each other now that EAP 7
final has been released?

Kind regards,
Arjan Tijms



On Fri, May 20, 2016 at 11:45 PM, Jason Greene <jason.greene at redhat.com>
wrote:

> Hello Everyone,
>
> I?d like to cut a 10.1 fairly soon, preferably in the next 2-3 weeks. My
> thinking is to take everything that is not explicitly tagged as 11.x and
> merge it ASAP. Really this should just be anything that doesn?t add
> instability, or introduces a half-finished API that we then have to support
> (the obvious exception is experimental capabilities that we denote as
> such). This is a bit of a departure from what I was suggesting earlier,
> where we we would cherry-pick major items into a separate branch, so if you
> have any concerns now is the time to raise them.
>
> This release would be a good opportunity to include features that are
> ready to go (suitable for a final release in 2-3 weeks) but didn?t make
> 10.0 (I have a feeling Sanne has been itching for some updates to search!).
> If you have something then send a PR (noting that you want it in 10.1) or
> raise your figurative hand :)..
>
> Thoughts?
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160521/d10131db/attachment.html 

From brian.stansberry at redhat.com  Fri May 20 18:10:05 2016
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Fri, 20 May 2016 17:10:05 -0500
Subject: [wildfly-dev] 10.1 Thoughts and Call for Ready Features
In-Reply-To: <532FC001-347F-438D-AFA2-612E052C72AE@redhat.com>
References: <532FC001-347F-438D-AFA2-612E052C72AE@redhat.com>
Message-ID: <eb79f622-5874-99af-e4c2-1486cd1e3493@redhat.com>

Just an FYI, if you have a change that changes management API, you'll 
need to bump the subsystem API and set up a transformer to the 10.0 
version. Same as always. Just keep that in mind if you propose something 
for 10.1. If the change is small but you expect other changes in 11, do 
you want to go through the effort of the version bump in 10.1?

On 5/20/16 4:45 PM, Jason Greene wrote:
> Hello Everyone,
>
> I?d like to cut a 10.1 fairly soon, preferably in the next 2-3 weeks. My thinking is to take everything that is not explicitly tagged as 11.x and merge it ASAP. Really this should just be anything that doesn?t add instability, or introduces a half-finished API that we then have to support (the obvious exception is experimental capabilities that we denote as such). This is a bit of a departure from what I was suggesting earlier, where we we would cherry-pick major items into a separate branch, so if you have any concerns now is the time to raise them.
>
> This release would be a good opportunity to include features that are ready to go (suitable for a final release in 2-3 weeks) but didn?t make 10.0 (I have a feeling Sanne has been itching for some updates to search!). If you have something then send a PR (noting that you want it in 10.1) or raise your figurative hand :)..
>
> Thoughts?
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


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

From brian.stansberry at redhat.com  Fri May 20 18:14:50 2016
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Fri, 20 May 2016 17:14:50 -0500
Subject: [wildfly-dev] 10.1 Thoughts and Call for Ready Features
In-Reply-To: <532FC001-347F-438D-AFA2-612E052C72AE@redhat.com>
References: <532FC001-347F-438D-AFA2-612E052C72AE@redhat.com>
Message-ID: <00efdbfd-2c99-5774-e171-86a10bd40872@redhat.com>

On 5/20/16 4:45 PM, Jason Greene wrote:
> Hello Everyone,
>
> I?d like to cut a 10.1 fairly soon, preferably in the next 2-3 weeks. My thinking is to take everything that is not explicitly tagged as 11.x

Remember that fairly few people can add github labels, so the present 
set of "11.x" labels really amounts to a couple peoples's tagging, 
mostly me semi-randomly looking at stuff I expect. So it's probably a 
good idea for people, component leads in particular, to mark ASAP ones 
that they don't think should be in 10.1. Probably changing the title to 
include "11.x" or similar is easiest.

> and merge it ASAP. Really this should just be anything that doesn?t add instability, or introduces a half-finished API that we then have to support (the obvious exception is experimental capabilities that we denote as such). This is a bit of a departure from what I was suggesting earlier, where we we would cherry-pick major items into a separate branch, so if you have any concerns now is the time to raise them.
>
> This release would be a good opportunity to include features that are ready to go (suitable for a final release in 2-3 weeks) but didn?t make 10.0 (I have a feeling Sanne has been itching for some updates to search!). If you have something then send a PR (noting that you want it in 10.1) or raise your figurative hand :)..
>
> Thoughts?
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


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

From jason.greene at redhat.com  Fri May 20 22:47:44 2016
From: jason.greene at redhat.com (Jason T. Greene)
Date: Fri, 20 May 2016 22:47:44 -0400 (EDT)
Subject: [wildfly-dev] 10.1 Thoughts and Call for Ready Features
In-Reply-To: <CAE=-AhC+ySGahMeVHjxQZfT_DmR=siF=O5K+XcYUqyFc+Yteeg@mail.gmail.com>
References: <532FC001-347F-438D-AFA2-612E052C72AE@redhat.com>
	<CAE=-AhC+ySGahMeVHjxQZfT_DmR=siF=O5K+XcYUqyFc+Yteeg@mail.gmail.com>
Message-ID: <630BEC60-A5F2-4CCE-A4C7-DC1DC8F14512@redhat.com>

On May 20, 2016, at 5:05 PM, arjan tijms <arjan.tijms at gmail.com> wrote:
> 
> Hi Jason,
> 
> Just wondering, but will WildFly 10.1 be the basis for a future EAP 8, or for a future EAP 7.x?
> 
> How are the WildFly and EAP branches related to each other now that EAP 7 final has been released?

Hi Arjan,

Good question.

A number of the features developed in WildFly 11 will be backported into the EAP 7.1 branch. Some of them might carry over into a 7.2 release. EAP8 is pretty far out, so there will be a number of community releases in between. 

Cheers,
Jason


> 
> Kind regards,
> Arjan Tijms
> 
> 
> 
>> On Fri, May 20, 2016 at 11:45 PM, Jason Greene <jason.greene at redhat.com> wrote:
>> Hello Everyone,
>> 
>> I?d like to cut a 10.1 fairly soon, preferably in the next 2-3 weeks. My thinking is to take everything that is not explicitly tagged as 11.x and merge it ASAP. Really this should just be anything that doesn?t add instability, or introduces a half-finished API that we then have to support (the obvious exception is experimental capabilities that we denote as such). This is a bit of a departure from what I was suggesting earlier, where we we would cherry-pick major items into a separate branch, so if you have any concerns now is the time to raise them.
>> 
>> This release would be a good opportunity to include features that are ready to go (suitable for a final release in 2-3 weeks) but didn?t make 10.0 (I have a feeling Sanne has been itching for some updates to search!). If you have something then send a PR (noting that you want it in 10.1) or raise your figurative hand :)..
>> 
>> Thoughts?
>> --
>> Jason T. Greene
>> WildFly Lead / JBoss EAP Platform Architect
>> JBoss, a division of Red Hat
>> 
>> 
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160520/6d03cbd1/attachment.html 

From ceharris414 at me.com  Sat May 21 09:47:38 2016
From: ceharris414 at me.com (Carl Harris)
Date: Sat, 21 May 2016 09:47:38 -0400
Subject: [wildfly-dev] JavaMail provider module and
	jboss-deployment-structure.xml
Message-ID: <6C07EF89-6E6C-4EA3-ADE0-684770EC80A2@me.com>

I have a custom JavaMail provider installed as a module in Wildfly 10.

In the configuration, I specify a mail session using the custom provider like this:

            <mail-session name="rcpt" jndi-name="FixedRecipient">
                <custom-server name="FixedRecipient">
                   <!-- configuration properties hee -->
                </custom-server>
            </mail-session>


If I make the provider a global module in the configuration, a deployment can successfully use the provider. 

However, if I specify the provider as module dependency in jboss-deployment-structure.xml, when trying to create a javax.mail.Session using the provider, a NoSuchProviderException is thrown (as though the base Session implementation cannot find a META-INF/javamail.providers mapping that identifies the custom provider).

I don't know whether specifying the provider as a deployment structure dependency should work or not, but it seems like it should.

Can someone please explain?

carl





From jai.forums2013 at gmail.com  Mon May 23 01:45:46 2016
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Mon, 23 May 2016 11:15:46 +0530
Subject: [wildfly-dev] 10.1 Thoughts and Call for Ready Features
In-Reply-To: <532FC001-347F-438D-AFA2-612E052C72AE@redhat.com>
References: <532FC001-347F-438D-AFA2-612E052C72AE@redhat.com>
Message-ID: <5742990A.5070402@gmail.com>

FWIW - there's a leak of application classes across redeployments 
currently in 10.x (and in previous releases) 
https://issues.jboss.org/browse/WFLY-6173 and appears to be related to 
Weld integration. Given that such issues have been considered blockers 
during previous releases, I thought I'll bring this issue to the notice 
of this list.

-Jaikiran
On Saturday 21 May 2016 03:15 AM, Jason Greene wrote:
> Hello Everyone,
>
> I?d like to cut a 10.1 fairly soon, preferably in the next 2-3 weeks. My thinking is to take everything that is not explicitly tagged as 11.x and merge it ASAP. Really this should just be anything that doesn?t add instability, or introduces a half-finished API that we then have to support (the obvious exception is experimental capabilities that we denote as such). This is a bit of a departure from what I was suggesting earlier, where we we would cherry-pick major items into a separate branch, so if you have any concerns now is the time to raise them.
>
> This release would be a good opportunity to include features that are ready to go (suitable for a final release in 2-3 weeks) but didn?t make 10.0 (I have a feeling Sanne has been itching for some updates to search!). If you have something then send a PR (noting that you want it in 10.1) or raise your figurative hand :)..
>
> Thoughts?
> --
> 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 emmanuel at hibernate.org  Mon May 23 04:19:15 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 23 May 2016 10:19:15 +0200
Subject: [wildfly-dev] update on WildFly NoSQL prototype integration...
In-Reply-To: <CAFm4XO38HRFSzwhbgZX0bxDPJq=BaHgW9JbtgaR=rz3VF5-ezA@mail.gmail.com>
References: <bf184686-ccbb-f6bf-3ce5-db00cb54bf6c@redhat.com>
	<CADGJaX9JiiEZw+8XqzsZjU2q5jcp3cnnx_7U3G_g4PgT86qQUw@mail.gmail.com>
	<ad804aed-782b-272e-7cde-afbd1598107a@redhat.com>
	<4E9D7BDF-2D04-42AA-9D53-649A63CF66F0@hibernate.org>
	<CAFm4XO38HRFSzwhbgZX0bxDPJq=BaHgW9JbtgaR=rz3VF5-ezA@mail.gmail.com>
Message-ID: <20160523081915.GM47981@hibernate.org>

On Thu 2016-05-12 13:41, Sanne Grinovero wrote:
> On 12 May 2016 at 12:24, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> >
> >
> > On 11 mai 2016, at 16:02, Scott Marlow <smarlow at redhat.com> wrote:
> >
> >>> Hibernate OGM should still be usable without WF; So maybe there should
> >>> be a separate project/repo which defines an SPI to obtain/manage
> >>> connections and implementations for different NoSQL stores?
> >>
> >> Excellent suggestion,  perhaps the SPI could be under
> >> https://github.com/jboss, which is a common area for sharing.  Possible
> >> locations for creating the per NoSQL store implementations could be
> >> https://github.com/jboss or https://github.com/hibernate or
> >> https://github.com/wildfly.
> >
> > I'm starting to think that this might be way overkill. If we are creating a sub project just to share between 20 and 50 lines of code per provider and the overhead code to abstract property configuration to plus OGM and WF ones, we are losing more than gaining.
> >
> > Thoughts ?
> 
> I agree it's overkill, and have an alternative proposal:
> 
> Hibernate OGM should define an interface which is appropriate for its
> own consumption; the Wildfly NoSQL subssystem can have its own
> interface so to not depend on OGM, but they would be somewhat similar
> for each given NoSQL technology we intend to support in this way.
> 
> Then JipiJapa can inject an adaptor into the OGM boostrap phase,
> delegating from one to the other. So only the OGM specific JipiJapa
> module would need to depend on both interfaces.
> If this dependency is not desirable either, then I think we can live
> with a non-typesafe generic provider of things.

But in the end it's just a freaking
if (inWF==true) { //fetch from JNDI } else { ///do it yourself }

Why do you want two layers of abstractions?

From brian.stansberry at redhat.com  Mon May 23 06:50:54 2016
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 23 May 2016 06:50:54 -0400
Subject: [wildfly-dev] 10.1 Thoughts and Call for Ready Features
In-Reply-To: <5742990A.5070402@gmail.com>
References: <532FC001-347F-438D-AFA2-612E052C72AE@redhat.com>
	<5742990A.5070402@gmail.com>
Message-ID: <b9e8974f-284f-77cb-0b5e-b055733da622@redhat.com>

Thanks. To make sure it doesn't fall in a crack I marked it as a blocker 
for 10.1.

On 5/23/16 1:45 AM, Jaikiran Pai wrote:
> FWIW - there's a leak of application classes across redeployments
> currently in 10.x (and in previous releases)
> https://issues.jboss.org/browse/WFLY-6173 and appears to be related to
> Weld integration. Given that such issues have been considered blockers
> during previous releases, I thought I'll bring this issue to the notice
> of this list.
>
> -Jaikiran
> On Saturday 21 May 2016 03:15 AM, Jason Greene wrote:
>> Hello Everyone,
>>
>> I?d like to cut a 10.1 fairly soon, preferably in the next 2-3 weeks. My thinking is to take everything that is not explicitly tagged as 11.x and merge it ASAP. Really this should just be anything that doesn?t add instability, or introduces a half-finished API that we then have to support (the obvious exception is experimental capabilities that we denote as such). This is a bit of a departure from what I was suggesting earlier, where we we would cherry-pick major items into a separate branch, so if you have any concerns now is the time to raise them.
>>
>> This release would be a good opportunity to include features that are ready to go (suitable for a final release in 2-3 weeks) but didn?t make 10.0 (I have a feeling Sanne has been itching for some updates to search!). If you have something then send a PR (noting that you want it in 10.1) or raise your figurative hand :)..
>>
>> Thoughts?
>> --
>> Jason T. Greene
>> WildFly Lead / JBoss EAP Platform Architect
>> JBoss, a division of Red Hat
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


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

From smarlow at redhat.com  Mon May 23 12:25:07 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Mon, 23 May 2016 12:25:07 -0400
Subject: [wildfly-dev] 10.1 Thoughts and Call for Ready Features
In-Reply-To: <532FC001-347F-438D-AFA2-612E052C72AE@redhat.com>
References: <532FC001-347F-438D-AFA2-612E052C72AE@redhat.com>
Message-ID: <32f23ee2-f0d2-d412-de02-07ded360d91f@redhat.com>



On 05/20/2016 05:45 PM, Jason Greene wrote:
> Hello Everyone,
>
> I?d like to cut a 10.1 fairly soon, preferably in the next 2-3 weeks. My thinking is to take everything that is not explicitly tagged as 11.x and merge it ASAP. Really this should just be anything that doesn?t add instability, or introduces a half-finished API that we then have to support (the obvious exception is experimental capabilities that we denote as such). This is a bit of a departure from what I was suggesting earlier, where we we would cherry-pick major items into a separate branch, so if you have any concerns now is the time to raise them.
>
> This release would be a good opportunity to include features that are ready to go (suitable for a final release in 2-3 weeks) but didn?t make 10.0 (I have a feeling Sanne has been itching for some updates to search!). If you have something then send a PR (noting that you want it in 10.1) or raise your figurative hand :)..
>
> Thoughts?

+1 for a quick 10.1 release in 2-3 weeks.

I added comments to the following pending PRs that they are for 10.1:

https://github.com/wildfly/wildfly/pull/8810
https://github.com/wildfly/wildfly/pull/8591

The following javassist export PR is marked as "fixme" but I'm not sure 
exactly what that means.  Would be good to have a comment that explains 
the minimal expected fix (shading Javassist runtime proxy code or adding 
Byte Buddy dependency to Hibernate ORM, so that could be used, which 
IMO, is a longer path and really not my call):

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


> --
> 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 tomaz.cerar at gmail.com  Mon May 23 16:12:52 2016
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Mon, 23 May 2016 22:12:52 +0200
Subject: [wildfly-dev] 10.1 Thoughts and Call for Ready Features
In-Reply-To: <32f23ee2-f0d2-d412-de02-07ded360d91f@redhat.com>
References: <532FC001-347F-438D-AFA2-612E052C72AE@redhat.com>
	<32f23ee2-f0d2-d412-de02-07ded360d91f@redhat.com>
Message-ID: <CAMquZP6P-Zdi20nAituNTqBQNNyEa6mP4Xhz_T5XMo2pbhOBhA@mail.gmail.com>

On Mon, May 23, 2016 at 6:25 PM, Scott Marlow <smarlow at redhat.com> wrote:

> The following javassist export PR is marked as "fixme" but I'm not sure
> exactly what that means.
>


the fixme label was added back in January, when testsuite was still failing
as result of PR itself.
That is long gone now, and it can be removed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160523/9a7f4987/attachment-0001.html 

From abattagl at redhat.com  Wed May 25 06:04:02 2016
From: abattagl at redhat.com (Andrea Battaglia)
Date: Wed, 25 May 2016 12:04:02 +0200
Subject: [wildfly-dev] Proposal for improving the the static modules
	management in Wildfly
Message-ID: <79BC8163-4E48-461A-AAAE-6E912058026D@redhat.com>

Hi all,

I would like to bring to your attention a proposal for improving the the static modules management in wildfly.
After a deep discussion with Sanne Grinovero about the static modules management in wildfly and about some interesting use cases, we tried to design out an improvement that can help both testers and developers.
Here are a couple of use cases of great interest:
 - Testing the new version of an existing module or testing its resources/dependencies: Sometimes it would be useful to test the integration of a different version of the new library into wildfly. Let's think about a patched version of hibernate-core or jgroups. This is supposed to be done without embedding the resource into the application, but delegating the library management to wildfly, instead.
 - Provisioning the static resources for third party libraries dynamically: They asked me to create a lot of static modules for third party libraries a lot of times. This happens each time (always) a bunch of applications use the same, shared set of third party libraries and, of course, each time a developer avoids bundling the libraries inside the binaries (ear/war). Let's think about apache commons, security libraries, or hadoop client libraries (see my github: https://github.com/andreabattaglia/cloudera-eap-modules <https://github.com/andreabattaglia/cloudera-eap-modules>, there you can find a huge set of the static modules for wildfly used to connect to hadoop services without need of embedding the jars into the applications binaries). This usecase applies to the jdbc drivers as well.

 My aim is to avoid wasting time to create the structure of each static module each time a developer needs  brand new one or a different version of it and to avoid wasting time googling for an existing solution. Usually, this activity requires to put a lot of effort in testing the static module as well. Moreover, sometimes , the solution to the same problem can be found on different sites or blogs in different flavours, which is misleading most of all for developers who have no experience in the management of static modules in wildfly.

 The idea: share the descriptor of the static module in a place accessible to all the developers. The tool used to save the descriptor files must be able to version them. Each time the wildfly deployer is asked for a static module which is not bunlded in the default package or is not already available locally, the module descriptor and its resource and dependencies will be built automatically.

 The solution design: wildfly is already able to download the components of a static module from an artifact repository, but this feature strictly relates to the resources.
 It would be useful to improve this feature in order to create a static module locally each time the module is requested by a subsystem or an application being deployed. The deployer should first check for the local module availability. If the module is not available locally, wildfly will first search for the module descriptor into the artifact repository (maven repo implementation), then create folder tree, download resources and repeat iteratively the algorithm for each dependency found in the module descriptor.
 This behaviour will automate the dynamic creation of the static module starting from the module descriptor.

 I'm keen to discuss the proposal with you and to help to design and develop a first implementation as well.

 Thanks a lot in advance for your time,

 Andrea
___________________________
Andrea Battaglia
EMEA Middleware Architect


Red Hat
Via Generale Gustavo Fara, 26
20124 MILANO
www.redhat.com
mobile: +39 328 1093652
fax: +39 02 6693111
email: andrea.battaglia at redhat.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160525/3e3d9533/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rh_signature_logo.png
Type: image/png
Size: 1453 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160525/3e3d9533/attachment.png 

From jason.greene at redhat.com  Thu May 26 05:21:25 2016
From: jason.greene at redhat.com (Jason Greene)
Date: Thu, 26 May 2016 11:21:25 +0200
Subject: [wildfly-dev] Proposal for improving the the static modules
	management in Wildfly
In-Reply-To: <79BC8163-4E48-461A-AAAE-6E912058026D@redhat.com>
References: <79BC8163-4E48-461A-AAAE-6E912058026D@redhat.com>
Message-ID: <C2F99A7F-3D1F-48D7-94B0-A310F1C085D3@redhat.com>

Hi Andrea,

Good timing! We are currently in a meeting discussing a provisioning infrastructure for WildFly. Expect to see some design proposals in this area on this list very soon. I think your idea is potentially doable on top of what we are thinking of building.

-Jason

> On May 25, 2016, at 12:04 PM, Andrea Battaglia <abattagl at redhat.com> wrote:
> 
> Hi all,
> 
> I would like to bring to your attention a proposal for improving the the static modules management in wildfly.
> After a deep discussion with Sanne Grinovero about the static modules management in wildfly and about some interesting use cases, we tried to design out an improvement that can help both testers and developers.
> Here are a couple of use cases of great interest:
>  - Testing the new version of an existing module or testing its resources/dependencies: Sometimes it would be useful to test the integration of a different version of the new library into wildfly. Let's think about a patched version of hibernate-core or jgroups. This is supposed to be done without embedding the resource into the application, but delegating the library management to wildfly, instead.
>  - Provisioning the static resources for third party libraries dynamically: They asked me to create a lot of static modules for third party libraries a lot of times. This happens each time (always) a bunch of applications use the same, shared set of third party libraries and, of course, each time a developer avoids bundling the libraries inside the binaries (ear/war). Let's think about apache commons, security libraries, or hadoop client libraries (see my github: https://github.com/andreabattaglia/cloudera-eap-modules <https://github.com/andreabattaglia/cloudera-eap-modules>, there you can find a huge set of the static modules for wildfly used to connect to hadoop services without need of embedding the jars into the applications binaries). This usecase applies to the jdbc drivers as well.
> 
>  My aim is to avoid wasting time to create the structure of each static module each time a developer needs  brand new one or a different version of it and to avoid wasting time googling for an existing solution. Usually, this activity requires to put a lot of effort in testing the static module as well. Moreover, sometimes , the solution to the same problem can be found on different sites or blogs in different flavours, which is misleading most of all for developers who have no experience in the management of static modules in wildfly.
> 
>  The idea: share the descriptor of the static module in a place accessible to all the developers. The tool used to save the descriptor files must be able to version them. Each time the wildfly deployer is asked for a static module which is not bunlded in the default package or is not already available locally, the module descriptor and its resource and dependencies will be built automatically.
> 
>  The solution design: wildfly is already able to download the components of a static module from an artifact repository, but this feature strictly relates to the resources.
>  It would be useful to improve this feature in order to create a static module locally each time the module is requested by a subsystem or an application being deployed. The deployer should first check for the local module availability. If the module is not available locally, wildfly will first search for the module descriptor into the artifact repository (maven repo implementation), then create folder tree, download resources and repeat iteratively the algorithm for each dependency found in the module descriptor.
>  This behaviour will automate the dynamic creation of the static module starting from the module descriptor.
> 
>  I'm keen to discuss the proposal with you and to help to design and develop a first implementation as well.
> 
>  Thanks a lot in advance for your time,
> 
>  Andrea
> ___________________________
> Andrea Battaglia
> EMEA Middleware Architect
> <rh_signature_logo.png>
> 
> Red Hat
> Via Generale Gustavo Fara, 26
> 20124 MILANO
> www.redhat.com <http://www.redhat.com/>
> mobile: +39 328 1093652
> fax: +39 02 6693111
> email: andrea.battaglia at redhat.com <mailto:andrea.battaglia at redhat.com>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

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

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

From smarlow at redhat.com  Thu May 26 09:02:14 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Thu, 26 May 2016 09:02:14 -0400
Subject: [wildfly-dev] adding several more NoSQL specific connection
 attributes and sucking less in
 MongoDriverSubsystemAdd.performBoottime/CassandraDriverSubsystemAdd.performBoottime
Message-ID: <59b14165-f461-337a-2782-a5cd565523b9@redhat.com>

Hi,

We will soon add several (nested) NoSQL configuration settings.  Before 
we do that, I would like some feedback on the current NoSQL subsystem 
code that reads connection settings.

Any major corrections that you can suggest for the NoSQL subsystem code 
[1][2]?  Especially, the 
MongoDriverSubsystemAdd.performBoottime/CassandraDriverSubsystemAdd.performBoottime 
methods.

Should we continue to read all of the configuration settings from one 
AddStepHandler or should we do that differently (perhaps with separate 
AbstractAddStepHandler's)?

Thanks,
Scott

[1] 
https://github.com/scottmarlow/wildfly/tree/nosql-dev9/nosql/cassandra/src/main/java/org/wildfly/extension/nosql/subsystem/cassandra

[2] 
https://github.com/scottmarlow/wildfly/tree/nosql-dev9/nosql/mongodb/src/main/java/org/wildfly/extension/nosql/subsystem/mongodb

From cfang at redhat.com  Fri May 27 09:23:09 2016
From: cfang at redhat.com (Cheng Fang)
Date: Fri, 27 May 2016 09:23:09 -0400
Subject: [wildfly-dev] Starting/monitoring JSR 352 batch job through
	admin console
In-Reply-To: <364315C6-E65B-4F72-AF9E-50666E4ED38E@redhat.com>
References: <CADGJaX9YWcfBrvzdwuRHMrUwtS3QyL074dyvtJi-yBpcmguxOw@mail.gmail.com>
	<364315C6-E65B-4F72-AF9E-50666E4ED38E@redhat.com>
Message-ID: <CABM4dPTTKz3XEfnPCPqdf+uYEXwUAHBnCAaXWEsbE7wVBpG86g@mail.gmail.com>

Harald,

What's the current plan for this task?  Is there a JIRA issue?

Thanks,
Cheng

On Mon, Mar 7, 2016 at 2:54 AM, Harald Pehl <hpehl at redhat.com> wrote:

> Currently there?s no dedicated support for that in the admin console.
> However you can view any kind of resource which is part of a deployment in
> a generic model browser. Just select the active deployment and click ?View?
> to see all details about the deployment and its subsystems.
>
> We might add a more sophisticated support for that in one of the next
> releases.
>
> > On 05 Mar 2016, at 20:25, Gunnar Morling <gunnar at hibernate.org> wrote:
> >
> > Hi,
> >
> > Is it possible to to start and monitor progress of JSR 352 batch jobs
> > in the admin console?
> >
> > I came across https://issues.jboss.org/browse/WFLY-3174 which states
> > that it's possible through the CLI and other management interfaces but
> > not the UI. Is this still the case?
> >
> > Thanks,
> >
> > --Gunnar
> > _______________________________________________
> > 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/20160527/e0243a92/attachment.html 

From brian.stansberry at redhat.com  Fri May 27 09:33:13 2016
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Fri, 27 May 2016 15:33:13 +0200
Subject: [wildfly-dev] adding several more NoSQL specific connection
 attributes and sucking less in
 MongoDriverSubsystemAdd.performBoottime/CassandraDriverSubsystemAdd.performBoottime
In-Reply-To: <59b14165-f461-337a-2782-a5cd565523b9@redhat.com>
References: <59b14165-f461-337a-2782-a5cd565523b9@redhat.com>
Message-ID: <0b66e7ef-ea37-5862-edff-5d3495221499@redhat.com>

Can a new profile be added post-boot without requiring a reload to take 
effect? If yes, the add handler for the profile resource should do the 
service installation for that profile. It shouldn't count on the parent 
to do it, as the parent logic will only execute during boot.

BTW, if post-boot profile adds/removes don't require reload, then [1] 
should not be inside the "if 
(mongoSubsystem.hasDefined(CommonAttributes.PROFILE)) {" block? Same 
question applies for the cassandra add handler.

[1] 
https://github.com/scottmarlow/wildfly/blob/nosql-dev9/nosql/mongodb/src/main/java/org/wildfly/extension/nosql/subsystem/mongodb/MongoDriverSubsystemAdd.java#L124

On 5/26/16 3:02 PM, Scott Marlow wrote:
> Hi,
>
> We will soon add several (nested) NoSQL configuration settings.  Before
> we do that, I would like some feedback on the current NoSQL subsystem
> code that reads connection settings.
>
> Any major corrections that you can suggest for the NoSQL subsystem code
> [1][2]?  Especially, the
> MongoDriverSubsystemAdd.performBoottime/CassandraDriverSubsystemAdd.performBoottime
> methods.
>
> Should we continue to read all of the configuration settings from one
> AddStepHandler or should we do that differently (perhaps with separate
> AbstractAddStepHandler's)?
>
> Thanks,
> Scott
>
> [1]
> https://github.com/scottmarlow/wildfly/tree/nosql-dev9/nosql/cassandra/src/main/java/org/wildfly/extension/nosql/subsystem/cassandra
>
> [2]
> https://github.com/scottmarlow/wildfly/tree/nosql-dev9/nosql/mongodb/src/main/java/org/wildfly/extension/nosql/subsystem/mongodb
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


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

From smarlow at redhat.com  Fri May 27 10:19:38 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Fri, 27 May 2016 10:19:38 -0400
Subject: [wildfly-dev] adding several more NoSQL specific connection
 attributes and sucking less in
 MongoDriverSubsystemAdd.performBoottime/CassandraDriverSubsystemAdd.performBoottime
In-Reply-To: <0b66e7ef-ea37-5862-edff-5d3495221499@redhat.com>
References: <59b14165-f461-337a-2782-a5cd565523b9@redhat.com>
	<0b66e7ef-ea37-5862-edff-5d3495221499@redhat.com>
Message-ID: <2276deab-3196-fb4a-740e-79d85160a7fa@redhat.com>



On 05/27/2016 09:33 AM, Brian Stansberry wrote:
> Can a new profile be added post-boot without requiring a reload to take
> effect? If yes, the add handler for the profile resource should do the
> service installation for that profile. It shouldn't count on the parent
> to do it, as the parent logic will only execute during boot.

I like the idea of adding a new profile post-boot, without requiring a 
reload of all of the profiles defined by the MongoDB/Cassandra subsystem.

Currently, the standalone*.xml might contain:

<subsystem xmlns="urn:jboss:domain:mongodb:1.0">
   <mongo name="default" id="mongodbtestprofile" 
jndi-name="java:jboss/mongodb/test" database="mongotestdb">
     <host name="default" outbound-socket-binding-ref="mongotesthost"/>
   </mongo>
   <mongo name="default2" id="mongodbdiary" 
jndi-name="java:jboss/mongodb/diary" database="diarydb">
     <host name="default" outbound-socket-binding-ref="mongotesthost"/>
   </mongo>
</subsystem>

If the user wants to add an additional profile to the mongodb subsystem, 
I think it would be worth us making the code changes to allow that. 
Will be great to add a new "otherDB", without stopping the existing 
database profiles.

For supporting "remove" of an existing profile, I think that we will 
need dependencies added on the underlying 
MongoDriverService/CassandraDriverService, will be very worthwhile to 
have that as well!  Great feedback! :-)

>
> BTW, if post-boot profile adds/removes don't require reload, then [1]
> should not be inside the "if
> (mongoSubsystem.hasDefined(CommonAttributes.PROFILE)) {" block?

Makes sense, looks like we need a remove handler also for the profile 
resource.

> Same
> question applies for the cassandra add handler.

We should change the cassandra add handler also.

Thanks again,
Scott

>
> [1]
> https://github.com/scottmarlow/wildfly/blob/nosql-dev9/nosql/mongodb/src/main/java/org/wildfly/extension/nosql/subsystem/mongodb/MongoDriverSubsystemAdd.java#L124
>
> On 5/26/16 3:02 PM, Scott Marlow wrote:
>> Hi,
>>
>> We will soon add several (nested) NoSQL configuration settings.  Before
>> we do that, I would like some feedback on the current NoSQL subsystem
>> code that reads connection settings.
>>
>> Any major corrections that you can suggest for the NoSQL subsystem code
>> [1][2]?  Especially, the
>> MongoDriverSubsystemAdd.performBoottime/CassandraDriverSubsystemAdd.performBoottime
>> methods.
>>
>> Should we continue to read all of the configuration settings from one
>> AddStepHandler or should we do that differently (perhaps with separate
>> AbstractAddStepHandler's)?
>>
>> Thanks,
>> Scott
>>
>> [1]
>> https://github.com/scottmarlow/wildfly/tree/nosql-dev9/nosql/cassandra/src/main/java/org/wildfly/extension/nosql/subsystem/cassandra
>>
>> [2]
>> https://github.com/scottmarlow/wildfly/tree/nosql-dev9/nosql/mongodb/src/main/java/org/wildfly/extension/nosql/subsystem/mongodb
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>

From jperkins at redhat.com  Fri May 27 13:33:44 2016
From: jperkins at redhat.com (James Perkins)
Date: Fri, 27 May 2016 10:33:44 -0700
Subject: [wildfly-dev] Starting/monitoring JSR 352 batch job through
	admin console
In-Reply-To: <CABM4dPTTKz3XEfnPCPqdf+uYEXwUAHBnCAaXWEsbE7wVBpG86g@mail.gmail.com>
References: <CADGJaX9YWcfBrvzdwuRHMrUwtS3QyL074dyvtJi-yBpcmguxOw@mail.gmail.com>
	<364315C6-E65B-4F72-AF9E-50666E4ED38E@redhat.com>
	<CABM4dPTTKz3XEfnPCPqdf+uYEXwUAHBnCAaXWEsbE7wVBpG86g@mail.gmail.com>
Message-ID: <CADGwLpg_gYmZiARC_aPd9u2RWpPRWcvgV_w3QxZ0tG1Vv8Ud=g@mail.gmail.com>

Hi Cheng,
I'm not sure on the JIRA, but I know Claudio in CC is working on it now.

On Fri, May 27, 2016 at 6:23 AM, Cheng Fang <cfang at redhat.com> wrote:

> Harald,
>
> What's the current plan for this task?  Is there a JIRA issue?
>
> Thanks,
> Cheng
>
> On Mon, Mar 7, 2016 at 2:54 AM, Harald Pehl <hpehl at redhat.com> wrote:
>
>> Currently there?s no dedicated support for that in the admin console.
>> However you can view any kind of resource which is part of a deployment in
>> a generic model browser. Just select the active deployment and click ?View?
>> to see all details about the deployment and its subsystems.
>>
>> We might add a more sophisticated support for that in one of the next
>> releases.
>>
>> > On 05 Mar 2016, at 20:25, Gunnar Morling <gunnar at hibernate.org> wrote:
>> >
>> > Hi,
>> >
>> > Is it possible to to start and monitor progress of JSR 352 batch jobs
>> > in the admin console?
>> >
>> > I came across https://issues.jboss.org/browse/WFLY-3174 which states
>> > that it's possible through the CLI and other management interfaces but
>> > not the UI. Is this still the case?
>> >
>> > Thanks,
>> >
>> > --Gunnar
>> > _______________________________________________
>> > 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
>



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

From cfang at redhat.com  Fri May 27 15:16:18 2016
From: cfang at redhat.com (Cheng Fang)
Date: Fri, 27 May 2016 15:16:18 -0400
Subject: [wildfly-dev] Starting/monitoring JSR 352 batch job through
	admin console
In-Reply-To: <CANn-eM8FFjvnWDEujCN=YXeDF4wNEjAW9sBax=CjhYRog3ReHw@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>
	<CANn-eM8FFjvnWDEujCN=YXeDF4wNEjAW9sBax=CjhYRog3ReHw@mail.gmail.com>
Message-ID: <CABM4dPT-r5pHPNK7JCT-i8RMbjHOS-KRkKEBZESq9jhLHU9=7Q@mail.gmail.com>

That's good to know.  If you need any change on jberet side, let James and
I know.

Thanks,
Cheng

On Fri, May 27, 2016 at 1:42 PM, Claudio Miranda <claudio at redhat.com> wrote:

> 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.
>
> Hi, I am working on it right now.
>
> https://issues.jboss.org/browse/HAL-1104
>
> --
> Claudio Miranda <claudio at redhat.com>
> Senior Software Engineer - Wildfly
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160527/9a6d0cdf/attachment-0001.html 

From claudio at claudius.com.br  Sat May 28 11:09:54 2016
From: claudio at claudius.com.br (Claudio Miranda)
Date: Sat, 28 May 2016 12:09:54 -0300
Subject: [wildfly-dev] Starting/monitoring JSR 352 batch job through
	admin console
In-Reply-To: <CADGwLpg_gYmZiARC_aPd9u2RWpPRWcvgV_w3QxZ0tG1Vv8Ud=g@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>
Message-ID: <CALbD--o_LieMSfNs56LZZC6gpPvwbR60nN9+dg=SwJpzNy1XuQ@mail.gmail.com>

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

From hbraun at redhat.com  Mon May 30 04:50:37 2016
From: hbraun at redhat.com (Heiko Braun)
Date: Mon, 30 May 2016 10:50:37 +0200
Subject: [wildfly-dev] Wildfly Swarm 1.0.0.CR1
Message-ID: <AFAD0DDA-6531-4A6D-AC7B-338A12C32B38@redhat.com>


Since both projects are closely related I hope it?s ok to cross post here. 

WildFly Swarm is approaching it?s first final release [1] and things become more stable and enjoyable to work with. If you haven?t done so already, now would be good time to time to take a closer look and see how Swarm may fit into your architecture. We?ve got plenty of examples [2] to get you going and a friendly and responsive mailing list [3] in case you get stuck. 

Regards, Heiko 

[1] http://wildfly-swarm.io/posts/announcement-1-0-0-cr1/ <http://wildfly-swarm.io/posts/announcement-1-0-0-cr1/>
[2] https://github.com/wildfly-swarm/wildfly-swarm-examples/tree/1.0.0.CR1 <https://github.com/wildfly-swarm/wildfly-swarm-examples/tree/1.0.0.CR1>
[3] https://groups.google.com/forum/?nomobile=true#!forum/wildfly-swarm <https://groups.google.com/forum/?nomobile=true#!forum/wildfly-swarm>







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

From rory.odonnell at oracle.com  Mon May 30 08:51:58 2016
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Mon, 30 May 2016 13:51:58 +0100
Subject: [wildfly-dev] Early Access builds of JDK 9 b120 & JDK 9 with
 Project Jigsaw b120 (#5074) are available on java.net
Message-ID: <f7793277-b972-e815-9d18-49e095c75fb5@oracle.com>

Hi Jason/Tomaz,

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

Early Access b120 <https://jdk9.java.net/jigsaw/> (#5074) for JDK 9 with 
Project Jigsaw is available on java.net.

JDK 9 Build 120 has over *400 *bug fixes, hotspot fixes making a 
significant contribution.
In addition , this build implements JEP 289: Deprecate the Applet API [1]

Notable changes since the is last announcement email - in JDK 9 b119 the 
big change
was moving the class file version from 52.0 to 53.0, see [2] for more 
details.

Rgds,Rory

[1] JEP 289: Deprecate the Applet API <http://openjdk.java.net/jeps/289>
[2] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-January/003507.html

-- 
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/20160530/b347a3ee/attachment.html 

From bmcwhirt at redhat.com  Mon May 30 13:04:54 2016
From: bmcwhirt at redhat.com (Bob McWhirter)
Date: Mon, 30 May 2016 13:04:54 -0400
Subject: [wildfly-dev] Proposal for improving the the static modules
 management in Wildfly
In-Reply-To: <C2F99A7F-3D1F-48D7-94B0-A310F1C085D3@redhat.com>
References: <79BC8163-4E48-461A-AAAE-6E912058026D@redhat.com>
	<C2F99A7F-3D1F-48D7-94B0-A310F1C085D3@redhat.com>
Message-ID: <CA+45JvF2XHsSR-V2RGbHoM83HPON2huLUnzeVOoaHOsBZ6KwuA@mail.gmail.com>

Somewhat related, maybe, would be to extend this to the entirety of the
modules tree that already exist in the feature-packs.

If every module was Maven addressable, in some form, this could conceivably
simplify the way WildFly Swarm stitches stuff together.

We currently have to prowl around and pluck stuff out of feature-packs, and
remember which feature-packs provide which modules.

With this, we could point to a small set of root module.xml?s and let maven
transitives find the subsequent module.xml files without having to consider
feature-packs.

I would recommend, in this case, some flavor of feature-pack plugin to
handle the current feature-pack disassembly and deployment into Central.

-Bob

On Thu, May 26, 2016 at 5:21 AM, Jason Greene <jason.greene at redhat.com>
wrote:

> Hi Andrea,
>
> Good timing! We are currently in a meeting discussing a provisioning
> infrastructure for WildFly. Expect to see some design proposals in this
> area on this list very soon. I think your idea is potentially doable on top
> of what we are thinking of building.
>
> -Jason
>
> On May 25, 2016, at 12:04 PM, Andrea Battaglia <abattagl at redhat.com>
> wrote:
>
> Hi all,
>
> I would like to bring to your attention a proposal for improving the the
> static modules management in wildfly.
> After a deep discussion with Sanne Grinovero about the static modules
> management in wildfly and about some interesting use cases, we tried to
> design out an improvement that can help both testers and developers.
> Here are a couple of use cases of great interest:
>  - Testing the new version of an existing module or testing its
> resources/dependencies: Sometimes it would be useful to test the
> integration of a different version of the new library into wildfly. Let's
> think about a patched version of hibernate-core or jgroups. This is
> supposed to be done without embedding the resource into the application,
> but delegating the library management to wildfly, instead.
>  - Provisioning the static resources for third party libraries
> dynamically: They asked me to create a lot of static modules for third
> party libraries a lot of times. This happens each time (always) a bunch of
> applications use the same, shared set of third party libraries and, of
> course, each time a developer avoids bundling the libraries inside the
> binaries (ear/war). Let's think about apache commons, security libraries,
> or hadoop client libraries (see my github:
> https://github.com/andreabattaglia/cloudera-eap-modules, there you can
> find a huge set of the static modules for wildfly used to connect to hadoop
> services without need of embedding the jars into the applications
> binaries). This usecase applies to the jdbc drivers as well.
>
>  My aim is to avoid wasting time to create the structure of each static
> module each time a developer needs  brand new one or a different version of
> it and to avoid wasting time googling for an existing solution. Usually,
> this activity requires to put a lot of effort in testing the static module
> as well. Moreover, sometimes , the solution to the same problem can be
> found on different sites or blogs in different flavours, which is
> misleading most of all for developers who have no experience in the
> management of static modules in wildfly.
>
>  The idea: share the descriptor of the static module in a place accessible
> to all the developers. The tool used to save the descriptor files must be
> able to version them. Each time the wildfly deployer is asked for a static
> module which is not bunlded in the default package or is not already
> available locally, the module descriptor and its resource and dependencies
> will be built automatically.
>
>  The solution design: wildfly is already able to download the components
> of a static module from an artifact repository, but this feature strictly
> relates to the resources.
>  It would be useful to improve this feature in order to create a static
> module locally each time the module is requested by a subsystem or an
> application being deployed. The deployer should first check for the local
> module availability. If the module is not available locally, wildfly will
> first search for the module descriptor into the artifact repository (maven
> repo implementation), then create folder tree, download resources and
> repeat iteratively the algorithm for each dependency found in the module
> descriptor.
>  This behaviour will automate the dynamic creation of the static module
> starting from the module descriptor.
>
>  I'm keen to discuss the proposal with you and to help to design and
> develop a first implementation as well.
>
>  Thanks a lot in advance for your time,
>
>  Andrea
> ___________________________
> Andrea Battaglia
> EMEA Middleware Architect
> <rh_signature_logo.png>
>
> Red Hat
> Via Generale Gustavo Fara, 26
> 20124 MILANO
> www.redhat.com
> mobile: +39 328 1093652
> fax: +39 02 6693111
> email: andrea.battaglia at redhat.com
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160530/b55db7d1/attachment-0001.html 

From smarlow at redhat.com  Tue May 31 16:48:50 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 31 May 2016 16:48:50 -0400
Subject: [wildfly-dev] adding several more NoSQL specific connection
 attributes and sucking less in
 MongoDriverSubsystemAdd.performBoottime/CassandraDriverSubsystemAdd.performBoottime
In-Reply-To: <2276deab-3196-fb4a-740e-79d85160a7fa@redhat.com>
References: <59b14165-f461-337a-2782-a5cd565523b9@redhat.com>
	<0b66e7ef-ea37-5862-edff-5d3495221499@redhat.com>
	<2276deab-3196-fb4a-740e-79d85160a7fa@redhat.com>
Message-ID: <673f9b90-e26f-bd2b-3567-8c07ba680d67@redhat.com>



On 05/27/2016 10:19 AM, Scott Marlow wrote:
>
>
> On 05/27/2016 09:33 AM, Brian Stansberry wrote:
>> Can a new profile be added post-boot without requiring a reload to take
>> effect? If yes, the add handler for the profile resource should do the
>> service installation for that profile. It shouldn't count on the parent
>> to do it, as the parent logic will only execute during boot.
>
> I like the idea of adding a new profile post-boot, without requiring a
> reload of all of the profiles defined by the MongoDB/Cassandra subsystem.

I need to back up on my response.  What does it mean for adding a new 
profile without requiring a reload?  Does that require a hot change to 
the NoSQL profile service without undeploying the application?

>
> Currently, the standalone*.xml might contain:
>
> <subsystem xmlns="urn:jboss:domain:mongodb:1.0">
>    <mongo name="default" id="mongodbtestprofile"
> jndi-name="java:jboss/mongodb/test" database="mongotestdb">
>      <host name="default" outbound-socket-binding-ref="mongotesthost"/>
>    </mongo>
>    <mongo name="default2" id="mongodbdiary"
> jndi-name="java:jboss/mongodb/diary" database="diarydb">
>      <host name="default" outbound-socket-binding-ref="mongotesthost"/>
>    </mongo>
> </subsystem>
>
> If the user wants to add an additional profile to the mongodb subsystem,
> I think it would be worth us making the code changes to allow that.
> Will be great to add a new "otherDB", without stopping the existing
> database profiles.
>
> For supporting "remove" of an existing profile, I think that we will
> need dependencies added on the underlying
> MongoDriverService/CassandraDriverService, will be very worthwhile to
> have that as well!  Great feedback! :-)
>
>>
>> BTW, if post-boot profile adds/removes don't require reload, then [1]
>> should not be inside the "if
>> (mongoSubsystem.hasDefined(CommonAttributes.PROFILE)) {" block?
>
> Makes sense, looks like we need a remove handler also for the profile
> resource.
>
>> Same
>> question applies for the cassandra add handler.
>
> We should change the cassandra add handler also.
>
> Thanks again,
> Scott
>
>>
>> [1]
>> https://github.com/scottmarlow/wildfly/blob/nosql-dev9/nosql/mongodb/src/main/java/org/wildfly/extension/nosql/subsystem/mongodb/MongoDriverSubsystemAdd.java#L124
>>
>> On 5/26/16 3:02 PM, Scott Marlow wrote:
>>> Hi,
>>>
>>> We will soon add several (nested) NoSQL configuration settings.  Before
>>> we do that, I would like some feedback on the current NoSQL subsystem
>>> code that reads connection settings.
>>>
>>> Any major corrections that you can suggest for the NoSQL subsystem code
>>> [1][2]?  Especially, the
>>> MongoDriverSubsystemAdd.performBoottime/CassandraDriverSubsystemAdd.performBoottime
>>> methods.
>>>
>>> Should we continue to read all of the configuration settings from one
>>> AddStepHandler or should we do that differently (perhaps with separate
>>> AbstractAddStepHandler's)?
>>>
>>> Thanks,
>>> Scott
>>>
>>> [1]
>>> https://github.com/scottmarlow/wildfly/tree/nosql-dev9/nosql/cassandra/src/main/java/org/wildfly/extension/nosql/subsystem/cassandra
>>>
>>> [2]
>>> https://github.com/scottmarlow/wildfly/tree/nosql-dev9/nosql/mongodb/src/main/java/org/wildfly/extension/nosql/subsystem/mongodb
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From smarlow at redhat.com  Tue May 31 19:04:38 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 31 May 2016 19:04:38 -0400
Subject: [wildfly-dev] adding several more NoSQL specific connection
 attributes and sucking less in
 MongoDriverSubsystemAdd.performBoottime/CassandraDriverSubsystemAdd.performBoottime
In-Reply-To: <673f9b90-e26f-bd2b-3567-8c07ba680d67@redhat.com>
References: <59b14165-f461-337a-2782-a5cd565523b9@redhat.com>
	<0b66e7ef-ea37-5862-edff-5d3495221499@redhat.com>
	<2276deab-3196-fb4a-740e-79d85160a7fa@redhat.com>
	<673f9b90-e26f-bd2b-3567-8c07ba680d67@redhat.com>
Message-ID: <320939ba-369a-b80e-f7d5-532d78aaf38c@redhat.com>


On 05/31/2016 04:48 PM, Scott Marlow wrote:
>
>
> On 05/27/2016 10:19 AM, Scott Marlow wrote:
>>
>>
>> On 05/27/2016 09:33 AM, Brian Stansberry wrote:
>>> Can a new profile be added post-boot without requiring a reload to take
>>> effect? If yes, the add handler for the profile resource should do the
>>> service installation for that profile. It shouldn't count on the parent
>>> to do it, as the parent logic will only execute during boot.
>>
>> I like the idea of adding a new profile post-boot, without requiring a
>> reload of all of the profiles defined by the MongoDB/Cassandra subsystem.
>
> I need to back up on my response.  What does it mean for adding a new
> profile without requiring a reload?  Does that require a hot change to
> the NoSQL profile service without undeploying the application?

After refreshing on 
https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-applyingruntimeupdates, 
I think currently, we should specify that a reload (all-services) is 
needed when adding/removing profiles.

>
>>
>> Currently, the standalone*.xml might contain:
>>
>> <subsystem xmlns="urn:jboss:domain:mongodb:1.0">
>>    <mongo name="default" id="mongodbtestprofile"
>> jndi-name="java:jboss/mongodb/test" database="mongotestdb">
>>      <host name="default" outbound-socket-binding-ref="mongotesthost"/>
>>    </mongo>
>>    <mongo name="default2" id="mongodbdiary"
>> jndi-name="java:jboss/mongodb/diary" database="diarydb">
>>      <host name="default" outbound-socket-binding-ref="mongotesthost"/>
>>    </mongo>
>> </subsystem>
>>
>> If the user wants to add an additional profile to the mongodb subsystem,
>> I think it would be worth us making the code changes to allow that.
>> Will be great to add a new "otherDB", without stopping the existing
>> database profiles.
>>
>> For supporting "remove" of an existing profile, I think that we will
>> need dependencies added on the underlying
>> MongoDriverService/CassandraDriverService, will be very worthwhile to
>> have that as well!  Great feedback! :-)
>>
>>>
>>> BTW, if post-boot profile adds/removes don't require reload, then [1]
>>> should not be inside the "if
>>> (mongoSubsystem.hasDefined(CommonAttributes.PROFILE)) {" block?
>>
>> Makes sense, looks like we need a remove handler also for the profile
>> resource.
>>
>>> Same
>>> question applies for the cassandra add handler.
>>
>> We should change the cassandra add handler also.
>>
>> Thanks again,
>> Scott
>>
>>>
>>> [1]
>>> https://github.com/scottmarlow/wildfly/blob/nosql-dev9/nosql/mongodb/src/main/java/org/wildfly/extension/nosql/subsystem/mongodb/MongoDriverSubsystemAdd.java#L124
>>>
>>> On 5/26/16 3:02 PM, Scott Marlow wrote:
>>>> Hi,
>>>>
>>>> We will soon add several (nested) NoSQL configuration settings.  Before
>>>> we do that, I would like some feedback on the current NoSQL subsystem
>>>> code that reads connection settings.
>>>>
>>>> Any major corrections that you can suggest for the NoSQL subsystem code
>>>> [1][2]?  Especially, the
>>>> MongoDriverSubsystemAdd.performBoottime/CassandraDriverSubsystemAdd.performBoottime
>>>> methods.
>>>>
>>>> Should we continue to read all of the configuration settings from one
>>>> AddStepHandler or should we do that differently (perhaps with separate
>>>> AbstractAddStepHandler's)?
>>>>
>>>> Thanks,
>>>> Scott
>>>>
>>>> [1]
>>>> https://github.com/scottmarlow/wildfly/tree/nosql-dev9/nosql/cassandra/src/main/java/org/wildfly/extension/nosql/subsystem/cassandra
>>>>
>>>> [2]
>>>> https://github.com/scottmarlow/wildfly/tree/nosql-dev9/nosql/mongodb/src/main/java/org/wildfly/extension/nosql/subsystem/mongodb
>>>> _______________________________________________
>>>> 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
>