From manderse at redhat.com  Sat Nov  1 05:23:51 2014
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Sat, 01 Nov 2014 10:23:51 +0100
Subject: [wildfly-dev] Issues in wildfly-javaee7-webapp-blank-archetype
In-Reply-To: <CAGBoHQUeiP+k_skwYLPj2_6RszLFSKGq+QY0xx3oOitHivhNRA@mail.gmail.com>
References: <CAGBoHQUzEVzAj8ExN+40TkgzCKb+zbWjx2rKp6GgztnrxeN_FA@mail.gmail.com>
	<5451F693.2070807@redhat.com>
	<CAGBoHQXFy9mi6MY4JHKOfEUpFudASj9mWA8oY0SnNWgwqW8FBA@mail.gmail.com>
	<CADP5VTVxRYLfNASgiauv24E_m6TRiYO4c=1w5ub5fWHcA0Wydw@mail.gmail.com>
	<CAGBoHQUeiP+k_skwYLPj2_6RszLFSKGq+QY0xx3oOitHivhNRA@mail.gmail.com>
Message-ID: <A62D4239-F078-4D33-AEBF-D44F7C133A2B@redhat.com>

I would consider it best practice that you have a way to separate what 
database you run against and what database you test against.

Using -test.ds.xml is a way to achieve that in a way that works in all 
cases without requiring property replacement magic doing development 
afair.

/max

> Default data sources is one of the new features of Java EE 7 and I 
> think
> its worth showcasing how apps can be simplified with that. I'll let 
> you
> decide upon resource/time but its useful IMHO.
>
> Arun
>
> On Fri Oct 31 2014 at 6:01:34 AM Sebastian ?askawiec <
> sebastian.laskawiec at gmail.com> wrote:
>
>> Hi Arun!
>>
>> Wildfly archetypes are created based on Quickstarts (just as Rafael
>> mentioned here [1]).
>> In case of *wildfly-**javaee7-webapp-blank-archetype* it is 
>> *kitchensink*
>> [1]. Quickstarts are designed in such a way, that they can be 
>> deployed all
>> together (this is why they need separate datasources).
>>
>> So, test-ds.xml is a design consequence of how Quickstarts are 
>> embedded
>> into archetypes. In my opinion we won't be able to get rid of it.
>> Alternatively we could refactor all quickstarts to use default 
>> database -
>> which might be pretty time consuming.
>>
>> Best regards
>> Sebastian
>>
>> [1] 
>> https://issues.jboss.org/browse/WFLY-4030?focusedCommentId=13016156
>> [2] https://github.com/wildfly/quickstart/tree/master/kitchensink
>>
>>
>> 2014-10-30 13:04 GMT+01:00 Arun Gupta <arun.gupta at gmail.com>:
>>
>>> For Java EE 7, a default data source is available if none is 
>>> specified
>>> in persistence.xml. In WildFly, this is mapped to ExampleDS already.
>>>
>>> Does test-ds.xml create a new data source, or map to an existing one 
>>> ?
>>>
>>> Arun
>>>
>>> On Thu, Oct 30, 2014 at 1:28 AM, Sebastian ?askawiec
>>> <slaskawi at redhat.com> wrote:
>>>> Hey
>>>>
>>>> I would like to volunteer for WFLY-4030 and a Quickstarts change:
>>> WFLY-4031.
>>>>
>>>> However I'm not sure about removing test-ds.xml. Maybe the point is 
>>>> to
>>>> show how to add DataSources bundled with the application?
>>>> On the other hand if this is not the point - I think we should 
>>>> change it
>>>> to ExampleDS.
>>>>
>>>> What's your opinion on that?
>>>>
>>>> Best regards
>>>> Sebastian
>>>>
>>>> On 10/29/2014 07:54 PM, Arun Gupta wrote:
>>>>> - What is the purpose of test-ds.xml ? It contains:
>>>>> This is anyway the default Java EE 7 data source in WildFly.
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>>>
>>> --
>>> http://blog.arungupta.me
>>> http://twitter.com/arungupta
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>
>>
>> --
>> Sebastian ?askawiec
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


/max
http://about.me/maxandersen

From stuart.w.douglas at gmail.com  Sun Nov  2 18:48:04 2014
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Mon, 3 Nov 2014 10:48:04 +1100
Subject: [wildfly-dev] Issues in wildfly-javaee7-webapp-blank-archetype
In-Reply-To: <CAGBoHQUeiP+k_skwYLPj2_6RszLFSKGq+QY0xx3oOitHivhNRA@mail.gmail.com>
References: <CAGBoHQUzEVzAj8ExN+40TkgzCKb+zbWjx2rKp6GgztnrxeN_FA@mail.gmail.com>
	<5451F693.2070807@redhat.com>
	<CAGBoHQXFy9mi6MY4JHKOfEUpFudASj9mWA8oY0SnNWgwqW8FBA@mail.gmail.com>
	<CADP5VTVxRYLfNASgiauv24E_m6TRiYO4c=1w5ub5fWHcA0Wydw@mail.gmail.com>
	<CAGBoHQUeiP+k_skwYLPj2_6RszLFSKGq+QY0xx3oOitHivhNRA@mail.gmail.com>
Message-ID: <CAAoo=c7D9jUA5+9eAeTCUVORZpgWWGzXZngajDpNVoLtxtLejw@mail.gmail.com>

I don't think people are going to want to run (non toy) apps against our
built in h2 server, which means they will want to define their own
datasource. Leaving this file in the quickstart provides them with an easy
template to work from.

Stuart

On Sat, Nov 1, 2014 at 12:07 AM, Arun Gupta <arun.gupta at gmail.com> wrote:

> Default data sources is one of the new features of Java EE 7 and I think
> its worth showcasing how apps can be simplified with that. I'll let you
> decide upon resource/time but its useful IMHO.
>
> Arun
>
> On Fri Oct 31 2014 at 6:01:34 AM Sebastian ?askawiec <
> sebastian.laskawiec at gmail.com> wrote:
>
>> Hi Arun!
>>
>> Wildfly archetypes are created based on Quickstarts (just as Rafael
>> mentioned here [1]).
>> In case of *wildfly-**javaee7-webapp-blank-archetype* it is *kitchensink*
>> [1]. Quickstarts are designed in such a way, that they can be deployed all
>> together (this is why they need separate datasources).
>>
>> So, test-ds.xml is a design consequence of how Quickstarts are embedded
>> into archetypes. In my opinion we won't be able to get rid of it.
>> Alternatively we could refactor all quickstarts to use default database -
>> which might be pretty time consuming.
>>
>> Best regards
>> Sebastian
>>
>> [1] https://issues.jboss.org/browse/WFLY-4030?focusedCommentId=13016156
>> [2] https://github.com/wildfly/quickstart/tree/master/kitchensink
>>
>>
>> 2014-10-30 13:04 GMT+01:00 Arun Gupta <arun.gupta at gmail.com>:
>>
>>> For Java EE 7, a default data source is available if none is specified
>>> in persistence.xml. In WildFly, this is mapped to ExampleDS already.
>>>
>>> Does test-ds.xml create a new data source, or map to an existing one ?
>>>
>>> Arun
>>>
>>> On Thu, Oct 30, 2014 at 1:28 AM, Sebastian ?askawiec
>>> <slaskawi at redhat.com> wrote:
>>> > Hey
>>> >
>>> > I would like to volunteer for WFLY-4030 and a Quickstarts change:
>>> WFLY-4031.
>>> >
>>> > However I'm not sure about removing test-ds.xml. Maybe the point is to
>>> > show how to add DataSources bundled with the application?
>>> > On the other hand if this is not the point - I think we should change
>>> it
>>> > to ExampleDS.
>>> >
>>> > What's your opinion on that?
>>> >
>>> > Best regards
>>> > Sebastian
>>> >
>>> > On 10/29/2014 07:54 PM, Arun Gupta wrote:
>>> >> - What is the purpose of test-ds.xml ? It contains:
>>> >> This is anyway the default Java EE 7 data source in WildFly.
>>> >
>>> > _______________________________________________
>>> > wildfly-dev mailing list
>>> > wildfly-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>>>
>>> --
>>> http://blog.arungupta.me
>>> http://twitter.com/arungupta
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>
>>
>> --
>> Sebastian ?askawiec
>>
>
> _______________________________________________
> 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/20141103/472abb04/attachment.html 

From lzoubek at redhat.com  Mon Nov  3 05:23:03 2014
From: lzoubek at redhat.com (Libor Zoubek)
Date: Mon, 3 Nov 2014 05:23:03 -0500 (EST)
Subject: [wildfly-dev] Announcing wildfly extension installer maven plugin
In-Reply-To: <476743654.4040778.1415008177214.JavaMail.zimbra@redhat.com>
Message-ID: <817982016.4058714.1415010183628.JavaMail.zimbra@redhat.com>

Hello, 

I'm happy to announce maven plugin capable of installing JBoss module to WildFly.

It provides helpful mojo to:
 - lay down JBoss module
 - register extension
 - setup subsystem
 - setup socket binding

It may become useful for developing/testing WildFly subsystems.

If interested, please see blogpost http://lzoubek.blogspot.com/2014/10/wildfly-extension-installer-maven-plugin.html or documentation http://lzoubek.github.io/wildfly-extension-maven-plugin/

Regards,

Libor Zoubek

From kpiwko at redhat.com  Mon Nov  3 11:49:34 2014
From: kpiwko at redhat.com (Karel Piwko)
Date: Mon, 03 Nov 2014 17:49:34 +0100
Subject: [wildfly-dev] Is there a chance to sync org.jboss:staxmapper to
	Maven Central?
Message-ID: <1415033374.2266.13.camel@kpiwko-x220>

Hi All, 

it looks like that some of the dependencies are missing in Maven Central
[1]. This does not matter if using Maven to resolve artifacts but fails
with Gradle that is ignoring <repository> element in pom.xml files.

Any chance that org.jboss:staxmapper:jar:1.1.0.Final can be synced to
Maven Central? Or its newer version?

https://repository.jboss.org/nexus/service/local/repositories/releases/content/org/jboss/staxmapper/1.1.0.Final/staxmapper-1.1.0.Final.pom

Thanks,

Karel

[1]
[INFO] +- org.jboss.as:jboss-as-controller:jar:7.2.0.Final:compile
[INFO] | +- org.jboss.modules:jboss-modules:jar:1.2.0.CR1:compile
[INFO] | +- org.jboss.msc:jboss-msc:jar:1.0.4.GA:compile
[INFO] | \- org.jboss:staxmapper:jar:1.1.0.Final:compile



From kabir.khan at jboss.com  Mon Nov  3 12:12:46 2014
From: kabir.khan at jboss.com (Kabir Khan)
Date: Mon, 3 Nov 2014 17:12:46 +0000
Subject: [wildfly-dev] Is there a chance to sync org.jboss:staxmapper to
	Maven Central?
In-Reply-To: <1415033374.2266.13.camel@kpiwko-x220>
References: <1415033374.2266.13.camel@kpiwko-x220>
Message-ID: <530C3597-E01B-4D27-877F-D6DF24F63477@jboss.com>

> On 3 Nov 2014, at 16:49, Karel Piwko <kpiwko at redhat.com> wrote:
> 
> Hi All, 
> 
> it looks like that some of the dependencies are missing in Maven Central
> [1]. This does not matter if using Maven to resolve artifacts but fails
> with Gradle that is ignoring <repository> element in pom.xml files.
> 
> Any chance that org.jboss:staxmapper:jar:1.1.0.Final can be synced to
> Maven Central?
I?ll leave that to whoever knows how :-)

> Or its newer version?
WFCORE master is also on 1.1.0.Final

> 
> https://repository.jboss.org/nexus/service/local/repositories/releases/content/org/jboss/staxmapper/1.1.0.Final/staxmapper-1.1.0.Final.pom
> 
> Thanks,
> 
> Karel
> 
> [1]
> [INFO] +- org.jboss.as:jboss-as-controller:jar:7.2.0.Final:compile
> [INFO] | +- org.jboss.modules:jboss-modules:jar:1.2.0.CR1:compile
> [INFO] | +- org.jboss.msc:jboss-msc:jar:1.0.4.GA:compile
> [INFO] | \- org.jboss:staxmapper:jar:1.1.0.Final:compile
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



From jperkins at redhat.com  Mon Nov  3 12:19:39 2014
From: jperkins at redhat.com (James R. Perkins)
Date: Mon, 03 Nov 2014 09:19:39 -0800
Subject: [wildfly-dev] Is there a chance to sync org.jboss:staxmapper to
 Maven Central?
In-Reply-To: <1415033374.2266.13.camel@kpiwko-x220>
References: <1415033374.2266.13.camel@kpiwko-x220>
Message-ID: <5457B92B.4050404@redhat.com>

Odd that it hasn't been updated, but it's not on the list 
https://developer.jboss.org/wiki/MavenRepositoryCentralSynchronization. 
Anyway yes I can handle that if no one else is at this point.

We should probably gather a list of other projects that need a sync as 
well to ensure we're getting them all.

On 11/03/2014 08:49 AM, Karel Piwko wrote:
> Hi All,
>
> it looks like that some of the dependencies are missing in Maven Central
> [1]. This does not matter if using Maven to resolve artifacts but fails
> with Gradle that is ignoring <repository> element in pom.xml files.
>
> Any chance that org.jboss:staxmapper:jar:1.1.0.Final can be synced to
> Maven Central? Or its newer version?
>
> https://repository.jboss.org/nexus/service/local/repositories/releases/content/org/jboss/staxmapper/1.1.0.Final/staxmapper-1.1.0.Final.pom
>
> Thanks,
>
> Karel
>
> [1]
> [INFO] +- org.jboss.as:jboss-as-controller:jar:7.2.0.Final:compile
> [INFO] | +- org.jboss.modules:jboss-modules:jar:1.2.0.CR1:compile
> [INFO] | +- org.jboss.msc:jboss-msc:jar:1.0.4.GA:compile
> [INFO] | \- org.jboss:staxmapper:jar:1.1.0.Final:compile
>
>
> _______________________________________________
> 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


From kpiwko at redhat.com  Mon Nov  3 12:24:23 2014
From: kpiwko at redhat.com (Karel Piwko)
Date: Mon, 03 Nov 2014 18:24:23 +0100
Subject: [wildfly-dev] Is there a chance to sync org.jboss:staxmapper to
 Maven Central?
In-Reply-To: <530C3597-E01B-4D27-877F-D6DF24F63477@jboss.com>
References: <1415033374.2266.13.camel@kpiwko-x220>
	<530C3597-E01B-4D27-877F-D6DF24F63477@jboss.com>
Message-ID: <1415035463.2266.18.camel@kpiwko-x220>

I can ask Sonatype guys for sync of groupId:artifactId of
org.jboss:staxmapper if nobody is against it. There is a chance that it
would be zero work effort. If not, there will be a report what formal
requirements is pom.xml missing, that would mean releasing newer version
with fixes if we want it in Central.

Karel

On Mon, 2014-11-03 at 17:12 +0000, Kabir Khan wrote:
> > On 3 Nov 2014, at 16:49, Karel Piwko <kpiwko at redhat.com> wrote:
> > 
> > Hi All, 
> > 
> > it looks like that some of the dependencies are missing in Maven Central
> > [1]. This does not matter if using Maven to resolve artifacts but fails
> > with Gradle that is ignoring <repository> element in pom.xml files.
> > 
> > Any chance that org.jboss:staxmapper:jar:1.1.0.Final can be synced to
> > Maven Central?
> I?ll leave that to whoever knows how :-)
> 
> > Or its newer version?
> WFCORE master is also on 1.1.0.Final
> 
> > 
> > https://repository.jboss.org/nexus/service/local/repositories/releases/content/org/jboss/staxmapper/1.1.0.Final/staxmapper-1.1.0.Final.pom
> > 
> > Thanks,
> > 
> > Karel
> > 
> > [1]
> > [INFO] +- org.jboss.as:jboss-as-controller:jar:7.2.0.Final:compile
> > [INFO] | +- org.jboss.modules:jboss-modules:jar:1.2.0.CR1:compile
> > [INFO] | +- org.jboss.msc:jboss-msc:jar:1.0.4.GA:compile
> > [INFO] | \- org.jboss:staxmapper:jar:1.1.0.Final:compile
> > 
> > 
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 



From hbraun at redhat.com  Mon Nov  3 13:01:11 2014
From: hbraun at redhat.com (Heiko Braun)
Date: Mon, 3 Nov 2014 19:01:11 +0100
Subject: [wildfly-dev] Map / reduce for management operations
In-Reply-To: <5453DD67.9040304@redhat.com>
References: <86CCB216-7726-4C75-9431-606DD4665CCF@redhat.com>
	<5453C1D8.4080202@redhat.com>
	<70C6B73B-C9E3-470C-9465-44E0E662E2E2@redhat.com>
	<5453DD67.9040304@redhat.com>
Message-ID: <D0090FDE-BA03-41A4-A3AE-EAB4D9549C12@redhat.com>


Ok, let's discuss it further. Maybe on irc. I dont fully understand your use case, but if you explain it further i am confident we can contribute to it. 

> Am 31.10.2014 um 20:05 schrieb Brian Stansberry <brian.stansberry at redhat.com>:
> 
>> On 10/31/14, 1:30 PM, Heiko Braun wrote:
>> 
>>> On 31 Oct 2014, at 18:07, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>> 
>>> This would definitely be useful.
>>> 
>>> On the server side we already support a wildcard variant of
>>> read-resource. But it only works within a single process, not across
>>> processes in the domain. We've never had time to sort that issue. I'd
>>> like to see this feature built on a foundation of a proper cross-domain
>>> wildcard read-resource. That will kill two birds with one stone, plus
>>> ensure consistent behavior.
>> 
>> glad to hear. we specifically isolated it from the current codebase to explore the ideas, before merging with existing approaches. Bringing it into the main codebase would be a task for somebody with a better understanding of the management layer internals.
> 
> Oh. I can't commit to when we'd be able to do multi-process wildcard read-resource. I was fired up by the possibility that a talented guy like Harald was interested. :) This thread certainly raises the visibility of it though. I'll be thinking about how to do it.
> 
>> 
>>> 
>>> Any other ideas for a name for this? "Map / reduce" to me implies a much
>>> broader set of functionality, and I wouldn't want to falsely advertise,
>>> nor burn an operation name that we may want later.
>> 
>> the name describes quiet well what's actually happening behind the scenes, but I agree that "map/reduce" is quiet overloaded these days and might lead to false expectations.
>> 
>>> That also relates to
>>> Stan's point in his response, re: this being an element in a broader
>>> query feature. If it has a precise name that implies a narrow scope, if
>>> later on there is a broader feature that broader feature can co-exist
>>> with its ancestor.
>>> 
>>>> On 10/31/14, 10:35 AM, Harald Pehl wrote:
>>>> TL;DR
>>>> 
>>>> For management clients it is tedious and awkward to read resources /
>>>> attributes in big domains (e.g. return the state of all running servers
>>>> across all hosts which are part of server group "foo"). Today this
>>>> requires to setup multiple composite operations *on the client* which
>>>> need to be executed in a specific order. This proposal suggests a new
>>>> operation which collects all relevant information *on the
>>>> server* and returns only the relevant data in one go to the client.
>>>> 
>>>> --------------------
>>>> 
>>>> # Background:
>>>> 
>>>> In the admin console we often need to read specific attributes across a
>>>> domain or across a deeply nested resource:
>>>> 
>>>> - List all enabled data sources of the current profile
>>>> - Show the port offset of all running servers across all hosts
>>>> - Get all users which belong to role Operator
>>>> 
>>>> Even for small domains with two server groups and a small number of
>>>> servers this procedure is awkward and error prone. What makes it even
>>>> more difficult is the asynchronous nature of the admin console. Soon you
>>>> end up in a deeply nested callback-hell. Besides that these 'queries'
>>>> lead to poor performance for big domains with tens of groups, hosts and
>>>> servers.
>>>> 
>>>> # Proposal / Prototype
>>>> 
>>>> The GitHub repository at [1] contains a more detailed description of the
>>>> problem statement and a working prototype. This includes details such as
>>>> how to address the requested resources, how the information is retrieved
>>>> and how to handle errors.
>>>> 
>>>> The proposal also includes a way to filter and reduce the resources
>>>> against a list of attributes and values *before* the response is sent to
>>>> the client.
>>>> 
>>>> [1] https://github.com/hpehl/map-reduce
>>>> 
>>>> ---
>>>> Harald Pehl
>>>> JBoss by Red Hat
>>>> http://hpehl.info
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> 
>>> 
>>> --
>>> Brian Stansberry
>>> Senior Principal Software Engineer
>>> JBoss by Red Hat
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> 
> -- 
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat


From brian.stansberry at redhat.com  Mon Nov  3 13:25:26 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 03 Nov 2014 12:25:26 -0600
Subject: [wildfly-dev] Map / reduce for management operations
In-Reply-To: <D0090FDE-BA03-41A4-A3AE-EAB4D9549C12@redhat.com>
References: <86CCB216-7726-4C75-9431-606DD4665CCF@redhat.com>
	<5453C1D8.4080202@redhat.com>
	<70C6B73B-C9E3-470C-9465-44E0E662E2E2@redhat.com>
	<5453DD67.9040304@redhat.com>
	<D0090FDE-BA03-41A4-A3AE-EAB4D9549C12@redhat.com>
Message-ID: <5457C896.80904@redhat.com>

Great. Chatting on IRC will be fine. We should involve Emanuel 
Muckenhuber, as he did the single-process wildcard read support we have, 
and he likely remembers best the hassles in doing it across processes.

The use case is basically the same one Harald has -- trying to get a 
bunch of data in one request. Harald goes further by filtering out 
addresses and/or attributes, but it all starts with sucking in lots of data.

On 11/3/14, 12:01 PM, Heiko Braun wrote:
>
> Ok, let's discuss it further. Maybe on irc. I dont fully understand your use case, but if you explain it further i am confident we can contribute to it.
>
>> Am 31.10.2014 um 20:05 schrieb Brian Stansberry <brian.stansberry at redhat.com>:
>>
>>> On 10/31/14, 1:30 PM, Heiko Braun wrote:
>>>
>>>> On 31 Oct 2014, at 18:07, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>>>
>>>> This would definitely be useful.
>>>>
>>>> On the server side we already support a wildcard variant of
>>>> read-resource. But it only works within a single process, not across
>>>> processes in the domain. We've never had time to sort that issue. I'd
>>>> like to see this feature built on a foundation of a proper cross-domain
>>>> wildcard read-resource. That will kill two birds with one stone, plus
>>>> ensure consistent behavior.
>>>
>>> glad to hear. we specifically isolated it from the current codebase to explore the ideas, before merging with existing approaches. Bringing it into the main codebase would be a task for somebody with a better understanding of the management layer internals.
>>
>> Oh. I can't commit to when we'd be able to do multi-process wildcard read-resource. I was fired up by the possibility that a talented guy like Harald was interested. :) This thread certainly raises the visibility of it though. I'll be thinking about how to do it.
>>
>>>
>>>>
>>>> Any other ideas for a name for this? "Map / reduce" to me implies a much
>>>> broader set of functionality, and I wouldn't want to falsely advertise,
>>>> nor burn an operation name that we may want later.
>>>
>>> the name describes quiet well what's actually happening behind the scenes, but I agree that "map/reduce" is quiet overloaded these days and might lead to false expectations.
>>>
>>>> That also relates to
>>>> Stan's point in his response, re: this being an element in a broader
>>>> query feature. If it has a precise name that implies a narrow scope, if
>>>> later on there is a broader feature that broader feature can co-exist
>>>> with its ancestor.
>>>>
>>>>> On 10/31/14, 10:35 AM, Harald Pehl wrote:
>>>>> TL;DR
>>>>>
>>>>> For management clients it is tedious and awkward to read resources /
>>>>> attributes in big domains (e.g. return the state of all running servers
>>>>> across all hosts which are part of server group "foo"). Today this
>>>>> requires to setup multiple composite operations *on the client* which
>>>>> need to be executed in a specific order. This proposal suggests a new
>>>>> operation which collects all relevant information *on the
>>>>> server* and returns only the relevant data in one go to the client.
>>>>>
>>>>> --------------------
>>>>>
>>>>> # Background:
>>>>>
>>>>> In the admin console we often need to read specific attributes across a
>>>>> domain or across a deeply nested resource:
>>>>>
>>>>> - List all enabled data sources of the current profile
>>>>> - Show the port offset of all running servers across all hosts
>>>>> - Get all users which belong to role Operator
>>>>>
>>>>> Even for small domains with two server groups and a small number of
>>>>> servers this procedure is awkward and error prone. What makes it even
>>>>> more difficult is the asynchronous nature of the admin console. Soon you
>>>>> end up in a deeply nested callback-hell. Besides that these 'queries'
>>>>> lead to poor performance for big domains with tens of groups, hosts and
>>>>> servers.
>>>>>
>>>>> # Proposal / Prototype
>>>>>
>>>>> The GitHub repository at [1] contains a more detailed description of the
>>>>> problem statement and a working prototype. This includes details such as
>>>>> how to address the requested resources, how the information is retrieved
>>>>> and how to handle errors.
>>>>>
>>>>> The proposal also includes a way to filter and reduce the resources
>>>>> against a list of attributes and values *before* the response is sent to
>>>>> the client.
>>>>>
>>>>> [1] https://github.com/hpehl/map-reduce
>>>>>
>>>>> ---
>>>>> Harald Pehl
>>>>> JBoss by Red Hat
>>>>> http://hpehl.info
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>>
>>>> --
>>>> Brian Stansberry
>>>> Senior Principal Software Engineer
>>>> JBoss by Red Hat
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>> --
>> Brian Stansberry
>> Senior Principal Software Engineer
>> JBoss by Red Hat


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

