From kabir.khan at jboss.com  Wed Apr  1 08:54:42 2015
From: kabir.khan at jboss.com (Kabir Khan)
Date: Wed, 1 Apr 2015 13:54:42 +0100
Subject: [wildfly-dev] Ordered child resources
Message-ID: <CC2B46FD-BC25-42A9-92A0-937150983990@jboss.com>

I am working on being able to order child resources, this is important for things like jgroups where the protocol order matters. On top of the domain operations work I inherited from Emanuel the order will get propagated through the domain. Currently for jgroups the only way to adjust the protocol order is to remove all protocols and add them again, and on the domain ops branch (before what I am outlining here) upon reconnect any new protocols end up at the end of the slave?s list.

The steps to make a child resource ordered are currently:
1) Make the ?parent? resource?s add handler call a different factory method:
	@Override
	protected Resource createResource(OperationContext context) {
		Resource resource = Resource.Factory.create(false, ?orderedA?, ?orderedB"); //Names of the child types where ordering matters
		context.addResource(PathAddress.EMPTY_ADDRESS, resource);
		return resource;
	}

2) In the ordered child resource definitions, override the new getOrderedChildResource() operation to 
	class OrderedChildResourceDefinition extends SimpleResourceDefinition {
		public OrderedChildResourceDefinition(PathElement element) { 
			super(PathElement.pathElement(?orderedA", new NonResolvingResourceDescriptionResolver(), 
				new OrderedChildAddHandler(REQUEST_ATTRIBUTES), new ModelOnlyRemoveStepHandler()); 
		}

		@Override
		protected boolean getOrderedChildResource() {
			return true;
		}
		?.
  }
This has the effect of adding a parameter called ?add-index? to the ?add? operation?s description. So if you have
	/some=where/orderedA=tree
	/some=where/orderedA=bush
You can do e.g. /some=where/orderedA=hedge:add(add-index=1) and end up with:
	/some=where/orderedA=tree
	/some=where/orderedA=hedge
	/some=where/orderedA=bush

3) The final part is to adjust the ordered child resource?s add handler to honour the add-index parameter:

	class OrderedChildAddHandler extends AbstractAddStepHandler {
		public OrderedChildAddHandler(AttributeDefinition... attributes) {
			super(attributes);
	}

	@Override
	protected Resource createResource(OperationContext context, ModelNode operation) {
		if (!operation.hasDefined(ADD_INDEX) || operation.get(ADD_INDEX).asInt() < 0) {
			return super.createResource(context);
		}
          	return context.createResource(PathAddress.EMPTY_ADDRESS, operation.get(ADD_INDEX).asInt());
	}

4) Not really related to what a user needs to do to create an ordered resource, but 1-3 are made possible by that on the resource interface I have two new methods:
  /**
   * Return the child types for which the order matters.
   *
   * @return {@code true} if the order of the children matters. If there are no ordered
   * children and empty set is returned. This method should never return {@code null}
   */
  Set<String> getOrderedChildTypes();

  /**
   * Register a child resource
   *
   * @param address the address
   * @param index the index at which to add the resource. Existing children with this index and higher will be shifted one uo
   * @param resource the resource
   * @throws IllegalStateException for a duplicate entry or if the resource does not support ordered children
   */
  void registerChild(PathElement address, int index, Resource resource);


The main question I have is whether 1-3 are too ?fragile? and if we need something to enforce/glue this together a bit more? At the same time ordered child resources should be the exception rather than the rule. 




From brian.stansberry at redhat.com  Wed Apr  1 14:48:01 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 01 Apr 2015 13:48:01 -0500
Subject: [wildfly-dev] Ordered child resources
In-Reply-To: <CC2B46FD-BC25-42A9-92A0-937150983990@jboss.com>
References: <CC2B46FD-BC25-42A9-92A0-937150983990@jboss.com>
Message-ID: <551C3D61.1040907@redhat.com>

Are the classes in your 2) and 3) new base classes, or examples of what 
users would need to do?

Given your question, I figure it's the latter.

It seems like it would be fairly straightforward to add the 3) stuff to 
AbstractAddStepHandler via a simple constructor param. The 1) stuff is 
pretty simple too, but doing both it and 3) starts to get messy in terms 
of too many constructor variants.

What about re-ordering? Done via add/remove?

On 4/1/15 7:54 AM, Kabir Khan wrote:
> I am working on being able to order child resources, this is important for things like jgroups where the protocol order matters. On top of the domain operations work I inherited from Emanuel the order will get propagated through the domain. Currently for jgroups the only way to adjust the protocol order is to remove all protocols and add them again, and on the domain ops branch (before what I am outlining here) upon reconnect any new protocols end up at the end of the slave?s list.
>
> The steps to make a child resource ordered are currently:
> 1) Make the ?parent? resource?s add handler call a different factory method:
> 	@Override
> 	protected Resource createResource(OperationContext context) {
> 		Resource resource = Resource.Factory.create(false, ?orderedA?, ?orderedB"); //Names of the child types where ordering matters
> 		context.addResource(PathAddress.EMPTY_ADDRESS, resource);
> 		return resource;
> 	}
>
> 2) In the ordered child resource definitions, override the new getOrderedChildResource() operation to
> 	class OrderedChildResourceDefinition extends SimpleResourceDefinition {
> 		public OrderedChildResourceDefinition(PathElement element) {
> 			super(PathElement.pathElement(?orderedA", new NonResolvingResourceDescriptionResolver(),
> 				new OrderedChildAddHandler(REQUEST_ATTRIBUTES), new ModelOnlyRemoveStepHandler());
> 		}
>
> 		@Override
> 		protected boolean getOrderedChildResource() {
> 			return true;
> 		}
> 		?.
>    }
> This has the effect of adding a parameter called ?add-index? to the ?add? operation?s description. So if you have
> 	/some=where/orderedA=tree
> 	/some=where/orderedA=bush
> You can do e.g. /some=where/orderedA=hedge:add(add-index=1) and end up with:
> 	/some=where/orderedA=tree
> 	/some=where/orderedA=hedge
> 	/some=where/orderedA=bush
>
> 3) The final part is to adjust the ordered child resource?s add handler to honour the add-index parameter:
>
> 	class OrderedChildAddHandler extends AbstractAddStepHandler {
> 		public OrderedChildAddHandler(AttributeDefinition... attributes) {
> 			super(attributes);
> 	}
>
> 	@Override
> 	protected Resource createResource(OperationContext context, ModelNode operation) {
> 		if (!operation.hasDefined(ADD_INDEX) || operation.get(ADD_INDEX).asInt() < 0) {
> 			return super.createResource(context);
> 		}
>            	return context.createResource(PathAddress.EMPTY_ADDRESS, operation.get(ADD_INDEX).asInt());
> 	}
>
> 4) Not really related to what a user needs to do to create an ordered resource, but 1-3 are made possible by that on the resource interface I have two new methods:
>    /**
>     * Return the child types for which the order matters.
>     *
>     * @return {@code true} if the order of the children matters. If there are no ordered
>     * children and empty set is returned. This method should never return {@code null}
>     */
>    Set<String> getOrderedChildTypes();
>
>    /**
>     * Register a child resource
>     *
>     * @param address the address
>     * @param index the index at which to add the resource. Existing children with this index and higher will be shifted one uo
>     * @param resource the resource
>     * @throws IllegalStateException for a duplicate entry or if the resource does not support ordered children
>     */
>    void registerChild(PathElement address, int index, Resource resource);
>
>
> The main question I have is whether 1-3 are too ?fragile? and if we need something to enforce/glue this together a bit more? At the same time ordered child resources should be the exception rather than the rule.
>
>
>
> _______________________________________________
> 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 rsvoboda at redhat.com  Thu Apr  2 05:34:50 2015
From: rsvoboda at redhat.com (Rostislav Svoboda)
Date: Thu, 2 Apr 2015 05:34:50 -0400 (EDT)
Subject: [wildfly-dev] Dropping legacy XSD schemas & its parsers
In-Reply-To: <551974E5.1080508@redhat.com>
References: <CAMquZP4kGzBv+jy_f_P3nmVv=tPXwFFGwbWOzkpAa=vaPJdY0Q@mail.gmail.com>
	<55157228.2000604@redhat.com>
	<CAMquZP6COFFdunr-70RLnMe6D=Xw27V6qvCo4Ex3uHQSYXzMFQ@mail.gmail.com>
	<551974E5.1080508@redhat.com>
Message-ID: <19455838.8453117.1427967290711.JavaMail.zimbra@redhat.com>

Doesn't "anything that is older than AS7.3 / EAP 6.2 is optional and can get dropped." affect https://issues.jboss.org/browse/EAP7-93 ?

Thanks.
Rostislav

----- Original Message -----
> On 3/30/15 10:58 AM, Toma? Cerar wrote:
> >
> > On Fri, Mar 27, 2015 at 4:07 PM, Brian Stansberry
> > <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>> wrote:
> >
> >     It's mildly tempting to support the 7.2.0 xsds, as that's the last 7
> >     release. But if we're going to have any cutoff, IMHO keeping the rule
> >     consistent with the mixed domain support cutoff is better. KISS.
> >
> >
> > Couldn't agree more with this. Lets keep things in line as much as
> > possible.
> > 7.2 users can upgrade to 8.2 and from there to 9/10.
> >
> > So can we agree on dropping xsds/parsers and have cut-off same as for
> > mixed domain
> > so anything that is older than AS7.3 / EAP 6.2 is optional and can get
> > dropped.
> >
> 
> I want to hear from Jason on this. I know he's expressed strong opinions
> in this area before, so I don't want to presume to know what he thinks.
> 
> Thanks for driving this.
> 
> > --
> > tomaz
> >
> >
> > _______________________________________________
> > 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 tomaz.cerar at gmail.com  Thu Apr  2 05:46:23 2015
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Thu, 2 Apr 2015 11:46:23 +0200
Subject: [wildfly-dev] Dropping legacy XSD schemas & its parsers
In-Reply-To: <19455838.8453117.1427967290711.JavaMail.zimbra@redhat.com>
References: <CAMquZP4kGzBv+jy_f_P3nmVv=tPXwFFGwbWOzkpAa=vaPJdY0Q@mail.gmail.com>
	<55157228.2000604@redhat.com>
	<CAMquZP6COFFdunr-70RLnMe6D=Xw27V6qvCo4Ex3uHQSYXzMFQ@mail.gmail.com>
	<551974E5.1080508@redhat.com>
	<19455838.8453117.1427967290711.JavaMail.zimbra@redhat.com>
Message-ID: <CAMquZP5TsLi=cPnxQ0gZpc271H9_5Pv537ms2vY23840r-9FNg@mail.gmail.com>

On Thu, Apr 2, 2015 at 11:34 AM, Rostislav Svoboda <rsvoboda at redhat.com>
wrote:

> Doesn't "anything that is older than AS7.3 / EAP 6.2 is optional and can
> get dropped." affect https://issues.jboss.org/browse/EAP7-93 ?
>


No it doesn't, it is somewhat related but EAP7-93 will still be satisfied.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150402/9386cadd/attachment.html 

From kabir.khan at jboss.com  Thu Apr  2 06:01:17 2015
From: kabir.khan at jboss.com (Kabir Khan)
Date: Thu, 2 Apr 2015 11:01:17 +0100
Subject: [wildfly-dev] Ordered child resources
In-Reply-To: <551C3D61.1040907@redhat.com>
References: <CC2B46FD-BC25-42A9-92A0-937150983990@jboss.com>
	<551C3D61.1040907@redhat.com>
Message-ID: <9787E9CB-16CB-465F-B395-97A3837E2FEE@jboss.com>


> On 1 Apr 2015, at 19:48, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> 
> Are the classes in your 2) and 3) new base classes, or examples of what 
> users would need to do?
> 
> Given your question, I figure it's the latter.
Yes they are examples cut and paste from a test case I am working on.
> 
> It seems like it would be fairly straightforward to add the 3) stuff to 
> AbstractAddStepHandler via a simple constructor param. The 1) stuff is 
> pretty simple too, but doing both it and 3) starts to get messy in terms 
> of too many constructor variants.
Rather than polluting the existing class too much, since this should really be an uncommon case (?) perhaps we need an AbstractOrderedAddStepHandler. But it is a bit weird since the parent and the child both need to override this differently. It shouldn?t be too hard to come up with something nicer though, I?ll let you know once I have had a play.
> 
> What about re-ordering? Done via add/remove?
Yes that would need to be done via remove and add (with add-index). Moving stuff around would still need to trigger awareness that something changed, but perhaps that could be done with a handler registered for these parent resources. e.g. something along the lines of /some=where:reorder-children(child-type=orderedA, order=[tree, bush, hedge]). For now I see this as a nice to have enhancement which can happen in the future :-)
> 
> On 4/1/15 7:54 AM, Kabir Khan wrote:
>> I am working on being able to order child resources, this is important for things like jgroups where the protocol order matters. On top of the domain operations work I inherited from Emanuel the order will get propagated through the domain. Currently for jgroups the only way to adjust the protocol order is to remove all protocols and add them again, and on the domain ops branch (before what I am outlining here) upon reconnect any new protocols end up at the end of the slave?s list.
>> 
>> The steps to make a child resource ordered are currently:
>> 1) Make the ?parent? resource?s add handler call a different factory method:
>> 	@Override
>> 	protected Resource createResource(OperationContext context) {
>> 		Resource resource = Resource.Factory.create(false, ?orderedA?, ?orderedB"); //Names of the child types where ordering matters
>> 		context.addResource(PathAddress.EMPTY_ADDRESS, resource);
>> 		return resource;
>> 	}
>> 
>> 2) In the ordered child resource definitions, override the new getOrderedChildResource() operation to
>> 	class OrderedChildResourceDefinition extends SimpleResourceDefinition {
>> 		public OrderedChildResourceDefinition(PathElement element) {
>> 			super(PathElement.pathElement(?orderedA", new NonResolvingResourceDescriptionResolver(),
>> 				new OrderedChildAddHandler(REQUEST_ATTRIBUTES), new ModelOnlyRemoveStepHandler());
>> 		}
>> 
>> 		@Override
>> 		protected boolean getOrderedChildResource() {
>> 			return true;
>> 		}
>> 		?.
>>   }
>> This has the effect of adding a parameter called ?add-index? to the ?add? operation?s description. So if you have
>> 	/some=where/orderedA=tree
>> 	/some=where/orderedA=bush
>> You can do e.g. /some=where/orderedA=hedge:add(add-index=1) and end up with:
>> 	/some=where/orderedA=tree
>> 	/some=where/orderedA=hedge
>> 	/some=where/orderedA=bush
>> 
>> 3) The final part is to adjust the ordered child resource?s add handler to honour the add-index parameter:
>> 
>> 	class OrderedChildAddHandler extends AbstractAddStepHandler {
>> 		public OrderedChildAddHandler(AttributeDefinition... attributes) {
>> 			super(attributes);
>> 	}
>> 
>> 	@Override
>> 	protected Resource createResource(OperationContext context, ModelNode operation) {
>> 		if (!operation.hasDefined(ADD_INDEX) || operation.get(ADD_INDEX).asInt() < 0) {
>> 			return super.createResource(context);
>> 		}
>>           	return context.createResource(PathAddress.EMPTY_ADDRESS, operation.get(ADD_INDEX).asInt());
>> 	}
>> 
>> 4) Not really related to what a user needs to do to create an ordered resource, but 1-3 are made possible by that on the resource interface I have two new methods:
>>   /**
>>    * Return the child types for which the order matters.
>>    *
>>    * @return {@code true} if the order of the children matters. If there are no ordered
>>    * children and empty set is returned. This method should never return {@code null}
>>    */
>>   Set<String> getOrderedChildTypes();
>> 
>>   /**
>>    * Register a child resource
>>    *
>>    * @param address the address
>>    * @param index the index at which to add the resource. Existing children with this index and higher will be shifted one uo
>>    * @param resource the resource
>>    * @throws IllegalStateException for a duplicate entry or if the resource does not support ordered children
>>    */
>>   void registerChild(PathElement address, int index, Resource resource);
>> 
>> 
>> The main question I have is whether 1-3 are too ?fragile? and if we need something to enforce/glue this together a bit more? At the same time ordered child resources should be the exception rather than the rule.
>> 
>> 
>> 
>> _______________________________________________
>> 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 kabir.khan at jboss.com  Thu Apr  2 07:11:43 2015
From: kabir.khan at jboss.com (Kabir Khan)
Date: Thu, 2 Apr 2015 12:11:43 +0100
Subject: [wildfly-dev] Ordered child resources
In-Reply-To: <9787E9CB-16CB-465F-B395-97A3837E2FEE@jboss.com>
References: <CC2B46FD-BC25-42A9-92A0-937150983990@jboss.com>
	<551C3D61.1040907@redhat.com>
	<9787E9CB-16CB-465F-B395-97A3837E2FEE@jboss.com>
Message-ID: <49CCC293-4EC0-40C9-AF37-14FBDB3C3407@jboss.com>


> On 2 Apr 2015, at 11:01, Kabir Khan <kabir.khan at jboss.com> wrote:
> 
> 
>> On 1 Apr 2015, at 19:48, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>> 
>> Are the classes in your 2) and 3) new base classes, or examples of what 
>> users would need to do?
>> 
>> Given your question, I figure it's the latter.
> Yes they are examples cut and paste from a test case I am working on.
>> 
>> It seems like it would be fairly straightforward to add the 3) stuff to 
>> AbstractAddStepHandler via a simple constructor param. The 1) stuff is 
>> pretty simple too, but doing both it and 3) starts to get messy in terms 
>> of too many constructor variants.
> Rather than polluting the existing class too much, since this should really be an uncommon case (?) perhaps we need an AbstractOrderedAddStepHandler. But it is a bit weird since the parent and the child both need to override this differently. It shouldn?t be too hard to come up with something nicer though, I?ll let you know once I have had a play.
It is doable, but all the constructors are getting a bit messy anyway. I?ll add a builder to AbstractAddStepHandler instead.
>> 
>> What about re-ordering? Done via add/remove?
> Yes that would need to be done via remove and add (with add-index). Moving stuff around would still need to trigger awareness that something changed, but perhaps that could be done with a handler registered for these parent resources. e.g. something along the lines of /some=where:reorder-children(child-type=orderedA, order=[tree, bush, hedge]). For now I see this as a nice to have enhancement which can happen in the future :-)
>> 
>> On 4/1/15 7:54 AM, Kabir Khan wrote:
>>> I am working on being able to order child resources, this is important for things like jgroups where the protocol order matters. On top of the domain operations work I inherited from Emanuel the order will get propagated through the domain. Currently for jgroups the only way to adjust the protocol order is to remove all protocols and add them again, and on the domain ops branch (before what I am outlining here) upon reconnect any new protocols end up at the end of the slave?s list.
>>> 
>>> The steps to make a child resource ordered are currently:
>>> 1) Make the ?parent? resource?s add handler call a different factory method:
>>> 	@Override
>>> 	protected Resource createResource(OperationContext context) {
>>> 		Resource resource = Resource.Factory.create(false, ?orderedA?, ?orderedB"); //Names of the child types where ordering matters
>>> 		context.addResource(PathAddress.EMPTY_ADDRESS, resource);
>>> 		return resource;
>>> 	}
>>> 
>>> 2) In the ordered child resource definitions, override the new getOrderedChildResource() operation to
>>> 	class OrderedChildResourceDefinition extends SimpleResourceDefinition {
>>> 		public OrderedChildResourceDefinition(PathElement element) {
>>> 			super(PathElement.pathElement(?orderedA", new NonResolvingResourceDescriptionResolver(),
>>> 				new OrderedChildAddHandler(REQUEST_ATTRIBUTES), new ModelOnlyRemoveStepHandler());
>>> 		}
>>> 
>>> 		@Override
>>> 		protected boolean getOrderedChildResource() {
>>> 			return true;
>>> 		}
>>> 		?.
>>>  }
>>> This has the effect of adding a parameter called ?add-index? to the ?add? operation?s description. So if you have
>>> 	/some=where/orderedA=tree
>>> 	/some=where/orderedA=bush
>>> You can do e.g. /some=where/orderedA=hedge:add(add-index=1) and end up with:
>>> 	/some=where/orderedA=tree
>>> 	/some=where/orderedA=hedge
>>> 	/some=where/orderedA=bush
>>> 
>>> 3) The final part is to adjust the ordered child resource?s add handler to honour the add-index parameter:
>>> 
>>> 	class OrderedChildAddHandler extends AbstractAddStepHandler {
>>> 		public OrderedChildAddHandler(AttributeDefinition... attributes) {
>>> 			super(attributes);
>>> 	}
>>> 
>>> 	@Override
>>> 	protected Resource createResource(OperationContext context, ModelNode operation) {
>>> 		if (!operation.hasDefined(ADD_INDEX) || operation.get(ADD_INDEX).asInt() < 0) {
>>> 			return super.createResource(context);
>>> 		}
>>>          	return context.createResource(PathAddress.EMPTY_ADDRESS, operation.get(ADD_INDEX).asInt());
>>> 	}
>>> 
>>> 4) Not really related to what a user needs to do to create an ordered resource, but 1-3 are made possible by that on the resource interface I have two new methods:
>>>  /**
>>>   * Return the child types for which the order matters.
>>>   *
>>>   * @return {@code true} if the order of the children matters. If there are no ordered
>>>   * children and empty set is returned. This method should never return {@code null}
>>>   */
>>>  Set<String> getOrderedChildTypes();
>>> 
>>>  /**
>>>   * Register a child resource
>>>   *
>>>   * @param address the address
>>>   * @param index the index at which to add the resource. Existing children with this index and higher will be shifted one uo
>>>   * @param resource the resource
>>>   * @throws IllegalStateException for a duplicate entry or if the resource does not support ordered children
>>>   */
>>>  void registerChild(PathElement address, int index, Resource resource);
>>> 
>>> 
>>> The main question I have is whether 1-3 are too ?fragile? and if we need something to enforce/glue this together a bit more? At the same time ordered child resources should be the exception rather than the rule.
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> 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
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



From brian.stansberry at redhat.com  Thu Apr  2 12:17:02 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 02 Apr 2015 11:17:02 -0500
Subject: [wildfly-dev] Ordered child resources
In-Reply-To: <49CCC293-4EC0-40C9-AF37-14FBDB3C3407@jboss.com>
References: <CC2B46FD-BC25-42A9-92A0-937150983990@jboss.com>
	<551C3D61.1040907@redhat.com>
	<9787E9CB-16CB-465F-B395-97A3837E2FEE@jboss.com>
	<49CCC293-4EC0-40C9-AF37-14FBDB3C3407@jboss.com>
Message-ID: <551D6B7E.3060206@redhat.com>

On 4/2/15 6:11 AM, Kabir Khan wrote:
>
>> On 2 Apr 2015, at 11:01, Kabir Khan <kabir.khan at jboss.com> wrote:
>>
>>
>>> On 1 Apr 2015, at 19:48, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>>
>>> Are the classes in your 2) and 3) new base classes, or examples of what
>>> users would need to do?
>>>
>>> Given your question, I figure it's the latter.
>> Yes they are examples cut and paste from a test case I am working on.
>>>
>>> It seems like it would be fairly straightforward to add the 3) stuff to
>>> AbstractAddStepHandler via a simple constructor param. The 1) stuff is
>>> pretty simple too, but doing both it and 3) starts to get messy in terms
>>> of too many constructor variants.
>> Rather than polluting the existing class too much, since this should really be an uncommon case (?) perhaps we need an AbstractOrderedAddStepHandler. But it is a bit weird since the parent and the child both need to override this differently. It shouldn?t be too hard to come up with something nicer though, I?ll let you know once I have had a play.
> It is doable, but all the constructors are getting a bit messy anyway. I?ll add a builder to AbstractAddStepHandler instead.

This (meaning the general problem, not a builder approach per se) can 
get complicated, due to the different varieties:

AbstractBoottimeAddStepHandler
RestartParentResourceAddHandler

The latter sounds particularly relevant for the child resources, as the 
need for ordering implies that it's the parent that's using the child's 
config data to manage some service.

>>>
>>> What about re-ordering? Done via add/remove?
>> Yes that would need to be done via remove and add (with add-index). Moving stuff around would still need to trigger awareness that something changed, but perhaps that could be done with a handler registered for these parent resources. e.g. something along the lines of /some=where:reorder-children(child-type=orderedA, order=[tree, bush, hedge]). For now I see this as a nice to have enhancement which can happen in the future :-)
>>>

I think remove+add is fine.

>>> On 4/1/15 7:54 AM, Kabir Khan wrote:
>>>> I am working on being able to order child resources, this is important for things like jgroups where the protocol order matters. On top of the domain operations work I inherited from Emanuel the order will get propagated through the domain. Currently for jgroups the only way to adjust the protocol order is to remove all protocols and add them again, and on the domain ops branch (before what I am outlining here) upon reconnect any new protocols end up at the end of the slave?s list.
>>>>
>>>> The steps to make a child resource ordered are currently:
>>>> 1) Make the ?parent? resource?s add handler call a different factory method:
>>>> 	@Override
>>>> 	protected Resource createResource(OperationContext context) {
>>>> 		Resource resource = Resource.Factory.create(false, ?orderedA?, ?orderedB"); //Names of the child types where ordering matters
>>>> 		context.addResource(PathAddress.EMPTY_ADDRESS, resource);
>>>> 		return resource;
>>>> 	}
>>>>
>>>> 2) In the ordered child resource definitions, override the new getOrderedChildResource() operation to
>>>> 	class OrderedChildResourceDefinition extends SimpleResourceDefinition {
>>>> 		public OrderedChildResourceDefinition(PathElement element) {
>>>> 			super(PathElement.pathElement(?orderedA", new NonResolvingResourceDescriptionResolver(),
>>>> 				new OrderedChildAddHandler(REQUEST_ATTRIBUTES), new ModelOnlyRemoveStepHandler());
>>>> 		}
>>>>
>>>> 		@Override
>>>> 		protected boolean getOrderedChildResource() {
>>>> 			return true;
>>>> 		}
>>>> 		?.
>>>>   }
>>>> This has the effect of adding a parameter called ?add-index? to the ?add? operation?s description. So if you have
>>>> 	/some=where/orderedA=tree
>>>> 	/some=where/orderedA=bush
>>>> You can do e.g. /some=where/orderedA=hedge:add(add-index=1) and end up with:
>>>> 	/some=where/orderedA=tree
>>>> 	/some=where/orderedA=hedge
>>>> 	/some=where/orderedA=bush
>>>>
>>>> 3) The final part is to adjust the ordered child resource?s add handler to honour the add-index parameter:
>>>>
>>>> 	class OrderedChildAddHandler extends AbstractAddStepHandler {
>>>> 		public OrderedChildAddHandler(AttributeDefinition... attributes) {
>>>> 			super(attributes);
>>>> 	}
>>>>
>>>> 	@Override
>>>> 	protected Resource createResource(OperationContext context, ModelNode operation) {
>>>> 		if (!operation.hasDefined(ADD_INDEX) || operation.get(ADD_INDEX).asInt() < 0) {
>>>> 			return super.createResource(context);
>>>> 		}
>>>>           	return context.createResource(PathAddress.EMPTY_ADDRESS, operation.get(ADD_INDEX).asInt());
>>>> 	}
>>>>
>>>> 4) Not really related to what a user needs to do to create an ordered resource, but 1-3 are made possible by that on the resource interface I have two new methods:
>>>>   /**
>>>>    * Return the child types for which the order matters.
>>>>    *
>>>>    * @return {@code true} if the order of the children matters. If there are no ordered
>>>>    * children and empty set is returned. This method should never return {@code null}
>>>>    */
>>>>   Set<String> getOrderedChildTypes();
>>>>
>>>>   /**
>>>>    * Register a child resource
>>>>    *
>>>>    * @param address the address
>>>>    * @param index the index at which to add the resource. Existing children with this index and higher will be shifted one uo
>>>>    * @param resource the resource
>>>>    * @throws IllegalStateException for a duplicate entry or if the resource does not support ordered children
>>>>    */
>>>>   void registerChild(PathElement address, int index, Resource resource);
>>>>
>>>>
>>>> The main question I have is whether 1-3 are too ?fragile? and if we need something to enforce/glue this together a bit more? At the same time ordered child resources should be the exception rather than the rule.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>> _______________________________________________
>> 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  Thu Apr  2 12:23:35 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 02 Apr 2015 11:23:35 -0500
Subject: [wildfly-dev] Dropping legacy XSD schemas & its parsers
In-Reply-To: <CAMquZP5TsLi=cPnxQ0gZpc271H9_5Pv537ms2vY23840r-9FNg@mail.gmail.com>
References: <CAMquZP4kGzBv+jy_f_P3nmVv=tPXwFFGwbWOzkpAa=vaPJdY0Q@mail.gmail.com>	<55157228.2000604@redhat.com>	<CAMquZP6COFFdunr-70RLnMe6D=Xw27V6qvCo4Ex3uHQSYXzMFQ@mail.gmail.com>	<551974E5.1080508@redhat.com>	<19455838.8453117.1427967290711.JavaMail.zimbra@redhat.com>
	<CAMquZP5TsLi=cPnxQ0gZpc271H9_5Pv537ms2vY23840r-9FNg@mail.gmail.com>
Message-ID: <551D6D07.4050808@redhat.com>

On 4/2/15 4:46 AM, Toma? Cerar wrote:
>
> On Thu, Apr 2, 2015 at 11:34 AM, Rostislav Svoboda <rsvoboda at redhat.com
> <mailto:rsvoboda at redhat.com>> wrote:
>
>     Doesn't "anything that is older than AS7.3 / EAP 6.2 is optional and
>     can get dropped." affect https://issues.jboss.org/browse/EAP7-93 ?
>
>
> No it doesn't, it is somewhat related but EAP7-93 will still be satisfied.

It's a good point though. Dropping this support has the potential to 
make that work harder. It doesn't make it impossible, but being able to 
parse old configs in the main server/HC code base might make EAP7-93 
work easier.

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

From kabir.khan at jboss.com  Thu Apr  2 12:53:32 2015
From: kabir.khan at jboss.com (Kabir Khan)
Date: Thu, 2 Apr 2015 17:53:32 +0100
Subject: [wildfly-dev] Ordered child resources
In-Reply-To: <551D6B7E.3060206@redhat.com>
References: <CC2B46FD-BC25-42A9-92A0-937150983990@jboss.com>
	<551C3D61.1040907@redhat.com>
	<9787E9CB-16CB-465F-B395-97A3837E2FEE@jboss.com>
	<49CCC293-4EC0-40C9-AF37-14FBDB3C3407@jboss.com>
	<551D6B7E.3060206@redhat.com>
Message-ID: <28164044-E6D4-4B7F-B422-888EA06A1F9B@jboss.com>


> On 2 Apr 2015, at 17:17, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> 
> On 4/2/15 6:11 AM, Kabir Khan wrote:
>> 
>>> On 2 Apr 2015, at 11:01, Kabir Khan <kabir.khan at jboss.com> wrote:
>>> 
>>> 
>>>> On 1 Apr 2015, at 19:48, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>>> 
>>>> Are the classes in your 2) and 3) new base classes, or examples of what
>>>> users would need to do?
>>>> 
>>>> Given your question, I figure it's the latter.
>>> Yes they are examples cut and paste from a test case I am working on.
>>>> 
>>>> It seems like it would be fairly straightforward to add the 3) stuff to
>>>> AbstractAddStepHandler via a simple constructor param. The 1) stuff is
>>>> pretty simple too, but doing both it and 3) starts to get messy in terms
>>>> of too many constructor variants.
>>> Rather than polluting the existing class too much, since this should really be an uncommon case (?) perhaps we need an AbstractOrderedAddStepHandler. But it is a bit weird since the parent and the child both need to override this differently. It shouldn?t be too hard to come up with something nicer though, I?ll let you know once I have had a play.
>> It is doable, but all the constructors are getting a bit messy anyway. I?ll add a builder to AbstractAddStepHandler instead.
> 
> This (meaning the general problem, not a builder approach per se) can get complicated, due to the different varieties:
> 
> AbstractBoottimeAddStepHandler
> RestartParentResourceAddHandler
> 
> The latter sounds particularly relevant for the child resources, as the need for ordering implies that it's the parent that's using the child's config data to manage some service.
I have scrapped the builder approach for now since these classes are built for overriding. I have:

public abstract class AbstractOrderedResourceAddStepHandler extends AbstractAddStepHandler {
    //Constructors
   ?.

    /**
     * If this ia a parent resource with ordered child resources, return a set of the names of the ordered child types.
     * If there are no ordered child types, return an empty set.
     *
     *  @return the ordered child types
     */
    protected Set<String> getOrderedChildTypes() {
        return Collections.emptySet();
    }

    /**
     * Return {@code true} if this is a child resource of a type whose parent supports ordered inserts
     *
     * @return whether ordered inserts are supportered
     */
    protected boolean supportIndexedAdd() {
        return false;
    }

    @Override
    protected Resource createResource(OperationContext context, ModelNode operation) {
        Set<String> orderedChildTypes = getOrderedChildTypes();
	//Creates a parent with ordered children (if set is not empty)
        Resource resource = Resource.Factory.create(false, orderedChildTypes);

	//Attempts to do the insert
        int index = -1;
        if (supportIndexedAdd() && operation.hasDefined(ADD_INDEX)) {
            index = operation.get(ADD_INDEX).asInt();
        }
        if (index >= 0) {
            context.addResource(PathAddress.EMPTY_ADDRESS, operation.get(ADD_INDEX).asInt(), resource);
        } else {
            context.addResource(PathAddress.EMPTY_ADDRESS, resource);
        }
        return resource;
    }
}

but that does not take the restart part into account at all. Perhaps I should push this all up into AbstractAddHandler anyway. Do you mind having something like a 
public class AbstractAddHandler implements OperationStepHandler {
?.
	protected ResourceCreator getResourceCreator() {
		return DEFAULT; // does what AbstractAddHandler does presently
	}

	protected Resource createResource(OperationContext context, ModelNode operation) {
		return getResourceCreator().createResource(context, operation);
	}
}

I could then have an implementation along the lines of
public class OrderedResourceCreator implements ResourceCreator {
	private final Set<String> orderedChildTypes;
	private final boolean indexedAdd;
	public OrderedResourceCreator(Set<String> orderedChildTypes, boolean indexedAdd) {
		this.orderedChildTypes = orderedChildTypes;
		this.indexedAdd = indexedAdd;
        }
	protected Resource createResource(OperationContext context, ModelNode operation) {
		//same as AbstractOrderedResourceAddStepHandler.createResource() above
	}
}
and have sub-classes override getResourceCreator() to return that. Or do you really, really want this in the constructor rather than in an overridden getter?