From rory.odonnell at oracle.com  Mon Nov  3 14:31:12 2014
From: rory.odonnell at oracle.com (Rory O'Donnell Oracle, Dublin Ireland)
Date: Mon, 03 Nov 2014 19:31:12 +0000
Subject: [wildfly-dev] JDK 9 Early Access with Project Jigsaw build b36 is
 available on java.net
Message-ID: <5457D800.5070903@oracle.com>


Hi Jason/Tomaz,

JDK 9 Early Access with Project Jigsaw build b36 is available on 
java.net [1]

The goal of Project Jigsaw [2] is to design and implement a standard 
module system for the Java SE Platform,
and to apply that system to the Platform itself and to the JDK.

As described in JEP 220 [3], this build provides a new runtime image 
structure. For example, this new runtime
image does not install an rt.jar file or a tools.jar file.

Please refer to Project Jigsaw's updated project pages [2] & [4] and 
Mark Reinhold's announcement email [5]
for further details.

We are very interested in your experiences testing this build. Comments, 
questions, and suggestions are
welcome on the jigsaw-dev mailing list or else submit bug reports via 
bugs.java.com.

Note: If you haven?t already subscribed to that mailing list then please 
do so first, otherwise
your message will be discarded as spam.


[1] https://jdk9.java.net/jigsaw/
[2] http://openjdk.java.net/projects/jigsaw/
[3] http://openjdk.java.net/jeps/220
[4] http://openjdk.java.net/projects/jigsaw/ea
[5] 
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2014-November/003878.html

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland


From arjan.tijms at gmail.com  Mon Nov  3 17:39:08 2014
From: arjan.tijms at gmail.com (arjan tijms)
Date: Mon, 3 Nov 2014 23:39:08 +0100
Subject: [wildfly-dev] Announcing wildfly extension installer maven
	plugin
In-Reply-To: <817982016.4058714.1415010183628.JavaMail.zimbra@redhat.com>
References: <476743654.4040778.1415008177214.JavaMail.zimbra@redhat.com>
	<817982016.4058714.1415010183628.JavaMail.zimbra@redhat.com>
Message-ID: <CAE=-AhDVdiMEH=4szZOrQT_Bf-y-9yGZw-gSQg+6GtmXYwCaVw@mail.gmail.com>

On Mon, Nov 3, 2014 at 11:23 AM, Libor Zoubek <lzoubek at redhat.com> wrote:
> I'm happy to announce maven plugin capable of installing JBoss module to WildFly.
>
> It provides helpful mojo to:
>  - lay down JBoss module
>  - register extension
>  - setup subsystem
>  - setup socket binding
>
> It may become useful for developing/testing WildFly subsystems.

I looks nice! Would it make sense to have this as an Arquillian feature as well?

Kind regards,
Arjan Tijms

From brian.stansberry at redhat.com  Mon Nov  3 21:21:23 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 03 Nov 2014 20:21:23 -0600
Subject: [wildfly-dev] WildFly Core 1.0.0.Alpha11 Released
Message-ID: <54583823.4010704@redhat.com>

I've released WildFly Core 1.0.0.Alpha11 and integrated it into the 
master branch of full WildFly.

We'll shoot to get back on the weekly release cadence previously 
discussed on this list.

Cheers,

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

From jason.greene at redhat.com  Mon Nov  3 22:08:06 2014
From: jason.greene at redhat.com (Jason T. Greene)
Date: Mon, 3 Nov 2014 22:08:06 -0500 (EST)
Subject: [wildfly-dev] Is there a chance to sync org.jboss:staxmapper to
	Maven Central?
In-Reply-To: <5457B92B.4050404@redhat.com>
References: <1415033374.2266.13.camel@kpiwko-x220>
	<5457B92B.4050404@redhat.com>
Message-ID: <7BF47F10-0961-40E0-B32B-2D418F30EDC2@redhat.com>

I thought that org.jboss.* was synced?

Sent from my iPhone

> On Nov 3, 2014, at 11:19 AM, James R. Perkins <jperkins at redhat.com> wrote:
> 
> Odd that it hasn't been updated, but it's not on the list 
> https://developer.jboss.org/wiki/MavenRepositoryCentralSynchronization. 
> Anyway yes I can handle that if no one else is at this point.
> 
> We should probably gather a list of other projects that need a sync as 
> well to ensure we're getting them all.
> 
>> On 11/03/2014 08:49 AM, Karel Piwko wrote:
>> Hi All,
>> 
>> it looks like that some of the dependencies are missing in Maven Central
>> [1]. This does not matter if using Maven to resolve artifacts but fails
>> with Gradle that is ignoring <repository> element in pom.xml files.
>> 
>> Any chance that org.jboss:staxmapper:jar:1.1.0.Final can be synced to
>> Maven Central? Or its newer version?
>> 
>> https://repository.jboss.org/nexus/service/local/repositories/releases/content/org/jboss/staxmapper/1.1.0.Final/staxmapper-1.1.0.Final.pom
>> 
>> Thanks,
>> 
>> Karel
>> 
>> [1]
>> [INFO] +- org.jboss.as:jboss-as-controller:jar:7.2.0.Final:compile
>> [INFO] | +- org.jboss.modules:jboss-modules:jar:1.2.0.CR1:compile
>> [INFO] | +- org.jboss.msc:jboss-msc:jar:1.0.4.GA:compile
>> [INFO] | \- org.jboss:staxmapper:jar:1.1.0.Final:compile
>> 
>> 
>> _______________________________________________
>> 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 kpiwko at redhat.com  Tue Nov  4 07:52:17 2014
From: kpiwko at redhat.com (Karel Piwko)
Date: Tue, 04 Nov 2014 13:52:17 +0100
Subject: [wildfly-dev] Is there a chance to sync org.jboss:staxmapper to
 Maven Central?
In-Reply-To: <5457B92B.4050404@redhat.com>
References: <1415033374.2266.13.camel@kpiwko-x220>
	<5457B92B.4050404@redhat.com>
Message-ID: <1415105537.2266.27.camel@kpiwko-x220>

On Mon, 2014-11-03 at 09:19 -0800, James R. Perkins wrote:
> Odd that it hasn't been updated, but it's not on the list 
> https://developer.jboss.org/wiki/MavenRepositoryCentralSynchronization. 
> Anyway yes I can handle that if no one else is at this point.
> 
> We should probably gather a list of other projects that need a sync as 
> well to ensure we're getting them all.

These artifacts (48) are missing in Maven Central in 7.2.0 tag:
https://gist.github.com/kpiwko/b96abdb8a13586b63a7d

(Some of them will not be applicable for sync (e.g. system scoped deps)
and some of them have been synced in later versions (e.g. byteman)
already)

Using https://github.com/kpiwko/maven-central-dependency-checker



> 
> On 11/03/2014 08:49 AM, Karel Piwko wrote:
> > Hi All,
> >
> > it looks like that some of the dependencies are missing in Maven Central
> > [1]. This does not matter if using Maven to resolve artifacts but fails
> > with Gradle that is ignoring <repository> element in pom.xml files.
> >
> > Any chance that org.jboss:staxmapper:jar:1.1.0.Final can be synced to
> > Maven Central? Or its newer version?
> >
> > https://repository.jboss.org/nexus/service/local/repositories/releases/content/org/jboss/staxmapper/1.1.0.Final/staxmapper-1.1.0.Final.pom
> >
> > Thanks,
> >
> > Karel
> >
> > [1]
> > [INFO] +- org.jboss.as:jboss-as-controller:jar:7.2.0.Final:compile
> > [INFO] | +- org.jboss.modules:jboss-modules:jar:1.2.0.CR1:compile
> > [INFO] | +- org.jboss.msc:jboss-msc:jar:1.0.4.GA:compile
> > [INFO] | \- org.jboss:staxmapper:jar:1.1.0.Final:compile
> >
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 



From tomaz.cerar at gmail.com  Tue Nov  4 08:02:49 2014
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Tue, 4 Nov 2014 14:02:49 +0100
Subject: [wildfly-dev] Is there a chance to sync org.jboss:staxmapper to
 Maven Central?
In-Reply-To: <1415105537.2266.27.camel@kpiwko-x220>
References: <1415033374.2266.13.camel@kpiwko-x220>
	<5457B92B.4050404@redhat.com>
	<1415105537.2266.27.camel@kpiwko-x220>
Message-ID: <CAMquZP7ibk6A+b3-jBbamJqiWXg7N5=E3Z3dDx9n4tUPyZ6knA@mail.gmail.com>

Can you chack for deps for WildFly 8.1 / 9.0.0.Alpha1

as I think should make sure that we have deps for our current releases
properly synced.

On Tue, Nov 4, 2014 at 1:52 PM, Karel Piwko <kpiwko at redhat.com> wrote:

> On Mon, 2014-11-03 at 09:19 -0800, James R. Perkins wrote:
> > Odd that it hasn't been updated, but it's not on the list
> > https://developer.jboss.org/wiki/MavenRepositoryCentralSynchronization.
> > Anyway yes I can handle that if no one else is at this point.
> >
> > We should probably gather a list of other projects that need a sync as
> > well to ensure we're getting them all.
>
> These artifacts (48) are missing in Maven Central in 7.2.0 tag:
> https://gist.github.com/kpiwko/b96abdb8a13586b63a7d
>
> (Some of them will not be applicable for sync (e.g. system scoped deps)
> and some of them have been synced in later versions (e.g. byteman)
> already)
>
> Using https://github.com/kpiwko/maven-central-dependency-checker
>
>
>
> >
> > On 11/03/2014 08:49 AM, Karel Piwko wrote:
> > > Hi All,
> > >
> > > it looks like that some of the dependencies are missing in Maven
> Central
> > > [1]. This does not matter if using Maven to resolve artifacts but fails
> > > with Gradle that is ignoring <repository> element in pom.xml files.
> > >
> > > Any chance that org.jboss:staxmapper:jar:1.1.0.Final can be synced to
> > > Maven Central? Or its newer version?
> > >
> > >
> https://repository.jboss.org/nexus/service/local/repositories/releases/content/org/jboss/staxmapper/1.1.0.Final/staxmapper-1.1.0.Final.pom
> > >
> > > Thanks,
> > >
> > > Karel
> > >
> > > [1]
> > > [INFO] +- org.jboss.as:jboss-as-controller:jar:7.2.0.Final:compile
> > > [INFO] | +- org.jboss.modules:jboss-modules:jar:1.2.0.CR1:compile
> > > [INFO] | +- org.jboss.msc:jboss-msc:jar:1.0.4.GA:compile
> > > [INFO] | \- org.jboss:staxmapper:jar:1.1.0.Final:compile
> > >
> > >
> > > _______________________________________________
> > > 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/20141104/3731f4fa/attachment.html 

From kpiwko at redhat.com  Tue Nov  4 08:58:44 2014
From: kpiwko at redhat.com (Karel Piwko)
Date: Tue, 04 Nov 2014 14:58:44 +0100
Subject: [wildfly-dev] Is there a chance to sync org.jboss:staxmapper to
 Maven Central?
In-Reply-To: <CAMquZP7ibk6A+b3-jBbamJqiWXg7N5=E3Z3dDx9n4tUPyZ6knA@mail.gmail.com>
References: <1415033374.2266.13.camel@kpiwko-x220>
	<5457B92B.4050404@redhat.com> <1415105537.2266.27.camel@kpiwko-x220>
	<CAMquZP7ibk6A+b3-jBbamJqiWXg7N5=E3Z3dDx9n4tUPyZ6knA@mail.gmail.com>
Message-ID: <1415109524.2266.29.camel@kpiwko-x220>

This is for WildFly 8.1.0.Final tag (57 deps missing):
https://gist.github.com/kpiwko/654fe9b1b4653e9e5877

I've updated instructions about getting mvn dependency:tree output for
the analysis:
https://github.com/kpiwko/maven-central-dependency-checker#usage . Now
you should be able to run check against any tag or any project you want.

Karel

On Tue, 2014-11-04 at 14:02 +0100, Toma? Cerar wrote:
> Can you chack for deps for WildFly 8.1 / 9.0.0.Alpha1
> 
> as I think should make sure that we have deps for our current releases
> properly synced.
> 
> On Tue, Nov 4, 2014 at 1:52 PM, Karel Piwko <kpiwko at redhat.com> wrote:
> 
> > On Mon, 2014-11-03 at 09:19 -0800, James R. Perkins wrote:
> > > Odd that it hasn't been updated, but it's not on the list
> > > https://developer.jboss.org/wiki/MavenRepositoryCentralSynchronization.
> > > Anyway yes I can handle that if no one else is at this point.
> > >
> > > We should probably gather a list of other projects that need a sync as
> > > well to ensure we're getting them all.
> >
> > These artifacts (48) are missing in Maven Central in 7.2.0 tag:
> > https://gist.github.com/kpiwko/b96abdb8a13586b63a7d
> >
> > (Some of them will not be applicable for sync (e.g. system scoped deps)
> > and some of them have been synced in later versions (e.g. byteman)
> > already)
> >
> > Using https://github.com/kpiwko/maven-central-dependency-checker
> >
> >
> >
> > >
> > > On 11/03/2014 08:49 AM, Karel Piwko wrote:
> > > > Hi All,
> > > >
> > > > it looks like that some of the dependencies are missing in Maven
> > Central
> > > > [1]. This does not matter if using Maven to resolve artifacts but fails
> > > > with Gradle that is ignoring <repository> element in pom.xml files.
> > > >
> > > > Any chance that org.jboss:staxmapper:jar:1.1.0.Final can be synced to
> > > > Maven Central? Or its newer version?
> > > >
> > > >
> > https://repository.jboss.org/nexus/service/local/repositories/releases/content/org/jboss/staxmapper/1.1.0.Final/staxmapper-1.1.0.Final.pom
> > > >
> > > > Thanks,
> > > >
> > > > Karel
> > > >
> > > > [1]
> > > > [INFO] +- org.jboss.as:jboss-as-controller:jar:7.2.0.Final:compile
> > > > [INFO] | +- org.jboss.modules:jboss-modules:jar:1.2.0.CR1:compile
> > > > [INFO] | +- org.jboss.msc:jboss-msc:jar:1.0.4.GA:compile
> > > > [INFO] | \- org.jboss:staxmapper:jar:1.1.0.Final:compile
> > > >
> > > >
> > > > _______________________________________________
> > > > 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 jperkins at redhat.com  Tue Nov  4 11:38:52 2014
From: jperkins at redhat.com (James R. Perkins)
Date: Tue, 04 Nov 2014 08:38:52 -0800
Subject: [wildfly-dev] Is there a chance to sync org.jboss:staxmapper to
 Maven Central?
In-Reply-To: <7BF47F10-0961-40E0-B32B-2D418F30EDC2@redhat.com>
References: <1415033374.2266.13.camel@kpiwko-x220>
	<5457B92B.4050404@redhat.com>
	<7BF47F10-0961-40E0-B32B-2D418F30EDC2@redhat.com>
Message-ID: <5459011C.7000709@redhat.com>

I don't think so, but I could be wrong. I know we have org.wildfly.* 
being synced though.

On 11/03/2014 07:08 PM, Jason T. Greene wrote:
> I thought that org.jboss.* was synced?
>
> Sent from my iPhone
>
>> On Nov 3, 2014, at 11:19 AM, James R. Perkins <jperkins at redhat.com> wrote:
>>
>> Odd that it hasn't been updated, but it's not on the list
>> https://developer.jboss.org/wiki/MavenRepositoryCentralSynchronization.
>> Anyway yes I can handle that if no one else is at this point.
>>
>> We should probably gather a list of other projects that need a sync as
>> well to ensure we're getting them all.
>>
>>> On 11/03/2014 08:49 AM, Karel Piwko wrote:
>>> Hi All,
>>>
>>> it looks like that some of the dependencies are missing in Maven Central
>>> [1]. This does not matter if using Maven to resolve artifacts but fails
>>> with Gradle that is ignoring <repository> element in pom.xml files.
>>>
>>> Any chance that org.jboss:staxmapper:jar:1.1.0.Final can be synced to
>>> Maven Central? Or its newer version?
>>>
>>> https://repository.jboss.org/nexus/service/local/repositories/releases/content/org/jboss/staxmapper/1.1.0.Final/staxmapper-1.1.0.Final.pom
>>>
>>> Thanks,
>>>
>>> Karel
>>>
>>> [1]
>>> [INFO] +- org.jboss.as:jboss-as-controller:jar:7.2.0.Final:compile
>>> [INFO] | +- org.jboss.modules:jboss-modules:jar:1.2.0.CR1:compile
>>> [INFO] | +- org.jboss.msc:jboss-msc:jar:1.0.4.GA:compile
>>> [INFO] | \- org.jboss:staxmapper:jar:1.1.0.Final:compile
>>>
>>>
>>> _______________________________________________
>>> 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

-- 
James R. Perkins
JBoss by Red Hat


From tomaz.cerar at gmail.com  Tue Nov  4 11:51:20 2014
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Tue, 4 Nov 2014 17:51:20 +0100
Subject: [wildfly-dev] Is there a chance to sync org.jboss:staxmapper to
 Maven Central?
In-Reply-To: <1415109524.2266.29.camel@kpiwko-x220>
References: <1415033374.2266.13.camel@kpiwko-x220>
	<5457B92B.4050404@redhat.com>
	<1415105537.2266.27.camel@kpiwko-x220>
	<CAMquZP7ibk6A+b3-jBbamJqiWXg7N5=E3Z3dDx9n4tUPyZ6knA@mail.gmail.com>
	<1415109524.2266.29.camel@kpiwko-x220>
Message-ID: <CAMquZP7Jb-g+189_vNmqDP0g3AAJwi5+kXVHMjS3KcjoyF8uTg@mail.gmail.com>

some of that stuff comes in as test only dependencies.
where we have code to test compatibility with previously released versions
of wildfly/AS7

at least that is why you can see duplicated entries with different versions

On Tue, Nov 4, 2014 at 2:58 PM, Karel Piwko <kpiwko at redhat.com> wrote:

> This is for WildFly 8.1.0.Final tag (57 deps missing):
> https://gist.github.com/kpiwko/654fe9b1b4653e9e5877
>
> I've updated instructions about getting mvn dependency:tree output for
> the analysis:
> https://github.com/kpiwko/maven-central-dependency-checker#usage . Now
> you should be able to run check against any tag or any project you want.
>
> Karel
>
> On Tue, 2014-11-04 at 14:02 +0100, Toma? Cerar wrote:
> > Can you chack for deps for WildFly 8.1 / 9.0.0.Alpha1
> >
> > as I think should make sure that we have deps for our current releases
> > properly synced.
> >
> > On Tue, Nov 4, 2014 at 1:52 PM, Karel Piwko <kpiwko at redhat.com> wrote:
> >
> > > On Mon, 2014-11-03 at 09:19 -0800, James R. Perkins wrote:
> > > > Odd that it hasn't been updated, but it's not on the list
> > > >
> https://developer.jboss.org/wiki/MavenRepositoryCentralSynchronization.
> > > > Anyway yes I can handle that if no one else is at this point.
> > > >
> > > > We should probably gather a list of other projects that need a sync
> as
> > > > well to ensure we're getting them all.
> > >
> > > These artifacts (48) are missing in Maven Central in 7.2.0 tag:
> > > https://gist.github.com/kpiwko/b96abdb8a13586b63a7d
> > >
> > > (Some of them will not be applicable for sync (e.g. system scoped deps)
> > > and some of them have been synced in later versions (e.g. byteman)
> > > already)
> > >
> > > Using https://github.com/kpiwko/maven-central-dependency-checker
> > >
> > >
> > >
> > > >
> > > > On 11/03/2014 08:49 AM, Karel Piwko wrote:
> > > > > Hi All,
> > > > >
> > > > > it looks like that some of the dependencies are missing in Maven
> > > Central
> > > > > [1]. This does not matter if using Maven to resolve artifacts but
> fails
> > > > > with Gradle that is ignoring <repository> element in pom.xml files.
> > > > >
> > > > > Any chance that org.jboss:staxmapper:jar:1.1.0.Final can be synced
> to
> > > > > Maven Central? Or its newer version?
> > > > >
> > > > >
> > >
> https://repository.jboss.org/nexus/service/local/repositories/releases/content/org/jboss/staxmapper/1.1.0.Final/staxmapper-1.1.0.Final.pom
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Karel
> > > > >
> > > > > [1]
> > > > > [INFO] +- org.jboss.as:jboss-as-controller:jar:7.2.0.Final:compile
> > > > > [INFO] | +- org.jboss.modules:jboss-modules:jar:1.2.0.CR1:compile
> > > > > [INFO] | +- org.jboss.msc:jboss-msc:jar:1.0.4.GA:compile
> > > > > [INFO] | \- org.jboss:staxmapper:jar:1.1.0.Final:compile
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > 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/20141104/e201daec/attachment-0001.html 

From pbenedict at apache.org  Tue Nov  4 22:53:00 2014
From: pbenedict at apache.org (Paul Benedict)
Date: Tue, 4 Nov 2014 21:53:00 -0600
Subject: [wildfly-dev] Potential error in jboss-web_8_0.xsd
Message-ID: <CABLGb9wADsigbYZtPCsFshBDi=7R+n-GdREAcfOJ7joxfvNGGQ@mail.gmail.com>

I think there's an error in this XSD [1] which prevents me from using the
"javaee"  elements you intend to import.

First, the "javaee" namespace is declared as "
http://xmlns.jcp.org/xml/ns/javaee" in the XML header, but then
(surprisingly) the <xsd:import> uses another namepace:

<xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation=
"web-app_3_1.xsd"/>

I'm pretty confident this is wrong. It's importing under the old Java EE
namespace -- not the new one which the header correctly declares. Hence,
consumers are unable to get the "javaee" elements.

Please confirm.

[1]
https://github.com/jboss/metadata/blob/master/web/src/main/resources/schema/jboss-web_8_0.xsd

Cheers,
Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141104/4df50229/attachment.html 

From hbraun at redhat.com  Wed Nov  5 08:38:28 2014
From: hbraun at redhat.com (Heiko Braun)
Date: Wed, 5 Nov 2014 14:38:28 +0100
Subject: [wildfly-dev] Monitoring wildfly using Influx
Message-ID: <69107B29-1ADD-488E-A808-C23AB8DB02A8@redhat.com>


I've created a quick walkthrough how to configure and use the #rhq monitoring subsystem and #influxdb to monitor wildfly instances:

https://github.com/rhq-project/wildfly-monitor/wiki/InfluxDB

This is the first cut, still in it's early stages, but provides an end-to-end demonstration how to offload monitoring data into InfluxDB and access it through a web interface or a command line utility.

Regards, Heiko

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

From brian.stansberry at redhat.com  Wed Nov  5 12:35:25 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 05 Nov 2014 11:35:25 -0600
Subject: [wildfly-dev] Monitoring wildfly using Influx
In-Reply-To: <69107B29-1ADD-488E-A808-C23AB8DB02A8@redhat.com>
References: <69107B29-1ADD-488E-A808-C23AB8DB02A8@redhat.com>
Message-ID: <545A5FDD.5060907@redhat.com>

Cool. Thanks!

On that doc I recommend expanding the "Subsystem Configuration" xml 
snippet a bit to show a simple server-monitor. Show a tiny bit on how 
the desired metrics are specified.

On 11/5/14, 7:38 AM, Heiko Braun wrote:
>
> I've created a quick walkthrough how to configure and use the #rhq
> monitoring subsystem and #influxdb to monitor wildfly instances:
>
> https://github.com/rhq-project/wildfly-monitor/wiki/InfluxDB
>
> This is the first cut, still in it's early stages, but provides an
> end-to-end demonstration how to offload monitoring data into InfluxDB
> and access it through a web interface or a command line utility.
>
> Regards, Heiko
>
>
>
> _______________________________________________
> 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 hbraun at redhat.com  Wed Nov  5 14:08:36 2014
From: hbraun at redhat.com (Heiko Braun)
Date: Wed, 5 Nov 2014 20:08:36 +0100
Subject: [wildfly-dev] Monitoring wildfly using Influx
In-Reply-To: <545A5FDD.5060907@redhat.com>
References: <69107B29-1ADD-488E-A808-C23AB8DB02A8@redhat.com>
	<545A5FDD.5060907@redhat.com>
Message-ID: <1A9994D2-1476-4DA0-A725-AC4DBD51FACF@redhat.com>

Ok, good point. I thought that the general readme for the subsystem covers it. I'll add a complete configuration, like this one: https://github.com/rhq-project/wildfly-monitor/blob/master/src/main/resources/subsystem.xml

Not sure if that came through: this is just the influx example. Alternatively you can run use with the new RHQ storage. Some docs will follow ...

> Am 05.11.2014 um 18:35 schrieb Brian Stansberry <brian.stansberry at redhat.com>:
> 
> Cool. Thanks!
> 
> On that doc I recommend expanding the "Subsystem Configuration" xml 
> snippet a bit to show a simple server-monitor. Show a tiny bit on how 
> the desired metrics are specified.
> 
>> On 11/5/14, 7:38 AM, Heiko Braun wrote:
>> 
>> I've created a quick walkthrough how to configure and use the #rhq
>> monitoring subsystem and #influxdb to monitor wildfly instances:
>> 
>> https://github.com/rhq-project/wildfly-monitor/wiki/InfluxDB
>> 
>> This is the first cut, still in it's early stages, but provides an
>> end-to-end demonstration how to offload monitoring data into InfluxDB
>> and access it through a web interface or a command line utility.
>> 
>> Regards, Heiko
>> 
>> 
>> 
>> _______________________________________________
>> 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


From claudio at claudius.com.br  Wed Nov  5 21:30:46 2014
From: claudio at claudius.com.br (Claudio Miranda)
Date: Thu, 6 Nov 2014 00:30:46 -0200
Subject: [wildfly-dev] duplicate resource on deploying
Message-ID: <CALbD--r0C7U_xmSwAWYhD4NyMH+U_FCisH-=hOC55GBuFafO7A@mail.gmail.com>

Hi, on latest wildfly, any resource jar in deployments directory
(standalone) is added to domain.xml and data/content directory.
Restart wildfly it throws duplicate resource exception because the
same resource is in deployments directory and deployment list of
standalone.xml

This was not the previous behavior, is it intended to be this way ?

-- 
  Claudio Miranda

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

From brian.stansberry at redhat.com  Wed Nov  5 21:48:29 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 05 Nov 2014 20:48:29 -0600
Subject: [wildfly-dev] duplicate resource on deploying
In-Reply-To: <CALbD--r0C7U_xmSwAWYhD4NyMH+U_FCisH-=hOC55GBuFafO7A@mail.gmail.com>
References: <CALbD--r0C7U_xmSwAWYhD4NyMH+U_FCisH-=hOC55GBuFafO7A@mail.gmail.com>
Message-ID: <545AE17D.2050806@redhat.com>

On 11/5/14, 8:30 PM, Claudio Miranda wrote:
> Hi, on latest wildfly, any resource jar in deployments directory
> (standalone) is added to domain.xml and data/content directory.
> Restart wildfly it throws duplicate resource exception because the
> same resource is in deployments directory and deployment list of
> standalone.xml
>
> This was not the previous behavior, is it intended to be this way ?
>

It's intended to be in data/content but should not end up in standalone.xml.

For me it doesn't appear in standalone.xml, at least not with a build 
fairly close to current master.

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

From brian.stansberry at redhat.com  Wed Nov  5 22:04:15 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 05 Nov 2014 21:04:15 -0600
Subject: [wildfly-dev] duplicate resource on deploying
In-Reply-To: <545AE17D.2050806@redhat.com>
References: <CALbD--r0C7U_xmSwAWYhD4NyMH+U_FCisH-=hOC55GBuFafO7A@mail.gmail.com>
	<545AE17D.2050806@redhat.com>
Message-ID: <545AE52F.3060107@redhat.com>

On 11/5/14, 8:48 PM, Brian Stansberry wrote:
> On 11/5/14, 8:30 PM, Claudio Miranda wrote:
>> Hi, on latest wildfly, any resource jar in deployments directory
>> (standalone) is added to domain.xml and data/content directory.
>> Restart wildfly it throws duplicate resource exception because the
>> same resource is in deployments directory and deployment list of
>> standalone.xml
>>
>> This was not the previous behavior, is it intended to be this way ?
>>
>
> It's intended to be in data/content but should not end up in standalone.xml.
>
> For me it doesn't appear in standalone.xml, at least not with a build
> fairly close to current master.
>

Sorry; I'm blind. It's there.

https://issues.jboss.org/browse/WFCORE-221

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

From claudio at claudius.com.br  Wed Nov  5 22:20:54 2014
From: claudio at claudius.com.br (Claudio Miranda)
Date: Thu, 6 Nov 2014 01:20:54 -0200
Subject: [wildfly-dev] duplicate resource on deploying
In-Reply-To: <545AE17D.2050806@redhat.com>
References: <CALbD--r0C7U_xmSwAWYhD4NyMH+U_FCisH-=hOC55GBuFafO7A@mail.gmail.com>
	<545AE17D.2050806@redhat.com>
Message-ID: <CALbD--q90sp=JH9DF8ke6tzqvg7aF=52zcfP3P2hn+pbaUyBvg@mail.gmail.com>

On Thu, Nov 6, 2014 at 12:48 AM, Brian Stansberry
<brian.stansberry at redhat.com> wrote:
> It's intended to be in data/content but should not end up in standalone.xml.

Does the jar resources in deployments directory to be copied or moved
to data/content ?


-- 
  Claudio Miranda

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

From brian.stansberry at redhat.com  Wed Nov  5 22:54:52 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 05 Nov 2014 21:54:52 -0600
Subject: [wildfly-dev] duplicate resource on deploying
In-Reply-To: <CALbD--q90sp=JH9DF8ke6tzqvg7aF=52zcfP3P2hn+pbaUyBvg@mail.gmail.com>
References: <CALbD--r0C7U_xmSwAWYhD4NyMH+U_FCisH-=hOC55GBuFafO7A@mail.gmail.com>
	<545AE17D.2050806@redhat.com>
	<CALbD--q90sp=JH9DF8ke6tzqvg7aF=52zcfP3P2hn+pbaUyBvg@mail.gmail.com>
Message-ID: <545AF10C.9080202@redhat.com>

On 11/5/14, 9:20 PM, Claudio Miranda wrote:
> On Thu, Nov 6, 2014 at 12:48 AM, Brian Stansberry
> <brian.stansberry at redhat.com> wrote:
>> It's intended to be in data/content but should not end up in standalone.xml.
>
> Does the jar resources in deployments directory to be copied or moved
> to data/content ?
>

Copied.


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

From brian.stansberry at redhat.com  Wed Nov  5 23:06:34 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 05 Nov 2014 22:06:34 -0600
Subject: [wildfly-dev] duplicate resource on deploying
In-Reply-To: <545AE52F.3060107@redhat.com>
References: <CALbD--r0C7U_xmSwAWYhD4NyMH+U_FCisH-=hOC55GBuFafO7A@mail.gmail.com>	<545AE17D.2050806@redhat.com>
	<545AE52F.3060107@redhat.com>
Message-ID: <545AF3CA.9040305@redhat.com>

On 11/5/14, 9:04 PM, Brian Stansberry wrote:
> On 11/5/14, 8:48 PM, Brian Stansberry wrote:
>> On 11/5/14, 8:30 PM, Claudio Miranda wrote:
>>> Hi, on latest wildfly, any resource jar in deployments directory
>>> (standalone) is added to domain.xml and data/content directory.
>>> Restart wildfly it throws duplicate resource exception because the
>>> same resource is in deployments directory and deployment list of
>>> standalone.xml
>>>
>>> This was not the previous behavior, is it intended to be this way ?
>>>
>>
>> It's intended to be in data/content but should not end up in standalone.xml.
>>
>> For me it doesn't appear in standalone.xml, at least not with a build
>> fairly close to current master.
>>
>
> Sorry; I'm blind. It's there.
>
> https://issues.jboss.org/browse/WFCORE-221
>

This will be fixed in the Friday/Monday release of core.

https://github.com/wildfly/wildfly-core/pull/293

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

From hrupp at redhat.com  Thu Nov  6 04:30:38 2014
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Thu, 6 Nov 2014 10:30:38 +0100
Subject: [wildfly-dev] Monitoring wildfly using Influx
In-Reply-To: <1A9994D2-1476-4DA0-A725-AC4DBD51FACF@redhat.com>
References: <69107B29-1ADD-488E-A808-C23AB8DB02A8@redhat.com>
	<545A5FDD.5060907@redhat.com>
	<1A9994D2-1476-4DA0-A725-AC4DBD51FACF@redhat.com>
Message-ID: <DA632B7A-A367-4104-9325-C53AC15643A6@redhat.com>


> Am 05.11.2014 um 20:08 schrieb Heiko Braun <hbraun at redhat.com>:
> Not sure if that came through: this is just the influx example. Alternatively you can run use with the new RHQ storage. Some docs will follow ...

After Heiko put the ball in my court, I've played with it:

https://github.com/rhq-project/wildfly-monitor/wiki/RHQ-Metrics-backend

  Heiko



From hbraun at redhat.com  Thu Nov  6 04:39:00 2014
From: hbraun at redhat.com (Heiko Braun)
Date: Thu, 6 Nov 2014 10:39:00 +0100
Subject: [wildfly-dev] Monitoring wildfly using Influx
In-Reply-To: <DA632B7A-A367-4104-9325-C53AC15643A6@redhat.com>
References: <69107B29-1ADD-488E-A808-C23AB8DB02A8@redhat.com>
	<545A5FDD.5060907@redhat.com>
	<1A9994D2-1476-4DA0-A725-AC4DBD51FACF@redhat.com>
	<DA632B7A-A367-4104-9325-C53AC15643A6@redhat.com>
Message-ID: <BF3F2447-6D88-411A-9579-0EF8A7F38D28@redhat.com>

Great, thanks for the documentation. Maybe we should explain how to install it on an existing Wildfly instance? 


On 06 Nov 2014, at 10:30, Heiko W.Rupp <hrupp at redhat.com> wrote:

> 
>> Am 05.11.2014 um 20:08 schrieb Heiko Braun <hbraun at redhat.com>:
>> Not sure if that came through: this is just the influx example. Alternatively you can run use with the new RHQ storage. Some docs will follow ...
> 
> After Heiko put the ball in my court, I've played with it:
> 
> https://github.com/rhq-project/wildfly-monitor/wiki/RHQ-Metrics-backend
> 
>  Heiko
> 



From hbraun at redhat.com  Thu Nov  6 04:42:34 2014
From: hbraun at redhat.com (Heiko Braun)
Date: Thu, 6 Nov 2014 10:42:34 +0100
Subject: [wildfly-dev] Monitoring wildfly using Influx
In-Reply-To: <BF3F2447-6D88-411A-9579-0EF8A7F38D28@redhat.com>
References: <69107B29-1ADD-488E-A808-C23AB8DB02A8@redhat.com>
	<545A5FDD.5060907@redhat.com>
	<1A9994D2-1476-4DA0-A725-AC4DBD51FACF@redhat.com>
	<DA632B7A-A367-4104-9325-C53AC15643A6@redhat.com>
	<BF3F2447-6D88-411A-9579-0EF8A7F38D28@redhat.com>
Message-ID: <5CC0C486-717A-4C45-A11B-1AF5747265FC@redhat.com>


Currently the docs are a little misleading, as it says you should install the monitor susbystem as described in the README but then points to the quickstart scripts ('start.sh') that download and install a dedicated WF instance.

I think it would be better to focus on the steps needed to install all components on an existing server.

On 06 Nov 2014, at 10:39, Heiko Braun <hbraun at redhat.com> wrote:

> Great, thanks for the documentation. Maybe we should explain how to install it on an existing Wildfly instance? 
> 
> 
> On 06 Nov 2014, at 10:30, Heiko W.Rupp <hrupp at redhat.com> wrote:
> 
>> 
>>> Am 05.11.2014 um 20:08 schrieb Heiko Braun <hbraun at redhat.com>:
>>> Not sure if that came through: this is just the influx example. Alternatively you can run use with the new RHQ storage. Some docs will follow ...
>> 
>> After Heiko put the ball in my court, I've played with it:
>> 
>> https://github.com/rhq-project/wildfly-monitor/wiki/RHQ-Metrics-backend
>> 
>> Heiko
>> 
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



From hrupp at redhat.com  Thu Nov  6 05:33:37 2014
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Thu, 6 Nov 2014 11:33:37 +0100
Subject: [wildfly-dev] Monitoring wildfly using Influx
In-Reply-To: <5CC0C486-717A-4C45-A11B-1AF5747265FC@redhat.com>
References: <69107B29-1ADD-488E-A808-C23AB8DB02A8@redhat.com>
	<545A5FDD.5060907@redhat.com>
	<1A9994D2-1476-4DA0-A725-AC4DBD51FACF@redhat.com>
	<DA632B7A-A367-4104-9325-C53AC15643A6@redhat.com>
	<BF3F2447-6D88-411A-9579-0EF8A7F38D28@redhat.com>
	<5CC0C486-717A-4C45-A11B-1AF5747265FC@redhat.com>
Message-ID: <5AE3AB94-9B82-4D56-8A4D-9B6D09584A2B@redhat.com>


> Am 06.11.2014 um 10:42 schrieb Heiko Braun <hbraun at redhat.com>:
> 
> 
> Currently the docs are a little misleading, as it says you should install the monitor susbystem as described in the README but then points to the quickstart scripts ('start.sh') that download and install a dedicated WF instance.
> 
> I think it would be better to focus on the steps needed to install all components on an existing server.

We should perhaps write a start_big.sh  that also installs your Cassandra subsystem, the wildfly monitor
and then rhq-metrics(.war)

Anyone with shell-fu around? :)



From hpehl at redhat.com  Thu Nov  6 05:47:40 2014
From: hpehl at redhat.com (Harald Pehl)
Date: Thu, 6 Nov 2014 11:47:40 +0100
Subject: [wildfly-dev] Monitoring wildfly using Influx
In-Reply-To: <5AE3AB94-9B82-4D56-8A4D-9B6D09584A2B@redhat.com>
References: <69107B29-1ADD-488E-A808-C23AB8DB02A8@redhat.com>
	<545A5FDD.5060907@redhat.com>
	<1A9994D2-1476-4DA0-A725-AC4DBD51FACF@redhat.com>
	<DA632B7A-A367-4104-9325-C53AC15643A6@redhat.com>
	<BF3F2447-6D88-411A-9579-0EF8A7F38D28@redhat.com>
	<5CC0C486-717A-4C45-A11B-1AF5747265FC@redhat.com>
	<5AE3AB94-9B82-4D56-8A4D-9B6D09584A2B@redhat.com>
Message-ID: <07B93A1F-FC9B-4A0A-8CE9-D8BDA3CDA286@redhat.com>

What about providing a couple of Docker images to quickly setup something devs can play around with? This way we could demo different solutions:

- WildFly Monitor + Cassandra + RHQ Metrics
- WildFly Monitor + InfluxDB + Grafana

I can try to put something together and push it to https://hub.docker.com/

.: Harald

> Am 06.11.2014 um 11:33 schrieb Heiko W.Rupp <hrupp at redhat.com>:
> 
> 
>> Am 06.11.2014 um 10:42 schrieb Heiko Braun <hbraun at redhat.com>:
>> 
>> 
>> Currently the docs are a little misleading, as it says you should install the monitor susbystem as described in the README but then points to the quickstart scripts ('start.sh') that download and install a dedicated WF instance.
>> 
>> I think it would be better to focus on the steps needed to install all components on an existing server.
> 
> We should perhaps write a start_big.sh  that also installs your Cassandra subsystem, the wildfly monitor
> and then rhq-metrics(.war)
> 
> Anyone with shell-fu around? :)
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

---
Harald Pehl
JBoss by Red Hat
http://hpehl.info



From hbraun at redhat.com  Thu Nov  6 05:52:16 2014
From: hbraun at redhat.com (Heiko Braun)
Date: Thu, 6 Nov 2014 11:52:16 +0100
Subject: [wildfly-dev] Monitoring wildfly using Influx
In-Reply-To: <5AE3AB94-9B82-4D56-8A4D-9B6D09584A2B@redhat.com>
References: <69107B29-1ADD-488E-A808-C23AB8DB02A8@redhat.com>
	<545A5FDD.5060907@redhat.com>
	<1A9994D2-1476-4DA0-A725-AC4DBD51FACF@redhat.com>
	<DA632B7A-A367-4104-9325-C53AC15643A6@redhat.com>
	<BF3F2447-6D88-411A-9579-0EF8A7F38D28@redhat.com>
	<5CC0C486-717A-4C45-A11B-1AF5747265FC@redhat.com>
	<5AE3AB94-9B82-4D56-8A4D-9B6D09584A2B@redhat.com>
Message-ID: <787AF548-8F58-447F-BB2B-E1483C639B29@redhat.com>



I would propose the other direction: provide access to the core components or their build and explain the manual steps to install & configure Wildfly to make use of it. 

the scripts, as provided right now, hide to much of the important details for people who want to install the monitor on an existing wildfly server. 

it might be a good quickstart experience that we can keep, but the documentation should explain the bare metal steps first and foremost. 

On 06 Nov 2014, at 11:33, Heiko W.Rupp <hrupp at redhat.com> wrote:

> 
>> Am 06.11.2014 um 10:42 schrieb Heiko Braun <hbraun at redhat.com>:
>> 
>> 
>> Currently the docs are a little misleading, as it says you should install the monitor susbystem as described in the README but then points to the quickstart scripts ('start.sh') that download and install a dedicated WF instance.
>> 
>> I think it would be better to focus on the steps needed to install all components on an existing server.
> 
> We should perhaps write a start_big.sh  that also installs your Cassandra subsystem, the wildfly monitor
> and then rhq-metrics(.war)
> 
> Anyone with shell-fu around? :)
> 



From hbraun at redhat.com  Thu Nov  6 05:55:56 2014
From: hbraun at redhat.com (Heiko Braun)
Date: Thu, 6 Nov 2014 11:55:56 +0100
Subject: [wildfly-dev] Monitoring wildfly using Influx
In-Reply-To: <07B93A1F-FC9B-4A0A-8CE9-D8BDA3CDA286@redhat.com>
References: <69107B29-1ADD-488E-A808-C23AB8DB02A8@redhat.com>
	<545A5FDD.5060907@redhat.com>
	<1A9994D2-1476-4DA0-A725-AC4DBD51FACF@redhat.com>
	<DA632B7A-A367-4104-9325-C53AC15643A6@redhat.com>
	<BF3F2447-6D88-411A-9579-0EF8A7F38D28@redhat.com>
	<5CC0C486-717A-4C45-A11B-1AF5747265FC@redhat.com>
	<5AE3AB94-9B82-4D56-8A4D-9B6D09584A2B@redhat.com>
	<07B93A1F-FC9B-4A0A-8CE9-D8BDA3CDA286@redhat.com>
Message-ID: <2A456772-BD58-45F1-A5E9-EC5D13A004E7@redhat.com>

that's certainly a good idea, but we need to deliver documentation of the bare metal steps first.

we can provide arbitrary layers of convenience _after_ we've explained how to build, install and configure the core components.

no auto-magic, no shortcuts, no additional layers of complexity that hide what's going on underneath. 



On 06 Nov 2014, at 11:47, Harald Pehl <hpehl at redhat.com> wrote:

> What about providing a couple of Docker images to quickly setup something devs can play around with? This way we could demo different solutions:
> 
> - WildFly Monitor + Cassandra + RHQ Metrics
> - WildFly Monitor + InfluxDB + Grafana
> 
> I can try to put something together and push it to https://hub.docker.com/
> 
> .: Harald
> 
>> Am 06.11.2014 um 11:33 schrieb Heiko W.Rupp <hrupp at redhat.com>:
>> 
>> 
>>> Am 06.11.2014 um 10:42 schrieb Heiko Braun <hbraun at redhat.com>:
>>> 
>>> 
>>> Currently the docs are a little misleading, as it says you should install the monitor susbystem as described in the README but then points to the quickstart scripts ('start.sh') that download and install a dedicated WF instance.
>>> 
>>> I think it would be better to focus on the steps needed to install all components on an existing server.
>> 
>> We should perhaps write a start_big.sh  that also installs your Cassandra subsystem, the wildfly monitor
>> and then rhq-metrics(.war)
>> 
>> Anyone with shell-fu around? :)
>> 
>> 
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> ---
> Harald Pehl
> JBoss by Red Hat
> http://hpehl.info
> 



From hbraun at redhat.com  Thu Nov  6 06:01:29 2014
From: hbraun at redhat.com (Heiko Braun)
Date: Thu, 6 Nov 2014 12:01:29 +0100
Subject: [wildfly-dev] Monitoring wildfly using Influx
In-Reply-To: <2A456772-BD58-45F1-A5E9-EC5D13A004E7@redhat.com>
References: <69107B29-1ADD-488E-A808-C23AB8DB02A8@redhat.com>
	<545A5FDD.5060907@redhat.com>
	<1A9994D2-1476-4DA0-A725-AC4DBD51FACF@redhat.com>
	<DA632B7A-A367-4104-9325-C53AC15643A6@redhat.com>
	<BF3F2447-6D88-411A-9579-0EF8A7F38D28@redhat.com>
	<5CC0C486-717A-4C45-A11B-1AF5747265FC@redhat.com>
	<5AE3AB94-9B82-4D56-8A4D-9B6D09584A2B@redhat.com>
	<07B93A1F-FC9B-4A0A-8CE9-D8BDA3CDA286@redhat.com>
	<2A456772-BD58-45F1-A5E9-EC5D13A004E7@redhat.com>
Message-ID: <A66EA767-C130-43D4-9C85-01B8CEECC9B3@redhat.com>


This example (taken from the RHQ docs) is not a good explanation how to install the various components:

$ git clone https://github.com/rhq-project/rhq-metrics
$ cd rhq-metrics
$ ./start.sh
It might be a quick start, but I don't want to explore the nitty gritty details of the shell script and the calls into maven to understand what actually happens and how I can replicate these steps on an exiting wildfly instance. 


On 06 Nov 2014, at 11:55, Heiko Braun <hbraun at redhat.com> wrote:

> that's certainly a good idea, but we need to deliver documentation of the bare metal steps first.
> 
> we can provide arbitrary layers of convenience _after_ we've explained how to build, install and configure the core components.
> 
> no auto-magic, no shortcuts, no additional layers of complexity that hide what's going on underneath. 
> 
> 
> 
> On 06 Nov 2014, at 11:47, Harald Pehl <hpehl at redhat.com> wrote:
> 
>> What about providing a couple of Docker images to quickly setup something devs can play around with? This way we could demo different solutions:
>> 
>> - WildFly Monitor + Cassandra + RHQ Metrics
>> - WildFly Monitor + InfluxDB + Grafana
>> 
>> I can try to put something together and push it to https://hub.docker.com/
>> 
>> .: Harald
>> 
>>> Am 06.11.2014 um 11:33 schrieb Heiko W.Rupp <hrupp at redhat.com>:
>>> 
>>> 
>>>> Am 06.11.2014 um 10:42 schrieb Heiko Braun <hbraun at redhat.com>:
>>>> 
>>>> 
>>>> Currently the docs are a little misleading, as it says you should install the monitor susbystem as described in the README but then points to the quickstart scripts ('start.sh') that download and install a dedicated WF instance.
>>>> 
>>>> I think it would be better to focus on the steps needed to install all components on an existing server.
>>> 
>>> We should perhaps write a start_big.sh  that also installs your Cassandra subsystem, the wildfly monitor
>>> and then rhq-metrics(.war)
>>> 
>>> Anyone with shell-fu around? :)
>>> 
>>> 
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> 
>> ---
>> Harald Pehl
>> JBoss by Red Hat
>> http://hpehl.info
>> 
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

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

From claudio at claudius.com.br  Thu Nov  6 07:01:24 2014
From: claudio at claudius.com.br (Claudio Miranda)
Date: Thu, 6 Nov 2014 10:01:24 -0200
Subject: [wildfly-dev] duplicate resource on deploying
In-Reply-To: <545AE17D.2050806@redhat.com>
References: <CALbD--r0C7U_xmSwAWYhD4NyMH+U_FCisH-=hOC55GBuFafO7A@mail.gmail.com>
	<545AE17D.2050806@redhat.com>
Message-ID: <CALbD--rgMXzs7RijJwbhMeCSMSgoGuukzoRWmxAU_c=ZkFbYRQ@mail.gmail.com>

On Thu, Nov 6, 2014 at 12:48 AM, Brian Stansberry
<brian.stansberry at redhat.com> wrote:
>
> It's intended to be in data/content but should not end up in standalone.xml.

Previously, resources added to deployments directory just stayed
there, what is the use to copy them to data/content ?

Just curious.


-- 
  Claudio Miranda

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

From brian.stansberry at redhat.com  Thu Nov  6 08:43:45 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 06 Nov 2014 07:43:45 -0600
Subject: [wildfly-dev] duplicate resource on deploying
In-Reply-To: <CALbD--rgMXzs7RijJwbhMeCSMSgoGuukzoRWmxAU_c=ZkFbYRQ@mail.gmail.com>
References: <CALbD--r0C7U_xmSwAWYhD4NyMH+U_FCisH-=hOC55GBuFafO7A@mail.gmail.com>
	<545AE17D.2050806@redhat.com>
	<CALbD--rgMXzs7RijJwbhMeCSMSgoGuukzoRWmxAU_c=ZkFbYRQ@mail.gmail.com>
Message-ID: <545B7B11.1010709@redhat.com>

On 11/6/14, 6:01 AM, Claudio Miranda wrote:
> On Thu, Nov 6, 2014 at 12:48 AM, Brian Stansberry
> <brian.stansberry at redhat.com> wrote:
>>
>> It's intended to be in data/content but should not end up in standalone.xml.
>
> Previously, resources added to deployments directory just stayed
> there,

That was a bug, a change in the original behavior introduced in a patch.

Granted, it's a bug that's been there for a long time, probably since 7.1.

> what is the use to copy them to data/content ?
>

The stuff in data/content is owned by the server process; the stuff in 
deployments/ is owned by whomever. Having the actual deployment used by 
the server owned by the server is safer.

We can't do that with exploded deployments (yet) but we can with zipped 
content.

> Just curious.
>
>


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

From claudio at claudius.com.br  Thu Nov  6 10:47:54 2014
From: claudio at claudius.com.br (Claudio Miranda)
Date: Thu, 6 Nov 2014 13:47:54 -0200
Subject: [wildfly-dev] webservices statistics-enabled is not persisted
Message-ID: <CALbD--r+owsQk5vwH7hJHj6u3r7HF70YbSzAD4Cu7skDm+2UEA@mail.gmail.com>

WF9 master, doesn't persist statistics-enabled=true for webservices
subsystem in standalone.xml

/subsystem=webservices:write-attribute(name=statistics-enabled,value=true)



-- 
  Claudio Miranda

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

From claudio at claudius.com.br  Thu Nov  6 19:48:15 2014
From: claudio at claudius.com.br (Claudio Miranda)
Date: Thu, 6 Nov 2014 22:48:15 -0200
Subject: [wildfly-dev] webservices statistics-enabled is not persisted
In-Reply-To: <CALbD--r+owsQk5vwH7hJHj6u3r7HF70YbSzAD4Cu7skDm+2UEA@mail.gmail.com>
References: <CALbD--r+owsQk5vwH7hJHj6u3r7HF70YbSzAD4Cu7skDm+2UEA@mail.gmail.com>
Message-ID: <CALbD--pkDRT1QLp6PwHYnAVStjFRKPuBJay4GJLQCy7Vz42J0w@mail.gmail.com>

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

I fixed it, will PR shortly.

On Thu, Nov 6, 2014 at 1:47 PM, Claudio Miranda <claudio at claudius.com.br> wrote:
> WF9 master, doesn't persist statistics-enabled=true for webservices
> subsystem in standalone.xml
>
> /subsystem=webservices:write-attribute(name=statistics-enabled,value=true)



-- 
  Claudio Miranda

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

From claudio at claudius.com.br  Thu Nov  6 20:35:19 2014
From: claudio at claudius.com.br (Claudio Miranda)
Date: Thu, 6 Nov 2014 23:35:19 -0200
Subject: [wildfly-dev] statistics-enabled missing in wildfly-undertow_2_0.xsd
Message-ID: <CALbD--rRzTEnBY5FMq7Gmkq5dhBu8Pnv8v=qC0-t113wzAqqjA@mail.gmail.com>

It is missing, but the attribute is persisted in xml. The XSD should
validate it in and not persist the attribute, is that correct ?

-- 
  Claudio Miranda

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

From brian.stansberry at redhat.com  Thu Nov  6 21:05:46 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 06 Nov 2014 20:05:46 -0600
Subject: [wildfly-dev] statistics-enabled missing in
	wildfly-undertow_2_0.xsd
In-Reply-To: <CALbD--rRzTEnBY5FMq7Gmkq5dhBu8Pnv8v=qC0-t113wzAqqjA@mail.gmail.com>
References: <CALbD--rRzTEnBY5FMq7Gmkq5dhBu8Pnv8v=qC0-t113wzAqqjA@mail.gmail.com>
Message-ID: <545C28FA.5020809@redhat.com>

On 11/6/14, 7:35 PM, Claudio Miranda wrote:
> It is missing, but the attribute is persisted in xml. The XSD should
> validate it in and not persist the attribute, is that correct ?
>

I don't understand this question.

The xsd declares the attribute, the management metadata says it's 
persistent, and the parser reads it, so I think it's just a matter of 
not being marshalled. Adding

Attributes.STATISTICS_ENABLED.marshallAsAttribute(subsystem, writer);

after

https://github.com/wildfly/wildfly/blob/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/dmr/WSSubsystemWriter.java#L62

will fix it.

Adding statistics-enabled="false" at the end of the element at

https://github.com/wildfly/wildfly/blob/master/webservices/server-integration/src/test/resources/org/jboss/as/webservices/dmr/ws-subsystem20.xml#L1

will ensure that the subsystem test verifies the marshalling.

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

From brian.stansberry at redhat.com  Thu Nov  6 21:09:06 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 06 Nov 2014 20:09:06 -0600
Subject: [wildfly-dev] statistics-enabled missing in
	wildfly-undertow_2_0.xsd
In-Reply-To: <545C28FA.5020809@redhat.com>
References: <CALbD--rRzTEnBY5FMq7Gmkq5dhBu8Pnv8v=qC0-t113wzAqqjA@mail.gmail.com>
	<545C28FA.5020809@redhat.com>
Message-ID: <545C29C2.4070600@redhat.com>

Ah, sorry, I see this is "undertow" you're asking about.

I'll have a look.

On 11/6/14, 8:05 PM, Brian Stansberry wrote:
> On 11/6/14, 7:35 PM, Claudio Miranda wrote:
>> It is missing, but the attribute is persisted in xml. The XSD should
>> validate it in and not persist the attribute, is that correct ?
>>
>
> I don't understand this question.
>
> The xsd declares the attribute, the management metadata says it's
> persistent, and the parser reads it, so I think it's just a matter of
> not being marshalled. Adding
>
> Attributes.STATISTICS_ENABLED.marshallAsAttribute(subsystem, writer);
>
> after
>
> https://github.com/wildfly/wildfly/blob/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/dmr/WSSubsystemWriter.java#L62
>
> will fix it.
>
> Adding statistics-enabled="false" at the end of the element at
>
> https://github.com/wildfly/wildfly/blob/master/webservices/server-integration/src/test/resources/org/jboss/as/webservices/dmr/ws-subsystem20.xml#L1
>
> will ensure that the subsystem test verifies the marshalling.
>


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

From brian.stansberry at redhat.com  Thu Nov  6 21:16:01 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 06 Nov 2014 20:16:01 -0600
Subject: [wildfly-dev] statistics-enabled missing in
	wildfly-undertow_2_0.xsd
In-Reply-To: <545C29C2.4070600@redhat.com>
References: <CALbD--rRzTEnBY5FMq7Gmkq5dhBu8Pnv8v=qC0-t113wzAqqjA@mail.gmail.com>	<545C28FA.5020809@redhat.com>
	<545C29C2.4070600@redhat.com>
Message-ID: <545C2B61.5030304@redhat.com>

Looks like it's just missing from the XSD and from the test case file at

https://github.com/wildfly/wildfly/blob/master/undertow/src/test/resources/org/wildfly/extension/undertow/undertow-2.0.xml#L26

The test passes if that's added, so that shows that the parsing and 
marshalling bits work, and it's just the XSD that is wrong.

On 11/6/14, 8:09 PM, Brian Stansberry wrote:
> Ah, sorry, I see this is "undertow" you're asking about.
>
> I'll have a look.
>
> On 11/6/14, 8:05 PM, Brian Stansberry wrote:
>> On 11/6/14, 7:35 PM, Claudio Miranda wrote:
>>> It is missing, but the attribute is persisted in xml. The XSD should
>>> validate it in and not persist the attribute, is that correct ?
>>>
>>
>> I don't understand this question.
>>
>> The xsd declares the attribute, the management metadata says it's
>> persistent, and the parser reads it, so I think it's just a matter of
>> not being marshalled. Adding
>>
>> Attributes.STATISTICS_ENABLED.marshallAsAttribute(subsystem, writer);
>>
>> after
>>
>> https://github.com/wildfly/wildfly/blob/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/dmr/WSSubsystemWriter.java#L62
>>
>> will fix it.
>>
>> Adding statistics-enabled="false" at the end of the element at
>>
>> https://github.com/wildfly/wildfly/blob/master/webservices/server-integration/src/test/resources/org/jboss/as/webservices/dmr/ws-subsystem20.xml#L1
>>
>> will ensure that the subsystem test verifies the marshalling.
>>
>
>


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

From claudio at claudius.com.br  Thu Nov  6 21:34:00 2014
From: claudio at claudius.com.br (Claudio Miranda)
Date: Fri, 7 Nov 2014 00:34:00 -0200
Subject: [wildfly-dev] statistics-enabled missing in
	wildfly-undertow_2_0.xsd
In-Reply-To: <545C2B61.5030304@redhat.com>
References: <CALbD--rRzTEnBY5FMq7Gmkq5dhBu8Pnv8v=qC0-t113wzAqqjA@mail.gmail.com>
	<545C28FA.5020809@redhat.com> <545C29C2.4070600@redhat.com>
	<545C2B61.5030304@redhat.com>
Message-ID: <CALbD--qMkVLxyJ00eUozwEg5zHLT5O2KPiyaTbsR68SLHOL2nw@mail.gmail.com>

On Fri, Nov 7, 2014 at 12:16 AM, Brian Stansberry
<brian.stansberry at redhat.com> wrote:
> The test passes if that's added, so that shows that the parsing and
> marshalling bits work, and it's just the XSD that is wrong.

Also, the attribute definition below validates the xml. I will fix the
XSD and submit PR.

https://github.com/wildfly/wildfly/blob/master/undertow/src/main/java/org/wildfly/extension/undertow/UndertowSubsystemParser_2_0.java#L66

Thanks for your valuable input Brian.
-- 
  Claudio Miranda

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

From tom at schuller.lu  Fri Nov  7 10:57:10 2014
From: tom at schuller.lu (Tom Schuller)
Date: Fri, 7 Nov 2014 16:57:10 +0100
Subject: [wildfly-dev] WildFly-latest-master: errors in add-user.bat
In-Reply-To: <CAFezRTR26M8D1hExuee6=3n4juYC92dij3=4btHxkOWchAEKeg@mail.gmail.com>
References: <CAFezRTR26M8D1hExuee6=3n4juYC92dij3=4btHxkOWchAEKeg@mail.gmail.com>
Message-ID: <CAFezRTSuNP21dHTvh3wDD3cpOiU-=-fWhsY-Fn7-vEyyO_ZkDA@mail.gmail.com>

Hy,
I have problems for testing the latest WildFly builds on my windows
environment.
I have downloaded the versions from:
 https <https://ci.jboss.org/hudson/job/WildFly-latest-master/>://
<https://ci.jboss.org/hudson/job/WildFly-latest-master/>ci.jboss.org
<https://ci.jboss.org/hudson/job/WildFly-latest-master/>/
<https://ci.jboss.org/hudson/job/WildFly-latest-master/>hudson
<https://ci.jboss.org/hudson/job/WildFly-latest-master/>/job/
<https://ci.jboss.org/hudson/job/WildFly-latest-master/>WildFly
<https://ci.jboss.org/hudson/job/WildFly-latest-master/>-
<https://ci.jboss.org/hudson/job/WildFly-latest-master/>latest
<https://ci.jboss.org/hudson/job/WildFly-latest-master/>-master/
<https://ci.jboss.org/hudson/job/WildFly-latest-master/>

On wildfly-#1467, I had to remove in the "bin\add-user.bat" this part to
get it working:
  lines 32-37
  if /i "%RESOLVED_JBOSS_HOME%" NEQ "%SANITIZED_JBOSS_HOME%" (
     echo.
     echo   WARNING: The JBOSS_HOME ("%SANITIZED_JBOSS_HOME%") that this
script uses points to a different installation than the one that this
script resides in ("%RESOLVED_JBOSS_HOME%"). Unpredictable results may
occur.
     echo.
     echo       JBOSS_HOME: "%JBOSS_HOME%"
     echo.
  )

After this, I could use the "add-user.bat" batch file.

Now with wildfly-#1470, I also have to remove these line to fix the bug of
"add-user.bat" as above.
But then, I'm getting this error:
  D:\java\wildfly-9.0.0.Alpha2-1470\bin>add-user.bat
  org.jboss.modules.ModuleNotFoundException:
org.jboss.as.domain-add-user:main
        at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236)
        at org.jboss.modules.Main.main(Main.java:385)
  Press any key to continue . . .

 What can/should I do?

 I don't  know if this is the right place to make these observations.
 But I think, I should not spam the forum with this really in-development
observations.

 Thanks,
  Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141107/ad8d65fe/attachment-0001.html 

From pbenedict at apache.org  Fri Nov  7 11:00:47 2014
From: pbenedict at apache.org (Paul Benedict)
Date: Fri, 7 Nov 2014 10:00:47 -0600
Subject: [wildfly-dev] Potential error in jboss-web_8_0.xsd
In-Reply-To: <CABLGb9wADsigbYZtPCsFshBDi=7R+n-GdREAcfOJ7joxfvNGGQ@mail.gmail.com>
References: <CABLGb9wADsigbYZtPCsFshBDi=7R+n-GdREAcfOJ7joxfvNGGQ@mail.gmail.com>
Message-ID: <CABLGb9yr=MpS+GiTWs1ZPw7yJnxrgPyPV1+=PPbN7h=TMExeog@mail.gmail.com>

Just following-up. If any Red hat developers are here, I'd like someone to
look into this issue. If this is the wrong mailing list and/or it's better
to raise a JIRA issue, please just let me know.

Cheers,
Paul

On Tue, Nov 4, 2014 at 9:53 PM, Paul Benedict <pbenedict at apache.org> wrote:

> I think there's an error in this XSD [1] which prevents me from using the
> "javaee"  elements you intend to import.
>
> First, the "javaee" namespace is declared as "
> http://xmlns.jcp.org/xml/ns/javaee" in the XML header, but then
> (surprisingly) the <xsd:import> uses another namepace:
>
> <xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation=
> "web-app_3_1.xsd"/>
>
> I'm pretty confident this is wrong. It's importing under the old Java EE
> namespace -- not the new one which the header correctly declares. Hence,
> consumers are unable to get the "javaee" elements.
>
> Please confirm.
>
> [1]
> https://github.com/jboss/metadata/blob/master/web/src/main/resources/schema/jboss-web_8_0.xsd
>
> Cheers,
> Paul
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141107/86fbd85b/attachment.html 

From tomaz.cerar at gmail.com  Fri Nov  7 11:04:19 2014
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Fri, 7 Nov 2014 17:04:19 +0100
Subject: [wildfly-dev] WildFly-latest-master: errors in add-user.bat
In-Reply-To: <CAFezRTSuNP21dHTvh3wDD3cpOiU-=-fWhsY-Fn7-vEyyO_ZkDA@mail.gmail.com>
References: <CAFezRTR26M8D1hExuee6=3n4juYC92dij3=4btHxkOWchAEKeg@mail.gmail.com>
	<CAFezRTSuNP21dHTvh3wDD3cpOiU-=-fWhsY-Fn7-vEyyO_ZkDA@mail.gmail.com>
Message-ID: <CAMquZP6ivadBUHDuktsjv2qYqFHd0GrW2e8JqLeh5s9pNGtt=g@mail.gmail.com>

You should not remove that part of script that tells you what is wrong :)

it is telling you that you are running script from different folder that
your JBOSS_HOME environment variable points to and that that could cause
"unpredictable results"

which is exactly what happens next.

just unset JBOSS_HOME and you will be fine.

you can do that by typing this:
*set JBOSS_HOME=*

or under system properties of you computer.

--
tomaz

On Fri, Nov 7, 2014 at 4:57 PM, Tom Schuller <tom at schuller.lu> wrote:

> Hy,
> I have problems for testing the latest WildFly builds on my windows
> environment.
> I have downloaded the versions from:
>  https <https://ci.jboss.org/hudson/job/WildFly-latest-master/>://
> <https://ci.jboss.org/hudson/job/WildFly-latest-master/>ci.jboss.org
> <https://ci.jboss.org/hudson/job/WildFly-latest-master/>/
> <https://ci.jboss.org/hudson/job/WildFly-latest-master/>hudson
> <https://ci.jboss.org/hudson/job/WildFly-latest-master/>/job/
> <https://ci.jboss.org/hudson/job/WildFly-latest-master/>WildFly
> <https://ci.jboss.org/hudson/job/WildFly-latest-master/>-
> <https://ci.jboss.org/hudson/job/WildFly-latest-master/>latest
> <https://ci.jboss.org/hudson/job/WildFly-latest-master/>-master/
> <https://ci.jboss.org/hudson/job/WildFly-latest-master/>
>
> On wildfly-#1467, I had to remove in the "bin\add-user.bat" this part to
> get it working:
>   lines 32-37
>   if /i "%RESOLVED_JBOSS_HOME%" NEQ "%SANITIZED_JBOSS_HOME%" (
>      echo.
>      echo   WARNING: The JBOSS_HOME ("%SANITIZED_JBOSS_HOME%") that this
> script uses points to a different installation than the one that this
> script resides in ("%RESOLVED_JBOSS_HOME%"). Unpredictable results may
> occur.
>      echo.
>      echo       JBOSS_HOME: "%JBOSS_HOME%"
>      echo.
>   )
>
> After this, I could use the "add-user.bat" batch file.
>
> Now with wildfly-#1470, I also have to remove these line to fix the bug of
> "add-user.bat" as above.
> But then, I'm getting this error:
>   D:\java\wildfly-9.0.0.Alpha2-1470\bin>add-user.bat
>   org.jboss.modules.ModuleNotFoundException:
> org.jboss.as.domain-add-user:main
>         at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236)
>         at org.jboss.modules.Main.main(Main.java:385)
>   Press any key to continue . . .
>
>  What can/should I do?
>
>  I don't  know if this is the right place to make these observations.
>  But I think, I should not spam the forum with this really in-development
> observations.
>
>  Thanks,
>   Tom
>
> _______________________________________________
> 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/20141107/6ddf4b63/attachment.html 

From brian.stansberry at redhat.com  Fri Nov  7 11:15:43 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Fri, 07 Nov 2014 10:15:43 -0600
Subject: [wildfly-dev] Potential error in jboss-web_8_0.xsd
In-Reply-To: <CABLGb9yr=MpS+GiTWs1ZPw7yJnxrgPyPV1+=PPbN7h=TMExeog@mail.gmail.com>
References: <CABLGb9wADsigbYZtPCsFshBDi=7R+n-GdREAcfOJ7joxfvNGGQ@mail.gmail.com>
	<CABLGb9yr=MpS+GiTWs1ZPw7yJnxrgPyPV1+=PPbN7h=TMExeog@mail.gmail.com>
Message-ID: <545CF02F.5000300@redhat.com>

Please file a JIRA issue. Thanks!

On 11/7/14, 10:00 AM, Paul Benedict wrote:
> Just following-up. If any Red hat developers are here, I'd like someone
> to look into this issue. If this is the wrong mailing list and/or it's
> better to raise a JIRA issue, please just let me know.
>
> Cheers,
> Paul
>
> On Tue, Nov 4, 2014 at 9:53 PM, Paul Benedict <pbenedict at apache.org
> <mailto:pbenedict at apache.org>> wrote:
>
>     I think there's an error in this XSD [1] which prevents me from
>     using the "javaee"  elements you intend to import.
>
>     First, the "javaee" namespace is declared as
>     "http://xmlns.jcp.org/xml/ns/javaee" in the XML header, but then
>     (surprisingly) the <xsd:import> uses another namepace:
>
>     <xsd:import namespace="http://java.sun.com/xml/ns/javaee"
>     schemaLocation="web-app_3_1.xsd"/>
>
>     I'm pretty confident this is wrong. It's importing under the old
>     Java EE namespace -- not the new one which the header correctly
>     declares. Hence, consumers are unable to get the "javaee" elements.
>
>     Please confirm.
>
>     [1]
>     https://github.com/jboss/metadata/blob/master/web/src/main/resources/schema/jboss-web_8_0.xsd
>
>     Cheers,
>     Paul
>
>
>
>
> _______________________________________________
> 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 tom at schuller.lu  Fri Nov  7 14:37:55 2014
From: tom at schuller.lu (Tom Schuller)
Date: Fri, 7 Nov 2014 20:37:55 +0100
Subject: [wildfly-dev] session.invalidate with open conversation results in
	DummyTransactionException
Message-ID: <CAFezRTQonJtY5qGy_-MNdSZMdg=K=nwmNk-y28+C=8LonmEzQQ@mail.gmail.com>

Hy,
We are getting DummyTransactionExceptions when we are invalidating a
session when a non-transient conversation is still open.

I just give in the forum a complete guide how to reproduce our problem.
Maybe somebody has time to look on it:
  https://developer.jboss.org/message/909561#909561


Here the resume of the forum:
 I just tried out with
https://ci.jboss.org/hudson/job/WildFly-latest-master/1470/
 We are getting the same exception DummyTransactionException
 We are working in the "full-ha" profile.

What we are to reproduce the problem:.
 - downloading WildFly-latest-master #1470 [Jenkins]
 - added an management user for the console with "add-user.bat"
 - changing in %JBOSS_HOME%\domain\configuration\domain.xml the
"cluster-password" to a real password
 - starting up with "domain.bat" and loading the console (
http://localhost:9990)
 - changed the "main-server-group" to "full-ha" profile with
"full-ha-sockets" binding
 - restarted the WildFly support to get it running in "full-ha"
 - deplayed the convTest.war (latest version with sources is attached in
the forum thread) to the main-server-group and enabled it
 - doing the test:
    - opening http://localhost:8080/convTest/step1.jsf
    - starting a conversation by clicking on "startConversation" button
    - clicking the "logout" button to invalidate the session

=> DummyTransactionException

What are we doing wrong?


Thanks.
 Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141107/24b17c05/attachment.html 

From tom at schuller.lu  Sun Nov  9 11:59:05 2014
From: tom at schuller.lu (Tom Schuller)
Date: Sun, 9 Nov 2014 17:59:05 +0100
Subject: [wildfly-dev] Fwd:  WildFly-latest-master: errors in add-user.bat
In-Reply-To: <CAFezRTS3RmuG04AcmiUwDX139tBKDSBQAKoOuASE=OUM6e_Nrw@mail.gmail.com>
References: <CAFezRTR26M8D1hExuee6=3n4juYC92dij3=4btHxkOWchAEKeg@mail.gmail.com>
	<CAFezRTSuNP21dHTvh3wDD3cpOiU-=-fWhsY-Fn7-vEyyO_ZkDA@mail.gmail.com>
	<CAMquZP6ivadBUHDuktsjv2qYqFHd0GrW2e8JqLeh5s9pNGtt=g@mail.gmail.com>
	<CAFezRTREW12hJ8GJ2hpA2-Bm-uFzQ-Hy=tfusMwkYQy_xNAAnQ@mail.gmail.com>
	<CAFezRTS3RmuG04AcmiUwDX139tBKDSBQAKoOuASE=OUM6e_Nrw@mail.gmail.com>
Message-ID: <CAFezRTS00MtaWoMeq_TpQWv3H8hrSu4xb=ra_xsvNteyank0Uw@mail.gmail.com>

I got it.
I extracted the zip again and now it's working.

Thanks,
 Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141109/7ff1373c/attachment.html 

From brian.stansberry at redhat.com  Sun Nov  9 19:28:15 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Sun, 09 Nov 2014 18:28:15 -0600
Subject: [wildfly-dev] WildFly Core 1.0.0.Alpha12
Message-ID: <5460069F.4000600@redhat.com>

This week's alpha of WildFly Core has been released and integrated into 
full WildFly.

Best regards,

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

From ehugonne at redhat.com  Mon Nov 10 13:43:57 2014
From: ehugonne at redhat.com (Emmanuel Hugonnet)
Date: Mon, 10 Nov 2014 19:43:57 +0100
Subject: [wildfly-dev] Detecting WildFly version
Message-ID: <5461076D.2000503@redhat.com>

Hi,
I need to detect the version of a WildFly installation (so not running).
I used to look into the Implementation-Version: entry in the MANIFEST.MF of org/jboss/as/server/main/wildfly-server-8.1.0.Final.jar
But with the full /core split now I'm getting the wildfly-core version which might not be relevant.
I thought also to look int jboss-as-version-${version}.jar but it suffers with the same issue :-(
What is the official supported way of doing this ?
Cheers,
Emmanuel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141110/3425f7fa/attachment-0001.bin 

From hbraun at redhat.com  Tue Nov 11 04:34:23 2014
From: hbraun at redhat.com (Heiko Braun)
Date: Tue, 11 Nov 2014 10:34:23 +0100
Subject: [wildfly-dev] Monitoring Subsystem: Some Documentation
Message-ID: <60883B31-BB78-4D59-B6B5-33E20C2BA46E@redhat.com>


I've updated the WIKI page for the monitoring subsystem to include some docs about the configuration options:

https://github.com/rhq-project/wildfly-monitor/wiki/Configuration-Options


Regards, Heiko


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

From hbraun at redhat.com  Tue Nov 11 04:52:52 2014
From: hbraun at redhat.com (Heiko Braun)
Date: Tue, 11 Nov 2014 10:52:52 +0100
Subject: [wildfly-dev] Map/Reduce proposal, next steps
Message-ID: <AAB35D0E-198B-41C4-8FBF-1C8061524375@redhat.com>



For the web console it would be really beneficial to include the map/reduce proposal in the next major release (Wildfly 9). Are there any objections if we move ahead prepare a PR that provides an additional top level operation with the functionality described in Haralds previous email?

>From my point of view it should well encapsulated in a distinct operation handler and thus I don't expect much side effects.

Regards, Heiko

From tomaz.cerar at gmail.com  Tue Nov 11 07:54:03 2014
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Tue, 11 Nov 2014 13:54:03 +0100
Subject: [wildfly-dev] Map/Reduce proposal, next steps
In-Reply-To: <AAB35D0E-198B-41C4-8FBF-1C8061524375@redhat.com>
References: <AAB35D0E-198B-41C4-8FBF-1C8061524375@redhat.com>
Message-ID: <CAMquZP5kB6vJUNdBV1WzRAyGDjk2MjzEm50BhUv3mD3VneDUyQ@mail.gmail.com>

On Tue, Nov 11, 2014 at 10:52 AM, Heiko Braun <hbraun at redhat.com> wrote:

> Are there any objections if we move ahead prepare a PR that provides an
> additional top level operation with the functionality described in Haralds
> previous email?


Sure, go ahead, just not sure what do you mean by top level operation? As
code in Harald's example was using client apis and not server side ones.
But beyond that it looks fine, we would probably just want to mark that
operation as private so it won't show by default in CLI.

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

From hbraun at redhat.com  Tue Nov 11 08:07:08 2014
From: hbraun at redhat.com (Heiko Braun)
Date: Tue, 11 Nov 2014 14:07:08 +0100
Subject: [wildfly-dev] Map/Reduce proposal, next steps
In-Reply-To: <CAMquZP5kB6vJUNdBV1WzRAyGDjk2MjzEm50BhUv3mD3VneDUyQ@mail.gmail.com>
References: <AAB35D0E-198B-41C4-8FBF-1C8061524375@redhat.com>
	<CAMquZP5kB6vJUNdBV1WzRAyGDjk2MjzEm50BhUv3mD3VneDUyQ@mail.gmail.com>
Message-ID: <AD8C38F3-1279-42B0-9C52-C6D1817F348A@redhat.com>

yes, but the code Harald demonstrated was intended to be used behind a root level dmr operation, meaning that we intend to register an operation handler with the root resource. similar to the "composite" operation handler.

On 11 Nov 2014, at 13:54, Toma? Cerar <tomaz.cerar at gmail.com> wrote:

> Sure, go ahead, just not sure what do you mean by top level operation? As code in Harald's example was using client apis and not server side ones.
> But beyond that it looks fine, we would probably just want to mark that operation as private so it won't show by default in CLI.

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

From tomaz.cerar at gmail.com  Tue Nov 11 08:19:42 2014
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Tue, 11 Nov 2014 14:19:42 +0100
Subject: [wildfly-dev] Map/Reduce proposal, next steps
In-Reply-To: <AD8C38F3-1279-42B0-9C52-C6D1817F348A@redhat.com>
References: <AAB35D0E-198B-41C4-8FBF-1C8061524375@redhat.com>
	<CAMquZP5kB6vJUNdBV1WzRAyGDjk2MjzEm50BhUv3mD3VneDUyQ@mail.gmail.com>
	<AD8C38F3-1279-42B0-9C52-C6D1817F348A@redhat.com>
Message-ID: <CAMquZP77-N6dB4-zTz=QMN1NzsE+eyhXM309N0gyF+dpKurtiQ@mail.gmail.com>

Sure, makes sense.

On Tue, Nov 11, 2014 at 2:07 PM, Heiko Braun <hbraun at redhat.com> wrote:

> yes, but the code Harald demonstrated was intended to be used behind a
> root level dmr operation, meaning that we intend to register an operation
> handler with the root resource. similar to the "composite" operation
> handler.
>
> On 11 Nov 2014, at 13:54, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
>
> Sure, go ahead, just not sure what do you mean by top level operation? As
> code in Harald's example was using client apis and not server side ones.
> But beyond that it looks fine, we would probably just want to mark that
> operation as private so it won't show by default in CLI.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141111/67c3607d/attachment.html 

From emuckenh at redhat.com  Tue Nov 11 11:14:05 2014
From: emuckenh at redhat.com (Emanuel Muckenhuber)
Date: Tue, 11 Nov 2014 17:14:05 +0100
Subject: [wildfly-dev] Map/Reduce proposal, next steps
In-Reply-To: <AAB35D0E-198B-41C4-8FBF-1C8061524375@redhat.com>
References: <AAB35D0E-198B-41C4-8FBF-1C8061524375@redhat.com>
Message-ID: <546235CD.4000206@redhat.com>

On 11/11/14 10:52, Heiko Braun wrote:
>
> For the web console it would be really beneficial to include the map/reduce proposal in the next major release (Wildfly 9). Are there any objections if we move ahead prepare a PR that provides an additional top level operation with the functionality described in Haralds previous email?
>
>>From my point of view it should well encapsulated in a distinct operation handler and thus I don't expect much side effects.
>

Since this came up last week i've been looking a bit into whether we can 
make wildcard operations working properly across processes. The main 
issue seems to be some details when we determine the operation routing 
in the domain.

I assume registering the operation at the root and passing the address 
as a separate parameter (not called address) is mainly necessary because 
of issues we are having executing composite operations targeting 
wildcards in the domain?

I need to do some more investigation, but maybe i can help you with some 
details getting this to work, so that the map/reduce operation would 
work similar to the read-resource operation. I guess this won't change 
too much of your work, it would however allow us to be more consistent 
with other operations and reuse the "address" param.


Emanuel

From hbraun at redhat.com  Tue Nov 11 12:09:26 2014
From: hbraun at redhat.com (Heiko Braun)
Date: Tue, 11 Nov 2014 18:09:26 +0100
Subject: [wildfly-dev] Map/Reduce proposal, next steps
In-Reply-To: <546235CD.4000206@redhat.com>
References: <AAB35D0E-198B-41C4-8FBF-1C8061524375@redhat.com>
	<546235CD.4000206@redhat.com>
Message-ID: <93333BA8-621A-4608-95B3-D61B840489DE@redhat.com>

Ok, i'll try to catch you on irc this week to discuss the next steps




> Am 11.11.2014 um 17:14 schrieb Emanuel Muckenhuber <emuckenh at redhat.com>:
> 
>> On 11/11/14 10:52, Heiko Braun wrote:
>> 
>> For the web console it would be really beneficial to include the map/reduce proposal in the next major release (Wildfly 9). Are there any objections if we move ahead prepare a PR that provides an additional top level operation with the functionality described in Haralds previous email?
>> 
>>> From my point of view it should well encapsulated in a distinct operation handler and thus I don't expect much side effects.
> 
> Since this came up last week i've been looking a bit into whether we can make wildcard operations working properly across processes. The main issue seems to be some details when we determine the operation routing in the domain.
> 
> I assume registering the operation at the root and passing the address as a separate parameter (not called address) is mainly necessary because of issues we are having executing composite operations targeting wildcards in the domain?
> 
> I need to do some more investigation, but maybe i can help you with some details getting this to work, so that the map/reduce operation would work similar to the read-resource operation. I guess this won't change too much of your work, it would however allow us to be more consistent with other operations and reuse the "address" param.
> 
> 
> Emanuel


From hbraun at redhat.com  Thu Nov 13 08:36:04 2014
From: hbraun at redhat.com (Heiko Braun)
Date: Thu, 13 Nov 2014 14:36:04 +0100
Subject: [wildfly-dev] Search Index: Call for help
Message-ID: <20C34684-F4C8-4C4A-B190-B613F43BB439@redhat.com>


We are looking for subject matter experts who help to improve the search in the console by providing reasonable keywords.

It takes you 2 minutes of your time. 

Here's how you can help:

1) Open the spreadsheet[1]. 
(The "token" represent a place in the user interface. 
The "resources" are the management model resources referenced by those places.)

2) Pick one or two rows that  are appealing to you
(i.e. a subsystem you know, a component you contributed to)