> 
>>>> 
>>>> What about re-ordering? Done via add/remove?
>>> Yes that would need to be done via remove and add (with add-index). Moving stuff around would still need to trigger awareness that something changed, but perhaps that could be done with a handler registered for these parent resources. e.g. something along the lines of /some=where:reorder-children(child-type=orderedA, order=[tree, bush, hedge]). For now I see this as a nice to have enhancement which can happen in the future :-)
>>>> 
> 
> I think remove+add is fine.
> 
>>>> On 4/1/15 7:54 AM, Kabir Khan wrote:
>>>>> I am working on being able to order child resources, this is important for things like jgroups where the protocol order matters. On top of the domain operations work I inherited from Emanuel the order will get propagated through the domain. Currently for jgroups the only way to adjust the protocol order is to remove all protocols and add them again, and on the domain ops branch (before what I am outlining here) upon reconnect any new protocols end up at the end of the slave?s list.
>>>>> 
>>>>> The steps to make a child resource ordered are currently:
>>>>> 1) Make the ?parent? resource?s add handler call a different factory method:
>>>>> 	@Override
>>>>> 	protected Resource createResource(OperationContext context) {
>>>>> 		Resource resource = Resource.Factory.create(false, ?orderedA?, ?orderedB"); //Names of the child types where ordering matters
>>>>> 		context.addResource(PathAddress.EMPTY_ADDRESS, resource);
>>>>> 		return resource;
>>>>> 	}
>>>>> 
>>>>> 2) In the ordered child resource definitions, override the new getOrderedChildResource() operation to
>>>>> 	class OrderedChildResourceDefinition extends SimpleResourceDefinition {
>>>>> 		public OrderedChildResourceDefinition(PathElement element) {
>>>>> 			super(PathElement.pathElement(?orderedA", new NonResolvingResourceDescriptionResolver(),
>>>>> 				new OrderedChildAddHandler(REQUEST_ATTRIBUTES), new ModelOnlyRemoveStepHandler());
>>>>> 		}
>>>>> 
>>>>> 		@Override
>>>>> 		protected boolean getOrderedChildResource() {
>>>>> 			return true;
>>>>> 		}
>>>>> 		?.
>>>>>  }
>>>>> This has the effect of adding a parameter called ?add-index? to the ?add? operation?s description. So if you have
>>>>> 	/some=where/orderedA=tree
>>>>> 	/some=where/orderedA=bush
>>>>> You can do e.g. /some=where/orderedA=hedge:add(add-index=1) and end up with:
>>>>> 	/some=where/orderedA=tree
>>>>> 	/some=where/orderedA=hedge
>>>>> 	/some=where/orderedA=bush
>>>>> 
>>>>> 3) The final part is to adjust the ordered child resource?s add handler to honour the add-index parameter:
>>>>> 
>>>>> 	class OrderedChildAddHandler extends AbstractAddStepHandler {
>>>>> 		public OrderedChildAddHandler(AttributeDefinition... attributes) {
>>>>> 			super(attributes);
>>>>> 	}
>>>>> 
>>>>> 	@Override
>>>>> 	protected Resource createResource(OperationContext context, ModelNode operation) {
>>>>> 		if (!operation.hasDefined(ADD_INDEX) || operation.get(ADD_INDEX).asInt() < 0) {
>>>>> 			return super.createResource(context);
>>>>> 		}
>>>>>          	return context.createResource(PathAddress.EMPTY_ADDRESS, operation.get(ADD_INDEX).asInt());
>>>>> 	}
>>>>> 
>>>>> 4) Not really related to what a user needs to do to create an ordered resource, but 1-3 are made possible by that on the resource interface I have two new methods:
>>>>>  /**
>>>>>   * Return the child types for which the order matters.
>>>>>   *
>>>>>   * @return {@code true} if the order of the children matters. If there are no ordered
>>>>>   * children and empty set is returned. This method should never return {@code null}
>>>>>   */
>>>>>  Set<String> getOrderedChildTypes();
>>>>> 
>>>>>  /**
>>>>>   * Register a child resource
>>>>>   *
>>>>>   * @param address the address
>>>>>   * @param index the index at which to add the resource. Existing children with this index and higher will be shifted one uo
>>>>>   * @param resource the resource
>>>>>   * @throws IllegalStateException for a duplicate entry or if the resource does not support ordered children
>>>>>   */
>>>>>  void registerChild(PathElement address, int index, Resource resource);
>>>>> 
>>>>> 
>>>>> The main question I have is whether 1-3 are too ?fragile? and if we need something to enforce/glue this together a bit more? At the same time ordered child resources should be the exception rather than the rule.
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> 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
>>> 
>>> 
>>> _______________________________________________
>>> 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  Thu Apr  2 13:00:15 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 02 Apr 2015 12:00:15 -0500
Subject: [wildfly-dev] Ordered child resources
In-Reply-To: <28164044-E6D4-4B7F-B422-888EA06A1F9B@jboss.com>
References: <CC2B46FD-BC25-42A9-92A0-937150983990@jboss.com>
	<551C3D61.1040907@redhat.com>
	<9787E9CB-16CB-465F-B395-97A3837E2FEE@jboss.com>
	<49CCC293-4EC0-40C9-AF37-14FBDB3C3407@jboss.com>
	<551D6B7E.3060206@redhat.com>
	<28164044-E6D4-4B7F-B422-888EA06A1F9B@jboss.com>
Message-ID: <551D759F.9020405@redhat.com>

On 4/2/15 11:53 AM, Kabir Khan wrote:
>
>> On 2 Apr 2015, at 17:17, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>
>> On 4/2/15 6:11 AM, Kabir Khan wrote:
>>>
>>>> On 2 Apr 2015, at 11:01, Kabir Khan <kabir.khan at jboss.com> wrote:
>>>>
>>>>
>>>>> On 1 Apr 2015, at 19:48, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>>>>
>>>>> Are the classes in your 2) and 3) new base classes, or examples of what
>>>>> users would need to do?
>>>>>
>>>>> Given your question, I figure it's the latter.
>>>> Yes they are examples cut and paste from a test case I am working on.
>>>>>
>>>>> It seems like it would be fairly straightforward to add the 3) stuff to
>>>>> AbstractAddStepHandler via a simple constructor param. The 1) stuff is
>>>>> pretty simple too, but doing both it and 3) starts to get messy in terms
>>>>> of too many constructor variants.
>>>> Rather than polluting the existing class too much, since this should really be an uncommon case (?) perhaps we need an AbstractOrderedAddStepHandler. But it is a bit weird since the parent and the child both need to override this differently. It shouldn?t be too hard to come up with something nicer though, I?ll let you know once I have had a play.
>>> It is doable, but all the constructors are getting a bit messy anyway. I?ll add a builder to AbstractAddStepHandler instead.
>>
>> This (meaning the general problem, not a builder approach per se) can get complicated, due to the different varieties:
>>
>> AbstractBoottimeAddStepHandler
>> RestartParentResourceAddHandler
>>
>> The latter sounds particularly relevant for the child resources, as the need for ordering implies that it's the parent that's using the child's config data to manage some service.
> I have scrapped the builder approach for now since these classes are built for overriding. I have:
>
> public abstract class AbstractOrderedResourceAddStepHandler extends AbstractAddStepHandler {
>      //Constructors
>     ?.
>
>      /**
>       * If this ia a parent resource with ordered child resources, return a set of the names of the ordered child types.
>       * If there are no ordered child types, return an empty set.
>       *
>       *  @return the ordered child types
>       */
>      protected Set<String> getOrderedChildTypes() {
>          return Collections.emptySet();
>      }
>
>      /**
>       * Return {@code true} if this is a child resource of a type whose parent supports ordered inserts
>       *
>       * @return whether ordered inserts are supportered
>       */
>      protected boolean supportIndexedAdd() {
>          return false;
>      }
>
>      @Override
>      protected Resource createResource(OperationContext context, ModelNode operation) {
>          Set<String> orderedChildTypes = getOrderedChildTypes();
> 	//Creates a parent with ordered children (if set is not empty)
>          Resource resource = Resource.Factory.create(false, orderedChildTypes);
>
> 	//Attempts to do the insert
>          int index = -1;
>          if (supportIndexedAdd() && operation.hasDefined(ADD_INDEX)) {
>              index = operation.get(ADD_INDEX).asInt();
>          }
>          if (index >= 0) {
>              context.addResource(PathAddress.EMPTY_ADDRESS, operation.get(ADD_INDEX).asInt(), resource);
>          } else {
>              context.addResource(PathAddress.EMPTY_ADDRESS, resource);
>          }
>          return resource;
>      }
> }
>
> but that does not take the restart part into account at all. Perhaps I should push this all up into AbstractAddHandler anyway. Do you mind having something like a
> public class AbstractAddHandler implements OperationStepHandler {
> ?.
> 	protected ResourceCreator getResourceCreator() {
> 		return DEFAULT; // does what AbstractAddHandler does presently
> 	}
>
> 	protected Resource createResource(OperationContext context, ModelNode operation) {
> 		return getResourceCreator().createResource(context, operation);
> 	}
> }
>
> I could then have an implementation along the lines of
> public class OrderedResourceCreator implements ResourceCreator {
> 	private final Set<String> orderedChildTypes;
> 	private final boolean indexedAdd;
> 	public OrderedResourceCreator(Set<String> orderedChildTypes, boolean indexedAdd) {
> 		this.orderedChildTypes = orderedChildTypes;
> 		this.indexedAdd = indexedAdd;
>          }
> 	protected Resource createResource(OperationContext context, ModelNode operation) {
> 		//same as AbstractOrderedResourceAddStepHandler.createResource() above
> 	}
> }
> and have sub-classes override getResourceCreator() to return that. Or do you really, really want this in the constructor rather than in an overridden getter?
>

Overriding is ok. I forgot about all the AbstractAddStepHandler 
constructor variants that came with the capabilities/requirements work. 
Adding this means too many permutations. Maybe we can make those go away 
and revisit this, but I think what you propose is fine.


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

From tomaz.cerar at gmail.com  Thu Apr  2 16:58:45 2015
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Thu, 2 Apr 2015 22:58:45 +0200
Subject: [wildfly-dev] Dropping legacy XSD schemas & its parsers
In-Reply-To: <551D6D07.4050808@redhat.com>
References: <CAMquZP4kGzBv+jy_f_P3nmVv=tPXwFFGwbWOzkpAa=vaPJdY0Q@mail.gmail.com>
	<55157228.2000604@redhat.com>
	<CAMquZP6COFFdunr-70RLnMe6D=Xw27V6qvCo4Ex3uHQSYXzMFQ@mail.gmail.com>
	<551974E5.1080508@redhat.com>
	<19455838.8453117.1427967290711.JavaMail.zimbra@redhat.com>
	<CAMquZP5TsLi=cPnxQ0gZpc271H9_5Pv537ms2vY23840r-9FNg@mail.gmail.com>
	<551D6D07.4050808@redhat.com>
Message-ID: <CAMquZP4Ljg=tFRVhBziE4XVzhjOin5V9sJ_LUBqH-TjJh3A13A@mail.gmail.com>

On Thu, Apr 2, 2015 at 6:23 PM, Brian Stansberry <
brian.stansberry at redhat.com> wrote:

> It's a good point though. Dropping this support has the potential to make
> that work harder. It doesn't make it impossible, but being able to parse
> old configs in the main server/HC code base might make EAP7-93 work easier.



lets talk about this on chat/hangout
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150402/cffeedd2/attachment.html 

From jperkins at redhat.com  Mon Apr  6 11:22:58 2015
From: jperkins at redhat.com (James R. Perkins)
Date: Mon, 06 Apr 2015 08:22:58 -0700
Subject: [wildfly-dev] Ordered child resources
In-Reply-To: <CC2B46FD-BC25-42A9-92A0-937150983990@jboss.com>
References: <CC2B46FD-BC25-42A9-92A0-937150983990@jboss.com>
Message-ID: <5522A4D2.1070905@redhat.com>

It's possible I'm misunderstanding, but would the using a comparator [1] 
in the describe handler work?

[1]: 
https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/java/org/jboss/as/controller/operations/common/GenericSubsystemDescribeHandler.java#L108

On 04/01/2015 05:54 AM, Kabir Khan wrote:
> I am working on being able to order child resources, this is important for things like jgroups where the protocol order matters. On top of the domain operations work I inherited from Emanuel the order will get propagated through the domain. Currently for jgroups the only way to adjust the protocol order is to remove all protocols and add them again, and on the domain ops branch (before what I am outlining here) upon reconnect any new protocols end up at the end of the slave?s list.
>
> The steps to make a child resource ordered are currently:
> 1) Make the ?parent? resource?s add handler call a different factory method:
> 	@Override
> 	protected Resource createResource(OperationContext context) {
> 		Resource resource = Resource.Factory.create(false, ?orderedA?, ?orderedB"); //Names of the child types where ordering matters
> 		context.addResource(PathAddress.EMPTY_ADDRESS, resource);
> 		return resource;
> 	}
>
> 2) In the ordered child resource definitions, override the new getOrderedChildResource() operation to
> 	class OrderedChildResourceDefinition extends SimpleResourceDefinition {
> 		public OrderedChildResourceDefinition(PathElement element) {
> 			super(PathElement.pathElement(?orderedA", new NonResolvingResourceDescriptionResolver(),
> 				new OrderedChildAddHandler(REQUEST_ATTRIBUTES), new ModelOnlyRemoveStepHandler());
> 		}
>
> 		@Override
> 		protected boolean getOrderedChildResource() {
> 			return true;
> 		}
> 		?.
>    }
> This has the effect of adding a parameter called ?add-index? to the ?add? operation?s description. So if you have
> 	/some=where/orderedA=tree
> 	/some=where/orderedA=bush
> You can do e.g. /some=where/orderedA=hedge:add(add-index=1) and end up with:
> 	/some=where/orderedA=tree
> 	/some=where/orderedA=hedge
> 	/some=where/orderedA=bush
>
> 3) The final part is to adjust the ordered child resource?s add handler to honour the add-index parameter:
>
> 	class OrderedChildAddHandler extends AbstractAddStepHandler {
> 		public OrderedChildAddHandler(AttributeDefinition... attributes) {
> 			super(attributes);
> 	}
>
> 	@Override
> 	protected Resource createResource(OperationContext context, ModelNode operation) {
> 		if (!operation.hasDefined(ADD_INDEX) || operation.get(ADD_INDEX).asInt() < 0) {
> 			return super.createResource(context);
> 		}
>            	return context.createResource(PathAddress.EMPTY_ADDRESS, operation.get(ADD_INDEX).asInt());
> 	}
>
> 4) Not really related to what a user needs to do to create an ordered resource, but 1-3 are made possible by that on the resource interface I have two new methods:
>    /**
>     * Return the child types for which the order matters.
>     *
>     * @return {@code true} if the order of the children matters. If there are no ordered
>     * children and empty set is returned. This method should never return {@code null}
>     */
>    Set<String> getOrderedChildTypes();
>
>    /**
>     * Register a child resource
>     *
>     * @param address the address
>     * @param index the index at which to add the resource. Existing children with this index and higher will be shifted one uo
>     * @param resource the resource
>     * @throws IllegalStateException for a duplicate entry or if the resource does not support ordered children
>     */
>    void registerChild(PathElement address, int index, Resource resource);
>
>
> The main question I have is whether 1-3 are too ?fragile? and if we need something to enforce/glue this together a bit more? At the same time ordered child resources should be the exception rather than the rule.
>
>
>
> _______________________________________________
> 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 stuart.w.douglas at gmail.com  Tue Apr  7 04:44:06 2015
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Tue, 7 Apr 2015 18:44:06 +1000
Subject: [wildfly-dev] Using JavaScript with Wildfly
Message-ID: <CAAoo=c66C3dmVMGjsLyWiQxUp_+MZzZh=K6dswXu=KWyv7VGcw@mail.gmail.com>

Hi all,

There has been some discussion about supporting JavaScript in Wildfly for a
while now, and as a result I have come up with a simple proof of concept of
the form I think this support could take.

At the moment this is actually not part of Wildfly at all, but rather a jar
file that you can include in your apps and allows you to register
JavaScript based handlers. These handlers can be mapped to URL's, and
inject container resources such as CDI beans and JNDI data sources. It also
provide some simple JavaScript wrappers to make some EE objects easier to
use from scripts.

At the moment handlers are mainly useful as REST endpoints, although if
there is interest I am planning on adding template engine support as well.

When combined with my external resources PR (
https://github.com/wildfly/wildfly/pull/7299) this allows for changes in
your script files to be immediately visible, without even needing to copy
to an exploded deployment.

I envisage the main use of this will not be creating node.js like apps that
are pure javascript, but rather to allow simpler parts of the app to be
written in JavaScript, and this avoiding the compile+redeploy cycle.

Full details are here: https://github.com/undertow-io/undertow.js

I have an example of the Kitchen Sink quickstart that has been re-done to
use this here:

https://github.com/wildfly/quickstart/compare/master...stuartwdouglas:js#diff-598449fd216b3768c251e297895211deR1

At this stage I am really not sure how this will evolve, or if it will go
anywhere, I am just putting it out there to get some feedback.

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

From kabir.khan at jboss.com  Tue Apr  7 06:27:40 2015
From: kabir.khan at jboss.com (Kabir Khan)
Date: Tue, 7 Apr 2015 11:27:40 +0100
Subject: [wildfly-dev] Ordered child resources
In-Reply-To: <5522A4D2.1070905@redhat.com>
References: <CC2B46FD-BC25-42A9-92A0-937150983990@jboss.com>
	<5522A4D2.1070905@redhat.com>
Message-ID: <A7745A5A-3E0C-4A7A-8A53-B1D70199063E@jboss.com>


> On 6 Apr 2015, at 16:22, James R. Perkins <jperkins at redhat.com> wrote:
> 
> It's possible I'm misunderstanding, but would the using a comparator [1] 
> in the describe handler work?
No :-)
> 
> [1]: 
> https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/java/org/jboss/as/controller/operations/common/GenericSubsystemDescribeHandler.java#L108
> 
> On 04/01/2015 05:54 AM, Kabir Khan wrote:
>> I am working on being able to order child resources, this is important for things like jgroups where the protocol order matters. On top of the domain operations work I inherited from Emanuel the order will get propagated through the domain. Currently for jgroups the only way to adjust the protocol order is to remove all protocols and add them again, and on the domain ops branch (before what I am outlining here) upon reconnect any new protocols end up at the end of the slave?s list.
>> 
>> The steps to make a child resource ordered are currently:
>> 1) Make the ?parent? resource?s add handler call a different factory method:
>> 	@Override
>> 	protected Resource createResource(OperationContext context) {
>> 		Resource resource = Resource.Factory.create(false, ?orderedA?, ?orderedB"); //Names of the child types where ordering matters
>> 		context.addResource(PathAddress.EMPTY_ADDRESS, resource);
>> 		return resource;
>> 	}
>> 
>> 2) In the ordered child resource definitions, override the new getOrderedChildResource() operation to
>> 	class OrderedChildResourceDefinition extends SimpleResourceDefinition {
>> 		public OrderedChildResourceDefinition(PathElement element) {
>> 			super(PathElement.pathElement(?orderedA", new NonResolvingResourceDescriptionResolver(),
>> 				new OrderedChildAddHandler(REQUEST_ATTRIBUTES), new ModelOnlyRemoveStepHandler());
>> 		}
>> 
>> 		@Override
>> 		protected boolean getOrderedChildResource() {
>> 			return true;
>> 		}
>> 		?.
>>   }
>> This has the effect of adding a parameter called ?add-index? to the ?add? operation?s description. So if you have
>> 	/some=where/orderedA=tree
>> 	/some=where/orderedA=bush
>> You can do e.g. /some=where/orderedA=hedge:add(add-index=1) and end up with:
>> 	/some=where/orderedA=tree
>> 	/some=where/orderedA=hedge
>> 	/some=where/orderedA=bush
>> 
>> 3) The final part is to adjust the ordered child resource?s add handler to honour the add-index parameter:
>> 
>> 	class OrderedChildAddHandler extends AbstractAddStepHandler {
>> 		public OrderedChildAddHandler(AttributeDefinition... attributes) {
>> 			super(attributes);
>> 	}
>> 
>> 	@Override
>> 	protected Resource createResource(OperationContext context, ModelNode operation) {
>> 		if (!operation.hasDefined(ADD_INDEX) || operation.get(ADD_INDEX).asInt() < 0) {
>> 			return super.createResource(context);
>> 		}
>>           	return context.createResource(PathAddress.EMPTY_ADDRESS, operation.get(ADD_INDEX).asInt());
>> 	}
>> 
>> 4) Not really related to what a user needs to do to create an ordered resource, but 1-3 are made possible by that on the resource interface I have two new methods:
>>   /**
>>    * Return the child types for which the order matters.
>>    *
>>    * @return {@code true} if the order of the children matters. If there are no ordered
>>    * children and empty set is returned. This method should never return {@code null}
>>    */
>>   Set<String> getOrderedChildTypes();
>> 
>>   /**
>>    * Register a child resource
>>    *
>>    * @param address the address
>>    * @param index the index at which to add the resource. Existing children with this index and higher will be shifted one uo
>>    * @param resource the resource
>>    * @throws IllegalStateException for a duplicate entry or if the resource does not support ordered children
>>    */
>>   void registerChild(PathElement address, int index, Resource resource);
>> 
>> 
>> The main question I have is whether 1-3 are too ?fragile? and if we need something to enforce/glue this together a bit more? At the same time ordered child resources should be the exception rather than the rule.
>> 
>> 
>> 
>> _______________________________________________
>> 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 kabir.khan at jboss.com  Tue Apr  7 08:16:30 2015
From: kabir.khan at jboss.com (Kabir Khan)
Date: Tue, 7 Apr 2015 13:16:30 +0100
Subject: [wildfly-dev] Ordered child resources
In-Reply-To: <551D759F.9020405@redhat.com>
References: <CC2B46FD-BC25-42A9-92A0-937150983990@jboss.com>
	<551C3D61.1040907@redhat.com>
	<9787E9CB-16CB-465F-B395-97A3837E2FEE@jboss.com>
	<49CCC293-4EC0-40C9-AF37-14FBDB3C3407@jboss.com>
	<551D6B7E.3060206@redhat.com>
	<28164044-E6D4-4B7F-B422-888EA06A1F9B@jboss.com>
	<551D759F.9020405@redhat.com>
Message-ID: <2D074F2E-D66B-4FCB-A082-B39BC66A8D60@jboss.com>

Hi,

I am adding a domain test to my indexed add stuff, and noticed the following in the inherited domain operations branch. However, it also seems to happen in master. The steps to reproduce are:

# Start a DC and a slave

# Reload the DC to admin only
[domain at localhost:9990 /] /host=master:reload(admin-only=true)

# Change something in a subsystem
[domain at localhost:9990 /] /profile=default/subsystem=logging/logger=test:add

# Reload the DC to be normal, so that the changes get applied
[domain at localhost:9990 /] /host=master:reload(admin-only=false)

# Now the changes are in the domain model and servers
[domain at localhost:9990 /] /profile=default/subsystem=logging:read-children-names(child-type=logger)
{
    "outcome" => "success",
    "result" => [
? SNIP --
        "test"
    ]
}
[domain at localhost:9990 /] /host=master/server=server-one/subsystem=logging:read-children-names(child-type=logger)
{
    "outcome" => "success",
    "result" => [
? SNIP --
        "test"
    ]
}

# They are also in the slave?s copy of the domain model
[domain at localhost:9990 /] connect remote://localhost:19999
[domain at localhost:19999 /] /profile=default/subsystem=logging:read-children-names(child-type=logger)
{
    "outcome" => "success",
    "result" => [
? SNIP --
        "test"
    ]
}

# But they are NOT in the slave server?s subsystem
[domain at localhost:19999 /] /host=localhost/server=server-one/subsystem=logging:read-children-names(child-type=logger)
{
    "outcome" => "success",
    "result" => [
        "com.arjuna",
        "jacorb",
        "jacorb.config",
        "org.apache.tomcat.util.modeler",
        "org.jboss.as.config",
        "sun.rmi"
    ]
}

# And the slave seems to have a normal state
[domain at localhost:19999 /] /host=localhost/server=server-one:read-resource(include-runtime=true)
{
    "outcome" => "success",
    "result" => {
        "host" => "localhost",
        "launch-type" => "DOMAIN",
        "management-major-version" => 3,
        "management-micro-version" => 0,
        "management-minor-version" => 0,
        "name" => "server-one",
        "namespaces" => [],
        "process-type" => "Server",
        "product-name" => undefined,
        "product-version" => undefined,
        "profile-name" => "default",
        "release-codename" => "Kenny",
        "release-version" => "1.0.0.Beta4-SNAPSHOT",
        "running-mode" => "NORMAL",
        "schema-locations" => [],
        "server-group" => "main-server-group",
        "server-state" => "running",
        "suspend-state" => "RUNNING",
? SNIP --
    }
}


I will attempt to fix this on the domain operations branch. Do we want to put the servers on the slave into reload-required, or should I propagate the operation to those?


> On 2 Apr 2015, at 18:00, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> 
> On 4/2/15 11:53 AM, Kabir Khan wrote:
>> 
>>> On 2 Apr 2015, at 17:17, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>> 
>>> On 4/2/15 6:11 AM, Kabir Khan wrote:
>>>> 
>>>>> On 2 Apr 2015, at 11:01, Kabir Khan <kabir.khan at jboss.com> wrote:
>>>>> 
>>>>> 
>>>>>> On 1 Apr 2015, at 19:48, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>>>>> 
>>>>>> Are the classes in your 2) and 3) new base classes, or examples of what
>>>>>> users would need to do?
>>>>>> 
>>>>>> Given your question, I figure it's the latter.
>>>>> Yes they are examples cut and paste from a test case I am working on.
>>>>>> 
>>>>>> It seems like it would be fairly straightforward to add the 3) stuff to
>>>>>> AbstractAddStepHandler via a simple constructor param. The 1) stuff is
>>>>>> pretty simple too, but doing both it and 3) starts to get messy in terms
>>>>>> of too many constructor variants.
>>>>> Rather than polluting the existing class too much, since this should really be an uncommon case (?) perhaps we need an AbstractOrderedAddStepHandler. But it is a bit weird since the parent and the child both need to override this differently. It shouldn?t be too hard to come up with something nicer though, I?ll let you know once I have had a play.
>>>> It is doable, but all the constructors are getting a bit messy anyway. I?ll add a builder to AbstractAddStepHandler instead.
>>> 
>>> This (meaning the general problem, not a builder approach per se) can get complicated, due to the different varieties:
>>> 
>>> AbstractBoottimeAddStepHandler
>>> RestartParentResourceAddHandler
>>> 
>>> The latter sounds particularly relevant for the child resources, as the need for ordering implies that it's the parent that's using the child's config data to manage some service.
>> I have scrapped the builder approach for now since these classes are built for overriding. I have:
>> 
>> public abstract class AbstractOrderedResourceAddStepHandler extends AbstractAddStepHandler {
>>     //Constructors
>>    ?.
>> 
>>     /**
>>      * If this ia a parent resource with ordered child resources, return a set of the names of the ordered child types.
>>      * If there are no ordered child types, return an empty set.
>>      *
>>      *  @return the ordered child types
>>      */
>>     protected Set<String> getOrderedChildTypes() {
>>         return Collections.emptySet();
>>     }
>> 
>>     /**
>>      * Return {@code true} if this is a child resource of a type whose parent supports ordered inserts
>>      *
>>      * @return whether ordered inserts are supportered
>>      */
>>     protected boolean supportIndexedAdd() {
>>         return false;
>>     }
>> 
>>     @Override
>>     protected Resource createResource(OperationContext context, ModelNode operation) {
>>         Set<String> orderedChildTypes = getOrderedChildTypes();
>> 	//Creates a parent with ordered children (if set is not empty)
>>         Resource resource = Resource.Factory.create(false, orderedChildTypes);
>> 
>> 	//Attempts to do the insert
>>         int index = -1;
>>         if (supportIndexedAdd() && operation.hasDefined(ADD_INDEX)) {
>>             index = operation.get(ADD_INDEX).asInt();
>>         }
>>         if (index >= 0) {
>>             context.addResource(PathAddress.EMPTY_ADDRESS, operation.get(ADD_INDEX).asInt(), resource);
>>         } else {
>>             context.addResource(PathAddress.EMPTY_ADDRESS, resource);
>>         }
>>         return resource;
>>     }
>> }
>> 
>> but that does not take the restart part into account at all. Perhaps I should push this all up into AbstractAddHandler anyway. Do you mind having something like a
>> public class AbstractAddHandler implements OperationStepHandler {
>> ?.
>> 	protected ResourceCreator getResourceCreator() {
>> 		return DEFAULT; // does what AbstractAddHandler does presently
>> 	}
>> 
>> 	protected Resource createResource(OperationContext context, ModelNode operation) {
>> 		return getResourceCreator().createResource(context, operation);
>> 	}
>> }
>> 
>> I could then have an implementation along the lines of
>> public class OrderedResourceCreator implements ResourceCreator {
>> 	private final Set<String> orderedChildTypes;
>> 	private final boolean indexedAdd;
>> 	public OrderedResourceCreator(Set<String> orderedChildTypes, boolean indexedAdd) {
>> 		this.orderedChildTypes = orderedChildTypes;
>> 		this.indexedAdd = indexedAdd;
>>         }
>> 	protected Resource createResource(OperationContext context, ModelNode operation) {
>> 		//same as AbstractOrderedResourceAddStepHandler.createResource() above
>> 	}
>> }
>> and have sub-classes override getResourceCreator() to return that. Or do you really, really want this in the constructor rather than in an overridden getter?
>> 
> 
> Overriding is ok. I forgot about all the AbstractAddStepHandler 
> constructor variants that came with the capabilities/requirements work. 
> Adding this means too many permutations. Maybe we can make those go away 
> and revisit this, but I think what you propose is fine.
> 
> 
> -- 
> 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 manderse at redhat.com  Thu Apr  9 07:26:46 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Thu, 09 Apr 2015 13:26:46 +0200
Subject: [wildfly-dev] Using JavaScript with Wildfly
In-Reply-To: <CAAoo=c66C3dmVMGjsLyWiQxUp_+MZzZh=K6dswXu=KWyv7VGcw@mail.gmail.com>
References: <CAAoo=c66C3dmVMGjsLyWiQxUp_+MZzZh=K6dswXu=KWyv7VGcw@mail.gmail.com>
Message-ID: <D6E6E366-197F-4FF7-BCAC-E65160644604@redhat.com>


very cool - definitely interested.

> When combined with my external resources PR (
> https://github.com/wildfly/wildfly/pull/7299) this allows for changes 
> in
> your script files to be immediately visible, without even needing to 
> copy
> to an exploded deployment.

but changing/updating javascript in exploded would work too ?

Where can I get more info about external resources ? i don't see any 
tests or examples of how to use that.

It looks like its suggested the mount info would be inside the archive 
which seems weird to me ;)

/max
http://about.me/maxandersen

From stuart.w.douglas at gmail.com  Thu Apr  9 07:30:48 2015
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Thu, 09 Apr 2015 21:30:48 +1000
Subject: [wildfly-dev] Using JavaScript with Wildfly
In-Reply-To: <D6E6E366-197F-4FF7-BCAC-E65160644604@redhat.com>
References: <CAAoo=c66C3dmVMGjsLyWiQxUp_+MZzZh=K6dswXu=KWyv7VGcw@mail.gmail.com>
	<D6E6E366-197F-4FF7-BCAC-E65160644604@redhat.com>
Message-ID: <552662E8.8020505@gmail.com>



Max Rydahl Andersen wrote:
>
> very cool - definitely interested.
>
>> When combined with my external resources PR (
>> https://github.com/wildfly/wildfly/pull/7299) this allows for changes in
>> your script files to be immediately visible, without even needing to copy
>> to an exploded deployment.
>
> but changing/updating javascript in exploded would work too ?

Yes

>
> Where can I get more info about external resources ? i don't see any
> tests or examples of how to use that.
>
> It looks like its suggested the mount info would be inside the archive
> which seems weird to me ;)


It only just went in, basically there is just a file 
(WEB-INF/undertow-external-mounts.conf) that contains the external mount 
points. In terms of workflow I was thinking that this file would just be 
added to .gitignore (or equivalent), and each developer would just have 
their own version pointed at their local workspace.

Stuart


>
> /max
> http://about.me/maxandersen

From manderse at redhat.com  Thu Apr  9 07:56:20 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Thu, 09 Apr 2015 13:56:20 +0200
Subject: [wildfly-dev] Using JavaScript with Wildfly
In-Reply-To: <552662E8.8020505@gmail.com>
References: <CAAoo=c66C3dmVMGjsLyWiQxUp_+MZzZh=K6dswXu=KWyv7VGcw@mail.gmail.com>
	<D6E6E366-197F-4FF7-BCAC-E65160644604@redhat.com>
	<552662E8.8020505@gmail.com>
Message-ID: <F8A5BCCF-76F7-4F59-8D97-D2CF581C5EFF@redhat.com>

On 9 Apr 2015, at 13:30, Stuart Douglas wrote:

> Max Rydahl Andersen wrote:
>>
>> very cool - definitely interested.
>>
>>> When combined with my external resources PR (
>>> https://github.com/wildfly/wildfly/pull/7299) this allows for 
>>> changes in
>>> your script files to be immediately visible, without even needing to 
>>> copy
>>> to an exploded deployment.
>>
>> but changing/updating javascript in exploded would work too ?
>
> Yes

great.

>> Where can I get more info about external resources ? i don't see any
>> tests or examples of how to use that.
>>
>> It looks like its suggested the mount info would be inside the 
>> archive
>> which seems weird to me ;)
>
>
> It only just went in, basically there is just a file 
> (WEB-INF/undertow-external-mounts.conf) that contains the external 
> mount points.

what is the syntax/format ?

> In terms of workflow I was thinking that this file would just be added 
> to .gitignore (or equivalent), and each developer would just have 
> their own version pointed at their local workspace.

yeah, well..hmm...I'll have to try it first to comment. :)

/max
http://about.me/maxandersen

From jason.greene at redhat.com  Fri Apr 10 19:23:54 2015
From: jason.greene at redhat.com (Jason Greene)
Date: Fri, 10 Apr 2015 18:23:54 -0500
Subject: [wildfly-dev] Call For Final Component Upgrades
Message-ID: <5FB2A2C9-E3B0-430F-888F-0FA218E749ED@redhat.com>

If you haven?t already, please send in a PR updating your component to Final status, as we hope to release 9 Final this month.

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



From bgaisford at punagroup.com  Fri Apr 10 22:18:23 2015
From: bgaisford at punagroup.com (Brandon Gaisford)
Date: Fri, 10 Apr 2015 16:18:23 -1000
Subject: [wildfly-dev] WFLY-2456 Sources Sought
Message-ID: <5F381CC9-2FEE-4390-A0D7-E726023A7D76@punagroup.com>


Newbie contributor here,

Started looking into WFLY-2456, have forked/cloned/built the project and the server starts up as expected.  Started digging through the source tree for the org.jboss.as.domain.management.security.adduser.AddUser class but it does?t appear to be there.  I?m guessing the dependency is being sucked in by Maven during the build process.

A quick search through the dist tree reveals a couple jars that contain the class in question: 

Starting search for org/jboss/as/domain/management/security/adduser/AddUser.class in /Volumes/Dev/punagroup/git/wildfly
Zipfile: /Volumes/Dev/punagroup/git/wildfly/build/target/wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar contains entry name: org/jboss/as/domain/management/security/adduser/AddUser.class
Zipfile: /Volumes/Dev/punagroup/git/wildfly/dist/target/wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar contains entry name: org/jboss/as/domain/management/security/adduser/AddUser.class
Zipfile: /Volumes/Dev/punagroup/git/wildfly/dist/target/wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar contains entry name: org/jboss/as/domain/management/security/adduser/AddUser.class
Zipfile: /Volumes/Dev/punagroup/git/wildfly/testsuite/integration/smoke/target/jbossas/bin/client/jboss-cli-client.jar contains entry name: org/jboss/as/domain/management/security/adduser/AddUser.class
Zipfile: /Volumes/Dev/punagroup/git/wildfly/testsuite/integration/target/jbossas/bin/client/jboss-cli-client.jar contains entry name: org/jboss/as/domain/management/security/adduser/AddUser.class
Zipfile: /Volumes/Dev/punagroup/git/wildfly/web-dist/target/wildfly-web-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar contains entry name: org/jboss/as/domain/management/security/adduser/AddUser.class
Exiting routine.

Looking for advice from the group, has this code not been migrated to the new source tree yet, or are there other intentions.  Any pointers would be appreciated.


Brandon 



From jason.greene at redhat.com  Fri Apr 10 23:28:14 2015
From: jason.greene at redhat.com (Jason T. Greene)
Date: Fri, 10 Apr 2015 23:28:14 -0400 (EDT)
Subject: [wildfly-dev] WFLY-2456 Sources Sought
In-Reply-To: <5F381CC9-2FEE-4390-A0D7-E726023A7D76@punagroup.com>
References: <5F381CC9-2FEE-4390-A0D7-E726023A7D76@punagroup.com>
Message-ID: <74E27C31-2C1D-4110-9AF8-9F4885751FE1@redhat.com>

Hello Brandon,

We split the source base for 9, so now the core server is in a separate repo, wildfly-core. 

The class you are looking for is here:
https://github.com/wildfly/wildfly-core/tree/master/domain-management/src/main/java/org/jboss/as/domain/management/security/adduser

Happy Hacking,
-Jason