3) Provide 5 keywords that relate to the resources referenced by that token 
(i.e. "token=modcluster" => keywords={"load-balancing", "reverse-proxy", "clustering"})


Please put the keywords right into the spreadsheet.

Thanks for your help, Heiko


[1] https://docs.google.com/spreadsheets/d/12T-rty5AfrsxeT7FIUjcyHC1j4G_VHWBAp3FZm-l_58/edit#gid=0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141113/3ddb0afc/attachment.html 

From david.lloyd at redhat.com  Thu Nov 13 09:52:21 2014
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Thu, 13 Nov 2014 08:52:21 -0600
Subject: [wildfly-dev] Search Index: Call for help
In-Reply-To: <20C34684-F4C8-4C4A-B190-B613F43BB439@redhat.com>
References: <20C34684-F4C8-4C4A-B190-B613F43BB439@redhat.com>
Message-ID: <5464C5A5.7050509@redhat.com>

I added a few.

On 11/13/2014 07:36 AM, Heiko Braun wrote:
>
> We are looking for subject matter experts who help to improve the search
> in the console by providing reasonable keywords.
>
> _It takes you 2 minutes of your time_.
>
> Here's how you can help:
>
> 1) Open the spreadsheet[1].
> /(The "token" represent a place in the user interface. /
> /The "resources" are the management model resources referenced by those
> places.)/
>
> 2) Pick one or two rows that  are appealing to you
> /(i.e. a subsystem you know, a component you contributed to)/
>
> 3) Provide 5 keywords that relate to the resources referenced by that token
> /(i.e. "token=modcluster" => keywords={"load-balancing",
> "reverse-proxy", "clustering"})/
>
>
> Please put the keywords right into the spreadsheet.
>
> Thanks for your help, Heiko
>
>
> [1]
> https://docs.google.com/spreadsheets/d/12T-rty5AfrsxeT7FIUjcyHC1j4G_VHWBAp3FZm-l_58/edit#gid=0
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

-- 
- DML

From hbraun at redhat.com  Thu Nov 13 09:59:07 2014
From: hbraun at redhat.com (Heiko Braun)
Date: Thu, 13 Nov 2014 15:59:07 +0100
Subject: [wildfly-dev] Search Index: Call for help
In-Reply-To: <5464C5A5.7050509@redhat.com>
References: <20C34684-F4C8-4C4A-B190-B613F43BB439@redhat.com>
	<5464C5A5.7050509@redhat.com>
Message-ID: <E55263F6-9762-4DFB-BC0F-2417A9F3EC4E@redhat.com>

Thanks David.

On 13 Nov 2014, at 15:52, David M. Lloyd <david.lloyd at redhat.com> wrote:

> I added a few.
> 
> On 11/13/2014 07:36 AM, Heiko Braun wrote:
>> 
>> We are looking for subject matter experts who help to improve the search
>> in the console by providing reasonable keywords.
>> 
>> _It takes you 2 minutes of your time_.
>> 
>> Here's how you can help:
>> 
>> 1) Open the spreadsheet[1].
>> /(The "token" represent a place in the user interface. /
>> /The "resources" are the management model resources referenced by those
>> places.)/
>> 
>> 2) Pick one or two rows that  are appealing to you
>> /(i.e. a subsystem you know, a component you contributed to)/
>> 
>> 3) Provide 5 keywords that relate to the resources referenced by that token
>> /(i.e. "token=modcluster" => keywords={"load-balancing",
>> "reverse-proxy", "clustering"})/
>> 
>> 
>> Please put the keywords right into the spreadsheet.
>> 
>> Thanks for your help, Heiko
>> 
>> 
>> [1]
>> https://docs.google.com/spreadsheets/d/12T-rty5AfrsxeT7FIUjcyHC1j4G_VHWBAp3FZm-l_58/edit#gid=0
>> 
>> 
>> _______________________________________________
>> 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 hbraun at redhat.com  Thu Nov 13 10:06:16 2014
From: hbraun at redhat.com (Heiko Braun)
Date: Thu, 13 Nov 2014 16:06:16 +0100
Subject: [wildfly-dev] Search Index: Call for help
In-Reply-To: <5464C808.9090409@redhat.com>
References: <20C34684-F4C8-4C4A-B190-B613F43BB439@redhat.com>
	<5464C808.9090409@redhat.com>
Message-ID: <BAB11AAC-3FDB-4820-A225-33D21BAB1DCD@redhat.com>

That's a good point Scott.

The search is limited by the quality of the data inout we use for indexing. Currently the index is being created from the model descriptions and, the keywords. Although matching keywords have a higher priority when queries are executed.

The keywords are the cheap win for us. But in the long run the underlying model descriptions should be improved as well. These are often ambiguous or not very descriptive at all. 

/Heiko

On 13 Nov 2014, at 16:02, Scott Marlow <smarlow at redhat.com> wrote:

> For the jpa-metrics token, I propose that we change the description to reflect that these are metrics.  Before updating the spreadsheet, is there any reason why the description for jpa-metrics should be "The configuration of the JPA subsystem.;"
> 
> We can probably change all metrics tokens as well if we agree.  Perhaps to something like "The JPA metrics.;
> 
> On 11/13/2014 08:36 AM, Heiko Braun wrote:
>> 
>> We are looking for subject matter experts who help to improve the search
>> in the console by providing reasonable keywords.
>> 
>> _It takes you 2 minutes of your time_.
>> 
>> Here's how you can help:
>> 
>> 1) Open the spreadsheet[1].
>> /(The "token" represent a place in the user interface. /
>> /The "resources" are the management model resources referenced by those
>> places.)/
>> 
>> 2) Pick one or two rows that  are appealing to you
>> /(i.e. a subsystem you know, a component you contributed to)/
>> 
>> 3) Provide 5 keywords that relate to the resources referenced by that token
>> /(i.e. "token=modcluster" => keywords={"load-balancing",
>> "reverse-proxy", "clustering"})/
>> 
>> 
>> Please put the keywords right into the spreadsheet.
>> 
>> Thanks for your help, Heiko
>> 
>> 
>> [1]
>> https://docs.google.com/spreadsheets/d/12T-rty5AfrsxeT7FIUjcyHC1j4G_VHWBAp3FZm-l_58/edit#gid=0
>> 
>> 
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> 
> 



From smarlow at redhat.com  Thu Nov 13 10:02:32 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Thu, 13 Nov 2014 10:02:32 -0500
Subject: [wildfly-dev] Search Index: Call for help
In-Reply-To: <20C34684-F4C8-4C4A-B190-B613F43BB439@redhat.com>
References: <20C34684-F4C8-4C4A-B190-B613F43BB439@redhat.com>
Message-ID: <5464C808.9090409@redhat.com>

For the jpa-metrics token, I propose that we change the description to 
reflect that these are metrics.  Before updating the spreadsheet, is 
there any reason why the description for jpa-metrics should be "The 
configuration of the JPA subsystem.;"

We can probably change all metrics tokens as well if we agree.  Perhaps 
to something like "The JPA metrics.;

On 11/13/2014 08:36 AM, Heiko Braun wrote:
>
> We are looking for subject matter experts who help to improve the search
> in the console by providing reasonable keywords.
>
> _It takes you 2 minutes of your time_.
>
> Here's how you can help:
>
> 1) Open the spreadsheet[1].
> /(The "token" represent a place in the user interface. /
> /The "resources" are the management model resources referenced by those
> places.)/
>
> 2) Pick one or two rows that  are appealing to you
> /(i.e. a subsystem you know, a component you contributed to)/
>
> 3) Provide 5 keywords that relate to the resources referenced by that token
> /(i.e. "token=modcluster" => keywords={"load-balancing",
> "reverse-proxy", "clustering"})/
>
>
> Please put the keywords right into the spreadsheet.
>
> Thanks for your help, Heiko
>
>
> [1]
> https://docs.google.com/spreadsheets/d/12T-rty5AfrsxeT7FIUjcyHC1j4G_VHWBAp3FZm-l_58/edit#gid=0
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


From tomaz.cerar at gmail.com  Thu Nov 13 11:24:59 2014
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Thu, 13 Nov 2014 17:24:59 +0100
Subject: [wildfly-dev] Search Index: Call for help
In-Reply-To: <5464C808.9090409@redhat.com>
References: <20C34684-F4C8-4C4A-B190-B613F43BB439@redhat.com>
	<5464C808.9090409@redhat.com>
Message-ID: <CAMquZP7SUdZQ5tGeXVSpLBsBcNYLgPa93m+n1Df+Xfuy=4O15g@mail.gmail.com>

On Thu, Nov 13, 2014 at 4:02 PM, Scott Marlow <smarlow at redhat.com> wrote:

> is
> there any reason why the description for jpa-metrics should be "The
> configuration of the JPA subsystem.;"
>


Yes, this is defined in LocalDescription.properties file for each subsystem.
It is up to subsystem author to define best descriptions possible for the
model of the subsystem there.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141113/eda55865/attachment.html 

From ssilvert at redhat.com  Thu Nov 13 16:54:53 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 13 Nov 2014 16:54:53 -0500
Subject: [wildfly-dev] Subsystem for both EAP6/AS7 and WildFly?
Message-ID: <546528AD.8070402@redhat.com>

I'd like for my subsystem to run on both.

Any gotchas I should know about?

For those times when I need to know which platform I'm on, what is the 
best way to tell?

Stan

From tomaz.cerar at gmail.com  Thu Nov 13 17:23:04 2014
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Thu, 13 Nov 2014 23:23:04 +0100
Subject: [wildfly-dev] Subsystem for both EAP6/AS7 and WildFly?
In-Reply-To: <546528AD.8070402@redhat.com>
References: <546528AD.8070402@redhat.com>
Message-ID: <CAMquZP4gVDkRQ4mNRM5gCMmTw4zgO6WeD0phO+Udnw8v0c41Sw@mail.gmail.com>

On Thu, Nov 13, 2014 at 10:54 PM, Stan Silvert <ssilvert at redhat.com> wrote:

> Any gotchas I should know about?
>


As long as you use APIs that are present in older version of the two you
will be fine.

As for version goes, take a look at

org.jboss.as.version.Version & org.jboss.as.version.ProductConfig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141113/4ef7e2fe/attachment.html 

From claudio at claudius.com.br  Thu Nov 13 20:51:44 2014
From: claudio at claudius.com.br (Claudio Miranda)
Date: Thu, 13 Nov 2014 23:51:44 -0200
Subject: [wildfly-dev] how subsystem can copy resources from DC to HC
Message-ID: <CALbD--p-n42BNQzcfQZ1tLhX0XYmwq=MK1dZXGadOBsPDLWpug@mail.gmail.com>

Hi, is there a way (API) where a resource file on DC can be copied to HC ?
Something like a subsystem needs to use a jks file, and when a new HC
is started, if the jks file is not there, the subsystem should copy
the file from DC to HC. Also, any subsystem write operation to this
resource file is modified on DC, then copied over to HCs.

Thanks
-- 
  Claudio Miranda

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

From claudio at claudius.com.br  Fri Nov 14 11:24:21 2014
From: claudio at claudius.com.br (Claudio Miranda)
Date: Fri, 14 Nov 2014 14:24:21 -0200
Subject: [wildfly-dev] WFLY-3512 - disable datasource undeploy
	application
Message-ID: <CALbD--qEzyPHO3qDDEL+wi3DMe4bGep883eajn4qNOWnfUi15Q@mail.gmail.com>

The behavior I could see, when user disables the datasource,
- the application is disabled,
- then the datasource is disabled,
- there is an error (DataSourceStatisticsListener at 53450cac" failed:
java.lang.IllegalArgumentException: WFLYCTL0218: A node is already
registered at '(subsystem => datasources)(data-source =>
ExampleDS)(statistics => jdbc)')
- the datasource is enabled
- then the application is enabled

Is this the expected behavior ?
User must be aware that disabling a datasource will put the
application in disabled status.

On 10/27/14, 11:27:55 AM, Brian Stansberry wrote:
> The datasource subsystem shouldn't need to know that kind of
> information. When the operation rolls back it should restore the
> services it removed, and MSC will take care of bringing back up whatever
> services were stopped when the DS services were removed.
>
> This needs fixing:
>
> https://github.com/wildfly/wildfly/blob/master/connector/src/main/java/org/jboss/as/connector/subsystems/datasources/AbstractDataSourceRemove.java#L111
>
> On 10/25/14, 7:33 AM, Claudio Miranda wrote:
> > Hi, related to WFLY-3512, disable a datasource used by some
> > application, undeploy the application, tested in 8.1 and 9.0 snapshot.
> >
> > I saw that org.jboss.as.connector.subsystems.datasources.DataSourceDisable
> > (connector module) is called, but there is no previous check about
> > deployments that uses it.
> > How can datasource subsystem get to know the deployment dependencies
> > for resources (datasource and resource adapter) ?
> > Is there a listener mechanism where datasource subsystem can listen to
> > deploy enablement, and check the resources dependencies ? This way,
> > datasource subsystem can have a lista of dependency and check it
> > before disable/remove of datasources.
> >
> > 1. https://issues.jboss.org/browse/WFLY-3512





-- 
  Claudio Miranda

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

From brian.stansberry at redhat.com  Fri Nov 14 18:30:48 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Fri, 14 Nov 2014 17:30:48 -0600
Subject: [wildfly-dev] WFLY-3512 - disable datasource undeploy
	application
In-Reply-To: <CALbD--qEzyPHO3qDDEL+wi3DMe4bGep883eajn4qNOWnfUi15Q@mail.gmail.com>
References: <CALbD--qEzyPHO3qDDEL+wi3DMe4bGep883eajn4qNOWnfUi15Q@mail.gmail.com>
Message-ID: <546690A8.6030808@redhat.com>

On 11/14/14, 10:24 AM, Claudio Miranda wrote:
> The behavior I could see, when user disables the datasource,
> - the application is disabled,
> - then the datasource is disabled,
> - there is an error (DataSourceStatisticsListener at 53450cac" failed:
> java.lang.IllegalArgumentException: WFLYCTL0218: A node is already
> registered at '(subsystem => datasources)(data-source =>
> ExampleDS)(statistics => jdbc)')
> - the datasource is enabled
> - then the application is enabled
>
> Is this the expected behavior ?

The error is not expected. Everything else is.

The re-enabling of the ds and app is a result of the server 
automatically rolling back the operation when the server detects that 
the operation has introduced a missing service dependency. I believe the 
error is a problem occurring during rollback.

> User must be aware that disabling a datasource will put the
> application in disabled status.
>

If the user does not include the allow-resource-service-restart=true 
operation header, the operation should simply change the config, put the 
server into reload-required state and not affect the runtime datasource 
service or the application.

If in addition to allow-resource-service-restart=true the user also 
includes operation header rollback-on-runtime-failure=false, then the 
datasource and the application should remain disabled in the runtime.

If you then execute the "enable" op on the ds, the application should 
come back up.

If you restart/reload the server before enabling the ds, you'll get boot 
failures due to the app needing the unavailable ds.

[1] 
https://docs.jboss.org/author/display/WFLY9/Admin+Guide#AdminGuide-OperationHeaders

> On 10/27/14, 11:27:55 AM, Brian Stansberry wrote:
>> The datasource subsystem shouldn't need to know that kind of
>> information. When the operation rolls back it should restore the
>> services it removed, and MSC will take care of bringing back up whatever
>> services were stopped when the DS services were removed.
>>
>> This needs fixing:
>>
>> https://github.com/wildfly/wildfly/blob/master/connector/src/main/java/org/jboss/as/connector/subsystems/datasources/AbstractDataSourceRemove.java#L111
>>
>> On 10/25/14, 7:33 AM, Claudio Miranda wrote:
>>> Hi, related to WFLY-3512, disable a datasource used by some
>>> application, undeploy the application, tested in 8.1 and 9.0 snapshot.
>>>
>>> I saw that org.jboss.as.connector.subsystems.datasources.DataSourceDisable
>>> (connector module) is called, but there is no previous check about
>>> deployments that uses it.
>>> How can datasource subsystem get to know the deployment dependencies
>>> for resources (datasource and resource adapter) ?
>>> Is there a listener mechanism where datasource subsystem can listen to
>>> deploy enablement, and check the resources dependencies ? This way,
>>> datasource subsystem can have a lista of dependency and check it
>>> before disable/remove of datasources.
>>>
>>> 1. https://issues.jboss.org/browse/WFLY-3512
>
>
>
>
>


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

From linux at dreamofjapan.de  Mon Nov 17 03:40:50 2014
From: linux at dreamofjapan.de (Test-Notebook)
Date: Mon, 17 Nov 2014 09:40:50 +0100
Subject: [wildfly-dev] Need help with "JBAS012005: Failed to send
 authentication key to process"
Message-ID: <1416213650.3775.6.camel@Testhost>

Dear Ladies and Gentlemen

I have in my test installation of WildFly an error. But I can not
explain the cause. In the log I get the following error message.

<log>
2014-11-14 16:59:58,978 INFO  [org.jboss.modules] (main) JBoss Modules
version 1.3.3.Final
2014-11-14 16:59:59,144 INFO  [org.jboss.as.process.Host
Controller.status] (main) JBAS012017: Starting process 'Host Controller'
2014-11-14 17:00:06,117 INFO
[org.jboss.as.process.Server:testserver.status]
(ProcessController-threads - 3) JBAS012017: Starting process
'Server:testserver'
2014-11-14 17:00:06,126 WARN
[org.jboss.as.process.Server:testserver.status]
(ProcessController-threads - 3) JBAS012005: Failed to send
authentication key to process 'Server:testserver': java.io.IOException:
Stream closed
2014-11-14 17:00:06,128 INFO
[org.jboss.as.process.Server:testserver.status] (reaper for
Server:testserver) JBAS012010: Process 'Server:testserver' finished with
an exit status of 1
2014-11-14 17:00:06,304 INFO
[org.jboss.as.process.Server:testserver2.status]
(ProcessController-threads - 3) JBAS012017: Starting process
'Server:testserver2'
2014-11-14 17:00:06,311 WARN
[org.jboss.as.process.Server:testserver2.status]
(ProcessController-threads - 3) JBAS012005: Failed to send
authentication key to process 'Server:testserver2': java.io.IOException:
Stream closed
2014-11-14 17:00:06,312 INFO
[org.jboss.as.process.Server:testserver2.status] (reaper for
Server:testserver2) JBAS012010: Process 'Server:testserver2' finished
with an exit status of 1
</log>

My application does not run after this error. My question is, where I
made a mistake or did I found a bug?

Thanks in advance and greetings from Germany
Frank


From rory.odonnell at oracle.com  Mon Nov 17 09:08:58 2014
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Mon, 17 Nov 2014 14:08:58 +0000
Subject: [wildfly-dev] Jigsaw early-access builds updated (build 38)
Message-ID: <546A017A.8020304@oracle.com>


Hi Jason/Tomaz,

JDK 9 Early Access with Project Jigsaw build b38 is available on 
java.net [1]

The goal of Project Jigsaw [2] is to design and implement a standard module
system for the Java SE Platform, and to apply that system to the 
Platform itself
and to the JDK.

The early-access builds implement the changes described in JEP 220 [3] . 
The
jrt file-system provider is not yet implemented.  As of build 38, the 
extension
mechanism has been removed.

Please refer to Project Jigsaw's updated project pages [2] & [4] and 
Mark Reinhold's
update [5] for further details.

We are very interested in your experiences testing this build. Comments, 
questions,
and suggestions are welcome on the jigsaw-dev 
<http://mail.openjdk.java.net/mailman/listinfo/jigsaw-dev> mailing list 
or through bug reports
via bugs.java.com <http://bugs.java.com/>.

Note: If you haven?t already subscribed to that mailing list then please 
do so first,
otherwise your message will be discarded as spam.

Rgds, Rory


[1] https://jdk9.java.net/jigsaw/
[2] http://openjdk.java.net/projects/jigsaw/
[3] http://openjdk.java.net/jeps/220
[4] http://openjdk.java.net/projects/jigsaw/ea
[5] 
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2014-November/003946.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/20141117/0789fd08/attachment.html 

From darran.lofthouse at jboss.com  Mon Nov 17 12:03:29 2014
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Mon, 17 Nov 2014 17:03:29 +0000
Subject: [wildfly-dev] Need help with "JBAS012005: Failed to send
 authentication key to process"
In-Reply-To: <1416213650.3775.6.camel@Testhost>
References: <1416213650.3775.6.camel@Testhost>
Message-ID: <546A2A61.4070802@jboss.com>

If possible can you please raise a Jira under WFCORE with the 
configuration that is failing (feel free to sanitise the sensitive 
stuff) - looking at the error I believe you have a ':' in your server 
name, wondering if that could be triggering it.

On 17/11/14 08:40, Test-Notebook wrote:
> Dear Ladies and Gentlemen
>
> I have in my test installation of WildFly an error. But I can not
> explain the cause. In the log I get the following error message.
>
> <log>
> 2014-11-14 16:59:58,978 INFO  [org.jboss.modules] (main) JBoss Modules
> version 1.3.3.Final
> 2014-11-14 16:59:59,144 INFO  [org.jboss.as.process.Host
> Controller.status] (main) JBAS012017: Starting process 'Host Controller'
> 2014-11-14 17:00:06,117 INFO
> [org.jboss.as.process.Server:testserver.status]
> (ProcessController-threads - 3) JBAS012017: Starting process
> 'Server:testserver'
> 2014-11-14 17:00:06,126 WARN
> [org.jboss.as.process.Server:testserver.status]
> (ProcessController-threads - 3) JBAS012005: Failed to send
> authentication key to process 'Server:testserver': java.io.IOException:
> Stream closed
> 2014-11-14 17:00:06,128 INFO
> [org.jboss.as.process.Server:testserver.status] (reaper for
> Server:testserver) JBAS012010: Process 'Server:testserver' finished with
> an exit status of 1
> 2014-11-14 17:00:06,304 INFO
> [org.jboss.as.process.Server:testserver2.status]
> (ProcessController-threads - 3) JBAS012017: Starting process
> 'Server:testserver2'
> 2014-11-14 17:00:06,311 WARN
> [org.jboss.as.process.Server:testserver2.status]
> (ProcessController-threads - 3) JBAS012005: Failed to send
> authentication key to process 'Server:testserver2': java.io.IOException:
> Stream closed
> 2014-11-14 17:00:06,312 INFO
> [org.jboss.as.process.Server:testserver2.status] (reaper for
> Server:testserver2) JBAS012010: Process 'Server:testserver2' finished
> with an exit status of 1
> </log>
>
> My application does not run after this error. My question is, where I
> made a mistake or did I found a bug?
>
> Thanks in advance and greetings from Germany
> Frank
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From brian.stansberry at redhat.com  Mon Nov 17 13:05:31 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 17 Nov 2014 12:05:31 -0600
Subject: [wildfly-dev] Need help with "JBAS012005: Failed to send
 authentication key to process"
In-Reply-To: <546A2A61.4070802@jboss.com>
References: <1416213650.3775.6.camel@Testhost> <546A2A61.4070802@jboss.com>
Message-ID: <546A38EB.9060301@redhat.com>

Regarding the ":", a message like "JBAS012017: Starting process 
'Server:testserver'" is normal from the Process Controller. The name of 
the server is "testserver". The preceding "Server:" is added by the PC 
to discriminate server processes from HostController processes, as the 
PC manages both.

On 11/17/14, 11:03 AM, Darran Lofthouse wrote:
> If possible can you please raise a Jira under WFCORE with the
> configuration that is failing (feel free to sanitise the sensitive
> stuff) - looking at the error I believe you have a ':' in your server
> name, wondering if that could be triggering it.
>
> On 17/11/14 08:40, Test-Notebook wrote:
>> Dear Ladies and Gentlemen
>>
>> I have in my test installation of WildFly an error. But I can not
>> explain the cause. In the log I get the following error message.
>>
>> <log>
>> 2014-11-14 16:59:58,978 INFO  [org.jboss.modules] (main) JBoss Modules
>> version 1.3.3.Final
>> 2014-11-14 16:59:59,144 INFO  [org.jboss.as.process.Host
>> Controller.status] (main) JBAS012017: Starting process 'Host Controller'
>> 2014-11-14 17:00:06,117 INFO
>> [org.jboss.as.process.Server:testserver.status]
>> (ProcessController-threads - 3) JBAS012017: Starting process
>> 'Server:testserver'
>> 2014-11-14 17:00:06,126 WARN
>> [org.jboss.as.process.Server:testserver.status]
>> (ProcessController-threads - 3) JBAS012005: Failed to send
>> authentication key to process 'Server:testserver': java.io.IOException:
>> Stream closed
>> 2014-11-14 17:00:06,128 INFO
>> [org.jboss.as.process.Server:testserver.status] (reaper for
>> Server:testserver) JBAS012010: Process 'Server:testserver' finished with
>> an exit status of 1
>> 2014-11-14 17:00:06,304 INFO
>> [org.jboss.as.process.Server:testserver2.status]
>> (ProcessController-threads - 3) JBAS012017: Starting process
>> 'Server:testserver2'
>> 2014-11-14 17:00:06,311 WARN
>> [org.jboss.as.process.Server:testserver2.status]
>> (ProcessController-threads - 3) JBAS012005: Failed to send
>> authentication key to process 'Server:testserver2': java.io.IOException:
>> Stream closed
>> 2014-11-14 17:00:06,312 INFO
>> [org.jboss.as.process.Server:testserver2.status] (reaper for
>> Server:testserver2) JBAS012010: Process 'Server:testserver2' finished
>> with an exit status of 1
>> </log>
>>
>> My application does not run after this error. My question is, where I
>> made a mistake or did I found a bug?
>>
>> Thanks in advance and greetings from Germany
>> Frank
>>
>> _______________________________________________
>> 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 brian.stansberry at redhat.com  Mon Nov 17 15:39:39 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 17 Nov 2014 14:39:39 -0600
Subject: [wildfly-dev] how subsystem can copy resources from DC to HC
In-Reply-To: <CALbD--p-n42BNQzcfQZ1tLhX0XYmwq=MK1dZXGadOBsPDLWpug@mail.gmail.com>
References: <CALbD--p-n42BNQzcfQZ1tLhX0XYmwq=MK1dZXGadOBsPDLWpug@mail.gmail.com>
Message-ID: <546A5D0B.8080507@redhat.com>

No, there is no such facility. We've talked about doing things similar 
to that, but there's no such facility that's currently usable.

On 11/13/14, 7:51 PM, Claudio Miranda wrote:
> Hi, is there a way (API) where a resource file on DC can be copied to HC ?
> Something like a subsystem needs to use a jks file, and when a new HC
> is started, if the jks file is not there, the subsystem should copy
> the file from DC to HC. Also, any subsystem write operation to this
> resource file is modified on DC, then copied over to HCs.
>
> Thanks
>


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

From linux at dreamofjapan.de  Tue Nov 18 02:26:36 2014
From: linux at dreamofjapan.de (Test-Notebook)
Date: Tue, 18 Nov 2014 08:26:36 +0100
Subject: [wildfly-dev] Need help with "JBAS012005: Failed to send
 authentication key to process"
In-Reply-To: <546A38EB.9060301@redhat.com>
References: <1416213650.3775.6.camel@Testhost> <546A2A61.4070802@jboss.com>
	<546A38EB.9060301@redhat.com>
Message-ID: <1416295596.3775.15.camel@Testhost>

Dear Ladies and Gentlemen

for operational purposes, we are not allowed to send the configuration
files. We now looking for things we can check to isolate the error. Can
there be for example a faulty Web application archives?

Our WildFly running in domain mode, with only one domain. In the debug
log, no exact error is shown.

It would also be interesting to know which checks the Host Controller
performs at the start, in order to better determine the problem.

Thanks in advance and greetings from Germany
Frank


Am Montag, den 17.11.2014, 12:05 -0600 schrieb Brian Stansberry: 
> Regarding the ":", a message like "JBAS012017: Starting process 
> 'Server:testserver'" is normal from the Process Controller. The name of 
> the server is "testserver". The preceding "Server:" is added by the PC 
> to discriminate server processes from HostController processes, as the 
> PC manages both.
> 
> On 11/17/14, 11:03 AM, Darran Lofthouse wrote:
> > If possible can you please raise a Jira under WFCORE with the
> > configuration that is failing (feel free to sanitise the sensitive
> > stuff) - looking at the error I believe you have a ':' in your server
> > name, wondering if that could be triggering it.
> >
> > On 17/11/14 08:40, Test-Notebook wrote:
> >> Dear Ladies and Gentlemen
> >>
> >> I have in my test installation of WildFly an error. But I can not
> >> explain the cause. In the log I get the following error message.
> >>
> >> <log>
> >> 2014-11-14 16:59:58,978 INFO  [org.jboss.modules] (main) JBoss Modules
> >> version 1.3.3.Final
> >> 2014-11-14 16:59:59,144 INFO  [org.jboss.as.process.Host
> >> Controller.status] (main) JBAS012017: Starting process 'Host Controller'
> >> 2014-11-14 17:00:06,117 INFO
> >> [org.jboss.as.process.Server:testserver.status]
> >> (ProcessController-threads - 3) JBAS012017: Starting process
> >> 'Server:testserver'
> >> 2014-11-14 17:00:06,126 WARN
> >> [org.jboss.as.process.Server:testserver.status]
> >> (ProcessController-threads - 3) JBAS012005: Failed to send
> >> authentication key to process 'Server:testserver': java.io.IOException:
> >> Stream closed
> >> 2014-11-14 17:00:06,128 INFO
> >> [org.jboss.as.process.Server:testserver.status] (reaper for
> >> Server:testserver) JBAS012010: Process 'Server:testserver' finished with
> >> an exit status of 1
> >> 2014-11-14 17:00:06,304 INFO
> >> [org.jboss.as.process.Server:testserver2.status]
> >> (ProcessController-threads - 3) JBAS012017: Starting process
> >> 'Server:testserver2'
> >> 2014-11-14 17:00:06,311 WARN
> >> [org.jboss.as.process.Server:testserver2.status]
> >> (ProcessController-threads - 3) JBAS012005: Failed to send
> >> authentication key to process 'Server:testserver2': java.io.IOException:
> >> Stream closed
> >> 2014-11-14 17:00:06,312 INFO
> >> [org.jboss.as.process.Server:testserver2.status] (reaper for
> >> Server:testserver2) JBAS012010: Process 'Server:testserver2' finished
> >> with an exit status of 1
> >> </log>
> >>
> >> My application does not run after this error. My question is, where I
> >> made a mistake or did I found a bug?
> >>
> >> Thanks in advance and greetings from Germany
> >> Frank
> >>
> >> _______________________________________________
> >> wildfly-dev mailing list
> >> wildfly-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> 
> 