> On Apr 10, 2015, at 9:19 PM, Brandon Gaisford <bgaisford at punagroup.com> wrote:
> 
> 
> Newbie contributor here,
> 
> Started looking into WFLY-2456, have forked/cloned/built the project and the server starts up as expected.  Started digging through the source tree for the org.jboss.as.domain.management.security.adduser.AddUser class but it does?t appear to be there.  I?m guessing the dependency is being sucked in by Maven during the build process.
> 
> A quick search through the dist tree reveals a couple jars that contain the class in question: 
> 
> Starting search for org/jboss/as/domain/management/security/adduser/AddUser.class in /Volumes/Dev/punagroup/git/wildfly
> Zipfile: /Volumes/Dev/punagroup/git/wildfly/build/target/wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar contains entry name: org/jboss/as/domain/management/security/adduser/AddUser.class
> Zipfile: /Volumes/Dev/punagroup/git/wildfly/dist/target/wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar contains entry name: org/jboss/as/domain/management/security/adduser/AddUser.class
> Zipfile: /Volumes/Dev/punagroup/git/wildfly/dist/target/wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar contains entry name: org/jboss/as/domain/management/security/adduser/AddUser.class
> Zipfile: /Volumes/Dev/punagroup/git/wildfly/testsuite/integration/smoke/target/jbossas/bin/client/jboss-cli-client.jar contains entry name: org/jboss/as/domain/management/security/adduser/AddUser.class
> Zipfile: /Volumes/Dev/punagroup/git/wildfly/testsuite/integration/target/jbossas/bin/client/jboss-cli-client.jar contains entry name: org/jboss/as/domain/management/security/adduser/AddUser.class
> Zipfile: /Volumes/Dev/punagroup/git/wildfly/web-dist/target/wildfly-web-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar contains entry name: org/jboss/as/domain/management/security/adduser/AddUser.class
> Exiting routine.
> 
> Looking for advice from the group, has this code not been migrated to the new source tree yet, or are there other intentions.  Any pointers would be appreciated.
> 
> 
> Brandon 
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From eduardo.santanadasilva at gmail.com  Sat Apr 11 07:00:26 2015
From: eduardo.santanadasilva at gmail.com (Eduardo Sant'Ana da Silva)
Date: Sat, 11 Apr 2015 08:00:26 -0300
Subject: [wildfly-dev] WFLY-2456 Sources Sought
In-Reply-To: <74E27C31-2C1D-4110-9AF8-9F4885751FE1@redhat.com>
References: <5F381CC9-2FEE-4390-A0D7-E726023A7D76@punagroup.com>
	<74E27C31-2C1D-4110-9AF8-9F4885751FE1@redhat.com>
Message-ID: <7C77C4B9-2A6F-48A2-BB2C-47D25D7E8116@gmail.com>

If you are looking for the jars that contains that class, the dist of wildfly-9.0.0.CR1-SNAPSHOT have it on  those two jars:

org.jboss.as.domain.management.security.adduser.AddUser

                 located in jar         ./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar

org.jboss.as.domain.management.security.adduser.AddUser

                 located in jar         ./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar

If you look at ./dist/target instead of the project root it will reduce the ambiguities on your search.
I've made a tool for locate classes as you did, I called jfinder and it facilitates my life a lot.  :)
Actually, I have to improve that, because it brings anything that contains the string to be searched.


java -jar ~/jfinder.jar . org.jboss.as.domain.management.security.adduser.AddUser
JFinder version 0.02
author: Eduardo Sant'Ana da Silva
org.jboss.as.domain.management.security.adduser.AddUser$1
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$1
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$10
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$11
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$12
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$13
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$14
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$15
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$2
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$3
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$4
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$5
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$6
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$7
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$8
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$9
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
org.jboss.as.domain.management.security.adduser.AddUser$FileMode
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
org.jboss.as.domain.management.security.adduser.AddUser$Interactiveness
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
org.jboss.as.domain.management.security.adduser.AddUser$RealmMode
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
org.jboss.as.domain.management.security.adduser.AddUser
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
org.jboss.as.domain.management.security.adduser.AddUserFailedException
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
org.jboss.as.domain.management.security.adduser.AddUserState
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
org.jboss.as.domain.management.security.adduser.AddUser$1
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$1
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$10
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$11
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$12
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$13
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$14
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$15
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$2
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$3
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$4
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$5
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$6
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$7
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$8
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$9
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
org.jboss.as.domain.management.security.adduser.AddUser$FileMode
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
org.jboss.as.domain.management.security.adduser.AddUser$Interactiveness
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
org.jboss.as.domain.management.security.adduser.AddUser$RealmMode
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
org.jboss.as.domain.management.security.adduser.AddUser
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
org.jboss.as.domain.management.security.adduser.AddUserFailedException
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
org.jboss.as.domain.management.security.adduser.AddUserState
		 located in jar  	/Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar

On Apr 11, 2015, at 12:28 AM, Jason T. Greene <jason.greene at redhat.com> wrote:

> Hello Brandon,
> 
> We split the source base for 9, so now the core server is in a separate repo, wildfly-core. 
> 
> The class you are looking for is here:
> https://github.com/wildfly/wildfly-core/tree/master/domain-management/src/main/java/org/jboss/as/domain/management/security/adduser
> 
> Happy Hacking,
> -Jason
> 
>> On Apr 10, 2015, at 9:19 PM, Brandon Gaisford <bgaisford at punagroup.com> wrote:
>> 
>> 
>> Newbie contributor here,
>> 
>> Started looking into WFLY-2456, have forked/cloned/built the project and the server starts up as expected.  Started digging through the source tree for the org.jboss.as.domain.management.security.adduser.AddUser class but it does?t appear to be there.  I?m guessing the dependency is being sucked in by Maven during the build process.
>> 
>> A quick search through the dist tree reveals a couple jars that contain the class in question: 
>> 
>> Starting search for org/jboss/as/domain/management/security/adduser/AddUser.class in /Volumes/Dev/punagroup/git/wildfly
>> Zipfile: /Volumes/Dev/punagroup/git/wildfly/build/target/wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar contains entry name: org/jboss/as/domain/management/security/adduser/AddUser.class
>> Zipfile: /Volumes/Dev/punagroup/git/wildfly/dist/target/wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar contains entry name: org/jboss/as/domain/management/security/adduser/AddUser.class
>> Zipfile: /Volumes/Dev/punagroup/git/wildfly/dist/target/wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar contains entry name: org/jboss/as/domain/management/security/adduser/AddUser.class
>> Zipfile: /Volumes/Dev/punagroup/git/wildfly/testsuite/integration/smoke/target/jbossas/bin/client/jboss-cli-client.jar contains entry name: org/jboss/as/domain/management/security/adduser/AddUser.class
>> Zipfile: /Volumes/Dev/punagroup/git/wildfly/testsuite/integration/target/jbossas/bin/client/jboss-cli-client.jar contains entry name: org/jboss/as/domain/management/security/adduser/AddUser.class
>> Zipfile: /Volumes/Dev/punagroup/git/wildfly/web-dist/target/wildfly-web-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar contains entry name: org/jboss/as/domain/management/security/adduser/AddUser.class
>> Exiting routine.
>> 
>> Looking for advice from the group, has this code not been migrated to the new source tree yet, or are there other intentions.  Any pointers would be appreciated.
>> 
>> 
>> Brandon 
>> 
>> 
>> _______________________________________________
>> 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/20150411/c551e182/attachment-0001.html 

From ales.justin at gmail.com  Mon Apr 13 07:21:44 2015
From: ales.justin at gmail.com (Ales Justin)
Date: Mon, 13 Apr 2015 13:21:44 +0200
Subject: [wildfly-dev] Call For Final Component Upgrades
In-Reply-To: <5FB2A2C9-E3B0-430F-888F-0FA218E749ED@redhat.com>
References: <5FB2A2C9-E3B0-430F-888F-0FA218E749ED@redhat.com>
Message-ID: <8EC07451-D2AE-4BC2-B9F8-3E670DBE674C@gmail.com>

Hibernate Search / Infinispan Query modules (and its dependencies) need a complete overhaul -- as they are a complete mess / useless atm.

So I'm just wondering who's gonna take this over?
Sanne / Gustavo?

-Ales

> On 11 Apr 2015, at 01:23, Jason Greene <jason.greene at redhat.com> wrote:
> 
> If you haven?t already, please send in a PR updating your component to Final status, as we hope to release 9 Final this month.
> 
> Thanks!
> --
> 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 darran.lofthouse at jboss.com  Mon Apr 13 07:54:18 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Mon, 13 Apr 2015 12:54:18 +0100
Subject: [wildfly-dev] WFLY-2456 Sources Sought
In-Reply-To: <7C77C4B9-2A6F-48A2-BB2C-47D25D7E8116@gmail.com>
References: <5F381CC9-2FEE-4390-A0D7-E726023A7D76@punagroup.com>	<74E27C31-2C1D-4110-9AF8-9F4885751FE1@redhat.com>
	<7C77C4B9-2A6F-48A2-BB2C-47D25D7E8116@gmail.com>
Message-ID: <552BAE6A.2020705@jboss.com>

On Linux the following effectively does the same thing: -

   find -name "*.jar" | xargs grep fully.qualified.class.name

e.g.

$ find -name "*.jar" | xargs grep 
org.jboss.as.domain.management.security.adduser.AddUser

Binary file ./bin/client/jboss-cli-client.jar matches
Binary file 
./modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta4-SNAPSHOT.jar 
matches


Regards,
Darran Lofthouse.


On 11/04/15 12:00, Eduardo Sant'Ana da Silva wrote:
> If you are looking for the jars that contains that class, the dist of
> wildfly-9.0.0.CR1-SNAPSHOT have it on  those two jars:
>
> org.jboss.as.domain.management.security.adduser.AddUser
>
>                   located in jar
>    ./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
>
> org.jboss.as.domain.management.security.adduser.AddUser
>
>                   located in jar
>    ./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
>
> If you look at ./dist/target instead of the project root it will reduce
> the ambiguities on your search.
> I've made a tool for locate classes as you did, I called jfinder and it
> facilitates my life a lot.  :)
> Actually, I have to improve that, because it brings anything that
> contains the string to be searched.
>
>
> java -jar ~/jfinder.jar .
> org.jboss.as.domain.management.security.adduser.AddUser
> JFinder version 0.02
> author: Eduardo Sant'Ana da Silva
> org.jboss.as.domain.management.security.adduser.AddUser$1
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
> org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$1
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
> org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$10
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
> org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$11
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
> org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$12
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
> org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$13
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
> org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$14
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
> org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$15
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
> org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$2
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
> org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$3
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
> org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$4
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
> org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$5
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
> org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$6
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
> org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$7
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
> org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$8
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
> org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$9
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
> org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
> org.jboss.as.domain.management.security.adduser.AddUser$FileMode
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
> org.jboss.as.domain.management.security.adduser.AddUser$Interactiveness
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
> org.jboss.as.domain.management.security.adduser.AddUser$RealmMode
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
> org.jboss.as.domain.management.security.adduser.AddUser
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
> org.jboss.as.domain.management.security.adduser.AddUserFailedException
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
> org.jboss.as.domain.management.security.adduser.AddUserState
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
> org.jboss.as.domain.management.security.adduser.AddUser$1
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
> org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$1
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
> org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$10
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
> org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$11
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
> org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$12
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
> org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$13
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
> org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$14
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
> org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$15
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
> org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$2
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
> org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$3
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
> org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$4
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
> org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$5
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
> org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$6
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
> org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$7
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
> org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$8
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
> org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument$9
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
> org.jboss.as.domain.management.security.adduser.AddUser$CommandLineArgument
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
> org.jboss.as.domain.management.security.adduser.AddUser$FileMode
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
> org.jboss.as.domain.management.security.adduser.AddUser$Interactiveness
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
> org.jboss.as.domain.management.security.adduser.AddUser$RealmMode
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
> org.jboss.as.domain.management.security.adduser.AddUser
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
> org.jboss.as.domain.management.security.adduser.AddUserFailedException
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
> org.jboss.as.domain.management.security.adduser.AddUserState
> located in jar
> /Users/eduardo/Data/Professional/RedHat/WildFly/Repo/jboss-as/dist/target/./wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
>
> On Apr 11, 2015, at 12:28 AM, Jason T. Greene <jason.greene at redhat.com
> <mailto:jason.greene at redhat.com>> wrote:
>
>> Hello Brandon,
>>
>> We split the source base for 9, so now the core server is in a
>> separate repo, wildfly-core.
>>
>> The class you are looking for is here:
>> https://github.com/wildfly/wildfly-core/tree/master/domain-management/src/main/java/org/jboss/as/domain/management/security/adduser
>>
>> Happy Hacking,
>> -Jason
>>
>>> On Apr 10, 2015, at 9:19 PM, Brandon Gaisford
>>> <bgaisford at punagroup.com> wrote:
>>>
>>>
>>> Newbie contributor here,
>>>
>>> Started looking into WFLY-2456, have forked/cloned/built the project
>>> and the server starts up as expected.  Started digging through the
>>> source tree for the
>>> org.jboss.as.domain.management.security.adduser.AddUser class but it
>>> does?t appear to be there.  I?m guessing the dependency is being
>>> sucked in by Maven during the build process.
>>>
>>> A quick search through the dist tree reveals a couple jars that
>>> contain the class in question:
>>>
>>> Starting search for
>>> org/jboss/as/domain/management/security/adduser/AddUser.class in
>>> /Volumes/Dev/punagroup/git/wildfly
>>> Zipfile:
>>> /Volumes/Dev/punagroup/git/wildfly/build/target/wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
>>> contains entry name:
>>> org/jboss/as/domain/management/security/adduser/AddUser.class
>>> Zipfile:
>>> /Volumes/Dev/punagroup/git/wildfly/dist/target/wildfly-9.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar
>>> contains entry name:
>>> org/jboss/as/domain/management/security/adduser/AddUser.class
>>> Zipfile:
>>> /Volumes/Dev/punagroup/git/wildfly/dist/target/wildfly-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
>>> contains entry name:
>>> org/jboss/as/domain/management/security/adduser/AddUser.class
>>> Zipfile:
>>> /Volumes/Dev/punagroup/git/wildfly/testsuite/integration/smoke/target/jbossas/bin/client/jboss-cli-client.jar
>>> contains entry name:
>>> org/jboss/as/domain/management/security/adduser/AddUser.class
>>> Zipfile:
>>> /Volumes/Dev/punagroup/git/wildfly/testsuite/integration/target/jbossas/bin/client/jboss-cli-client.jar
>>> contains entry name:
>>> org/jboss/as/domain/management/security/adduser/AddUser.class
>>> Zipfile:
>>> /Volumes/Dev/punagroup/git/wildfly/web-dist/target/wildfly-web-9.0.0.CR1-SNAPSHOT/modules/system/layers/base/org/jboss/as/domain-management/main/wildfly-domain-management-1.0.0.Beta2.jar
>>> contains entry name:
>>> org/jboss/as/domain/management/security/adduser/AddUser.class
>>> Exiting routine.
>>>
>>> Looking for advice from the group, has this code not been migrated to
>>> the new source tree yet, or are there other intentions.  Any pointers
>>> would be appreciated.
>>>
>>>
>>> Brandon
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From darran.lofthouse at jboss.com  Mon Apr 13 08:10:48 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Mon, 13 Apr 2015 13:10:48 +0100
Subject: [wildfly-dev] Call For Final Component Upgrades
In-Reply-To: <5FB2A2C9-E3B0-430F-888F-0FA218E749ED@redhat.com>
References: <5FB2A2C9-E3B0-430F-888F-0FA218E749ED@redhat.com>
Message-ID: <552BB248.6030801@jboss.com>

Is there going to be a candidate release?  The reason I released a CR of 
Remoting JMX was to try and give an opportunity for community to test 
the reported bugs are fixed in the next WildFly CR before all are tagged 
.Final.


On 11/04/15 00:23, Jason Greene wrote:
> If you haven?t already, please send in a PR updating your component to Final status, as we hope to release 9 Final this month.
>
> Thanks!
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From jason.greene at redhat.com  Mon Apr 13 09:25:47 2015
From: jason.greene at redhat.com (Jason T. Greene)
Date: Mon, 13 Apr 2015 09:25:47 -0400 (EDT)
Subject: [wildfly-dev] Call For Final Component Upgrades
In-Reply-To: <552BB248.6030801@jboss.com>
References: <5FB2A2C9-E3B0-430F-888F-0FA218E749ED@redhat.com>
	<552BB248.6030801@jboss.com>
Message-ID: <40659E0E-1FAB-444F-90A5-98CBDEDE7314@redhat.com>

Yes but a very short one. So far we have had nothing major on Beta, so I think it's pretty solid. It would mainly be to shake out any release errors.

Ideally we wouldn't be updating all deps unless there was an actual bug we had to fix. Is there a quality concern or is it more just not jumping right to final for your component?

> On Apr 13, 2015, at 7:11 AM, Darran Lofthouse <darran.lofthouse at jboss.com> wrote:
> 
> Is there going to be a candidate release?  The reason I released a CR of 
> Remoting JMX was to try and give an opportunity for community to test 
> the reported bugs are fixed in the next WildFly CR before all are tagged 
> .Final.
> 
> 
>> On 11/04/15 00:23, Jason Greene wrote:
>> If you haven?t already, please send in a PR updating your component to Final status, as we hope to release 9 Final this month.
>> 
>> Thanks!
>> --
>> Jason T. Greene
>> WildFly Lead / JBoss EAP Platform Architect
>> JBoss, a division of Red Hat
>> 
>> 
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From darran.lofthouse at jboss.com  Mon Apr 13 09:31:33 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Mon, 13 Apr 2015 14:31:33 +0100
Subject: [wildfly-dev] Call For Final Component Upgrades
In-Reply-To: <40659E0E-1FAB-444F-90A5-98CBDEDE7314@redhat.com>
References: <5FB2A2C9-E3B0-430F-888F-0FA218E749ED@redhat.com>
	<552BB248.6030801@jboss.com>
	<40659E0E-1FAB-444F-90A5-98CBDEDE7314@redhat.com>
Message-ID: <552BC535.2030705@jboss.com>

On 13/04/15 14:25, Jason T. Greene wrote:
> Yes but a very short one. So far we have had nothing major on Beta, so I think it's pretty solid. It would mainly be to shake out any release errors.
>
> Ideally we wouldn't be updating all deps unless there was an actual bug we had to fix. Is there a quality concern or is it more just not jumping right to final for your component?

No real quality concern, bug fixes affected connection state so would 
just be nice for an opportunity for community to also report back.

I can tag now if you really want but also not a big deal to tag at an 
agreed date - it is a genuine candidate for release.

>
>> On Apr 13, 2015, at 7:11 AM, Darran Lofthouse <darran.lofthouse at jboss.com> wrote:
>>
>> Is there going to be a candidate release?  The reason I released a CR of
>> Remoting JMX was to try and give an opportunity for community to test
>> the reported bugs are fixed in the next WildFly CR before all are tagged
>> .Final.
>>
>>
>>> On 11/04/15 00:23, Jason Greene wrote:
>>> If you haven?t already, please send in a PR updating your component to Final status, as we hope to release 9 Final this month.
>>>
>>> Thanks!
>>> --
>>> Jason T. Greene
>>> WildFly Lead / JBoss EAP Platform Architect
>>> JBoss, a division of Red Hat
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From tomaz.cerar at gmail.com  Tue Apr 14 10:15:44 2015
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Tue, 14 Apr 2015 16:15:44 +0200
Subject: [wildfly-dev] Dropping legacy XSD schemas & its parsers
In-Reply-To: <551D6D07.4050808@redhat.com>
References: <CAMquZP4kGzBv+jy_f_P3nmVv=tPXwFFGwbWOzkpAa=vaPJdY0Q@mail.gmail.com>
	<55157228.2000604@redhat.com>
	<CAMquZP6COFFdunr-70RLnMe6D=Xw27V6qvCo4Ex3uHQSYXzMFQ@mail.gmail.com>
	<551974E5.1080508@redhat.com>
	<19455838.8453117.1427967290711.JavaMail.zimbra@redhat.com>
	<CAMquZP5TsLi=cPnxQ0gZpc271H9_5Pv537ms2vY23840r-9FNg@mail.gmail.com>
	<551D6D07.4050808@redhat.com>
Message-ID: <CAMquZP6TfZjiNGpZwWayiUD21-6h2u5_X7EQr74x5GRLDxX8vQ@mail.gmail.com>

As discussed on various mediums (irc, hipchat, mail)
dropping any parsers/xsd schemas included in EAP 6.0.0(AS7.1.2) and up
doesn't really make any sense at this point.

It would just make migration efforts harder.

We need to make sure that all old parsers still provide working subsystem
as I know some of them have had problems with that.

We could probably go and remove any parsers introduced before AS7.1.2 for
example ones from 7.0.x series.
That shouldn't be a priority or standalone task, but if someone is doing
work in same area it could go ahead.

If anyone sees any problems with supporting that old parsers please speak
up.

--
tomaz

On Thu, Apr 2, 2015 at 6:23 PM, Brian Stansberry <
brian.stansberry at redhat.com> wrote:

> On 4/2/15 4:46 AM, Toma? Cerar wrote:
>
>>
>> On Thu, Apr 2, 2015 at 11:34 AM, Rostislav Svoboda <rsvoboda at redhat.com
>> <mailto:rsvoboda at redhat.com>> wrote:
>>
>>     Doesn't "anything that is older than AS7.3 / EAP 6.2 is optional and
>>     can get dropped." affect https://issues.jboss.org/browse/EAP7-93 ?
>>
>>
>> No it doesn't, it is somewhat related but EAP7-93 will still be satisfied.
>>
>
> It's a good point though. Dropping this support has the potential to make
> that work harder. It doesn't make it impossible, but being able to parse
> old configs in the main server/HC code base might make EAP7-93 work easier.
>
>
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150414/672ad2a9/attachment.html 

From bgaisford at punagroup.com  Tue Apr 14 15:47:55 2015
From: bgaisford at punagroup.com (Brandon Gaisford)
Date: Tue, 14 Apr 2015 09:47:55 -1000
Subject: [wildfly-dev] (WFCORE-640) Platform and User Specific Unit Tests
Message-ID: <9BC41E4B-FFDE-4C9C-B228-6F26D472CE50@punagroup.com>


Hello,

I?m code complete on WFCORE-640 and have completed my development testing on OS X and Windows 7.  This feature deals with resolution of file permissions and I?m not sure how best to proceed with the creation of unit tests and subsequent Maven integration.  Not being very familiar with the build and release process I thought others may have some advice.

Does the current build process get executed on both *nix and Windows platforms?  Platform specific unit test init scripts need to be executed to construct a folder hierarchy with specific file/folder permissions required for later tests.   On the Windows side, those init scripts should be executed as an administrator user and the unit tests executed as a non-administrator user. 

Use case:  Given a directory path and a properties file name, determine whether a given user of the system may update the properties file.

Test cases:

Directory path contains folders w/o read and execute permissions
Properties file has Read Only property set (Windows)
Properties file is not writable
Properties file in not readable
Etc.

Thanks,

Brandon
 


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

From darran.lofthouse at jboss.com  Wed Apr 15 11:04:06 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Wed, 15 Apr 2015 16:04:06 +0100
Subject: [wildfly-dev] (WFCORE-640) Platform and User Specific Unit Tests
In-Reply-To: <9BC41E4B-FFDE-4C9C-B228-6F26D472CE50@punagroup.com>
References: <9BC41E4B-FFDE-4C9C-B228-6F26D472CE50@punagroup.com>
Message-ID: <552E7DE6.2040403@jboss.com>

For something like this maybe your test case could just modify some 
permissions first using Java APIs - anything OS specific can quickly 
become a problem to maintain.

Regards,
Darran Lofthouse


On 14/04/15 20:47, Brandon Gaisford wrote:
>
> Hello,
>
> I?m code complete on WFCORE-640 and have completed my development
> testing on OS X and Windows 7.  This feature deals with resolution of
> file permissions and I?m not sure how best to proceed with the creation
> of unit tests and subsequent Maven integration.  Not being very familiar
> with the build and release process I thought others may have some advice.
>
> Does the current build process get executed on both *nix and Windows
> platforms?  Platform specific unit test init scripts need to be executed
> to construct a folder hierarchy with specific file/folder permissions
> required for later tests.   On the Windows side, those init scripts
> should be executed as an administrator user and the unit tests executed
> as a non-administrator user.
>
> Use case:  Given a directory path and a properties file name, determine
> whether a given user of the system may update the properties file.
>
> Test cases:
>
>  1. Directory path contains folders w/o read and execute permissions
>  2. Properties file has Read Only property set (Windows)
>  3. Properties file is not writable
>  4. Properties file in not readable
>  5. Etc.
>
>
> Thanks,
>
> Brandon
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From sridharthiyagarajan at gmail.com  Thu Apr 16 02:23:49 2015
From: sridharthiyagarajan at gmail.com (sridhar thiyagarajan)
Date: Thu, 16 Apr 2015 11:53:49 +0530
Subject: [wildfly-dev] Default resource adapter in Wildfly
Message-ID: <CAE06nMNKy6R2PnSHqs2VZxh6FBprDD+uMiTBH0M0ptB9rgq2BQ@mail.gmail.com>

Hi,

I am migrating my application from JBoss 6 to Wildfly 8. MDB in my
application uses  "jms-ra.rar" as resource adapter and the rar archive is
present in *server/deploy *directory of JBoss 6.

Can anyone help me about the default resource adapter in Wildfly that can
be used. There is a module *org.hornetq.ra* I observed and please anyone
explain about how to use the default resource adapter in Wildfly.

Many thanks in advance.

Sridhar Thiyagarajan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150416/e4e829c4/attachment.html 

From sanne at hibernate.org  Thu Apr 16 10:34:48 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 16 Apr 2015 15:34:48 +0100
Subject: [wildfly-dev] Feature-packs,
	versions / module slots and independent release cycles
Message-ID: <CAFm4XO1aWdK4E00YD8KcZKii+iNCBic4p-LcSS-A7pjEYi7Xqw@mail.gmail.com>

Hi all,
Toma? is helping me figure out how we could publish a WildFly feature
pack when we do an Hibernate Search release.

We already did publish "modules" in a zip format, uploaded to the
Maven repository so that people could easily layer a bleeding edge
version on top of a slightly outdated WildFly version.
We have been doing this for a couple of years now.

It's important for our users to have a little bit of flexibility on
the exact versions.
While it's great for the huge population of Hibernate users to find
both Hibernate ORM and Hibernate Search "out of the box" in WildFly,
for the minority of those power users which actually help us by
contributing or testing each and every release they need to be able to
continue "layering" the latest of our releases without waiting for a
WildFly release.
Not least, that's essential for us to be able to catch bugs ourselves
and run every snapshot on integration tests on WildFly.

Ales, Toma? and myself were looking for a way to DRY on the module
definitions: as we do far more integration tests of these modules in
"upstream" Hibernate Search than what is feasible for us to maintain
within the WildFly codebase, it recently happened that the modules in
WildFly were lagging behind (structurally different) and not good
enough for CapeDwarf purposes. Not an issue for the mass of Hibernate
users, but still something we'd want to prevent from happening again.

So one solution could be move all our integration tests into WildFly,
but that will slow down your build, and still force us all to maintain
two sets of identical modules.

The other idea is for WildFly to download our feature pack during the
assembly of the distribution, and rely on our integration tests. Toma?
actually has a nice branch showcasing how this could work already.

But it looks like that if it's up to us to pre-package these modules
in advance, we should be using the "main" slot for the modules, as
they are copied "as is" into the distribution - while we always
considered the usage of the "main" slot as a prerogative of components
tightly coupled with the WildFly version.

This would imply that when someone fetches our "latest" version and
overlays it on WildFly, he would literally overwrite the bits which
were shipped with Wildfly, I don't like that idea.

Proposal:
we'll publish feature packs which make use of the slot to qualify each
distribution of our "upstream modules" with a version in format
"major.minor"; the WildFly build should then download these and
include them as-is, but also include an alias with slot "main"
pointing to the exact version which is being included in the WildFly
release.

We're already using a similar approach between Infinispan and
Hibernate Search versions - to use both qualified versions and aliases
- as they both publish modules (in different cycles) and yet depend on
each other. This approach made it feasible.

WDYT?

BTW we're paving the road with Hibernate Search, but consider it just
an example as several other projects are interested to follow up with
a similar scheme.

Thanks,
Sanne


From david.lloyd at redhat.com  Thu Apr 16 18:52:15 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Thu, 16 Apr 2015 17:52:15 -0500
Subject: [wildfly-dev] EJB Client branch changes
Message-ID: <55303D1F.6050704@redhat.com>

The JBoss EJB Client project at GitHub [1] has undergone a couple of 
administrative changes in anticipation of WildFly 10 development.

The 'master' branch, which was previously versioned at 2.1.x, is now for 
3.x development.  The 2.x development branch has been moved to the '2.x' 
branch.  Development of the 1.0.x series is still in the existing 1.0 
branch and will remain there, as will the 2.0 branch for 2.0.x development.

The 3.x code is presently reasonably stable but it does rely on a 
snapshot of JBoss Remoting 5.x at the moment.

The JIRA project [2] has been updated with a 3.0.0.Beta1 release.

[1] https://github.com/jbossas/jboss-ejb-client
[2] https://issues.jboss.org/browse/EJBCLIENT

-- 
- DML

From bgaisford at punagroup.com  Thu Apr 16 20:01:06 2015
From: bgaisford at punagroup.com (Brandon Gaisford)
Date: Thu, 16 Apr 2015 14:01:06 -1000
Subject: [wildfly-dev] WFLY-1192 - Volunteering to work on this
Message-ID: <0ADD6038-BD15-482C-BA73-A07D363081DB@punagroup.com>


If no one is actively working on WFLY-1192, I?ll give it a go.  Not sure how quickly I?ll be able to turn it around.  Sources appear to be under wildly-core.  Let me know if you?d like to me to work on this.

Thanks,

Brandon

From jason.greene at redhat.com  Thu Apr 16 21:07:10 2015
From: jason.greene at redhat.com (Jason T. Greene)
Date: Thu, 16 Apr 2015 21:07:10 -0400 (EDT)
Subject: [wildfly-dev] WFLY-1192 - Volunteering to work on this
In-Reply-To: <0ADD6038-BD15-482C-BA73-A07D363081DB@punagroup.com>
References: <0ADD6038-BD15-482C-BA73-A07D363081DB@punagroup.com>
Message-ID: <1CD5379F-E687-43C7-82FA-F0394BD8236D@redhat.com>



> On Apr 16, 2015, at 7:06 PM, Brandon Gaisford <bgaisford at punagroup.com> wrote:
> 
> 
> If no one is actively working on WFLY-1192, I?ll give it a go.  Not sure how quickly I?ll be able to turn it around.  Sources appear to be under wildly-core.  Let me know if you?d like to me to work on this.

Sure, thanks for stepping up. One thing that's important though, is to avoid breaking compatibility. The cascade behavior should somehow be specified. Do you agree?


From bgaisford at punagroup.com  Thu Apr 16 21:11:51 2015
From: bgaisford at punagroup.com (Brandon Gaisford)
Date: Thu, 16 Apr 2015 15:11:51 -1000
Subject: [wildfly-dev] WFLY-1192 - Volunteering to work on this
In-Reply-To: <1CD5379F-E687-43C7-82FA-F0394BD8236D@redhat.com>
References: <0ADD6038-BD15-482C-BA73-A07D363081DB@punagroup.com>
	<1CD5379F-E687-43C7-82FA-F0394BD8236D@redhat.com>
Message-ID: <94B53A0C-B0FD-40AD-91E5-BCC067B07764@punagroup.com>


Hi Jason,

Yes, I totally agree.  It?s going to take some effort on my part to understand this code.  I think for this particular feature it would be best if I do some prototyping and then propose a formal design document to the team before proceeding.

Brandon


On Apr 16, 2015, at 3:07 PM, Jason T. Greene <jason.greene at redhat.com> wrote:

> 
> 
>> On Apr 16, 2015, at 7:06 PM, Brandon Gaisford <bgaisford at punagroup.com> wrote:
>> 
>> 
>> If no one is actively working on WFLY-1192, I?ll give it a go.  Not sure how quickly I?ll be able to turn it around.  Sources appear to be under wildly-core.  Let me know if you?d like to me to work on this.
> 
> Sure, thanks for stepping up. One thing that's important though, is to avoid breaking compatibility. The cascade behavior should somehow be specified. Do you agree?



From jmesnil at redhat.com  Fri Apr 17 08:39:16 2015
From: jmesnil at redhat.com (Jeff Mesnil)
Date: Fri, 17 Apr 2015 14:39:16 +0200
Subject: [wildfly-dev] Default resource adapter in Wildfly
In-Reply-To: <CAE06nMNKy6R2PnSHqs2VZxh6FBprDD+uMiTBH0M0ptB9rgq2BQ@mail.gmail.com>
References: <CAE06nMNKy6R2PnSHqs2VZxh6FBprDD+uMiTBH0M0ptB9rgq2BQ@mail.gmail.com>
Message-ID: <11554890-BFED-4340-B1BB-9C9DC5138685@redhat.com>

Please use the community forum for such user question.

> On 16 Apr 2015, at 08:23, sridhar thiyagarajan <sridharthiyagarajan at gmail.com> wrote:
> I am migrating my application from JBoss 6 to Wildfly 8. MDB in my application uses  "jms-ra.rar" as resource adapter and the rar archive is present in server/deploy directory of JBoss 6.  
> 
> Can anyone help me about the default resource adapter in Wildfly that can be used. There is a module org.hornetq.ra I observed and please anyone explain about how to use the default resource adapter in Wildfly.

The default JMS resource adapter for WildFly 8 (and above) is a pooled-connection-factory configured in the messaging subsystem named ?hornetq-ra?.

You can find more information in the messaging guide: https://docs.jboss.org/author/display/WFLY8/Messaging+configuration#Messagingconfiguration-JMSConnectionFactories




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



From darran.lofthouse at jboss.com  Fri Apr 17 09:03:12 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Fri, 17 Apr 2015 14:03:12 +0100
Subject: [wildfly-dev] Java 8 API Warning
Message-ID: <55310490.7050001@jboss.com>

Quick warning for anyone developing using Java 8 but on projects still 
dependent on Java 7.

Normally this is fine, as an engineer you make sure you don't use any 
new language features or call new APIs and generally it all works.

With Java 8 there is one addition gotcha, Java 8 adds support for 
default method implementations on interfaces, to add to this some 
pre-existing methods have now been replaced with default 
implementations.  The side effect being it is easy to miss that you have 
a method missing from a class and it will not be picked up till it is 
compiled on Java 7.

e.g. On java.util.Iterator the remove method is now default so classes 
that implement this interface no longer need to implement that method 
unless they really are providing an implementation of that method.

Regards,
Darran Lofthouse.


From steve at hibernate.org  Fri Apr 17 09:11:14 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 17 Apr 2015 08:11:14 -0500
Subject: [wildfly-dev] Java 8 API Warning
In-Reply-To: <55310490.7050001@jboss.com>
References: <55310490.7050001@jboss.com>
Message-ID: <CAFdSV9vHRj-Je6K_GofJVwqONzrz_m=Ntu2tSOw6s+qr3H1Dog@mail.gmail.com>

I ran into issues with using Java 8 to run my build but targeting Java 7
for most artifacts.  I would highly suggest applying a solution based on
AnimalSniffer or supplying the Java 6/7 tools.jar for bootclasspath to
javac.  Helps catch these types of issues
On Apr 17, 2015 8:04 AM, "Darran Lofthouse" <darran.lofthouse at jboss.com>
wrote:

> Quick warning for anyone developing using Java 8 but on projects still
> dependent on Java 7.
>
> Normally this is fine, as an engineer you make sure you don't use any
> new language features or call new APIs and generally it all works.
>
> With Java 8 there is one addition gotcha, Java 8 adds support for
> default method implementations on interfaces, to add to this some
> pre-existing methods have now been replaced with default
> implementations.  The side effect being it is easy to miss that you have
> a method missing from a class and it will not be picked up till it is
> compiled on Java 7.
>
> e.g. On java.util.Iterator the remove method is now default so classes
> that implement this interface no longer need to implement that method
> unless they really are providing an implementation of that method.
>
> Regards,
> Darran Lofthouse.
>
> _______________________________________________
> 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/20150417/0c61361f/attachment.html 