From darran.lofthouse at jboss.com  Tue Nov 18 05:19:31 2014
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Tue, 18 Nov 2014 10:19:31 +0000
Subject: [wildfly-dev] WildFly Core 1.0.0.Alpha14
Message-ID: <546B1D33.8020003@jboss.com>

Can someone please create the version 1.0.0.Alpha14 in Jira for WFCORE?

At the moment we have PRs being merged but the corresponding Jira issues 
can not be closed as we do not have the correct version available?

Or maybe I am missing something, have we moved onto Beta1?

Regards,
Darran Lofthouse.

From david.lloyd at redhat.com  Tue Nov 18 08:53:04 2014
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Tue, 18 Nov 2014 07:53:04 -0600
Subject: [wildfly-dev] WildFly Core 1.0.0.Alpha14
In-Reply-To: <546B1D33.8020003@jboss.com>
References: <546B1D33.8020003@jboss.com>
Message-ID: <546B4F40.3040507@redhat.com>

My mistake, sorry.

On 11/18/2014 04:19 AM, Darran Lofthouse wrote:
> Can someone please create the version 1.0.0.Alpha14 in Jira for WFCORE?
>
> At the moment we have PRs being merged but the corresponding Jira issues
> can not be closed as we do not have the correct version available?
>
> Or maybe I am missing something, have we moved onto Beta1?
>
> Regards,
> Darran Lofthouse.
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

-- 
- DML

From darran.lofthouse at jboss.com  Tue Nov 18 11:44:13 2014
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Tue, 18 Nov 2014 16:44:13 +0000
Subject: [wildfly-dev] WildFly Core 1.0.0.Alpha14
In-Reply-To: <546B4F40.3040507@redhat.com>
References: <546B1D33.8020003@jboss.com> <546B4F40.3040507@redhat.com>
Message-ID: <546B775D.3090400@jboss.com>

Thanks David

On 18/11/14 13:53, David M. Lloyd wrote:
> My mistake, sorry.
>
> On 11/18/2014 04:19 AM, Darran Lofthouse wrote:
>> Can someone please create the version 1.0.0.Alpha14 in Jira for WFCORE?
>>
>> At the moment we have PRs being merged but the corresponding Jira issues
>> can not be closed as we do not have the correct version available?
>>
>> Or maybe I am missing something, have we moved onto Beta1?
>>
>> Regards,
>> Darran Lofthouse.
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>

From claudio at claudius.com.br  Tue Nov 18 12:18:04 2014
From: claudio at claudius.com.br (Claudio Miranda)
Date: Tue, 18 Nov 2014 15:18:04 -0200
Subject: [wildfly-dev] how subsystem can copy resources from DC to HC
In-Reply-To: <546A5D0B.8080507@redhat.com>
References: <CALbD--p-n42BNQzcfQZ1tLhX0XYmwq=MK1dZXGadOBsPDLWpug@mail.gmail.com>
	<546A5D0B.8080507@redhat.com>
Message-ID: <CALbD--ov8g8Si1DQtq=4P23sCQyaE1wqHbwexqf6Pb8C7mzUQw@mail.gmail.com>

On Mon, Nov 17, 2014 at 6:39 PM, Brian Stansberry
<brian.stansberry at redhat.com> wrote:
> No, there is no such facility. We've talked about doing things similar
> to that, but there's no such facility that's currently usable.

That would be very useful for subsystems that wants to add
functionality, that needs copy resources over to slaves.
Is it planned for 9.0 ?


-- 
  Claudio Miranda

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

From brian.stansberry at redhat.com  Tue Nov 18 14:37:45 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 18 Nov 2014 13:37:45 -0600
Subject: [wildfly-dev] how subsystem can copy resources from DC to HC
In-Reply-To: <CALbD--ov8g8Si1DQtq=4P23sCQyaE1wqHbwexqf6Pb8C7mzUQw@mail.gmail.com>
References: <CALbD--p-n42BNQzcfQZ1tLhX0XYmwq=MK1dZXGadOBsPDLWpug@mail.gmail.com>
	<546A5D0B.8080507@redhat.com>
	<CALbD--ov8g8Si1DQtq=4P23sCQyaE1wqHbwexqf6Pb8C7mzUQw@mail.gmail.com>
Message-ID: <546BA009.7090002@redhat.com>

On 11/18/14, 11:18 AM, Claudio Miranda wrote:
> On Mon, Nov 17, 2014 at 6:39 PM, Brian Stansberry
> <brian.stansberry at redhat.com> wrote:
>> No, there is no such facility. We've talked about doing things similar
>> to that, but there's no such facility that's currently usable.
>
> That would be very useful for subsystems that wants to add
> functionality, that needs copy resources over to slaves.
> Is it planned for 9.0 ?
>

It would be useful, although there are a lot of implications to copying 
things like keystores around. It's not on the WF 9 roadmap though.


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

From jason.greene at redhat.com  Fri Nov 21 02:00:36 2014
From: jason.greene at redhat.com (Jason Greene)
Date: Fri, 21 Nov 2014 01:00:36 -0600
Subject: [wildfly-dev] WildFly 8.2.0.Final is released!
Message-ID: <B8DD00B3-C4CB-4E12-B758-D9C773FB806E@redhat.com>

http://wildfly.org/news/2014/11/20/WildFly82-Final-Released/

Thank you everyone for going the extra mile on this release! I was blown away (again) by your tenacity!

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



From jai.forums2013 at gmail.com  Fri Nov 21 02:01:52 2014
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Fri, 21 Nov 2014 12:31:52 +0530
Subject: [wildfly-dev] WildFly 8.2.0.Final is released!
In-Reply-To: <B8DD00B3-C4CB-4E12-B758-D9C773FB806E@redhat.com>
References: <B8DD00B3-C4CB-4E12-B758-D9C773FB806E@redhat.com>
Message-ID: <546EE360.6040202@gmail.com>

Congratulations everyone!

-Jaikiran
On Friday 21 November 2014 12:30 PM, Jason Greene wrote:
> http://wildfly.org/news/2014/11/20/WildFly82-Final-Released/
>
> Thank you everyone for going the extra mile on this release! I was blown away (again) by your tenacity!
>
> --
> 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 pxntium at gmail.com  Fri Nov 21 02:07:19 2014
From: pxntium at gmail.com (=?UTF-8?Q?Francisco_Mart=C3=ADnez?=)
Date: Fri, 21 Nov 2014 08:07:19 +0100
Subject: [wildfly-dev] WildFly 8.2.0.Final is released!
In-Reply-To: <B8DD00B3-C4CB-4E12-B758-D9C773FB806E@redhat.com>
References: <B8DD00B3-C4CB-4E12-B758-D9C773FB806E@redhat.com>
Message-ID: <CAE9-Q_tkh5p6ut_Xy8EsHKc1AEg=DCoDou3=-Sf9GA_PXzX4ig@mail.gmail.com>

Good news and gr8 job!
Congratulations!!

Fran
 El 21/11/2014 08:00, "Jason Greene" <jason.greene at redhat.com> escribi?:

> http://wildfly.org/news/2014/11/20/WildFly82-Final-Released/
>
> Thank you everyone for going the extra mile on this release! I was blown
> away (again) by your tenacity!
>
> --
> 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/20141121/5d732f3c/attachment.html 

From hrupp at redhat.com  Fri Nov 21 02:37:13 2014
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 21 Nov 2014 08:37:13 +0100
Subject: [wildfly-dev] WildFly 8.2.0.Final is released!
In-Reply-To: <B8DD00B3-C4CB-4E12-B758-D9C773FB806E@redhat.com>
References: <B8DD00B3-C4CB-4E12-B758-D9C773FB806E@redhat.com>
Message-ID: <9030B831-5C56-41CD-946D-BCF61CCB50EA@redhat.com>


> Am 21.11.2014 um 08:00 schrieb Jason Greene <jason.greene at redhat.com>:
> 
> http://wildfly.org/news/2014/11/20/WildFly82-Final-Released/

Veery good. Congratulations to everyone involved.

  Heiko


From luis.m.costa at gmail.com  Fri Nov 21 03:07:18 2014
From: luis.m.costa at gmail.com (=?UTF-8?B?THXDrXMgTS4gQ29zdGE=?=)
Date: Fri, 21 Nov 2014 08:07:18 +0000
Subject: [wildfly-dev] Fw:  WildFly 8.2.0.Final is released!
In-Reply-To: <B8DD00B3-C4CB-4E12-B758-D9C773FB806E@redhat.com>
References: <B8DD00B3-C4CB-4E12-B758-D9C773FB806E@redhat.com>
Message-ID: <CAPLBHR7ofEnx4cXxDdk+ZMnV_87pHKWNUAJjD2CcFaHAi2ZCgw@mail.gmail.com>

Viva!

Curiosamente ainda ontem fui ao roadmap do wildfly e pensei: "fixe j?
faltam menos de 20 issues". E agora temos release...

Se calhar pe?o ao Paulo para explorar isto enquanto a monitoriza??o n?o ?
mais detalhada - mas j? est? mto mais clara...

At? j?,
  Lu?s

Em 21/11/2014 07:00, "Jason Greene" <jason.greene at redhat.com> escreveu:
>
> http://wildfly.org/news/2014/11/20/WildFly82-Final-Released/
>
> Thank you everyone for going the extra mile on this release! I was blown
away (again) by your tenacity!
>
> --
> 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/20141121/dd0d4208/attachment.html 

From lfugaro at redhat.com  Fri Nov 21 06:37:26 2014
From: lfugaro at redhat.com (Luigi Fugaro)
Date: Fri, 21 Nov 2014 12:37:26 +0100
Subject: [wildfly-dev] WildFly 8.2.0.Final is released!
In-Reply-To: <CAPLBHR7ofEnx4cXxDdk+ZMnV_87pHKWNUAJjD2CcFaHAi2ZCgw@mail.gmail.com>
References: <B8DD00B3-C4CB-4E12-B758-D9C773FB806E@redhat.com>
	<CAPLBHR7ofEnx4cXxDdk+ZMnV_87pHKWNUAJjD2CcFaHAi2ZCgw@mail.gmail.com>
Message-ID: <2866F677-AFFA-4D95-810F-FF22B08A6340@redhat.com>

Claro que si!

> On 21 Nov 2014, at 09:07, Lu?s M. Costa <luis.m.costa at gmail.com> wrote:
> 
> Viva!
> 
> Curiosamente ainda ontem fui ao roadmap do wildfly e pensei: "fixe j? faltam menos de 20 issues". E agora temos release...
> 
> Se calhar pe?o ao Paulo para explorar isto enquanto a monitoriza??o n?o ? mais detalhada - mas j? est? mto mais clara...
> 
> At? j?,
>   Lu?s
> 
> 
> Em 21/11/2014 07:00, "Jason Greene" <jason.greene at redhat.com <mailto:jason.greene at redhat.com>> escreveu:
> >
> > http://wildfly.org/news/2014/11/20/WildFly82-Final-Released/ <http://wildfly.org/news/2014/11/20/WildFly82-Final-Released/>
> >
> > Thank you everyone for going the extra mile on this release! I was blown away (again) by your tenacity!
> >
> > --
> > 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 <mailto:wildfly-dev at lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

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

From luis.m.costa at gmail.com  Fri Nov 21 06:43:51 2014
From: luis.m.costa at gmail.com (=?UTF-8?B?THXDrXMgTS4gQ29zdGE=?=)
Date: Fri, 21 Nov 2014 11:43:51 +0000
Subject: [wildfly-dev] WildFly 8.2.0.Final is released!
In-Reply-To: <2866F677-AFFA-4D95-810F-FF22B08A6340@redhat.com>
References: <B8DD00B3-C4CB-4E12-B758-D9C773FB806E@redhat.com>
	<CAPLBHR7ofEnx4cXxDdk+ZMnV_87pHKWNUAJjD2CcFaHAi2ZCgw@mail.gmail.com>
	<2866F677-AFFA-4D95-810F-FF22B08A6340@redhat.com>
Message-ID: <CAPLBHR5ypd60iiQL5=Fors8sEO8_i9QGUMdR2KqAgNbcT9CvJw@mail.gmail.com>

It seems there was a glitch with my client email, and a forward became a
forward and reply... I'm very sorry for that.

But, as you may see, if you translate my original message, we are going to
evaluate it wright way - it is already being done.

Congratulations on the new release! :-)

Lu?s

2014-11-21 11:37 GMT+00:00 Luigi Fugaro <lfugaro at redhat.com>:

> Claro que si!
>
> On 21 Nov 2014, at 09:07, Lu?s M. Costa <luis.m.costa at gmail.com> wrote:
>
> Viva!
>
> Curiosamente ainda ontem fui ao roadmap do wildfly e pensei: "fixe j?
> faltam menos de 20 issues". E agora temos release...
>
> Se calhar pe?o ao Paulo para explorar isto enquanto a monitoriza??o n?o ?
> mais detalhada - mas j? est? mto mais clara...
>
> At? j?,
>   Lu?s
>
> Em 21/11/2014 07:00, "Jason Greene" <jason.greene at redhat.com> escreveu:
> >
> > http://wildfly.org/news/2014/11/20/WildFly82-Final-Released/
> >
> > Thank you everyone for going the extra mile on this release! I was blown
> away (again) by your tenacity!
> >
> > --
> > 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141121/fafa8085/attachment-0001.html 

From arjan.tijms at gmail.com  Fri Nov 21 07:14:50 2014
From: arjan.tijms at gmail.com (arjan tijms)
Date: Fri, 21 Nov 2014 13:14:50 +0100
Subject: [wildfly-dev] WildFly 8.2.0.Final is released!
In-Reply-To: <CAPLBHR5ypd60iiQL5=Fors8sEO8_i9QGUMdR2KqAgNbcT9CvJw@mail.gmail.com>
References: <B8DD00B3-C4CB-4E12-B758-D9C773FB806E@redhat.com>
	<CAPLBHR7ofEnx4cXxDdk+ZMnV_87pHKWNUAJjD2CcFaHAi2ZCgw@mail.gmail.com>
	<2866F677-AFFA-4D95-810F-FF22B08A6340@redhat.com>
	<CAPLBHR5ypd60iiQL5=Fors8sEO8_i9QGUMdR2KqAgNbcT9CvJw@mail.gmail.com>
Message-ID: <CAE=-AhDC8G_k6V3tGa9=nNy2y8G9XD7u4XWqbgZpV8p9RxS3gg@mail.gmail.com>

Congratz!

>EJBs in WARs now inherit the WAR security domain

\O/


On Fri, Nov 21, 2014 at 12:43 PM, Lu?s M. Costa <luis.m.costa at gmail.com> wrote:
> It seems there was a glitch with my client email, and a forward became a
> forward and reply... I'm very sorry for that.
>
> But, as you may see, if you translate my original message, we are going to
> evaluate it wright way - it is already being done.
>
> Congratulations on the new release! :-)
>
> Lu?s
>
> 2014-11-21 11:37 GMT+00:00 Luigi Fugaro <lfugaro at redhat.com>:
>>
>> Claro que si!
>>
>> On 21 Nov 2014, at 09:07, Lu?s M. Costa <luis.m.costa at gmail.com> wrote:
>>
>> Viva!
>>
>> Curiosamente ainda ontem fui ao roadmap do wildfly e pensei: "fixe j?
>> faltam menos de 20 issues". E agora temos release...
>>
>> Se calhar pe?o ao Paulo para explorar isto enquanto a monitoriza??o n?o ?
>> mais detalhada - mas j? est? mto mais clara...
>>
>> At? j?,
>>   Lu?s
>>
>> Em 21/11/2014 07:00, "Jason Greene" <jason.greene at redhat.com> escreveu:
>> >
>> > http://wildfly.org/news/2014/11/20/WildFly82-Final-Released/
>> >
>> > Thank you everyone for going the extra mile on this release! I was blown
>> > away (again) by your tenacity!
>> >
>> > --
>> > 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
>>
>>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From filippespolti at gmail.com  Fri Nov 21 08:00:39 2014
From: filippespolti at gmail.com (Filippe Spolti)
Date: Fri, 21 Nov 2014 11:00:39 -0200
Subject: [wildfly-dev] WildFly 8.2.0.Final is released!
In-Reply-To: <CAE9-Q_tkh5p6ut_Xy8EsHKc1AEg=DCoDou3=-Sf9GA_PXzX4ig@mail.gmail.com>
References: <B8DD00B3-C4CB-4E12-B758-D9C773FB806E@redhat.com>
	<CAE9-Q_tkh5p6ut_Xy8EsHKc1AEg=DCoDou3=-Sf9GA_PXzX4ig@mail.gmail.com>
Message-ID: <546F3777.503@gmail.com>

On 11/21/2014 05:07 AM, Francisco Mart?nez wrote:
>
> Good news and gr8 job!
> Congratulations!!
>
> Fran
>
> El 21/11/2014 08:00, "Jason Greene" <jason.greene at redhat.com 
> <mailto:jason.greene at redhat.com>> escribi?:
>
>     http://wildfly.org/news/2014/11/20/WildFly82-Final-Released/
>
>     Thank you everyone for going the extra mile on this release! I was
>     blown away (again) by your tenacity!
>
>     --
>     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 <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
Congratulations. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141121/57f138ad/attachment.html 

From hpehl at redhat.com  Fri Nov 21 09:13:01 2014
From: hpehl at redhat.com (Harald Pehl)
Date: Fri, 21 Nov 2014 15:13:01 +0100
Subject: [wildfly-dev] Search Index: Call for help
In-Reply-To: <CAMquZP7SUdZQ5tGeXVSpLBsBcNYLgPa93m+n1Df+Xfuy=4O15g@mail.gmail.com>
References: <20C34684-F4C8-4C4A-B190-B613F43BB439@redhat.com>
	<5464C808.9090409@redhat.com>
	<CAMquZP7SUdZQ5tGeXVSpLBsBcNYLgPa93m+n1Df+Xfuy=4O15g@mail.gmail.com>
Message-ID: <7B9C2945-E568-473A-BEDF-853AB853A465@redhat.com>

Thanks to all of you for your support! The new search is now available in the latest WildFly 8.2 release! Give it a try and let us know how you like it.

My latest blog post gives some more details about the new search feature in the management console:
http://hpehl.info/search_in_console.html

Thanks 
Harald 

> Am 13.11.2014 um 17:24 schrieb Toma? Cerar <tomaz.cerar at gmail.com>:
> 
> 
> On Thu, Nov 13, 2014 at 4:02 PM, Scott Marlow <smarlow at redhat.com <mailto:smarlow at redhat.com>> wrote:
> is
> there any reason why the description for jpa-metrics should be "The
> configuration of the JPA subsystem.;"
> 
> 
> Yes, this is defined in LocalDescription.properties file for each subsystem.
> It is up to subsystem author to define best descriptions possible for the model of the subsystem there.
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

---
Harald Pehl
JBoss by Red Hat
http://hpehl.info

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

From bilge at redhat.com  Fri Nov 21 09:48:01 2014
From: bilge at redhat.com (Bilgehan Ozpeynirci)
Date: Fri, 21 Nov 2014 09:48:01 -0500 (EST)
Subject: [wildfly-dev] WildFly 8.2.0.Final is released!
In-Reply-To: <B8DD00B3-C4CB-4E12-B758-D9C773FB806E@redhat.com>
References: <B8DD00B3-C4CB-4E12-B758-D9C773FB806E@redhat.com>
Message-ID: <213802914.16089035.1416581281378.JavaMail.zimbra@redhat.com>

Congrats to all for this important milestone! 
-Bilge 

----- Original Message -----

| From: "Jason Greene" <jason.greene at redhat.com>
| To: "WildFly Dev" <wildfly-dev at lists.jboss.org>
| Sent: Friday, November 21, 2014 2:00:36 AM
| Subject: [wildfly-dev] WildFly 8.2.0.Final is released!

| http://wildfly.org/news/2014/11/20/WildFly82-Final-Released/

| Thank you everyone for going the extra mile on this release! I was blown away
| (again) by your tenacity!

| --
| 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/20141121/81692488/attachment.html 

From jose.e.chavez at gmail.com  Fri Nov 21 09:51:58 2014
From: jose.e.chavez at gmail.com (Jose Chavez)
Date: Fri, 21 Nov 2014 08:51:58 -0600
Subject: [wildfly-dev] WildFly 8.2.0.Final is released!
In-Reply-To: <213802914.16089035.1416581281378.JavaMail.zimbra@redhat.com>
References: <B8DD00B3-C4CB-4E12-B758-D9C773FB806E@redhat.com>
	<213802914.16089035.1416581281378.JavaMail.zimbra@redhat.com>
Message-ID: <CADn8Fo1V1_MAT9MfKzmcHhLiYWY2gB=YYm2OYB9kpY0YBQ45ig@mail.gmail.com>

Hi guys,

Thanks for all your hard work! We Java EE Devs are downloading the newest
update as I type this!

Jose E. Chavez
jose.e.chavez at gmail.com

On Fri, Nov 21, 2014 at 8:48 AM, Bilgehan Ozpeynirci <bilge at redhat.com>
wrote:

> Congrats to all for this important milestone!
> -Bilge
>
>
> ------------------------------
>
> *From: *"Jason Greene" <jason.greene at redhat.com>
> *To: *"WildFly Dev" <wildfly-dev at lists.jboss.org>
> *Sent: *Friday, November 21, 2014 2:00:36 AM
> *Subject: *[wildfly-dev] WildFly 8.2.0.Final is released!
>
>
> http://wildfly.org/news/2014/11/20/WildFly82-Final-Released/
>
> Thank you everyone for going the extra mile on this release! I was blown
> away (again) by your tenacity!
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141121/ba1e6afc/attachment.html 

From david.lloyd at redhat.com  Fri Nov 21 13:42:53 2014
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Fri, 21 Nov 2014 12:42:53 -0600
Subject: [wildfly-dev] About client-side configuration
Message-ID: <546F87AD.4050600@redhat.com>

I'm currently working on reorganizing most of our client-side components 
to support URI-based connection and invocation for the following services:

? JBoss Remoting
? EJB Client
? Remote Naming (JNDI)
? Remote Transactions
? Elytron (remote authentication)

Each of these components will require a separate chunk of configuration. 
  The works in progress presently will rely on separated XML files for 
each of these things (which in many/most cases will be reusable 
in-container as deployment descriptors).

I think you see where I'm going with this.

I'm kicking around the idea of doing something kind of similar to the 
unified configuration idea we tried out in WildFly, where there's one 
namespaced configuration file with each component picking up its piece 
via some registration process.

The upside is, (optionally?) one client-side configuration file for 
everything, even things we haven't written yet.

The downside is having another common dependency for everything that 
consumes client configuration.  Though we *could* make it optional 
(which in turn has another downside that we can't really unify our 
parsing, which has some benefits like consistent error reporting, 
xinclude support, and pretty substantial code deduplication, among 
(probably) other things).

I'm leaning towards just going ahead with it and creating a small 
wildfly-client-configuration project which parses a "wildfly-client.xml" 
file and does the business.

Any thoughts, opinions, additional reasons not to do this?
-- 
- DML

From ssilvert at redhat.com  Fri Nov 21 14:47:55 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 21 Nov 2014 14:47:55 -0500
Subject: [wildfly-dev] About client-side configuration
In-Reply-To: <546F87AD.4050600@redhat.com>
References: <546F87AD.4050600@redhat.com>
Message-ID: <546F96EB.5020904@redhat.com>

It sounds good to me.  I can't think of a strong reason to make the 
dependency optional.

On 11/21/2014 1:42 PM, David M. Lloyd wrote:
> I'm currently working on reorganizing most of our client-side components
> to support URI-based connection and invocation for the following services:
>
> ? JBoss Remoting
> ? EJB Client
> ? Remote Naming (JNDI)
> ? Remote Transactions
> ? Elytron (remote authentication)
>
> Each of these components will require a separate chunk of configuration.
>    The works in progress presently will rely on separated XML files for
> each of these things (which in many/most cases will be reusable
> in-container as deployment descriptors).
>
> I think you see where I'm going with this.
>
> I'm kicking around the idea of doing something kind of similar to the
> unified configuration idea we tried out in WildFly, where there's one
> namespaced configuration file with each component picking up its piece
> via some registration process.
>
> The upside is, (optionally?) one client-side configuration file for
> everything, even things we haven't written yet.
>
> The downside is having another common dependency for everything that
> consumes client configuration.  Though we *could* make it optional
> (which in turn has another downside that we can't really unify our
> parsing, which has some benefits like consistent error reporting,
> xinclude support, and pretty substantial code deduplication, among
> (probably) other things).
>
> I'm leaning towards just going ahead with it and creating a small
> wildfly-client-configuration project which parses a "wildfly-client.xml"
> file and does the business.
>
> Any thoughts, opinions, additional reasons not to do this?


From fjuma at redhat.com  Fri Nov 21 15:21:42 2014
From: fjuma at redhat.com (Farah Juma)
Date: Fri, 21 Nov 2014 15:21:42 -0500 (EST)
Subject: [wildfly-dev] WildFly 8.2.0.Final is now on OpenShift
In-Reply-To: <117884381.2271309.1416597660761.JavaMail.zimbra@redhat.com>
Message-ID: <703189374.2295159.1416601302199.JavaMail.zimbra@redhat.com>

See https://developer.jboss.org/people/fjuma/blog/2014/11/21/wildfly-820final-on-openshift for details on how to get started.

Enjoy!


From jason.greene at redhat.com  Sat Nov 22 20:17:40 2014
From: jason.greene at redhat.com (Jason T. Greene)
Date: Sat, 22 Nov 2014 20:17:40 -0500 (EST)
Subject: [wildfly-dev] WildFly 8.2.0.Final is now on OpenShift
In-Reply-To: <703189374.2295159.1416601302199.JavaMail.zimbra@redhat.com>
References: <703189374.2295159.1416601302199.JavaMail.zimbra@redhat.com>
Message-ID: <3537EE3E-CA28-4AF9-8616-8BB782C84943@redhat.com>

Awesome!


> On Nov 21, 2014, at 2:22 PM, Farah Juma <fjuma at redhat.com> wrote:
> 
> See https://developer.jboss.org/people/fjuma/blog/2014/11/21/wildfly-820final-on-openshift for details on how to get started.
> 
> Enjoy!
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From manderse at redhat.com  Mon Nov 24 07:34:23 2014
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Mon, 24 Nov 2014 13:34:23 +0100
Subject: [wildfly-dev] JBAS011592 the logging subsystem requires the log
 manager to be org.jboss.logmanager.LogManager
In-Reply-To: <513BC043-2599-40A9-8C28-6574B29929C1@redhat.com>
References: <8619BFE7-73A8-414A-A1C7-9B3E0DBFC410@redhat.com>
	<54436B65.6060607@gmail.com> <54444DE6.3000705@redhat.com>
	<513BC043-2599-40A9-8C28-6574B29929C1@redhat.com>
Message-ID: <55F7C7CE-078F-409A-8A47-0FEC83969361@redhat.com>

On 20 Oct 2014, at 11:20, Max Rydahl Andersen wrote:> On 20 Oct 2014, at 
1:48, James R. Perkins wrote:
>
>> As Stuart asked more details would help.
>>
>> The only way this could happen is if something, an agent for example, 
>> attempts to get a logger before JBoss Modules initializes logging. 
>> JBoss Modules looks for a META-INF/services/ 
>> java.util.logging.LogManager service which JBoss Log Manager has. If 
>> an agent needs to be used the java.util.logging.manager needs to be 
>> set to org.jboss.logmanager.LogManager before the agent initializes a 
>> logger.
>
> It is all in the jira.
>
> And no, these errors have been happening on what is just plain vanilla 
> WildFly or EAP/JPP bundles.
>
> We do not do any agent funkyness afaik.
>
> And as said the "workaround" so far have been "restart it" and it 
> works.
>
> zero changes to the state or arguments.

okey so there been some new movement in this.

https://bugzilla.redhat.com/show_bug.cgi?id=1037970

Indicating there actually is a race condition if something pings the jvm 
via jmx during the startup
*before* jboss main boot process manages to set the logmanager. 
Something that will happen because
we actually have a feature that scans for locally running jvm's and 
attach an agent to gather info.

Suggested workaround is to add this to our launch:
JAVA_OPTS="$JAVA_OPTS 
-Djava.util.logging.manager=org.jboss.logmanager.LogManager"
JAVA_OPTS="$JAVA_OPTS 
-Xbootclasspath/p:$JBOSS_HOME/modules/org/jboss/logmanager/main/jboss-logmanager-1.3.1.Final-redhat-1.jar" 
-logging org.jboss.logmanager.LogManager

Question from us is, is the above workaround proper ? Will EAP/WildFly 
change their boot arguments to match to avoid this race condition issue 
for bat/sh launched servers too ?

/max

>
> /max
>
>>
>> On 10/19/2014 12:42 AM, Stuart Douglas wrote:
>>> Are you using a java agent by any chance?
>>>
>>> If you are then the java agent is probably causing the issue, by
>>> attempting to log something before JBoss modules can set the log 
>>> manager.
>>>
>>> If you are not using a java agent then I am not sure exactly what 
>>> the
>>> cause might be. Looking at the code it looks like it is possible for 
>>> a
>>> custom security manager to break logging as the security manager is
>>> initialized first, however that does not seem likely.
>>>
>>> Can you share the details on exactly what command line is being used 
>>> to
>>> start the server?
>>>
>>> Stuart
>>>
>>> Max Rydahl Andersen wrote:
>>>> Heya,
>>>>
>>>> In tools and around arquillian I'm seeing more and more of $subject
>>>> error that I can't figure out the cause of.
>>>>
>>>> I've found https://issues.jboss.org/browse/WFLY-3152 which David
>>>> responds the error message is clear.
>>>>
>>>> I might be clear, but I can't figure out why starting wildfly the 
>>>> exact
>>>> same way will in one case result in this
>>>> error but then on second start it just works.
>>>>
>>>> I first thought that our tools might not be setting the LogManager
>>>> (which it does not), but when I look at standalone.sh
>>>> in the same server there is also no setting of this property hence
>>>> afaics the server is being obtuse.
>>>>
>>>> The answer in all cases seem to have been "have tried restarting 
>>>> it?"
>>>> and then things starts working, until it doesn't - and
>>>> then we restart again.
>>>>
>>>> Any idea on what is going on  here ?
>>>>
>>>> Thanks,
>>>> /max
>>>> http://about.me/maxandersen
>>>> _______________________________________________
>>>> 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
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> /max
> http://about.me/maxandersen


/max
http://about.me/maxandersen


From rory.odonnell at oracle.com  Mon Nov 24 09:13:30 2014
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Mon, 24 Nov 2014 14:13:30 +0000
Subject: [wildfly-dev] Jigsaw early-access builds updated (JDK 9 build 40)
Message-ID: <54733D0A.4090709@oracle.com>


Hi Jason/Tomaz,

JDK 9 Early Access with Project Jigsaw build b40 is available for 
download at :
https://jdk9.java.net/jigsaw/

The goal of Project Jigsaw [2] is to design and implement a standard module
system for the Java SE Platform, and to apply that system to the 
Platform itself
and to the JDK.

The main change in this build is that it includes the jrt: file-system 
provider,
so it now implements all of the changes described in JEP 220.

Please refer to Project Jigsaw's updated project pages [2] & [4] and Mark
Reinhold's update [5] for further details.

We are very interested in your experiences testing this build. Comments,
questions, and suggestions are welcome on the jigsaw-dev 
<http://mail.openjdk.java.net/mailman/listinfo/jigsaw-dev> mailing list or
through bug reports via bugs.java.com <http://bugs.java.com/>.

Note: If you haven?t already subscribed to that mailing list then please do
so first, otherwise your message will be discarded as spam.

Rgds, Rory

[1] https://jdk9.java.net/jigsaw/
[2] http://openjdk.java.net/projects/jigsaw/
[3] http://openjdk.java.net/jeps/220
[4] http://openjdk.java.net/projects/jigsaw/ea
[5] 
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2014-November/004014.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/20141124/de16d8eb/attachment.html 

From david.lloyd at redhat.com  Mon Nov 24 09:20:19 2014
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Mon, 24 Nov 2014 08:20:19 -0600
Subject: [wildfly-dev] JBAS011592 the logging subsystem requires the log
 manager to be org.jboss.logmanager.LogManager
In-Reply-To: <55F7C7CE-078F-409A-8A47-0FEC83969361@redhat.com>
References: <8619BFE7-73A8-414A-A1C7-9B3E0DBFC410@redhat.com>	<54436B65.6060607@gmail.com>
	<54444DE6.3000705@redhat.com>	<513BC043-2599-40A9-8C28-6574B29929C1@redhat.com>
	<55F7C7CE-078F-409A-8A47-0FEC83969361@redhat.com>
Message-ID: <54733EA3.5070507@redhat.com>