From david.lloyd at redhat.com  Fri Apr 17 09:12:49 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Fri, 17 Apr 2015 08:12:49 -0500
Subject: [wildfly-dev] Java 8 API Warning
In-Reply-To: <CAFdSV9vHRj-Je6K_GofJVwqONzrz_m=Ntu2tSOw6s+qr3H1Dog@mail.gmail.com>
References: <55310490.7050001@jboss.com>
	<CAFdSV9vHRj-Je6K_GofJVwqONzrz_m=Ntu2tSOw6s+qr3H1Dog@mail.gmail.com>
Message-ID: <553106D1.7040907@redhat.com>

The good news is, there's talk that with Java 9, the JDK will include 
(in some form) APIs for previous versions, so that if you want to target 
an earlier version, you can link against its runtime as well.

On 04/17/2015 08:11 AM, Steve Ebersole wrote:
> I ran into issues with using Java 8 to run my build but targeting Java 7
> for most artifacts.  I would highly suggest applying a solution based on
> AnimalSniffer or supplying the Java 6/7 tools.jar for bootclasspath to
> javac.  Helps catch these types of issues
>
> On Apr 17, 2015 8:04 AM, "Darran Lofthouse" <darran.lofthouse at jboss.com
> <mailto:darran.lofthouse at jboss.com>> wrote:
>
>     Quick warning for anyone developing using Java 8 but on projects still
>     dependent on Java 7.
>
>     Normally this is fine, as an engineer you make sure you don't use any
>     new language features or call new APIs and generally it all works.
>
>     With Java 8 there is one addition gotcha, Java 8 adds support for
>     default method implementations on interfaces, to add to this some
>     pre-existing methods have now been replaced with default
>     implementations.  The side effect being it is easy to miss that you have
>     a method missing from a class and it will not be picked up till it is
>     compiled on Java 7.
>
>     e.g. On java.util.Iterator the remove method is now default so classes
>     that implement this interface no longer need to implement that method
>     unless they really are providing an implementation of that method.
>
>     Regards,
>     Darran Lofthouse.
>
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

-- 
- DML

From darran.lofthouse at jboss.com  Fri Apr 17 09:24:30 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Fri, 17 Apr 2015 14:24:30 +0100
Subject: [wildfly-dev] Should management interfaces be in a subsystem?
Message-ID: <5531098E.9060701@jboss.com>

The reason this is coming up now is I am working on adding references to 
Elytron services from the interfaces, also I know there is plenty of 
demand for additional configuration options on these.

So the question is should the management interface definitions be a part 
of a subsystem of their own or should they remain a top level?

My vote would be make them a part of a subsystem, my main justifications 
being: -
  - They are going to be dependent on capabilities supplied by other 
subsystems.
  - We already have non-optimal code in there to access subsystem 
supplied services so can clean this up.
  - In standalone mode they should not be strictly necessary, it should 
be possible to remove all remote administration for standalone.

Even in the case of a slave host controller, if that host controller 
pulls it's Elytron definition from the master it could also pull it's 
management interface definitions from master.

Regards,
Darran Lofthouse.


From jose.e.chavez at gmail.com  Fri Apr 17 09:42:14 2015
From: jose.e.chavez at gmail.com (Jose Chavez)
Date: Fri, 17 Apr 2015 08:42:14 -0500
Subject: [wildfly-dev] Java 8 API Warning
In-Reply-To: <55310490.7050001@jboss.com>
References: <55310490.7050001@jboss.com>
Message-ID: <CADn8Fo2dP7yFc3n7A4AJA-3hf0OL58_cpLarfL2x4EMZbzvqmw@mail.gmail.com>

Sounds like a C# virtual method :)


   [image: --]

Jose E. Chavez
[image: http://]about.me/jose.e.chavez
   <http://about.me/jose.e.chavez?promo=email_sig>


On Fri, Apr 17, 2015 at 8:03 AM, Darran Lofthouse <
darran.lofthouse at jboss.com> wrote:

> Quick warning for anyone developing using Java 8 but on projects still
> dependent on Java 7.
>
> Normally this is fine, as an engineer you make sure you don't use any
> new language features or call new APIs and generally it all works.
>
> With Java 8 there is one addition gotcha, Java 8 adds support for
> default method implementations on interfaces, to add to this some
> pre-existing methods have now been replaced with default
> implementations.  The side effect being it is easy to miss that you have
> a method missing from a class and it will not be picked up till it is
> compiled on Java 7.
>
> e.g. On java.util.Iterator the remove method is now default so classes
> that implement this interface no longer need to implement that method
> unless they really are providing an implementation of that method.
>
> Regards,
> Darran Lofthouse.
>
> _______________________________________________
> 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/20150417/3c57a567/attachment.html 

From brian.stansberry at redhat.com  Fri Apr 17 10:26:58 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Fri, 17 Apr 2015 09:26:58 -0500
Subject: [wildfly-dev] Should management interfaces be in a subsystem?
In-Reply-To: <5531098E.9060701@jboss.com>
References: <5531098E.9060701@jboss.com>
Message-ID: <55311832.2070902@redhat.com>

Long term answer:

Yes, I think they should be in a subsystem.

Short term answer:

That will be a lot of work, particularly in regards to providing the 
necessary compatibility and, possibly, migration support. So I think we 
need to get further along on our list of must have stuff before we 
attack this problem in a lot of depth. If we can get to it, great.

I believe the capabilities and requirements stuff should clean up a lot 
of the issues around kernel stuff needing things provided by by 
subsystems. The distinction should disappear, and it all becomes just 
things providing capabilities and other things consuming them. So a 
logical path to follow here is once that part is done, we can figure out 
how to deal with the compatibility and migration aspects, and if we have 
a good solution move on to the relatively easy part of new parsers, 
ResourceDefinitions etc.

On 4/17/15 8:24 AM, Darran Lofthouse wrote:
> The reason this is coming up now is I am working on adding references to
> Elytron services from the interfaces, also I know there is plenty of
> demand for additional configuration options on these.
>
> So the question is should the management interface definitions be a part
> of a subsystem of their own or should they remain a top level?
>
> My vote would be make them a part of a subsystem, my main justifications
> being: -
>    - They are going to be dependent on capabilities supplied by other
> subsystems.
>    - We already have non-optimal code in there to access subsystem
> supplied services so can clean this up.
>    - In standalone mode they should not be strictly necessary, it should
> be possible to remove all remote administration for standalone.
>
> Even in the case of a slave host controller, if that host controller
> pulls it's Elytron definition from the master it could also pull it's
> management interface definitions from master.
>
> Regards,
> Darran Lofthouse.
>
> _______________________________________________
> 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 darran.lofthouse at jboss.com  Fri Apr 17 10:31:19 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Fri, 17 Apr 2015 15:31:19 +0100
Subject: [wildfly-dev] Should management interfaces be in a subsystem?
In-Reply-To: <55311832.2070902@redhat.com>
References: <5531098E.9060701@jboss.com> <55311832.2070902@redhat.com>
Message-ID: <55311937.4020606@jboss.com>

Thanks Brian,

So this does sound like I should go ahead and bump the schema and 
management versions so I can continue with my tasks and I will send in a 
PR as soon as we move to 2.0.x development.

Enhancements to the interface definitions can continue along that path 
until we feel ready to move them.

Regards,
Darran Lofthouse.


On 17/04/15 15:26, Brian Stansberry wrote:
> Long term answer:
>
> Yes, I think they should be in a subsystem.
>
> Short term answer:
>
> That will be a lot of work, particularly in regards to providing the
> necessary compatibility and, possibly, migration support. So I think we
> need to get further along on our list of must have stuff before we
> attack this problem in a lot of depth. If we can get to it, great.
>
> I believe the capabilities and requirements stuff should clean up a lot
> of the issues around kernel stuff needing things provided by by
> subsystems. The distinction should disappear, and it all becomes just
> things providing capabilities and other things consuming them. So a
> logical path to follow here is once that part is done, we can figure out
> how to deal with the compatibility and migration aspects, and if we have
> a good solution move on to the relatively easy part of new parsers,
> ResourceDefinitions etc.
>
> On 4/17/15 8:24 AM, Darran Lofthouse wrote:
>> The reason this is coming up now is I am working on adding references to
>> Elytron services from the interfaces, also I know there is plenty of
>> demand for additional configuration options on these.
>>
>> So the question is should the management interface definitions be a part
>> of a subsystem of their own or should they remain a top level?
>>
>> My vote would be make them a part of a subsystem, my main justifications
>> being: -
>>     - They are going to be dependent on capabilities supplied by other
>> subsystems.
>>     - We already have non-optimal code in there to access subsystem
>> supplied services so can clean this up.
>>     - In standalone mode they should not be strictly necessary, it should
>> be possible to remove all remote administration for standalone.
>>
>> Even in the case of a slave host controller, if that host controller
>> pulls it's Elytron definition from the master it could also pull it's
>> management interface definitions from master.
>>
>> Regards,
>> Darran Lofthouse.
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>

From steve at hibernate.org  Fri Apr 17 10:34:00 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 17 Apr 2015 09:34:00 -0500
Subject: [wildfly-dev] Java 8 API Warning
In-Reply-To: <553106D1.7040907@redhat.com>
References: <55310490.7050001@jboss.com>
	<CAFdSV9vHRj-Je6K_GofJVwqONzrz_m=Ntu2tSOw6s+qr3H1Dog@mail.gmail.com>
	<553106D1.7040907@redhat.com>
Message-ID: <CAFdSV9tHk9Vht3CyztU+1WcinMB4U0b4+=+7Sep4T4Pf+Wvt8w@mail.gmail.com>

That would be great rather than needing another path.
On Apr 17, 2015 8:13 AM, "David M. Lloyd" <david.lloyd at redhat.com> wrote:

> The good news is, there's talk that with Java 9, the JDK will include
> (in some form) APIs for previous versions, so that if you want to target
> an earlier version, you can link against its runtime as well.
>
> On 04/17/2015 08:11 AM, Steve Ebersole wrote:
> > I ran into issues with using Java 8 to run my build but targeting Java 7
> > for most artifacts.  I would highly suggest applying a solution based on
> > AnimalSniffer or supplying the Java 6/7 tools.jar for bootclasspath to
> > javac.  Helps catch these types of issues
> >
> > On Apr 17, 2015 8:04 AM, "Darran Lofthouse" <darran.lofthouse at jboss.com
> > <mailto:darran.lofthouse at jboss.com>> wrote:
> >
> >     Quick warning for anyone developing using Java 8 but on projects
> still
> >     dependent on Java 7.
> >
> >     Normally this is fine, as an engineer you make sure you don't use any
> >     new language features or call new APIs and generally it all works.
> >
> >     With Java 8 there is one addition gotcha, Java 8 adds support for
> >     default method implementations on interfaces, to add to this some
> >     pre-existing methods have now been replaced with default
> >     implementations.  The side effect being it is easy to miss that you
> have
> >     a method missing from a class and it will not be picked up till it is
> >     compiled on Java 7.
> >
> >     e.g. On java.util.Iterator the remove method is now default so
> classes
> >     that implement this interface no longer need to implement that method
> >     unless they really are providing an implementation of that method.
> >
> >     Regards,
> >     Darran Lofthouse.
> >
> >     _______________________________________________
> >     wildfly-dev mailing list
> >     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
> >     https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> >
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
>
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150417/e576fc1e/attachment.html 

From brian.stansberry at redhat.com  Fri Apr 17 10:38:42 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Fri, 17 Apr 2015 09:38:42 -0500
Subject: [wildfly-dev] Should management interfaces be in a subsystem?
In-Reply-To: <55311937.4020606@jboss.com>
References: <5531098E.9060701@jboss.com> <55311832.2070902@redhat.com>
	<55311937.4020606@jboss.com>
Message-ID: <55311AF2.7070701@redhat.com>

A kernel schema bump to 2.0 is fine, thanks. For sure we will be making 
some changes so the chances of it being wasted effort are nil.

On 4/17/15 9:31 AM, Darran Lofthouse wrote:
> Thanks Brian,
>
> So this does sound like I should go ahead and bump the schema and
> management versions so I can continue with my tasks and I will send in a
> PR as soon as we move to 2.0.x development.
>
> Enhancements to the interface definitions can continue along that path
> until we feel ready to move them.
>
> Regards,
> Darran Lofthouse.
>
>
> On 17/04/15 15:26, Brian Stansberry wrote:
>> Long term answer:
>>
>> Yes, I think they should be in a subsystem.
>>
>> Short term answer:
>>
>> That will be a lot of work, particularly in regards to providing the
>> necessary compatibility and, possibly, migration support. So I think we
>> need to get further along on our list of must have stuff before we
>> attack this problem in a lot of depth. If we can get to it, great.
>>
>> I believe the capabilities and requirements stuff should clean up a lot
>> of the issues around kernel stuff needing things provided by by
>> subsystems. The distinction should disappear, and it all becomes just
>> things providing capabilities and other things consuming them. So a
>> logical path to follow here is once that part is done, we can figure out
>> how to deal with the compatibility and migration aspects, and if we have
>> a good solution move on to the relatively easy part of new parsers,
>> ResourceDefinitions etc.
>>
>> On 4/17/15 8:24 AM, Darran Lofthouse wrote:
>>> The reason this is coming up now is I am working on adding references to
>>> Elytron services from the interfaces, also I know there is plenty of
>>> demand for additional configuration options on these.
>>>
>>> So the question is should the management interface definitions be a part
>>> of a subsystem of their own or should they remain a top level?
>>>
>>> My vote would be make them a part of a subsystem, my main justifications
>>> being: -
>>>      - They are going to be dependent on capabilities supplied by other
>>> subsystems.
>>>      - We already have non-optimal code in there to access subsystem
>>> supplied services so can clean this up.
>>>      - In standalone mode they should not be strictly necessary, it should
>>> be possible to remove all remote administration for standalone.
>>>
>>> Even in the case of a slave host controller, if that host controller
>>> pulls it's Elytron definition from the master it could also pull it's
>>> management interface definitions from master.
>>>
>>> Regards,
>>> Darran Lofthouse.
>>>
>>> _______________________________________________
>>> 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  Fri Apr 17 10:43:31 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Fri, 17 Apr 2015 09:43:31 -0500
Subject: [wildfly-dev] WFLY-1192 - Volunteering to work on this
In-Reply-To: <94B53A0C-B0FD-40AD-91E5-BCC067B07764@punagroup.com>
References: <0ADD6038-BD15-482C-BA73-A07D363081DB@punagroup.com>	<1CD5379F-E687-43C7-82FA-F0394BD8236D@redhat.com>
	<94B53A0C-B0FD-40AD-91E5-BCC067B07764@punagroup.com>
Message-ID: <55311C13.8000801@redhat.com>

Sounds, great. Thanks, Brandon. I agree this sounds like something in 
WildFly Core, so I'm going to move this JIRA to the WFCORE project.

On 4/16/15 8:11 PM, Brandon Gaisford wrote:
>
> Hi Jason,
>
> Yes, I totally agree.  It?s going to take some effort on my part to understand this code.  I think for this particular feature it would be best if I do some prototyping and then propose a formal design document to the team before proceeding.
>
> Brandon
>
>
> On Apr 16, 2015, at 3:07 PM, Jason T. Greene <jason.greene at redhat.com> wrote:
>
>>
>>
>>> On Apr 16, 2015, at 7:06 PM, Brandon Gaisford <bgaisford at punagroup.com> wrote:
>>>
>>>
>>> If no one is actively working on WFLY-1192, I?ll give it a go.  Not sure how quickly I?ll be able to turn it around.  Sources appear to be under wildly-core.  Let me know if you?d like to me to work on this.
>>
>> Sure, thanks for stepping up. One thing that's important though, is to avoid breaking compatibility. The cascade behavior should somehow be specified. Do you agree?
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


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

From brian.stansberry at redhat.com  Fri Apr 17 10:53:54 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Fri, 17 Apr 2015 09:53:54 -0500
Subject: [wildfly-dev] WFLY-1192 - Volunteering to work on this
In-Reply-To: <55311C13.8000801@redhat.com>
References: <0ADD6038-BD15-482C-BA73-A07D363081DB@punagroup.com>	<1CD5379F-E687-43C7-82FA-F0394BD8236D@redhat.com>	<94B53A0C-B0FD-40AD-91E5-BCC067B07764@punagroup.com>
	<55311C13.8000801@redhat.com>
Message-ID: <55311E82.7080907@redhat.com>

It's now https://issues.jboss.org/browse/WFCORE-648. The old link will 
redirect. I assigned it to you, Brandon.

On 4/17/15 9:43 AM, Brian Stansberry wrote:
> Sounds, great. Thanks, Brandon. I agree this sounds like something in
> WildFly Core, so I'm going to move this JIRA to the WFCORE project.
>
> On 4/16/15 8:11 PM, Brandon Gaisford wrote:
>>
>> Hi Jason,
>>
>> Yes, I totally agree.  It?s going to take some effort on my part to understand this code.  I think for this particular feature it would be best if I do some prototyping and then propose a formal design document to the team before proceeding.
>>
>> Brandon
>>
>>
>> On Apr 16, 2015, at 3:07 PM, Jason T. Greene <jason.greene at redhat.com> wrote:
>>
>>>
>>>
>>>> On Apr 16, 2015, at 7:06 PM, Brandon Gaisford <bgaisford at punagroup.com> wrote:
>>>>
>>>>
>>>> If no one is actively working on WFLY-1192, I?ll give it a go.  Not sure how quickly I?ll be able to turn it around.  Sources appear to be under wildly-core.  Let me know if you?d like to me to work on this.
>>>
>>> Sure, thanks for stepping up. One thing that's important though, is to avoid breaking compatibility. The cascade behavior should somehow be specified. Do you agree?
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>


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

From jason.greene at redhat.com  Sat Apr 18 10:12:29 2015
From: jason.greene at redhat.com (Jason T. Greene)
Date: Sat, 18 Apr 2015 10:12:29 -0400 (EDT)
Subject: [wildfly-dev] Should management interfaces be in a subsystem?
In-Reply-To: <55311AF2.7070701@redhat.com>
References: <5531098E.9060701@jboss.com> <55311832.2070902@redhat.com>
	<55311937.4020606@jboss.com> <55311AF2.7070701@redhat.com>
Message-ID: <35206EAA-6107-44B0-96FD-4169DCEA416B@redhat.com>

So, to me, the major benefits of something being a subsystem is that it is either optional or replaceable. Does elytron, at least the core of it, fit this? If not perhaps it should be part of the core model?

> On Apr 17, 2015, at 9:39 AM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> 
> A kernel schema bump to 2.0 is fine, thanks. For sure we will be making 
> some changes so the chances of it being wasted effort are nil.
> 
>> On 4/17/15 9:31 AM, Darran Lofthouse wrote:
>> Thanks Brian,
>> 
>> So this does sound like I should go ahead and bump the schema and
>> management versions so I can continue with my tasks and I will send in a
>> PR as soon as we move to 2.0.x development.
>> 
>> Enhancements to the interface definitions can continue along that path
>> until we feel ready to move them.
>> 
>> Regards,
>> Darran Lofthouse.
>> 
>> 
>>> On 17/04/15 15:26, Brian Stansberry wrote:
>>> Long term answer:
>>> 
>>> Yes, I think they should be in a subsystem.
>>> 
>>> Short term answer:
>>> 
>>> That will be a lot of work, particularly in regards to providing the
>>> necessary compatibility and, possibly, migration support. So I think we
>>> need to get further along on our list of must have stuff before we
>>> attack this problem in a lot of depth. If we can get to it, great.
>>> 
>>> I believe the capabilities and requirements stuff should clean up a lot
>>> of the issues around kernel stuff needing things provided by by
>>> subsystems. The distinction should disappear, and it all becomes just
>>> things providing capabilities and other things consuming them. So a
>>> logical path to follow here is once that part is done, we can figure out
>>> how to deal with the compatibility and migration aspects, and if we have
>>> a good solution move on to the relatively easy part of new parsers,
>>> ResourceDefinitions etc.
>>> 
>>>> On 4/17/15 8:24 AM, Darran Lofthouse wrote:
>>>> The reason this is coming up now is I am working on adding references to
>>>> Elytron services from the interfaces, also I know there is plenty of
>>>> demand for additional configuration options on these.
>>>> 
>>>> So the question is should the management interface definitions be a part
>>>> of a subsystem of their own or should they remain a top level?
>>>> 
>>>> My vote would be make them a part of a subsystem, my main justifications
>>>> being: -
>>>>     - They are going to be dependent on capabilities supplied by other
>>>> subsystems.
>>>>     - We already have non-optimal code in there to access subsystem
>>>> supplied services so can clean this up.
>>>>     - In standalone mode they should not be strictly necessary, it should
>>>> be possible to remove all remote administration for standalone.
>>>> 
>>>> Even in the case of a slave host controller, if that host controller
>>>> pulls it's Elytron definition from the master it could also pull it's
>>>> management interface definitions from master.
>>>> 
>>>> Regards,
>>>> Darran Lofthouse.
>>>> 
>>>> _______________________________________________
>>>> 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
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From darran.lofthouse at jboss.com  Mon Apr 20 05:38:17 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Mon, 20 Apr 2015 10:38:17 +0100
Subject: [wildfly-dev] Should management interfaces be in a subsystem?
In-Reply-To: <35206EAA-6107-44B0-96FD-4169DCEA416B@redhat.com>
References: <5531098E.9060701@jboss.com>
	<55311832.2070902@redhat.com>	<55311937.4020606@jboss.com>
	<55311AF2.7070701@redhat.com>
	<35206EAA-6107-44B0-96FD-4169DCEA416B@redhat.com>
Message-ID: <5534C909.6060308@jboss.com>

The Elytron Subsystem fits that 100%, the Elytron Subsystem is providing 
a set of services that return either standard Java types or types 
defined within the Elytron project.

If another subsystem chooses to provide a set of services with the same 
set of capabilities then the whole Elytron subsystem could be removed. 
Of course the core of the server is still going to depend on Elytron 
APIs but the subsystem providing those services is interchangeable.

As an example within KeyCloak they are currently looking at adding realm 
support to their subsystem, should they also provide the remaining 
services they could technically create a distribution based on WildFly 
100% backed by KeyCloak and drop the Elytron subsystem.  At the same 
time we end up with no hard dependencies on any other providers of these 
services.

Regards,
Darran Lofthouse.


On 18/04/15 15:12, Jason T. Greene wrote:
> So, to me, the major benefits of something being a subsystem is that it is either optional or replaceable. Does elytron, at least the core of it, fit this? If not perhaps it should be part of the core model?
>
>> On Apr 17, 2015, at 9:39 AM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>
>> A kernel schema bump to 2.0 is fine, thanks. For sure we will be making
>> some changes so the chances of it being wasted effort are nil.
>>
>>> On 4/17/15 9:31 AM, Darran Lofthouse wrote:
>>> Thanks Brian,
>>>
>>> So this does sound like I should go ahead and bump the schema and
>>> management versions so I can continue with my tasks and I will send in a
>>> PR as soon as we move to 2.0.x development.
>>>
>>> Enhancements to the interface definitions can continue along that path
>>> until we feel ready to move them.
>>>
>>> Regards,
>>> Darran Lofthouse.
>>>
>>>
>>>> On 17/04/15 15:26, Brian Stansberry wrote:
>>>> Long term answer:
>>>>
>>>> Yes, I think they should be in a subsystem.
>>>>
>>>> Short term answer:
>>>>
>>>> That will be a lot of work, particularly in regards to providing the
>>>> necessary compatibility and, possibly, migration support. So I think we
>>>> need to get further along on our list of must have stuff before we
>>>> attack this problem in a lot of depth. If we can get to it, great.
>>>>
>>>> I believe the capabilities and requirements stuff should clean up a lot
>>>> of the issues around kernel stuff needing things provided by by
>>>> subsystems. The distinction should disappear, and it all becomes just
>>>> things providing capabilities and other things consuming them. So a
>>>> logical path to follow here is once that part is done, we can figure out
>>>> how to deal with the compatibility and migration aspects, and if we have
>>>> a good solution move on to the relatively easy part of new parsers,
>>>> ResourceDefinitions etc.
>>>>
>>>>> On 4/17/15 8:24 AM, Darran Lofthouse wrote:
>>>>> The reason this is coming up now is I am working on adding references to
>>>>> Elytron services from the interfaces, also I know there is plenty of
>>>>> demand for additional configuration options on these.
>>>>>
>>>>> So the question is should the management interface definitions be a part
>>>>> of a subsystem of their own or should they remain a top level?
>>>>>
>>>>> My vote would be make them a part of a subsystem, my main justifications
>>>>> being: -
>>>>>      - They are going to be dependent on capabilities supplied by other
>>>>> subsystems.
>>>>>      - We already have non-optimal code in there to access subsystem
>>>>> supplied services so can clean this up.
>>>>>      - In standalone mode they should not be strictly necessary, it should
>>>>> be possible to remove all remote administration for standalone.
>>>>>
>>>>> Even in the case of a slave host controller, if that host controller
>>>>> pulls it's Elytron definition from the master it could also pull it's
>>>>> management interface definitions from master.
>>>>>
>>>>> Regards,
>>>>> Darran Lofthouse.
>>>>>
>>>>> _______________________________________________
>>>>> 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
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From sanne at hibernate.org  Mon Apr 20 14:15:01 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 20 Apr 2015 19:15:01 +0100
Subject: [wildfly-dev] Call For Final Component Upgrades
In-Reply-To: <8EC07451-D2AE-4BC2-B9F8-3E670DBE674C@gmail.com>
References: <5FB2A2C9-E3B0-430F-888F-0FA218E749ED@redhat.com>
	<8EC07451-D2AE-4BC2-B9F8-3E670DBE674C@gmail.com>
Message-ID: <CAFm4XO0k=Tj-7qpJA_n1xitnQpTxxXQtoJ1V21H3u07-cs9i+g@mail.gmail.com>

Hi Ales,

that modules refactoring is tracked by WFLY-4232.

Note that it was marked "just" as an improvement (to minimize
dependencies) as there never was an intention to expose the Infinispan
Query features to users. I'll raise the priority (and fix it) since it
seems CapeDwarf needs it but discussing with Toma? we've found a
better solution for post-WF9; see also the thread "Feature-packs,
versions / module slots and independent release cycles", that
describes how we should solve it in future.

Sanne

On 13 April 2015 at 12:21, Ales Justin <ales.justin at gmail.com> wrote:
> Hibernate Search / Infinispan Query modules (and its dependencies) need a complete overhaul -- as they are a complete mess / useless atm.
>
> So I'm just wondering who's gonna take this over?
> Sanne / Gustavo?
>
> -Ales
>
>> On 11 Apr 2015, at 01:23, Jason Greene <jason.greene at redhat.com> wrote:
>>
>> If you haven?t already, please send in a PR updating your component to Final status, as we hope to release 9 Final this month.
>>
>> Thanks!
>> --
>> Jason T. Greene
>> WildFly Lead / JBoss EAP Platform Architect
>> JBoss, a division of Red Hat
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


From tomaz.cerar at gmail.com  Mon Apr 20 17:29:56 2015
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Mon, 20 Apr 2015 23:29:56 +0200
Subject: [wildfly-dev] Proposal for improving handling complex types in
	CLI
In-Reply-To: <CAMquZP4XrhuyKEchE5YW11hFvKeqVvVT4HKHjjfVh7LSN5Gr7Q@mail.gmail.com>
References: <CAMquZP4ZY5xkC7yn4-wq0czi0+hAek4N8bz0JRKOx0uN=XmUHA@mail.gmail.com>
	<5FDCDF0E-3871-41DB-B8F4-F70830508C6A@redhat.com>
	<CAMquZP7-oCP5MHasZmNEBj430Qwn--aRJ8wsOgXd8DQTZQZUbQ@mail.gmail.com>
	<53F22B14.8090205@redhat.com>
	<CAMquZP4XrhuyKEchE5YW11hFvKeqVvVT4HKHjjfVh7LSN5Gr7Q@mail.gmail.com>
Message-ID: <CAMquZP6+wSHiVmv_Yd9DHTTc1mRzKdKsYW4+6vq+dcEcJqrBag@mail.gmail.com>

Hey guys,

just heads up that what was discussed in this thread was just merged to
wildfly-core
as part of https://github.com/wildfly/wildfly-core/pull/621

original "spec" is here https://gist.github.com/ctomc/91055a6f4e7502dcd130

There was also one additional improvement, that allows to use enhanced
syntax also
on collection operation :map-* and :list-*

--
tomaz


On Mon, Aug 18, 2014 at 10:04 PM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:

>
> On Mon, Aug 18, 2014 at 6:34 PM, Brian Stansberry <
> brian.stansberry at redhat.com> wrote:
>
>> 3) DMR has a really simple interface -- 4 public classes, ModelNode,
>> ModelType, Property, ValueExpression. To be useful, ModelType.MAP will
>> require some sort of new concept, to express the type of the map value,
>> and perhaps the map key. So a 25% or more increase in the number of
>> types in the public API. Not a big deal by itself but it's a sign that
>> this isn't some minor change.
>>
>
>
> Maybe I wasn't clear enough what I meant here.
> I only implied that we would add ModelType.MAP to jboss-dmr.
>
> All other changes would be part of WildFly management,
> with introducing new model key "key-type" and alike.
>
> But I can see what you meant and I am leaning more and more on
> *not* adding ModelType.MAP.
>
> All we need can be handled as part of wildfly mgmt apis to hide as much
> of "map internal impl" and as long people would use that api it wouldn't
> matter what impl is.
> Once we move to annotation driven model most of this will be hidden anyway.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150420/3acc69fb/attachment.html 

From ales.justin at gmail.com  Tue Apr 21 04:21:26 2015
From: ales.justin at gmail.com (Ales Justin)
Date: Tue, 21 Apr 2015 10:21:26 +0200
Subject: [wildfly-dev] Call For Final Component Upgrades
In-Reply-To: <CAFm4XO0k=Tj-7qpJA_n1xitnQpTxxXQtoJ1V21H3u07-cs9i+g@mail.gmail.com>
References: <5FB2A2C9-E3B0-430F-888F-0FA218E749ED@redhat.com>
	<8EC07451-D2AE-4BC2-B9F8-3E670DBE674C@gmail.com>
	<CAFm4XO0k=Tj-7qpJA_n1xitnQpTxxXQtoJ1V21H3u07-cs9i+g@mail.gmail.com>
Message-ID: <DBFD1DEF-770A-42F8-BF1A-5703691AAF77@gmail.com>

With latest Ispn 7.2.0.CR1 and HS 5.2.0.Beta1 I get a ton of exceptions when upgraded in WF9.0.0.Beta2.
(not that it?s unexpected, just pointing it out for Paul to fix it :-)

* https://gist.github.com/alesj/9260503671f88d010d6a <https://gist.github.com/alesj/9260503671f88d010d6a>

-Ales

> On 20 Apr 2015, at 20:15, Sanne Grinovero <sanne at hibernate.org> wrote:
> 
> Hi Ales,
> 
> that modules refactoring is tracked by WFLY-4232.
> 
> Note that it was marked "just" as an improvement (to minimize
> dependencies) as there never was an intention to expose the Infinispan
> Query features to users. I'll raise the priority (and fix it) since it
> seems CapeDwarf needs it but discussing with Toma? we've found a
> better solution for post-WF9; see also the thread "Feature-packs,
> versions / module slots and independent release cycles", that
> describes how we should solve it in future.
> 
> Sanne
> 
> On 13 April 2015 at 12:21, Ales Justin <ales.justin at gmail.com> wrote:
>> Hibernate Search / Infinispan Query modules (and its dependencies) need a complete overhaul -- as they are a complete mess / useless atm.
>> 
>> So I'm just wondering who's gonna take this over?
>> Sanne / Gustavo?
>> 
>> -Ales
>> 
>>> On 11 Apr 2015, at 01:23, Jason Greene <jason.greene at redhat.com> wrote:
>>> 
>>> If you haven?t already, please send in a PR updating your component to Final status, as we hope to release 9 Final this month.
>>> 
>>> Thanks!
>>> --
>>> 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/20150421/8fe11528/attachment.html 

From cdewolf at redhat.com  Wed Apr 22 04:25:48 2015
From: cdewolf at redhat.com (Carlo de Wolf)
Date: Wed, 22 Apr 2015 10:25:48 +0200
Subject: [wildfly-dev] Purpose of
	https://github.com/jboss/jboss-javax-sql-api_spec
Message-ID: <55375B0C.5080604@redhat.com>

What is the purpose of this component?
All those classes are JDK.

Carlo

From stuart.w.douglas at gmail.com  Wed Apr 22 06:57:43 2015
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Wed, 22 Apr 2015 10:57:43 +0000
Subject: [wildfly-dev] Purpose of
	https://github.com/jboss/jboss-javax-sql-api_spec
In-Reply-To: <55375B0C.5080604@redhat.com>
References: <55375B0C.5080604@redhat.com>
Message-ID: <CAAoo=c7ekt-b2i5G0E3RopLQrFoYT18Gr5+77Afbc3-XyPNWhA@mail.gmail.com>

For reference this is the original JIRA that resulted in the module being
created:

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

Stuart


On Wed, 22 Apr 2015 at 16:26 Carlo de Wolf <cdewolf at redhat.com> wrote:

> What is the purpose of this component?
> All those classes are JDK.
>
> Carlo
> _______________________________________________
> 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/20150422/b663cdcb/attachment.html 

From darran.lofthouse at jboss.com  Wed Apr 22 07:20:05 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Wed, 22 Apr 2015 12:20:05 +0100
Subject: [wildfly-dev] Management Parser Versioning
Message-ID: <553783E5.3010204@jboss.com>

Working with the parsers for the core config has become increasingly 
cryptic, we are now at the point where we have three different major 
versions which diverge and converge as we work on them.  Most recent 
changes have resulted in large sections of the config converging for 1.x 
and 3.x leaving 2.x independent.

So that I can add references to Elytron I am starting to add support for 
version 4.

One think that I have learned is that each major version tends to belong 
to one branch of the codebase, all changes to that version happen on 
that branch first: -

  1.x - Maintained only for EAP
  2.x - WildFly 8.x branch
  3.x - WildFly Core master branch

I would expect if further changes are made to core for WildFly 9 
releases we will end up with 1.x branch of core and and 4.x version of 
the schema will be owned by the master branch.

To make things less cryptic I am proposing that until we find a better 
solution for all subsequent major schema versions we just fork the 
parser and all related classes.

This will simplify the code being modified for the upstream development.

Forward porting parsing changes will also become a simple copy and paste.

For the current cryptic approach I think almost every engineer (and I am 
finding it really hard to think of exceptions) that has worked in-depth 
in this area has introduced at least one bug and I don't think the test 
coverage is high enough to protect against this.

Regards,
Darran Lofthouse.


From brian.stansberry at redhat.com  Wed Apr 22 08:30:04 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 22 Apr 2015 07:30:04 -0500
Subject: [wildfly-dev] Management Parser Versioning
In-Reply-To: <553783E5.3010204@jboss.com>
References: <553783E5.3010204@jboss.com>
Message-ID: <5537944C.9090602@redhat.com>

That's fine with me.