On 11/24/2014 06:34 AM, Max Rydahl Andersen wrote:
> On 20 Oct 2014, at 11:20, Max Rydahl Andersen wrote:> On 20 Oct 2014, at
> 1:48, James R. Perkins wrote:
>>
>>> As Stuart asked more details would help.
>>>
>>> The only way this could happen is if something, an agent for example,
>>> attempts to get a logger before JBoss Modules initializes logging.
>>> JBoss Modules looks for a META-INF/services/
>>> java.util.logging.LogManager service which JBoss Log Manager has. If
>>> an agent needs to be used the java.util.logging.manager needs to be
>>> set to org.jboss.logmanager.LogManager before the agent initializes a
>>> logger.
>>
>> It is all in the jira.
>>
>> And no, these errors have been happening on what is just plain vanilla
>> WildFly or EAP/JPP bundles.
>>
>> We do not do any agent funkyness afaik.
>>
>> And as said the "workaround" so far have been "restart it" and it
>> works.
>>
>> zero changes to the state or arguments.
>
> okey so there been some new movement in this.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1037970
>
> Indicating there actually is a race condition if something pings the jvm
> via jmx during the startup
> *before* jboss main boot process manages to set the logmanager.
> Something that will happen because
> we actually have a feature that scans for locally running jvm's and
> attach an agent to gather info.
>
> Suggested workaround is to add this to our launch:
> JAVA_OPTS="$JAVA_OPTS
> -Djava.util.logging.manager=org.jboss.logmanager.LogManager"
> JAVA_OPTS="$JAVA_OPTS
> -Xbootclasspath/p:$JBOSS_HOME/modules/org/jboss/logmanager/main/jboss-logmanager-1.3.1.Final-redhat-1.jar"
> -logging org.jboss.logmanager.LogManager
>
> Question from us is, is the above workaround proper ? Will EAP/WildFly
> change their boot arguments to match to avoid this race condition issue
> for bat/sh launched servers too ?

No, there's a very good chance that will cause weird stuff to happen, 
like two copies of the log manager being installed.  It may work, 
mostly, but this is not a risk-free solution.

The "proper fix" is to come up with some kind of agent mode for 
jboss-modules, but it's not really clear how this can be accomplished 
without yet more goofy side-effects.
-- 
- DML

From jason.greene at redhat.com  Mon Nov 24 10:39:33 2014
From: jason.greene at redhat.com (Jason Greene)
Date: Mon, 24 Nov 2014 09:39:33 -0600
Subject: [wildfly-dev] JBAS011592 the logging subsystem requires the log
	manager to be org.jboss.logmanager.LogManager
In-Reply-To: <54733EA3.5070507@redhat.com>
References: <8619BFE7-73A8-414A-A1C7-9B3E0DBFC410@redhat.com>
	<54436B65.6060607@gmail.com> <54444DE6.3000705@redhat.com>
	<513BC043-2599-40A9-8C28-6574B29929C1@redhat.com>
	<55F7C7CE-078F-409A-8A47-0FEC83969361@redhat.com>
	<54733EA3.5070507@redhat.com>
Message-ID: <466BFCD3-66D7-41E5-8EE4-9D740BBCD3E1@redhat.com>


> On Nov 24, 2014, at 8:20 AM, David M. Lloyd <david.lloyd at redhat.com> wrote:
> 
> On 11/24/2014 06:34 AM, Max Rydahl Andersen wrote:
>> On 20 Oct 2014, at 11:20, Max Rydahl Andersen wrote:> On 20 Oct 2014, at
>> 1:48, James R. Perkins wrote:
>>> 
>>>> As Stuart asked more details would help.
>>>> 
>>>> The only way this could happen is if something, an agent for example,
>>>> attempts to get a logger before JBoss Modules initializes logging.
>>>> JBoss Modules looks for a META-INF/services/
>>>> java.util.logging.LogManager service which JBoss Log Manager has. If
>>>> an agent needs to be used the java.util.logging.manager needs to be
>>>> set to org.jboss.logmanager.LogManager before the agent initializes a
>>>> logger.
>>> 
>>> It is all in the jira.
>>> 
>>> And no, these errors have been happening on what is just plain vanilla
>>> WildFly or EAP/JPP bundles.
>>> 
>>> We do not do any agent funkyness afaik.
>>> 
>>> And as said the "workaround" so far have been "restart it" and it
>>> works.
>>> 
>>> zero changes to the state or arguments.
>> 
>> okey so there been some new movement in this.
>> 
>> https://bugzilla.redhat.com/show_bug.cgi?id=1037970
>> 
>> Indicating there actually is a race condition if something pings the jvm
>> via jmx during the startup
>> *before* jboss main boot process manages to set the logmanager.
>> Something that will happen because
>> we actually have a feature that scans for locally running jvm's and
>> attach an agent to gather info.
>> 
>> Suggested workaround is to add this to our launch:
>> JAVA_OPTS="$JAVA_OPTS
>> -Djava.util.logging.manager=org.jboss.logmanager.LogManager"
>> JAVA_OPTS="$JAVA_OPTS
>> -Xbootclasspath/p:$JBOSS_HOME/modules/org/jboss/logmanager/main/jboss-logmanager-1.3.1.Final-redhat-1.jar"
>> -logging org.jboss.logmanager.LogManager
>> 
>> Question from us is, is the above workaround proper ? Will EAP/WildFly
>> change their boot arguments to match to avoid this race condition issue
>> for bat/sh launched servers too ?
> 
> No, there's a very good chance that will cause weird stuff to happen, 
> like two copies of the log manager being installed.  It may work, 
> mostly, but this is not a risk-free solution.
> 
> The "proper fix" is to come up with some kind of agent mode for 
> jboss-modules, but it's not really clear how this can be accomplished 
> without yet more goofy side-effects.
> -- 
> - DML

IIRC agents have order, and we could rely on that.

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



From manderse at redhat.com  Mon Nov 24 11:40:16 2014
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Mon, 24 Nov 2014 17:40:16 +0100
Subject: [wildfly-dev] JBAS011592 the logging subsystem requires the log
 manager to be org.jboss.logmanager.LogManager
In-Reply-To: <54733EA3.5070507@redhat.com>
References: <8619BFE7-73A8-414A-A1C7-9B3E0DBFC410@redhat.com>
	<54436B65.6060607@gmail.com> <54444DE6.3000705@redhat.com>
	<513BC043-2599-40A9-8C28-6574B29929C1@redhat.com>
	<55F7C7CE-078F-409A-8A47-0FEC83969361@redhat.com>
	<54733EA3.5070507@redhat.com>
Message-ID: <A6C45C5E-308E-4C17-91FE-7FEEB60AA7B2@redhat.com>

>>>
>>> We do not do any agent funkyness afaik.
>>>
>>> And as said the "workaround" so far have been "restart it" and it
>>> works.
>>>
>>> zero changes to the state or arguments.
>>
>> okey so there been some new movement in this.
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1037970
>>
>> Indicating there actually is a race condition if something pings the 
>> jvm
>> via jmx during the startup
>> *before* jboss main boot process manages to set the logmanager.
>> Something that will happen because
>> we actually have a feature that scans for locally running jvm's and
>> attach an agent to gather info.
>>
>> Suggested workaround is to add this to our launch:
>> JAVA_OPTS="$JAVA_OPTS
>> -Djava.util.logging.manager=org.jboss.logmanager.LogManager"
>> JAVA_OPTS="$JAVA_OPTS
>> -Xbootclasspath/p:$JBOSS_HOME/modules/org/jboss/logmanager/main/jboss-logmanager-1.3.1.Final-redhat-1.jar"
>> -logging org.jboss.logmanager.LogManager
>>
>> Question from us is, is the above workaround proper ? Will 
>> EAP/WildFly
>> change their boot arguments to match to avoid this race condition 
>> issue
>> for bat/sh launched servers too ?
>
> No, there's a very good chance that will cause weird stuff to happen,
> like two copies of the log manager being installed.  It may work,
> mostly, but this is not a risk-free solution.

Yeah, that was what I feared...btw. this is what the official 
recommendation is on the knowledge base article about this issue ;/

But can you confirm that the issue is can and will happen if a remote 
process tries to install an agent and even if the agent has zero jboss 
logging usage
that can somehow result in jboss logging getting activated before it has 
settings configured ?

I'm just wondering what code actually is being invoked that needs this 
log manager when we are installing an agent very early in the start up 
phase ?

> The "proper fix" is to come up with some kind of agent mode for
> jboss-modules, but it's not really clear how this can be accomplished
> without yet more goofy side-effects.

okey ;/

/max
http://about.me/maxandersen


From david.lloyd at redhat.com  Mon Nov 24 11:48:48 2014
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Mon, 24 Nov 2014 10:48:48 -0600
Subject: [wildfly-dev] JBAS011592 the logging subsystem requires the log
 manager to be org.jboss.logmanager.LogManager
In-Reply-To: <A6C45C5E-308E-4C17-91FE-7FEEB60AA7B2@redhat.com>
References: <8619BFE7-73A8-414A-A1C7-9B3E0DBFC410@redhat.com>
	<54436B65.6060607@gmail.com> <54444DE6.3000705@redhat.com>
	<513BC043-2599-40A9-8C28-6574B29929C1@redhat.com>
	<55F7C7CE-078F-409A-8A47-0FEC83969361@redhat.com>
	<54733EA3.5070507@redhat.com>
	<A6C45C5E-308E-4C17-91FE-7FEEB60AA7B2@redhat.com>
Message-ID: <54736170.5050204@redhat.com>

On 11/24/2014 10:40 AM, Max Rydahl Andersen wrote:
>>>>
>>>> We do not do any agent funkyness afaik.
>>>>
>>>> And as said the "workaround" so far have been "restart it" and it
>>>> works.
>>>>
>>>> zero changes to the state or arguments.
>>>
>>> okey so there been some new movement in this.
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1037970
>>>
>>> Indicating there actually is a race condition if something pings the jvm
>>> via jmx during the startup
>>> *before* jboss main boot process manages to set the logmanager.
>>> Something that will happen because
>>> we actually have a feature that scans for locally running jvm's and
>>> attach an agent to gather info.
>>>
>>> Suggested workaround is to add this to our launch:
>>> JAVA_OPTS="$JAVA_OPTS
>>> -Djava.util.logging.manager=org.jboss.logmanager.LogManager"
>>> JAVA_OPTS="$JAVA_OPTS
>>> -Xbootclasspath/p:$JBOSS_HOME/modules/org/jboss/logmanager/main/jboss-logmanager-1.3.1.Final-redhat-1.jar"
>>>
>>> -logging org.jboss.logmanager.LogManager
>>>
>>> Question from us is, is the above workaround proper ? Will EAP/WildFly
>>> change their boot arguments to match to avoid this race condition issue
>>> for bat/sh launched servers too ?
>>
>> No, there's a very good chance that will cause weird stuff to happen,
>> like two copies of the log manager being installed.  It may work,
>> mostly, but this is not a risk-free solution.
>
> Yeah, that was what I feared...btw. this is what the official
> recommendation is on the knowledge base article about this issue ;/
>
> But can you confirm that the issue is can and will happen if a remote
> process tries to install an agent and even if the agent has zero jboss
> logging usage
> that can somehow result in jboss logging getting activated before it has
> settings configured ?
>
> I'm just wondering what code actually is being invoked that needs this
> log manager when we are installing an agent very early in the start up
> phase ?

Conceptually we don't need or want our log manager to be installed until 
we have something interesting to log.  But, you only get one chance to 
install the log manager, and the JVM initializes it whenever it wants, 
so that's the basic summary of the problem.  The only way to "beat" the 
JVM is to get in there ahead of it.

You could theoretically dig in with reflection and swap out the log 
manager after the fact, but then you'd also have to somehow swap out all 
the loggers made with the original log manager, otherwise what happens 
is some log messages just go missing.

Another option is to install some kind of "proxy" log manager that has a 
facility to swap out all the backing loggers.

>> The "proper fix" is to come up with some kind of agent mode for
>> jboss-modules, but it's not really clear how this can be accomplished
>> without yet more goofy side-effects.
>
> okey ;/
>
> /max
> http://about.me/maxandersen

-- 
- DML

From darran.lofthouse at jboss.com  Mon Nov 24 13:37:17 2014
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Mon, 24 Nov 2014 18:37:17 +0000
Subject: [wildfly-dev] WFCORE-276 - :whoami(verbose=true) Fails for user
	with no roles.
Message-ID: <54737ADD.9020807@jboss.com>

Hello Alexey / Brian,

Just trying to get to the bottom of a failure where 
:whoami(verbose=true) is being performed by a user in the CLI with no 
roles and the following error is received and looking for some ideas.

"WFLYCTL0313: Unauthorized to execute operation 
'read-operation-description' for resource '[]' -- "WFLYCTL0332: 
Permission denied""

The call to the :whoami operation would be fine except as there is a 
parameter the CLI is attempting to validate the parameters by making a 
call to read-operation-description and it is that call that is failing.

Personally I think this operation working is important as it enables 
some debugging of role assignment, i.e. if a user has not been granted 
the expected roles this call helps provide some information about that.

So unless we are going to say the user should not be calling whoami we 
broadly have two options: -

1 - Make a special case in the CLI and skip the 
read-operation-description call.

2 - Access control changes to make it possible to call 
read-operation-description for the whoami operation.

Regards,
Darran Lofthouse.

From brian.stansberry at redhat.com  Mon Nov 24 14:04:59 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 24 Nov 2014 13:04:59 -0600
Subject: [wildfly-dev] WFCORE-276 - :whoami(verbose=true) Fails for user
	with no roles.
In-Reply-To: <54737ADD.9020807@jboss.com>
References: <54737ADD.9020807@jboss.com>
Message-ID: <5473815B.60609@redhat.com>

On 11/24/14, 12:37 PM, Darran Lofthouse wrote:
> Hello Alexey / Brian,
>
> Just trying to get to the bottom of a failure where
> :whoami(verbose=true) is being performed by a user in the CLI with no
> roles and the following error is received and looking for some ideas.
>
> "WFLYCTL0313: Unauthorized to execute operation
> 'read-operation-description' for resource '[]' -- "WFLYCTL0332:
> Permission denied""
>
> The call to the :whoami operation would be fine except as there is a
> parameter the CLI is attempting to validate the parameters by making a
> call to read-operation-description and it is that call that is failing.
>
> Personally I think this operation working is important as it enables
> some debugging of role assignment, i.e. if a user has not been granted
> the expected roles this call helps provide some information about that.
>
> So unless we are going to say the user should not be calling whoami we
> broadly have two options: -
>
> 1 - Make a special case in the CLI and skip the
> read-operation-description call.
>

There should be a high level command in the CLI for this anyway. I don't 
really like the low level op being handled as a special case, but a high 
level command is fine with me.

> 2 - Access control changes to make it possible to call
> read-operation-description for the whoami operation.
>

-1. I'd much rather not even allow the use of this op than go this route.

Related to this, today isn't good but let's chat some time soon re: how 
to make the interactive-mode CLI behavior more user-friendly when the 
user has no permissions, e.g. can't read the root resource. For example, 
output a message informing the user of this and, if reasonably do-able, 
limiting the tab completion list to just a few things. Just the message 
would help a lot; something analogous to this message we print when the 
user isn't connected:

You are disconnected at the moment. Type 'connect' to connect to the 
server or 'help' for the list of supported commands.

> Regards,
> Darran Lofthouse.


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

From darran.lofthouse at jboss.com  Mon Nov 24 14:08:21 2014
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Mon, 24 Nov 2014 19:08:21 +0000
Subject: [wildfly-dev] WFCORE-276 - :whoami(verbose=true) Fails for user
	with no roles.
In-Reply-To: <5473815B.60609@redhat.com>
References: <54737ADD.9020807@jboss.com> <5473815B.60609@redhat.com>
Message-ID: <54738225.6030505@jboss.com>



On 24/11/14 19:04, Brian Stansberry wrote:
> On 11/24/14, 12:37 PM, Darran Lofthouse wrote:
>> Hello Alexey / Brian,
>>
>> Just trying to get to the bottom of a failure where
>> :whoami(verbose=true) is being performed by a user in the CLI with no
>> roles and the following error is received and looking for some ideas.
>>
>> "WFLYCTL0313: Unauthorized to execute operation
>> 'read-operation-description' for resource '[]' -- "WFLYCTL0332:
>> Permission denied""
>>
>> The call to the :whoami operation would be fine except as there is a
>> parameter the CLI is attempting to validate the parameters by making a
>> call to read-operation-description and it is that call that is failing.
>>
>> Personally I think this operation working is important as it enables
>> some debugging of role assignment, i.e. if a user has not been granted
>> the expected roles this call helps provide some information about that.
>>
>> So unless we are going to say the user should not be calling whoami we
>> broadly have two options: -
>>
>> 1 - Make a special case in the CLI and skip the
>> read-operation-description call.
>>
>
> There should be a high level command in the CLI for this anyway. I don't
> really like the low level op being handled as a special case, but a high
> level command is fine with me.

Thanks - That could work, will look at that option.

>> 2 - Access control changes to make it possible to call
>> read-operation-description for the whoami operation.
>>
>
> -1. I'd much rather not even allow the use of this op than go this route.
>
> Related to this, today isn't good but let's chat some time soon re: how
> to make the interactive-mode CLI behavior more user-friendly when the
> user has no permissions, e.g. can't read the root resource. For example,
> output a message informing the user of this and, if reasonably do-able,
> limiting the tab completion list to just a few things. Just the message
> would help a lot; something analogous to this message we print when the
> user isn't connected:

At the moment the CLI could also use the :whoami operation to check a 
user does have at least one role but that will not help much if a 
non-role based access control provider is ever installed.

> You are disconnected at the moment. Type 'connect' to connect to the
> server or 'help' for the list of supported commands.
>
>> Regards,
>> Darran Lofthouse.
>
>

From darran.lofthouse at jboss.com  Mon Nov 24 14:31:13 2014
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Mon, 24 Nov 2014 19:31:13 +0000
Subject: [wildfly-dev] WFCORE-276 - :whoami(verbose=true) Fails for user
	with no roles.
In-Reply-To: <54738225.6030505@jboss.com>
References: <54737ADD.9020807@jboss.com> <5473815B.60609@redhat.com>
	<54738225.6030505@jboss.com>
Message-ID: <54738781.2010809@jboss.com>

After a further check we have the contributed high level command handler 
for 'connection-info' which amongst other things outputs the output from 
:whoami(verbose=true) so in that case I don't think I need to duplicate 
this with another high level whoami operation.

I will resolve the Jira I think, if anyone searches for the error they 
will find it now and I will comment that they should use connection-info 
instead.

Regards,
Darran Lofthouse.


On 24/11/14 19:08, Darran Lofthouse wrote:
>
>
> On 24/11/14 19:04, Brian Stansberry wrote:
>> On 11/24/14, 12:37 PM, Darran Lofthouse wrote:
>>> Hello Alexey / Brian,
>>>
>>> Just trying to get to the bottom of a failure where
>>> :whoami(verbose=true) is being performed by a user in the CLI with no
>>> roles and the following error is received and looking for some ideas.
>>>
>>> "WFLYCTL0313: Unauthorized to execute operation
>>> 'read-operation-description' for resource '[]' -- "WFLYCTL0332:
>>> Permission denied""
>>>
>>> The call to the :whoami operation would be fine except as there is a
>>> parameter the CLI is attempting to validate the parameters by making a
>>> call to read-operation-description and it is that call that is failing.
>>>
>>> Personally I think this operation working is important as it enables
>>> some debugging of role assignment, i.e. if a user has not been granted
>>> the expected roles this call helps provide some information about that.
>>>
>>> So unless we are going to say the user should not be calling whoami we
>>> broadly have two options: -
>>>
>>> 1 - Make a special case in the CLI and skip the
>>> read-operation-description call.
>>>
>>
>> There should be a high level command in the CLI for this anyway. I don't
>> really like the low level op being handled as a special case, but a high
>> level command is fine with me.
>
> Thanks - That could work, will look at that option.
>
>>> 2 - Access control changes to make it possible to call
>>> read-operation-description for the whoami operation.
>>>
>>
>> -1. I'd much rather not even allow the use of this op than go this route.
>>
>> Related to this, today isn't good but let's chat some time soon re: how
>> to make the interactive-mode CLI behavior more user-friendly when the
>> user has no permissions, e.g. can't read the root resource. For example,
>> output a message informing the user of this and, if reasonably do-able,
>> limiting the tab completion list to just a few things. Just the message
>> would help a lot; something analogous to this message we print when the
>> user isn't connected:
>
> At the moment the CLI could also use the :whoami operation to check a
> user does have at least one role but that will not help much if a
> non-role based access control provider is ever installed.
>
>> You are disconnected at the moment. Type 'connect' to connect to the
>> server or 'help' for the list of supported commands.
>>
>>> Regards,
>>> Darran Lofthouse.
>>
>>

From brian.stansberry at redhat.com  Mon Nov 24 14:36:02 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 24 Nov 2014 13:36:02 -0600
Subject: [wildfly-dev] WFCORE-276 - :whoami(verbose=true) Fails for user
	with no roles.
In-Reply-To: <54738781.2010809@jboss.com>
References: <54737ADD.9020807@jboss.com> <5473815B.60609@redhat.com>
	<54738225.6030505@jboss.com> <54738781.2010809@jboss.com>
Message-ID: <547388A2.8090600@redhat.com>

Sounds good.

On 11/24/14, 1:31 PM, Darran Lofthouse wrote:
> After a further check we have the contributed high level command handler
> for 'connection-info' which amongst other things outputs the output from
> :whoami(verbose=true) so in that case I don't think I need to duplicate
> this with another high level whoami operation.
>
> I will resolve the Jira I think, if anyone searches for the error they
> will find it now and I will comment that they should use connection-info
> instead.
>
> Regards,
> Darran Lofthouse.
>
>
> On 24/11/14 19:08, Darran Lofthouse wrote:
>>
>>
>> On 24/11/14 19:04, Brian Stansberry wrote:
>>> On 11/24/14, 12:37 PM, Darran Lofthouse wrote:
>>>> Hello Alexey / Brian,
>>>>
>>>> Just trying to get to the bottom of a failure where
>>>> :whoami(verbose=true) is being performed by a user in the CLI with no
>>>> roles and the following error is received and looking for some ideas.
>>>>
>>>> "WFLYCTL0313: Unauthorized to execute operation
>>>> 'read-operation-description' for resource '[]' -- "WFLYCTL0332:
>>>> Permission denied""
>>>>
>>>> The call to the :whoami operation would be fine except as there is a
>>>> parameter the CLI is attempting to validate the parameters by making a
>>>> call to read-operation-description and it is that call that is failing.
>>>>
>>>> Personally I think this operation working is important as it enables
>>>> some debugging of role assignment, i.e. if a user has not been granted
>>>> the expected roles this call helps provide some information about that.
>>>>
>>>> So unless we are going to say the user should not be calling whoami we
>>>> broadly have two options: -
>>>>
>>>> 1 - Make a special case in the CLI and skip the
>>>> read-operation-description call.
>>>>
>>>
>>> There should be a high level command in the CLI for this anyway. I don't
>>> really like the low level op being handled as a special case, but a high
>>> level command is fine with me.
>>
>> Thanks - That could work, will look at that option.
>>
>>>> 2 - Access control changes to make it possible to call
>>>> read-operation-description for the whoami operation.
>>>>
>>>
>>> -1. I'd much rather not even allow the use of this op than go this
>>> route.
>>>
>>> Related to this, today isn't good but let's chat some time soon re: how
>>> to make the interactive-mode CLI behavior more user-friendly when the
>>> user has no permissions, e.g. can't read the root resource. For example,
>>> output a message informing the user of this and, if reasonably do-able,
>>> limiting the tab completion list to just a few things. Just the message
>>> would help a lot; something analogous to this message we print when the
>>> user isn't connected:
>>
>> At the moment the CLI could also use the :whoami operation to check a
>> user does have at least one role but that will not help much if a
>> non-role based access control provider is ever installed.
>>
>>> You are disconnected at the moment. Type 'connect' to connect to the
>>> server or 'help' for the list of supported commands.
>>>
>>>> Regards,
>>>> Darran Lofthouse.
>>>
>>>


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

From david.lloyd at redhat.com  Wed Nov 26 13:54:51 2014
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Wed, 26 Nov 2014 12:54:51 -0600
Subject: [wildfly-dev] IMPORTANT: First overview of changes to
 jboss-ejb-client 3.0 for WildFly 10 (probably)
Message-ID: <547621FB.3050107@redhat.com>

I don't want to commit this to a specific WildFly release but I guess 
and hope it'll come in around WildFly 10 or so (definitely not 9).

As previously discussed, the EJB client architecture is undergoing the 
following substantial changes:

? Introduction of URIAffinity, and URI-based invocation
? Expansion of the 'ejb' JNDI initial context to auto-associate the 
PROVIDER_URL as the URI affinity for looked-up proxies
? Elimination of all "nested" EJB client context functionality
? Integration with Elytron for client identity management
? Deferral to Remoting for automatic connection management
? Unification of client configuration, so the Elytron authentication 
client, Remoting connection management, remote transaction client, and 
EJB client configurations all can be configured in one file or 
deployment descriptor

As such, I've introduced a 2.x branch for upstream where continued 
development of the 2.x series will take place.  The "master" branch is 
being re-purposed towards this new development, targeted for 3.x of this 
library.

There are a number of compatibility considerations from 2.x to 3.x. 
Most (I hope) existing client code (which avoids specialized manual 
configuration or nested client contexts) should continue to function 
as-is, with the following exceptions:

? The following classes and interfaces are currently removed in my 
working copy:
    ? ClusterContext - replaced with discovery (?)
    ? ClusterNodeManager - replaced with discovery

    ? ClusterNodeSelector - replaced with discovery
    ? DeploymentNodeSelector - replaced with discovery

    ? ContextSelector - replaced with general selector class
    ? ConstantContextSelector
    ? IdentityEJBClientContextSelector
    ? ThreadLocalContextSelector

    ? EJBClientContextInitializer - no replacement
    ? DefaultInterceptorsClientContextInitializer
    ? TransactionRecoveryContextInitializer

    ? EJBClientContextIdentifier - no replacement
    ? NamedEJBClientContextIdentifier

    ? DefaultCallbackHandler - no replacement

    ? EJBClientConfiguration - replaced with context builder
    ? PropertiesBasedEJBClientConfiguration

    ? EJBClientContextListener - no replacement
    ? EJBClientInterceptor.Registration - no replacement (interceptor 
set cannot be changed)
    ? EJBClient*TransactionContext - replaced by 
wildfly-transaction-client facility
    ? EJBReceiverContext - no replacement
    ? ReceiverInterceptor - no replacement (internal class)

    ? ALL public classes in the org.jboss.ejb.client.remoting package 
including ReconnectHandler

? The following changes will be made to these core classes and interfaces:
    ? EJBClient
       ? Added more createSession() variants to support new affinity types
       ? Change createSession() methods to throw CreateException instead 
of Exception
       ? Remove createProxy() and createSession() variants which accept 
EJBClientContextIdentifier
       ? Remove getEJBClientContextIdentifierFor() method
    ? Attachable
       ? Remove getAttachments() method
    ? EJBClientContext
       ? No longer implements Closeable
       ? Remove close() method
       ? Remove all static create() methods, replaced with Builder class
       ? Remove finalize() method
       ? Remove getClusterContext(), getEJBClientConfiguration(), 
getOrCreateClusterContext(), removeCluster()
       ? Remove selector-related methods, replaced with general Selector 
class
       ? Remove register*() and unregister*() methods (providers are 
added to Builder)
       ? Remove require() method which accepts EJBClientContextIdentifier
       ? Add getInvocationTimeout() method
    ? Affinity
       ? Add forUri() factory method
    ? EJBClientInvocationContext
       ? Add getCompressionLevel(), isClientAsync(), and isIdempotent() 
query methods
       ? Remove finalize()
    ? EJB*Locator classes
       ? Additional constructors which also accept an affinity
       ? Additional "copy" constructors which accept a locator and 
affinity, to change the target affinity
    ? EJBReceiver class
       ? openSession() method changed to accept a stateless EJB locator
       ? Constructor changed to no args
       ? Remove all send*() and other methods related to transactions
       ? Remove associate(), getNodeName(), [de]registerModule(), exists()
    ? EJBReceiverInvocationContext
       ? Remove retryInvocation() method
       ? Remove getEjbReceiverContext() method
       ? Remove getNodeName() method
    ? EJBMetaDataImpl
       ? Deprecated, changed to not use raw types
    ? RequestSendFailedException
       ? Replaced constructor with standard exception four-constructor setup
? The following API classes are added:
    ? EJBClientPermission - a general permission class
    ? AbstractEJBMetaData - type-safe hierarchical version of 
EJBMetaDataImpl
    ? EJBClientContext.Builder - forwards-compatible builder for 
EJBClientContext
    ? EJBDiscoveryProvider - an interface to provide pluggable discovery
    ? EJBTransportProvider - an interface to provide URI-compatible 
transport (factory for EJBReceivers)
    ? URIAffinity - a type of affinity which has a URI for a target

Note in particular that most of the cluster-support infrastructure is 
presently removed with no replacement.  It is my hope and intent that 
the discovery infrastructure will be able to take over this function. 
How much of the code will be new, compared to how much of the code can 
be forward-ported and reintroduced from 2.x, remains to be discussed.

At present, the plan is for wire compatibility to be supported for 2.x 
clients talking to 3.x servers and vice-versa.

Transaction handling will be relegated to a separate 
wildfly-transaction-client API.  However the getUserTransaction(node) 
method will continue to be supported as a deprecated delegation to the 
transaction-client API.  In addition, when talking to a 2.x server, it 
is expected that a wildfly-transaction-client SPI implementation will 
piggyback on the existing EJB protocol transaction messages.

If any of these API changes seems unacceptable, now is the time to 
discuss it.  All the code that was removed was determined to be tied too 
tightly to the previous location or configuration strategy, and thus 
couldn't sensibly be supported going forward.  I have hopefully been 
adequately upfront about what I intended to remove or support going 
forward.  In addition, by supporting the 2.x client, most migration 
concerns can hopefully be mitigated.  But it's possible that some 
classes or methods could indeed be reintroduced with sensible semantics 
and in such a way as to not cause problems; if you have any thoughts 
along these lines, please share them and we can discuss them on a 
case-by-case basis.

I've pushed up the proposed baseline 3.0 API at 
https://github.com/dmlloyd/jboss-ejb-client/tree/uri_invocation for 
review.  I intend for pull requests that are relevant to both old and 
new code bases to be applied to both if possible, to avoid increasing 
the incompatibility window even further.

-- 
- DML

From arun.gupta at gmail.com  Wed Nov 26 15:25:07 2014
From: arun.gupta at gmail.com (Arun Gupta)
Date: Wed, 26 Nov 2014 20:25:07 +0000
Subject: [wildfly-dev] Regression in Java EE 7 HOL
Message-ID: <CAGBoHQWk1Us5vpg8FYX6agKHNA8A5U=CHtOMTxzObnbqhdPyYQ@mail.gmail.com>

Java EE 7 HOL is failing to deploy on WildFly 8.2:

12:08:38,801 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8)
MSC000001: Failed to start service
jboss.deployment.unit."movieplex7-1.0-SNAPSHOT.war".WeldStartService:
org.jboss.msc.service.StartException in service
jboss.deployment.unit."movieplex7-1.0-SNAPSHOT.war".WeldStartService:
Failed to start service

at
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
[jboss-msc-1.2.2.Final.jar:1.2.2.Final]

at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[rt.jar:1.8.0_20]

at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[rt.jar:1.8.0_20]

at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]

Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-000072: Bean
declaring a passivating scope must be passivation capable.  Bean:  Managed
Bean [class org.javaee7.movieplex7.booking.Booking] with qualifiers
[@Default @Any @Named]

at org.jboss.weld.bean.ManagedBean.checkType(ManagedBean.java:203)

at
org.jboss.weld.bean.AbstractBean.initializeAfterBeanDiscovery(AbstractBean.java:105)

at
org.jboss.weld.bean.ManagedBean.initializeAfterBeanDiscovery(ManagedBean.java:113)

at
org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:136)

at
org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:127)

at
org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)

at
org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)

at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[rt.jar:1.8.0_20]

... 3 more


Its complaining for the bean defined at:

https://github.com/javaee-samples/javaee7-hol/blob/master/solution/movieplex7/src/main/java/org/javaee7/movieplex7/booking/Booking.java

This has worked, and is still working fine, on WildFly 8.1.

Thoughts ?

Arun
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141126/3ea02a96/attachment.html 

From jason.greene at redhat.com  Wed Nov 26 15:51:13 2014
From: jason.greene at redhat.com (Jason Greene)
Date: Wed, 26 Nov 2014 14:51:13 -0600
Subject: [wildfly-dev] IMPORTANT: First overview of changes to
	jboss-ejb-client 3.0 for WildFly 10 (probably)
In-Reply-To: <547621FB.3050107@redhat.com>
References: <547621FB.3050107@redhat.com>
Message-ID: <87CF180C-9368-4B77-A985-050DE16880DA@redhat.com>



> On Nov 26, 2014, at 12:54 PM, David M. Lloyd <david.lloyd at redhat.com> wrote:
> 
> I don't want to commit this to a specific WildFly release but I guess 
> and hope it'll come in around WildFly 10 or so (definitely not 9).
> 
> As previously discussed, the EJB client architecture is undergoing the 
> following substantial changes:

Could you give an overview of how applications that are using only standard APIs would be affected?

As an example, the scope stuff was all config driven, so I imagine that for most users this will just be property changes, and there existing code will most likely work as is.