On 4/22/15 6:20 AM, Darran Lofthouse wrote:
> Working with the parsers for the core config has become increasingly
> cryptic, we are now at the point where we have three different major
> versions which diverge and converge as we work on them.  Most recent
> changes have resulted in large sections of the config converging for 1.x
> and 3.x leaving 2.x independent.
>
> So that I can add references to Elytron I am starting to add support for
> version 4.
>
> One think that I have learned is that each major version tends to belong
> to one branch of the codebase, all changes to that version happen on
> that branch first: -
>
>    1.x - Maintained only for EAP
>    2.x - WildFly 8.x branch
>    3.x - WildFly Core master branch
>
> I would expect if further changes are made to core for WildFly 9
> releases we will end up with 1.x branch of core and and 4.x version of
> the schema will be owned by the master branch.
>
> To make things less cryptic I am proposing that until we find a better
> solution for all subsequent major schema versions we just fork the
> parser and all related classes.
>
> This will simplify the code being modified for the upstream development.
>
> Forward porting parsing changes will also become a simple copy and paste.
>
> For the current cryptic approach I think almost every engineer (and I am
> finding it really hard to think of exceptions) that has worked in-depth
> in this area has introduced at least one bug and I don't think the test
> coverage is high enough to protect against this.
>
> Regards,
> Darran Lofthouse.
>
> _______________________________________________
> 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 ales.justin at gmail.com  Wed Apr 22 10:57:12 2015
From: ales.justin at gmail.com (Ales Justin)
Date: Wed, 22 Apr 2015 16:57:12 +0200
Subject: [wildfly-dev] Call For Final Component Upgrades
In-Reply-To: <CAFm4XO0k=Tj-7qpJA_n1xitnQpTxxXQtoJ1V21H3u07-cs9i+g@mail.gmail.com>
References: <5FB2A2C9-E3B0-430F-888F-0FA218E749ED@redhat.com>
	<8EC07451-D2AE-4BC2-B9F8-3E670DBE674C@gmail.com>
	<CAFm4XO0k=Tj-7qpJA_n1xitnQpTxxXQtoJ1V21H3u07-cs9i+g@mail.gmail.com>
Message-ID: <70BDA36A-C40E-41F8-B11F-7D56C047D7DE@gmail.com>

Are there plans to update Ispn to 7.2.x version in latest WF?
@Paul, Rado ^^

-Ales

> On 20 Apr 2015, at 20:15, Sanne Grinovero <sanne at hibernate.org> wrote:
> 
> Hi Ales,
> 
> that modules refactoring is tracked by WFLY-4232.
> 
> Note that it was marked "just" as an improvement (to minimize
> dependencies) as there never was an intention to expose the Infinispan
> Query features to users. I'll raise the priority (and fix it) since it
> seems CapeDwarf needs it but discussing with Toma? we've found a
> better solution for post-WF9; see also the thread "Feature-packs,
> versions / module slots and independent release cycles", that
> describes how we should solve it in future.
> 
> Sanne
> 
> On 13 April 2015 at 12:21, Ales Justin <ales.justin at gmail.com> wrote:
>> Hibernate Search / Infinispan Query modules (and its dependencies) need a complete overhaul -- as they are a complete mess / useless atm.
>> 
>> So I'm just wondering who's gonna take this over?
>> Sanne / Gustavo?
>> 
>> -Ales
>> 
>>> On 11 Apr 2015, at 01:23, Jason Greene <jason.greene at redhat.com> wrote:
>>> 
>>> If you haven?t already, please send in a PR updating your component to Final status, as we hope to release 9 Final this month.
>>> 
>>> Thanks!
>>> --
>>> 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 steve at hibernate.org  Wed Apr 22 17:11:10 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 22 Apr 2015 16:11:10 -0500
Subject: [wildfly-dev] arquillian-container-karaf-managed
Message-ID: <CAFdSV9uSLg+OD9f2zXGeN1n6wq9ZhOZ-HX29hkXwx=vwpFt3Zw@mail.gmail.com>

Anyone know of tutorials or guides on
using arquillian-container-karaf-managed?  Or willing to help me figure out
using that in hibernate-osgi tests?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150422/56050ff2/attachment.html 

From hardy at hibernate.org  Thu Apr 23 04:49:43 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Thu, 23 Apr 2015 10:49:43 +0200
Subject: [wildfly-dev] arquillian-container-karaf-managed
In-Reply-To: <CAFdSV9uSLg+OD9f2zXGeN1n6wq9ZhOZ-HX29hkXwx=vwpFt3Zw@mail.gmail.com>
References: <CAFdSV9uSLg+OD9f2zXGeN1n6wq9ZhOZ-HX29hkXwx=vwpFt3Zw@mail.gmail.com>
Message-ID: <20150423084943.GA34889@Nineveh.lan>

Hi,

does it have to be Arquillian? In Search and Validator we are using Pax Exam[1]
for Karaf integration tests. See for example OsgiIntegrationTest [2] in Validator.

It works quite well, but no matter whether Pax Exam or Arquillian it gets painful
once you need to debug the tests. There it is often the best approach to have a local
Karaf instance into which you deploy your features to verify that it actually deploys.

From my conversations with Brett I concluded that the Arquillian approach is more fragile than
Pax Exam, but I don't have actual experience with Arquillian + Karaf.

--Hardy

[1] https://ops4j1.jira.com/wiki/display/paxexam/Pax+Exam
[2] https://github.com/hferentschik/hibernate-validator/blob/HV-978/osgi/integrationtest/src/test/java/org/hibernate/validator/osgi/integrationtest/OsgiIntegrationTest.java


On Wed, Apr 22, 2015 at 04:11:10PM -0500, Steve Ebersole wrote:
> Anyone know of tutorials or guides on
> using arquillian-container-karaf-managed?  Or willing to help me figure out
> using that in hibernate-osgi tests?

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150423/b9912636/attachment.bin 

From rhusar at redhat.com  Thu Apr 23 05:45:23 2015
From: rhusar at redhat.com (Radoslav Husar)
Date: Thu, 23 Apr 2015 11:45:23 +0200
Subject: [wildfly-dev] Call For Final Component Upgrades
In-Reply-To: <70BDA36A-C40E-41F8-B11F-7D56C047D7DE@gmail.com>
References: <5FB2A2C9-E3B0-430F-888F-0FA218E749ED@redhat.com>
	<8EC07451-D2AE-4BC2-B9F8-3E670DBE674C@gmail.com>
	<CAFm4XO0k=Tj-7qpJA_n1xitnQpTxxXQtoJ1V21H3u07-cs9i+g@mail.gmail.com>
	<70BDA36A-C40E-41F8-B11F-7D56C047D7DE@gmail.com>
Message-ID: <5538BF33.20002@redhat.com>

Hi Ales,

the current plan is to stick with 7.1 (currently we are pulling 
7.1.1.Final) due to timing since we are targeting WF final at the end of 
month and Infinispan 7.2 likely won't be final in time (and yes, simply 
dropping in 7.2.0.CR1 won't work since it won't even compile).

Rado

On 22/04/15 16:57, Ales Justin wrote:
> Are there plans to update Ispn to 7.2.x version in latest WF?
> @Paul, Rado ^^
>
> -Ales
>
>> On 20 Apr 2015, at 20:15, Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> Hi Ales,
>>
>> that modules refactoring is tracked by WFLY-4232.
>>
>> Note that it was marked "just" as an improvement (to minimize
>> dependencies) as there never was an intention to expose the Infinispan
>> Query features to users. I'll raise the priority (and fix it) since it
>> seems CapeDwarf needs it but discussing with Toma? we've found a
>> better solution for post-WF9; see also the thread "Feature-packs,
>> versions / module slots and independent release cycles", that
>> describes how we should solve it in future.
>>
>> Sanne
>>
>> On 13 April 2015 at 12:21, Ales Justin <ales.justin at gmail.com> wrote:
>>> Hibernate Search / Infinispan Query modules (and its dependencies) need a complete overhaul -- as they are a complete mess / useless atm.
>>>
>>> So I'm just wondering who's gonna take this over?
>>> Sanne / Gustavo?
>>>
>>> -Ales
>>>
>>>> On 11 Apr 2015, at 01:23, Jason Greene <jason.greene at redhat.com> wrote:
>>>>
>>>> If you haven?t already, please send in a PR updating your component to Final status, as we hope to release 9 Final this month.
>>>>
>>>> Thanks!
>>>> --
>>>> 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 psotirop at redhat.com  Thu Apr 23 09:31:33 2015
From: psotirop at redhat.com (Panagiotis Sotiropoulos)
Date: Thu, 23 Apr 2015 09:31:33 -0400 (EDT)
Subject: [wildfly-dev] JBoss Automated Metrics Project
In-Reply-To: <1028674574.5387174.1429795699702.JavaMail.zimbra@redhat.com>
Message-ID: <1829850840.5389734.1429795893673.JavaMail.zimbra@redhat.com>

Hello all,

JBoss Automated Metrics is a project under development : https://developer.jboss.org/wiki/JBoss-Automated-Metrics
Please, feel free to make any recommendation or comment towards its improvement.

Thank you in advance,
Panagiotis



From psotirop at redhat.com  Thu Apr 23 09:37:19 2015
From: psotirop at redhat.com (Panagiotis Sotiropoulos)
Date: Thu, 23 Apr 2015 09:37:19 -0400 (EDT)
Subject: [wildfly-dev] JBoss Automated Metrics Project
In-Reply-To: <1829850840.5389734.1429795893673.JavaMail.zimbra@redhat.com>
References: <1829850840.5389734.1429795893673.JavaMail.zimbra@redhat.com>
Message-ID: <2141964078.5393912.1429796239617.JavaMail.zimbra@redhat.com>

Hello all,

JBoss Automated Metrics is a project under development : https://developer.jboss.org/wiki/JBoss-Automated-Metrics
Please, feel free to make any recommendation or comment towards its improvement.

Thank you in advance,
Panagiotis



From darran.lofthouse at jboss.com  Thu Apr 23 11:17:39 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Thu, 23 Apr 2015 16:17:39 +0100
Subject: [wildfly-dev] Management Parser Versioning
In-Reply-To: <5537944C.9090602@redhat.com>
References: <553783E5.3010204@jboss.com> <5537944C.9090602@redhat.com>
Message-ID: <55390D13.3020706@jboss.com>

Thinking about future XML changes, once the parser is forked I think we 
can also relax how we add new optional attributes and elements to the 
schema.

As I see it our main commitment is: -

* XML that is valid according to the schema should parse without error. *

I say 'should' as I believe in some cases documentation is relied upon 
to describe valid combinations.

* The XML we write must be valid according to the schema. *

Don't see any justification for not following that one.

* Parsers can be tolerant to XML that is technically invalid. *

e.g. we are not big on enforcing sequence ordering.

So lets say we have a release that contains a 4.0 version of the schema 
I think if in version 4.1 of the schema we add an optional attribute or 
element we can just add support for that attribute or element to the 
existing parse method.

Of course if the new attribute or element is required then we will need 
to switch to something version specific to avoid rejecting previously 
valid configuration.

I know this is a long way off but I only raise this now as I realise 
this has already happened where a new optional element has been added to 
the schema.  Technically if we were strict about it the code is wrong 
but the scenarios where it is going to break for someone are quite 
contrived and I think this fits with tolerant parsing and we will 
automatically fix on the next write.

Regards,
Darran Lofthouse.


On 22/04/15 13:30, Brian Stansberry wrote:
> That's fine with me.
>
> On 4/22/15 6:20 AM, Darran Lofthouse wrote:
>> Working with the parsers for the core config has become increasingly
>> cryptic, we are now at the point where we have three different major
>> versions which diverge and converge as we work on them.  Most recent
>> changes have resulted in large sections of the config converging for 1.x
>> and 3.x leaving 2.x independent.
>>
>> So that I can add references to Elytron I am starting to add support for
>> version 4.
>>
>> One think that I have learned is that each major version tends to belong
>> to one branch of the codebase, all changes to that version happen on
>> that branch first: -
>>
>>     1.x - Maintained only for EAP
>>     2.x - WildFly 8.x branch
>>     3.x - WildFly Core master branch
>>
>> I would expect if further changes are made to core for WildFly 9
>> releases we will end up with 1.x branch of core and and 4.x version of
>> the schema will be owned by the master branch.
>>
>> To make things less cryptic I am proposing that until we find a better
>> solution for all subsequent major schema versions we just fork the
>> parser and all related classes.
>>
>> This will simplify the code being modified for the upstream development.
>>
>> Forward porting parsing changes will also become a simple copy and paste.
>>
>> For the current cryptic approach I think almost every engineer (and I am
>> finding it really hard to think of exceptions) that has worked in-depth
>> in this area has introduced at least one bug and I don't think the test
>> coverage is high enough to protect against this.
>>
>> Regards,
>> Darran Lofthouse.
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>

From brian.stansberry at redhat.com  Thu Apr 23 11:32:54 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 23 Apr 2015 10:32:54 -0500
Subject: [wildfly-dev] Management Parser Versioning
In-Reply-To: <55390D13.3020706@jboss.com>
References: <553783E5.3010204@jboss.com> <5537944C.9090602@redhat.com>
	<55390D13.3020706@jboss.com>
Message-ID: <553910A6.9060909@redhat.com>

I don't think I've ever rejected or even questioned a PR because it made 
a parser tolerant in the way you describe, so I'm fine with being tolerant.

My only caveat is in no way do we have any commitment to be tolerant. If 
a change is implemented in such a way that the legacy schema parsing is 
tolerant, then it's tolerant for that change. Some other change may not 
be implemented that way and the parsing won't be tolerant. So we'll be 
inconsistent.

I'm sure we're already inconsistent in this regard, so that doesn't 
worry me. The schema defines the rules. If you follow them, you know 
what you'll get. If you break them, maybe it will work anyway, maybe 
not. Our only guarantee if you break the rules is you'll either end up 
with a valid running configuration or we'll fail.

On 4/23/15 10:17 AM, Darran Lofthouse wrote:
> Thinking about future XML changes, once the parser is forked I think we
> can also relax how we add new optional attributes and elements to the
> schema.
>
> As I see it our main commitment is: -
>
> * XML that is valid according to the schema should parse without error. *
>
> I say 'should' as I believe in some cases documentation is relied upon
> to describe valid combinations.
>
> * The XML we write must be valid according to the schema. *
>
> Don't see any justification for not following that one.
>
> * Parsers can be tolerant to XML that is technically invalid. *
>
> e.g. we are not big on enforcing sequence ordering.
>
> So lets say we have a release that contains a 4.0 version of the schema
> I think if in version 4.1 of the schema we add an optional attribute or
> element we can just add support for that attribute or element to the
> existing parse method.
>
> Of course if the new attribute or element is required then we will need
> to switch to something version specific to avoid rejecting previously
> valid configuration.
>
> I know this is a long way off but I only raise this now as I realise
> this has already happened where a new optional element has been added to
> the schema.  Technically if we were strict about it the code is wrong
> but the scenarios where it is going to break for someone are quite
> contrived and I think this fits with tolerant parsing and we will
> automatically fix on the next write.
>
> Regards,
> Darran Lofthouse.
>
>
> On 22/04/15 13:30, Brian Stansberry wrote:
>> That's fine with me.
>>
>> On 4/22/15 6:20 AM, Darran Lofthouse wrote:
>>> Working with the parsers for the core config has become increasingly
>>> cryptic, we are now at the point where we have three different major
>>> versions which diverge and converge as we work on them.  Most recent
>>> changes have resulted in large sections of the config converging for 1.x
>>> and 3.x leaving 2.x independent.
>>>
>>> So that I can add references to Elytron I am starting to add support for
>>> version 4.
>>>
>>> One think that I have learned is that each major version tends to belong
>>> to one branch of the codebase, all changes to that version happen on
>>> that branch first: -
>>>
>>>      1.x - Maintained only for EAP
>>>      2.x - WildFly 8.x branch
>>>      3.x - WildFly Core master branch
>>>
>>> I would expect if further changes are made to core for WildFly 9
>>> releases we will end up with 1.x branch of core and and 4.x version of
>>> the schema will be owned by the master branch.
>>>
>>> To make things less cryptic I am proposing that until we find a better
>>> solution for all subsequent major schema versions we just fork the
>>> parser and all related classes.
>>>
>>> This will simplify the code being modified for the upstream development.
>>>
>>> Forward porting parsing changes will also become a simple copy and paste.
>>>
>>> For the current cryptic approach I think almost every engineer (and I am
>>> finding it really hard to think of exceptions) that has worked in-depth
>>> in this area has introduced at least one bug and I don't think the test
>>> coverage is high enough to protect against this.
>>>
>>> Regards,
>>> Darran Lofthouse.
>>>
>>> _______________________________________________
>>> 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 darran.lofthouse at jboss.com  Thu Apr 23 11:37:38 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Thu, 23 Apr 2015 16:37:38 +0100
Subject: [wildfly-dev] Management Parser Versioning
In-Reply-To: <553910A6.9060909@redhat.com>
References: <553783E5.3010204@jboss.com>
	<5537944C.9090602@redhat.com>	<55390D13.3020706@jboss.com>
	<553910A6.9060909@redhat.com>
Message-ID: <553911C2.8010706@jboss.com>

On 23/04/15 16:32, Brian Stansberry wrote:
> I don't think I've ever rejected or even questioned a PR because it made
> a parser tolerant in the way you describe, so I'm fine with being tolerant.

+1 I think the first two rules are what we need to advertise we support, 
after all that is why we have schemas.  The third point is more about 
the requirements being placed on the maintainer of the parser so if your 
XML does not match the schema the best we say is "It may work, it may 
not work and that can change without warning".

> My only caveat is in no way do we have any commitment to be tolerant. If
> a change is implemented in such a way that the legacy schema parsing is
> tolerant, then it's tolerant for that change. Some other change may not
> be implemented that way and the parsing won't be tolerant. So we'll be
> inconsistent.
>
> I'm sure we're already inconsistent in this regard, so that doesn't
> worry me. The schema defines the rules. If you follow them, you know
> what you'll get. If you break them, maybe it will work anyway, maybe
> not. Our only guarantee if you break the rules is you'll either end up
> with a valid running configuration or we'll fail.
>
> On 4/23/15 10:17 AM, Darran Lofthouse wrote:
>> Thinking about future XML changes, once the parser is forked I think we
>> can also relax how we add new optional attributes and elements to the
>> schema.
>>
>> As I see it our main commitment is: -
>>
>> * XML that is valid according to the schema should parse without error. *
>>
>> I say 'should' as I believe in some cases documentation is relied upon
>> to describe valid combinations.
>>
>> * The XML we write must be valid according to the schema. *
>>
>> Don't see any justification for not following that one.
>>
>> * Parsers can be tolerant to XML that is technically invalid. *
>>
>> e.g. we are not big on enforcing sequence ordering.
>>
>> So lets say we have a release that contains a 4.0 version of the schema
>> I think if in version 4.1 of the schema we add an optional attribute or
>> element we can just add support for that attribute or element to the
>> existing parse method.
>>
>> Of course if the new attribute or element is required then we will need
>> to switch to something version specific to avoid rejecting previously
>> valid configuration.
>>
>> I know this is a long way off but I only raise this now as I realise
>> this has already happened where a new optional element has been added to
>> the schema.  Technically if we were strict about it the code is wrong
>> but the scenarios where it is going to break for someone are quite
>> contrived and I think this fits with tolerant parsing and we will
>> automatically fix on the next write.
>>
>> Regards,
>> Darran Lofthouse.
>>
>>
>> On 22/04/15 13:30, Brian Stansberry wrote:
>>> That's fine with me.
>>>
>>> On 4/22/15 6:20 AM, Darran Lofthouse wrote:
>>>> Working with the parsers for the core config has become increasingly
>>>> cryptic, we are now at the point where we have three different major
>>>> versions which diverge and converge as we work on them.  Most recent
>>>> changes have resulted in large sections of the config converging for 1.x
>>>> and 3.x leaving 2.x independent.
>>>>
>>>> So that I can add references to Elytron I am starting to add support for
>>>> version 4.
>>>>
>>>> One think that I have learned is that each major version tends to belong
>>>> to one branch of the codebase, all changes to that version happen on
>>>> that branch first: -
>>>>
>>>>       1.x - Maintained only for EAP
>>>>       2.x - WildFly 8.x branch
>>>>       3.x - WildFly Core master branch
>>>>
>>>> I would expect if further changes are made to core for WildFly 9
>>>> releases we will end up with 1.x branch of core and and 4.x version of
>>>> the schema will be owned by the master branch.
>>>>
>>>> To make things less cryptic I am proposing that until we find a better
>>>> solution for all subsequent major schema versions we just fork the
>>>> parser and all related classes.
>>>>
>>>> This will simplify the code being modified for the upstream development.
>>>>
>>>> Forward porting parsing changes will also become a simple copy and paste.
>>>>
>>>> For the current cryptic approach I think almost every engineer (and I am
>>>> finding it really hard to think of exceptions) that has worked in-depth
>>>> in this area has introduced at least one bug and I don't think the test
>>>> coverage is high enough to protect against this.
>>>>
>>>> Regards,
>>>> Darran Lofthouse.
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>

From jason.greene at redhat.com  Thu Apr 23 12:11:01 2015
From: jason.greene at redhat.com (Jason Greene)
Date: Thu, 23 Apr 2015 11:11:01 -0500
Subject: [wildfly-dev] Management Parser Versioning
In-Reply-To: <553783E5.3010204@jboss.com>
References: <553783E5.3010204@jboss.com>
Message-ID: <97BCA845-5C2B-4664-86B5-5CE2D4F6574A@redhat.com>

Thanks for looking at this Darran. I agree with your proposal as well.

> On Apr 22, 2015, at 6:20 AM, Darran Lofthouse <darran.lofthouse at jboss.com> wrote:
> 
> Working with the parsers for the core config has become increasingly 
> cryptic, we are now at the point where we have three different major 
> versions which diverge and converge as we work on them.  Most recent 
> changes have resulted in large sections of the config converging for 1.x 
> and 3.x leaving 2.x independent.
> 
> So that I can add references to Elytron I am starting to add support for 
> version 4.
> 
> One think that I have learned is that each major version tends to belong 
> to one branch of the codebase, all changes to that version happen on 
> that branch first: -
> 
>  1.x - Maintained only for EAP
>  2.x - WildFly 8.x branch
>  3.x - WildFly Core master branch
> 
> I would expect if further changes are made to core for WildFly 9 
> releases we will end up with 1.x branch of core and and 4.x version of 
> the schema will be owned by the master branch.
> 
> To make things less cryptic I am proposing that until we find a better 
> solution for all subsequent major schema versions we just fork the 
> parser and all related classes.
> 
> This will simplify the code being modified for the upstream development.
> 
> Forward porting parsing changes will also become a simple copy and paste.
> 
> For the current cryptic approach I think almost every engineer (and I am 
> finding it really hard to think of exceptions) that has worked in-depth 
> in this area has introduced at least one bug and I don't think the test 
> coverage is high enough to protect against this.
> 
> Regards,
> Darran Lofthouse.
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

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



From jason.greene at redhat.com  Thu Apr 23 12:12:14 2015
From: jason.greene at redhat.com (Jason Greene)
Date: Thu, 23 Apr 2015 11:12:14 -0500
Subject: [wildfly-dev] Management Parser Versioning
In-Reply-To: <553910A6.9060909@redhat.com>
References: <553783E5.3010204@jboss.com> <5537944C.9090602@redhat.com>
	<55390D13.3020706@jboss.com> <553910A6.9060909@redhat.com>
Message-ID: <77FFD3F9-7C74-4DA7-9A16-61A17FA62562@redhat.com>

Yes, we don?t need to have bug-for-bug validation forward compatibility. We should only guarantee compatibility for the version as it was written.

> On Apr 23, 2015, at 10:32 AM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> 
> I don't think I've ever rejected or even questioned a PR because it made 
> a parser tolerant in the way you describe, so I'm fine with being tolerant.
> 
> My only caveat is in no way do we have any commitment to be tolerant. If 
> a change is implemented in such a way that the legacy schema parsing is 
> tolerant, then it's tolerant for that change. Some other change may not 
> be implemented that way and the parsing won't be tolerant. So we'll be 
> inconsistent.
> 
> I'm sure we're already inconsistent in this regard, so that doesn't 
> worry me. The schema defines the rules. If you follow them, you know 
> what you'll get. If you break them, maybe it will work anyway, maybe 
> not. Our only guarantee if you break the rules is you'll either end up 
> with a valid running configuration or we'll fail.
> 
> On 4/23/15 10:17 AM, Darran Lofthouse wrote:
>> Thinking about future XML changes, once the parser is forked I think we
>> can also relax how we add new optional attributes and elements to the
>> schema.
>> 
>> As I see it our main commitment is: -
>> 
>> * XML that is valid according to the schema should parse without error. *
>> 
>> I say 'should' as I believe in some cases documentation is relied upon
>> to describe valid combinations.
>> 
>> * The XML we write must be valid according to the schema. *
>> 
>> Don't see any justification for not following that one.
>> 
>> * Parsers can be tolerant to XML that is technically invalid. *
>> 
>> e.g. we are not big on enforcing sequence ordering.
>> 
>> So lets say we have a release that contains a 4.0 version of the schema
>> I think if in version 4.1 of the schema we add an optional attribute or
>> element we can just add support for that attribute or element to the
>> existing parse method.
>> 
>> Of course if the new attribute or element is required then we will need
>> to switch to something version specific to avoid rejecting previously
>> valid configuration.
>> 
>> I know this is a long way off but I only raise this now as I realise
>> this has already happened where a new optional element has been added to
>> the schema.  Technically if we were strict about it the code is wrong
>> but the scenarios where it is going to break for someone are quite
>> contrived and I think this fits with tolerant parsing and we will
>> automatically fix on the next write.
>> 
>> Regards,
>> Darran Lofthouse.
>> 
>> 
>> On 22/04/15 13:30, Brian Stansberry wrote:
>>> That's fine with me.
>>> 
>>> On 4/22/15 6:20 AM, Darran Lofthouse wrote:
>>>> Working with the parsers for the core config has become increasingly
>>>> cryptic, we are now at the point where we have three different major
>>>> versions which diverge and converge as we work on them.  Most recent
>>>> changes have resulted in large sections of the config converging for 1.x
>>>> and 3.x leaving 2.x independent.
>>>> 
>>>> So that I can add references to Elytron I am starting to add support for
>>>> version 4.
>>>> 
>>>> One think that I have learned is that each major version tends to belong
>>>> to one branch of the codebase, all changes to that version happen on
>>>> that branch first: -
>>>> 
>>>>     1.x - Maintained only for EAP
>>>>     2.x - WildFly 8.x branch
>>>>     3.x - WildFly Core master branch
>>>> 
>>>> I would expect if further changes are made to core for WildFly 9
>>>> releases we will end up with 1.x branch of core and and 4.x version of
>>>> the schema will be owned by the master branch.
>>>> 
>>>> To make things less cryptic I am proposing that until we find a better
>>>> solution for all subsequent major schema versions we just fork the
>>>> parser and all related classes.
>>>> 
>>>> This will simplify the code being modified for the upstream development.
>>>> 
>>>> Forward porting parsing changes will also become a simple copy and paste.
>>>> 
>>>> For the current cryptic approach I think almost every engineer (and I am
>>>> finding it really hard to think of exceptions) that has worked in-depth
>>>> in this area has introduced at least one bug and I don't think the test
>>>> coverage is high enough to protect against this.
>>>> 
>>>> Regards,
>>>> Darran Lofthouse.
>>>> 
>>>> _______________________________________________
>>>> 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
> _______________________________________________
> 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 cdewolf at redhat.com  Thu Apr 23 13:48:00 2015
From: cdewolf at redhat.com (Carlo de Wolf)
Date: Thu, 23 Apr 2015 19:48:00 +0200
Subject: [wildfly-dev] Purpose of
	https://github.com/jboss/jboss-javax-sql-api_spec
In-Reply-To: <CAAoo=c7ekt-b2i5G0E3RopLQrFoYT18Gr5+77Afbc3-XyPNWhA@mail.gmail.com>
References: <55375B0C.5080604@redhat.com>
	<CAAoo=c7ekt-b2i5G0E3RopLQrFoYT18Gr5+77Afbc3-XyPNWhA@mail.gmail.com>
Message-ID: <55393050.7060705@redhat.com>

Okay, that explains it.

Why don't we have the javax.sql.api module expose the javax.sql classes 
from the JDK instead of rewriting those classes?

Carlo

On 04/22/2015 12:57 PM, Stuart Douglas wrote:
> For reference this is the original JIRA that resulted in the module 
> being created:
>
> https://issues.jboss.org/browse/WFCORE-561
>
> Stuart
>
>
> On Wed, 22 Apr 2015 at 16:26 Carlo de Wolf <cdewolf at redhat.com 
> <mailto:cdewolf at redhat.com>> wrote:
>
>     What is the purpose of this component?
>     All those classes are JDK.
>
>     Carlo
>     _______________________________________________
>     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/20150423/c3dc0180/attachment.html 

From david.lloyd at redhat.com  Thu Apr 23 14:32:04 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Thu, 23 Apr 2015 13:32:04 -0500
Subject: [wildfly-dev] Purpose of
	https://github.com/jboss/jboss-javax-sql-api_spec
In-Reply-To: <55393050.7060705@redhat.com>
References: <55375B0C.5080604@redhat.com>	<CAAoo=c7ekt-b2i5G0E3RopLQrFoYT18Gr5+77Afbc3-XyPNWhA@mail.gmail.com>
	<55393050.7060705@redhat.com>
Message-ID: <55393AA4.2070509@redhat.com>

Because those classes link against classes that we replace in modules, 
like XAResource.

On 04/23/2015 12:48 PM, Carlo de Wolf wrote:
> Okay, that explains it.
>
> Why don't we have the javax.sql.api module expose the javax.sql classes
> from the JDK instead of rewriting those classes?
>
> Carlo
>
> On 04/22/2015 12:57 PM, Stuart Douglas wrote:
>> For reference this is the original JIRA that resulted in the module
>> being created:
>>
>> https://issues.jboss.org/browse/WFCORE-561
>>
>> Stuart
>>
>>
>> On Wed, 22 Apr 2015 at 16:26 Carlo de Wolf <cdewolf at redhat.com
>> <mailto:cdewolf at redhat.com>> wrote:
>>
>>     What is the purpose of this component?
>>     All those classes are JDK.
>>
>>     Carlo
>>     _______________________________________________
>>     wildfly-dev mailing list
>>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

-- 
- DML

From steve at hibernate.org  Thu Apr 23 17:02:09 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 23 Apr 2015 16:02:09 -0500
Subject: [wildfly-dev] arquillian-container-karaf-managed
In-Reply-To: <20150423084943.GA34889@Nineveh.lan>
References: <CAFdSV9uSLg+OD9f2zXGeN1n6wq9ZhOZ-HX29hkXwx=vwpFt3Zw@mail.gmail.com>
	<20150423084943.GA34889@Nineveh.lan>
Message-ID: <CAFdSV9tKSoMxDonYAaRJhgUfRupVCEHYcBYgVXaPvQBb1RjGEg@mail.gmail.com>

Nope, it does not have to be arquillian per-se.  As long as there is some
way I can:
1) start the thing when the tests start
2) stop it after they are done
3) easily deploy the test bundle(s)

On Thu, Apr 23, 2015 at 3:49 AM, Hardy Ferentschik <hardy at hibernate.org>
wrote:

> Hi,
>
> does it have to be Arquillian? In Search and Validator we are using Pax
> Exam[1]
> for Karaf integration tests. See for example OsgiIntegrationTest [2] in
> Validator.
>
> It works quite well, but no matter whether Pax Exam or Arquillian it gets
> painful
> once you need to debug the tests. There it is often the best approach to
> have a local
> Karaf instance into which you deploy your features to verify that it
> actually deploys.
>
> From my conversations with Brett I concluded that the Arquillian approach
> is more fragile than
> Pax Exam, but I don't have actual experience with Arquillian + Karaf.
>
> --Hardy
>
> [1] https://ops4j1.jira.com/wiki/display/paxexam/Pax+Exam
> [2]
> https://github.com/hferentschik/hibernate-validator/blob/HV-978/osgi/integrationtest/src/test/java/org/hibernate/validator/osgi/integrationtest/OsgiIntegrationTest.java
>
>
> On Wed, Apr 22, 2015 at 04:11:10PM -0500, Steve Ebersole wrote:
> > Anyone know of tutorials or guides on
> > using arquillian-container-karaf-managed?  Or willing to help me figure
> out
> > using that in hibernate-osgi tests?
>
> > _______________________________________________
> > 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/20150423/bc00ffc2/attachment.html 

From rory.odonnell at oracle.com  Fri Apr 24 03:47:46 2015
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Fri, 24 Apr 2015 08:47:46 +0100
Subject: [wildfly-dev] Early Access builds for JDK 9 b60 and JDK 8u60 b12
 are available on java.net
Message-ID: <5539F522.9060508@oracle.com>

Hi Jason/Tomaz,

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

Early Access build for JDK 8u60 b12 <http://jdk8.java.net/download.html> 
is available on java.net, summary of changes are listed here. 
<http://www.java.net/download/jdk8u60/changes/jdk8u60-b12.html>

Rgds,Rory

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

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

From ewertz at redhat.com  Fri Apr 24 05:21:07 2015
From: ewertz at redhat.com (Edward Wertz)
Date: Fri, 24 Apr 2015 05:21:07 -0400 (EDT)
Subject: [wildfly-dev] CLI 'module add/remove' Command Discussion
In-Reply-To: <2119280.218.1429854526568.JavaMail.joe@localhost.localdomain>
Message-ID: <32047850.292.1429867261940.JavaMail.joe@localhost.localdomain>

I discovered that the CLI 'module' command has been in need of a discussion for awhile. There are some issues with the command, and lingering enhancement requests, that can't be cleared up unless a future is clearly established. Since I can't seem to find any existing discussion on the subject, I wanted to throw it out here.

Issues:

 * The main issue is that the current command simply doesn't interact with the server to do anything. It relies on file system access and creates or removes module directories and resources on it's own. The server can then reload and find them. Simple, but effective.

 * Another issue is that the command is disabled for domain mode. Interestingly, since the command can be used in a disconnected state, it can still be used to manipulate domain modules assuming the servers module path remains the default at 'JBOSS_HOME/modules'. A module can be added or removed while the CLI is disconnected, then it can connect and reload the servers to complete the add or remove.

Refactoring Thoughts:

To bring it in-line with most other commands, and allow it to be expanded, the process should probably be happening server-side rather than CLI-side. I'm envisioning something akin to the deploy functionality. For the time being refactoring a simple add/remove, but later expanding it to be far more functional. However I haven't had the chance yet to look into how, or if, the server maintains or manipulates the modules and paths anywhere or if the value is simply passed into the jboss-modules system. I don't believe there's a clear API for the modules system at the moment, so this puts me somewhat in the dark as to whether what I'm thinking about is even possible.

Of course, everything is possible. With enough work.

Concerns:

 * My main concern with needing a connection is that the current functionality would suffer. Right now the module command, being independent from the server, is enabled while the CLI is disconnected. I think that functionality is somewhat valuable since a standalone server reload does not actually remove a module. Once added and the server reloaded, a module is active until a full shutdown and restart. From what I understand it's much easier to add classes to a JVM than remove them, so this is expected. If not fixed a standalone server would have to be started, then the module removed, then shutdown and restarted. While not excessive, it is a little annoying.

 * Also, as pointed out earlier, the command can currently be used on domain servers if certain criteria are met. If a connection is required the command would become completely unusable for domain servers unless the functionality is expanded during the refactoring. 
 ** Note: The first concern doesn't seem to apply to domain servers, since the servers can be completely restarted from the host controller.

Thoughts and input are encouraged. Whether on the technical aspects of a refactor or simply using the command.

Joe Wertz

From smarlow at redhat.com  Fri Apr 24 10:01:10 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Fri, 24 Apr 2015 10:01:10 -0400
Subject: [wildfly-dev] WildFly NoSQL integration prototype
Message-ID: <553A4CA6.70905@redhat.com>

Are you interested in allowing NoSQL databases access from WildFly 
application deployments?  This email is about an integration effort to 
allow WildFly applications to use NoSQL.  Feedback is welcome on this 
effort, as well as help in improving [1].  Some basic unit tests are 
already added that show a session bean reading/writing MongoDB [2] + 
Cassandra [3] databases.  In order for the tests to pass, the local 
machine must already be running MongoDB or Cassandra databases.

1. Things that currently (seems to be) working in the prototype:

* During WildFly startup, MongoDB/Cassandra databases are connected to 
based on settings in their respective subsystems.  See the configuration 
example [4].

* Applications can access native MongoDB/Cassandra objects that 
represent database connections (with internal native connection 
pooling).  See @Resource example [2][3].  Will see how the requirements 
evolve going forward and whether @Resource is the right way and/or 
whether other annotations are needed.

2.  Currently not working in the prototype:

* Multiple hosts/ports cannot be specified yet for target database.

* Protection against applications closing pooled connections.

* NoSQL drivers currently may create threads in EE application threads 
which could leak ClassLoaders/AccessControlContexts.  One solution might 
be to contribute a patch that allows WildFly to do the thread creation 
in some fashion for the NoSQL drivers.

* We have not (yet) tried using (Java) security manager support with the 
NoSQL driver clients.

* Additional NoSQL connection attributes need to be added to the NoSQL 
subsystems.

* Native NoSQL class objects are bound to JNDI currently (e.g. 
MongoClient).  We might want to bind wrapper or proxy objects so that we 
can extend the NoSQL classes or in some cases, prevent certain actions 
(e.g. prevent calls to MongoClient.close()).  Perhaps we will end up 
with a mixed approach, where we could extend the NoSQL driver if that is 
the only way to manage it, or contribute a listener patch for WildFly to 
get control during certain events (e.g. for ignoring close of pooled 
database connections).

* The prototype currently gives all (WildFly) deployments access to the 
Cassandra/MongoDB driver module classloaders.  This is likely to change 
but not yet sure to what.

3.  The Weld (CDI) project is also looking at NoSQL enhancements, as is 
the Narayana project.  There is also the Hibernate OGM project that is 
pushing on JPA integration and will also help contribute changes to the 
NoSQL drivers that are needed for WildFly integration (e.g. introduce 
alternative way for NoSQL drivers manage thread creation for background 
task execution).

4.  We will need a place to track issues for NoSQL integration.  If the 
NoSQL integration changes are merged directly into WildFly, perhaps we 
could have a nosql category under https://issues.jboss.org/browse/WFLY.

5. You can view outstanding issues in the MongoDB server [5], Java 
driver [6] to get feel for problems that others have run into (just like 
you would with WildFly).  You can view outstanding issues in the 
Cassandra server [7] and Java driver [8] to get a feel for problems as well.

6.  Infinispan [9] integration in WildFly is still going strong. 
Infinispan is still the backbone of WildFly clustering and also 
available for applications to use as a datasource.

7.  The standalone.xml settings [4] will soon change (would like to 
eliminate the "name=default", add more attributes and get the multiple 
host/ports wired in).

8.  If the NoSQL unit tests do stay in the WildFly repo, they will need 
to be disabled by default, as most WildFly developers will not have a 
NoSQL database running.  Speaking of which, we need to wire the unit 
tests to update the standalone.xml to contain the MongoDB/Cassandra 
subsystem settings [4].

9.  What version of NoSQL databases will work with the WildFly NoSQL 
integration?  At this point, we will only work with one version of each 
NoSQL database that is integrated with.  Because we are likely to need 
some changes in the NoSQL client drivers, we will work with the upstream 
communities to ensure the NoSQL driver code can run in an EE container 
thread, without causing leaks.  First we have to identity the changes 
that we need (e.g. find some actual leaks that I only suspect will 
happen at this point and propose some changes).  The Hibernate OGM team 
is going to help with the driver patches (thanks Hibernate OGM team! :-)

10.  Going forward, how can WildFly extend the NoSQL (client driver 
side) capabilities to improve the different application life cycles 
through development, test, production?

Scott

[1] https://github.com/scottmarlow/wildfly/tree/nosql-dev

[2] 
https://github.com/scottmarlow/wildfly/blob/nosql-dev/testsuite/compat/src/test/java/org/jboss/as/test/compat/nosql/mongodb/StatefulTestBean.java#L23

[3] 
https://github.com/scottmarlow/wildfly/blob/nosql-dev/testsuite/compat/src/test/java/org/jboss/as/test/compat/nosql/cassandra/StatefulTestBean.java#L19

[4] https://gist.github.com/scottmarlow/b8196bdc56431bb171c8

[5] https://jira.mongodb.org/browse/SERVER

[6] https://jira.mongodb.org/browse/JAVA

[7] https://issues.apache.org/jira/browse/CASSANDRA

[8] https://datastax-oss.atlassian.net/browse/JAVA

[9] http://infinispan.org

From brian.stansberry at redhat.com  Fri Apr 24 13:50:44 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Fri, 24 Apr 2015 12:50:44 -0500
Subject: [wildfly-dev] CLI 'module add/remove' Command Discussion
In-Reply-To: <32047850.292.1429867261940.JavaMail.joe@localhost.localdomain>
References: <32047850.292.1429867261940.JavaMail.joe@localhost.localdomain>
Message-ID: <553A8274.2060106@redhat.com>

FYI, Flavia Rainone was looking into this general topic, so you should 
coordinate with her.

On 4/24/15 4:21 AM, Edward Wertz wrote:
> I discovered that the CLI 'module' command has been in need of a discussion for awhile. There are some issues with the command, and lingering enhancement requests, that can't be cleared up unless a future is clearly established. Since I can't seem to find any existing discussion on the subject, I wanted to throw it out here.
>
> Issues:
>
>   * The main issue is that the current command simply doesn't interact with the server to do anything. It relies on file system access and creates or removes module directories and resources on it's own. The server can then reload and find them. Simple, but effective.
>
>   * Another issue is that the command is disabled for domain mode. Interestingly, since the command can be used in a disconnected state, it can still be used to manipulate domain modules assuming the servers module path remains the default at 'JBOSS_HOME/modules'. A module can be added or removed while the CLI is disconnected, then it can connect and reload the servers to complete the add or remove.
>
> Refactoring Thoughts:
>
> To bring it in-line with most other commands, and allow it to be expanded, the process should probably be happening server-side rather than CLI-side. I'm envisioning something akin to the deploy functionality. For the time being refactoring a simple add/remove, but later expanding it to be far more functional. However I haven't had the chance yet to look into how, or if, the server maintains or manipulates the modules and paths anywhere or if the value is simply passed into the jboss-modules system. I don't believe there's a clear API for the modules system at the moment, so this puts me somewhat in the dark as to whether what I'm thinking about is even possible.
>
> Of course, everything is possible. With enough work.
>
> Concerns:
>
>   * My main concern with needing a connection is that the current functionality would suffer. Right now the module command, being independent from the server, is enabled while the CLI is disconnected. I think that functionality is somewhat valuable since a standalone server reload does not actually remove a module. Once added and the server reloaded, a module is active until a full shutdown and restart. From what I understand it's much easier to add classes to a JVM than remove them, so this is expected. If not fixed a standalone server would have to be started, then the module removed, then shutdown and restarted. While not excessive, it is a little annoying.
>
I'm fine with that limitation. I don't think the CLI should be in the 
business of making local changes not mediated by the server.

The offline CLI stuff in WF 9 Beta1 may help with this, as the CLI can 
delegate to server-side logic without needing to spin up a separate process.

>   * Also, as pointed out earlier, the command can currently be used on domain servers if certain criteria are met. If a connection is required the command would become completely unusable for domain servers unless the functionality is expanded during the refactoring.
>   ** Note: The first concern doesn't seem to apply to domain servers, since the servers can be completely restarted from the host controller.
>
> Thoughts and input are encouraged. Whether on the technical aspects of a refactor or simply using the command.
>

The big issue with this in domain mode is that domain mode is all about 
maintaining consistency across the domain. That includes things like 
sending deployment content to new hosts that join the domain long after 
the first addition of the deployment. When we have CLI commands for 
things, I expect that basic behavior pattern will be upheld. To have 
equivalent behavior with modules that we have with deployments, that 
means storing data in the domain-wide persistent configuration, a la 
what we do with deployments. It's that data that drives the ability to 
provide content to newly joining hosts.

If we don't store that kind of data in the domain-wide config, this 
becomes more of a what I call a "provisioning" feature. Provisioning was 
very much out of scope for AS 7's management layer. We can of course 
consider changing the scope, but IMHO we need to have a very broad 
discussion before doing that. (So thanks for this thread.) We shouldn't 
do it via feature creep, which is what the current 'module' command was.


> Joe Wertz
> _______________________________________________
> 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 Apr 27 12:13:26 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 27 Apr 2015 11:13:26 -0500
Subject: [wildfly-dev] WFCORE-665
Message-ID: <553E6026.9090104@redhat.com>

Hi Jay,

Re: https://issues.jboss.org/browse/WFCORE-665

I wanted to discuss this here, just because it's a potential change in 
longstanding behavior, so it could use more visibility than JIRA 
comments or pull requests get.

I think the simple solution is just to invert the priority between 
groupVM and hostVM in the call to the JVMElement constructor at

https://github.com/wildfly/wildfly-core/blob/master/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServerBootCmdFactory.java#L132

There's one other analogous situation, with system properties, and there 
the host model value takes precedence over server-group. See 
ManagedServerOperationsFactory.getAllSystemProperties.

I want those two to be consistent, as I want all such precedence things 
to be consistent. (The "path" and "interface" resources are the other 
precedence things, but there "server-group" is not a factor.)

The argument for host overriding server-group is better to me than the 
opposite, so if we're picking one to be consistent with, I pick the 
former. One of the basic ideas of domain.xml versus host.xml is 
domain.xml sets the base config and then specific items can be overriden 
at the host level. So having server-group take precedence is unintuitive.

I don't like the approach in your patch because it makes the rules more 
complex. Whether host takes precedence over server-group depends on 
whether there's a jvm config at the server level with a name that 
matches one of the host level configs. That's too complicated.

Cheers,

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

From darran.lofthouse at jboss.com  Mon Apr 27 12:14:05 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Mon, 27 Apr 2015 17:14:05 +0100
Subject: [wildfly-dev] Management Parser Versioning
In-Reply-To: <553911C2.8010706@jboss.com>
References: <553783E5.3010204@jboss.com>	<5537944C.9090602@redhat.com>	<55390D13.3020706@jboss.com>	<553910A6.9060909@redhat.com>
	<553911C2.8010706@jboss.com>
Message-ID: <553E604D.7040207@jboss.com>

The following commits are now the end result of the re-factoring to 
allow a fork on new major versions and also to add version 4.0 of the 
schema: -

https://github.com/wildfly/wildfly-core/compare/f4a07f4e9b41dc59823fea1813f947c67965525a...58faefb1fa830d0193f862da9958b2541aea7dad

The changes look extensive but TBH the bulk is just moving of existing 
code and some duplicate for the fork for 4.

I have distinct commits to show the steps taken but the key points are: -

# Split out the model specific parsing from CommonXml into smaller 
implementations, this was to allow CommonXml to remain the common base 
without still containing version specific parsing.

# Rework of ManagementXml to be version based and rework the delegate, 
the big problem we had was we were looping back on ourselves with static 
calls which did not cleanly map to versioned implementations.

# Moved existing StandalonXml, HostXml, DomainXml, ManagementXml into 
'Legacy' parsers and used existing class to load these on-demand.

# Forked the legacy parsers to create the version 4 parsers, removed all 
version handling so a clean start for 4.

At this point there is still plenty of parsing code not forked for 4 but 
TBH those are all relatively stable and rarely change, StandaloneXml, 
HostXml, DomainXml, and ManagementXml on the other hand have changed for 
every major version so far.

Regards,
Darran Lofthouse.

On 23/04/15 16:37, Darran Lofthouse wrote:
> On 23/04/15 16:32, Brian Stansberry wrote:
>> I don't think I've ever rejected or even questioned a PR because it made
>> a parser tolerant in the way you describe, so I'm fine with being tolerant.
>
> +1 I think the first two rules are what we need to advertise we support,
> after all that is why we have schemas.  The third point is more about
> the requirements being placed on the maintainer of the parser so if your
> XML does not match the schema the best we say is "It may work, it may
> not work and that can change without warning".
>
>> My only caveat is in no way do we have any commitment to be tolerant. If
>> a change is implemented in such a way that the legacy schema parsing is
>> tolerant, then it's tolerant for that change. Some other change may not
>> be implemented that way and the parsing won't be tolerant. So we'll be
>> inconsistent.
>>
>> I'm sure we're already inconsistent in this regard, so that doesn't
>> worry me. The schema defines the rules. If you follow them, you know
>> what you'll get. If you break them, maybe it will work anyway, maybe
>> not. Our only guarantee if you break the rules is you'll either end up
>> with a valid running configuration or we'll fail.
>>
>> On 4/23/15 10:17 AM, Darran Lofthouse wrote:
>>> Thinking about future XML changes, once the parser is forked I think we
>>> can also relax how we add new optional attributes and elements to the
>>> schema.
>>>
>>> As I see it our main commitment is: -
>>>
>>> * XML that is valid according to the schema should parse without error. *
>>>
>>> I say 'should' as I believe in some cases documentation is relied upon
>>> to describe valid combinations.
>>>
>>> * The XML we write must be valid according to the schema. *
>>>
>>> Don't see any justification for not following that one.
>>>
>>> * Parsers can be tolerant to XML that is technically invalid. *
>>>
>>> e.g. we are not big on enforcing sequence ordering.
>>>
>>> So lets say we have a release that contains a 4.0 version of the schema
>>> I think if in version 4.1 of the schema we add an optional attribute or
>>> element we can just add support for that attribute or element to the
>>> existing parse method.
>>>
>>> Of course if the new attribute or element is required then we will need
>>> to switch to something version specific to avoid rejecting previously
>>> valid configuration.
>>>
>>> I know this is a long way off but I only raise this now as I realise
>>> this has already happened where a new optional element has been added to
>>> the schema.  Technically if we were strict about it the code is wrong
>>> but the scenarios where it is going to break for someone are quite
>>> contrived and I think this fits with tolerant parsing and we will
>>> automatically fix on the next write.
>>>
>>> Regards,
>>> Darran Lofthouse.
>>>
>>>
>>> On 22/04/15 13:30, Brian Stansberry wrote:
>>>> That's fine with me.
>>>>
>>>> On 4/22/15 6:20 AM, Darran Lofthouse wrote:
>>>>> Working with the parsers for the core config has become increasingly
>>>>> cryptic, we are now at the point where we have three different major
>>>>> versions which diverge and converge as we work on them.  Most recent
>>>>> changes have resulted in large sections of the config converging for 1.x
>>>>> and 3.x leaving 2.x independent.
>>>>>
>>>>> So that I can add references to Elytron I am starting to add support for
>>>>> version 4.
>>>>>
>>>>> One think that I have learned is that each major version tends to belong
>>>>> to one branch of the codebase, all changes to that version happen on
>>>>> that branch first: -
>>>>>
>>>>>        1.x - Maintained only for EAP
>>>>>        2.x - WildFly 8.x branch
>>>>>        3.x - WildFly Core master branch
>>>>>
>>>>> I would expect if further changes are made to core for WildFly 9
>>>>> releases we will end up with 1.x branch of core and and 4.x version of
>>>>> the schema will be owned by the master branch.
>>>>>
>>>>> To make things less cryptic I am proposing that until we find a better
>>>>> solution for all subsequent major schema versions we just fork the
>>>>> parser and all related classes.
>>>>>
>>>>> This will simplify the code being modified for the upstream development.
>>>>>
>>>>> Forward porting parsing changes will also become a simple copy and paste.
>>>>>
>>>>> For the current cryptic approach I think almost every engineer (and I am
>>>>> finding it really hard to think of exceptions) that has worked in-depth
>>>>> in this area has introduced at least one bug and I don't think the test
>>>>> coverage is high enough to protect against this.
>>>>>
>>>>> Regards,
>>>>> Darran Lofthouse.
>>>>>
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>
>>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From jason.greene at redhat.com  Mon Apr 27 12:25:01 2015
From: jason.greene at redhat.com (Jason Greene)
Date: Mon, 27 Apr 2015 11:25:01 -0500
Subject: [wildfly-dev] WFCORE-665
In-Reply-To: <553E6026.9090104@redhat.com>
References: <553E6026.9090104@redhat.com>
Message-ID: <20D2778F-E7E3-4902-9CA0-1884A3A18148@redhat.com>


> On Apr 27, 2015, at 11:13 AM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> 
> Hi Jay,
> 
> Re: https://issues.jboss.org/browse/WFCORE-665
> 
> I wanted to discuss this here, just because it's a potential change in 
> longstanding behavior, so it could use more visibility than JIRA 
> comments or pull requests get.
> 
> I think the simple solution is just to invert the priority between 
> groupVM and hostVM in the call to the JVMElement constructor at


The key question I have is if that will break people, and in particular if it will break old configs. If we are convinced that the existing approach was lightly used, or its just totally broken, we might be able to live with the break, but otherwise we might need some sort of resolution ordering property.

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



From brian.stansberry at redhat.com  Mon Apr 27 12:36:48 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 27 Apr 2015 11:36:48 -0500
Subject: [wildfly-dev] WFCORE-665
In-Reply-To: <20D2778F-E7E3-4902-9CA0-1884A3A18148@redhat.com>
References: <553E6026.9090104@redhat.com>
	<20D2778F-E7E3-4902-9CA0-1884A3A18148@redhat.com>
Message-ID: <553E65A0.80205@redhat.com>

On 4/27/15 11:25 AM, Jason Greene wrote:
>
>> On Apr 27, 2015, at 11:13 AM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>
>> Hi Jay,
>>
>> Re: https://issues.jboss.org/browse/WFCORE-665
>>
>> I wanted to discuss this here, just because it's a potential change in
>> longstanding behavior, so it could use more visibility than JIRA
>> comments or pull requests get.
>>
>> I think the simple solution is just to invert the priority between
>> groupVM and hostVM in the call to the JVMElement constructor at
>
>
> The key question I have is if that will break people, and in particular if it will break old configs. If we are convinced that the existing approach was lightly used, or its just totally broken, we might be able to live with the break, but otherwise we might need some sort of resolution ordering property.
>

It's possible, but it seems like an edge case. We merge the configs, so 
it's not a matter of completely ignoring the lower precedence stuff. So 
this would only affect someone if they declare some config item in both 
the host level and the server-group level and expect the server-group to 
take precedence.

For sure we'd need to audit this in detail though to look for gotchas. 
Stuff like unconfigured defaults suddenly taking precedence over 
configured values. (That one sounds like a bug anyway though.)


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

From darran.lofthouse at jboss.com  Tue Apr 28 11:04:01 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Tue, 28 Apr 2015 16:04:01 +0100
Subject: [wildfly-dev] Management Parser Versioning
In-Reply-To: <553E604D.7040207@jboss.com>
References: <553783E5.3010204@jboss.com>	<5537944C.9090602@redhat.com>	<55390D13.3020706@jboss.com>	<553910A6.9060909@redhat.com>	<553911C2.8010706@jboss.com>
	<553E604D.7040207@jboss.com>
Message-ID: <553FA161.9080604@jboss.com>

The following commit covers the WildFly side: -

https://github.com/darranl/wildfly/commit/8fc073eb11b71904d6235381ad2d3903ce3241aa

One problem with the current split is that as soon as you add a new 
management schema to core the integration with wildfly is broken 
immediately as some tests verify we write as version 3 when now we write 
as version 4.

I would suggest that as soon as we start development on WildFly 10 we 
create a very fast tag or core with just a few changes, probably just: -
  - Bump to Java 8
  - This schema version bump in this thread.
  - Any other build tweaks needed for Java 8.

WildFly can then use the new tag and have the same treatment.

Regards,
Darran Lofthouse.


On 27/04/15 17:14, Darran Lofthouse wrote:
> The following commits are now the end result of the re-factoring to
> allow a fork on new major versions and also to add version 4.0 of the
> schema: -
>
> https://github.com/wildfly/wildfly-core/compare/f4a07f4e9b41dc59823fea1813f947c67965525a...58faefb1fa830d0193f862da9958b2541aea7dad
>
> The changes look extensive but TBH the bulk is just moving of existing
> code and some duplicate for the fork for 4.
>
> I have distinct commits to show the steps taken but the key points are: -
>
> # Split out the model specific parsing from CommonXml into smaller
> implementations, this was to allow CommonXml to remain the common base
> without still containing version specific parsing.
>
> # Rework of ManagementXml to be version based and rework the delegate,
> the big problem we had was we were looping back on ourselves with static
> calls which did not cleanly map to versioned implementations.
>
> # Moved existing StandalonXml, HostXml, DomainXml, ManagementXml into
> 'Legacy' parsers and used existing class to load these on-demand.
>
> # Forked the legacy parsers to create the version 4 parsers, removed all
> version handling so a clean start for 4.
>
> At this point there is still plenty of parsing code not forked for 4 but
> TBH those are all relatively stable and rarely change, StandaloneXml,
> HostXml, DomainXml, and ManagementXml on the other hand have changed for
> every major version so far.
>
> Regards,
> Darran Lofthouse.
>
> On 23/04/15 16:37, Darran Lofthouse wrote:
>> On 23/04/15 16:32, Brian Stansberry wrote:
>>> I don't think I've ever rejected or even questioned a PR because it made
>>> a parser tolerant in the way you describe, so I'm fine with being tolerant.
>>
>> +1 I think the first two rules are what we need to advertise we support,
>> after all that is why we have schemas.  The third point is more about
>> the requirements being placed on the maintainer of the parser so if your
>> XML does not match the schema the best we say is "It may work, it may
>> not work and that can change without warning".
>>
>>> My only caveat is in no way do we have any commitment to be tolerant. If
>>> a change is implemented in such a way that the legacy schema parsing is
>>> tolerant, then it's tolerant for that change. Some other change may not
>>> be implemented that way and the parsing won't be tolerant. So we'll be
>>> inconsistent.
>>>
>>> I'm sure we're already inconsistent in this regard, so that doesn't
>>> worry me. The schema defines the rules. If you follow them, you know
>>> what you'll get. If you break them, maybe it will work anyway, maybe
>>> not. Our only guarantee if you break the rules is you'll either end up
>>> with a valid running configuration or we'll fail.
>>>
>>> On 4/23/15 10:17 AM, Darran Lofthouse wrote:
>>>> Thinking about future XML changes, once the parser is forked I think we
>>>> can also relax how we add new optional attributes and elements to the
>>>> schema.
>>>>
>>>> As I see it our main commitment is: -
>>>>
>>>> * XML that is valid according to the schema should parse without error. *
>>>>
>>>> I say 'should' as I believe in some cases documentation is relied upon
>>>> to describe valid combinations.
>>>>
>>>> * The XML we write must be valid according to the schema. *
>>>>
>>>> Don't see any justification for not following that one.
>>>>
>>>> * Parsers can be tolerant to XML that is technically invalid. *
>>>>
>>>> e.g. we are not big on enforcing sequence ordering.
>>>>
>>>> So lets say we have a release that contains a 4.0 version of the schema
>>>> I think if in version 4.1 of the schema we add an optional attribute or
>>>> element we can just add support for that attribute or element to the
>>>> existing parse method.
>>>>
>>>> Of course if the new attribute or element is required then we will need
>>>> to switch to something version specific to avoid rejecting previously
>>>> valid configuration.
>>>>
>>>> I know this is a long way off but I only raise this now as I realise
>>>> this has already happened where a new optional element has been added to
>>>> the schema.  Technically if we were strict about it the code is wrong
>>>> but the scenarios where it is going to break for someone are quite
>>>> contrived and I think this fits with tolerant parsing and we will
>>>> automatically fix on the next write.
>>>>
>>>> Regards,
>>>> Darran Lofthouse.
>>>>
>>>>
>>>> On 22/04/15 13:30, Brian Stansberry wrote:
>>>>> That's fine with me.
>>>>>
>>>>> On 4/22/15 6:20 AM, Darran Lofthouse wrote:
>>>>>> Working with the parsers for the core config has become increasingly
>>>>>> cryptic, we are now at the point where we have three different major
>>>>>> versions which diverge and converge as we work on them.  Most recent
>>>>>> changes have resulted in large sections of the config converging for 1.x
>>>>>> and 3.x leaving 2.x independent.
>>>>>>
>>>>>> So that I can add references to Elytron I am starting to add support for
>>>>>> version 4.
>>>>>>
>>>>>> One think that I have learned is that each major version tends to belong
>>>>>> to one branch of the codebase, all changes to that version happen on
>>>>>> that branch first: -
>>>>>>
>>>>>>         1.x - Maintained only for EAP
>>>>>>         2.x - WildFly 8.x branch
>>>>>>         3.x - WildFly Core master branch
>>>>>>
>>>>>> I would expect if further changes are made to core for WildFly 9
>>>>>> releases we will end up with 1.x branch of core and and 4.x version of
>>>>>> the schema will be owned by the master branch.
>>>>>>
>>>>>> To make things less cryptic I am proposing that until we find a better
>>>>>> solution for all subsequent major schema versions we just fork the
>>>>>> parser and all related classes.
>>>>>>
>>>>>> This will simplify the code being modified for the upstream development.
>>>>>>
>>>>>> Forward porting parsing changes will also become a simple copy and paste.
>>>>>>
>>>>>> For the current cryptic approach I think almost every engineer (and I am
>>>>>> finding it really hard to think of exceptions) that has worked in-depth
>>>>>> in this area has introduced at least one bug and I don't think the test
>>>>>> coverage is high enough to protect against this.
>>>>>>
>>>>>> Regards,
>>>>>> Darran Lofthouse.
>>>>>>
>>>>>> _______________________________________________
>>>>>> wildfly-dev mailing list
>>>>>> wildfly-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From brian.stansberry at redhat.com  Tue Apr 28 11:23:20 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 28 Apr 2015 10:23:20 -0500
Subject: [wildfly-dev] Management Parser Versioning
In-Reply-To: <553FA161.9080604@jboss.com>
References: <553783E5.3010204@jboss.com>	<5537944C.9090602@redhat.com>	<55390D13.3020706@jboss.com>	<553910A6.9060909@redhat.com>	<553911C2.8010706@jboss.com>	<553E604D.7040207@jboss.com>
	<553FA161.9080604@jboss.com>
Message-ID: <553FA5E8.2040601@redhat.com>

On 4/28/15 10:04 AM, Darran Lofthouse wrote:
> The following commit covers the WildFly side: -
>
> https://github.com/darranl/wildfly/commit/8fc073eb11b71904d6235381ad2d3903ce3241aa
>
> One problem with the current split is that as soon as you add a new
> management schema to core the integration with wildfly is broken
> immediately as some tests verify we write as version 3 when now we write
> as version 4.
>

What tests?

If full tests are validating core concerns, we need to move that 
validation to core, or drop it if it is redundant.

> I would suggest that as soon as we start development on WildFly 10 we
> create a very fast tag or core with just a few changes, probably just: -
>    - Bump to Java 8
>    - This schema version bump in this thread.
>    - Any other build tweaks needed for Java 8.
>
> WildFly can then use the new tag and have the same treatment.
>
> Regards,
> Darran Lofthouse.
>
>
> On 27/04/15 17:14, Darran Lofthouse wrote:
>> The following commits are now the end result of the re-factoring to
>> allow a fork on new major versions and also to add version 4.0 of the
>> schema: -
>>
>> https://github.com/wildfly/wildfly-core/compare/f4a07f4e9b41dc59823fea1813f947c67965525a...58faefb1fa830d0193f862da9958b2541aea7dad
>>
>> The changes look extensive but TBH the bulk is just moving of existing
>> code and some duplicate for the fork for 4.
>>
>> I have distinct commits to show the steps taken but the key points are: -
>>
>> # Split out the model specific parsing from CommonXml into smaller
>> implementations, this was to allow CommonXml to remain the common base
>> without still containing version specific parsing.
>>
>> # Rework of ManagementXml to be version based and rework the delegate,
>> the big problem we had was we were looping back on ourselves with static
>> calls which did not cleanly map to versioned implementations.
>>
>> # Moved existing StandalonXml, HostXml, DomainXml, ManagementXml into
>> 'Legacy' parsers and used existing class to load these on-demand.
>>
>> # Forked the legacy parsers to create the version 4 parsers, removed all
>> version handling so a clean start for 4.
>>
>> At this point there is still plenty of parsing code not forked for 4 but
>> TBH those are all relatively stable and rarely change, StandaloneXml,
>> HostXml, DomainXml, and ManagementXml on the other hand have changed for
>> every major version so far.
>>
>> Regards,
>> Darran Lofthouse.
>>
>> On 23/04/15 16:37, Darran Lofthouse wrote:
>>> On 23/04/15 16:32, Brian Stansberry wrote:
>>>> I don't think I've ever rejected or even questioned a PR because it made
>>>> a parser tolerant in the way you describe, so I'm fine with being tolerant.
>>>
>>> +1 I think the first two rules are what we need to advertise we support,
>>> after all that is why we have schemas.  The third point is more about
>>> the requirements being placed on the maintainer of the parser so if your
>>> XML does not match the schema the best we say is "It may work, it may
>>> not work and that can change without warning".
>>>
>>>> My only caveat is in no way do we have any commitment to be tolerant. If
>>>> a change is implemented in such a way that the legacy schema parsing is
>>>> tolerant, then it's tolerant for that change. Some other change may not
>>>> be implemented that way and the parsing won't be tolerant. So we'll be
>>>> inconsistent.
>>>>
>>>> I'm sure we're already inconsistent in this regard, so that doesn't
>>>> worry me. The schema defines the rules. If you follow them, you know
>>>> what you'll get. If you break them, maybe it will work anyway, maybe
>>>> not. Our only guarantee if you break the rules is you'll either end up
>>>> with a valid running configuration or we'll fail.
>>>>
>>>> On 4/23/15 10:17 AM, Darran Lofthouse wrote:
>>>>> Thinking about future XML changes, once the parser is forked I think we
>>>>> can also relax how we add new optional attributes and elements to the
>>>>> schema.
>>>>>
>>>>> As I see it our main commitment is: -
>>>>>
>>>>> * XML that is valid according to the schema should parse without error. *
>>>>>
>>>>> I say 'should' as I believe in some cases documentation is relied upon
>>>>> to describe valid combinations.
>>>>>
>>>>> * The XML we write must be valid according to the schema. *
>>>>>
>>>>> Don't see any justification for not following that one.
>>>>>
>>>>> * Parsers can be tolerant to XML that is technically invalid. *
>>>>>
>>>>> e.g. we are not big on enforcing sequence ordering.
>>>>>
>>>>> So lets say we have a release that contains a 4.0 version of the schema
>>>>> I think if in version 4.1 of the schema we add an optional attribute or
>>>>> element we can just add support for that attribute or element to the
>>>>> existing parse method.
>>>>>
>>>>> Of course if the new attribute or element is required then we will need
>>>>> to switch to something version specific to avoid rejecting previously
>>>>> valid configuration.
>>>>>
>>>>> I know this is a long way off but I only raise this now as I realise
>>>>> this has already happened where a new optional element has been added to
>>>>> the schema.  Technically if we were strict about it the code is wrong
>>>>> but the scenarios where it is going to break for someone are quite
>>>>> contrived and I think this fits with tolerant parsing and we will
>>>>> automatically fix on the next write.
>>>>>
>>>>> Regards,
>>>>> Darran Lofthouse.
>>>>>
>>>>>
>>>>> On 22/04/15 13:30, Brian Stansberry wrote:
>>>>>> That's fine with me.
>>>>>>
>>>>>> On 4/22/15 6:20 AM, Darran Lofthouse wrote:
>>>>>>> Working with the parsers for the core config has become increasingly
>>>>>>> cryptic, we are now at the point where we have three different major
>>>>>>> versions which diverge and converge as we work on them.  Most recent
>>>>>>> changes have resulted in large sections of the config converging for 1.x
>>>>>>> and 3.x leaving 2.x independent.
>>>>>>>
>>>>>>> So that I can add references to Elytron I am starting to add support for
>>>>>>> version 4.
>>>>>>>
>>>>>>> One think that I have learned is that each major version tends to belong
>>>>>>> to one branch of the codebase, all changes to that version happen on
>>>>>>> that branch first: -
>>>>>>>
>>>>>>>          1.x - Maintained only for EAP
>>>>>>>          2.x - WildFly 8.x branch
>>>>>>>          3.x - WildFly Core master branch
>>>>>>>
>>>>>>> I would expect if further changes are made to core for WildFly 9
>>>>>>> releases we will end up with 1.x branch of core and and 4.x version of
>>>>>>> the schema will be owned by the master branch.
>>>>>>>
>>>>>>> To make things less cryptic I am proposing that until we find a better
>>>>>>> solution for all subsequent major schema versions we just fork the
>>>>>>> parser and all related classes.
>>>>>>>
>>>>>>> This will simplify the code being modified for the upstream development.
>>>>>>>
>>>>>>> Forward porting parsing changes will also become a simple copy and paste.
>>>>>>>
>>>>>>> For the current cryptic approach I think almost every engineer (and I am
>>>>>>> finding it really hard to think of exceptions) that has worked in-depth
>>>>>>> in this area has introduced at least one bug and I don't think the test
>>>>>>> coverage is high enough to protect against this.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Darran Lofthouse.
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> wildfly-dev mailing list
>>>>>>> wildfly-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>
>>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


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

From darran.lofthouse at jboss.com  Tue Apr 28 11:44:37 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Tue, 28 Apr 2015 16:44:37 +0100
Subject: [wildfly-dev] Management Parser Versioning
In-Reply-To: <553FA5E8.2040601@redhat.com>
References: <553783E5.3010204@jboss.com>	<5537944C.9090602@redhat.com>	<55390D13.3020706@jboss.com>	<553910A6.9060909@redhat.com>	<553911C2.8010706@jboss.com>	<553E604D.7040207@jboss.com>	<553FA161.9080604@jboss.com>
	<553FA5E8.2040601@redhat.com>
Message-ID: <553FAAE5.7040700@jboss.com>

StandardConfigsXMLValidationUnitTestCase - I have not dug into why it is 
failing but when I update all configs to use version 4 it is back to 
passing.