> 
> ? Introduction of URIAffinity, and URI-based invocation
> ? Expansion of the 'ejb' JNDI initial context to auto-associate the 
> PROVIDER_URL as the URI affinity for looked-up proxies
> ? Elimination of all "nested" EJB client context functionality
> ? Integration with Elytron for client identity management
> ? Deferral to Remoting for automatic connection management
> ? Unification of client configuration, so the Elytron authentication 
> client, Remoting connection management, remote transaction client, and 
> EJB client configurations all can be configured in one file or 
> deployment descriptor
> 
> As such, I've introduced a 2.x branch for upstream where continued 
> development of the 2.x series will take place.  The "master" branch is 
> being re-purposed towards this new development, targeted for 3.x of this 
> library.
> 
> There are a number of compatibility considerations from 2.x to 3.x. 
> Most (I hope) existing client code (which avoids specialized manual 
> configuration or nested client contexts) should continue to function 
> as-is, with the following exceptions:
> 
> ? The following classes and interfaces are currently removed in my 
> working copy:
>    ? ClusterContext - replaced with discovery (?)
>    ? ClusterNodeManager - replaced with discovery
> 
>    ? ClusterNodeSelector - replaced with discovery
>    ? DeploymentNodeSelector - replaced with discovery
> 
>    ? ContextSelector - replaced with general selector class
>    ? ConstantContextSelector
>    ? IdentityEJBClientContextSelector
>    ? ThreadLocalContextSelector
> 
>    ? EJBClientContextInitializer - no replacement
>    ? DefaultInterceptorsClientContextInitializer
>    ? TransactionRecoveryContextInitializer
> 
>    ? EJBClientContextIdentifier - no replacement
>    ? NamedEJBClientContextIdentifier
> 
>    ? DefaultCallbackHandler - no replacement
> 
>    ? EJBClientConfiguration - replaced with context builder
>    ? PropertiesBasedEJBClientConfiguration
> 
>    ? EJBClientContextListener - no replacement
>    ? EJBClientInterceptor.Registration - no replacement (interceptor 
> set cannot be changed)
>    ? EJBClient*TransactionContext - replaced by 
> wildfly-transaction-client facility
>    ? EJBReceiverContext - no replacement
>    ? ReceiverInterceptor - no replacement (internal class)
> 
>    ? ALL public classes in the org.jboss.ejb.client.remoting package 
> including ReconnectHandler
> 
> ? The following changes will be made to these core classes and interfaces:
>    ? EJBClient
>       ? Added more createSession() variants to support new affinity types
>       ? Change createSession() methods to throw CreateException instead 
> of Exception
>       ? Remove createProxy() and createSession() variants which accept 
> EJBClientContextIdentifier
>       ? Remove getEJBClientContextIdentifierFor() method
>    ? Attachable
>       ? Remove getAttachments() method
>    ? EJBClientContext
>       ? No longer implements Closeable
>       ? Remove close() method
>       ? Remove all static create() methods, replaced with Builder class
>       ? Remove finalize() method
>       ? Remove getClusterContext(), getEJBClientConfiguration(), 
> getOrCreateClusterContext(), removeCluster()
>       ? Remove selector-related methods, replaced with general Selector 
> class
>       ? Remove register*() and unregister*() methods (providers are 
> added to Builder)
>       ? Remove require() method which accepts EJBClientContextIdentifier
>       ? Add getInvocationTimeout() method
>    ? Affinity
>       ? Add forUri() factory method
>    ? EJBClientInvocationContext
>       ? Add getCompressionLevel(), isClientAsync(), and isIdempotent() 
> query methods
>       ? Remove finalize()
>    ? EJB*Locator classes
>       ? Additional constructors which also accept an affinity
>       ? Additional "copy" constructors which accept a locator and 
> affinity, to change the target affinity
>    ? EJBReceiver class
>       ? openSession() method changed to accept a stateless EJB locator
>       ? Constructor changed to no args
>       ? Remove all send*() and other methods related to transactions
>       ? Remove associate(), getNodeName(), [de]registerModule(), exists()
>    ? EJBReceiverInvocationContext
>       ? Remove retryInvocation() method
>       ? Remove getEjbReceiverContext() method
>       ? Remove getNodeName() method
>    ? EJBMetaDataImpl
>       ? Deprecated, changed to not use raw types
>    ? RequestSendFailedException
>       ? Replaced constructor with standard exception four-constructor setup
> ? The following API classes are added:
>    ? EJBClientPermission - a general permission class
>    ? AbstractEJBMetaData - type-safe hierarchical version of 
> EJBMetaDataImpl
>    ? EJBClientContext.Builder - forwards-compatible builder for 
> EJBClientContext
>    ? EJBDiscoveryProvider - an interface to provide pluggable discovery
>    ? EJBTransportProvider - an interface to provide URI-compatible 
> transport (factory for EJBReceivers)
>    ? URIAffinity - a type of affinity which has a URI for a target
> 
> Note in particular that most of the cluster-support infrastructure is 
> presently removed with no replacement.  It is my hope and intent that 
> the discovery infrastructure will be able to take over this function. 
> How much of the code will be new, compared to how much of the code can 
> be forward-ported and reintroduced from 2.x, remains to be discussed.
> 
> At present, the plan is for wire compatibility to be supported for 2.x 
> clients talking to 3.x servers and vice-versa.
> 
> Transaction handling will be relegated to a separate 
> wildfly-transaction-client API.  However the getUserTransaction(node) 
> method will continue to be supported as a deprecated delegation to the 
> transaction-client API.  In addition, when talking to a 2.x server, it 
> is expected that a wildfly-transaction-client SPI implementation will 
> piggyback on the existing EJB protocol transaction messages.
> 
> If any of these API changes seems unacceptable, now is the time to 
> discuss it.  All the code that was removed was determined to be tied too 
> tightly to the previous location or configuration strategy, and thus 
> couldn't sensibly be supported going forward.  I have hopefully been 
> adequately upfront about what I intended to remove or support going 
> forward.  In addition, by supporting the 2.x client, most migration 
> concerns can hopefully be mitigated.  But it's possible that some 
> classes or methods could indeed be reintroduced with sensible semantics 
> and in such a way as to not cause problems; if you have any thoughts 
> along these lines, please share them and we can discuss them on a 
> case-by-case basis.
> 
> I've pushed up the proposed baseline 3.0 API at 
> https://github.com/dmlloyd/jboss-ejb-client/tree/uri_invocation for 
> review.  I intend for pull requests that are relevant to both old and 
> new code bases to be applied to both if possible, to avoid increasing 
> the incompatibility window even further.
> 
> -- 
> - DML
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

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



From stuart.w.douglas at gmail.com  Wed Nov 26 16:20:51 2014
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Wed, 26 Nov 2014 21:20:51 +0000
Subject: [wildfly-dev] Regression in Java EE 7 HOL
References: <CAGBoHQWk1Us5vpg8FYX6agKHNA8A5U=CHtOMTxzObnbqhdPyYQ@mail.gmail.com>
Message-ID: <CAAoo=c6yobkkU-hQOFPae-dxtJNxPno9EZsCXbwJ8_wo-pj7Vw@mail.gmail.com>

Its probably related to the CDI upgrade. At a guess I would say thinks the
bean is not passivation capable because of the EntityManager injection.

I think this is a Weld bug, but Jozef (in CC) would know more.

Stuart

On Thu Nov 27 2014 at 7:25:31 AM Arun Gupta <arun.gupta at gmail.com> wrote:

> Java EE 7 HOL is failing to deploy on WildFly 8.2:
>
> 12:08:38,801 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8)
> MSC000001: Failed to start service
> jboss.deployment.unit."movieplex7-1.0-SNAPSHOT.war".WeldStartService:
> org.jboss.msc.service.StartException in service
> jboss.deployment.unit."movieplex7-1.0-SNAPSHOT.war".WeldStartService:
> Failed to start service
>
> at
> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
>
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [rt.jar:1.8.0_20]
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [rt.jar:1.8.0_20]
>
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
>
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-000072:
> Bean declaring a passivating scope must be passivation capable.  Bean:
> Managed Bean [class org.javaee7.movieplex7.booking.Booking] with qualifiers
> [@Default @Any @Named]
>
> at org.jboss.weld.bean.ManagedBean.checkType(ManagedBean.java:203)
>
> at
> org.jboss.weld.bean.AbstractBean.initializeAfterBeanDiscovery(AbstractBean.java:105)
>
> at
> org.jboss.weld.bean.ManagedBean.initializeAfterBeanDiscovery(ManagedBean.java:113)
>
> at
> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:136)
>
> at
> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:127)
>
> at
> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
>
> at
> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
>
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [rt.jar:1.8.0_20]
>
> ... 3 more
>
>
> Its complaining for the bean defined at:
>
>
> https://github.com/javaee-samples/javaee7-hol/blob/master/solution/movieplex7/src/main/java/org/javaee7/movieplex7/booking/Booking.java
>
> This has worked, and is still working fine, on WildFly 8.1.
>
> Thoughts ?
>
> Arun
> _______________________________________________
> 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/20141126/a52a41af/attachment.html 

From stuart.w.douglas at gmail.com  Wed Nov 26 16:24:10 2014
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Wed, 26 Nov 2014 21:24:10 +0000
Subject: [wildfly-dev] IMPORTANT: First overview of changes to
 jboss-ejb-client 3.0 for WildFly 10 (probably)
References: <547621FB.3050107@redhat.com>
Message-ID: <CAAoo=c5apZSfWGwOADDRhROTT3ZnQ0-1rfw7S-tZSAjcnn3uoA@mail.gmail.com>

Is there any documentation somewhere about the new design (I am talking
about a broad overview rather than changes to specific classes)?

Stuart

On Thu Nov 27 2014 at 5:55:16 AM David M. Lloyd <david.lloyd at redhat.com>
wrote:

> I don't want to commit this to a specific WildFly release but I guess
> and hope it'll come in around WildFly 10 or so (definitely not 9).
>
> As previously discussed, the EJB client architecture is undergoing the
> following substantial changes:
>
> ? Introduction of URIAffinity, and URI-based invocation
> ? Expansion of the 'ejb' JNDI initial context to auto-associate the
> PROVIDER_URL as the URI affinity for looked-up proxies
> ? Elimination of all "nested" EJB client context functionality
> ? Integration with Elytron for client identity management
> ? Deferral to Remoting for automatic connection management
> ? Unification of client configuration, so the Elytron authentication
> client, Remoting connection management, remote transaction client, and
> EJB client configurations all can be configured in one file or
> deployment descriptor
>
> As such, I've introduced a 2.x branch for upstream where continued
> development of the 2.x series will take place.  The "master" branch is
> being re-purposed towards this new development, targeted for 3.x of this
> library.
>
> There are a number of compatibility considerations from 2.x to 3.x.
> Most (I hope) existing client code (which avoids specialized manual
> configuration or nested client contexts) should continue to function
> as-is, with the following exceptions:
>
> ? The following classes and interfaces are currently removed in my
> working copy:
>     ? ClusterContext - replaced with discovery (?)
>     ? ClusterNodeManager - replaced with discovery
>
>     ? ClusterNodeSelector - replaced with discovery
>     ? DeploymentNodeSelector - replaced with discovery
>
>     ? ContextSelector - replaced with general selector class
>     ? ConstantContextSelector
>     ? IdentityEJBClientContextSelector
>     ? ThreadLocalContextSelector
>
>     ? EJBClientContextInitializer - no replacement
>     ? DefaultInterceptorsClientContextInitializer
>     ? TransactionRecoveryContextInitializer
>
>     ? EJBClientContextIdentifier - no replacement
>     ? NamedEJBClientContextIdentifier
>
>     ? DefaultCallbackHandler - no replacement
>
>     ? EJBClientConfiguration - replaced with context builder
>     ? PropertiesBasedEJBClientConfiguration
>
>     ? EJBClientContextListener - no replacement
>     ? EJBClientInterceptor.Registration - no replacement (interceptor
> set cannot be changed)
>     ? EJBClient*TransactionContext - replaced by
> wildfly-transaction-client facility
>     ? EJBReceiverContext - no replacement
>     ? ReceiverInterceptor - no replacement (internal class)
>
>     ? ALL public classes in the org.jboss.ejb.client.remoting package
> including ReconnectHandler
>
> ? The following changes will be made to these core classes and interfaces:
>     ? EJBClient
>        ? Added more createSession() variants to support new affinity types
>        ? Change createSession() methods to throw CreateException instead
> of Exception
>        ? Remove createProxy() and createSession() variants which accept
> EJBClientContextIdentifier
>        ? Remove getEJBClientContextIdentifierFor() method
>     ? Attachable
>        ? Remove getAttachments() method
>     ? EJBClientContext
>        ? No longer implements Closeable
>        ? Remove close() method
>        ? Remove all static create() methods, replaced with Builder class
>        ? Remove finalize() method
>        ? Remove getClusterContext(), getEJBClientConfiguration(),
> getOrCreateClusterContext(), removeCluster()
>        ? Remove selector-related methods, replaced with general Selector
> class
>        ? Remove register*() and unregister*() methods (providers are
> added to Builder)
>        ? Remove require() method which accepts EJBClientContextIdentifier
>        ? Add getInvocationTimeout() method
>     ? Affinity
>        ? Add forUri() factory method
>     ? EJBClientInvocationContext
>        ? Add getCompressionLevel(), isClientAsync(), and isIdempotent()
> query methods
>        ? Remove finalize()
>     ? EJB*Locator classes
>        ? Additional constructors which also accept an affinity
>        ? Additional "copy" constructors which accept a locator and
> affinity, to change the target affinity
>     ? EJBReceiver class
>        ? openSession() method changed to accept a stateless EJB locator
>        ? Constructor changed to no args
>        ? Remove all send*() and other methods related to transactions
>        ? Remove associate(), getNodeName(), [de]registerModule(), exists()
>     ? EJBReceiverInvocationContext
>        ? Remove retryInvocation() method
>        ? Remove getEjbReceiverContext() method
>        ? Remove getNodeName() method
>     ? EJBMetaDataImpl
>        ? Deprecated, changed to not use raw types
>     ? RequestSendFailedException
>        ? Replaced constructor with standard exception four-constructor
> setup
> ? The following API classes are added:
>     ? EJBClientPermission - a general permission class
>     ? AbstractEJBMetaData - type-safe hierarchical version of
> EJBMetaDataImpl
>     ? EJBClientContext.Builder - forwards-compatible builder for
> EJBClientContext
>     ? EJBDiscoveryProvider - an interface to provide pluggable discovery
>     ? EJBTransportProvider - an interface to provide URI-compatible
> transport (factory for EJBReceivers)
>     ? URIAffinity - a type of affinity which has a URI for a target
>
> Note in particular that most of the cluster-support infrastructure is
> presently removed with no replacement.  It is my hope and intent that
> the discovery infrastructure will be able to take over this function.
> How much of the code will be new, compared to how much of the code can
> be forward-ported and reintroduced from 2.x, remains to be discussed.
>
> At present, the plan is for wire compatibility to be supported for 2.x
> clients talking to 3.x servers and vice-versa.
>
> Transaction handling will be relegated to a separate
> wildfly-transaction-client API.  However the getUserTransaction(node)
> method will continue to be supported as a deprecated delegation to the
> transaction-client API.  In addition, when talking to a 2.x server, it
> is expected that a wildfly-transaction-client SPI implementation will
> piggyback on the existing EJB protocol transaction messages.
>
> If any of these API changes seems unacceptable, now is the time to
> discuss it.  All the code that was removed was determined to be tied too
> tightly to the previous location or configuration strategy, and thus
> couldn't sensibly be supported going forward.  I have hopefully been
> adequately upfront about what I intended to remove or support going
> forward.  In addition, by supporting the 2.x client, most migration
> concerns can hopefully be mitigated.  But it's possible that some
> classes or methods could indeed be reintroduced with sensible semantics
> and in such a way as to not cause problems; if you have any thoughts
> along these lines, please share them and we can discuss them on a
> case-by-case basis.
>
> I've pushed up the proposed baseline 3.0 API at
> https://github.com/dmlloyd/jboss-ejb-client/tree/uri_invocation for
> review.  I intend for pull requests that are relevant to both old and
> new code bases to be applied to both if possible, to avoid increasing
> the incompatibility window even further.
>
> --
> - 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/20141126/fadad575/attachment-0001.html 

From david.lloyd at redhat.com  Wed Nov 26 17:05:24 2014
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Wed, 26 Nov 2014 16:05:24 -0600
Subject: [wildfly-dev] IMPORTANT: First overview of changes to
 jboss-ejb-client 3.0 for WildFly 10 (probably)
In-Reply-To: <CAAoo=c5apZSfWGwOADDRhROTT3ZnQ0-1rfw7S-tZSAjcnn3uoA@mail.gmail.com>
References: <547621FB.3050107@redhat.com>
	<CAAoo=c5apZSfWGwOADDRhROTT3ZnQ0-1rfw7S-tZSAjcnn3uoA@mail.gmail.com>
Message-ID: <54764EA4.80203@redhat.com>

No, nothing assembled in one place other than a couple etherpads and 
(IIRC) previous emails to this list and the discussion from last year's 
meeting in Brno.

The core design elements basically change like this:

? Add URIAffinity, including ensuring that affinity is part of 
equals/hashCode for all locators
? Existing node/cluster affinity becomes equivalent to the URI schemes 
"node:xxx" and "cluster:xxx" (presently I am retaining the classes 
though, and creating a URI affinity with one of these schemes 
automatically creates Node/ClusterAffinity instances for maximum 
compatibility)
? Extract transactions out of EJB and into a separate mechanism (either 
part of Remoting or a separate client lib); EJB invocations still carry 
transaction associations though
? Remote protocol implements "remote" schemas
? Add discovery for resolving Affinity.NONE EJBs and 
"node:xxx"/"cluster:xxx" into "remote:" schemas (first impl will simply 
be config-driven static "discovery", which should allow most existing 
code to run unchanged)
? Compatibility protocol ties into discovery mechanism for equivalent 
functionality to previous versions
? Generally eliminate or modify all SPI code that makes special 
assumptions about location outside of URIs
? A "local:"/Affinity.LOCAL is added so that discovery can be used to 
map "self" URLs ("remote:" URLs that refer to the calling container) 
back to the local container, if a matching EJBReceiver is installed

Otherwise things are largely the same.  The configuration stuff ties in, 
but it's not centrally important to the design.  We'd rely on Remoting 
to maintain connections, which would be established by URI and shared 
among services like we discussed.  Elytron does all the authentication 
(including association of identity for each invocation); EJB no longer 
needs to be aware of that.  The interceptor structure is basically 
unchanged.

I think that's it.  It's pretty simple at its core - it's basically 90% 
just code simplification - though I feel like I haven't explained it 
very well at all. :)

On 11/26/2014 03:24 PM, Stuart Douglas wrote:
> Is there any documentation somewhere about the new design (I am talking
> about a broad overview rather than changes to specific classes)?
>
> Stuart
>
> On Thu Nov 27 2014 at 5:55:16 AM David M. Lloyd <david.lloyd at redhat.com
> <mailto:david.lloyd at redhat.com>> wrote:
>
>     I don't want to commit this to a specific WildFly release but I guess
>     and hope it'll come in around WildFly 10 or so (definitely not 9).
>
>     As previously discussed, the EJB client architecture is undergoing the
>     following substantial changes:
>
>     ? Introduction of URIAffinity, and URI-based invocation
>     ? Expansion of the 'ejb' JNDI initial context to auto-associate the
>     PROVIDER_URL as the URI affinity for looked-up proxies
>     ? Elimination of all "nested" EJB client context functionality
>     ? Integration with Elytron for client identity management
>     ? Deferral to Remoting for automatic connection management
>     ? Unification of client configuration, so the Elytron authentication
>     client, Remoting connection management, remote transaction client, and
>     EJB client configurations all can be configured in one file or
>     deployment descriptor
>
>     As such, I've introduced a 2.x branch for upstream where continued
>     development of the 2.x series will take place.  The "master" branch is
>     being re-purposed towards this new development, targeted for 3.x of this
>     library.
>
>     There are a number of compatibility considerations from 2.x to 3.x.
>     Most (I hope) existing client code (which avoids specialized manual
>     configuration or nested client contexts) should continue to function
>     as-is, with the following exceptions:
>
>     ? The following classes and interfaces are currently removed in my
>     working copy:
>          ? ClusterContext - replaced with discovery (?)
>          ? ClusterNodeManager - replaced with discovery
>
>          ? ClusterNodeSelector - replaced with discovery
>          ? DeploymentNodeSelector - replaced with discovery
>
>          ? ContextSelector - replaced with general selector class
>          ? ConstantContextSelector
>          ? IdentityEJBClientContextSelect__or
>          ? ThreadLocalContextSelector
>
>          ? EJBClientContextInitializer - no replacement
>          ? DefaultInterceptorsClientConte__xtInitializer
>          ? TransactionRecoveryContextInit__ializer
>
>          ? EJBClientContextIdentifier - no replacement
>          ? NamedEJBClientContextIdentifie__r
>
>          ? DefaultCallbackHandler - no replacement
>
>          ? EJBClientConfiguration - replaced with context builder
>          ? PropertiesBasedEJBClientConfig__uration
>
>          ? EJBClientContextListener - no replacement
>          ? EJBClientInterceptor.__Registration - no replacement (interceptor
>     set cannot be changed)
>          ? EJBClient*TransactionContext - replaced by
>     wildfly-transaction-client facility
>          ? EJBReceiverContext - no replacement
>          ? ReceiverInterceptor - no replacement (internal class)
>
>          ? ALL public classes in the org.jboss.ejb.client.remoting package
>     including ReconnectHandler
>
>     ? The following changes will be made to these core classes and
>     interfaces:
>          ? EJBClient
>             ? Added more createSession() variants to support new
>     affinity types
>             ? Change createSession() methods to throw CreateException
>     instead
>     of Exception
>             ? Remove createProxy() and createSession() variants which accept
>     EJBClientContextIdentifier
>             ? Remove getEJBClientContextIdentifierF__or() method
>          ? Attachable
>             ? Remove getAttachments() method
>          ? EJBClientContext
>             ? No longer implements Closeable
>             ? Remove close() method
>             ? Remove all static create() methods, replaced with Builder
>     class
>             ? Remove finalize() method
>             ? Remove getClusterContext(), getEJBClientConfiguration(),
>     getOrCreateClusterContext(), removeCluster()
>             ? Remove selector-related methods, replaced with general
>     Selector
>     class
>             ? Remove register*() and unregister*() methods (providers are
>     added to Builder)
>             ? Remove require() method which accepts
>     EJBClientContextIdentifier
>             ? Add getInvocationTimeout() method
>          ? Affinity
>             ? Add forUri() factory method
>          ? EJBClientInvocationContext
>             ? Add getCompressionLevel(), isClientAsync(), and isIdempotent()
>     query methods
>             ? Remove finalize()
>          ? EJB*Locator classes
>             ? Additional constructors which also accept an affinity
>             ? Additional "copy" constructors which accept a locator and
>     affinity, to change the target affinity
>          ? EJBReceiver class
>             ? openSession() method changed to accept a stateless EJB locator
>             ? Constructor changed to no args
>             ? Remove all send*() and other methods related to transactions
>             ? Remove associate(), getNodeName(), [de]registerModule(),
>     exists()
>          ? EJBReceiverInvocationContext
>             ? Remove retryInvocation() method
>             ? Remove getEjbReceiverContext() method
>             ? Remove getNodeName() method
>          ? EJBMetaDataImpl
>             ? Deprecated, changed to not use raw types
>          ? RequestSendFailedException
>             ? Replaced constructor with standard exception
>     four-constructor setup
>     ? The following API classes are added:
>          ? EJBClientPermission - a general permission class
>          ? AbstractEJBMetaData - type-safe hierarchical version of
>     EJBMetaDataImpl
>          ? EJBClientContext.Builder - forwards-compatible builder for
>     EJBClientContext
>          ? EJBDiscoveryProvider - an interface to provide pluggable
>     discovery
>          ? EJBTransportProvider - an interface to provide URI-compatible
>     transport (factory for EJBReceivers)
>          ? URIAffinity - a type of affinity which has a URI for a target
>
>     Note in particular that most of the cluster-support infrastructure is
>     presently removed with no replacement.  It is my hope and intent that
>     the discovery infrastructure will be able to take over this function.
>     How much of the code will be new, compared to how much of the code can
>     be forward-ported and reintroduced from 2.x, remains to be discussed.
>
>     At present, the plan is for wire compatibility to be supported for 2.x
>     clients talking to 3.x servers and vice-versa.
>
>     Transaction handling will be relegated to a separate
>     wildfly-transaction-client API.  However the getUserTransaction(node)
>     method will continue to be supported as a deprecated delegation to the
>     transaction-client API.  In addition, when talking to a 2.x server, it
>     is expected that a wildfly-transaction-client SPI implementation will
>     piggyback on the existing EJB protocol transaction messages.
>
>     If any of these API changes seems unacceptable, now is the time to
>     discuss it.  All the code that was removed was determined to be tied too
>     tightly to the previous location or configuration strategy, and thus
>     couldn't sensibly be supported going forward.  I have hopefully been
>     adequately upfront about what I intended to remove or support going
>     forward.  In addition, by supporting the 2.x client, most migration
>     concerns can hopefully be mitigated.  But it's possible that some
>     classes or methods could indeed be reintroduced with sensible semantics
>     and in such a way as to not cause problems; if you have any thoughts
>     along these lines, please share them and we can discuss them on a
>     case-by-case basis.
>
>     I've pushed up the proposed baseline 3.0 API at
>     https://github.com/dmlloyd/__jboss-ejb-client/tree/uri___invocation
>     <https://github.com/dmlloyd/jboss-ejb-client/tree/uri_invocation> for
>     review.  I intend for pull requests that are relevant to both old and
>     new code bases to be applied to both if possible, to avoid increasing
>     the incompatibility window even further.
>
>     --
>     - 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
>     <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>

-- 
- DML

From david.lloyd at redhat.com  Wed Nov 26 17:11:48 2014
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Wed, 26 Nov 2014 16:11:48 -0600
Subject: [wildfly-dev] IMPORTANT: First overview of changes to
 jboss-ejb-client 3.0 for WildFly 10 (probably)
In-Reply-To: <87CF180C-9368-4B77-A985-050DE16880DA@redhat.com>
References: <547621FB.3050107@redhat.com>
	<87CF180C-9368-4B77-A985-050DE16880DA@redhat.com>
Message-ID: <54765024.9020007@redhat.com>

On 11/26/2014 02:51 PM, Jason Greene wrote:
>> On Nov 26, 2014, at 12:54 PM, David M. Lloyd <david.lloyd at redhat.com> wrote:
>>
>> I don't want to commit this to a specific WildFly release but I guess
>> and hope it'll come in around WildFly 10 or so (definitely not 9).
>>
>> As previously discussed, the EJB client architecture is undergoing the
>> following substantial changes:
>
> Could you give an overview of how applications that are using only standard APIs would be affected?

I believe that as long as code isn't touching nested client contexts, 
most client code should work unchanged; at least, that's the intent. 
That's why I did the in-depth change analysis (I used 
japi-compliance-checker to derive the list of changes on the original mail).

> As an example, the scope stuff was all config driven, so I imagine that for most users this will just be property changes, and there existing code will most likely work as is.

Yeah.  I haven't done *anything* with the existing property-based config 
format though; I think this would have to be a compatibility module for 
the shared config stuff, something that lives in ejb-client and runs if 
the new client XML config isn't found, as a fallback.  I'm pretty 
confident that we can do that without too much trouble though.

I'm hoping that by getting out ahead of this, we can flush out any 
compatibility surprises before everything is in .final though.
-- 
- DML

From eduardo.santanadasilva at gmail.com  Wed Nov 26 17:12:54 2014
From: eduardo.santanadasilva at gmail.com (=?UTF-8?Q?Eduardo_Sant=C2=B4Ana_da_Silva?=)
Date: Wed, 26 Nov 2014 20:12:54 -0200
Subject: [wildfly-dev] Regression in Java EE 7 HOL
In-Reply-To: <CAAoo=c6yobkkU-hQOFPae-dxtJNxPno9EZsCXbwJ8_wo-pj7Vw@mail.gmail.com>
References: <CAGBoHQWk1Us5vpg8FYX6agKHNA8A5U=CHtOMTxzObnbqhdPyYQ@mail.gmail.com>
	<CAAoo=c6yobkkU-hQOFPae-dxtJNxPno9EZsCXbwJ8_wo-pj7Vw@mail.gmail.com>
Message-ID: <CAFVp3Z6WT2trnj7-UTMVmYq9hC_qMkFt8SBsHtquqFrK2oudVA@mail.gmail.com>

Arun,

I got rid of this error implementing the Serializable interface on the bean
that you specified.

              public class Booking implements Serializable {

But there are other errors that probably is related with what Stuart said:


org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied
dependencies for type JMSContext with qualifiers @Default

  at injection point [BackedAnnotatedField] @Inject
org.javaee7.movieplex7.points.ReceivePointsBean.context

  at
org.javaee7.movieplex7.points.ReceivePointsBean.context(ReceivePointsBean.java:0)

...


Regards,
Eduardo Sant'Ana da Silva

2014-11-26 19:20 GMT-02:00 Stuart Douglas <stuart.w.douglas at gmail.com>:

> Its probably related to the CDI upgrade. At a guess I would say thinks the
> bean is not passivation capable because of the EntityManager injection.
>
> I think this is a Weld bug, but Jozef (in CC) would know more.
>
> Stuart
>
> On Thu Nov 27 2014 at 7:25:31 AM Arun Gupta <arun.gupta at gmail.com> wrote:
>
>> Java EE 7 HOL is failing to deploy on WildFly 8.2:
>>
>> 12:08:38,801 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8)
>> MSC000001: Failed to start service
>> jboss.deployment.unit."movieplex7-1.0-SNAPSHOT.war".WeldStartService:
>> org.jboss.msc.service.StartException in service
>> jboss.deployment.unit."movieplex7-1.0-SNAPSHOT.war".WeldStartService:
>> Failed to start service
>>
>> at
>> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
>> [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
>>
>> at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>> [rt.jar:1.8.0_20]
>>
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> [rt.jar:1.8.0_20]
>>
>> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
>>
>> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-000072:
>> Bean declaring a passivating scope must be passivation capable.  Bean:
>> Managed Bean [class org.javaee7.movieplex7.booking.Booking] with qualifiers
>> [@Default @Any @Named]
>>
>> at org.jboss.weld.bean.ManagedBean.checkType(ManagedBean.java:203)
>>
>> at
>> org.jboss.weld.bean.AbstractBean.initializeAfterBeanDiscovery(AbstractBean.java:105)
>>
>> at
>> org.jboss.weld.bean.ManagedBean.initializeAfterBeanDiscovery(ManagedBean.java:113)
>>
>> at
>> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:136)
>>
>> at
>> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:127)
>>
>> at
>> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
>>
>> at
>> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
>>
>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>> [rt.jar:1.8.0_20]
>>
>> ... 3 more
>>
>>
>> Its complaining for the bean defined at:
>>
>>
>> https://github.com/javaee-samples/javaee7-hol/blob/master/solution/movieplex7/src/main/java/org/javaee7/movieplex7/booking/Booking.java
>>
>> This has worked, and is still working fine, on WildFly 8.1.
>>
>> Thoughts ?
>>
>> Arun
>> _______________________________________________
>> 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
>



-- 
__________________________
Eduardo Sant'Ana da Silva - Dr.
Pesquisador / Consultor de TI
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141126/28cafe8e/attachment.html 

From jharting at redhat.com  Wed Nov 26 17:26:24 2014
From: jharting at redhat.com (Jozef Hartinger)
Date: Wed, 26 Nov 2014 23:26:24 +0100
Subject: [wildfly-dev] Regression in Java EE 7 HOL
In-Reply-To: <CAAoo=c6yobkkU-hQOFPae-dxtJNxPno9EZsCXbwJ8_wo-pj7Vw@mail.gmail.com>
References: <CAGBoHQWk1Us5vpg8FYX6agKHNA8A5U=CHtOMTxzObnbqhdPyYQ@mail.gmail.com>
	<CAAoo=c6yobkkU-hQOFPae-dxtJNxPno9EZsCXbwJ8_wo-pj7Vw@mail.gmail.com>
Message-ID: <54765390.1020607@redhat.com>

It's actually related to JSF upgrade. In the past @ViewScoped and 
@FlowScoped were not marked as passivating scopes but effectively they 
were as JSF was putting these objects into session (causing 
Serialization errors at runtime). In Mojarra 2.2.7 they fixed this [1] 
by defining these scopes as passivating.

Since these scopes are now passivating Weld checks whether they can 
really be passivated. Since Booking does not implement Serializable, 
Weld fails the deployment.

[1] https://java.net/jira/browse/JAVASERVERFACES-3250

On 11/26/2014 10:20 PM, Stuart Douglas wrote:
> Its probably related to the CDI upgrade. At a guess I would say thinks 
> the bean is not passivation capable because of the EntityManager 
> injection.
>
> I think this is a Weld bug, but Jozef (in CC) would know more.
>
> Stuart
>
> On Thu Nov 27 2014 at 7:25:31 AM Arun Gupta <arun.gupta at gmail.com 
> <mailto:arun.gupta at gmail.com>> wrote:
>
>     Java EE 7 HOL is failing to deploy on WildFly 8.2:
>
>     12:08:38,801 ERROR [org.jboss.msc.service.fail] (MSC service
>     thread 1-8) MSC000001: Failed to start service
>     jboss.deployment.unit."movieplex7-1.0-SNAPSHOT.war".WeldStartService:
>     org.jboss.msc.service.StartException in service
>     jboss.deployment.unit."movieplex7-1.0-SNAPSHOT.war".WeldStartService:
>     Failed to start service
>
>     at
>     org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
>     [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
>
>     at
>     java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>     [rt.jar:1.8.0_20]
>
>     at
>     java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>     [rt.jar:1.8.0_20]
>
>     at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
>
>     Caused by: org.jboss.weld.exceptions.DeploymentException:
>     WELD-000072: Bean declaring a passivating scope must be
>     passivation capable.  Bean:  Managed Bean [class
>     org.javaee7.movieplex7.booking.Booking] with qualifiers [@Default
>     @Any @Named]
>
>     at org.jboss.weld.bean.ManagedBean.checkType(ManagedBean.java:203)
>
>     at
>     org.jboss.weld.bean.AbstractBean.initializeAfterBeanDiscovery(AbstractBean.java:105)
>
>     at
>     org.jboss.weld.bean.ManagedBean.initializeAfterBeanDiscovery(ManagedBean.java:113)
>
>     at
>     org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:136)
>
>     at
>     org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:127)
>
>     at
>     org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
>
>     at
>     org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
>
>     at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>     [rt.jar:1.8.0_20]
>
>     ... 3 more
>
>
>     Its complaining for the bean defined at:
>
>     https://github.com/javaee-samples/javaee7-hol/blob/master/solution/movieplex7/src/main/java/org/javaee7/movieplex7/booking/Booking.java
>
>     This has worked, and is still working fine, on WildFly 8.1.
>
>     Thoughts ?
>
>     Arun
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

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

From stuart.w.douglas at gmail.com  Wed Nov 26 17:26:54 2014
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Thu, 27 Nov 2014 09:26:54 +1100
Subject: [wildfly-dev] Regression in Java EE 7 HOL
In-Reply-To: <CAFVp3Z6WT2trnj7-UTMVmYq9hC_qMkFt8SBsHtquqFrK2oudVA@mail.gmail.com>
References: <CAGBoHQWk1Us5vpg8FYX6agKHNA8A5U=CHtOMTxzObnbqhdPyYQ@mail.gmail.com>
	<CAAoo=c6yobkkU-hQOFPae-dxtJNxPno9EZsCXbwJ8_wo-pj7Vw@mail.gmail.com>
	<CAFVp3Z6WT2trnj7-UTMVmYq9hC_qMkFt8SBsHtquqFrK2oudVA@mail.gmail.com>
Message-ID: <547653AE.903@gmail.com>

Ah yea, of course the bean itself has to be Serializable to be 
passivation capable.

That error with JMSContext looks like you may be trying to deploy using 
standalone.xml when it needs standalone-full.xml (which includes JMS)?

Stuart

Eduardo Sant?Ana da Silva wrote:
> Arun,
>
> I got rid of this error implementing the Serializable interface on the
> bean that you specified.
>
>                public class Booking implements Serializable {
>
> But there are other errors that probably is related with what Stuart said:
>
>
> org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied
> dependencies for type JMSContext with qualifiers @Default
>
>    at injection point [BackedAnnotatedField] @Inject
> org.javaee7.movieplex7.points.ReceivePointsBean.context
>
>    at
> org.javaee7.movieplex7.points.ReceivePointsBean.context(ReceivePointsBean.java:0)
>
> ...
>
>
> Regards,
> Eduardo Sant'Ana da Silva
>
> 2014-11-26 19:20 GMT-02:00 Stuart Douglas <stuart.w.douglas at gmail.com
> <mailto:stuart.w.douglas at gmail.com>>:
>
>     Its probably related to the CDI upgrade. At a guess I would say
>     thinks the bean is not passivation capable because of the
>     EntityManager injection.
>
>     I think this is a Weld bug, but Jozef (in CC) would know more.
>
>     Stuart
>
>     On Thu Nov 27 2014 at 7:25:31 AM Arun Gupta <arun.gupta at gmail.com
>     <mailto:arun.gupta at gmail.com>> wrote:
>
>         Java EE 7 HOL is failing to deploy on WildFly 8.2:
>
>         12:08:38,801 ERROR [org.jboss.msc.service.fail] (MSC service
>         thread 1-8) MSC000001: Failed to start service
>         jboss.deployment.unit."movieplex7-1.0-SNAPSHOT.war".WeldStartService:
>         org.jboss.msc.service.StartException in service
>         jboss.deployment.unit."movieplex7-1.0-SNAPSHOT.war".WeldStartService:
>         Failed to start service
>
>         at
>         org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
>         [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
>
>         at
>         java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>         [rt.jar:1.8.0_20]
>
>         at
>         java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>         [rt.jar:1.8.0_20]
>
>         at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
>
>         Caused by: org.jboss.weld.exceptions.DeploymentException:
>         WELD-000072: Bean declaring a passivating scope must be
>         passivation capable.  Bean:  Managed Bean [class
>         org.javaee7.movieplex7.booking.Booking] with qualifiers
>         [@Default @Any @Named]
>
>         at org.jboss.weld.bean.ManagedBean.checkType(ManagedBean.java:203)
>
>         at
>         org.jboss.weld.bean.AbstractBean.initializeAfterBeanDiscovery(AbstractBean.java:105)
>
>         at
>         org.jboss.weld.bean.ManagedBean.initializeAfterBeanDiscovery(ManagedBean.java:113)
>
>         at
>         org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:136)
>
>         at
>         org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:127)
>
>         at
>         org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
>
>         at
>         org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
>
>         at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>         [rt.jar:1.8.0_20]
>
>         ... 3 more
>
>
>         Its complaining for the bean defined at:
>
>         https://github.com/javaee-samples/javaee7-hol/blob/master/solution/movieplex7/src/main/java/org/javaee7/movieplex7/booking/Booking.java
>
>         This has worked, and is still working fine, on WildFly 8.1.
>
>         Thoughts ?
>
>         Arun
>         _________________________________________________
>         wildfly-dev mailing list
>         wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>         https://lists.jboss.org/__mailman/listinfo/wildfly-dev
>         <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>
>
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
> --
> __________________________
> Eduardo Sant'Ana da Silva - Dr.
> Pesquisador / Consultor de TI
>

From arun.gupta at gmail.com  Wed Nov 26 18:08:37 2014
From: arun.gupta at gmail.com (Arun Gupta)
Date: Wed, 26 Nov 2014 15:08:37 -0800
Subject: [wildfly-dev] Regression in Java EE 7 HOL
In-Reply-To: <547653AE.903@gmail.com>
References: <CAGBoHQWk1Us5vpg8FYX6agKHNA8A5U=CHtOMTxzObnbqhdPyYQ@mail.gmail.com>
	<CAAoo=c6yobkkU-hQOFPae-dxtJNxPno9EZsCXbwJ8_wo-pj7Vw@mail.gmail.com>
	<CAFVp3Z6WT2trnj7-UTMVmYq9hC_qMkFt8SBsHtquqFrK2oudVA@mail.gmail.com>
	<547653AE.903@gmail.com>
Message-ID: <CAGBoHQUCO-HjJghjn4-7t=bObHHjrAu-YwuHybFERvFEPiCnQA@mail.gmail.com>

Adding "implements Serializable" fixed the issue and updated the
instructions at: https://github.com/javaee-samples/javaee7-hol

Thanks
Arun

On Wed, Nov 26, 2014 at 2:26 PM, Stuart Douglas
<stuart.w.douglas at gmail.com> wrote:
> Ah yea, of course the bean itself has to be Serializable to be passivation
> capable.
>
> That error with JMSContext looks like you may be trying to deploy using
> standalone.xml when it needs standalone-full.xml (which includes JMS)?
>
> Stuart
>
> Eduardo Sant?Ana da Silva wrote:
>>
>> Arun,
>>
>> I got rid of this error implementing the Serializable interface on the
>> bean that you specified.
>>
>>                public class Booking implements Serializable {
>>
>> But there are other errors that probably is related with what Stuart said:
>>
>>
>> org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied
>> dependencies for type JMSContext with qualifiers @Default
>>
>>    at injection point [BackedAnnotatedField] @Inject
>> org.javaee7.movieplex7.points.ReceivePointsBean.context
>>
>>    at
>>
>> org.javaee7.movieplex7.points.ReceivePointsBean.context(ReceivePointsBean.java:0)
>>
>> ...
>>
>>
>> Regards,
>> Eduardo Sant'Ana da Silva
>>
>> 2014-11-26 19:20 GMT-02:00 Stuart Douglas <stuart.w.douglas at gmail.com
>> <mailto:stuart.w.douglas at gmail.com>>:
>>
>>     Its probably related to the CDI upgrade. At a guess I would say
>>     thinks the bean is not passivation capable because of the
>>     EntityManager injection.
>>
>>     I think this is a Weld bug, but Jozef (in CC) would know more.
>>
>>     Stuart
>>
>>     On Thu Nov 27 2014 at 7:25:31 AM Arun Gupta <arun.gupta at gmail.com
>>     <mailto:arun.gupta at gmail.com>> wrote:
>>
>>         Java EE 7 HOL is failing to deploy on WildFly 8.2:
>>
>>         12:08:38,801 ERROR [org.jboss.msc.service.fail] (MSC service
>>         thread 1-8) MSC000001: Failed to start service
>>
>> jboss.deployment.unit."movieplex7-1.0-SNAPSHOT.war".WeldStartService:
>>         org.jboss.msc.service.StartException in service
>>
>> jboss.deployment.unit."movieplex7-1.0-SNAPSHOT.war".WeldStartService:
>>         Failed to start service
>>
>>         at
>>
>> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
>>         [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
>>
>>         at
>>
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>>         [rt.jar:1.8.0_20]
>>
>>         at
>>
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>>         [rt.jar:1.8.0_20]
>>
>>         at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
>>
>>         Caused by: org.jboss.weld.exceptions.DeploymentException:
>>         WELD-000072: Bean declaring a passivating scope must be
>>         passivation capable.  Bean:  Managed Bean [class
>>         org.javaee7.movieplex7.booking.Booking] with qualifiers
>>         [@Default @Any @Named]
>>
>>         at org.jboss.weld.bean.ManagedBean.checkType(ManagedBean.java:203)
>>
>>         at
>>
>> org.jboss.weld.bean.AbstractBean.initializeAfterBeanDiscovery(AbstractBean.java:105)
>>
>>         at
>>
>> org.jboss.weld.bean.ManagedBean.initializeAfterBeanDiscovery(ManagedBean.java:113)
>>
>>         at
>>
>> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:136)
>>
>>         at
>>
>> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:127)
>>
>>         at
>>
>> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
>>
>>         at
>>
>> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
>>
>>         at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>         [rt.jar:1.8.0_20]
>>
>>         ... 3 more
>>
>>
>>         Its complaining for the bean defined at:
>>
>>
>> https://github.com/javaee-samples/javaee7-hol/blob/master/solution/movieplex7/src/main/java/org/javaee7/movieplex7/booking/Booking.java
>>
>>         This has worked, and is still working fine, on WildFly 8.1.
>>
>>         Thoughts ?
>>
>>         Arun
>>         _________________________________________________
>>         wildfly-dev mailing list
>>         wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>         https://lists.jboss.org/__mailman/listinfo/wildfly-dev
>>         <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>>
>>
>>     _______________________________________________
>>     wildfly-dev mailing list
>>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
>>
>> --
>> __________________________
>> Eduardo Sant'Ana da Silva - Dr.
>> Pesquisador / Consultor de TI
>>
>



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


From manderse at redhat.com  Thu Nov 27 04:32:12 2014
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Thu, 27 Nov 2014 10:32:12 +0100
Subject: [wildfly-dev] JBAS011592 the logging subsystem requires the log
 manager to be org.jboss.logmanager.LogManager
In-Reply-To: <54736170.5050204@redhat.com>
References: <8619BFE7-73A8-414A-A1C7-9B3E0DBFC410@redhat.com>
	<54436B65.6060607@gmail.com> <54444DE6.3000705@redhat.com>
	<513BC043-2599-40A9-8C28-6574B29929C1@redhat.com>
	<55F7C7CE-078F-409A-8A47-0FEC83969361@redhat.com>
	<54733EA3.5070507@redhat.com>
	<A6C45C5E-308E-4C17-91FE-7FEEB60AA7B2@redhat.com>
	<54736170.5050204@redhat.com>
Message-ID: <01024322-E215-407F-8839-7DA6824E019D@redhat.com>

On 24 Nov 2014, at 17:48, David M. Lloyd wrote:

> On 11/24/2014 10:40 AM, Max Rydahl Andersen wrote:
>>>>>
>>>>> We do not do any agent funkyness afaik.
>>>>>
>>>>> And as said the "workaround" so far have been "restart it" and it
>>>>> works.
>>>>>
>>>>> zero changes to the state or arguments.
>>>>
>>>> okey so there been some new movement in this.
>>>>
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1037970
>>>>
>>>> Indicating there actually is a race condition if something pings 
>>>> the jvm
>>>> via jmx during the startup
>>>> *before* jboss main boot process manages to set the logmanager.
>>>> Something that will happen because
>>>> we actually have a feature that scans for locally running jvm's and
>>>> attach an agent to gather info.
>>>>
>>>> Suggested workaround is to add this to our launch:
>>>> JAVA_OPTS="$JAVA_OPTS
>>>> -Djava.util.logging.manager=org.jboss.logmanager.LogManager"
>>>> JAVA_OPTS="$JAVA_OPTS
>>>> -Xbootclasspath/p:$JBOSS_HOME/modules/org/jboss/logmanager/main/jboss-logmanager-1.3.1.Final-redhat-1.jar"
>>>>
>>>> -logging org.jboss.logmanager.LogManager
>>>>
>>>> Question from us is, is the above workaround proper ? Will 
>>>> EAP/WildFly
>>>> change their boot arguments to match to avoid this race condition 
>>>> issue
>>>> for bat/sh launched servers too ?
>>>
>>> No, there's a very good chance that will cause weird stuff to 
>>> happen,
>>> like two copies of the log manager being installed.  It may work,
>>> mostly, but this is not a risk-free solution.
>>
>> Yeah, that was what I feared...btw. this is what the official
>> recommendation is on the knowledge base article about this issue ;/
>>
>> But can you confirm that the issue is can and will happen if a remote
>> process tries to install an agent and even if the agent has zero 
>> jboss
>> logging usage
>> that can somehow result in jboss logging getting activated before it 
>> has
>> settings configured ?
>>
>> I'm just wondering what code actually is being invoked that needs 
>> this
>> log manager when we are installing an agent very early in the start 
>> up
>> phase ?
>
> Conceptually we don't need or want our log manager to be installed 
> until we have something interesting to log.  But, you only get one 
> chance to install the log manager, and the JVM initializes it whenever 
> it wants, so that's the basic summary of the problem.  The only way to 
> "beat" the JVM is to get in there ahead of it.
>
> You could theoretically dig in with reflection and swap out the log 
> manager after the fact, but then you'd also have to somehow swap out 
> all the loggers made with the original log manager, otherwise what 
> happens is some log messages just go missing.
>
> Another option is to install some kind of "proxy" log manager that has 
> a facility to swap out all the backing loggers.

and I assume there are some reason why the logmanager don't have a 
fallback default it will use until its fully configured ?  (i.e. to 
avoid this racecondition to result in full error/stopping of the server)

/max
http://about.me/maxandersen


From wfink at redhat.com  Fri Nov 28 09:59:01 2014
From: wfink at redhat.com (Wolf-Dieter Fink)
Date: Fri, 28 Nov 2014 15:59:01 +0100
Subject: [wildfly-dev] IMPORTANT: First overview of changes to
 jboss-ejb-client 3.0 for WildFly 10 (probably)
In-Reply-To: <547621FB.3050107@redhat.com>
References: <547621FB.3050107@redhat.com>
Message-ID: <54788DB5.3040001@redhat.com>

Hi David,

I'm looking more from the functional side not from the implementation.
So in general simplifying the code will make it better to understand.
 From my perspective we need to cover the requirements from our users 
and make it easy to handle.

I don't care whether we have different possibilities to configure the 
client. But the most important is to create a InitialContext programatic 
with properties and use it for all server actions.
This should be done with a minimum of properties, i.e. default SSL=off 
as there is a need to configure it correct at server side.

So I would assume that we deprecate the scoped-context and remote-naming 
complete and use the new approach.

I'll create a client project to show typical use-cases with the new API 
and check whether we cover the current issues.
For this I appreciate if you have some examples if the creation and 
handling for the client has changed.

BTW, is it possible to use the ejb-client 3.0 with current EAP/WildFly? 
Is there any restriction or dependency?
At the moment I'm not able to compile the project (branch 
uri_invocation), there is a missing dependency.
   org.wildfly.common:wildfly-common:jar:1.0.0.Beta1-SNAPSHOT


please find my other comments inline.

- Wolf

On 26/11/14 19:54, David M. Lloyd wrote:
> I don't want to commit this to a specific WildFly release but I guess
> and hope it'll come in around WildFly 10 or so (definitely not 9).
>
> As previously discussed, the EJB client architecture is undergoing the
> following substantial changes:
>
> ? Introduction of URIAffinity, and URI-based invocation
> ? Expansion of the 'ejb' JNDI initial context to auto-associate the
> PROVIDER_URL as the URI affinity for looked-up proxies
What does that mean?
Is it possible to use an InitialContext without any jboss-ejb-client 
configuration to be able to invoke ejb's and lookup other JNDI stuff 
like JMS with one IC and no redundant server properties?
> ? Elimination of all "nested" EJB client context functionality
> ? Integration with Elytron for client identity management
Does that mean the credentials for the connection and ejb invocation are 
decoupled?
Is there a possibility to use the old style CallBackHandler and/or being 
able to change the user for an existing remoting connection?
Also whether the credentials are used to invoke ejb's in a 
server-to-server communication and the user will be the invocation use 
of the first EJB and not the connection user?
> ? Deferral to Remoting for automatic connection management
> ? Unification of client configuration, so the Elytron authentication
> client, Remoting connection management, remote transaction client, and
> EJB client configurations all can be configured in one file or
> deployment descriptor
Great!
> As such, I've introduced a 2.x branch for upstream where continued
> development of the 2.x series will take place.  The "master" branch is
> being re-purposed towards this new development, targeted for 3.x of this
> library.
>
> There are a number of compatibility considerations from 2.x to 3.x.
> Most (I hope) existing client code (which avoids specialized manual
> configuration or nested client contexts) should continue to function
> as-is, with the following exceptions:
>
> ? The following classes and interfaces are currently removed in my
> working copy:
>      ? ClusterContext - replaced with discovery (?)
>      ? ClusterNodeManager - replaced with discovery
>
>      ? ClusterNodeSelector - replaced with discovery
>      ? DeploymentNodeSelector - replaced with discovery
As Cluster/Deployment NodeSelector is being removed and replaced by 
discovery this sounds to me that there is no possibility to customize 
the load-balancing process
This might affect some use-cases where such policy was implemented to 
control specific behaviour.

Does this mean also that the cluster configuration at client side is 
deprecated and not longer necessary?
Also the need to configure the cluster-name within the server 
configuration to distinguish between different clusters?
>      ? ContextSelector - replaced with general selector class
>      ? ConstantContextSelector
>      ? IdentityEJBClientContextSelector
>      ? ThreadLocalContextSelector
>
>      ? EJBClientContextInitializer - no replacement
>      ? DefaultInterceptorsClientContextInitializer
>      ? TransactionRecoveryContextInitializer
>
>      ? EJBClientContextIdentifier - no replacement
>      ? NamedEJBClientContextIdentifier
>
>      ? DefaultCallbackHandler - no replacement
>
>      ? EJBClientConfiguration - replaced with context builder
>      ? PropertiesBasedEJBClientConfiguration
>
>      ? EJBClientContextListener - no replacement
>      ? EJBClientInterceptor.Registration - no replacement (interceptor
> set cannot be changed)
>      ? EJBClient*TransactionContext - replaced by
> wildfly-transaction-client facility
>      ? EJBReceiverContext - no replacement
>      ? ReceiverInterceptor - no replacement (internal class)
>
>      ? ALL public classes in the org.jboss.ejb.client.remoting package
> including ReconnectHandler
>
> ? The following changes will be made to these core classes and interfaces:
>      ? EJBClient
>         ? Added more createSession() variants to support new affinity types
>         ? Change createSession() methods to throw CreateException instead
> of Exception
>         ? Remove createProxy() and createSession() variants which accept
> EJBClientContextIdentifier
>         ? Remove getEJBClientContextIdentifierFor() method
>      ? Attachable
>         ? Remove getAttachments() method
>      ? EJBClientContext
>         ? No longer implements Closeable
Does this mean there is no longer a need to close a context to avoid 
"too much channel" problems. I suppose the "scoped context" will be removed
>         ? Remove close() method
>         ? Remove all static create() methods, replaced with Builder class
>         ? Remove finalize() method
>         ? Remove getClusterContext(), getEJBClientConfiguration(),
> getOrCreateClusterContext(), removeCluster()
>         ? Remove selector-related methods, replaced with general Selector
> class
>         ? Remove register*() and unregister*() methods (providers are
> added to Builder)
>         ? Remove require() method which accepts EJBClientContextIdentifier
>         ? Add getInvocationTimeout() method
>      ? Affinity
>         ? Add forUri() factory method
>      ? EJBClientInvocationContext
>         ? Add getCompressionLevel(), isClientAsync(), and isIdempotent()
> query methods
>         ? Remove finalize()
>      ? EJB*Locator classes
>         ? Additional constructors which also accept an affinity
>         ? Additional "copy" constructors which accept a locator and
> affinity, to change the target affinity
>      ? EJBReceiver class
>         ? openSession() method changed to accept a stateless EJB locator
>         ? Constructor changed to no args
>         ? Remove all send*() and other methods related to transactions
>         ? Remove associate(), getNodeName(), [de]registerModule(), exists()
>      ? EJBReceiverInvocationContext
>         ? Remove retryInvocation() method
>         ? Remove getEjbReceiverContext() method
>         ? Remove getNodeName() method
>      ? EJBMetaDataImpl
>         ? Deprecated, changed to not use raw types
>      ? RequestSendFailedException
>         ? Replaced constructor with standard exception four-constructor setup
> ? The following API classes are added:
>      ? EJBClientPermission - a general permission class
>      ? AbstractEJBMetaData - type-safe hierarchical version of
> EJBMetaDataImpl
>      ? EJBClientContext.Builder - forwards-compatible builder for
> EJBClientContext
>      ? EJBDiscoveryProvider - an interface to provide pluggable discovery
>      ? EJBTransportProvider - an interface to provide URI-compatible
> transport (factory for EJBReceivers)
>      ? URIAffinity - a type of affinity which has a URI for a target
>
> Note in particular that most of the cluster-support infrastructure is
> presently removed with no replacement.  It is my hope and intent that
> the discovery infrastructure will be able to take over this function.
> How much of the code will be new, compared to how much of the code can
> be forward-ported and reintroduced from 2.x, remains to be discussed.
>
> At present, the plan is for wire compatibility to be supported for 2.x
> clients talking to 3.x servers and vice-versa.
>
> Transaction handling will be relegated to a separate
> wildfly-transaction-client API.  However the getUserTransaction(node)
> method will continue to be supported as a deprecated delegation to the
> transaction-client API.  In addition, when talking to a 2.x server, it
> is expected that a wildfly-transaction-client SPI implementation will
> piggyback on the existing EJB protocol transaction messages.
Is there a possibility to use the InitialContext and do a 
lookup("UserTransaction") to get a reference to UserTransaction without 
any knowledge of the server environment?
This was used <AS7 and also from other vendor.
Also is the ejb and other invocations sticky during the Tx is active?
>
> If any of these API changes seems unacceptable, now is the time to
> discuss it.  All the code that was removed was determined to be tied too
> tightly to the previous location or configuration strategy, and thus
> couldn't sensibly be supported going forward.  I have hopefully been
> adequately upfront about what I intended to remove or support going
> forward.  In addition, by supporting the 2.x client, most migration
> concerns can hopefully be mitigated.  But it's possible that some
> classes or methods could indeed be reintroduced with sensible semantics
> and in such a way as to not cause problems; if you have any thoughts
> along these lines, please share them and we can discuss them on a
> case-by-case basis.
>
> I've pushed up the proposed baseline 3.0 API at
> https://github.com/dmlloyd/jboss-ejb-client/tree/uri_invocation for
> review.  I intend for pull requests that are relevant to both old and
> new code bases to be applied to both if possible, to avoid increasing
> the incompatibility window even further.
>

From david.lloyd at redhat.com  Fri Nov 28 11:00:07 2014
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Fri, 28 Nov 2014 10:00:07 -0600
Subject: [wildfly-dev] IMPORTANT: First overview of changes to
 jboss-ejb-client 3.0 for WildFly 10 (probably)
In-Reply-To: <54788DB5.3040001@redhat.com>
References: <547621FB.3050107@redhat.com> <54788DB5.3040001@redhat.com>
Message-ID: <54789C07.7010309@redhat.com>

Thanks for responding; answers inline.

On 11/28/2014 08:59 AM, Wolf-Dieter Fink wrote:
> Hi David,
>
> I'm looking more from the functional side not from the implementation.
> So in general simplifying the code will make it better to understand.
>  From my perspective we need to cover the requirements from our users
> and make it easy to handle.
>
> I don't care whether we have different possibilities to configure the
> client. But the most important is to create a InitialContext programatic
> with properties and use it for all server actions.
> This should be done with a minimum of properties, i.e. default SSL=off
> as there is a need to configure it correct at server side.
>
> So I would assume that we deprecate the scoped-context and remote-naming
> complete and use the new approach.

I think remote-naming will continue to exist however it faces some 
similar refactoring (though likely smaller in scale), probably over the 
next month if all goes well.  But the user-facing changes to that 
project will be far less dramatic (probably completely unnoticeable in 
fact).

> I'll create a client project to show typical use-cases with the new API
> and check whether we cover the current issues.
> For this I appreciate if you have some examples if the creation and
> handling for the client has changed.

I'll put a few directly into this reply.

> BTW, is it possible to use the ejb-client 3.0 with current EAP/WildFly?
> Is there any restriction or dependency?
> At the moment I'm not able to compile the project (branch
> uri_invocation), there is a missing dependency.
>    org.wildfly.common:wildfly-common:jar:1.0.0.Beta1-SNAPSHOT

The API coding is done but there are some things still missing - in 
particular, all the protocol code needs to be rebuilt (probably from 
scratch), so that's going to be at least one person-week of work yet 
(with a few holidays thrown in that time) before the 3.x code will even 
*attempt* to connect to anything.  In addition, it needs an i18n 
work-over and a bunch more documentation.

Also, the wildfly-common project has not yet achieved full existence. 
If you clone and build it from my repository at 
https://github.com/dmlloyd/wildfly-common though, you should be able to 
build with all tests passing.

> please find my other comments inline.

More responses following inline comments.

> On 26/11/14 19:54, David M. Lloyd wrote:
>> I don't want to commit this to a specific WildFly release but I guess
>> and hope it'll come in around WildFly 10 or so (definitely not 9).
>>
>> As previously discussed, the EJB client architecture is undergoing the
>> following substantial changes:
>>
>> ? Introduction of URIAffinity, and URI-based invocation
>> ? Expansion of the 'ejb' JNDI initial context to auto-associate the
>> PROVIDER_URL as the URI affinity for looked-up proxies
> What does that mean?
> Is it possible to use an InitialContext without any jboss-ejb-client
> configuration to be able to invoke ejb's and lookup other JNDI stuff
> like JMS with one IC and no redundant server properties?

Yes, however any EJB proxies created with an unconfigured IC will have 
Affinity.NONE, meaning the client will have to rely on discovery to 
locate these EJBs (similar to how it works today, though hopefully 
somewhat more robust).

So to give an example:

    Context ctx = new InitialContext();
    MyEJBRemote r = (MyEJBRemote) ctx.lookup("ejb:/myapp/mymodule/MyEJB");

is the same as:

    MyEJBRemote r = EJBClient.createProxy(
        new StatelessEJBLocator(
            MyEJBRemote.class,
            "myapp",
            "mymodule",
            "MyEJB",
            Affinity.NONE));

Any attempt to invoke on "r" relies on the discovery implementation's 
ability to look up a concrete destination URI.

However, if I do this:

    Properties props = new Properties();
    props.put(Context.PROVIDER_URL, "remote://myhost.foo.com:12345");
    Context ctx = new InitialContext(props);
    MyEJBRemote r = (MyEJBRemote) ctx.lookup("ejb:/myapp/mymodule/MyEJB");

This is the same as:

    MyEJBRemote r = EJBClient.createProxy(
        new StatelessEJBLocator(
            MyEJBRemote.class,
            "myapp",
            "mymodule",
            "MyEJB",
            Affinity.forURI(new URI("remote://myhost.foo.com:12345"))));

So any attempt to invoke on "r" will directly create or reuse a 
(possibly preconfigured) connection to "remote://myhost.foo.com:12345" 
with no discovery latency or round-trips of any kind (also, as before, 
no server connection establishment is required to instantiate this 
stateless proxy).

>> ? Elimination of all "nested" EJB client context functionality
>> ? Integration with Elytron for client identity management
> Does that mean the credentials for the connection and ejb invocation are
> decoupled?

Yes, but only if you've configured it thus.

You can switch identity with the current Elytron API by doing one of the 
following.  First, there's the completely programmatic option:

    AuthenticationContext ctx =
        AuthenticationContext.captureCurrent().with(
 
MatchRule.empty().matchHost("myhost.foo.com").matchProtocol("remote"),
 
AuthenticationConfiguration.EMPTY.setUserName("jane").setPassword("xyz")
        );

    ctx.run(new PrivilegedAction<Void>() {
        public Void run() {
            // This method will run as "jane"
            r.invokeSomeMethod();
        }
    });

Second, you can preconfigure two (or more) identities in the global 
configuration, and switch by using different URI affinities:

    Properties props = new Properties();
    props.put(Context.PROVIDER_URL, "remote://jane at myhost.foo.com:12345");
    Context janeCtx = new InitialContext(props);
    MyEJBRemote janeRemote = (MyEJBRemote) 
janeCtx.lookup("ejb:/myapp/mymodule/MyEJB");
    props.put(Context.PROVIDER_URL, "remote://joe at myhost.foo.com:12345");
    Context joeCtx = new InitialContext(props);
    MyEJBRemote joeRemote = (MyEJBRemote) 
joeCtx.lookup("ejb:/myapp/mymodule/MyEJB");

The identity used will depend on which proxy is invoked (one connection 
is still shared though).

> Is there a possibility to use the old style CallBackHandler and/or being
> able to change the user for an existing remoting connection?

Yes, you can use the Elytron APIs to do both of these things.  In the 
present design, there is no way to use credentials configured in an 
InitialContext property map though; we haven't found a way to map this 
to Elytron that was both intuitive and also not rife with security and 
implementation problems.  It's not a closed issue though; any input here 
is appreciated.

> Also whether the credentials are used to invoke ejb's in a
> server-to-server communication and the user will be the invocation use
> of the first EJB and not the connection user?

Yes it will be possible to easily connect with one set of credentials 
and invoke EJBs with different credentials, even switching identities on 
a per-invocation basis (as briefly described above).

>> ? Deferral to Remoting for automatic connection management
>> ? Unification of client configuration, so the Elytron authentication
>> client, Remoting connection management, remote transaction client, and
>> EJB client configurations all can be configured in one file or
>> deployment descriptor
> Great!

:-D

>> ? The following classes and interfaces are currently removed in my
>> working copy:
>>      ? ClusterContext - replaced with discovery (?)
>>      ? ClusterNodeManager - replaced with discovery
>>
>>      ? ClusterNodeSelector - replaced with discovery
>>      ? DeploymentNodeSelector - replaced with discovery
> As Cluster/Deployment NodeSelector is being removed and replaced by
> discovery this sounds to me that there is no possibility to customize
> the load-balancing process
>
> This might affect some use-cases where such policy was implemented to
> control specific behaviour.

This is an example of an API that can probably be added back.  I want to 
spend some time consulting with Radoslav H. and Paul F. though to make 
sure that the API is "right" before I reintroduce this exact API (or a 
similar one).  Any input regarding use cases will be useful, I expect.

> Does this mean also that the cluster configuration at client side is
> deprecated and not longer necessary?

I'm not sure yet.  Maybe.

> Also the need to configure the cluster-name within the server
> configuration to distinguish between different clusters?

Yeah having a name-based identity for clusters is still the key to the 
EJB clustering design (for better or worse).  Ideally this would be 
something that the user can keep unique within their organizations.

>>      ? EJBClientContext
>>         ? No longer implements Closeable
> Does this mean there is no longer a need to close a context to avoid
> "too much channel" problems. I suppose the "scoped context" will be removed

Correct.  Remoting will maintain all connections based on configuration 
(including idle timeouts, if any), and all connections will be shareable 
among all Remoting-based services.  Other protocols (like HTTP) will 
similarly be responsible for the configuration and reuse of connections. 
  There will no longer be a need to close *anything*, which I believe 
our experiences have shown will be a good thing overall.

>> Transaction handling will be relegated to a separate
>> wildfly-transaction-client API.  However the getUserTransaction(node)
>> method will continue to be supported as a deprecated delegation to the
>> transaction-client API.  In addition, when talking to a 2.x server, it
>> is expected that a wildfly-transaction-client SPI implementation will
>> piggyback on the existing EJB protocol transaction messages.

> Is there a possibility to use the InitialContext and do a
> lookup("UserTransaction") to get a reference to UserTransaction without
> any knowledge of the server environment?  This was used <AS7 and also from other vendor.

Yes, that's a possibility.  I can imagine a simple JNDI protocol handler 
to accomplish this, e.g. lookup("txn:UserTransaction") or something 
along those lines.  The UserTransaction should be associated with a URI 
in exactly the same way that the EJB proxies would be, and this code 
would work universally on client and server (much like the EJB "ejb:" 
contexts are universal).

> Also is the ejb and other invocations sticky during the Tx is active?

Yes.  And, like today, trying to use an EJB which is located someplace 
that is incompatible with the current transaction will result in an 
error.  In addition, any current or future additional services we 
transport over Remoting (current: JMX, Management, JNDI; future: 
Authentication, maybe others like JDBC) can also reuse the same 
transaction context.  At present this can not include JMS though, 
unfortunately, unless you have a local Narayana transaction manager that 
can manage the transaction using JTA and XA, or unless we (or someone 
else) would create a Remoting-based transport for one or more JMS 
implementations.

-- 
- DML

From rory.odonnell at oracle.com  Fri Nov 28 13:29:22 2014
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Fri, 28 Nov 2014 18:29:22 +0000
Subject: [wildfly-dev] Jigsaw early-access builds updated (JDK 9 build
	40)
In-Reply-To: <54733D0A.4090709@oracle.com>
References: <54733D0A.4090709@oracle.com>
Message-ID: <5478BF02.70406@oracle.com>

Hi Jason/Tomaz,

We have had a report internally that Jigsaw in JDK 9 Build 36 seems to 
work with WildFly, while there
are issues with b40. The details are sketchy at the moment, is it 
possible to check this out and let us
know ?

Rgds,Rory
On 24/11/2014 14:13, Rory O'Donnell wrote:
>
> Hi Jason/Tomaz,
>
> JDK 9 Early Access with Project Jigsaw build b40 is available for 
> download at :
> https://jdk9.java.net/jigsaw/
>
> The goal of Project Jigsaw [2] is to design and implement a standard 
> module
> system for the Java SE Platform, and to apply that system to the 
> Platform itself
> and to the JDK.
>
> The main change in this build is that it includes the jrt: file-system 
> provider,
> so it now implements all of the changes described in JEP 220.
>
> Please refer to Project Jigsaw's updated project pages [2] & [4] and Mark
> Reinhold's update [5] for further details.
>
> We are very interested in your experiences testing this build. Comments,
> questions, and suggestions are welcome on the jigsaw-dev 
> <http://mail.openjdk.java.net/mailman/listinfo/jigsaw-dev> mailing 
> list or
> through bug reports via bugs.java.com <http://bugs.java.com/>.
>
> Note: If you haven?t already subscribed to that mailing list then 
> please do
> so first, otherwise your message will be discarded as spam.
>
> Rgds, Rory
>
> [1] https://jdk9.java.net/jigsaw/
> [2] http://openjdk.java.net/projects/jigsaw/
> [3] http://openjdk.java.net/jeps/220
> [4] http://openjdk.java.net/projects/jigsaw/ea
> [5] 
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2014-November/004014.html
> -- 
> Rgds,Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA , Dublin, Ireland

-- 
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/20141128/7bd1d524/attachment.html