On 28/04/15 16:23, Brian Stansberry wrote:
> On 4/28/15 10:04 AM, Darran Lofthouse wrote:
>> The following commit covers the WildFly side: -
>>
>> https://github.com/darranl/wildfly/commit/8fc073eb11b71904d6235381ad2d3903ce3241aa
>>
>> One problem with the current split is that as soon as you add a new
>> management schema to core the integration with wildfly is broken
>> immediately as some tests verify we write as version 3 when now we write
>> as version 4.
>>
>
> What tests?
>
> If full tests are validating core concerns, we need to move that
> validation to core, or drop it if it is redundant.
>
>> I would suggest that as soon as we start development on WildFly 10 we
>> create a very fast tag or core with just a few changes, probably just: -
>>     - Bump to Java 8
>>     - This schema version bump in this thread.
>>     - Any other build tweaks needed for Java 8.
>>
>> WildFly can then use the new tag and have the same treatment.
>>
>> Regards,
>> Darran Lofthouse.
>>
>>
>> On 27/04/15 17:14, Darran Lofthouse wrote:
>>> The following commits are now the end result of the re-factoring to
>>> allow a fork on new major versions and also to add version 4.0 of the
>>> schema: -
>>>
>>> https://github.com/wildfly/wildfly-core/compare/f4a07f4e9b41dc59823fea1813f947c67965525a...58faefb1fa830d0193f862da9958b2541aea7dad
>>>
>>> The changes look extensive but TBH the bulk is just moving of existing
>>> code and some duplicate for the fork for 4.
>>>
>>> I have distinct commits to show the steps taken but the key points are: -
>>>
>>> # Split out the model specific parsing from CommonXml into smaller
>>> implementations, this was to allow CommonXml to remain the common base
>>> without still containing version specific parsing.
>>>
>>> # Rework of ManagementXml to be version based and rework the delegate,
>>> the big problem we had was we were looping back on ourselves with static
>>> calls which did not cleanly map to versioned implementations.
>>>
>>> # Moved existing StandalonXml, HostXml, DomainXml, ManagementXml into
>>> 'Legacy' parsers and used existing class to load these on-demand.
>>>
>>> # Forked the legacy parsers to create the version 4 parsers, removed all
>>> version handling so a clean start for 4.
>>>
>>> At this point there is still plenty of parsing code not forked for 4 but
>>> TBH those are all relatively stable and rarely change, StandaloneXml,
>>> HostXml, DomainXml, and ManagementXml on the other hand have changed for
>>> every major version so far.
>>>
>>> Regards,
>>> Darran Lofthouse.
>>>
>>> On 23/04/15 16:37, Darran Lofthouse wrote:
>>>> On 23/04/15 16:32, Brian Stansberry wrote:
>>>>> I don't think I've ever rejected or even questioned a PR because it made
>>>>> a parser tolerant in the way you describe, so I'm fine with being tolerant.
>>>>
>>>> +1 I think the first two rules are what we need to advertise we support,
>>>> after all that is why we have schemas.  The third point is more about
>>>> the requirements being placed on the maintainer of the parser so if your
>>>> XML does not match the schema the best we say is "It may work, it may
>>>> not work and that can change without warning".
>>>>
>>>>> My only caveat is in no way do we have any commitment to be tolerant. If
>>>>> a change is implemented in such a way that the legacy schema parsing is
>>>>> tolerant, then it's tolerant for that change. Some other change may not
>>>>> be implemented that way and the parsing won't be tolerant. So we'll be
>>>>> inconsistent.
>>>>>
>>>>> I'm sure we're already inconsistent in this regard, so that doesn't
>>>>> worry me. The schema defines the rules. If you follow them, you know
>>>>> what you'll get. If you break them, maybe it will work anyway, maybe
>>>>> not. Our only guarantee if you break the rules is you'll either end up
>>>>> with a valid running configuration or we'll fail.
>>>>>
>>>>> On 4/23/15 10:17 AM, Darran Lofthouse wrote:
>>>>>> Thinking about future XML changes, once the parser is forked I think we
>>>>>> can also relax how we add new optional attributes and elements to the
>>>>>> schema.
>>>>>>
>>>>>> As I see it our main commitment is: -
>>>>>>
>>>>>> * XML that is valid according to the schema should parse without error. *
>>>>>>
>>>>>> I say 'should' as I believe in some cases documentation is relied upon
>>>>>> to describe valid combinations.
>>>>>>
>>>>>> * The XML we write must be valid according to the schema. *
>>>>>>
>>>>>> Don't see any justification for not following that one.
>>>>>>
>>>>>> * Parsers can be tolerant to XML that is technically invalid. *
>>>>>>
>>>>>> e.g. we are not big on enforcing sequence ordering.
>>>>>>
>>>>>> So lets say we have a release that contains a 4.0 version of the schema
>>>>>> I think if in version 4.1 of the schema we add an optional attribute or
>>>>>> element we can just add support for that attribute or element to the
>>>>>> existing parse method.
>>>>>>
>>>>>> Of course if the new attribute or element is required then we will need
>>>>>> to switch to something version specific to avoid rejecting previously
>>>>>> valid configuration.
>>>>>>
>>>>>> I know this is a long way off but I only raise this now as I realise
>>>>>> this has already happened where a new optional element has been added to
>>>>>> the schema.  Technically if we were strict about it the code is wrong
>>>>>> but the scenarios where it is going to break for someone are quite
>>>>>> contrived and I think this fits with tolerant parsing and we will
>>>>>> automatically fix on the next write.
>>>>>>
>>>>>> Regards,
>>>>>> Darran Lofthouse.
>>>>>>
>>>>>>
>>>>>> On 22/04/15 13:30, Brian Stansberry wrote:
>>>>>>> That's fine with me.
>>>>>>>
>>>>>>> On 4/22/15 6:20 AM, Darran Lofthouse wrote:
>>>>>>>> Working with the parsers for the core config has become increasingly
>>>>>>>> cryptic, we are now at the point where we have three different major
>>>>>>>> versions which diverge and converge as we work on them.  Most recent
>>>>>>>> changes have resulted in large sections of the config converging for 1.x
>>>>>>>> and 3.x leaving 2.x independent.
>>>>>>>>
>>>>>>>> So that I can add references to Elytron I am starting to add support for
>>>>>>>> version 4.
>>>>>>>>
>>>>>>>> One think that I have learned is that each major version tends to belong
>>>>>>>> to one branch of the codebase, all changes to that version happen on
>>>>>>>> that branch first: -
>>>>>>>>
>>>>>>>>           1.x - Maintained only for EAP
>>>>>>>>           2.x - WildFly 8.x branch
>>>>>>>>           3.x - WildFly Core master branch
>>>>>>>>
>>>>>>>> I would expect if further changes are made to core for WildFly 9
>>>>>>>> releases we will end up with 1.x branch of core and and 4.x version of
>>>>>>>> the schema will be owned by the master branch.
>>>>>>>>
>>>>>>>> To make things less cryptic I am proposing that until we find a better
>>>>>>>> solution for all subsequent major schema versions we just fork the
>>>>>>>> parser and all related classes.
>>>>>>>>
>>>>>>>> This will simplify the code being modified for the upstream development.
>>>>>>>>
>>>>>>>> Forward porting parsing changes will also become a simple copy and paste.
>>>>>>>>
>>>>>>>> For the current cryptic approach I think almost every engineer (and I am
>>>>>>>> finding it really hard to think of exceptions) that has worked in-depth
>>>>>>>> in this area has introduced at least one bug and I don't think the test
>>>>>>>> coverage is high enough to protect against this.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Darran Lofthouse.
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> wildfly-dev mailing list
>>>>>>>> wildfly-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> wildfly-dev mailing list
>>>>>> wildfly-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>

From brian.stansberry at redhat.com  Tue Apr 28 12:18:04 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 28 Apr 2015 11:18:04 -0500
Subject: [wildfly-dev] Management Parser Versioning
In-Reply-To: <553FAAE5.7040700@jboss.com>
References: <553783E5.3010204@jboss.com>	<5537944C.9090602@redhat.com>	<55390D13.3020706@jboss.com>	<553910A6.9060909@redhat.com>	<553911C2.8010706@jboss.com>	<553E604D.7040207@jboss.com>	<553FA161.9080604@jboss.com>	<553FA5E8.2040601@redhat.com>
	<553FAAE5.7040700@jboss.com>
Message-ID: <553FB2BC.8070804@redhat.com>

Thanks. That test is specifically checking that the standard configs are 
using the latest xsd, so yeah, it will fail whenever a core snapshot 
bumps the xsd versions. I was hoping it was some static thing we could 
make smarter, but it seems not.

A hack would be to make the test more lenient if system prop 
version.org.wildfly.core ends with "-SNAPSHOT". The PR to update core 
would still need to fix the full configs, but that's less of a problem.

On 4/28/15 10:44 AM, Darran Lofthouse wrote:
> StandardConfigsXMLValidationUnitTestCase - I have not dug into why it is
> failing but when I update all configs to use version 4 it is back to
> passing.
>
> On 28/04/15 16:23, Brian Stansberry wrote:
>> On 4/28/15 10:04 AM, Darran Lofthouse wrote:
>>> The following commit covers the WildFly side: -
>>>
>>> https://github.com/darranl/wildfly/commit/8fc073eb11b71904d6235381ad2d3903ce3241aa
>>>
>>> One problem with the current split is that as soon as you add a new
>>> management schema to core the integration with wildfly is broken
>>> immediately as some tests verify we write as version 3 when now we write
>>> as version 4.
>>>
>>
>> What tests?
>>
>> If full tests are validating core concerns, we need to move that
>> validation to core, or drop it if it is redundant.
>>
>>> I would suggest that as soon as we start development on WildFly 10 we
>>> create a very fast tag or core with just a few changes, probably just: -
>>>      - Bump to Java 8
>>>      - This schema version bump in this thread.
>>>      - Any other build tweaks needed for Java 8.
>>>
>>> WildFly can then use the new tag and have the same treatment.
>>>
>>> Regards,
>>> Darran Lofthouse.
>>>
>>>
>>> On 27/04/15 17:14, Darran Lofthouse wrote:
>>>> The following commits are now the end result of the re-factoring to
>>>> allow a fork on new major versions and also to add version 4.0 of the
>>>> schema: -
>>>>
>>>> https://github.com/wildfly/wildfly-core/compare/f4a07f4e9b41dc59823fea1813f947c67965525a...58faefb1fa830d0193f862da9958b2541aea7dad
>>>>
>>>> The changes look extensive but TBH the bulk is just moving of existing
>>>> code and some duplicate for the fork for 4.
>>>>
>>>> I have distinct commits to show the steps taken but the key points are: -
>>>>
>>>> # Split out the model specific parsing from CommonXml into smaller
>>>> implementations, this was to allow CommonXml to remain the common base
>>>> without still containing version specific parsing.
>>>>
>>>> # Rework of ManagementXml to be version based and rework the delegate,
>>>> the big problem we had was we were looping back on ourselves with static
>>>> calls which did not cleanly map to versioned implementations.
>>>>
>>>> # Moved existing StandalonXml, HostXml, DomainXml, ManagementXml into
>>>> 'Legacy' parsers and used existing class to load these on-demand.
>>>>
>>>> # Forked the legacy parsers to create the version 4 parsers, removed all
>>>> version handling so a clean start for 4.
>>>>
>>>> At this point there is still plenty of parsing code not forked for 4 but
>>>> TBH those are all relatively stable and rarely change, StandaloneXml,
>>>> HostXml, DomainXml, and ManagementXml on the other hand have changed for
>>>> every major version so far.
>>>>
>>>> Regards,
>>>> Darran Lofthouse.
>>>>
>>>> On 23/04/15 16:37, Darran Lofthouse wrote:
>>>>> On 23/04/15 16:32, Brian Stansberry wrote:
>>>>>> I don't think I've ever rejected or even questioned a PR because it made
>>>>>> a parser tolerant in the way you describe, so I'm fine with being tolerant.
>>>>>
>>>>> +1 I think the first two rules are what we need to advertise we support,
>>>>> after all that is why we have schemas.  The third point is more about
>>>>> the requirements being placed on the maintainer of the parser so if your
>>>>> XML does not match the schema the best we say is "It may work, it may
>>>>> not work and that can change without warning".
>>>>>
>>>>>> My only caveat is in no way do we have any commitment to be tolerant. If
>>>>>> a change is implemented in such a way that the legacy schema parsing is
>>>>>> tolerant, then it's tolerant for that change. Some other change may not
>>>>>> be implemented that way and the parsing won't be tolerant. So we'll be
>>>>>> inconsistent.
>>>>>>
>>>>>> I'm sure we're already inconsistent in this regard, so that doesn't
>>>>>> worry me. The schema defines the rules. If you follow them, you know
>>>>>> what you'll get. If you break them, maybe it will work anyway, maybe
>>>>>> not. Our only guarantee if you break the rules is you'll either end up
>>>>>> with a valid running configuration or we'll fail.
>>>>>>
>>>>>> On 4/23/15 10:17 AM, Darran Lofthouse wrote:
>>>>>>> Thinking about future XML changes, once the parser is forked I think we
>>>>>>> can also relax how we add new optional attributes and elements to the
>>>>>>> schema.
>>>>>>>
>>>>>>> As I see it our main commitment is: -
>>>>>>>
>>>>>>> * XML that is valid according to the schema should parse without error. *
>>>>>>>
>>>>>>> I say 'should' as I believe in some cases documentation is relied upon
>>>>>>> to describe valid combinations.
>>>>>>>
>>>>>>> * The XML we write must be valid according to the schema. *
>>>>>>>
>>>>>>> Don't see any justification for not following that one.
>>>>>>>
>>>>>>> * Parsers can be tolerant to XML that is technically invalid. *
>>>>>>>
>>>>>>> e.g. we are not big on enforcing sequence ordering.
>>>>>>>
>>>>>>> So lets say we have a release that contains a 4.0 version of the schema
>>>>>>> I think if in version 4.1 of the schema we add an optional attribute or
>>>>>>> element we can just add support for that attribute or element to the
>>>>>>> existing parse method.
>>>>>>>
>>>>>>> Of course if the new attribute or element is required then we will need
>>>>>>> to switch to something version specific to avoid rejecting previously
>>>>>>> valid configuration.
>>>>>>>
>>>>>>> I know this is a long way off but I only raise this now as I realise
>>>>>>> this has already happened where a new optional element has been added to
>>>>>>> the schema.  Technically if we were strict about it the code is wrong
>>>>>>> but the scenarios where it is going to break for someone are quite
>>>>>>> contrived and I think this fits with tolerant parsing and we will
>>>>>>> automatically fix on the next write.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Darran Lofthouse.
>>>>>>>
>>>>>>>
>>>>>>> On 22/04/15 13:30, Brian Stansberry wrote:
>>>>>>>> That's fine with me.
>>>>>>>>
>>>>>>>> On 4/22/15 6:20 AM, Darran Lofthouse wrote:
>>>>>>>>> Working with the parsers for the core config has become increasingly
>>>>>>>>> cryptic, we are now at the point where we have three different major
>>>>>>>>> versions which diverge and converge as we work on them.  Most recent
>>>>>>>>> changes have resulted in large sections of the config converging for 1.x
>>>>>>>>> and 3.x leaving 2.x independent.
>>>>>>>>>
>>>>>>>>> So that I can add references to Elytron I am starting to add support for
>>>>>>>>> version 4.
>>>>>>>>>
>>>>>>>>> One think that I have learned is that each major version tends to belong
>>>>>>>>> to one branch of the codebase, all changes to that version happen on
>>>>>>>>> that branch first: -
>>>>>>>>>
>>>>>>>>>            1.x - Maintained only for EAP
>>>>>>>>>            2.x - WildFly 8.x branch
>>>>>>>>>            3.x - WildFly Core master branch
>>>>>>>>>
>>>>>>>>> I would expect if further changes are made to core for WildFly 9
>>>>>>>>> releases we will end up with 1.x branch of core and and 4.x version of
>>>>>>>>> the schema will be owned by the master branch.
>>>>>>>>>
>>>>>>>>> To make things less cryptic I am proposing that until we find a better
>>>>>>>>> solution for all subsequent major schema versions we just fork the
>>>>>>>>> parser and all related classes.
>>>>>>>>>
>>>>>>>>> This will simplify the code being modified for the upstream development.
>>>>>>>>>
>>>>>>>>> Forward porting parsing changes will also become a simple copy and paste.
>>>>>>>>>
>>>>>>>>> For the current cryptic approach I think almost every engineer (and I am
>>>>>>>>> finding it really hard to think of exceptions) that has worked in-depth
>>>>>>>>> in this area has introduced at least one bug and I don't think the test
>>>>>>>>> coverage is high enough to protect against this.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Darran Lofthouse.
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> wildfly-dev mailing list
>>>>>>>>> wildfly-dev at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> wildfly-dev mailing list
>>>>>>> wildfly-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>
> _______________________________________________
> 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 arjan.tijms at gmail.com  Tue Apr 28 12:26:39 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Tue, 28 Apr 2015 18:26:39 +0200
Subject: [wildfly-dev] WildFly leaking sockets when response not fully read
	when using AJP
Message-ID: <CAE=-AhCg-bxRT0-zD2iCw6o9HppFFjAm24Fxdj3CNstVfqZWqA@mail.gmail.com>

Hi,

I've encountered an issue where WildFly/Undertow is leaking a large number
of sockets when a (misbehaving) client does not fully read the response.

I've filed an issue for this here:
https://issues.jboss.org/browse/UNDERTOW-427

But I wonder if anyone else has encountered anything like this?

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

From darran.lofthouse at jboss.com  Tue Apr 28 12:33:17 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Tue, 28 Apr 2015 17:33:17 +0100
Subject: [wildfly-dev] Management Parser Versioning
In-Reply-To: <553FB2BC.8070804@redhat.com>
References: <553783E5.3010204@jboss.com>	<5537944C.9090602@redhat.com>	<55390D13.3020706@jboss.com>	<553910A6.9060909@redhat.com>	<553911C2.8010706@jboss.com>	<553E604D.7040207@jboss.com>	<553FA161.9080604@jboss.com>	<553FA5E8.2040601@redhat.com>	<553FAAE5.7040700@jboss.com>
	<553FB2BC.8070804@redhat.com>
Message-ID: <553FB64D.2000204@jboss.com>

On 28/04/15 17:18, Brian Stansberry wrote:
> Thanks. That test is specifically checking that the standard configs are
> using the latest xsd, so yeah, it will fail whenever a core snapshot
> bumps the xsd versions. I was hoping it was some static thing we could
> make smarter, but it seems not.
>
> A hack would be to make the test more lenient if system prop
> version.org.wildfly.core ends with "-SNAPSHOT". The PR to update core
> would still need to fix the full configs, but that's less of a problem.

I think this is going to be a rare issue, an early tag of core should be 
sufficient to cover this.

> On 4/28/15 10:44 AM, Darran Lofthouse wrote:
>> StandardConfigsXMLValidationUnitTestCase - I have not dug into why it is
>> failing but when I update all configs to use version 4 it is back to
>> passing.
>>
>> On 28/04/15 16:23, Brian Stansberry wrote:
>>> On 4/28/15 10:04 AM, Darran Lofthouse wrote:
>>>> The following commit covers the WildFly side: -
>>>>
>>>> https://github.com/darranl/wildfly/commit/8fc073eb11b71904d6235381ad2d3903ce3241aa
>>>>
>>>> One problem with the current split is that as soon as you add a new
>>>> management schema to core the integration with wildfly is broken
>>>> immediately as some tests verify we write as version 3 when now we write
>>>> as version 4.
>>>>
>>>
>>> What tests?
>>>
>>> If full tests are validating core concerns, we need to move that
>>> validation to core, or drop it if it is redundant.
>>>
>>>> I would suggest that as soon as we start development on WildFly 10 we
>>>> create a very fast tag or core with just a few changes, probably just: -
>>>>       - Bump to Java 8
>>>>       - This schema version bump in this thread.
>>>>       - Any other build tweaks needed for Java 8.
>>>>
>>>> WildFly can then use the new tag and have the same treatment.
>>>>
>>>> Regards,
>>>> Darran Lofthouse.
>>>>
>>>>
>>>> On 27/04/15 17:14, Darran Lofthouse wrote:
>>>>> The following commits are now the end result of the re-factoring to
>>>>> allow a fork on new major versions and also to add version 4.0 of the
>>>>> schema: -
>>>>>
>>>>> https://github.com/wildfly/wildfly-core/compare/f4a07f4e9b41dc59823fea1813f947c67965525a...58faefb1fa830d0193f862da9958b2541aea7dad
>>>>>
>>>>> The changes look extensive but TBH the bulk is just moving of existing
>>>>> code and some duplicate for the fork for 4.
>>>>>
>>>>> I have distinct commits to show the steps taken but the key points are: -
>>>>>
>>>>> # Split out the model specific parsing from CommonXml into smaller
>>>>> implementations, this was to allow CommonXml to remain the common base
>>>>> without still containing version specific parsing.
>>>>>
>>>>> # Rework of ManagementXml to be version based and rework the delegate,
>>>>> the big problem we had was we were looping back on ourselves with static
>>>>> calls which did not cleanly map to versioned implementations.
>>>>>
>>>>> # Moved existing StandalonXml, HostXml, DomainXml, ManagementXml into
>>>>> 'Legacy' parsers and used existing class to load these on-demand.
>>>>>
>>>>> # Forked the legacy parsers to create the version 4 parsers, removed all
>>>>> version handling so a clean start for 4.
>>>>>
>>>>> At this point there is still plenty of parsing code not forked for 4 but
>>>>> TBH those are all relatively stable and rarely change, StandaloneXml,
>>>>> HostXml, DomainXml, and ManagementXml on the other hand have changed for
>>>>> every major version so far.
>>>>>
>>>>> Regards,
>>>>> Darran Lofthouse.
>>>>>
>>>>> On 23/04/15 16:37, Darran Lofthouse wrote:
>>>>>> On 23/04/15 16:32, Brian Stansberry wrote:
>>>>>>> I don't think I've ever rejected or even questioned a PR because it made
>>>>>>> a parser tolerant in the way you describe, so I'm fine with being tolerant.
>>>>>>
>>>>>> +1 I think the first two rules are what we need to advertise we support,
>>>>>> after all that is why we have schemas.  The third point is more about
>>>>>> the requirements being placed on the maintainer of the parser so if your
>>>>>> XML does not match the schema the best we say is "It may work, it may
>>>>>> not work and that can change without warning".
>>>>>>
>>>>>>> My only caveat is in no way do we have any commitment to be tolerant. If
>>>>>>> a change is implemented in such a way that the legacy schema parsing is
>>>>>>> tolerant, then it's tolerant for that change. Some other change may not
>>>>>>> be implemented that way and the parsing won't be tolerant. So we'll be
>>>>>>> inconsistent.
>>>>>>>
>>>>>>> I'm sure we're already inconsistent in this regard, so that doesn't
>>>>>>> worry me. The schema defines the rules. If you follow them, you know
>>>>>>> what you'll get. If you break them, maybe it will work anyway, maybe
>>>>>>> not. Our only guarantee if you break the rules is you'll either end up
>>>>>>> with a valid running configuration or we'll fail.
>>>>>>>
>>>>>>> On 4/23/15 10:17 AM, Darran Lofthouse wrote:
>>>>>>>> Thinking about future XML changes, once the parser is forked I think we
>>>>>>>> can also relax how we add new optional attributes and elements to the
>>>>>>>> schema.
>>>>>>>>
>>>>>>>> As I see it our main commitment is: -
>>>>>>>>
>>>>>>>> * XML that is valid according to the schema should parse without error. *
>>>>>>>>
>>>>>>>> I say 'should' as I believe in some cases documentation is relied upon
>>>>>>>> to describe valid combinations.
>>>>>>>>
>>>>>>>> * The XML we write must be valid according to the schema. *
>>>>>>>>
>>>>>>>> Don't see any justification for not following that one.
>>>>>>>>
>>>>>>>> * Parsers can be tolerant to XML that is technically invalid. *
>>>>>>>>
>>>>>>>> e.g. we are not big on enforcing sequence ordering.
>>>>>>>>
>>>>>>>> So lets say we have a release that contains a 4.0 version of the schema
>>>>>>>> I think if in version 4.1 of the schema we add an optional attribute or
>>>>>>>> element we can just add support for that attribute or element to the
>>>>>>>> existing parse method.
>>>>>>>>
>>>>>>>> Of course if the new attribute or element is required then we will need
>>>>>>>> to switch to something version specific to avoid rejecting previously
>>>>>>>> valid configuration.
>>>>>>>>
>>>>>>>> I know this is a long way off but I only raise this now as I realise
>>>>>>>> this has already happened where a new optional element has been added to
>>>>>>>> the schema.  Technically if we were strict about it the code is wrong
>>>>>>>> but the scenarios where it is going to break for someone are quite
>>>>>>>> contrived and I think this fits with tolerant parsing and we will
>>>>>>>> automatically fix on the next write.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Darran Lofthouse.
>>>>>>>>
>>>>>>>>
>>>>>>>> On 22/04/15 13:30, Brian Stansberry wrote:
>>>>>>>>> That's fine with me.
>>>>>>>>>
>>>>>>>>> On 4/22/15 6:20 AM, Darran Lofthouse wrote:
>>>>>>>>>> Working with the parsers for the core config has become increasingly
>>>>>>>>>> cryptic, we are now at the point where we have three different major
>>>>>>>>>> versions which diverge and converge as we work on them.  Most recent
>>>>>>>>>> changes have resulted in large sections of the config converging for 1.x
>>>>>>>>>> and 3.x leaving 2.x independent.
>>>>>>>>>>
>>>>>>>>>> So that I can add references to Elytron I am starting to add support for
>>>>>>>>>> version 4.
>>>>>>>>>>
>>>>>>>>>> One think that I have learned is that each major version tends to belong
>>>>>>>>>> to one branch of the codebase, all changes to that version happen on
>>>>>>>>>> that branch first: -
>>>>>>>>>>
>>>>>>>>>>             1.x - Maintained only for EAP
>>>>>>>>>>             2.x - WildFly 8.x branch
>>>>>>>>>>             3.x - WildFly Core master branch
>>>>>>>>>>
>>>>>>>>>> I would expect if further changes are made to core for WildFly 9
>>>>>>>>>> releases we will end up with 1.x branch of core and and 4.x version of
>>>>>>>>>> the schema will be owned by the master branch.
>>>>>>>>>>
>>>>>>>>>> To make things less cryptic I am proposing that until we find a better
>>>>>>>>>> solution for all subsequent major schema versions we just fork the
>>>>>>>>>> parser and all related classes.
>>>>>>>>>>
>>>>>>>>>> This will simplify the code being modified for the upstream development.
>>>>>>>>>>
>>>>>>>>>> Forward porting parsing changes will also become a simple copy and paste.
>>>>>>>>>>
>>>>>>>>>> For the current cryptic approach I think almost every engineer (and I am
>>>>>>>>>> finding it really hard to think of exceptions) that has worked in-depth
>>>>>>>>>> in this area has introduced at least one bug and I don't think the test
>>>>>>>>>> coverage is high enough to protect against this.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Darran Lofthouse.
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> wildfly-dev mailing list
>>>>>>>>>> wildfly-dev at lists.jboss.org
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> wildfly-dev mailing list
>>>>>>>> wildfly-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> wildfly-dev mailing list
>>>>>> wildfly-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>

From jmesnil at redhat.com  Wed Apr 29 10:00:18 2015
From: jmesnil at redhat.com (Jeff Mesnil)
Date: Wed, 29 Apr 2015 16:00:18 +0200
Subject: [wildfly-dev] Management operation for legacy subsystem migration
Message-ID: <6FD54261-C452-4839-9795-FCDDC18D8BCC@redhat.com>

With WildFly 9 and 10, we will have new subsystems that will replace some older subsystems (called legacy subsystems below).

We have to deal with migrating these subsystems:

* migrate from web (JBoss Web)     to undertow
* migrate from messaging (HornetQ) to messaging-activemq (with Apache ActiveMQ Artemis)
* migrate from jacorb              to iiop-openjdk

These 3 tasks are about providing a management operation to perform one-time migration (i.e. the migration is an operation performed by the server on its management model).

I have started to look at this from the messaging perspective.

To constrain this task, I have added some requirements:

1. the legacy subsystem must be an empty shell and has no runtime
=> in WildFLy 10, /subsystem=messaging is only exposing its management model but there is no runtime (HornetQ server library is not included)
2. the server must be in admin-only mode during migration
=> the server is not serving any client during migration.
=> the migration deals only with the server management model by creating the model for the new subsystem based on the legacy subsystem's model
3. Data are not moved during this migration operation
=> moving messages from HornetQ to ActiveMQ destinations is not performed during this management migration.
=> we already have process (such as using JMS bridges) to move messages from one messaging provider to another

Having these three requirements simplifies the migration task and sounds reasonable.
Do you foresee any issues with having them?
 
Given these requirements, the legacy subsystem would need to expose a :migrate operation (at the root of the subsystem) to perform the actual migration of the management model.

Its pseudo code would be something like:

* check the server is in admin-only mode
defined any child resource)
* :describe the legacy subsystem model
* transform the legacy subsystem description to the new subsystem
=> if everything is successful
  * create a composite operation to add the new messaging-activemq extension and all the transformed :add operations
  * report the composite operation outcome to the user
=> else
  * report the error(s) to the user

It is possible that the legacy subsystem can not be fully migrated (e.g. if it defines an attribute that has no equivalent on the new subsystem). In that case, the :migrate operation reports the error(s) to the user.
The user can then change the legacy subsystem model to remove the problematic resource/attributes and invoke :migrate again

For the messaging subsystem, I expect that it will not be possible to fully migrate the replication configuration of the legacy subsystem to the new subsystem (the configuration has significantly changed between HornetQ and ActiveMQ, some configuration will be incompatible).
In that case, I'd expect the user to migrate to the new messaging-activemq subsystem by discarding the legacy subsystem's replication configuration, invoke :migrate and then configure replication for the new subsystem.

In my proof of concept, the :migrate operation has a dry-run boolean attribute. If set to true, the operation will not run the composite operation. It will instead return to the user the list of operations that will be executed when the :migrate operation is actually performed.

I have talked to Tomek which is charge of the iiop migration and he has an additional requirement to emulate the legacy jacorb subsystem with the new iioop-openjdk subsystem. I have not this requirement for the messaging subsystem so I have not given much thought about it...
Same goes for the web -> undertow migration.

It's also important to note that this operation to migrate the management model of a legacy subsystem to a new one is only one step of the whole migration story.
For messaging, the workflow to upgrade an WFLY 9 server to WFLY 10 is made of several other steps (and I may have forgotten some)

* install the new server
* copy the old configuration (with the legacy messaging subsystem)
* start the new server in admin-only mode
* invoke /subsystem=messaging:migrate
  => rinse and repeat by tweaking the legacy subsystem until the migration is successful
* if migration of data can be done offline, do it now (the server is in admin-only mode, so it's ok)
* reload the server to return to running mode with the new messaging subsystem
* if the migration of data must be done offline, it can be done now
  (e.g. create a new JMS bridge from the old running WFLY9/messaging server to this new WFLY10/messaging-activemq server)
* if everything is fine, invoke /subsystem=messaging:remove to remote the legacy subsystem model.

Any comment, critic, feedback?

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



From brian.stansberry at redhat.com  Wed Apr 29 10:58:07 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 29 Apr 2015 09:58:07 -0500
Subject: [wildfly-dev] Management operation for legacy subsystem
	migration
In-Reply-To: <6FD54261-C452-4839-9795-FCDDC18D8BCC@redhat.com>
References: <6FD54261-C452-4839-9795-FCDDC18D8BCC@redhat.com>
Message-ID: <5540F17F.3040408@redhat.com>

On 4/29/15 9:00 AM, Jeff Mesnil wrote:
> With WildFly 9 and 10, we will have new subsystems that will replace some older subsystems (called legacy subsystems below).
>
> We have to deal with migrating these subsystems:
>
> * migrate from web (JBoss Web)     to undertow
> * migrate from messaging (HornetQ) to messaging-activemq (with Apache ActiveMQ Artemis)
> * migrate from jacorb              to iiop-openjdk
>
> These 3 tasks are about providing a management operation to perform one-time migration (i.e. the migration is an operation performed by the server on its management model).
>
> I have started to look at this from the messaging perspective.
>
> To constrain this task, I have added some requirements:
>
> 1. the legacy subsystem must be an empty shell and has no runtime
> => in WildFLy 10, /subsystem=messaging is only exposing its management model but there is no runtime (HornetQ server library is not included)

I don't see why this needs to be a requirement. In the jacorb case, it 
will be violated, as the jacorb subsystem can run as a kind of 
"compatibility subsystem", delegating to the iiop-openjdk runtime 
services as long as the config doesn't specify any settings that can't 
be translated.

> 2. the server must be in admin-only mode during migration
> => the server is not serving any client during migration.
> => the migration deals only with the server management model by creating the model for the new subsystem based on the legacy subsystem's model

+1 for server

It would be very nice to say the same for the DC, but it's worth 
discussing. Requiring the DC to be in admin-only creates a fair bit of 
usability downside. The whole domain reacts when the DC goes away. Once 
we have automatic failover of the DC, it may result in the failover DC 
taking over, introducing other problems. (Ken Wills -- this is one to 
think about in general re: DC failover.)

It's possible we could allow a migration to happen on a profile where 
there aren't any servers running. The basic domain rollout behavior 
would allow this without any change. If the HCs allowed the migrate op 
to run, and then it gets rolled out to any affected servers, the servers 
will reject the op (as they aren't admin-only.) So the op will be rolled 
back. (Except in an extreme corner case where the user specifies a 
rollout plan that says all servers can fail.)

> 3. Data are not moved during this migration operation
> => moving messages from HornetQ to ActiveMQ destinations is not performed during this management migration.
> => we already have process (such as using JMS bridges) to move messages from one messaging provider to another

+1

>
> Having these three requirements simplifies the migration task and sounds reasonable.
> Do you foresee any issues with having them?
>
> Given these requirements, the legacy subsystem would need to expose a :migrate operation (at the root of the subsystem) to perform the actual migration of the management model.
>
> Its pseudo code would be something like:
>
> * check the server is in admin-only mode
> defined any child resource)
> * :describe the legacy subsystem model
> * transform the legacy subsystem description to the new subsystem
> => if everything is successful
>    * create a composite operation to add the new messaging-activemq extension and all the transformed :add operations
>    * report the composite operation outcome to the user
> => else
>    * report the error(s) to the user
>

There needs to be validation as to whether the extension is already 
present; if so skip the add.

This is an edge case on a server but is fairly likely on a DC, where the 
extension may be used in profile-new, and now the users wants to migrate 
the subsystem in profile-old.

Also, we're going to need to change how the "composite" op works, as 
including an extension=foo:add in the same composite as steps that touch 
its subsystems won't work. There's a JIRA for this, but JIRA doesn't 
seem to be responding at the moment.

There's a workaround for that issue if necessary; just have the migrate 
op add a step that deals with the extension add and then a next step 
with the composite.

> It is possible that the legacy subsystem can not be fully migrated (e.g. if it defines an attribute that has no equivalent on the new subsystem). In that case, the :migrate operation reports the error(s) to the user.
> The user can then change the legacy subsystem model to remove the problematic resource/attributes and invoke :migrate again
>
> For the messaging subsystem, I expect that it will not be possible to fully migrate the replication configuration of the legacy subsystem to the new subsystem (the configuration has significantly changed between HornetQ and ActiveMQ, some configuration will be incompatible).
> In that case, I'd expect the user to migrate to the new messaging-activemq subsystem by discarding the legacy subsystem's replication configuration, invoke :migrate and then configure replication for the new subsystem.
>
> In my proof of concept, the :migrate operation has a dry-run boolean attribute. If set to true, the operation will not run the composite operation. It will instead return to the user the list of operations that will be executed when the :migrate operation is actually performed.
>

The return value should be the same regardless of the value of that 
attribute. Ops have single return value description.

We need to be careful about RBAC. This basically amounts to one op that 
then convinces the server to do a whole bunch of other stuff.

A simple thing there is to just mark the op as sensitive. That's 
conservative but inelegant.

I don't think that's necessary though. The return value from this op is 
a bunch of steps. That provides a lot of data the user may not be 
authorized to see. But, to provide that data, you're going to do a lot 
of reads, and the access control layer will reject the reads if the user 
is not authorized. So the user shouldn't be able to use this to see data 
they shouldn't.

As for writes, if the users isn't authorized to do the writes, then they 
will fail.

> I have talked to Tomek which is charge of the iiop migration and he has an additional requirement to emulate the legacy jacorb subsystem with the new iioop-openjdk subsystem. I have not this requirement for the messaging subsystem so I have not given much thought about it...
> Same goes for the web -> undertow migration.
>

Oh, I should have read the whole thing before starting to reply!

> It's also important to note that this operation to migrate the management model of a legacy subsystem to a new one is only one step of the whole migration story.
> For messaging, the workflow to upgrade an WFLY 9 server to WFLY 10 is made of several other steps (and I may have forgotten some)
>
> * install the new server
> * copy the old configuration (with the legacy messaging subsystem)
> * start the new server in admin-only mode
> * invoke /subsystem=messaging:migrate
>    => rinse and repeat by tweaking the legacy subsystem until the migration is successful
> * if migration of data can be done offline, do it now (the server is in admin-only mode, so it's ok)
> * reload the server to return to running mode with the new messaging subsystem
> * if the migration of data must be done offline, it can be done now
>    (e.g. create a new JMS bridge from the old running WFLY9/messaging server to this new WFLY10/messaging-activemq server)
> * if everything is fine, invoke /subsystem=messaging:remove to remote the legacy subsystem model.
>
> Any comment, critic, feedback?
>

Sounds good. We need to think in general about the domain case.


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

From lfryc at redhat.com  Wed Apr 29 10:58:09 2015
From: lfryc at redhat.com (Lukas Fryc)
Date: Wed, 29 Apr 2015 16:58:09 +0200
Subject: [wildfly-dev] Embedded Arquillian Container
Message-ID: <CAAnALH=US8TS1zRbRC=HH9wv7JHPDVChM8GLtnbiZGy01sM+OQ@mail.gmail.com>

Hey guys,

just wondering if wildfly-arquillian-container-embedded was discontinued
with split of 9.x:

https://github.com/wildfly/wildfly-arquillian/blob/master/pom.xml#L96


When working on a re-enablement, I found out that even though arq adapter
now depends on wildfly-core/embedded, particularly
on EmbeddedServerFactory, this class has its counterpart in
wildfly/embedded as well.

Question is, should be embedded arquillian container still available for
9.x?

If yes, I can continue and provide a PR, just I will need a bit of guidance
with what EmbeddedServerFactory it should actually use (if that matters).


Cheers,

~ Lukas

--
Lukas Fryc
AeroGear Core Developer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150429/24fed695/attachment.html 

From tadamski at redhat.com  Wed Apr 29 16:09:57 2015
From: tadamski at redhat.com (Tomasz Adamski)
Date: Wed, 29 Apr 2015 16:09:57 -0400 (EDT)
Subject: [wildfly-dev] Management operation for legacy
	subsystem	migration
In-Reply-To: <5540F17F.3040408@redhat.com>
References: <6FD54261-C452-4839-9795-FCDDC18D8BCC@redhat.com>
	<5540F17F.3040408@redhat.com>
Message-ID: <1884593375.7291059.1430338197136.JavaMail.zimbra@redhat.com>

>From the iiop perspective:
Conversion between subsystems is fairy staightforward as they are very similiar. The problem is that the jacorb subsystem, from which :migrate operation is executed, has also a compatibility subsystem role. What is more it behaves differently in standalone and domain mode. Standalone subsystem emulates jacorb and as a result of that it checks that all properties can be emulated - it they can't the server won't start. On the other hand domain controller does not reject properties as it may send them to hosts with jacorb subsystem. So migrate operation in standalone mode works the way Jeff describe it but the "rinse and repeat" stage is moved to server startup. It has a runtime though. Migrate operation in domain mode requires discussion. Point 3 does not apply to iiop - no data is moved.

-- 
Tomasz Adamski
Software Engineer
JBoss by Red Hat 

----- Original Message -----
From: "Brian Stansberry" <brian.stansberry at redhat.com>
To: wildfly-dev at lists.jboss.org
Sent: Wednesday, April 29, 2015 4:58:07 PM
Subject: Re: [wildfly-dev] Management operation for legacy subsystem	migration

On 4/29/15 9:00 AM, Jeff Mesnil wrote:
> With WildFly 9 and 10, we will have new subsystems that will replace some older subsystems (called legacy subsystems below).
>
> We have to deal with migrating these subsystems:
>
> * migrate from web (JBoss Web)     to undertow
> * migrate from messaging (HornetQ) to messaging-activemq (with Apache ActiveMQ Artemis)
> * migrate from jacorb              to iiop-openjdk
>
> These 3 tasks are about providing a management operation to perform one-time migration (i.e. the migration is an operation performed by the server on its management model).
>
> I have started to look at this from the messaging perspective.
>
> To constrain this task, I have added some requirements:
>
> 1. the legacy subsystem must be an empty shell and has no runtime
> => in WildFLy 10, /subsystem=messaging is only exposing its management model but there is no runtime (HornetQ server library is not included)

I don't see why this needs to be a requirement. In the jacorb case, it 
will be violated, as the jacorb subsystem can run as a kind of 
"compatibility subsystem", delegating to the iiop-openjdk runtime 
services as long as the config doesn't specify any settings that can't 
be translated.

> 2. the server must be in admin-only mode during migration
> => the server is not serving any client during migration.
> => the migration deals only with the server management model by creating the model for the new subsystem based on the legacy subsystem's model

+1 for server

It would be very nice to say the same for the DC, but it's worth 
discussing. Requiring the DC to be in admin-only creates a fair bit of 
usability downside. The whole domain reacts when the DC goes away. Once 
we have automatic failover of the DC, it may result in the failover DC 
taking over, introducing other problems. (Ken Wills -- this is one to 
think about in general re: DC failover.)

It's possible we could allow a migration to happen on a profile where 
there aren't any servers running. The basic domain rollout behavior 
would allow this without any change. If the HCs allowed the migrate op 
to run, and then it gets rolled out to any affected servers, the servers 
will reject the op (as they aren't admin-only.) So the op will be rolled 
back. (Except in an extreme corner case where the user specifies a 
rollout plan that says all servers can fail.)

> 3. Data are not moved during this migration operation
> => moving messages from HornetQ to ActiveMQ destinations is not performed during this management migration.
> => we already have process (such as using JMS bridges) to move messages from one messaging provider to another

+1

>
> Having these three requirements simplifies the migration task and sounds reasonable.
> Do you foresee any issues with having them?
>
> Given these requirements, the legacy subsystem would need to expose a :migrate operation (at the root of the subsystem) to perform the actual migration of the management model.
>
> Its pseudo code would be something like:
>
> * check the server is in admin-only mode
> defined any child resource)
> * :describe the legacy subsystem model
> * transform the legacy subsystem description to the new subsystem
> => if everything is successful
>    * create a composite operation to add the new messaging-activemq extension and all the transformed :add operations
>    * report the composite operation outcome to the user
> => else
>    * report the error(s) to the user
>

There needs to be validation as to whether the extension is already 
present; if so skip the add.

This is an edge case on a server but is fairly likely on a DC, where the 
extension may be used in profile-new, and now the users wants to migrate 
the subsystem in profile-old.

Also, we're going to need to change how the "composite" op works, as 
including an extension=foo:add in the same composite as steps that touch 
its subsystems won't work. There's a JIRA for this, but JIRA doesn't 
seem to be responding at the moment.

There's a workaround for that issue if necessary; just have the migrate 
op add a step that deals with the extension add and then a next step 
with the composite.

> It is possible that the legacy subsystem can not be fully migrated (e.g. if it defines an attribute that has no equivalent on the new subsystem). In that case, the :migrate operation reports the error(s) to the user.
> The user can then change the legacy subsystem model to remove the problematic resource/attributes and invoke :migrate again
>
> For the messaging subsystem, I expect that it will not be possible to fully migrate the replication configuration of the legacy subsystem to the new subsystem (the configuration has significantly changed between HornetQ and ActiveMQ, some configuration will be incompatible).
> In that case, I'd expect the user to migrate to the new messaging-activemq subsystem by discarding the legacy subsystem's replication configuration, invoke :migrate and then configure replication for the new subsystem.
>
> In my proof of concept, the :migrate operation has a dry-run boolean attribute. If set to true, the operation will not run the composite operation. It will instead return to the user the list of operations that will be executed when the :migrate operation is actually performed.
>

The return value should be the same regardless of the value of that 
attribute. Ops have single return value description.

We need to be careful about RBAC. This basically amounts to one op that 
then convinces the server to do a whole bunch of other stuff.

A simple thing there is to just mark the op as sensitive. That's 
conservative but inelegant.

I don't think that's necessary though. The return value from this op is 
a bunch of steps. That provides a lot of data the user may not be 
authorized to see. But, to provide that data, you're going to do a lot 
of reads, and the access control layer will reject the reads if the user 
is not authorized. So the user shouldn't be able to use this to see data 
they shouldn't.

As for writes, if the users isn't authorized to do the writes, then they 
will fail.

> I have talked to Tomek which is charge of the iiop migration and he has an additional requirement to emulate the legacy jacorb subsystem with the new iioop-openjdk subsystem. I have not this requirement for the messaging subsystem so I have not given much thought about it...
> Same goes for the web -> undertow migration.
>

Oh, I should have read the whole thing before starting to reply!

> It's also important to note that this operation to migrate the management model of a legacy subsystem to a new one is only one step of the whole migration story.
> For messaging, the workflow to upgrade an WFLY 9 server to WFLY 10 is made of several other steps (and I may have forgotten some)
>
> * install the new server
> * copy the old configuration (with the legacy messaging subsystem)
> * start the new server in admin-only mode
> * invoke /subsystem=messaging:migrate
>    => rinse and repeat by tweaking the legacy subsystem until the migration is successful
> * if migration of data can be done offline, do it now (the server is in admin-only mode, so it's ok)
> * reload the server to return to running mode with the new messaging subsystem
> * if the migration of data must be done offline, it can be done now
>    (e.g. create a new JMS bridge from the old running WFLY9/messaging server to this new WFLY10/messaging-activemq server)
> * if everything is fine, invoke /subsystem=messaging:remove to remote the legacy subsystem model.
>
> Any comment, critic, feedback?
>

Sounds good. We need to think in general about the domain case.


-- 
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 jason.greene at redhat.com  Wed Apr 29 22:53:56 2015
From: jason.greene at redhat.com (Jason T. Greene)
Date: Wed, 29 Apr 2015 22:53:56 -0400 (EDT)
Subject: [wildfly-dev] Management operation for legacy subsystem
	migration
In-Reply-To: <6FD54261-C452-4839-9795-FCDDC18D8BCC@redhat.com>
References: <6FD54261-C452-4839-9795-FCDDC18D8BCC@redhat.com>
Message-ID: <5E0B3616-2473-4CBA-B591-BAC2F0DE073C@redhat.com>

Instead of hard errors, and manipulating the old model, wouldn't it be better to just convert and then report back in the response what was dropped? 

The outcome is the same right, but with just less steps.

If we are worried about config data loss or something like that, the dry run option cold be he default.

> On Apr 29, 2015, at 9:01 AM, Jeff Mesnil <jmesnil at redhat.com> wrote:
> 
> With WildFly 9 and 10, we will have new subsystems that will replace some older subsystems (called legacy subsystems below).
> 
> We have to deal with migrating these subsystems:
> 
> * migrate from web (JBoss Web)     to undertow
> * migrate from messaging (HornetQ) to messaging-activemq (with Apache ActiveMQ Artemis)
> * migrate from jacorb              to iiop-openjdk
> 
> These 3 tasks are about providing a management operation to perform one-time migration (i.e. the migration is an operation performed by the server on its management model).
> 
> I have started to look at this from the messaging perspective.
> 
> To constrain this task, I have added some requirements:
> 
> 1. the legacy subsystem must be an empty shell and has no runtime
> => in WildFLy 10, /subsystem=messaging is only exposing its management model but there is no runtime (HornetQ server library is not included)
> 2. the server must be in admin-only mode during migration
> => the server is not serving any client during migration.
> => the migration deals only with the server management model by creating the model for the new subsystem based on the legacy subsystem's model
> 3. Data are not moved during this migration operation
> => moving messages from HornetQ to ActiveMQ destinations is not performed during this management migration.
> => we already have process (such as using JMS bridges) to move messages from one messaging provider to another
> 
> Having these three requirements simplifies the migration task and sounds reasonable.
> Do you foresee any issues with having them?
> 
> Given these requirements, the legacy subsystem would need to expose a :migrate operation (at the root of the subsystem) to perform the actual migration of the management model.
> 
> Its pseudo code would be something like:
> 
> * check the server is in admin-only mode
> defined any child resource)
> * :describe the legacy subsystem model
> * transform the legacy subsystem description to the new subsystem
> => if everything is successful
>  * create a composite operation to add the new messaging-activemq extension and all the transformed :add operations
>  * report the composite operation outcome to the user
> => else
>  * report the error(s) to the user
> 
> It is possible that the legacy subsystem can not be fully migrated (e.g. if it defines an attribute that has no equivalent on the new subsystem). In that case, the :migrate operation reports the error(s) to the user.
> The user can then change the legacy subsystem model to remove the problematic resource/attributes and invoke :migrate again
> 
> For the messaging subsystem, I expect that it will not be possible to fully migrate the replication configuration of the legacy subsystem to the new subsystem (the configuration has significantly changed between HornetQ and ActiveMQ, some configuration will be incompatible).
> In that case, I'd expect the user to migrate to the new messaging-activemq subsystem by discarding the legacy subsystem's replication configuration, invoke :migrate and then configure replication for the new subsystem.
> 
> In my proof of concept, the :migrate operation has a dry-run boolean attribute. If set to true, the operation will not run the composite operation. It will instead return to the user the list of operations that will be executed when the :migrate operation is actually performed.
> 
> I have talked to Tomek which is charge of the iiop migration and he has an additional requirement to emulate the legacy jacorb subsystem with the new iioop-openjdk subsystem. I have not this requirement for the messaging subsystem so I have not given much thought about it...
> Same goes for the web -> undertow migration.
> 
> It's also important to note that this operation to migrate the management model of a legacy subsystem to a new one is only one step of the whole migration story.
> For messaging, the workflow to upgrade an WFLY 9 server to WFLY 10 is made of several other steps (and I may have forgotten some)
> 
> * install the new server
> * copy the old configuration (with the legacy messaging subsystem)
> * start the new server in admin-only mode
> * invoke /subsystem=messaging:migrate
>  => rinse and repeat by tweaking the legacy subsystem until the migration is successful
> * if migration of data can be done offline, do it now (the server is in admin-only mode, so it's ok)
> * reload the server to return to running mode with the new messaging subsystem
> * if the migration of data must be done offline, it can be done now
>  (e.g. create a new JMS bridge from the old running WFLY9/messaging server to this new WFLY10/messaging-activemq server)
> * if everything is fine, invoke /subsystem=messaging:remove to remote the legacy subsystem model.
> 
> Any comment, critic, feedback?
> 
> -- 
> Jeff Mesnil
> JBoss, a division of Red Hat
> http://jmesnil.net/
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From brian.stansberry at redhat.com  Thu Apr 30 09:47:27 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 30 Apr 2015 08:47:27 -0500
Subject: [wildfly-dev] Embedded Arquillian Container
In-Reply-To: <CAAnALH=US8TS1zRbRC=HH9wv7JHPDVChM8GLtnbiZGy01sM+OQ@mail.gmail.com>
References: <CAAnALH=US8TS1zRbRC=HH9wv7JHPDVChM8GLtnbiZGy01sM+OQ@mail.gmail.com>
Message-ID: <5542326F.6040602@redhat.com>

Hi Lukas,

On 4/29/15 9:58 AM, Lukas Fryc wrote:
> Hey guys,
>
> just wondering if wildfly-arquillian-container-embedded was discontinued
> with split of 9.x:
>
> https://github.com/wildfly/wildfly-arquillian/blob/master/pom.xml#L96
>

It was, yes, as wildfly-arquillian shouldn't depend on WildFly Full (to 
avoid a circular dependency) and WildFly Core didn't have an embedding 
module.
>
> When working on a re-enablement, I found out that even though arq
> adapter now depends on wildfly-core/embedded, particularly
> on EmbeddedServerFactory, this class has its counterpart in
> wildfly/embedded as well.
>

I added the wildfly-core/embedded module in order to support the Offline 
CLI.[1]  At this point I consider it to be an internal module, not 
public API. I expect that will soften over time, but for WildFly Core 
1.0 / WildFly Full 9.0 at least, that's what it is.

[1] http://wildfly.org/news/2015/03/13/Offline-CLI/

> Question is, should be embedded arquillian container still available for
> 9.x?
>

Jason Greene would need to rule on that, but I know we were ok with 
dropping it before. Is there much use of it?

> If yes, I can continue and provide a PR, just I will need a bit of
> guidance with what EmbeddedServerFactory it should actually use (if that
> matters).
>

What API would it need from wildfly-core/embedded? Is the 
StandaloneServer API there adequate?

>
> Cheers,
>
> ~ Lukas
>
> --
> Lukas Fryc
> AeroGear Core Developer
> 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 jmesnil at redhat.com  Thu Apr 30 10:03:59 2015
From: jmesnil at redhat.com (Jeff Mesnil)
Date: Thu, 30 Apr 2015 16:03:59 +0200
Subject: [wildfly-dev] Management operation for legacy subsystem
	migration
In-Reply-To: <5540F17F.3040408@redhat.com>
References: <6FD54261-C452-4839-9795-FCDDC18D8BCC@redhat.com>
	<5540F17F.3040408@redhat.com>
Message-ID: <6CE9420F-D2C7-4E83-8F00-E8FEBC06D1E6@redhat.com>

comments embedded.

> On 29 Apr 2015, at 16:58, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> 
> On 4/29/15 9:00 AM, Jeff Mesnil wrote:
>> With WildFly 9 and 10, we will have new subsystems that will replace some older subsystems (called legacy subsystems below).
>> 
>> We have to deal with migrating these subsystems:
>> 
>> * migrate from web (JBoss Web)     to undertow
>> * migrate from messaging (HornetQ) to messaging-activemq (with Apache ActiveMQ Artemis)
>> * migrate from jacorb              to iiop-openjdk
>> 
>> These 3 tasks are about providing a management operation to perform one-time migration (i.e. the migration is an operation performed by the server on its management model).
>> 
>> I have started to look at this from the messaging perspective.
>> 
>> To constrain this task, I have added some requirements:
>> 
>> 1. the legacy subsystem must be an empty shell and has no runtime
>> => in WildFLy 10, /subsystem=messaging is only exposing its management model but there is no runtime (HornetQ server library is not included)
> 
> I don't see why this needs to be a requirement. In the jacorb case, it 
> will be violated, as the jacorb subsystem can run as a kind of 
> "compatibility subsystem", delegating to the iiop-openjdk runtime 
> services as long as the config doesn't specify any settings that can't 
> be translated.

You are right, this is not a requirement. It?s specific to the legacy messaging subsystem and is not related to the generic migrate operation of legacy subsystem.
 
> There needs to be validation as to whether the extension is already 
> present; if so skip the add.
> 
> This is an edge case on a server but is fairly likely on a DC, where the 
> extension may be used in profile-new, and now the users wants to migrate 
> the subsystem in profile-old.

Ok, I?ll add this check.

> 
> Also, we're going to need to change how the "composite" op works, as 
> including an extension=foo:add in the same composite as steps that touch 
> its subsystems won't work. There's a JIRA for this, but JIRA doesn't 
> seem to be responding at the moment.
> 
> There's a workaround for that issue if necessary; just have the migrate 
> op add a step that deals with the extension add and then a next step 
> with the composite.

Ok, that?s what I did in my POC[1]. I was not sure if it was a bug or not.

The JIRA should be https://issues.jboss.org/browse/WFCORE-323.
You even used the messaging subsystem for its example :)

> 
>> It is possible that the legacy subsystem can not be fully migrated (e.g. if it defines an attribute that has no equivalent on the new subsystem). In that case, the :migrate operation reports the error(s) to the user.
>> The user can then change the legacy subsystem model to remove the problematic resource/attributes and invoke :migrate again
>> 
>> For the messaging subsystem, I expect that it will not be possible to fully migrate the replication configuration of the legacy subsystem to the new subsystem (the configuration has significantly changed between HornetQ and ActiveMQ, some configuration will be incompatible).
>> In that case, I'd expect the user to migrate to the new messaging-activemq subsystem by discarding the legacy subsystem's replication configuration, invoke :migrate and then configure replication for the new subsystem.
>> 
>> In my proof of concept, the :migrate operation has a dry-run boolean attribute. If set to true, the operation will not run the composite operation. It will instead return to the user the list of operations that will be executed when the :migrate operation is actually performed.
>> 
> 
> The return value should be the same regardless of the value of that 
> attribute. Ops have single return value description.

Good point. In that case, the :migrate operation will return the outcome of the migration operation.
And I can add a :describe-migration that lists the required operations.

> We need to be careful about RBAC. This basically amounts to one op that 
> then convinces the server to do a whole bunch of other stuff.

This :migrate operation is using the outcome of the :describe operation on the legacy subsystem (which has a READ_WHOLE_CONFIG access constraint) and execute :add operations.
Do we need to flag it specifically or are its constraints the byproduct of the :describe and :add operations constraints?

jeff

[1] https://github.com/jmesnil/wildfly/blob/messaging-activemq-xml/messaging/src/main/java/org/jboss/as/messaging/MigrateOperation.java#L119

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



From jmesnil at redhat.com  Thu Apr 30 10:08:52 2015
From: jmesnil at redhat.com (Jeff Mesnil)
Date: Thu, 30 Apr 2015 16:08:52 +0200
Subject: [wildfly-dev] Management operation for legacy subsystem
	migration
In-Reply-To: <5E0B3616-2473-4CBA-B591-BAC2F0DE073C@redhat.com>
References: <6FD54261-C452-4839-9795-FCDDC18D8BCC@redhat.com>
	<5E0B3616-2473-4CBA-B591-BAC2F0DE073C@redhat.com>
Message-ID: <6F363D95-FACA-4BCB-BB67-1B46485DDBE8@redhat.com>

On 30 Apr 2015, at 04:53, Jason T. Greene <jason.greene at redhat.com> wrote:
> 
> Instead of hard errors, and manipulating the old model, wouldn't it be better to just convert and then report back in the response what was dropped? 

I?m not sure to understand your remark. Could you clarify?

I don?t manipulate the old model. I describe it and use the description to create the :add operations for the new subsystem.

At first, I was reading the old model, manipulating it to create the new subsystem model and create a new Resource with that manipulated model.
It turns out to be a bad idea as I was bypassing any validation steps performed by the :add operations and ended up with an invalid new subsystem (that could not be loaded).

Using the ":describe + new :add operations" approach ensures that my new subsystem will be valid if my :migrate operation succeeds.

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



From brian.stansberry at redhat.com  Thu Apr 30 13:40:15 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 30 Apr 2015 12:40:15 -0500
Subject: [wildfly-dev] Management operation for legacy subsystem
	migration
In-Reply-To: <6CE9420F-D2C7-4E83-8F00-E8FEBC06D1E6@redhat.com>
References: <6FD54261-C452-4839-9795-FCDDC18D8BCC@redhat.com>
	<5540F17F.3040408@redhat.com>
	<6CE9420F-D2C7-4E83-8F00-E8FEBC06D1E6@redhat.com>
Message-ID: <554268FF.3080000@redhat.com>

On 4/30/15 9:03 AM, Jeff Mesnil wrote:
> comments embedded.
>
>> On 29 Apr 2015, at 16:58, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>
>> On 4/29/15 9:00 AM, Jeff Mesnil wrote:
>>> With WildFly 9 and 10, we will have new subsystems that will replace some older subsystems (called legacy subsystems below).
>>>
>>> We have to deal with migrating these subsystems:
>>>
>>> * migrate from web (JBoss Web)     to undertow
>>> * migrate from messaging (HornetQ) to messaging-activemq (with Apache ActiveMQ Artemis)
>>> * migrate from jacorb              to iiop-openjdk
>>>
>>> These 3 tasks are about providing a management operation to perform one-time migration (i.e. the migration is an operation performed by the server on its management model).
>>>
>>> I have started to look at this from the messaging perspective.
>>>
>>> To constrain this task, I have added some requirements:
>>>
>>> 1. the legacy subsystem must be an empty shell and has no runtime
>>> => in WildFLy 10, /subsystem=messaging is only exposing its management model but there is no runtime (HornetQ server library is not included)
>>
>> I don't see why this needs to be a requirement. In the jacorb case, it
>> will be violated, as the jacorb subsystem can run as a kind of
>> "compatibility subsystem", delegating to the iiop-openjdk runtime
>> services as long as the config doesn't specify any settings that can't
>> be translated.
>
> You are right, this is not a requirement. It?s specific to the legacy messaging subsystem and is not related to the generic migrate operation of legacy subsystem.
>
>> There needs to be validation as to whether the extension is already
>> present; if so skip the add.
>>
>> This is an edge case on a server but is fairly likely on a DC, where the
>> extension may be used in profile-new, and now the users wants to migrate
>> the subsystem in profile-old.
>
> Ok, I?ll add this check.
>
>>
>> Also, we're going to need to change how the "composite" op works, as
>> including an extension=foo:add in the same composite as steps that touch
>> its subsystems won't work. There's a JIRA for this, but JIRA doesn't
>> seem to be responding at the moment.
>>
>> There's a workaround for that issue if necessary; just have the migrate
>> op add a step that deals with the extension add and then a next step
>> with the composite.
>
> Ok, that?s what I did in my POC[1]. I was not sure if it was a bug or not.
>
> The JIRA should be https://issues.jboss.org/browse/WFCORE-323.
> You even used the messaging subsystem for its example :)
>
>>
>>> It is possible that the legacy subsystem can not be fully migrated (e.g. if it defines an attribute that has no equivalent on the new subsystem). In that case, the :migrate operation reports the error(s) to the user.
>>> The user can then change the legacy subsystem model to remove the problematic resource/attributes and invoke :migrate again
>>>
>>> For the messaging subsystem, I expect that it will not be possible to fully migrate the replication configuration of the legacy subsystem to the new subsystem (the configuration has significantly changed between HornetQ and ActiveMQ, some configuration will be incompatible).
>>> In that case, I'd expect the user to migrate to the new messaging-activemq subsystem by discarding the legacy subsystem's replication configuration, invoke :migrate and then configure replication for the new subsystem.
>>>
>>> In my proof of concept, the :migrate operation has a dry-run boolean attribute. If set to true, the operation will not run the composite operation. It will instead return to the user the list of operations that will be executed when the :migrate operation is actually performed.
>>>
>>
>> The return value should be the same regardless of the value of that
>> attribute. Ops have single return value description.
>
> Good point. In that case, the :migrate operation will return the outcome of the migration operation.

What would that be? If the describe-migration is a separate op, then I 
figure for this op, the response would be

{"outcome"=>"success","result"=>undefined}

> And I can add a :describe-migration that lists the required operations.
>
>> We need to be careful about RBAC. This basically amounts to one op that
>> then convinces the server to do a whole bunch of other stuff.
>
> This :migrate operation is using the outcome of the :describe operation on the legacy subsystem (which has a READ_WHOLE_CONFIG access constraint) and execute :add operations.
> Do we need to flag it specifically or are its constraints the byproduct of the :describe and :add operations constraints?
>

So this basically means these ops would be limited to SuperUser or 
Administrator (unless the users change the settings for READ_WHOLE_CONFIG.)

I'd forgotten that "describe" worked that way.

The constraints would be a byproduct, but we should flag the op anyway, 
otherwise it's unintuitive. The metadata for the op inform the user of 
the effective constraint. Plus if we're not careful the user may end up 
getting a failure message saying they aren't authorized to run the 
"describe" op when they didn't request that op.

> jeff
>
> [1] https://github.com/jmesnil/wildfly/blob/messaging-activemq-xml/messaging/src/main/java/org/jboss/as/messaging/MigrateOperation.java#L119
>


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

From daniel.kreuter85 at gmail.com  Thu Apr 30 13:57:03 2015
From: daniel.kreuter85 at gmail.com (Daniel Kreuter)
Date: Thu, 30 Apr 2015 19:57:03 +0200
Subject: [wildfly-dev] Embedded Arquillian Container
In-Reply-To: <5542326F.6040602@redhat.com>
References: <CAAnALH=US8TS1zRbRC=HH9wv7JHPDVChM8GLtnbiZGy01sM+OQ@mail.gmail.com>
	<5542326F.6040602@redhat.com>
Message-ID: <E6FD362C-8879-4C7E-8A33-C0A9B86EFDE5@gmail.com>

Hi,

> Am 30.04.2015 um 15:47 schrieb Brian Stansberry <brian.stansberry at redhat.com>:
> 
> 
> [1] http://wildfly.org/news/2015/03/13/Offline-CLI/ <http://wildfly.org/news/2015/03/13/Offline-CLI/>
> 
>> Question is, should be embedded arquillian container still available for
>> 9.x?
>> 
> 
> Jason Greene would need to rule on that, but I know we were ok with 
> dropping it before. Is there much use of it?

One thing I use the embedded module is for our jenkins build because we have no access to a managed or remote WildFly instance on that machine, so yeah I would like to see a working plugin for future versions of WildFly, otherwise I either need to drop my integration tests or stick with 8.2 instead.

Regards,

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

From jperkins at redhat.com  Thu Apr 30 14:05:19 2015
From: jperkins at redhat.com (James R. Perkins)
Date: Thu, 30 Apr 2015 11:05:19 -0700
Subject: [wildfly-dev] Embedded Arquillian Container
In-Reply-To: <E6FD362C-8879-4C7E-8A33-C0A9B86EFDE5@gmail.com>
References: <CAAnALH=US8TS1zRbRC=HH9wv7JHPDVChM8GLtnbiZGy01sM+OQ@mail.gmail.com>	<5542326F.6040602@redhat.com>
	<E6FD362C-8879-4C7E-8A33-C0A9B86EFDE5@gmail.com>
Message-ID: <55426EDF.10902@redhat.com>

If you're using maven you could download the wildfly-dist ZIP and unzip 
it into a directory. This would have the advantage of using the correct 
target runtime you're using too.

Example:
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
     <executions>
         <execution>
             <id>unpack-wildfly</id>
             <phase>process-test-classes</phase>
             <goals>
                 <goal>unpack</goal>
             </goals>
             <configuration>
                 <artifactItems>
                     <artifactItem>
<groupId>org.wildfly</groupId>
<artifactId>wildfly-dist</artifactId>
<version>${version.org.wildfly.dist}</version>
                         <type>zip</type>
                         <!-- overwrite to clean any previous 
deployments -->
<overWrite>true</overWrite>
<outputDirectory>${project.build.directory}</outputDirectory>
                     </artifactItem>
                 </artifactItems>
             </configuration>
         </execution>
     </executions>
</plugin>

On 04/30/2015 10:57 AM, Daniel Kreuter wrote:
> Hi,
>
>> Am 30.04.2015 um 15:47 schrieb Brian Stansberry 
>> <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>>:
>>
>>
>> [1]http://wildfly.org/news/2015/03/13/Offline-CLI/
>>
>>> Question is, should be embedded arquillian container still available for
>>> 9.x?
>>>
>>
>> Jason Greene would need to rule on that, but I know we were ok with
>> dropping it before. Is there much use of it?
>
> One thing I use the embedded module is for our jenkins build because 
> we have no access to a managed or remote WildFly instance on that 
> machine, so yeah I would like to see a working plugin for future 
> versions of WildFly, otherwise I either need to drop my integration 
> tests or stick with 8.2 instead.
>
> Regards,
>
> Daniel
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-- 
James R. Perkins
JBoss by Red Hat

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

From brian.stansberry at redhat.com  Thu Apr 30 14:06:15 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 30 Apr 2015 13:06:15 -0500
Subject: [wildfly-dev] Embedded Arquillian Container
In-Reply-To: <E6FD362C-8879-4C7E-8A33-C0A9B86EFDE5@gmail.com>
References: <CAAnALH=US8TS1zRbRC=HH9wv7JHPDVChM8GLtnbiZGy01sM+OQ@mail.gmail.com>
	<5542326F.6040602@redhat.com>
	<E6FD362C-8879-4C7E-8A33-C0A9B86EFDE5@gmail.com>
Message-ID: <55426F17.10901@redhat.com>

On 4/30/15 12:57 PM, Daniel Kreuter wrote:
> Hi,
>
>> Am 30.04.2015 um 15:47 schrieb Brian Stansberry
>> <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>>:
>>
>>
>> [1]http://wildfly.org/news/2015/03/13/Offline-CLI/
>>
>>> Question is, should be embedded arquillian container still available for
>>> 9.x?
>>>
>>
>> Jason Greene would need to rule on that, but I know we were ok with
>> dropping it before. Is there much use of it?
>
> One thing I use the embedded module is for our jenkins build because we
> have no access to a managed or remote WildFly instance on that machine,

I'm curious why not. A maven-based testsuite can spin up a managed 
container.

> so yeah I would like to see a working plugin for future versions of
> WildFly, otherwise I either need to drop my integration tests or stick
> with 8.2 instead.
>
> Regards,
>
> Daniel


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

From brian.stansberry at redhat.com  Thu Apr 30 14:21:41 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 30 Apr 2015 13:21:41 -0500
Subject: [wildfly-dev] Management operation for legacy
	subsystem	migration
In-Reply-To: <1884593375.7291059.1430338197136.JavaMail.zimbra@redhat.com>
References: <6FD54261-C452-4839-9795-FCDDC18D8BCC@redhat.com>	<5540F17F.3040408@redhat.com>
	<1884593375.7291059.1430338197136.JavaMail.zimbra@redhat.com>
Message-ID: <554272B5.4050705@redhat.com>

On 4/29/15 3:09 PM, Tomasz Adamski wrote:
>>From the iiop perspective:
> Conversion between subsystems is fairy staightforward as they are very similiar. The problem is that the jacorb subsystem, from which :migrate operation is executed, has also a compatibility subsystem role. What is more it behaves differently in standalone and domain mode. Standalone subsystem emulates jacorb and as a result of that it checks that all properties can be emulated - it they can't the server won't start. On the other hand domain controller does not reject properties as it may send them to hosts with jacorb subsystem. So migrate operation in standalone mode works the way Jeff describe it but the "rinse and repeat" stage is moved to server startup.

We could consider being more forgiving in admin-only mode; instead of 
failing, log ERROR messages. That gives the user the option to fix stuff.

It would be very good to be able to take an AS 7 / WF 8 / EAP 6 config 
and be able to bring it into compliance with WF 10 without having to use 
anything but the management API.

> It has a runtime though. Migrate operation in domain mode requires discussion. Point 3 does not apply to iiop - no data is moved.
>


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

From tadamski at redhat.com  Thu Apr 30 14:28:30 2015
From: tadamski at redhat.com (Tomasz Adamski)
Date: Thu, 30 Apr 2015 14:28:30 -0400 (EDT)
Subject: [wildfly-dev] Management operation for
	legacy	subsystem	migration
In-Reply-To: <554272B5.4050705@redhat.com>
References: <6FD54261-C452-4839-9795-FCDDC18D8BCC@redhat.com>
	<5540F17F.3040408@redhat.com>
	<1884593375.7291059.1430338197136.JavaMail.zimbra@redhat.com>
	<554272B5.4050705@redhat.com>
Message-ID: <608738433.7895840.1430418510116.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Brian Stansberry" <brian.stansberry at redhat.com>
> To: wildfly-dev at lists.jboss.org
> Sent: Thursday, April 30, 2015 8:21:41 PM
> Subject: Re: [wildfly-dev] Management operation for legacy	subsystem	migration
> 
> On 4/29/15 3:09 PM, Tomasz Adamski wrote:
> >>From the iiop perspective:
> > Conversion between subsystems is fairy staightforward as they are very
> > similiar. The problem is that the jacorb subsystem, from which :migrate
> > operation is executed, has also a compatibility subsystem role. What is
> > more it behaves differently in standalone and domain mode. Standalone
> > subsystem emulates jacorb and as a result of that it checks that all
> > properties can be emulated - it they can't the server won't start. On the
> > other hand domain controller does not reject properties as it may send
> > them to hosts with jacorb subsystem. So migrate operation in standalone
> > mode works the way Jeff describe it but the "rinse and repeat" stage is
> > moved to server startup.
> 
> We could consider being more forgiving in admin-only mode; instead of
> failing, log ERROR messages. That gives the user the option to fix stuff.
> 
> It would be very good to be able to take an AS 7 / WF 8 / EAP 6 config
> and be able to bring it into compliance with WF 10 without having to use
> anything but the management API.

OK. Will fix it.

> 
> > It has a runtime though. Migrate operation in domain mode requires
> > discussion. Point 3 does not apply to iiop - no data is moved.
> >
> 
> 
> --
> 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 jason.greene at redhat.com  Thu Apr 30 17:23:44 2015
From: jason.greene at redhat.com (Jason T. Greene)
Date: Thu, 30 Apr 2015 17:23:44 -0400 (EDT)
Subject: [wildfly-dev] Management operation for legacy subsystem
	migration
In-Reply-To: <6F363D95-FACA-4BCB-BB67-1B46485DDBE8@redhat.com>
References: <6FD54261-C452-4839-9795-FCDDC18D8BCC@redhat.com>
	<5E0B3616-2473-4CBA-B591-BAC2F0DE073C@redhat.com>
	<6F363D95-FACA-4BCB-BB67-1B46485DDBE8@redhat.com>
Message-ID: <E578CFDE-6834-40DF-868D-466478BE3611@redhat.com>



Sent from my iPhone

> On Apr 30, 2015, at 9:08 AM, Jeff Mesnil <jmesnil at redhat.com> wrote:
> 
>> On 30 Apr 2015, at 04:53, Jason T. Greene <jason.greene at redhat.com> wrote:
>> 
>> Instead of hard errors, and manipulating the old model, wouldn't it be better to just convert and then report back in the response what was dropped?
> 
> I?m not sure to understand your remark. Could you clarify?

Sorry I meant wouldn't it be better to skip/ignore configuration that does not have an equivalent mapping and report just warnings about what doesn't map. My point was that it's probably easier for the user to fixup the new subsystem  then it is to repeatedly alter the old subsystem until you get something that will convert.

> 
> I don?t manipulate the old model. I describe it and use the description to create the :add operations for the new subsystem.
> 
> At first, I was reading the old model, manipulating it to create the new subsystem model and create a new Resource with that manipulated model.
> It turns out to be a bad idea as I was bypassing any validation steps performed by the :add operations and ended up with an invalid new subsystem (that could not be loaded).
> 
> Using the ":describe + new :add operations" approach ensures that my new subsystem will be valid if my :migrate operation succeeds.
> 
> -- 
> Jeff Mesnil
> JBoss, a division of Red Hat
> http://jmesnil.net/
>