From stuart.w.douglas at gmail.com  Sun Mar  1 17:49:44 2015
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Sun, 01 Mar 2015 22:49:44 +0000
Subject: [wildfly-dev] Heads up on JBoss Logger 3.2 : more changed than
 what it looks like
References: <CAFm4XO2wnBqZywOkgDjhM=p-UDn6nintBpGS73PU+yPO_fSfgA@mail.gmail.com>
	<54F102D5.80005@redhat.com>
	<329392AD-687F-42F2-8BDE-4FE86C9751A7@gmail.com>
Message-ID: <CAAoo=c5Lm-Ze_DZgo6NeY0VxW9erLb1k9ZXm1wqJwcQD00_HCw@mail.gmail.com>

On Sun, 1 Mar 2015 at 02:32 Eduardo Sant'Ana da Silva <
eduardo.santanadasilva at gmail.com> wrote:

> I was wondering if just adding a new method to the BasicLogger interface
> could resolve the problem.
>
>
> *void* debugf(String format, *Integer* arg);
> *void* debugf(String format, *Long* arg);
>

This won't help. The issue is that method signatures are resolved at
compile time. If you add these new methods the compiler will use them, but
they are still not present in the older version, and you will have the same
problem.

Stuart


>
> Correct me if I'm wrong, but the problem reported was a collateral effect
> of the the addition of  :
>
> *   void* debugf(String format, *int *arg);
> *   void* debugf(String format, *long *arg);
>
>
> https://github.com/jboss-logging/jboss-logging/blob/master/src/main/java/org/jboss/logging/BasicLogger.java
>
> This was added last September, and with the additions of the Integer and
> Long types, the autoboxing will resolve our problems, and not cast will be
> necessary.
>
>
> *int* i = 123;
> bl.debugf( "Number: %d", i );
> >> *void* debugf(String format, *int* arg);
>
> *Integer* i = 123;
> bl.debugf( "Number: %d", i );
> *>> void* debugf(String format, Integer param1);
>
>
> Object i = *new* Integer(123);
> bl.debugf( "Number: %d", i );
> >> *void* debugf(String format, Object param1);
>
> (same thing to Long type)
>
>
> Since debugf methods are inherited from BasicLogger.
>
>
>
>
> On Feb 27, 2015, at 8:50 PM, James R. Perkins <jperkins at redhat.com> wrote:
>
> We faced some odd compile errors with JDK 7 when we switched WildFly
> Core to 3.2.1.Final. Really the only way to get around it would be to
> cast int's or long's to their object types. Though that's not really
> ideal either I realize.
>
> That said it should be fine in WildFly 9 as we're using 3.2.1.Final now.
>
> On 02/27/2015 12:08 PM, Sanne Grinovero wrote:
>
> Hi all,
> today I've upgraded jboss-logging from version 3.1.4.GA to 3.2.1.Final
> in an Hibernate project, and got some integration test failures.
>
> The surprising aspect is that everything seemed fine at compile level:
> just switch the version in the pom, and without needing any further
> changes it compiles fine and runs all unit tests successfully.. but
> fails when using the freshly built libraries in WildFly 8.2.
>
> It's not a regression of jboss-logging, but one of its improvements
> require a bit of attention.
>
> This is what happened to us:
> we have some log statements which look like this in source code (after
> simplifying):
>
>     int i = ...
>     log.debugf( "Number: %d", i );
>
> This does of course compile fine in both old an new versions of JBoss
> Logger. And it all works as expected in unit tests.
> But when deploying the modified version of this Hibernate library in
> WildFly 8.2, you'd get some of these:
>  - java.lang.NoSuchMethodError:
> org.hibernate.search.util.logging.impl.Log.debugf(Ljava/lang/String;J)V"}}
>
> When using the older version of JBoss Logger (at compile time), the
> above line of code is compiled as an invocation to:
>
>     void debugf(String format, Object param1);
>
> (which is a method present in both versions)
>
> When using the new version of JBoss Logger (at compile time), the same
> line of code is interpreted as the (better) invocation to:
>
>     void debugf(String format, int arg);
>
> So that's what the library is going to invoke at runtime - and that
> method doesn't exist in WildFly 8.2.
>
> Be aware of this when upgrading as it might look like a trivial
> version bump but it makes it quite hard to guarantee backwards
> compatibility with older versions of the logger.
>
> Personally since I want to upgrade the logger but don't want to drop
> compatibility with existing WildFly releases, I'm trying to figure how
> to reliably validate that no logging statement is going to invoke one
> of the new ones.. for now.
>
> I guess this also means that users won't actually benefit from the
> better performance of the new logging methods until we recompile all
> of its client libraries using the new version ;-)
> Auto-boxing is evil..
>
> Sanne
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> --
> James R. Perkins
> JBoss by Red Hat
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150301/2fb6bd1c/attachment.html 

From sanne at hibernate.org  Mon Mar  2 12:40:29 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 2 Mar 2015 17:40:29 +0000
Subject: [wildfly-dev] Heads up on JBoss Logger 3.2 : more changed than
 what it looks like
In-Reply-To: <CAAoo=c5Lm-Ze_DZgo6NeY0VxW9erLb1k9ZXm1wqJwcQD00_HCw@mail.gmail.com>
References: <CAFm4XO2wnBqZywOkgDjhM=p-UDn6nintBpGS73PU+yPO_fSfgA@mail.gmail.com>
	<54F102D5.80005@redhat.com>
	<329392AD-687F-42F2-8BDE-4FE86C9751A7@gmail.com>
	<CAAoo=c5Lm-Ze_DZgo6NeY0VxW9erLb1k9ZXm1wqJwcQD00_HCw@mail.gmail.com>
Message-ID: <CAFm4XO0krPkx5wBbKuQ3Zo3Ax2YFvqCRpWuWYiDyQUruqCwSVQ@mail.gmail.com>

Hi Eduardo,
thanks but really it's not an issue at all.

My email was just to warn to not upgrade Logger in a project which
still needs compatibility with WildFly 8 - as even if it looks like as
simple as changing the version in some build script, there is more
going on.

Sanne

On 1 March 2015 at 22:49, Stuart Douglas <stuart.w.douglas at gmail.com> wrote:
>
>
> On Sun, 1 Mar 2015 at 02:32 Eduardo Sant'Ana da Silva
> <eduardo.santanadasilva at gmail.com> wrote:
>>
>> I was wondering if just adding a new method to the BasicLogger interface
>> could resolve the problem.
>>
>>
>>
>> void debugf(String format, Integer arg);
>> void debugf(String format, Long arg);
>
>
> This won't help. The issue is that method signatures are resolved at compile
> time. If you add these new methods the compiler will use them, but they are
> still not present in the older version, and you will have the same problem.
>
> Stuart
>
>>
>>
>> Correct me if I'm wrong, but the problem reported was a collateral effect
>> of the the addition of  :
>>
>>    void debugf(String format, int arg);
>>    void debugf(String format, long arg);
>>
>>
>> https://github.com/jboss-logging/jboss-logging/blob/master/src/main/java/org/jboss/logging/BasicLogger.java
>>
>> This was added last September, and with the additions of the Integer and
>> Long types, the autoboxing will resolve our problems, and not cast will be
>> necessary.
>>
>>
>> int i = 123;
>> bl.debugf( "Number: %d", i );
>> >> void debugf(String format, int arg);
>>
>> Integer i = 123;
>> bl.debugf( "Number: %d", i );
>> >> void debugf(String format, Integer param1);
>>
>>
>> Object i = new Integer(123);
>> bl.debugf( "Number: %d", i );
>> >> void debugf(String format, Object param1);
>>
>> (same thing to Long type)
>>
>>
>> Since debugf methods are inherited from BasicLogger.
>>
>>
>>
>>
>> On Feb 27, 2015, at 8:50 PM, James R. Perkins <jperkins at redhat.com> wrote:
>>
>> We faced some odd compile errors with JDK 7 when we switched WildFly
>> Core to 3.2.1.Final. Really the only way to get around it would be to
>> cast int's or long's to their object types. Though that's not really
>> ideal either I realize.
>>
>> That said it should be fine in WildFly 9 as we're using 3.2.1.Final now.
>>
>> On 02/27/2015 12:08 PM, Sanne Grinovero wrote:
>>
>> Hi all,
>> today I've upgraded jboss-logging from version 3.1.4.GA to 3.2.1.Final
>> in an Hibernate project, and got some integration test failures.
>>
>> The surprising aspect is that everything seemed fine at compile level:
>> just switch the version in the pom, and without needing any further
>> changes it compiles fine and runs all unit tests successfully.. but
>> fails when using the freshly built libraries in WildFly 8.2.
>>
>> It's not a regression of jboss-logging, but one of its improvements
>> require a bit of attention.
>>
>> This is what happened to us:
>> we have some log statements which look like this in source code (after
>> simplifying):
>>
>>     int i = ...
>>     log.debugf( "Number: %d", i );
>>
>> This does of course compile fine in both old an new versions of JBoss
>> Logger. And it all works as expected in unit tests.
>> But when deploying the modified version of this Hibernate library in
>> WildFly 8.2, you'd get some of these:
>>  - java.lang.NoSuchMethodError:
>> org.hibernate.search.util.logging.impl.Log.debugf(Ljava/lang/String;J)V"}}
>>
>> When using the older version of JBoss Logger (at compile time), the
>> above line of code is compiled as an invocation to:
>>
>>     void debugf(String format, Object param1);
>>
>> (which is a method present in both versions)
>>
>> When using the new version of JBoss Logger (at compile time), the same
>> line of code is interpreted as the (better) invocation to:
>>
>>     void debugf(String format, int arg);
>>
>> So that's what the library is going to invoke at runtime - and that
>> method doesn't exist in WildFly 8.2.
>>
>> Be aware of this when upgrading as it might look like a trivial
>> version bump but it makes it quite hard to guarantee backwards
>> compatibility with older versions of the logger.
>>
>> Personally since I want to upgrade the logger but don't want to drop
>> compatibility with existing WildFly releases, I'm trying to figure how
>> to reliably validate that no logging statement is going to invoke one
>> of the new ones.. for now.
>>
>> I guess this also means that users won't actually benefit from the
>> better performance of the new logging methods until we recompile all
>> of its client libraries using the new version ;-)
>> Auto-boxing is evil..
>>
>> Sanne
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>> --
>> James R. Perkins
>> JBoss by Red Hat
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

From bbaranow at redhat.com  Thu Mar  5 02:41:11 2015
From: bbaranow at redhat.com (Bartosz Baranowski)
Date: Thu, 5 Mar 2015 02:41:11 -0500 (EST)
Subject: [wildfly-dev] WFCORE - ClassIndex vs ClassReflectionIndex - why
	there are two?
In-Reply-To: <671544142.19307466.1425541200475.JavaMail.zimbra@redhat.com>
Message-ID: <1766062643.19307612.1425541271655.JavaMail.zimbra@redhat.com>

Hi

As per subject, why there are two different classes like those two?

From wfink at redhat.com  Mon Mar  9 10:25:32 2015
From: wfink at redhat.com (Wolf-Dieter Fink)
Date: Mon, 09 Mar 2015 15:25:32 +0100
Subject: [wildfly-dev] WFLY-2422 or simplifying the remote outbound
 connection configuration for server to server communication
Message-ID: <54FDAD5C.2030600@redhat.com>

I start a request for simplifying the configuration for "in EE 
application" clients and get rid of extra cluster configuration and 
repeat properties many times.
Also the client should not need to have knowledge about the server 
topology, there is no need to know how many servers there are or whether 
they are clustered or not.

Starting point in EAP6/WF8 is a application configuration like this:
https://github.com/wildfly/quickstart/blob/master/ejb-multi-server/app-main/ear/src/main/application/META-INF/jboss-ejb-client.xml?

and a server side configuration like this:
             <subsystem xmlns="urn:jboss:domain:remoting:3.0">
                 <endpoint worker="default"/>
                 <http-connector name="http-remoting-connector" 
connector-ref="default" security-realm="ApplicationRealm"/>
                 <outbound-connections>
                     <remote-outbound-connection 
name="remote-ejb-connection-1" 
outbound-socket-binding-ref="remote-ejb-1" username="quickuser1" 
security-realm="ejb-security-realm-1" protocol="http-remoting">
                         <properties>
                             <property name="SASL_POLICY_NOANONYMOUS" 
value="false"/>
                             <property name="SSL_ENABLED" value="false"/>
                         </properties>
                     </remote-outbound-connection>
                     <remote-outbound-connection 
name="remote-ejb-connection-2" 
outbound-socket-binding-ref="remote-ejb-2" username="quickuser2" 
security-realm="ejb-security-realm-2" protocol="http-remoting">
                         <properties>
                             <property name="SASL_POLICY_NOANONYMOUS" 
value="false"/>
                             <property name="SSL_ENABLED" value="false"/>
                         </properties>
                     </remote-outbound-connection>
                 </outbound-connections>
             </subsystem>



Tomasz did some refactoring (WF9) to use a profile from the application 
perspective. The configuration is like this:

jboss-ejb-client.xml
     <client-context>
         <profile name="main-app"/>
     </client-context>

server profile:
                 <remote connector-ref="http-remoting-connector" 
thread-pool-name="default">
                     <profiles>
                         <profile name="main-app">
                             <remoting-ejb-receiver name="AppOneA" 
outbound-connection-ref="remote-ejb-connection-1"/>
                             <remoting-ejb-receiver name="AppTwoA" 
outbound-connection-ref="remote-ejb-connection-2"/>
                         </profile>
                     </profiles>
                 </remote>
....
             <subsystem xmlns="urn:jboss:domain:remoting:3.0">
                 <outbound-connections>
                     <remote-outbound-connection 
name="remote-ejb-connection-1" 
outbound-socket-binding-ref="remote-ejb-1" username="quickuser1" 
security-realm="ejb-security-realm-1" protocol="http-remoting">
                         <properties>
                             <property name="SASL_POLICY_NOANONYMOUS" 
value="false"/>
                             <property name="SSL_ENABLED" value="false"/>
                         </properties>
                     </remote-outbound-connection>
                     <remote-outbound-connection 
name="remote-ejb-connection-2" 
outbound-socket-binding-ref="remote-ejb-2" username="quickuser2" 
security-realm="ejb-security-realm-2" protocol="http-remoting">
                         <properties>
                             <property name="SASL_POLICY_NOANONYMOUS" 
value="false"/>
                             <property name="SSL_ENABLED" value="false"/>
                         </properties>
                     </remote-outbound-connection>
                 </outbound-connections>
             </subsystem>


With the current implementation there are some issues or 
concerns/enhancements
- profile does not work with clusters
- not possible to have multiple profiles
- the properties/user must be still repeated



 From my point of view
- a cluster need to have the same property configuration, also different 
users make no sense. Might work, but at least the cluster view will use 
the same user
- a similar group of servers for the same application should not have 
different properties/users as this will be error prone
- configuration should be as small and intuitive as possible

My initial idea was to have a jboss-ejb-client.xml which reference 
'applications' to connect, that is similar to profiles
The server side as followed (don't care about the exact XML elements or 
names)

             <subsystem xmlns="urn:jboss:domain:remoting:3.0">
                 <outbound-connections>
                     <profile name="App1" username="quickuser1" 
security-realm="ejb-security-realm-1" protocol="http-remoting">
                         <properties>
                             <property name="SASL_POLICY_NOANONYMOUS" 
value="false"/>
                             <property name="SSL_ENABLED" value="false"/>
                         </properties>
<outbound-sockets>remote-ejb-1,remote-ejb2</outbound-sockets> <!-- 
repeated elements seems better -->
                     </remote-outbound-connection>
                     <remote-outbound-connection 
name="remote-ejb-connection-X" 
outbound-socket-binding-ref="remote-ejb-X" username="quickuser2" 
security-realm="ejb-security-realm-2" protocol="http-remoting">
                         <properties>
                             <property name="SASL_POLICY_NOANONYMOUS" 
value="false"/>
                             <property name="SSL_ENABLED" value="false"/>
                         </properties>
                     </remote-outbound-connection>
                 </outbound-connections>
             </subsystem>

In this case the profile use the user/security and properties for all 
connections and the cluster as well. In this it is necessary to have the 
same configuration for all the servers in the profile-bunch.
Another option I thought about is to use the user/properties in 
<profile> as default and have the possibility to use a inner element 
remote-outbound-connection, or a reference to remote-outbound-connection 
which can override these, but I'm not sure whether this is needed.

We (Tomasz Adamski and me) had a discussion about this and, technically 
there is no problem with each approach.

But ...

I know that all the ejb-client stuff is subject to change and to prevent 
from incompatible changes which are changed in every version
and from unnecessary work if the code will be changed before it will be 
used at all
I think it will need to be discussed with others because of this.

cheers
Wolf

From rory.odonnell at oracle.com  Tue Mar 10 07:03:44 2015
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Tue, 10 Mar 2015 11:03:44 +0000
Subject: [wildfly-dev] Early Access builds for JDK 9 b53 and JDK 8u60 b05
 are available on java.net
Message-ID: <54FECF90.3080206@oracle.com>


Hi Jason/Tomaz,

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

Early Access build for JDK 8u60 b05 <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-b05.html>

I'd also like to use this opportunity to point you to JEP 238: 
Multi-Version JAR Files [0],
which is currently a Candidate JEP for JDK 9.

It's goal is to extend the JAR file format to allow multiple, JDK 
release-specific versions of class
files to coexist in a single file. An additional goal is to backport the 
run-time changes to
JDK 8u60, thereby enabling JDK 8 to consume multi-version JARs. For a 
detailed discussion,
please see the corresponding thread on the core-libs-dev mailing list. [1]

Please keep in mind that a JEP in the Candidate state is merely an idea 
worthy of consideration
by JDK Release Projects and related efforts; there is no commitment that 
it will be delivered in
any particular release.

Comments, questions, and suggestions are welcome on the corelibs-dev 
mailing list. (If you
haven?t already subscribed to that list then please do so first, 
otherwise your message will be
discarded as spam.)

Rgds,Rory

[0] http://openjdk.java.net/jeps/238
[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031461.html 



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

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

From sridharthiyagarajan at gmail.com  Wed Mar 11 08:00:29 2015
From: sridharthiyagarajan at gmail.com (sridhar thiyagarajan)
Date: Wed, 11 Mar 2015 17:30:29 +0530
Subject: [wildfly-dev] How to make a service MBean depend on singleton
 stateless session bean using jboss-service.xml in wildfly 8
Message-ID: <CAE06nMO_H6w8qn3j2STG5bXn3MM-c=bKZwBy0cj8wuvwK04+2Q@mail.gmail.com>

Hi,

I am trying to make a service mbean depend on a singleton stateless session
bean by configuring in *jboss-service.xml *using *<depends> *in *wildfly AS
8 *but getting the below error:




*ERROR [org.jboss.as.controller.management-operation] (Controller Boot
Thread) JBAS014613: Operation ("deploy") failed - address: ([("deployment"
=> "TestEAR.ear")]) - failure description: {"JBAS014771: Services with
missing/unavailable dependencies" =>
["jboss.mbean.service.TestService.start is missing
[jboss.mbean.service.\"jboss.j2ee:ear=TestEAR.ear,jar=module-A.jar,name=TestConfig,service=EJB3\".start]","jboss.mbean.service.TestService.create
is missing
[jboss.mbean.service.\"jboss.j2ee:ear=TestEAR.ear,jar=module-A.jar,name=TestConfig,service=EJB3\".create]"*
Please find below the details on the code employed: Please help me to
resolve the error. Many thanks.

*project structure*

TestEAR (ear)

--- module-A (ejb jar containing singleton stateless session bean)
--- module-B (jar containing service mbean)
--- meta-inf/jboss-service.xml

*singleton stateless session bean (under module-A JAR)*

@Local(TestLocal.class)
@Resource(name="TestConfig", mappedName="java:/ConnectionFactory")
public class TestConfig {
... code ...
}

*jboss-service.xml (under meta-inf folder in TestEAR.ear)*

<server>
<mbean code="com.test.TestService" name="TestService">
<depends>jboss.j2ee:ear=TestEAR.ear,jar=module-A.jar,name=TestConfig,service=EJB3</depends>
</mbean>

*TestService.java (MBean) (under module-B JAR)*

public class TestService extends ServiceMBeanSupport implements TestMBean {
protected void startService() throws Exception {
...code...
}
protected void stopService() throws Exception {
...code...
}
protected void createService() throws Exception {
...code...
}
protected void destroyService() throws Exception {
...code...
}
}

*TestMBean.java (MBean interface) (under module-B JAR)*

public interface TestMBean extends org.jboss.system.ServiceMBean { }

Thanks.

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

From arjan.tijms at gmail.com  Thu Mar 12 09:52:01 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Thu, 12 Mar 2015 14:52:01 +0100
Subject: [wildfly-dev] [javaee7-samples] Added test to see if a logout
 from the web propagates to EJB (#290)
In-Reply-To: <CAE=-AhCew+7nTsCcj17k5Zoog6_w6poJ073r9OHGS3y5_z90AQ@mail.gmail.com>
References: <javaee-samples/javaee7-samples/pull/290@github.com>
	<CAGBoHQVPqDjkA4fO6gvczzjXFU-0Y44j=UpeFmxk+Nor=o_YNQ@mail.gmail.com>
	<CAE=-AhCew+7nTsCcj17k5Zoog6_w6poJ073r9OHGS3y5_z90AQ@mail.gmail.com>
Message-ID: <CAE=-AhARfjB7ZLBoxAXJGgJQGkB=kBe2R1BYUyakF2pFhHOjQA@mail.gmail.com>

Hi,

Just wondering if anyone from JBoss can say something about this issue?

Kind regards,
Arjan Tijms

On Mon, Feb 23, 2015 at 7:05 PM, arjan tijms <arjan.tijms at gmail.com> wrote:

> Hi,
>
> Fyi, I created a JIRA issue for the failure here:
> https://issues.jboss.org/browse/SECURITY-876
>
> Grtz,
> Arjan
>
>
> On Monday, February 23, 2015, Arun Gupta <arun.gupta at gmail.com> wrote:
>
>> A new test has been added javaee7-samples test and is failing on WildFly
>> 8.2. Can anybody take a look at this?
>>
>> Arun
>>
>> ---------- Forwarded message ----------
>> From: Arjan Tijms <notifications at github.com>
>> Date: Mon, Feb 23, 2015 at 9:05 AM
>> Subject: [javaee7-samples] Added test to see if a logout from the web
>> propagates to EJB (#290)
>> To: javaee-samples/javaee7-samples <javaee7-samples at noreply.github.com>
>>
>>
>> This adds a test to see if a logout from the web propagates to EJB, as it
>> should.
>>
>> This fails on WildFly 8.2, but succeeds on GlassFish 4.0 and 4.1.
>>
>> (note: this test has been tested)
>> ------------------------------
>> You can view, comment on, or merge this pull request online at:
>>
>>   https://github.com/javaee-samples/javaee7-samples/pull/290
>> Commit Summary
>>
>>    - Merge pull request #1 from javaee-samples/master
>>    - Added test to see if a logout from the web propagates to EJB
>>
>> File Changes
>>
>>    - *M* jaspic/ejb-propagation/pom.xml
>>    <https://github.com/javaee-samples/javaee7-samples/pull/290/files#diff-0>
>>    (3)
>>    - *A*
>>    jaspic/ejb-propagation/src/main/java/org/javaee7/jaspic/ejbpropagation/servlet/PublicServletPublicEJBLogout.java
>>    <https://github.com/javaee-samples/javaee7-samples/pull/290/files#diff-1>
>>    (56)
>>    - *A*
>>    jaspic/ejb-propagation/src/test/java/org/javaee7/jaspic/ejbpropagation/PublicEJBPropagationLogoutTest.java
>>    <https://github.com/javaee-samples/javaee7-samples/pull/290/files#diff-2>
>>    (62)
>>
>> Patch Links:
>>
>>    - https://github.com/javaee-samples/javaee7-samples/pull/290.patch
>>    - https://github.com/javaee-samples/javaee7-samples/pull/290.diff
>>
>> ?
>> Reply to this email directly or view it on GitHub
>> <https://github.com/javaee-samples/javaee7-samples/pull/290>.
>>
>>
>>
>> --
>> http://blog.arungupta.me
>> http://twitter.com/arungupta
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150312/7f6a9b85/attachment.html 

From jason.greene at redhat.com  Thu Mar 12 15:41:20 2015
From: jason.greene at redhat.com (Jason Greene)
Date: Thu, 12 Mar 2015 14:41:20 -0500
Subject: [wildfly-dev] 9.0.0.Beta1 Release Notes (Need Your Help!)
Message-ID: <6AB2F848-4E05-479C-9DBE-1F5F136184FB@redhat.com>

Hello Everyone!

I am assembling the release notes for the upcoming 9 Beta release. My first draft is located here:
https://developer.jboss.org/wiki/WildFly900Beta1ReleaseNotes

Please add any features you would like noted for this major release. This isn?t limited to enhancements within the core codebase. If you would like to note something from a subproject or third party library that you feel is interesting, then please do.

Thanks!

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



From jason.greene at redhat.com  Sun Mar 15 11:05:28 2015
From: jason.greene at redhat.com (Jason T. Greene)
Date: Sun, 15 Mar 2015 11:05:28 -0400 (EDT)
Subject: [wildfly-dev] WF10 Deployment Changes
Message-ID: <48881ED3-A37A-413D-A976-A83E4E639553@redhat.com>

Currently we are a bit inconsistent with whether or not partial deployment services are allowed to restart. This is because most require metadata that is intended to be temporary and is intended to be wiped out at the end of deployment. A major exception is JPA which is holding on to jandex annotation indexes, so that if its underlying JCA datasource bounces, it's able to restart. 

This is bad though because it wastes more memory than is actually needed (the state that JPA requires is less than the combined state of all annotation indexes and other deployment info). It's particular bad when we upgrade to jandex 2 since it stores a lot more information (generics, all method and field signatures, type annotations etc).

IMO based on this inconsistency and the time we have on the schedule, I think we need to momentarily suspend the not really attained goal of partial restart-ability. We should change JPA to stop keeping a hard reference to the indexes, and once that service goes down, a full redeployment is required. Stuart has a hack that can restart this automatically as part of a listener. We should probably look at extending this further.

Longer term I think we need to redesign the deployment service hierarchy to better represent the reality that restarting a portion deployment requires rerunning the initial scanning phases.

Thoughts?


Sent from my iPhone

From stuart.w.douglas at gmail.com  Sun Mar 15 16:51:00 2015
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Sun, 15 Mar 2015 20:51:00 +0000
Subject: [wildfly-dev] WF10 Deployment Changes
In-Reply-To: <48881ED3-A37A-413D-A976-A83E4E639553@redhat.com>
References: <48881ED3-A37A-413D-A976-A83E4E639553@redhat.com>
Message-ID: <CAAoo=c4nqKSvDqxrh4qDpaCNNUedNS5izoSuaiOvQNPjHrKNoQ@mail.gmail.com>

I started a branch that forces a redeploy on any deployment service
restart:
https://github.com/wildfly/wildfly-core/compare/master...stuartwdouglas:deployment-service-restart

It does break some singleton functionality though, although that should be
easy enough to work around (perhaps some kind of marker interface to mark
services as restartable).

Stuart



On Mon, 16 Mar 2015 at 02:06 Jason T. Greene <jason.greene at redhat.com>
wrote:

> Currently we are a bit inconsistent with whether or not partial deployment
> services are allowed to restart. This is because most require metadata that
> is intended to be temporary and is intended to be wiped out at the end of
> deployment. A major exception is JPA which is holding on to jandex
> annotation indexes, so that if its underlying JCA datasource bounces, it's
> able to restart.
>
> This is bad though because it wastes more memory than is actually needed
> (the state that JPA requires is less than the combined state of all
> annotation indexes and other deployment info). It's particular bad when we
> upgrade to jandex 2 since it stores a lot more information (generics, all
> method and field signatures, type annotations etc).
>
> IMO based on this inconsistency and the time we have on the schedule, I
> think we need to momentarily suspend the not really attained goal of
> partial restart-ability. We should change JPA to stop keeping a hard
> reference to the indexes, and once that service goes down, a full
> redeployment is required. Stuart has a hack that can restart this
> automatically as part of a listener. We should probably look at extending
> this further.
>
> Longer term I think we need to redesign the deployment service hierarchy
> to better represent the reality that restarting a portion deployment
> requires rerunning the initial scanning phases.
>
> Thoughts?
>
>
> Sent from my iPhone
> _______________________________________________
> 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/20150315/17866a85/attachment-0001.html 

From mazz at redhat.com  Sun Mar 15 17:37:17 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Sun, 15 Mar 2015 17:37:17 -0400 (EDT)
Subject: [wildfly-dev] problem binding to JNDI in subsystem extension
In-Reply-To: <1988184333.30089629.1426454762077.JavaMail.zimbra@redhat.com>
Message-ID: <209829657.30090021.1426455437984.JavaMail.zimbra@redhat.com>

I have a custom subsystem extension I'm deploying in Wildfly 8.2. I hit a problem when trying to bind an object to JNDI.

In my AbstractAddStepHandler.performRuntime() (the Subsystem Add handler), I want to bind an object to JNDI, like this:

  InitialContext initialContext = new InitialContext();
  WritableServiceBasedNamingStore.pushOwner(context.getServiceTarget());
    try {
      initialContext.bind(jndiName, jndiObject); // <--- this sometimes throws exception you see below
    } finally {
      WritableServiceBasedNamingStore.popOwner();
    }

where "context" is the first parameter passed to the performRuntime() method, and "jndiName" is "java:global/example/demo/myname" and "jndiObject" is just a java.lang.String, like "hello".

The use of WritableServiceBasedNamingStore is recommended on the wiki: https://docs.jboss.org/author/display/WFLY8/JNDI+Reference - though I have no idea what it is doing :)

The problem is - each time I start my wildfly server, sometimes it works, other times it doesn't. It is as if there is a race condition somewhere on startup of the wildfly server. If it works, my JNDI object is bound properly; when it fails, this bombs with the exception I show below.

Anyone know what the problem is and how to fix?

====

javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file:  java.naming.factory.initial
	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:662) [rt.jar:1.8.0_31]
	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313) [rt.jar:1.8.0_31]
	at javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:350) [rt.jar:1.8.0_31]
	at javax.naming.InitialContext.bind(InitialContext.java:425) [rt.jar:1.8.0_31]
	at org.demo.extension.SubsystemAdd.performRuntime(SubsystemAdd.java:153)
	at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:75) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:660) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:501) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:298) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:293) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
	at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:354) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_31]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_31]
	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_31]
	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]

From stuart.w.douglas at gmail.com  Sun Mar 15 19:16:42 2015
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Sun, 15 Mar 2015 23:16:42 +0000
Subject: [wildfly-dev] problem binding to JNDI in subsystem extension
In-Reply-To: <209829657.30090021.1426455437984.JavaMail.zimbra@redhat.com>
References: <1988184333.30089629.1426454762077.JavaMail.zimbra@redhat.com>
	<209829657.30090021.1426455437984.JavaMail.zimbra@redhat.com>
Message-ID: <CAAoo=c75=9tB2mbT4YhKZ98y9pmDWmHWv+PtfcWL=uMXPBX-Fg@mail.gmail.com>

Looks like your extension is being initialised before JNDI. There are two
options:

- Use org.jboss.as.naming.service.BinderService to do the binding (there
are lots of examples of how to use this in the Wildfly code base
- Create a custom service that depends upon the appropriate naming
subsystem services (namely
DefaultNamespaceContextSelectorService.SERVICE_NAME), and do the
bind/unbind in the services start/stop method. This will make sure the
naming subsystem is up before the bind takes place.

Stuart

On Mon, 16 Mar 2015 at 08:37 John Mazzitelli <mazz at redhat.com> wrote:

> I have a custom subsystem extension I'm deploying in Wildfly 8.2. I hit a
> problem when trying to bind an object to JNDI.
>
> In my AbstractAddStepHandler.performRuntime() (the Subsystem Add
> handler), I want to bind an object to JNDI, like this:
>
>   InitialContext initialContext = new InitialContext();
>   WritableServiceBasedNamingStore.pushOwner(context.getServiceTarget());
>     try {
>       initialContext.bind(jndiName, jndiObject); // <--- this sometimes
> throws exception you see below
>     } finally {
>       WritableServiceBasedNamingStore.popOwner();
>     }
>
> where "context" is the first parameter passed to the performRuntime()
> method, and "jndiName" is "java:global/example/demo/myname" and
> "jndiObject" is just a java.lang.String, like "hello".
>
> The use of WritableServiceBasedNamingStore is recommended on the wiki:
> https://docs.jboss.org/author/display/WFLY8/JNDI+Reference - though I
> have no idea what it is doing :)
>
> The problem is - each time I start my wildfly server, sometimes it works,
> other times it doesn't. It is as if there is a race condition somewhere on
> startup of the wildfly server. If it works, my JNDI object is bound
> properly; when it fails, this bombs with the exception I show below.
>
> Anyone know what the problem is and how to fix?
>
> ====
>
> javax.naming.NoInitialContextException: Need to specify class name in
> environment or system property, or as an applet parameter, or in an
> application resource file:  java.naming.factory.initial
>         at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:662)
> [rt.jar:1.8.0_31]
>         at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> [rt.jar:1.8.0_31]
>         at javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:350)
> [rt.jar:1.8.0_31]
>         at javax.naming.InitialContext.bind(InitialContext.java:425)
> [rt.jar:1.8.0_31]
>         at org.demo.extension.SubsystemAdd.performRuntime(
> SubsystemAdd.java:153)
>         at org.jboss.as.controller.AbstractAddStepHandler$1.execute(
> AbstractAddStepHandler.java:75) [wildfly-controller-8.2.0.
> Final.jar:8.2.0.Final]
>         at org.jboss.as.controller.AbstractOperationContext.executeStep(
> AbstractOperationContext.java:660) [wildfly-controller-8.2.0.
> Final.jar:8.2.0.Final]
>         at org.jboss.as.controller.AbstractOperationContext.
> doCompleteStep(AbstractOperationContext.java:501)
> [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
>         at org.jboss.as.controller.AbstractOperationContext.
> completeStepInternal(AbstractOperationContext.java:298)
> [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
>         at org.jboss.as.controller.AbstractOperationContext.
> executeOperation(AbstractOperationContext.java:293)
> [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
>         at org.jboss.as.controller.ParallelBootOperationStepHandl
> er$ParallelBootTask.run(ParallelBootOperationStepHandler.java:354)
> [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [rt.jar:1.8.0_31]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [rt.jar:1.8.0_31]
>         at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_31]
>         at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> _______________________________________________
> 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/20150315/9e0e8dac/attachment.html 

From mazz at redhat.com  Sun Mar 15 21:59:15 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Sun, 15 Mar 2015 21:59:15 -0400 (EDT)
Subject: [wildfly-dev] problem binding to JNDI in subsystem extension
In-Reply-To: <CAAoo=c75=9tB2mbT4YhKZ98y9pmDWmHWv+PtfcWL=uMXPBX-Fg@mail.gmail.com>
References: <1988184333.30089629.1426454762077.JavaMail.zimbra@redhat.com>
	<209829657.30090021.1426455437984.JavaMail.zimbra@redhat.com>
	<CAAoo=c75=9tB2mbT4YhKZ98y9pmDWmHWv+PtfcWL=uMXPBX-Fg@mail.gmail.com>
Message-ID: <1383840197.30126852.1426471155055.JavaMail.zimbra@redhat.com>

> - Use org.jboss.as.naming.service.BinderService to do the binding (there
> are lots of examples of how to use this in the Wildfly code base

Ahh.. sweet. Thanks Stuart. Found a good piece of Wildfly code I was able to follow:

https://github.com/wildfly/wildfly/blob/master/mail/src/main/java/org/jboss/as/mail/extension/MailSessionAdd.java#L116L139

Looks like I got it to work using something like that :)

--John Mazz

----- Original Message -----
> Looks like your extension is being initialised before JNDI. There are two
> options:
> 
> - Use org.jboss.as.naming.service.BinderService to do the binding (there
> are lots of examples of how to use this in the Wildfly code base
> - Create a custom service that depends upon the appropriate naming
> subsystem services (namely
> DefaultNamespaceContextSelectorService.SERVICE_NAME), and do the
> bind/unbind in the services start/stop method. This will make sure the
> naming subsystem is up before the bind takes place.
> 
> Stuart
> 
> On Mon, 16 Mar 2015 at 08:37 John Mazzitelli <mazz at redhat.com> wrote:
> 
> > I have a custom subsystem extension I'm deploying in Wildfly 8.2. I hit a
> > problem when trying to bind an object to JNDI.
> >
> > In my AbstractAddStepHandler.performRuntime() (the Subsystem Add
> > handler), I want to bind an object to JNDI, like this:
> >
> >   InitialContext initialContext = new InitialContext();
> >   WritableServiceBasedNamingStore.pushOwner(context.getServiceTarget());
> >     try {
> >       initialContext.bind(jndiName, jndiObject); // <--- this sometimes
> > throws exception you see below
> >     } finally {
> >       WritableServiceBasedNamingStore.popOwner();
> >     }
> >
> > where "context" is the first parameter passed to the performRuntime()
> > method, and "jndiName" is "java:global/example/demo/myname" and
> > "jndiObject" is just a java.lang.String, like "hello".
> >
> > The use of WritableServiceBasedNamingStore is recommended on the wiki:
> > https://docs.jboss.org/author/display/WFLY8/JNDI+Reference - though I
> > have no idea what it is doing :)
> >
> > The problem is - each time I start my wildfly server, sometimes it works,
> > other times it doesn't. It is as if there is a race condition somewhere on
> > startup of the wildfly server. If it works, my JNDI object is bound
> > properly; when it fails, this bombs with the exception I show below.
> >
> > Anyone know what the problem is and how to fix?
> >
> > ====
> >
> > javax.naming.NoInitialContextException: Need to specify class name in
> > environment or system property, or as an applet parameter, or in an
> > application resource file:  java.naming.factory.initial
> >         at
> >         javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:662)
> > [rt.jar:1.8.0_31]
> >         at
> >         javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> > [rt.jar:1.8.0_31]
> >         at
> >         javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:350)
> > [rt.jar:1.8.0_31]
> >         at javax.naming.InitialContext.bind(InitialContext.java:425)
> > [rt.jar:1.8.0_31]
> >         at org.demo.extension.SubsystemAdd.performRuntime(
> > SubsystemAdd.java:153)
> >         at org.jboss.as.controller.AbstractAddStepHandler$1.execute(
> > AbstractAddStepHandler.java:75) [wildfly-controller-8.2.0.
> > Final.jar:8.2.0.Final]
> >         at org.jboss.as.controller.AbstractOperationContext.executeStep(
> > AbstractOperationContext.java:660) [wildfly-controller-8.2.0.
> > Final.jar:8.2.0.Final]
> >         at org.jboss.as.controller.AbstractOperationContext.
> > doCompleteStep(AbstractOperationContext.java:501)
> > [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> >         at org.jboss.as.controller.AbstractOperationContext.
> > completeStepInternal(AbstractOperationContext.java:298)
> > [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> >         at org.jboss.as.controller.AbstractOperationContext.
> > executeOperation(AbstractOperationContext.java:293)
> > [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> >         at org.jboss.as.controller.ParallelBootOperationStepHandl
> > er$ParallelBootTask.run(ParallelBootOperationStepHandler.java:354)
> > [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> >         at
> >         java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> > [rt.jar:1.8.0_31]
> >         at
> >         java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> > [rt.jar:1.8.0_31]
> >         at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_31]
> >         at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> > [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> 

From darran.lofthouse at jboss.com  Tue Mar 17 09:04:50 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Tue, 17 Mar 2015 13:04:50 +0000
Subject: [wildfly-dev] WFLY-2422 or simplifying the remote outbound
 connection configuration for server to server communication
In-Reply-To: <54FDAD5C.2030600@redhat.com>
References: <54FDAD5C.2030600@redhat.com>
Message-ID: <55082672.1010006@jboss.com>

Don't forget that the server to server security settings are being 
re-visited for WildFly 10 so that area is already going to be subject to 
a reasonably large change.


On 09/03/15 14:25, Wolf-Dieter Fink wrote:
> I start a request for simplifying the configuration for "in EE
> application" clients and get rid of extra cluster configuration and
> repeat properties many times.
> Also the client should not need to have knowledge about the server
> topology, there is no need to know how many servers there are or whether
> they are clustered or not.
>
> Starting point in EAP6/WF8 is a application configuration like this:
> https://github.com/wildfly/quickstart/blob/master/ejb-multi-server/app-main/ear/src/main/application/META-INF/jboss-ejb-client.xml?
>
> and a server side configuration like this:
>               <subsystem xmlns="urn:jboss:domain:remoting:3.0">
>                   <endpoint worker="default"/>
>                   <http-connector name="http-remoting-connector"
> connector-ref="default" security-realm="ApplicationRealm"/>
>                   <outbound-connections>
>                       <remote-outbound-connection
> name="remote-ejb-connection-1"
> outbound-socket-binding-ref="remote-ejb-1" username="quickuser1"
> security-realm="ejb-security-realm-1" protocol="http-remoting">
>                           <properties>
>                               <property name="SASL_POLICY_NOANONYMOUS"
> value="false"/>
>                               <property name="SSL_ENABLED" value="false"/>
>                           </properties>
>                       </remote-outbound-connection>
>                       <remote-outbound-connection
> name="remote-ejb-connection-2"
> outbound-socket-binding-ref="remote-ejb-2" username="quickuser2"
> security-realm="ejb-security-realm-2" protocol="http-remoting">
>                           <properties>
>                               <property name="SASL_POLICY_NOANONYMOUS"
> value="false"/>
>                               <property name="SSL_ENABLED" value="false"/>
>                           </properties>
>                       </remote-outbound-connection>
>                   </outbound-connections>
>               </subsystem>
>
>
>
> Tomasz did some refactoring (WF9) to use a profile from the application
> perspective. The configuration is like this:
>
> jboss-ejb-client.xml
>       <client-context>
>           <profile name="main-app"/>
>       </client-context>
>
> server profile:
>                   <remote connector-ref="http-remoting-connector"
> thread-pool-name="default">
>                       <profiles>
>                           <profile name="main-app">
>                               <remoting-ejb-receiver name="AppOneA"
> outbound-connection-ref="remote-ejb-connection-1"/>
>                               <remoting-ejb-receiver name="AppTwoA"
> outbound-connection-ref="remote-ejb-connection-2"/>
>                           </profile>
>                       </profiles>
>                   </remote>
> ....
>               <subsystem xmlns="urn:jboss:domain:remoting:3.0">
>                   <outbound-connections>
>                       <remote-outbound-connection
> name="remote-ejb-connection-1"
> outbound-socket-binding-ref="remote-ejb-1" username="quickuser1"
> security-realm="ejb-security-realm-1" protocol="http-remoting">
>                           <properties>
>                               <property name="SASL_POLICY_NOANONYMOUS"
> value="false"/>
>                               <property name="SSL_ENABLED" value="false"/>
>                           </properties>
>                       </remote-outbound-connection>
>                       <remote-outbound-connection
> name="remote-ejb-connection-2"
> outbound-socket-binding-ref="remote-ejb-2" username="quickuser2"
> security-realm="ejb-security-realm-2" protocol="http-remoting">
>                           <properties>
>                               <property name="SASL_POLICY_NOANONYMOUS"
> value="false"/>
>                               <property name="SSL_ENABLED" value="false"/>
>                           </properties>
>                       </remote-outbound-connection>
>                   </outbound-connections>
>               </subsystem>
>
>
> With the current implementation there are some issues or
> concerns/enhancements
> - profile does not work with clusters
> - not possible to have multiple profiles
> - the properties/user must be still repeated
>
>
>
>   From my point of view
> - a cluster need to have the same property configuration, also different
> users make no sense. Might work, but at least the cluster view will use
> the same user
> - a similar group of servers for the same application should not have
> different properties/users as this will be error prone
> - configuration should be as small and intuitive as possible
>
> My initial idea was to have a jboss-ejb-client.xml which reference
> 'applications' to connect, that is similar to profiles
> The server side as followed (don't care about the exact XML elements or
> names)
>
>               <subsystem xmlns="urn:jboss:domain:remoting:3.0">
>                   <outbound-connections>
>                       <profile name="App1" username="quickuser1"
> security-realm="ejb-security-realm-1" protocol="http-remoting">
>                           <properties>
>                               <property name="SASL_POLICY_NOANONYMOUS"
> value="false"/>
>                               <property name="SSL_ENABLED" value="false"/>
>                           </properties>
> <outbound-sockets>remote-ejb-1,remote-ejb2</outbound-sockets> <!--
> repeated elements seems better -->
>                       </remote-outbound-connection>
>                       <remote-outbound-connection
> name="remote-ejb-connection-X"
> outbound-socket-binding-ref="remote-ejb-X" username="quickuser2"
> security-realm="ejb-security-realm-2" protocol="http-remoting">
>                           <properties>
>                               <property name="SASL_POLICY_NOANONYMOUS"
> value="false"/>
>                               <property name="SSL_ENABLED" value="false"/>
>                           </properties>
>                       </remote-outbound-connection>
>                   </outbound-connections>
>               </subsystem>
>
> In this case the profile use the user/security and properties for all
> connections and the cluster as well. In this it is necessary to have the
> same configuration for all the servers in the profile-bunch.
> Another option I thought about is to use the user/properties in
> <profile> as default and have the possibility to use a inner element
> remote-outbound-connection, or a reference to remote-outbound-connection
> which can override these, but I'm not sure whether this is needed.
>
> We (Tomasz Adamski and me) had a discussion about this and, technically
> there is no problem with each approach.
>
> But ...
>
> I know that all the ejb-client stuff is subject to change and to prevent
> from incompatible changes which are changed in every version
> and from unnecessary work if the code will be changed before it will be
> used at all
> I think it will need to be discussed with others because of this.
>
> cheers
> Wolf
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From smarlow at redhat.com  Tue Mar 17 11:11:10 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 17 Mar 2015 11:11:10 -0400
Subject: [wildfly-dev] WF10 Deployment Changes
In-Reply-To: <CAAoo=c4nqKSvDqxrh4qDpaCNNUedNS5izoSuaiOvQNPjHrKNoQ@mail.gmail.com>
References: <48881ED3-A37A-413D-A976-A83E4E639553@redhat.com>
	<CAAoo=c4nqKSvDqxrh4qDpaCNNUedNS5izoSuaiOvQNPjHrKNoQ@mail.gmail.com>
Message-ID: <5508440E.4050603@redhat.com>

Our JPA container is only caching the Jandex indexes for restart of 
Hibernate ORM versions less than 4.3.0.  Once the caching is no longer 
needed (deployment-service-restart is merged in), we should update [1] 
to not cache the jandex indexes anymore.  We don't do any Jandex index 
caching for the default Hibernate ORM 4.3.8 version in WildFly 9.0 today.

We might pass the Jandex indexes into Hibernate 5.0, which is something 
we talked about doing a while back (via "hibernate.jandex_index" 
integration map property).  I'll check to make sure that Hibernate ORM 
5.0, doesn't keep a reference to the Jandex indexes after deployment 
completes (since we won't be able to pass "hibernate.jandex_index" in if 
it does).

Scott

[1] 
https://github.com/jipijapa/jipijapa/blob/master/hibernate4_1/src/main/java/org/jboss/as/jpa/hibernate4/HibernateAnnotationScanner.java#L55

On 03/15/2015 04:51 PM, Stuart Douglas wrote:
> I started a branch that forces a redeploy on any deployment service
> restart:
> https://github.com/wildfly/wildfly-core/compare/master...stuartwdouglas:deployment-service-restart
>
> It does break some singleton functionality though, although that should
> be easy enough to work around (perhaps some kind of marker interface to
> mark services as restartable).
>
> Stuart
>
>
>
> On Mon, 16 Mar 2015 at 02:06 Jason T. Greene <jason.greene at redhat.com
> <mailto:jason.greene at redhat.com>> wrote:
>
>     Currently we are a bit inconsistent with whether or not partial
>     deployment services are allowed to restart. This is because most
>     require metadata that is intended to be temporary and is intended to
>     be wiped out at the end of deployment. A major exception is JPA
>     which is holding on to jandex annotation indexes, so that if its
>     underlying JCA datasource bounces, it's able to restart.
>
>     This is bad though because it wastes more memory than is actually
>     needed (the state that JPA requires is less than the combined state
>     of all annotation indexes and other deployment info). It's
>     particular bad when we upgrade to jandex 2 since it stores a lot
>     more information (generics, all method and field signatures, type
>     annotations etc).
>
>     IMO based on this inconsistency and the time we have on the
>     schedule, I think we need to momentarily suspend the not really
>     attained goal of partial restart-ability. We should change JPA to
>     stop keeping a hard reference to the indexes, and once that service
>     goes down, a full redeployment is required. Stuart has a hack that
>     can restart this automatically as part of a listener. We should
>     probably look at extending this further.
>
>     Longer term I think we need to redesign the deployment service
>     hierarchy to better represent the reality that restarting a portion
>     deployment requires rerunning the initial scanning phases.
>
>     Thoughts?
>
>
>     Sent from my iPhone
>     _________________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/__mailman/listinfo/wildfly-dev
>     <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From manderse at redhat.com  Tue Mar 17 13:30:05 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Tue, 17 Mar 2015 18:30:05 +0100
Subject: [wildfly-dev] WF10 Deployment Changes
In-Reply-To: <48881ED3-A37A-413D-A976-A83E4E639553@redhat.com>
References: <48881ED3-A37A-413D-A976-A83E4E639553@redhat.com>
Message-ID: <93A166C1-808A-43EF-A946-E0EF7802B0CC@redhat.com>

I'm trying to grok what impact this have on endusers ?

do they need to wait longer/less/same as before when certain 
changes/deployments occur ?

/max

> Currently we are a bit inconsistent with whether or not partial 
> deployment services are allowed to restart. This is because most 
> require metadata that is intended to be temporary and is intended to 
> be wiped out at the end of deployment. A major exception is JPA which 
> is holding on to jandex annotation indexes, so that if its underlying 
> JCA datasource bounces, it's able to restart.
>
> This is bad though because it wastes more memory than is actually 
> needed (the state that JPA requires is less than the combined state of 
> all annotation indexes and other deployment info). It's particular bad 
> when we upgrade to jandex 2 since it stores a lot more information 
> (generics, all method and field signatures, type annotations etc).
>
> IMO based on this inconsistency and the time we have on the schedule, 
> I think we need to momentarily suspend the not really attained goal of 
> partial restart-ability. We should change JPA to stop keeping a hard 
> reference to the indexes, and once that service goes down, a full 
> redeployment is required. Stuart has a hack that can restart this 
> automatically as part of a listener. We should probably look at 
> extending this further.
>
> Longer term I think we need to redesign the deployment service 
> hierarchy to better represent the reality that restarting a portion 
> deployment requires rerunning the initial scanning phases.
>
> Thoughts?
>
>
> Sent from my iPhone
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


/max
http://about.me/maxandersen

From smarlow at redhat.com  Tue Mar 17 19:13:37 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 17 Mar 2015 19:13:37 -0400
Subject: [wildfly-dev] WF10 Deployment Changes
In-Reply-To: <5508440E.4050603@redhat.com>
References: <48881ED3-A37A-413D-A976-A83E4E639553@redhat.com>	<CAAoo=c4nqKSvDqxrh4qDpaCNNUedNS5izoSuaiOvQNPjHrKNoQ@mail.gmail.com>
	<5508440E.4050603@redhat.com>
Message-ID: <5508B521.1030004@redhat.com>



On 03/17/2015 11:11 AM, Scott Marlow wrote:
> Our JPA container is only caching the Jandex indexes for restart of
> Hibernate ORM versions less than 4.3.0.  Once the caching is no longer
> needed (deployment-service-restart is merged in), we should update [1]
> to not cache the jandex indexes anymore.  We don't do any Jandex index
> caching for the default Hibernate ORM 4.3.8 version in WildFly 9.0 today.
>
> We might pass the Jandex indexes into Hibernate 5.0, which is something
> we talked about doing a while back (via "hibernate.jandex_index"
> integration map property).  I'll check to make sure that Hibernate ORM
> 5.0, doesn't keep a reference to the Jandex indexes after deployment
> completes (since we won't be able to pass "hibernate.jandex_index" in if
> it does).

Currently, Hibernate 4.3 is building its own Jandex IndexView [2] but we 
could probably build/pass one in (via "hibernate.jandex_index"), so that 
Hibernate won't build its own indexes anymore.  We discussed doing this 
for integrating with Hibernate 5.0 (WFLY-3291) but the same should also 
work for 4.3.x.

Scott

[2] 
https://github.com/hibernate/hibernate-orm/blob/4.3/hibernate-entitymanager/src/main/java/org/hibernate/jpa/boot/internal/EntityManagerFactoryBuilderImpl.java

>
> Scott
>
> [1]
> https://github.com/jipijapa/jipijapa/blob/master/hibernate4_1/src/main/java/org/jboss/as/jpa/hibernate4/HibernateAnnotationScanner.java#L55
>
> On 03/15/2015 04:51 PM, Stuart Douglas wrote:
>> I started a branch that forces a redeploy on any deployment service
>> restart:
>> https://github.com/wildfly/wildfly-core/compare/master...stuartwdouglas:deployment-service-restart
>>
>> It does break some singleton functionality though, although that should
>> be easy enough to work around (perhaps some kind of marker interface to
>> mark services as restartable).
>>
>> Stuart
>>
>>
>>
>> On Mon, 16 Mar 2015 at 02:06 Jason T. Greene <jason.greene at redhat.com
>> <mailto:jason.greene at redhat.com>> wrote:
>>
>>      Currently we are a bit inconsistent with whether or not partial
>>      deployment services are allowed to restart. This is because most
>>      require metadata that is intended to be temporary and is intended to
>>      be wiped out at the end of deployment. A major exception is JPA
>>      which is holding on to jandex annotation indexes, so that if its
>>      underlying JCA datasource bounces, it's able to restart.
>>
>>      This is bad though because it wastes more memory than is actually
>>      needed (the state that JPA requires is less than the combined state
>>      of all annotation indexes and other deployment info). It's
>>      particular bad when we upgrade to jandex 2 since it stores a lot
>>      more information (generics, all method and field signatures, type
>>      annotations etc).
>>
>>      IMO based on this inconsistency and the time we have on the
>>      schedule, I think we need to momentarily suspend the not really
>>      attained goal of partial restart-ability. We should change JPA to
>>      stop keeping a hard reference to the indexes, and once that service
>>      goes down, a full redeployment is required. Stuart has a hack that
>>      can restart this automatically as part of a listener. We should
>>      probably look at extending this further.
>>
>>      Longer term I think we need to redesign the deployment service
>>      hierarchy to better represent the reality that restarting a portion
>>      deployment requires rerunning the initial scanning phases.
>>
>>      Thoughts?
>>
>>
>>      Sent from my iPhone
>>      _________________________________________________
>>      wildfly-dev mailing list
>>      wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>      https://lists.jboss.org/__mailman/listinfo/wildfly-dev
>>      <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From smarlow at redhat.com  Tue Mar 17 19:45:07 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 17 Mar 2015 19:45:07 -0400
Subject: [wildfly-dev] WF10 Deployment Changes
In-Reply-To: <5508B521.1030004@redhat.com>
References: <48881ED3-A37A-413D-A976-A83E4E639553@redhat.com>	<CAAoo=c4nqKSvDqxrh4qDpaCNNUedNS5izoSuaiOvQNPjHrKNoQ@mail.gmail.com>	<5508440E.4050603@redhat.com>
	<5508B521.1030004@redhat.com>
Message-ID: <5508BC83.9030303@redhat.com>

>
> Currently, Hibernate 4.3 is building its own Jandex IndexView [2] but we
> could probably build/pass one in (via "hibernate.jandex_index"), so that
> Hibernate won't build its own indexes anymore.  We discussed doing this
> for integrating with Hibernate 5.0 (WFLY-3291) but the same should also
> work for 4.3.x.
>

We cannot pass our Jandex indexes into Hibernate until the 
deployment-service-restart changes are merged into WildFly (or something 
like that).  On a partial restart, we will need access to the Jandex 
indexes, which need to be rebuilt (as already pointed out by Jason on 
this thread).

From arun.gupta at gmail.com  Wed Mar 18 00:57:25 2015
From: arun.gupta at gmail.com (Arun Gupta)
Date: Tue, 17 Mar 2015 21:57:25 -0700
Subject: [wildfly-dev] MORE_JAVA_OPTS in standalone.sh
Message-ID: <CAGBoHQUSZY345Us-Eyzqz5aKHQmkgBUbt_dPyNqfxiWx+1ezjw@mail.gmail.com>

Can standalone.sh script be extended such that it takes an additional
environment variable that is then added to JAVA_OPTS during startup?

This can be used for passing additional Java options from WildFly
Docker image. Cursory look at the script does not reveal anything like
that exist.

Arun


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

From jai.forums2013 at gmail.com  Wed Mar 18 01:22:26 2015
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Wed, 18 Mar 2015 10:52:26 +0530
Subject: [wildfly-dev] MORE_JAVA_OPTS in standalone.sh
In-Reply-To: <CAGBoHQUSZY345Us-Eyzqz5aKHQmkgBUbt_dPyNqfxiWx+1ezjw@mail.gmail.com>
References: <CAGBoHQUSZY345Us-Eyzqz5aKHQmkgBUbt_dPyNqfxiWx+1ezjw@mail.gmail.com>
Message-ID: <55090B92.3040606@gmail.com>

Hi Arun,

The WildFly startup scripts allow you to *override* the JAVA_OPTS by 
setting an environment variable of that same name. See the 
standalone.conf (for *nix OS) file for details. From what I see, there's 
no option to append to the default JAVA_OPTS, by setting an environment 
variable. This could be worked around (in a bit brittle manner) by 
setting the overriding environment variable value to contain the default 
JAVA_OPTS (copied over from standalone.conf) plus the other 
custom/specific ones that the caller wants to pass.

-Jaikiran
On Wednesday 18 March 2015 10:27 AM, Arun Gupta wrote:
> Can standalone.sh script be extended such that it takes an additional
> environment variable that is then added to JAVA_OPTS during startup?
>
> This can be used for passing additional Java options from WildFly
> Docker image. Cursory look at the script does not reveal anything like
> that exist.
>
> Arun
>
>


From hardy at hibernate.org  Wed Mar 18 05:12:26 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 18 Mar 2015 10:12:26 +0100
Subject: [wildfly-dev] WF10 Deployment Changes
In-Reply-To: <5508B521.1030004@redhat.com>
References: <48881ED3-A37A-413D-A976-A83E4E639553@redhat.com>
	<CAAoo=c4nqKSvDqxrh4qDpaCNNUedNS5izoSuaiOvQNPjHrKNoQ@mail.gmail.com>
	<5508440E.4050603@redhat.com> <5508B521.1030004@redhat.com>
Message-ID: <20150318091226.GA77706@Nineveh.lan>

On Tue, Mar 17, 2015 at 07:13:37PM -0400, Scott Marlow wrote:
> Currently, Hibernate 4.3 is building its own Jandex IndexView [2] but we 
> could probably build/pass one in (via "hibernate.jandex_index"), so that 
> Hibernate won't build its own indexes anymore.  We discussed doing this 
> for integrating with Hibernate 5.0 (WFLY-3291) but the same should also 
> work for 4.3.x.

Interesting, afair 4.3 does not use Jandex. I wonder whether there is really a
need for Jandex in 4.3? I can see it contains the metamodel code, but that could
be removed afaiu.

--Hardy
-------------- 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/20150318/72668b54/attachment.bin 

From arun.gupta at gmail.com  Wed Mar 18 08:42:38 2015
From: arun.gupta at gmail.com (Arun Gupta)
Date: Wed, 18 Mar 2015 05:42:38 -0700
Subject: [wildfly-dev] MORE_JAVA_OPTS in standalone.sh
In-Reply-To: <55090B92.3040606@gmail.com>
References: <CAGBoHQUSZY345Us-Eyzqz5aKHQmkgBUbt_dPyNqfxiWx+1ezjw@mail.gmail.com>
	<55090B92.3040606@gmail.com>
Message-ID: <CAGBoHQW7K0YekvjNVoWeRhEN6OEicG52FiEg6OTN6gjLWscijw@mail.gmail.com>

I'd like to not override the default JAVA_OPTS used by WildFly,
instead add my own value to it. I think that's where MORE_JAVA_OPTS or
EXTRA_JAVA_OPTS could be useful.

Copy/pasting the existing JAVA_OPTS and including my own does not feel right :)

Arun

On Tue, Mar 17, 2015 at 10:22 PM, Jaikiran Pai <jai.forums2013 at gmail.com> wrote:
> Hi Arun,
>
> The WildFly startup scripts allow you to *override* the JAVA_OPTS by setting
> an environment variable of that same name. See the standalone.conf (for *nix
> OS) file for details. From what I see, there's no option to append to the
> default JAVA_OPTS, by setting an environment variable. This could be worked
> around (in a bit brittle manner) by setting the overriding environment
> variable value to contain the default JAVA_OPTS (copied over from
> standalone.conf) plus the other custom/specific ones that the caller wants
> to pass.
>
> -Jaikiran
>
> On Wednesday 18 March 2015 10:27 AM, Arun Gupta wrote:
>>
>> Can standalone.sh script be extended such that it takes an additional
>> environment variable that is then added to JAVA_OPTS during startup?
>>
>> This can be used for passing additional Java options from WildFly
>> Docker image. Cursory look at the script does not reveal anything like
>> that exist.
>>
>> Arun
>>
>>
>



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

From jai.forums2013 at gmail.com  Wed Mar 18 08:47:34 2015
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Wed, 18 Mar 2015 18:17:34 +0530
Subject: [wildfly-dev] MORE_JAVA_OPTS in standalone.sh
In-Reply-To: <CAGBoHQW7K0YekvjNVoWeRhEN6OEicG52FiEg6OTN6gjLWscijw@mail.gmail.com>
References: <CAGBoHQUSZY345Us-Eyzqz5aKHQmkgBUbt_dPyNqfxiWx+1ezjw@mail.gmail.com>	<55090B92.3040606@gmail.com>
	<CAGBoHQW7K0YekvjNVoWeRhEN6OEicG52FiEg6OTN6gjLWscijw@mail.gmail.com>
Message-ID: <550973E6.3040708@gmail.com>

Fair enough. I vaguely recollect that a feature like this, was something 
that was either added in JBoss AS 4.2.x days or was proposed at that 
time. Looking at the current 8.x scripts, this isn't available, so IMO 
filing an enhancement might be a good idea.

-Jaikiran
On Wednesday 18 March 2015 06:12 PM, Arun Gupta wrote:
> I'd like to not override the default JAVA_OPTS used by WildFly,
> instead add my own value to it. I think that's where MORE_JAVA_OPTS or
> EXTRA_JAVA_OPTS could be useful.
>
> Copy/pasting the existing JAVA_OPTS and including my own does not feel right :)
>
> Arun
>
> On Tue, Mar 17, 2015 at 10:22 PM, Jaikiran Pai <jai.forums2013 at gmail.com> wrote:
>> Hi Arun,
>>
>> The WildFly startup scripts allow you to *override* the JAVA_OPTS by setting
>> an environment variable of that same name. See the standalone.conf (for *nix
>> OS) file for details. From what I see, there's no option to append to the
>> default JAVA_OPTS, by setting an environment variable. This could be worked
>> around (in a bit brittle manner) by setting the overriding environment
>> variable value to contain the default JAVA_OPTS (copied over from
>> standalone.conf) plus the other custom/specific ones that the caller wants
>> to pass.
>>
>> -Jaikiran
>>
>> On Wednesday 18 March 2015 10:27 AM, Arun Gupta wrote:
>>> Can standalone.sh script be extended such that it takes an additional
>>> environment variable that is then added to JAVA_OPTS during startup?
>>>
>>> This can be used for passing additional Java options from WildFly
>>> Docker image. Cursory look at the script does not reveal anything like
>>> that exist.
>>>
>>> Arun
>>>
>>>
>
>


From fnasser at redhat.com  Wed Mar 18 08:48:07 2015
From: fnasser at redhat.com (Fernando Nasser)
Date: Wed, 18 Mar 2015 08:48:07 -0400
Subject: [wildfly-dev] MORE_JAVA_OPTS in standalone.sh
In-Reply-To: <CAGBoHQW7K0YekvjNVoWeRhEN6OEicG52FiEg6OTN6gjLWscijw@mail.gmail.com>
References: <CAGBoHQUSZY345Us-Eyzqz5aKHQmkgBUbt_dPyNqfxiWx+1ezjw@mail.gmail.com>	<55090B92.3040606@gmail.com>
	<CAGBoHQW7K0YekvjNVoWeRhEN6OEicG52FiEg6OTN6gjLWscijw@mail.gmail.com>
Message-ID: <55097407.1020402@redhat.com>

On 2015-03-18 8:42 AM, Arun Gupta wrote:
> I'd like to not override the default JAVA_OPTS used by WildFly,
> instead add my own value to it. I think that's where MORE_JAVA_OPTS or
> EXTRA_JAVA_OPTS could be useful.
>
> Copy/pasting the existing JAVA_OPTS and including my own does not feel right :)
JAVA_OPTS="${JAVA_OPTS} <your new args>"



>
> Arun
>
> On Tue, Mar 17, 2015 at 10:22 PM, Jaikiran Pai <jai.forums2013 at gmail.com> wrote:
>> Hi Arun,
>>
>> The WildFly startup scripts allow you to *override* the JAVA_OPTS by setting
>> an environment variable of that same name. See the standalone.conf (for *nix
>> OS) file for details. From what I see, there's no option to append to the
>> default JAVA_OPTS, by setting an environment variable. This could be worked
>> around (in a bit brittle manner) by setting the overriding environment
>> variable value to contain the default JAVA_OPTS (copied over from
>> standalone.conf) plus the other custom/specific ones that the caller wants
>> to pass.
>>
>> -Jaikiran
>>
>> On Wednesday 18 March 2015 10:27 AM, Arun Gupta wrote:
>>> Can standalone.sh script be extended such that it takes an additional
>>> environment variable that is then added to JAVA_OPTS during startup?
>>>
>>> This can be used for passing additional Java options from WildFly
>>> Docker image. Cursory look at the script does not reveal anything like
>>> that exist.
>>>
>>> Arun
>>>
>>>
>
>


From smarlow at redhat.com  Wed Mar 18 08:50:39 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 18 Mar 2015 08:50:39 -0400
Subject: [wildfly-dev] WF10 Deployment Changes
In-Reply-To: <20150318091226.GA77706@Nineveh.lan>
References: <48881ED3-A37A-413D-A976-A83E4E639553@redhat.com>
	<CAAoo=c4nqKSvDqxrh4qDpaCNNUedNS5izoSuaiOvQNPjHrKNoQ@mail.gmail.com>
	<5508440E.4050603@redhat.com> <5508B521.1030004@redhat.com>
	<20150318091226.GA77706@Nineveh.lan>
Message-ID: <5509749F.8000906@redhat.com>



On 03/18/2015 05:12 AM, Hardy Ferentschik wrote:
> On Tue, Mar 17, 2015 at 07:13:37PM -0400, Scott Marlow wrote:
>> Currently, Hibernate 4.3 is building its own Jandex IndexView [2] but we
>> could probably build/pass one in (via "hibernate.jandex_index"), so that
>> Hibernate won't build its own indexes anymore.  We discussed doing this
>> for integrating with Hibernate 5.0 (WFLY-3291) but the same should also
>> work for 4.3.x.
>
> Interesting, afair 4.3 does not use Jandex. I wonder whether there is really a
> need for Jandex in 4.3? I can see it contains the metamodel code, but that could
> be removed afaiu.

[1][2] shows that the ORM EntityManagerFactoryBuilderImpl is using 
Jandex.  We are using EntityManagerFactoryBuilderImpl to create the 
persistence unit in two phases (1st phase for enhancing/rewriting entity 
classes and 2nd phase later when other resources are available).

Scott

[1] 
https://github.com/hibernate/hibernate-orm/blob/4.3/hibernate-entitymanager/src/main/java/org/hibernate/jpa/boot/internal/EntityManagerFactoryBuilderImpl.java#L150

[2] 
https://github.com/hibernate/hibernate-orm/blob/4.3/hibernate-entitymanager/src/main/java/org/hibernate/jpa/boot/internal/EntityManagerFactoryBuilderImpl.java#L431
>
> --Hardy
>

From jai.forums2013 at gmail.com  Wed Mar 18 08:52:48 2015
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Wed, 18 Mar 2015 18:22:48 +0530
Subject: [wildfly-dev] MORE_JAVA_OPTS in standalone.sh
In-Reply-To: <55097407.1020402@redhat.com>
References: <CAGBoHQUSZY345Us-Eyzqz5aKHQmkgBUbt_dPyNqfxiWx+1ezjw@mail.gmail.com>	<55090B92.3040606@gmail.com>	<CAGBoHQW7K0YekvjNVoWeRhEN6OEicG52FiEg6OTN6gjLWscijw@mail.gmail.com>
	<55097407.1020402@redhat.com>
Message-ID: <55097520.6000004@gmail.com>


On Wednesday 18 March 2015 06:18 PM, Fernando Nasser wrote:
> On 2015-03-18 8:42 AM, Arun Gupta wrote:
>> I'd like to not override the default JAVA_OPTS used by WildFly,
>> instead add my own value to it. I think that's where MORE_JAVA_OPTS or
>> EXTRA_JAVA_OPTS could be useful.
>>
>> Copy/pasting the existing JAVA_OPTS and including my own does not feel right :)
> JAVA_OPTS="${JAVA_OPTS} <your new args>"

 From what I see in WildFly 8.2.0.Final standalone.conf script, that 
wouldn't work, since it has this 
https://github.com/wildfly/wildfly/blob/8.x/build/src/main/resources/bin/standalone.conf#L49 
:

#
# Specify options to pass to the Java VM.
#
if [ "x$JAVA_OPTS" = "x" ]; then
    JAVA_OPTS="-Xms64m -Xmx512m -XX:MaxPermSize=256m 
-Djava.net.preferIPv4Stack=true"
    JAVA_OPTS="$JAVA_OPTS 
-Djboss.modules.system.pkgs=$JBOSS_MODULES_SYSTEM_PKGS 
-Djava.awt.headless=true"
else
    echo "JAVA_OPTS already set in environment; overriding default 
settings with values: $JAVA_OPTS"
fi


-Jaikiran


>
>
>> Arun
>>
>> On Tue, Mar 17, 2015 at 10:22 PM, Jaikiran Pai <jai.forums2013 at gmail.com> wrote:
>>> Hi Arun,
>>>
>>> The WildFly startup scripts allow you to *override* the JAVA_OPTS by setting
>>> an environment variable of that same name. See the standalone.conf (for *nix
>>> OS) file for details. From what I see, there's no option to append to the
>>> default JAVA_OPTS, by setting an environment variable. This could be worked
>>> around (in a bit brittle manner) by setting the overriding environment
>>> variable value to contain the default JAVA_OPTS (copied over from
>>> standalone.conf) plus the other custom/specific ones that the caller wants
>>> to pass.
>>>
>>> -Jaikiran
>>>
>>> On Wednesday 18 March 2015 10:27 AM, Arun Gupta wrote:
>>>> Can standalone.sh script be extended such that it takes an additional
>>>> environment variable that is then added to JAVA_OPTS during startup?
>>>>
>>>> This can be used for passing additional Java options from WildFly
>>>> Docker image. Cursory look at the script does not reveal anything like
>>>> that exist.
>>>>
>>>> Arun
>>>>
>>>>
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From fnasser at redhat.com  Wed Mar 18 08:55:56 2015
From: fnasser at redhat.com (Fernando Nasser)
Date: Wed, 18 Mar 2015 08:55:56 -0400
Subject: [wildfly-dev] MORE_JAVA_OPTS in standalone.sh
In-Reply-To: <55097407.1020402@redhat.com>
References: <CAGBoHQUSZY345Us-Eyzqz5aKHQmkgBUbt_dPyNqfxiWx+1ezjw@mail.gmail.com>	<55090B92.3040606@gmail.com>	<CAGBoHQW7K0YekvjNVoWeRhEN6OEicG52FiEg6OTN6gjLWscijw@mail.gmail.com>
	<55097407.1020402@redhat.com>
Message-ID: <550975DC.1030603@redhat.com>

On 2015-03-18 8:48 AM, Fernando Nasser wrote:
> On 2015-03-18 8:42 AM, Arun Gupta wrote:
>> I'd like to not override the default JAVA_OPTS used by WildFly,
>> instead add my own value to it. I think that's where MORE_JAVA_OPTS or
>> EXTRA_JAVA_OPTS could be useful.
>>
>> Copy/pasting the existing JAVA_OPTS and including my own does not feel right :)
> JAVA_OPTS="${JAVA_OPTS} <your new args>"
Ah, I understand now, you don't want to modify your standalone.conf file.

Maybe we could source a custom .conf file so some additional changes 
could be made w/o touching the shipped one.

So after

if [ -r "$RUN_CONF" ]; then
     . "$RUN_CONF"
fi

we'd also source some other file CUSTOM_CONF to get any changes.

Fernando

>
>
>
>> Arun
>>
>> On Tue, Mar 17, 2015 at 10:22 PM, Jaikiran Pai <jai.forums2013 at gmail.com> wrote:
>>> Hi Arun,
>>>
>>> The WildFly startup scripts allow you to *override* the JAVA_OPTS by setting
>>> an environment variable of that same name. See the standalone.conf (for *nix
>>> OS) file for details. From what I see, there's no option to append to the
>>> default JAVA_OPTS, by setting an environment variable. This could be worked
>>> around (in a bit brittle manner) by setting the overriding environment
>>> variable value to contain the default JAVA_OPTS (copied over from
>>> standalone.conf) plus the other custom/specific ones that the caller wants
>>> to pass.
>>>
>>> -Jaikiran
>>>
>>> On Wednesday 18 March 2015 10:27 AM, Arun Gupta wrote:
>>>> Can standalone.sh script be extended such that it takes an additional
>>>> environment variable that is then added to JAVA_OPTS during startup?
>>>>
>>>> This can be used for passing additional Java options from WildFly
>>>> Docker image. Cursory look at the script does not reveal anything like
>>>> that exist.
>>>>
>>>> Arun
>>>>
>>>>
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>


From smarlow at redhat.com  Wed Mar 18 08:56:52 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 18 Mar 2015 08:56:52 -0400
Subject: [wildfly-dev] WF10 Deployment Changes
In-Reply-To: <5508BC83.9030303@redhat.com>
References: <48881ED3-A37A-413D-A976-A83E4E639553@redhat.com>	<CAAoo=c4nqKSvDqxrh4qDpaCNNUedNS5izoSuaiOvQNPjHrKNoQ@mail.gmail.com>	<5508440E.4050603@redhat.com>	<5508B521.1030004@redhat.com>
	<5508BC83.9030303@redhat.com>
Message-ID: <55097614.40306@redhat.com>



On 03/17/2015 07:45 PM, Scott Marlow wrote:
>>
>> Currently, Hibernate 4.3 is building its own Jandex IndexView [2] but we
>> could probably build/pass one in (via "hibernate.jandex_index"), so that
>> Hibernate won't build its own indexes anymore.  We discussed doing this
>> for integrating with Hibernate 5.0 (WFLY-3291) but the same should also
>> work for 4.3.x.
>>
>
> We cannot pass our Jandex indexes into Hibernate until the
> deployment-service-restart changes are merged into WildFly (or something
> like that).  On a partial restart, we will need access to the Jandex
> indexes, which need to be rebuilt (as already pointed out by Jason on
> this thread).

For WF 9, we could also try a hybrid approach.  Use the Jandex indexes 
when they are available (e.g. first time application is deployed) and 
let Hibernate build the Jandex indexes on a partial restart 
(Attachments.ANNOTATION_INDEX entries will not be found in deployment 
resource roots).

The downside of passing "hibernate.jandex_index" into Hibernate, is that 
both WildFly + Hibernate ORM, will need to use compatible Jandex jars.

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

From fnasser at redhat.com  Wed Mar 18 09:01:01 2015
From: fnasser at redhat.com (Fernando Nasser)
Date: Wed, 18 Mar 2015 09:01:01 -0400
Subject: [wildfly-dev] MORE_JAVA_OPTS in standalone.sh
In-Reply-To: <550975DC.1030603@redhat.com>
References: <CAGBoHQUSZY345Us-Eyzqz5aKHQmkgBUbt_dPyNqfxiWx+1ezjw@mail.gmail.com>	<55090B92.3040606@gmail.com>	<CAGBoHQW7K0YekvjNVoWeRhEN6OEicG52FiEg6OTN6gjLWscijw@mail.gmail.com>	<55097407.1020402@redhat.com>
	<550975DC.1030603@redhat.com>
Message-ID: <5509770D.7010605@redhat.com>

Maybe the original intention was not to have the configuration done in 
the server at all, so a new .conf file will not accomplish that.

If that is the case I'd propose a WILDFLY_EXTRA_JAVA_OPTS to prevent 
mixing up with any generic JAVA_OPTS that may be set  (or our nice test 
for a stray JAVA_OPTS would be moot).

Fernando


On 2015-03-18 8:55 AM, Fernando Nasser wrote:
> On 2015-03-18 8:48 AM, Fernando Nasser wrote:
>> On 2015-03-18 8:42 AM, Arun Gupta wrote:
>>> I'd like to not override the default JAVA_OPTS used by WildFly,
>>> instead add my own value to it. I think that's where MORE_JAVA_OPTS or
>>> EXTRA_JAVA_OPTS could be useful.
>>>
>>> Copy/pasting the existing JAVA_OPTS and including my own does not feel right :)
>> JAVA_OPTS="${JAVA_OPTS} <your new args>"
> Ah, I understand now, you don't want to modify your standalone.conf file.
>
> Maybe we could source a custom .conf file so some additional changes
> could be made w/o touching the shipped one.
>
> So after
>
> if [ -r "$RUN_CONF" ]; then
>       . "$RUN_CONF"
> fi
>
> we'd also source some other file CUSTOM_CONF to get any changes.
>
> Fernando
>
>>
>>
>>> Arun
>>>
>>> On Tue, Mar 17, 2015 at 10:22 PM, Jaikiran Pai <jai.forums2013 at gmail.com> wrote:
>>>> Hi Arun,
>>>>
>>>> The WildFly startup scripts allow you to *override* the JAVA_OPTS by setting
>>>> an environment variable of that same name. See the standalone.conf (for *nix
>>>> OS) file for details. From what I see, there's no option to append to the
>>>> default JAVA_OPTS, by setting an environment variable. This could be worked
>>>> around (in a bit brittle manner) by setting the overriding environment
>>>> variable value to contain the default JAVA_OPTS (copied over from
>>>> standalone.conf) plus the other custom/specific ones that the caller wants
>>>> to pass.
>>>>
>>>> -Jaikiran
>>>>
>>>> On Wednesday 18 March 2015 10:27 AM, Arun Gupta wrote:
>>>>> Can standalone.sh script be extended such that it takes an additional
>>>>> environment variable that is then added to JAVA_OPTS during startup?
>>>>>
>>>>> This can be used for passing additional Java options from WildFly
>>>>> Docker image. Cursory look at the script does not reveal anything like
>>>>> that exist.
>>>>>
>>>>> Arun
>>>>>
>>>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>


From darran.lofthouse at jboss.com  Wed Mar 18 09:57:32 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Wed, 18 Mar 2015 13:57:32 +0000
Subject: [wildfly-dev] MORE_JAVA_OPTS in standalone.sh
In-Reply-To: <CAGBoHQW7K0YekvjNVoWeRhEN6OEicG52FiEg6OTN6gjLWscijw@mail.gmail.com>
References: <CAGBoHQUSZY345Us-Eyzqz5aKHQmkgBUbt_dPyNqfxiWx+1ezjw@mail.gmail.com>	<55090B92.3040606@gmail.com>
	<CAGBoHQW7K0YekvjNVoWeRhEN6OEicG52FiEg6OTN6gjLWscijw@mail.gmail.com>
Message-ID: <5509844C.5010402@jboss.com>

One issue with that however is how you would cope with duplicate or 
conflicting options within the OPTS, all it could take is one conflict a 
script can not resolve and you are back to just defining the whole string.

Regards,
Darran Lofthouse.


On 18/03/15 12:42, Arun Gupta wrote:
> I'd like to not override the default JAVA_OPTS used by WildFly,
> instead add my own value to it. I think that's where MORE_JAVA_OPTS or
> EXTRA_JAVA_OPTS could be useful.
>
> Copy/pasting the existing JAVA_OPTS and including my own does not feel right :)
>
> Arun
>
> On Tue, Mar 17, 2015 at 10:22 PM, Jaikiran Pai <jai.forums2013 at gmail.com> wrote:
>> Hi Arun,
>>
>> The WildFly startup scripts allow you to *override* the JAVA_OPTS by setting
>> an environment variable of that same name. See the standalone.conf (for *nix
>> OS) file for details. From what I see, there's no option to append to the
>> default JAVA_OPTS, by setting an environment variable. This could be worked
>> around (in a bit brittle manner) by setting the overriding environment
>> variable value to contain the default JAVA_OPTS (copied over from
>> standalone.conf) plus the other custom/specific ones that the caller wants
>> to pass.
>>
>> -Jaikiran
>>
>> On Wednesday 18 March 2015 10:27 AM, Arun Gupta wrote:
>>>
>>> Can standalone.sh script be extended such that it takes an additional
>>> environment variable that is then added to JAVA_OPTS during startup?
>>>
>>> This can be used for passing additional Java options from WildFly
>>> Docker image. Cursory look at the script does not reveal anything like
>>> that exist.
>>>
>>> Arun
>>>
>>>
>>
>
>
>

From arun.gupta at gmail.com  Wed Mar 18 11:37:09 2015
From: arun.gupta at gmail.com (Arun Gupta)
Date: Wed, 18 Mar 2015 08:37:09 -0700
Subject: [wildfly-dev] MORE_JAVA_OPTS in standalone.sh
In-Reply-To: <550973E6.3040708@gmail.com>
References: <CAGBoHQUSZY345Us-Eyzqz5aKHQmkgBUbt_dPyNqfxiWx+1ezjw@mail.gmail.com>
	<55090B92.3040606@gmail.com>
	<CAGBoHQW7K0YekvjNVoWeRhEN6OEicG52FiEg6OTN6gjLWscijw@mail.gmail.com>
	<550973E6.3040708@gmail.com>
Message-ID: <CAGBoHQUV0nB6dKxj+7EgyVnXszFzoT7k69G9zmze=EB+0r+qoA@mail.gmail.com>

Done: https://issues.jboss.org/browse/WFLY-4442

On Wed, Mar 18, 2015 at 5:47 AM, Jaikiran Pai <jai.forums2013 at gmail.com> wrote:
> Fair enough. I vaguely recollect that a feature like this, was something
> that was either added in JBoss AS 4.2.x days or was proposed at that time.
> Looking at the current 8.x scripts, this isn't available, so IMO filing an
> enhancement might be a good idea.
>
> -Jaikiran
>
> On Wednesday 18 March 2015 06:12 PM, Arun Gupta wrote:
>>
>> I'd like to not override the default JAVA_OPTS used by WildFly,
>> instead add my own value to it. I think that's where MORE_JAVA_OPTS or
>> EXTRA_JAVA_OPTS could be useful.
>>
>> Copy/pasting the existing JAVA_OPTS and including my own does not feel
>> right :)
>>
>> Arun
>>
>> On Tue, Mar 17, 2015 at 10:22 PM, Jaikiran Pai <jai.forums2013 at gmail.com>
>> wrote:
>>>
>>> Hi Arun,
>>>
>>> The WildFly startup scripts allow you to *override* the JAVA_OPTS by
>>> setting
>>> an environment variable of that same name. See the standalone.conf (for
>>> *nix
>>> OS) file for details. From what I see, there's no option to append to the
>>> default JAVA_OPTS, by setting an environment variable. This could be
>>> worked
>>> around (in a bit brittle manner) by setting the overriding environment
>>> variable value to contain the default JAVA_OPTS (copied over from
>>> standalone.conf) plus the other custom/specific ones that the caller
>>> wants
>>> to pass.
>>>
>>> -Jaikiran
>>>
>>> On Wednesday 18 March 2015 10:27 AM, Arun Gupta wrote:
>>>>
>>>> Can standalone.sh script be extended such that it takes an additional
>>>> environment variable that is then added to JAVA_OPTS during startup?
>>>>
>>>> This can be used for passing additional Java options from WildFly
>>>> Docker image. Cursory look at the script does not reveal anything like
>>>> that exist.
>>>>
>>>> Arun
>>>>
>>>>
>>
>>
>



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

From jperkins at redhat.com  Wed Mar 18 12:08:36 2015
From: jperkins at redhat.com (James R. Perkins)
Date: Wed, 18 Mar 2015 09:08:36 -0700
Subject: [wildfly-dev] MORE_JAVA_OPTS in standalone.sh
In-Reply-To: <5509844C.5010402@jboss.com>
References: <CAGBoHQUSZY345Us-Eyzqz5aKHQmkgBUbt_dPyNqfxiWx+1ezjw@mail.gmail.com>	<55090B92.3040606@gmail.com>	<CAGBoHQW7K0YekvjNVoWeRhEN6OEicG52FiEg6OTN6gjLWscijw@mail.gmail.com>
	<5509844C.5010402@jboss.com>
Message-ID: <5509A304.3040500@redhat.com>

This will definitely be an issue. I can guarantee that some will want to 
replace one option that's already defined resulting in a duplicate. 
Processing the either option looking for duplicates is not an option. 
Every time we introduce something that requires scanning JAVA_OPTS it's 
extremely painful and error prone.

In docker wouldn't we just do something like:

RUN echo "JAVA_OPTS=\"$JAVA_OPTS -Dkey.value\"" >> 
$JBOSS_HOME/standalone.conf

On 03/18/2015 06:57 AM, Darran Lofthouse wrote:
> One issue with that however is how you would cope with duplicate or
> conflicting options within the OPTS, all it could take is one conflict a
> script can not resolve and you are back to just defining the whole string.
>
> Regards,
> Darran Lofthouse.
>
>
> On 18/03/15 12:42, Arun Gupta wrote:
>> I'd like to not override the default JAVA_OPTS used by WildFly,
>> instead add my own value to it. I think that's where MORE_JAVA_OPTS or
>> EXTRA_JAVA_OPTS could be useful.
>>
>> Copy/pasting the existing JAVA_OPTS and including my own does not feel right :)
>>
>> Arun
>>
>> On Tue, Mar 17, 2015 at 10:22 PM, Jaikiran Pai <jai.forums2013 at gmail.com> wrote:
>>> Hi Arun,
>>>
>>> The WildFly startup scripts allow you to *override* the JAVA_OPTS by setting
>>> an environment variable of that same name. See the standalone.conf (for *nix
>>> OS) file for details. From what I see, there's no option to append to the
>>> default JAVA_OPTS, by setting an environment variable. This could be worked
>>> around (in a bit brittle manner) by setting the overriding environment
>>> variable value to contain the default JAVA_OPTS (copied over from
>>> standalone.conf) plus the other custom/specific ones that the caller wants
>>> to pass.
>>>
>>> -Jaikiran
>>>
>>> On Wednesday 18 March 2015 10:27 AM, Arun Gupta wrote:
>>>> Can standalone.sh script be extended such that it takes an additional
>>>> environment variable that is then added to JAVA_OPTS during startup?
>>>>
>>>> This can be used for passing additional Java options from WildFly
>>>> Docker image. Cursory look at the script does not reveal anything like
>>>> that exist.
>>>>
>>>> Arun
>>>>
>>>>
>>
>>
> _______________________________________________
> 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 arun.gupta at gmail.com  Wed Mar 18 12:26:49 2015
From: arun.gupta at gmail.com (Arun Gupta)
Date: Wed, 18 Mar 2015 09:26:49 -0700
Subject: [wildfly-dev] MORE_JAVA_OPTS in standalone.sh
In-Reply-To: <5509A304.3040500@redhat.com>
References: <CAGBoHQUSZY345Us-Eyzqz5aKHQmkgBUbt_dPyNqfxiWx+1ezjw@mail.gmail.com>
	<55090B92.3040606@gmail.com>
	<CAGBoHQW7K0YekvjNVoWeRhEN6OEicG52FiEg6OTN6gjLWscijw@mail.gmail.com>
	<5509844C.5010402@jboss.com> <5509A304.3040500@redhat.com>
Message-ID: <CAGBoHQU2sKCdGzaSJ-7iTNcrmefPA42X6W5go6pZG+8qwy12ag@mail.gmail.com>

On Wed, Mar 18, 2015 at 9:08 AM, James R. Perkins <jperkins at redhat.com> wrote:
> This will definitely be an issue. I can guarantee that some will want to
> replace one option that's already defined resulting in a duplicate.
> Processing the either option looking for duplicates is not an option.
> Every time we introduce something that requires scanning JAVA_OPTS it's
> extremely painful and error prone.

Valid point.

How do we recommend users to specify JAVA_OPTS in that case? Edit
standalone.conf?

>
> In docker wouldn't we just do something like:
>
> RUN echo "JAVA_OPTS=\"$JAVA_OPTS -Dkey.value\"" >>
> $JBOSS_HOME/standalone.conf

This worked very well, thanks for the tip!

Arun

>
> On 03/18/2015 06:57 AM, Darran Lofthouse wrote:
>> One issue with that however is how you would cope with duplicate or
>> conflicting options within the OPTS, all it could take is one conflict a
>> script can not resolve and you are back to just defining the whole string.
>>
>> Regards,
>> Darran Lofthouse.
>>
>>
>> On 18/03/15 12:42, Arun Gupta wrote:
>>> I'd like to not override the default JAVA_OPTS used by WildFly,
>>> instead add my own value to it. I think that's where MORE_JAVA_OPTS or
>>> EXTRA_JAVA_OPTS could be useful.
>>>
>>> Copy/pasting the existing JAVA_OPTS and including my own does not feel right :)
>>>
>>> Arun
>>>
>>> On Tue, Mar 17, 2015 at 10:22 PM, Jaikiran Pai <jai.forums2013 at gmail.com> wrote:
>>>> Hi Arun,
>>>>
>>>> The WildFly startup scripts allow you to *override* the JAVA_OPTS by setting
>>>> an environment variable of that same name. See the standalone.conf (for *nix
>>>> OS) file for details. From what I see, there's no option to append to the
>>>> default JAVA_OPTS, by setting an environment variable. This could be worked
>>>> around (in a bit brittle manner) by setting the overriding environment
>>>> variable value to contain the default JAVA_OPTS (copied over from
>>>> standalone.conf) plus the other custom/specific ones that the caller wants
>>>> to pass.
>>>>
>>>> -Jaikiran
>>>>
>>>> On Wednesday 18 March 2015 10:27 AM, Arun Gupta wrote:
>>>>> Can standalone.sh script be extended such that it takes an additional
>>>>> environment variable that is then added to JAVA_OPTS during startup?
>>>>>
>>>>> This can be used for passing additional Java options from WildFly
>>>>> Docker image. Cursory look at the script does not reveal anything like
>>>>> that exist.
>>>>>
>>>>> Arun
>>>>>
>>>>>
>>>
>>>
>> _______________________________________________
>> 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



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

From jperkins at redhat.com  Wed Mar 18 12:29:53 2015
From: jperkins at redhat.com (James R. Perkins)
Date: Wed, 18 Mar 2015 09:29:53 -0700
Subject: [wildfly-dev] MORE_JAVA_OPTS in standalone.sh
In-Reply-To: <CAGBoHQU2sKCdGzaSJ-7iTNcrmefPA42X6W5go6pZG+8qwy12ag@mail.gmail.com>
References: <CAGBoHQUSZY345Us-Eyzqz5aKHQmkgBUbt_dPyNqfxiWx+1ezjw@mail.gmail.com>	<55090B92.3040606@gmail.com>	<CAGBoHQW7K0YekvjNVoWeRhEN6OEicG52FiEg6OTN6gjLWscijw@mail.gmail.com>	<5509844C.5010402@jboss.com>	<5509A304.3040500@redhat.com>
	<CAGBoHQU2sKCdGzaSJ-7iTNcrmefPA42X6W5go6pZG+8qwy12ag@mail.gmail.com>
Message-ID: <5509A801.9020904@redhat.com>



On 03/18/2015 09:26 AM, Arun Gupta wrote:
> On Wed, Mar 18, 2015 at 9:08 AM, James R. Perkins <jperkins at redhat.com> wrote:
>> This will definitely be an issue. I can guarantee that some will want to
>> replace one option that's already defined resulting in a duplicate.
>> Processing the either option looking for duplicates is not an option.
>> Every time we introduce something that requires scanning JAVA_OPTS it's
>> extremely painful and error prone.
> Valid point.
>
> How do we recommend users to specify JAVA_OPTS in that case? Edit
> standalone.conf?
For now yes. I say for now because I have an ultimate goal of removing 
most of the logic from the scripts in general :) Whether or not that 
will become reality has not yet been decided.
>
>> In docker wouldn't we just do something like:
>>
>> RUN echo "JAVA_OPTS=\"$JAVA_OPTS -Dkey.value\"" >>
>> $JBOSS_HOME/standalone.conf
> This worked very well, thanks for the tip!
Excellent!
>
> Arun
>
>>
>
>

-- 
James R. Perkins
JBoss by Red Hat


From wfink at redhat.com  Thu Mar 19 05:11:47 2015
From: wfink at redhat.com (Wolf-Dieter Fink)
Date: Thu, 19 Mar 2015 10:11:47 +0100
Subject: [wildfly-dev] WFLY-2422 or simplifying the remote outbound
 connection configuration for server to server communication
In-Reply-To: <54FDAD5C.2030600@redhat.com>
References: <54FDAD5C.2030600@redhat.com>
Message-ID: <550A92D3.9020909@redhat.com>

Any thoughts on this about the best/simplest/reasonable approach?

On 09/03/15 15:25, Wolf-Dieter Fink wrote:
> I start a request for simplifying the configuration for "in EE
> application" clients and get rid of extra cluster configuration and
> repeat properties many times.
> Also the client should not need to have knowledge about the server
> topology, there is no need to know how many servers there are or whether
> they are clustered or not.
>
> Starting point in EAP6/WF8 is a application configuration like this:
> https://github.com/wildfly/quickstart/blob/master/ejb-multi-server/app-main/ear/src/main/application/META-INF/jboss-ejb-client.xml?
>
> and a server side configuration like this:
>               <subsystem xmlns="urn:jboss:domain:remoting:3.0">
>                   <endpoint worker="default"/>
>                   <http-connector name="http-remoting-connector"
> connector-ref="default" security-realm="ApplicationRealm"/>
>                   <outbound-connections>
>                       <remote-outbound-connection
> name="remote-ejb-connection-1"
> outbound-socket-binding-ref="remote-ejb-1" username="quickuser1"
> security-realm="ejb-security-realm-1" protocol="http-remoting">
>                           <properties>
>                               <property name="SASL_POLICY_NOANONYMOUS"
> value="false"/>
>                               <property name="SSL_ENABLED" value="false"/>
>                           </properties>
>                       </remote-outbound-connection>
>                       <remote-outbound-connection
> name="remote-ejb-connection-2"
> outbound-socket-binding-ref="remote-ejb-2" username="quickuser2"
> security-realm="ejb-security-realm-2" protocol="http-remoting">
>                           <properties>
>                               <property name="SASL_POLICY_NOANONYMOUS"
> value="false"/>
>                               <property name="SSL_ENABLED" value="false"/>
>                           </properties>
>                       </remote-outbound-connection>
>                   </outbound-connections>
>               </subsystem>
>
>
>
> Tomasz did some refactoring (WF9) to use a profile from the application
> perspective. The configuration is like this:
>
> jboss-ejb-client.xml
>       <client-context>
>           <profile name="main-app"/>
>
>
>
> -- 
>
> Email: wfink at redhat.com
>
> Red Hat Customer Portal http://bit.ly/accessRH
> Twitter http://bit.ly/RHsupport
> Facebook - http://bit.ly/RHsupportFB
> Google+ http://bit.ly/RHsupportG
> ________________________________________________________________________
> Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
> Commercial register: Amtsgericht Muenchen, HRB 153243,
>
>
>       </client-context>
>
> server profile:
>                   <remote connector-ref="http-remoting-connector"
> thread-pool-name="default">
>                       <profiles>
>                           <profile name="main-app">
>                               <remoting-ejb-receiver name="AppOneA"
> outbound-connection-ref="remote-ejb-connection-1"/>
>                               <remoting-ejb-receiver name="AppTwoA"
> outbound-connection-ref="remote-ejb-connection-2"/>
>                           </profile>
>                       </profiles>
>                   </remote>
> ....
>               <subsystem xmlns="urn:jboss:domain:remoting:3.0">
>                   <outbound-connections>
>                       <remote-outbound-connection
> name="remote-ejb-connection-1"
> outbound-socket-binding-ref="remote-ejb-1" username="quickuser1"
> security-realm="ejb-security-realm-1" protocol="http-remoting">
>                           <properties>
>                               <property name="SASL_POLICY_NOANONYMOUS"
> value="false"/>
>                               <property name="SSL_ENABLED" value="false"/>
>                           </properties>
>                       </remote-outbound-connection>
>                       <remote-outbound-connection
> name="remote-ejb-connection-2"
> outbound-socket-binding-ref="remote-ejb-2" username="quickuser2"
> security-realm="ejb-security-realm-2" protocol="http-remoting">
>                           <properties>
>                               <property name="SASL_POLICY_NOANONYMOUS"
> value="false"/>
>                               <property name="SSL_ENABLED" value="false"/>
>                           </properties>
>                       </remote-outbound-connection>
>                   </outbound-connections>
>               </subsystem>
>
>
> With the current implementation there are some issues or
> concerns/enhancements
> - profile does not work with clusters
> - not possible to have multiple profiles
> - the properties/user must be still repeated
>
>
>
>   From my point of view
> - a cluster need to have the same property configuration, also different
> users make no sense. Might work, but at least the cluster view will use
> the same user
> - a similar group of servers for the same application should not have
> different properties/users as this will be error prone
> - configuration should be as small and intuitive as possible
>
> My initial idea was to have a jboss-ejb-client.xml which reference
> 'applications' to connect, that is similar to profiles
> The server side as followed (don't care about the exact XML elements or
> names)
>
>               <subsystem xmlns="urn:jboss:domain:remoting:3.0">
>                   <outbound-connections>
>                       <profile name="App1" username="quickuser1"
> security-realm="ejb-security-realm-1" protocol="http-remoting">
>                           <properties>
>                               <property name="SASL_POLICY_NOANONYMOUS"
> value="false"/>
>                               <property name="SSL_ENABLED" value="false"/>
>                           </properties>
> <outbound-sockets>remote-ejb-1,remote-ejb2</outbound-sockets> <!--
> repeated elements seems better -->
>                       </remote-outbound-connection>
>                       <remote-outbound-connection
> name="remote-ejb-connection-X"
> outbound-socket-binding-ref="remote-ejb-X" username="quickuser2"
> security-realm="ejb-security-realm-2" protocol="http-remoting">
>                           <properties>
>                               <property name="SASL_POLICY_NOANONYMOUS"
> value="false"/>
>                               <property name="SSL_ENABLED" value="false"/>
>                           </properties>
>                       </remote-outbound-connection>
>                   </outbound-connections>
>               </subsystem>
>
> In this case the profile use the user/security and properties for all
> connections and the cluster as well. In this it is necessary to have the
> same configuration for all the servers in the profile-bunch.
> Another option I thought about is to use the user/properties in
> <profile> as default and have the possibility to use a inner element
> remote-outbound-connection, or a reference to remote-outbound-connection
> which can override these, but I'm not sure whether this is needed.
>
> We (Tomasz Adamski and me) had a discussion about this and, technically
> there is no problem with each approach.
>
> But ...
>
> I know that all the ejb-client stuff is subject to change and to prevent
> from incompatible changes which are changed in every version
> and from unnecessary work if the code will be changed before it will be
> used at all
> I think it will need to be discussed with others because of this.
>
> cheers
> Wolf
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From darran.lofthouse at jboss.com  Thu Mar 19 06:20:09 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Thu, 19 Mar 2015 10:20:09 +0000
Subject: [wildfly-dev] Preparation for requirements and capabilities.
Message-ID: <550AA2D9.4040103@jboss.com>

Assuming the title still covers the scenarios I have in mind is there 
anything we can be doing now to prepare for requirements and 
capabilities support to make transitioning easier once it is available.

As an example within Elytron we will have a number of services that 
define either standard types or types defined by API that we want to 
inject - is there anything we can do today for subsystems that want to 
say "I want a type X, named Y injected here" whilst minimising 
interaction with and knowledge of the Elytron subsystem.

Secondly is there anything we can do at the model level regarding 
assisting the user with referential integrity, as an example say I am 
writing an attribute using the CLI called 'keystore', this is going to 
be a reference to a named KeyStore - how about some form of op 
associated with that attribute that can dynamically generate the list of 
accepted values on demand, e.g. by querying the model and finding out 
which KeyStores are actually available.

Regards,
Darran Lofthouse.

From jperkins at redhat.com  Thu Mar 19 12:23:14 2015
From: jperkins at redhat.com (James R. Perkins)
Date: Thu, 19 Mar 2015 09:23:14 -0700
Subject: [wildfly-dev] Preparation for requirements and capabilities.
In-Reply-To: <550AA2D9.4040103@jboss.com>
References: <550AA2D9.4040103@jboss.com>
Message-ID: <550AF7F2.60506@redhat.com>



On 03/19/2015 03:20 AM, Darran Lofthouse wrote:
> Assuming the title still covers the scenarios I have in mind is there
> anything we can be doing now to prepare for requirements and
> capabilities support to make transitioning easier once it is available.
>
> As an example within Elytron we will have a number of services that
> define either standard types or types defined by API that we want to
> inject - is there anything we can do today for subsystems that want to
> say "I want a type X, named Y injected here" whilst minimising
> interaction with and knowledge of the Elytron subsystem.
>
> Secondly is there anything we can do at the model level regarding
> assisting the user with referential integrity, as an example say I am
> writing an attribute using the CLI called 'keystore', this is going to
> be a reference to a named KeyStore - how about some form of op
> associated with that attribute that can dynamically generate the list of
> accepted values on demand, e.g. by querying the model and finding out
> which KeyStores are actually available.
Attributes can use an EnumValidator which allows only the values in an 
enum to be used. These work with tab complete in CLI as well. Would that 
solve the your issue? Or are you looking for the allowed values based on 
another resource?
>
> Regards,
> Darran Lofthouse.
> _______________________________________________
> 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 darran.lofthouse at jboss.com  Thu Mar 19 12:46:21 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Thu, 19 Mar 2015 16:46:21 +0000
Subject: [wildfly-dev] Preparation for requirements and capabilities.
In-Reply-To: <550AF7F2.60506@redhat.com>
References: <550AA2D9.4040103@jboss.com> <550AF7F2.60506@redhat.com>
Message-ID: <550AFD5D.4050105@jboss.com>



On 19/03/15 16:23, James R. Perkins wrote:
>
>
> On 03/19/2015 03:20 AM, Darran Lofthouse wrote:
>> Assuming the title still covers the scenarios I have in mind is there
>> anything we can be doing now to prepare for requirements and
>> capabilities support to make transitioning easier once it is available.
>>
>> As an example within Elytron we will have a number of services that
>> define either standard types or types defined by API that we want to
>> inject - is there anything we can do today for subsystems that want to
>> say "I want a type X, named Y injected here" whilst minimising
>> interaction with and knowledge of the Elytron subsystem.
>>
>> Secondly is there anything we can do at the model level regarding
>> assisting the user with referential integrity, as an example say I am
>> writing an attribute using the CLI called 'keystore', this is going to
>> be a reference to a named KeyStore - how about some form of op
>> associated with that attribute that can dynamically generate the list of
>> accepted values on demand, e.g. by querying the model and finding out
>> which KeyStores are actually available.
> Attributes can use an EnumValidator which allows only the values in an
> enum to be used. These work with tab complete in CLI as well. Would that
> solve the your issue? Or are you looking for the allowed values based on
> another resource?

Allowed based on other resources, also we probably need to accept values 
not in the allowed list as it could be a compound op adding the 
acceptable resource.

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

From jperkins at redhat.com  Thu Mar 19 12:58:35 2015
From: jperkins at redhat.com (James R. Perkins)
Date: Thu, 19 Mar 2015 09:58:35 -0700
Subject: [wildfly-dev] Preparation for requirements and capabilities.
In-Reply-To: <550AFD5D.4050105@jboss.com>
References: <550AA2D9.4040103@jboss.com> <550AF7F2.60506@redhat.com>
	<550AFD5D.4050105@jboss.com>
Message-ID: <550B003B.1020704@redhat.com>



On 03/19/2015 09:46 AM, Darran Lofthouse wrote:
>
> On 19/03/15 16:23, James R. Perkins wrote:
>>
>> On 03/19/2015 03:20 AM, Darran Lofthouse wrote:
>>> Assuming the title still covers the scenarios I have in mind is there
>>> anything we can be doing now to prepare for requirements and
>>> capabilities support to make transitioning easier once it is available.
>>>
>>> As an example within Elytron we will have a number of services that
>>> define either standard types or types defined by API that we want to
>>> inject - is there anything we can do today for subsystems that want to
>>> say "I want a type X, named Y injected here" whilst minimising
>>> interaction with and knowledge of the Elytron subsystem.
>>>
>>> Secondly is there anything we can do at the model level regarding
>>> assisting the user with referential integrity, as an example say I am
>>> writing an attribute using the CLI called 'keystore', this is going to
>>> be a reference to a named KeyStore - how about some form of op
>>> associated with that attribute that can dynamically generate the list of
>>> accepted values on demand, e.g. by querying the model and finding out
>>> which KeyStores are actually available.
>> Attributes can use an EnumValidator which allows only the values in an
>> enum to be used. These work with tab complete in CLI as well. Would that
>> solve the your issue? Or are you looking for the allowed values based on
>> another resource?
> Allowed based on other resources, also we probably need to accept values
> not in the allowed list as it could be a compound op adding the
> acceptable resource.
Ah okay. As far as I know then there is nothing available for that. I've 
thought about possibly looking at creating a custom tab completer for my 
use case, but I haven't really spent any time looking at it.
>>> 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

-- 
James R. Perkins
JBoss by Red Hat


From darran.lofthouse at jboss.com  Thu Mar 19 13:08:57 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Thu, 19 Mar 2015 17:08:57 +0000
Subject: [wildfly-dev] Preparation for requirements and capabilities.
In-Reply-To: <550AA2D9.4040103@jboss.com>
References: <550AA2D9.4040103@jboss.com>
Message-ID: <550B02A9.6050508@jboss.com>

On 19/03/15 10:20, Darran Lofthouse wrote:
> Assuming the title still covers the scenarios I have in mind is there
> anything we can be doing now to prepare for requirements and
> capabilities support to make transitioning easier once it is available.
>
> As an example within Elytron we will have a number of services that
> define either standard types or types defined by API that we want to
> inject - is there anything we can do today for subsystems that want to
> say "I want a type X, named Y injected here" whilst minimising
> interaction with and knowledge of the Elytron subsystem.

For the service naming issue I have one idea, I create a utility class 
in wildfly-core with the following method: -

public static ServiceName createServiceName(Class<?> type,
     String simpleName);

The type here is the type that the service returns, this methods 
constructs a ServiceName taking into account the class name of the type 
and the supplied simpleName which really is just it's reference.

Within the Elytron subsystem I install services by using this method to 
construct the names.

For any other service that depends on one of these types the same method 
is used when creating the dependency.

This way details of the Elytron subsystem do not leak out to other 
subsystems.

> Secondly is there anything we can do at the model level regarding
> assisting the user with referential integrity, as an example say I am
> writing an attribute using the CLI called 'keystore', this is going to
> be a reference to a named KeyStore - how about some form of op
> associated with that attribute that can dynamically generate the list of
> accepted values on demand, e.g. by querying the model and finding out
> which KeyStores are actually available.
>
> 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  Tue Mar 24 09:48:43 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 24 Mar 2015 08:48:43 -0500
Subject: [wildfly-dev] Preparation for requirements and capabilities.
In-Reply-To: <550AA2D9.4040103@jboss.com>
References: <550AA2D9.4040103@jboss.com>
Message-ID: <55116B3B.8090802@redhat.com>

On 3/19/15 5:20 AM, Darran Lofthouse wrote:
> Assuming the title still covers the scenarios I have in mind is there
> anything we can be doing now to prepare for requirements and
> capabilities support to make transitioning easier once it is available.
>
> As an example within Elytron we will have a number of services that
> define either standard types or types defined by API that we want to
> inject - is there anything we can do today for subsystems that want to
> say "I want a type X, named Y injected here" whilst minimising
> interaction with and knowledge of the Elytron subsystem.
>

I'll respond to your second post separately.

I'll be getting back to the capability and requirement stuff full time 
as soon as I'm done with WFCORE-282; hopefully I'll finish that this week.

Are the types Elytron will provide even available, with impls available 
that the current code can also provide? If so, then I guess what you are 
looking for is some way to switch how the service names are determined 
so when Elytron comes in it all just works?

> Secondly is there anything we can do at the model level regarding
> assisting the user with referential integrity, as an example say I am
> writing an attribute using the CLI called 'keystore', this is going to
> be a reference to a named KeyStore - how about some form of op
> associated with that attribute that can dynamically generate the list of
> accepted values on demand, e.g. by querying the model and finding out
> which KeyStores are actually available.
>

That's definitely my intent; information about the available 
capabilities will be available as management resources, including the 
instance names registered in each capability's namespace. "Model 
reference" attributes will include in their metadata the name of the 
capability they reference. With that data available the CLI tab 
completion stuff should be able to determine the currently available names.

I don't see this aspect as blocking Elytron work in any way though. It's 
a feature that would have been useful in many areas since AS 7.0.

> 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 brian.stansberry at redhat.com  Tue Mar 24 10:24:47 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 24 Mar 2015 09:24:47 -0500
Subject: [wildfly-dev] Preparation for requirements and capabilities.
In-Reply-To: <550B02A9.6050508@jboss.com>
References: <550AA2D9.4040103@jboss.com> <550B02A9.6050508@jboss.com>
Message-ID: <551173AF.4040101@redhat.com>

On 3/19/15 12:08 PM, Darran Lofthouse wrote:
> On 19/03/15 10:20, Darran Lofthouse wrote:
>> Assuming the title still covers the scenarios I have in mind is there
>> anything we can be doing now to prepare for requirements and
>> capabilities support to make transitioning easier once it is available.
>>
>> As an example within Elytron we will have a number of services that
>> define either standard types or types defined by API that we want to
>> inject - is there anything we can do today for subsystems that want to
>> say "I want a type X, named Y injected here" whilst minimising
>> interaction with and knowledge of the Elytron subsystem.
>
> For the service naming issue I have one idea, I create a utility class
> in wildfly-core with the following method: -
>
> public static ServiceName createServiceName(Class<?> type,
>       String simpleName);
>
> The type here is the type that the service returns, this methods
> constructs a ServiceName taking into account the class name of the type
> and the supplied simpleName which really is just it's reference.
>
> Within the Elytron subsystem I install services by using this method to
> construct the names.
>
> For any other service that depends on one of these types the same method
> is used when creating the dependency.
>
> This way details of the Elytron subsystem do not leak out to other
> subsystems.
>

I like the notion of both the capability code and the requiring code 
turning over the mechanics of service name creation to the core. I 
expect that will go into the OperationContext though, as it has the 
knowledge of what capabilities exist. If it's purely a mechanical 
function though with no validation required it could just go in some 
static method somewhere, but it's likely in the real use cases there 
will be some validation.

I don't see a type as being valid data for creating a ServiceName. There 
isn't a 1:1 correspondence between a type and the various things that 
can provide services whose value is of that type. Simplest case being 
Service<Void>, but I bet we have some Service<String> out there.

If we limit a capability to providing just a single type for injections, 
then it can just be:

public ServiceName getServiceName(String capability, String instanceName)

A capability provides a namespace, as does the prefix for a ServiceName 
so it seems reasonable enough to me to reuse one for the other. 
Particularly if it's all hidden behind a method the core provides.

I was a bit reluctant to limit a capability to providing just a single 
injection type, as there are some cases where it's a bit fine grained. 
For example IIOP provides both an ORB and a CORBA NamingContextExt. But 
I don't think there are enough such cases to outweigh the simplicity 
advantages of having a single injection type per capability.

>> Secondly is there anything we can do at the model level regarding
>> assisting the user with referential integrity, as an example say I am
>> writing an attribute using the CLI called 'keystore', this is going to
>> be a reference to a named KeyStore - how about some form of op
>> associated with that attribute that can dynamically generate the list of
>> accepted values on demand, e.g. by querying the model and finding out
>> which KeyStores are actually available.
>>
>> 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  Tue Mar 24 10:28:27 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Tue, 24 Mar 2015 14:28:27 +0000
Subject: [wildfly-dev] Preparation for requirements and capabilities.
In-Reply-To: <55116B3B.8090802@redhat.com>
References: <550AA2D9.4040103@jboss.com> <55116B3B.8090802@redhat.com>
Message-ID: <5511748B.3040804@jboss.com>



On 24/03/15 13:48, Brian Stansberry wrote:
> On 3/19/15 5:20 AM, Darran Lofthouse wrote:
>> Assuming the title still covers the scenarios I have in mind is there
>> anything we can be doing now to prepare for requirements and
>> capabilities support to make transitioning easier once it is available.
>>
>> As an example within Elytron we will have a number of services that
>> define either standard types or types defined by API that we want to
>> inject - is there anything we can do today for subsystems that want to
>> say "I want a type X, named Y injected here" whilst minimising
>> interaction with and knowledge of the Elytron subsystem.
>>
>
> I'll respond to your second post separately.
>
> I'll be getting back to the capability and requirement stuff full time
> as soon as I'm done with WFCORE-282; hopefully I'll finish that this week.
>
> Are the types Elytron will provide even available, with impls available
> that the current code can also provide? If so, then I guess what you are
> looking for is some way to switch how the service names are determined
> so when Elytron comes in it all just works?
>
>> Secondly is there anything we can do at the model level regarding
>> assisting the user with referential integrity, as an example say I am
>> writing an attribute using the CLI called 'keystore', this is going to
>> be a reference to a named KeyStore - how about some form of op
>> associated with that attribute that can dynamically generate the list of
>> accepted values on demand, e.g. by querying the model and finding out
>> which KeyStores are actually available.

The types will be referenceable without the subsystem i.e. we are 
talking about standard Java types or types defined within the Elytron 
project.  Without the subsystem the impls will not exist, the point 
being that once resources reference a named capability it will need to 
exist but until that point it is an optional reference.

We will have some transitioning between old and new but my main point 
here is everything that gets secures will need to know about Elytron but 
nothing should know about it's subsystem.


> That's definitely my intent; information about the available
> capabilities will be available as management resources, including the
> instance names registered in each capability's namespace. "Model
> reference" attributes will include in their metadata the name of the
> capability they reference. With that data available the CLI tab
> completion stuff should be able to determine the currently available names.
>
> I don't see this aspect as blocking Elytron work in any way though. It's
> a feature that would have been useful in many areas since AS 7.0.

+1 This one is not blocking Elytron work, this part of the questions is 
more to check if there is anything I can be doing to assist this but it 
sounds like that may not be necessary.

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

From darran.lofthouse at jboss.com  Tue Mar 24 10:33:08 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Tue, 24 Mar 2015 14:33:08 +0000
Subject: [wildfly-dev] Preparation for requirements and capabilities.
In-Reply-To: <551173AF.4040101@redhat.com>
References: <550AA2D9.4040103@jboss.com> <550B02A9.6050508@jboss.com>
	<551173AF.4040101@redhat.com>
Message-ID: <551175A4.1000409@jboss.com>



On 24/03/15 14:24, Brian Stansberry wrote:
> On 3/19/15 12:08 PM, Darran Lofthouse wrote:
>> On 19/03/15 10:20, Darran Lofthouse wrote:
>>> Assuming the title still covers the scenarios I have in mind is there
>>> anything we can be doing now to prepare for requirements and
>>> capabilities support to make transitioning easier once it is available.
>>>
>>> As an example within Elytron we will have a number of services that
>>> define either standard types or types defined by API that we want to
>>> inject - is there anything we can do today for subsystems that want to
>>> say "I want a type X, named Y injected here" whilst minimising
>>> interaction with and knowledge of the Elytron subsystem.
>>
>> For the service naming issue I have one idea, I create a utility class
>> in wildfly-core with the following method: -
>>
>> public static ServiceName createServiceName(Class<?> type,
>>        String simpleName);
>>
>> The type here is the type that the service returns, this methods
>> constructs a ServiceName taking into account the class name of the type
>> and the supplied simpleName which really is just it's reference.
>>
>> Within the Elytron subsystem I install services by using this method to
>> construct the names.
>>
>> For any other service that depends on one of these types the same method
>> is used when creating the dependency.
>>
>> This way details of the Elytron subsystem do not leak out to other
>> subsystems.
>>
>
> I like the notion of both the capability code and the requiring code
> turning over the mechanics of service name creation to the core. I
> expect that will go into the OperationContext though, as it has the
> knowledge of what capabilities exist. If it's purely a mechanical
> function though with no validation required it could just go in some
> static method somewhere, but it's likely in the real use cases there
> will be some validation.
>
> I don't see a type as being valid data for creating a ServiceName. There
> isn't a 1:1 correspondence between a type and the various things that
> can provide services whose value is of that type. Simplest case being
> Service<Void>, but I bet we have some Service<String> out there.
>
> If we limit a capability to providing just a single type for injections,
> then it can just be:
>
> public ServiceName getServiceName(String capability, String instanceName)
>
> A capability provides a namespace, as does the prefix for a ServiceName
> so it seems reasonable enough to me to reuse one for the other.
> Particularly if it's all hidden behind a method the core provides.
>
> I was a bit reluctant to limit a capability to providing just a single
> injection type, as there are some cases where it's a bit fine grained.
> For example IIOP provides both an ORB and a CORBA NamingContextExt. But
> I don't think there are enough such cases to outweigh the simplicity
> advantages of having a single injection type per capability.

+1 Take my suggestion extremely lightly, that was only going to be a 
temporary step towards being capability based - from your other e-mail 
it sounds like that is going to be actively developed now so I can just 
use the real thing.

I am at the point now where I am starting to wire things together in the 
server and have just started an incubation fork of wildfly-core for my 
development so let me know if there is anything you want me to try out.

>>> Secondly is there anything we can do at the model level regarding
>>> assisting the user with referential integrity, as an example say I am
>>> writing an attribute using the CLI called 'keystore', this is going to
>>> be a reference to a named KeyStore - how about some form of op
>>> associated with that attribute that can dynamically generate the list of
>>> accepted values on demand, e.g. by querying the model and finding out
>>> which KeyStores are actually available.
>>>
>>> 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 brian.stansberry at redhat.com  Tue Mar 24 10:41:03 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 24 Mar 2015 09:41:03 -0500
Subject: [wildfly-dev] Preparation for requirements and capabilities.
In-Reply-To: <551175A4.1000409@jboss.com>
References: <550AA2D9.4040103@jboss.com>
	<550B02A9.6050508@jboss.com>	<551173AF.4040101@redhat.com>
	<551175A4.1000409@jboss.com>
Message-ID: <5511777F.9040005@redhat.com>

On 3/24/15 9:33 AM, Darran Lofthouse wrote:
>
>
> On 24/03/15 14:24, Brian Stansberry wrote:
>> On 3/19/15 12:08 PM, Darran Lofthouse wrote:
>>> On 19/03/15 10:20, Darran Lofthouse wrote:
>>>> Assuming the title still covers the scenarios I have in mind is there
>>>> anything we can be doing now to prepare for requirements and
>>>> capabilities support to make transitioning easier once it is available.
>>>>
>>>> As an example within Elytron we will have a number of services that
>>>> define either standard types or types defined by API that we want to
>>>> inject - is there anything we can do today for subsystems that want to
>>>> say "I want a type X, named Y injected here" whilst minimising
>>>> interaction with and knowledge of the Elytron subsystem.
>>>
>>> For the service naming issue I have one idea, I create a utility class
>>> in wildfly-core with the following method: -
>>>
>>> public static ServiceName createServiceName(Class<?> type,
>>>         String simpleName);
>>>
>>> The type here is the type that the service returns, this methods
>>> constructs a ServiceName taking into account the class name of the type
>>> and the supplied simpleName which really is just it's reference.
>>>
>>> Within the Elytron subsystem I install services by using this method to
>>> construct the names.
>>>
>>> For any other service that depends on one of these types the same method
>>> is used when creating the dependency.
>>>
>>> This way details of the Elytron subsystem do not leak out to other
>>> subsystems.
>>>
>>
>> I like the notion of both the capability code and the requiring code
>> turning over the mechanics of service name creation to the core. I
>> expect that will go into the OperationContext though, as it has the
>> knowledge of what capabilities exist. If it's purely a mechanical
>> function though with no validation required it could just go in some
>> static method somewhere, but it's likely in the real use cases there
>> will be some validation.
>>
>> I don't see a type as being valid data for creating a ServiceName. There
>> isn't a 1:1 correspondence between a type and the various things that
>> can provide services whose value is of that type. Simplest case being
>> Service<Void>, but I bet we have some Service<String> out there.
>>
>> If we limit a capability to providing just a single type for injections,
>> then it can just be:
>>
>> public ServiceName getServiceName(String capability, String instanceName)
>>
>> A capability provides a namespace, as does the prefix for a ServiceName
>> so it seems reasonable enough to me to reuse one for the other.
>> Particularly if it's all hidden behind a method the core provides.
>>
>> I was a bit reluctant to limit a capability to providing just a single
>> injection type, as there are some cases where it's a bit fine grained.
>> For example IIOP provides both an ORB and a CORBA NamingContextExt. But
>> I don't think there are enough such cases to outweigh the simplicity
>> advantages of having a single injection type per capability.
>
> +1 Take my suggestion extremely lightly, that was only going to be a
> temporary step towards being capability based - from your other e-mail
> it sounds like that is going to be actively developed now so I can just
> use the real thing.
>

Yes, it will be. I did a fair amount last summer/fall but then hit a 
point where I wanted to let ideas percolate, plus I had to do a lot of 
other tasks. But I think enough percolation has happened (including your 
helpful suggestion above) and the list other stuff I've had to do is 
getting short.

> I am at the point now where I am starting to wire things together in the
> server and have just started an incubation fork of wildfly-core for my
> development so let me know if there is anything you want me to try out.
>

Thanks; I'll do that for sure.

>>>> Secondly is there anything we can do at the model level regarding
>>>> assisting the user with referential integrity, as an example say I am
>>>> writing an attribute using the CLI called 'keystore', this is going to
>>>> be a reference to a named KeyStore - how about some form of op
>>>> associated with that attribute that can dynamically generate the list of
>>>> accepted values on demand, e.g. by querying the model and finding out
>>>> which KeyStores are actually available.
>>>>
>>>> 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
>


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

From darran.lofthouse at jboss.com  Tue Mar 24 14:08:45 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Tue, 24 Mar 2015 18:08:45 +0000
Subject: [wildfly-dev] Preparation for requirements and capabilities.
In-Reply-To: <5511777F.9040005@redhat.com>
References: <550AA2D9.4040103@jboss.com>	<550B02A9.6050508@jboss.com>	<551173AF.4040101@redhat.com>	<551175A4.1000409@jboss.com>
	<5511777F.9040005@redhat.com>
Message-ID: <5511A82D.9000704@jboss.com>

My first questions in this area are - What are the constraints going to 
be about unique naming of capabilities?  Will the implementation / API 
provide methods a subsystem can use to help enforce this?

When it comes to resource definitions the definition can either be 
focused on the implementation behind the service or the type the service 
returns.  My preference is to focus on the implementation.

As an example I have a few different security realm implementations: -

keystore-realm=*
ldap-realm=*
jaas-realm=*

All of these would register a service that returns 'SecurityRealm' so 
'SecurityRealm' would be the capability.

So this is really the basis of my question as now the model does not 
enforce unique names.  The reason for this type of split is so each can 
have it's own set of attribute definitions.

If I turned this on it's head and have: -

security-realm=*

Now the model will enforce unique names within my subsystem but I have 
lost the association of type specific attributes.  A security realm 
could support all attribute types but now it becomes hard to work with 
and understand what does what depending on the type.  Or I could add a 
child resource for type specific settings but that moves away from my 
aim of a 1:1 mapping between resource and service.

Although the model enforces unique names this is specific to my 
subsystem only, if another subsystem is also capable of supplying 
SecurityRealm implementations duplicates are again possible.

So overall my preference would be let capabilities and requirements 
worry about naming constraints and leave subsystem implementations to 
focus on understandable typed resources.

Regards,
Darran Lofthouse.




On 24/03/15 14:41, Brian Stansberry wrote:
> On 3/24/15 9:33 AM, Darran Lofthouse wrote:
>>
>>
>> On 24/03/15 14:24, Brian Stansberry wrote:
>>> On 3/19/15 12:08 PM, Darran Lofthouse wrote:
>>>> On 19/03/15 10:20, Darran Lofthouse wrote:
>>>>> Assuming the title still covers the scenarios I have in mind is there
>>>>> anything we can be doing now to prepare for requirements and
>>>>> capabilities support to make transitioning easier once it is available.
>>>>>
>>>>> As an example within Elytron we will have a number of services that
>>>>> define either standard types or types defined by API that we want to
>>>>> inject - is there anything we can do today for subsystems that want to
>>>>> say "I want a type X, named Y injected here" whilst minimising
>>>>> interaction with and knowledge of the Elytron subsystem.
>>>>
>>>> For the service naming issue I have one idea, I create a utility class
>>>> in wildfly-core with the following method: -
>>>>
>>>> public static ServiceName createServiceName(Class<?> type,
>>>>          String simpleName);
>>>>
>>>> The type here is the type that the service returns, this methods
>>>> constructs a ServiceName taking into account the class name of the type
>>>> and the supplied simpleName which really is just it's reference.
>>>>
>>>> Within the Elytron subsystem I install services by using this method to
>>>> construct the names.
>>>>
>>>> For any other service that depends on one of these types the same method
>>>> is used when creating the dependency.
>>>>
>>>> This way details of the Elytron subsystem do not leak out to other
>>>> subsystems.
>>>>
>>>
>>> I like the notion of both the capability code and the requiring code
>>> turning over the mechanics of service name creation to the core. I
>>> expect that will go into the OperationContext though, as it has the
>>> knowledge of what capabilities exist. If it's purely a mechanical
>>> function though with no validation required it could just go in some
>>> static method somewhere, but it's likely in the real use cases there
>>> will be some validation.
>>>
>>> I don't see a type as being valid data for creating a ServiceName. There
>>> isn't a 1:1 correspondence between a type and the various things that
>>> can provide services whose value is of that type. Simplest case being
>>> Service<Void>, but I bet we have some Service<String> out there.
>>>
>>> If we limit a capability to providing just a single type for injections,
>>> then it can just be:
>>>
>>> public ServiceName getServiceName(String capability, String instanceName)
>>>
>>> A capability provides a namespace, as does the prefix for a ServiceName
>>> so it seems reasonable enough to me to reuse one for the other.
>>> Particularly if it's all hidden behind a method the core provides.
>>>
>>> I was a bit reluctant to limit a capability to providing just a single
>>> injection type, as there are some cases where it's a bit fine grained.
>>> For example IIOP provides both an ORB and a CORBA NamingContextExt. But
>>> I don't think there are enough such cases to outweigh the simplicity
>>> advantages of having a single injection type per capability.
>>
>> +1 Take my suggestion extremely lightly, that was only going to be a
>> temporary step towards being capability based - from your other e-mail
>> it sounds like that is going to be actively developed now so I can just
>> use the real thing.
>>
>
> Yes, it will be. I did a fair amount last summer/fall but then hit a
> point where I wanted to let ideas percolate, plus I had to do a lot of
> other tasks. But I think enough percolation has happened (including your
> helpful suggestion above) and the list other stuff I've had to do is
> getting short.
>
>> I am at the point now where I am starting to wire things together in the
>> server and have just started an incubation fork of wildfly-core for my
>> development so let me know if there is anything you want me to try out.
>>
>
> Thanks; I'll do that for sure.
>
>>>>> Secondly is there anything we can do at the model level regarding
>>>>> assisting the user with referential integrity, as an example say I am
>>>>> writing an attribute using the CLI called 'keystore', this is going to
>>>>> be a reference to a named KeyStore - how about some form of op
>>>>> associated with that attribute that can dynamically generate the list of
>>>>> accepted values on demand, e.g. by querying the model and finding out
>>>>> which KeyStores are actually available.
>>>>>
>>>>> 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 brian.stansberry at redhat.com  Tue Mar 24 16:11:46 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 24 Mar 2015 15:11:46 -0500
Subject: [wildfly-dev] Preparation for requirements and capabilities.
In-Reply-To: <5511A82D.9000704@jboss.com>
References: <550AA2D9.4040103@jboss.com>	<550B02A9.6050508@jboss.com>	<551173AF.4040101@redhat.com>	<551175A4.1000409@jboss.com>	<5511777F.9040005@redhat.com>
	<5511A82D.9000704@jboss.com>
Message-ID: <5511C502.2060306@redhat.com>

On 3/24/15 1:08 PM, Darran Lofthouse wrote:
> My first questions in this area are - What are the constraints going to
> be about unique naming of capabilities?

They must be namespaced. See 
https://developer.jboss.org/wiki/CoreAndSubsystemCapabilitiesAndRequirements.

The ones we provide must be in the org.wildfly namespace, which is 
reserved for us. Use org.wildfly.extension.xxxx for stuff this is 
provided by an extension, and isn't part of the kernel.

(OT: I'm going to start using the term 'kernel' to mean what used to be 
called the 'core' since now WildFly Core means the kernel plus a few 
subsystems.)

> Will the implementation / API
> provide methods a subsystem can use to help enforce this?
>

The OperationContext will enforce uniqueness. I don't think a subsystem 
will help enforce this; the subsystem authors will just create a 
reasonable namespace and stick to it.

> When it comes to resource definitions the definition can either be
> focused on the implementation behind the service or the type the service
> returns.  My preference is to focus on the implementation.
>
> As an example I have a few different security realm implementations: -
>
> keystore-realm=*
> ldap-realm=*
> jaas-realm=*
>
> All of these would register a service that returns 'SecurityRealm' so
> 'SecurityRealm' would be the capability.
>
> So this is really the basis of my question as now the model does not
> enforce unique names.  The reason for this type of split is so each can
> have it's own set of attribute definitions.
>
> If I turned this on it's head and have: -
>
> security-realm=*
>
> Now the model will enforce unique names within my subsystem but I have
> lost the association of type specific attributes.  A security realm
> could support all attribute types but now it becomes hard to work with
> and understand what does what depending on the type.  Or I could add a
> child resource for type specific settings but that moves away from my
> aim of a 1:1 mapping between resource and service.
>
> Although the model enforces unique names this is specific to my
> subsystem only, if another subsystem is also capable of supplying
> SecurityRealm implementations duplicates are again possible.
>

Within a given context (i.e. a standalone server or a domain profile) 
some other subsystem providing a capability with the same name will not 
be allowed. If someone else wants to provide access to 
Service<SecurityRealm> for some unrelated reason then they need to 
provide their own capability name. If they are actually another 
implementation of the same capability, then the user has to pick one or 
the other within a context.

> So overall my preference would be let capabilities and requirements
> worry about naming constraints and leave subsystem implementations to
> focus on understandable typed resources.
>

That's fine. If keystore-realm=* et al are all providing instances of 
the same capability, then the OperationContext can enforce that as part 
of model validation by detecting duplicate instance names registered 
within a single capability namespace.

Having keystore-realm=*, ldap-realm=*, jaas-realm=* all registering 
instance names in the same capability namespace will add some complexity 
to the validation though, so thanks for pointing that use case out. The 
complexity is discriminating your use case (legal) from two completely 
different subsystems using the same namespace in the same context 
(illegal). A possible solution is the parent resource for those is what 
declares that it provides capability org.wildfly.extension.xxx and then 
the kernel accepts instance name registrations from children, while 
rejecting them from non-children.

> Regards,
> Darran Lofthouse.
>
>
>
>
> On 24/03/15 14:41, Brian Stansberry wrote:
>> On 3/24/15 9:33 AM, Darran Lofthouse wrote:
>>>
>>>
>>> On 24/03/15 14:24, Brian Stansberry wrote:
>>>> On 3/19/15 12:08 PM, Darran Lofthouse wrote:
>>>>> On 19/03/15 10:20, Darran Lofthouse wrote:
>>>>>> Assuming the title still covers the scenarios I have in mind is there
>>>>>> anything we can be doing now to prepare for requirements and
>>>>>> capabilities support to make transitioning easier once it is available.
>>>>>>
>>>>>> As an example within Elytron we will have a number of services that
>>>>>> define either standard types or types defined by API that we want to
>>>>>> inject - is there anything we can do today for subsystems that want to
>>>>>> say "I want a type X, named Y injected here" whilst minimising
>>>>>> interaction with and knowledge of the Elytron subsystem.
>>>>>
>>>>> For the service naming issue I have one idea, I create a utility class
>>>>> in wildfly-core with the following method: -
>>>>>
>>>>> public static ServiceName createServiceName(Class<?> type,
>>>>>           String simpleName);
>>>>>
>>>>> The type here is the type that the service returns, this methods
>>>>> constructs a ServiceName taking into account the class name of the type
>>>>> and the supplied simpleName which really is just it's reference.
>>>>>
>>>>> Within the Elytron subsystem I install services by using this method to
>>>>> construct the names.
>>>>>
>>>>> For any other service that depends on one of these types the same method
>>>>> is used when creating the dependency.
>>>>>
>>>>> This way details of the Elytron subsystem do not leak out to other
>>>>> subsystems.
>>>>>
>>>>
>>>> I like the notion of both the capability code and the requiring code
>>>> turning over the mechanics of service name creation to the core. I
>>>> expect that will go into the OperationContext though, as it has the
>>>> knowledge of what capabilities exist. If it's purely a mechanical
>>>> function though with no validation required it could just go in some
>>>> static method somewhere, but it's likely in the real use cases there
>>>> will be some validation.
>>>>
>>>> I don't see a type as being valid data for creating a ServiceName. There
>>>> isn't a 1:1 correspondence between a type and the various things that
>>>> can provide services whose value is of that type. Simplest case being
>>>> Service<Void>, but I bet we have some Service<String> out there.
>>>>
>>>> If we limit a capability to providing just a single type for injections,
>>>> then it can just be:
>>>>
>>>> public ServiceName getServiceName(String capability, String instanceName)
>>>>
>>>> A capability provides a namespace, as does the prefix for a ServiceName
>>>> so it seems reasonable enough to me to reuse one for the other.
>>>> Particularly if it's all hidden behind a method the core provides.
>>>>
>>>> I was a bit reluctant to limit a capability to providing just a single
>>>> injection type, as there are some cases where it's a bit fine grained.
>>>> For example IIOP provides both an ORB and a CORBA NamingContextExt. But
>>>> I don't think there are enough such cases to outweigh the simplicity
>>>> advantages of having a single injection type per capability.
>>>
>>> +1 Take my suggestion extremely lightly, that was only going to be a
>>> temporary step towards being capability based - from your other e-mail
>>> it sounds like that is going to be actively developed now so I can just
>>> use the real thing.
>>>
>>
>> Yes, it will be. I did a fair amount last summer/fall but then hit a
>> point where I wanted to let ideas percolate, plus I had to do a lot of
>> other tasks. But I think enough percolation has happened (including your
>> helpful suggestion above) and the list other stuff I've had to do is
>> getting short.
>>
>>> I am at the point now where I am starting to wire things together in the
>>> server and have just started an incubation fork of wildfly-core for my
>>> development so let me know if there is anything you want me to try out.
>>>
>>
>> Thanks; I'll do that for sure.
>>
>>>>>> Secondly is there anything we can do at the model level regarding
>>>>>> assisting the user with referential integrity, as an example say I am
>>>>>> writing an attribute using the CLI called 'keystore', this is going to
>>>>>> be a reference to a named KeyStore - how about some form of op
>>>>>> associated with that attribute that can dynamically generate the list of
>>>>>> accepted values on demand, e.g. by querying the model and finding out
>>>>>> which KeyStores are actually available.
>>>>>>
>>>>>> 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
>


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

From darran.lofthouse at jboss.com  Wed Mar 25 08:01:56 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Wed, 25 Mar 2015 12:01:56 +0000
Subject: [wildfly-dev] Preparation for requirements and capabilities.
In-Reply-To: <5511C502.2060306@redhat.com>
References: <550AA2D9.4040103@jboss.com>	<550B02A9.6050508@jboss.com>	<551173AF.4040101@redhat.com>	<551175A4.1000409@jboss.com>	<5511777F.9040005@redhat.com>	<5511A82D.9000704@jboss.com>
	<5511C502.2060306@redhat.com>
Message-ID: <5512A3B4.2010609@jboss.com>




On 24/03/15 20:11, Brian Stansberry wrote:
 > On 3/24/15 1:08 PM, Darran Lofthouse wrote:
 >> My first questions in this area are - What are the constraints going to
 >> be about unique naming of capabilities?
 >
 > They must be namespaced. See
 > 
https://developer.jboss.org/wiki/CoreAndSubsystemCapabilitiesAndRequirements.
 >
 > The ones we provide must be in the org.wildfly namespace, which is
 > reserved for us. Use org.wildfly.extension.xxxx for stuff this is
 > provided by an extension, and isn't part of the kernel.
 >
 > (OT: I'm going to start using the term 'kernel' to mean what used to be
 > called the 'core' since now WildFly Core means the kernel plus a few
 > subsystems.)

(OT: Personally I wish kernel was it's own build )

 >
 >> Will the implementation / API
 >> provide methods a subsystem can use to help enforce this?
 >>
 >
 > The OperationContext will enforce uniqueness. I don't think a subsystem
 > will help enforce this; the subsystem authors will just create a
 > reasonable namespace and stick to it.

I may be thinking of this the opposite way around, or it may be that my 
capabilities are more ingrained with the application server as a whole.

In the case of Elytron I think we have a successful API/SPI separation 
if we can say the Elytron Subsystem is optional, primarily this gives us 
two different situations: -
  - No capabilities provided and nothing requiring them - essentially a 
completely unsecured server.
  - An alternative subsystem providing all of the capabilities, maybe 
this is a pure KeyCloak server or maybe an ISV wants the security 
tightly built on their product.

As I type this having the namespace defined by the subsystem is probably 
not an issue provided that every place say a security realm can be 
referenced this is a qualified reference including the namespace.  Also 
the discovery of available security realms would need to take into 
account different namespaces being available.

(OT:  Wonder if we should think about access control here, I am waiting 
till I have the majority of the model in place to really look into it 
but we do have the issue of no longer being able to tell which parts of 
security are app and which parts are management)

 >> When it comes to resource definitions the definition can either be
 >> focused on the implementation behind the service or the type the service
 >> returns.  My preference is to focus on the implementation.
 >>
 >> As an example I have a few different security realm implementations: -
 >>
 >> keystore-realm=*
 >> ldap-realm=*
 >> jaas-realm=*
 >>
 >> All of these would register a service that returns 'SecurityRealm' so
 >> 'SecurityRealm' would be the capability.
 >>
 >> So this is really the basis of my question as now the model does not
 >> enforce unique names.  The reason for this type of split is so each can
 >> have it's own set of attribute definitions.
 >>
 >> If I turned this on it's head and have: -
 >>
 >> security-realm=*
 >>
 >> Now the model will enforce unique names within my subsystem but I have
 >> lost the association of type specific attributes.  A security realm
 >> could support all attribute types but now it becomes hard to work with
 >> and understand what does what depending on the type.  Or I could add a
 >> child resource for type specific settings but that moves away from my
 >> aim of a 1:1 mapping between resource and service.
 >>
 >> Although the model enforces unique names this is specific to my
 >> subsystem only, if another subsystem is also capable of supplying
 >> SecurityRealm implementations duplicates are again possible.
 >>
 >
 > Within a given context (i.e. a standalone server or a domain profile)
 > some other subsystem providing a capability with the same name will not
 > be allowed. If someone else wants to provide access to
 > Service<SecurityRealm> for some unrelated reason then they need to
 > provide their own capability name. If they are actually another
 > implementation of the same capability, then the user has to pick one or
 > the other within a context.
 >
 >> So overall my preference would be let capabilities and requirements
 >> worry about naming constraints and leave subsystem implementations to
 >> focus on understandable typed resources.
 >>
 >
 > That's fine. If keystore-realm=* et al are all providing instances of
 > the same capability, then the OperationContext can enforce that as part
 > of model validation by detecting duplicate instance names registered
 > within a single capability namespace.
 >
 > Having keystore-realm=*, ldap-realm=*, jaas-realm=* all registering
 > instance names in the same capability namespace will add some complexity
 > to the validation though, so thanks for pointing that use case out. The
 > complexity is discriminating your use case (legal) from two completely
 > different subsystems using the same namespace in the same context
 > (illegal). A possible solution is the parent resource for those is what
 > declares that it provides capability org.wildfly.extension.xxx and then
 > the kernel accepts instance name registrations from children, while
 > rejecting them from non-children.
 >
 >> Regards,
 >> Darran Lofthouse.
 >>
 >>
 >>
 >>
 >> On 24/03/15 14:41, Brian Stansberry wrote:
 >>> On 3/24/15 9:33 AM, Darran Lofthouse wrote:
 >>>>
 >>>>
 >>>> On 24/03/15 14:24, Brian Stansberry wrote:
 >>>>> On 3/19/15 12:08 PM, Darran Lofthouse wrote:
 >>>>>> On 19/03/15 10:20, Darran Lofthouse wrote:
 >>>>>>> Assuming the title still covers the scenarios I have in mind is 
there
 >>>>>>> anything we can be doing now to prepare for requirements and
 >>>>>>> capabilities support to make transitioning easier once it is 
available.
 >>>>>>>
 >>>>>>> As an example within Elytron we will have a number of services that
 >>>>>>> define either standard types or types defined by API that we 
want to
 >>>>>>> inject - is there anything we can do today for subsystems that 
want to
 >>>>>>> say "I want a type X, named Y injected here" whilst minimising
 >>>>>>> interaction with and knowledge of the Elytron subsystem.
 >>>>>>
 >>>>>> For the service naming issue I have one idea, I create a utility 
class
 >>>>>> in wildfly-core with the following method: -
 >>>>>>
 >>>>>> public static ServiceName createServiceName(Class<?> type,
 >>>>>>            String simpleName);
 >>>>>>
 >>>>>> The type here is the type that the service returns, this methods
 >>>>>> constructs a ServiceName taking into account the class name of 
the type
 >>>>>> and the supplied simpleName which really is just it's reference.
 >>>>>>
 >>>>>> Within the Elytron subsystem I install services by using this 
method to
 >>>>>> construct the names.
 >>>>>>
 >>>>>> For any other service that depends on one of these types the 
same method
 >>>>>> is used when creating the dependency.
 >>>>>>
 >>>>>> This way details of the Elytron subsystem do not leak out to other
 >>>>>> subsystems.
 >>>>>>
 >>>>>
 >>>>> I like the notion of both the capability code and the requiring code
 >>>>> turning over the mechanics of service name creation to the core. I
 >>>>> expect that will go into the OperationContext though, as it has the
 >>>>> knowledge of what capabilities exist. If it's purely a mechanical
 >>>>> function though with no validation required it could just go in some
 >>>>> static method somewhere, but it's likely in the real use cases there
 >>>>> will be some validation.
 >>>>>
 >>>>> I don't see a type as being valid data for creating a 
ServiceName. There
 >>>>> isn't a 1:1 correspondence between a type and the various things that
 >>>>> can provide services whose value is of that type. Simplest case being
 >>>>> Service<Void>, but I bet we have some Service<String> out there.
 >>>>>
 >>>>> If we limit a capability to providing just a single type for 
injections,
 >>>>> then it can just be:
 >>>>>
 >>>>> public ServiceName getServiceName(String capability, String 
instanceName)
 >>>>>
 >>>>> A capability provides a namespace, as does the prefix for a 
ServiceName
 >>>>> so it seems reasonable enough to me to reuse one for the other.
 >>>>> Particularly if it's all hidden behind a method the core provides.
 >>>>>
 >>>>> I was a bit reluctant to limit a capability to providing just a 
single
 >>>>> injection type, as there are some cases where it's a bit fine 
grained.
 >>>>> For example IIOP provides both an ORB and a CORBA 
NamingContextExt. But
 >>>>> I don't think there are enough such cases to outweigh the simplicity
 >>>>> advantages of having a single injection type per capability.
 >>>>
 >>>> +1 Take my suggestion extremely lightly, that was only going to be a
 >>>> temporary step towards being capability based - from your other e-mail
 >>>> it sounds like that is going to be actively developed now so I can 
just
 >>>> use the real thing.
 >>>>
 >>>
 >>> Yes, it will be. I did a fair amount last summer/fall but then hit a
 >>> point where I wanted to let ideas percolate, plus I had to do a lot of
 >>> other tasks. But I think enough percolation has happened (including 
your
 >>> helpful suggestion above) and the list other stuff I've had to do is
 >>> getting short.
 >>>
 >>>> I am at the point now where I am starting to wire things together 
in the
 >>>> server and have just started an incubation fork of wildfly-core for my
 >>>> development so let me know if there is anything you want me to try 
out.
 >>>>
 >>>
 >>> Thanks; I'll do that for sure.
 >>>
 >>>>>>> Secondly is there anything we can do at the model level regarding
 >>>>>>> assisting the user with referential integrity, as an example 
say I am
 >>>>>>> writing an attribute using the CLI called 'keystore', this is 
going to
 >>>>>>> be a reference to a named KeyStore - how about some form of op
 >>>>>>> associated with that attribute that can dynamically generate 
the list of
 >>>>>>> accepted values on demand, e.g. by querying the model and 
finding out
 >>>>>>> which KeyStores are actually available.
 >>>>>>>
 >>>>>>> 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 david.lloyd at redhat.com  Wed Mar 25 10:15:03 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Wed, 25 Mar 2015 09:15:03 -0500
Subject: [wildfly-dev] Preparation for requirements and capabilities.
In-Reply-To: <5511C502.2060306@redhat.com>
References: <550AA2D9.4040103@jboss.com>	<550B02A9.6050508@jboss.com>	<551173AF.4040101@redhat.com>	<551175A4.1000409@jboss.com>	<5511777F.9040005@redhat.com>	<5511A82D.9000704@jboss.com>
	<5511C502.2060306@redhat.com>
Message-ID: <5512C2E7.50509@redhat.com>

On 03/24/2015 03:11 PM, Brian Stansberry wrote:
> On 3/24/15 1:08 PM, Darran Lofthouse wrote:
>> My first questions in this area are - What are the constraints going to
>> be about unique naming of capabilities?
>
> They must be namespaced. See
> https://developer.jboss.org/wiki/CoreAndSubsystemCapabilitiesAndRequirements.
>
> The ones we provide must be in the org.wildfly namespace, which is
> reserved for us. Use org.wildfly.extension.xxxx for stuff this is
> provided by an extension, and isn't part of the kernel.
>
> (OT: I'm going to start using the term 'kernel' to mean what used to be
> called the 'core' since now WildFly Core means the kernel plus a few
> subsystems.)
>
>> Will the implementation / API
>> provide methods a subsystem can use to help enforce this?
>>
>
> The OperationContext will enforce uniqueness. I don't think a subsystem
> will help enforce this; the subsystem authors will just create a
> reasonable namespace and stick to it.
>
>> When it comes to resource definitions the definition can either be
>> focused on the implementation behind the service or the type the service
>> returns.  My preference is to focus on the implementation.
>>
>> As an example I have a few different security realm implementations: -
>>
>> keystore-realm=*
>> ldap-realm=*
>> jaas-realm=*
>>
>> All of these would register a service that returns 'SecurityRealm' so
>> 'SecurityRealm' would be the capability.
>>
>> So this is really the basis of my question as now the model does not
>> enforce unique names.  The reason for this type of split is so each can
>> have it's own set of attribute definitions.
>>
>> If I turned this on it's head and have: -
>>
>> security-realm=*
>>
>> Now the model will enforce unique names within my subsystem but I have
>> lost the association of type specific attributes.  A security realm
>> could support all attribute types but now it becomes hard to work with
>> and understand what does what depending on the type.  Or I could add a
>> child resource for type specific settings but that moves away from my
>> aim of a 1:1 mapping between resource and service.
>>
>> Although the model enforces unique names this is specific to my
>> subsystem only, if another subsystem is also capable of supplying
>> SecurityRealm implementations duplicates are again possible.
>>
>
> Within a given context (i.e. a standalone server or a domain profile)
> some other subsystem providing a capability with the same name will not
> be allowed. If someone else wants to provide access to
> Service<SecurityRealm> for some unrelated reason then they need to
> provide their own capability name. If they are actually another
> implementation of the same capability, then the user has to pick one or
> the other within a context.
>
>> So overall my preference would be let capabilities and requirements
>> worry about naming constraints and leave subsystem implementations to
>> focus on understandable typed resources.
>>
>
> That's fine. If keystore-realm=* et al are all providing instances of
> the same capability, then the OperationContext can enforce that as part
> of model validation by detecting duplicate instance names registered
> within a single capability namespace.
>
> Having keystore-realm=*, ldap-realm=*, jaas-realm=* all registering
> instance names in the same capability namespace will add some complexity
> to the validation though, so thanks for pointing that use case out. The
> complexity is discriminating your use case (legal) from two completely
> different subsystems using the same namespace in the same context
> (illegal). A possible solution is the parent resource for those is what
> declares that it provides capability org.wildfly.extension.xxx and then
> the kernel accepts instance name registrations from children, while
> rejecting them from non-children.

The thing is that some things will require specific types and some will 
allow the general type.  So the simple solution is, each realm shall 
register two capabilities, one being the generic security-realm=myname 
and the other being type-specific, ldap-realm=myname.  This way things 
which allow the generic type can use it, whereas things which require 
ldap can require that.  Additional "levels" can be added in the event 
that there is a hierarchy of types.  This allows the simpler mechanism 
to accommodate complex use cases.

>> Regards,
>> Darran Lofthouse.
>>
>>
>>
>>
>> On 24/03/15 14:41, Brian Stansberry wrote:
>>> On 3/24/15 9:33 AM, Darran Lofthouse wrote:
>>>>
>>>>
>>>> On 24/03/15 14:24, Brian Stansberry wrote:
>>>>> On 3/19/15 12:08 PM, Darran Lofthouse wrote:
>>>>>> On 19/03/15 10:20, Darran Lofthouse wrote:
>>>>>>> Assuming the title still covers the scenarios I have in mind is there
>>>>>>> anything we can be doing now to prepare for requirements and
>>>>>>> capabilities support to make transitioning easier once it is available.
>>>>>>>
>>>>>>> As an example within Elytron we will have a number of services that
>>>>>>> define either standard types or types defined by API that we want to
>>>>>>> inject - is there anything we can do today for subsystems that want to
>>>>>>> say "I want a type X, named Y injected here" whilst minimising
>>>>>>> interaction with and knowledge of the Elytron subsystem.
>>>>>>
>>>>>> For the service naming issue I have one idea, I create a utility class
>>>>>> in wildfly-core with the following method: -
>>>>>>
>>>>>> public static ServiceName createServiceName(Class<?> type,
>>>>>>            String simpleName);
>>>>>>
>>>>>> The type here is the type that the service returns, this methods
>>>>>> constructs a ServiceName taking into account the class name of the type
>>>>>> and the supplied simpleName which really is just it's reference.
>>>>>>
>>>>>> Within the Elytron subsystem I install services by using this method to
>>>>>> construct the names.
>>>>>>
>>>>>> For any other service that depends on one of these types the same method
>>>>>> is used when creating the dependency.
>>>>>>
>>>>>> This way details of the Elytron subsystem do not leak out to other
>>>>>> subsystems.
>>>>>>
>>>>>
>>>>> I like the notion of both the capability code and the requiring code
>>>>> turning over the mechanics of service name creation to the core. I
>>>>> expect that will go into the OperationContext though, as it has the
>>>>> knowledge of what capabilities exist. If it's purely a mechanical
>>>>> function though with no validation required it could just go in some
>>>>> static method somewhere, but it's likely in the real use cases there
>>>>> will be some validation.
>>>>>
>>>>> I don't see a type as being valid data for creating a ServiceName. There
>>>>> isn't a 1:1 correspondence between a type and the various things that
>>>>> can provide services whose value is of that type. Simplest case being
>>>>> Service<Void>, but I bet we have some Service<String> out there.
>>>>>
>>>>> If we limit a capability to providing just a single type for injections,
>>>>> then it can just be:
>>>>>
>>>>> public ServiceName getServiceName(String capability, String instanceName)
>>>>>
>>>>> A capability provides a namespace, as does the prefix for a ServiceName
>>>>> so it seems reasonable enough to me to reuse one for the other.
>>>>> Particularly if it's all hidden behind a method the core provides.
>>>>>
>>>>> I was a bit reluctant to limit a capability to providing just a single
>>>>> injection type, as there are some cases where it's a bit fine grained.
>>>>> For example IIOP provides both an ORB and a CORBA NamingContextExt. But
>>>>> I don't think there are enough such cases to outweigh the simplicity
>>>>> advantages of having a single injection type per capability.
>>>>
>>>> +1 Take my suggestion extremely lightly, that was only going to be a
>>>> temporary step towards being capability based - from your other e-mail
>>>> it sounds like that is going to be actively developed now so I can just
>>>> use the real thing.
>>>>
>>>
>>> Yes, it will be. I did a fair amount last summer/fall but then hit a
>>> point where I wanted to let ideas percolate, plus I had to do a lot of
>>> other tasks. But I think enough percolation has happened (including your
>>> helpful suggestion above) and the list other stuff I've had to do is
>>> getting short.
>>>
>>>> I am at the point now where I am starting to wire things together in the
>>>> server and have just started an incubation fork of wildfly-core for my
>>>> development so let me know if there is anything you want me to try out.
>>>>
>>>
>>> Thanks; I'll do that for sure.
>>>
>>>>>>> Secondly is there anything we can do at the model level regarding
>>>>>>> assisting the user with referential integrity, as an example say I am
>>>>>>> writing an attribute using the CLI called 'keystore', this is going to
>>>>>>> be a reference to a named KeyStore - how about some form of op
>>>>>>> associated with that attribute that can dynamically generate the list of
>>>>>>> accepted values on demand, e.g. by querying the model and finding out
>>>>>>> which KeyStores are actually available.
>>>>>>>
>>>>>>> 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
>>
>
>

-- 
- DML

From brian.stansberry at redhat.com  Wed Mar 25 10:28:59 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 25 Mar 2015 09:28:59 -0500
Subject: [wildfly-dev] Preparation for requirements and capabilities.
In-Reply-To: <5512A3B4.2010609@jboss.com>
References: <550AA2D9.4040103@jboss.com>	<550B02A9.6050508@jboss.com>	<551173AF.4040101@redhat.com>	<551175A4.1000409@jboss.com>	<5511777F.9040005@redhat.com>	<5511A82D.9000704@jboss.com>	<5511C502.2060306@redhat.com>
	<5512A3B4.2010609@jboss.com>
Message-ID: <5512C62B.2040007@redhat.com>

On 3/25/15 7:01 AM, Darran Lofthouse wrote:
>
>
>
> On 24/03/15 20:11, Brian Stansberry wrote:
>   > On 3/24/15 1:08 PM, Darran Lofthouse wrote:
>   >> My first questions in this area are - What are the constraints going to
>   >> be about unique naming of capabilities?
>   >
>   > They must be namespaced. See
>   >
> https://developer.jboss.org/wiki/CoreAndSubsystemCapabilitiesAndRequirements.
>   >
>   > The ones we provide must be in the org.wildfly namespace, which is
>   > reserved for us. Use org.wildfly.extension.xxxx for stuff this is
>   > provided by an extension, and isn't part of the kernel.
>   >
>   > (OT: I'm going to start using the term 'kernel' to mean what used to be
>   > called the 'core' since now WildFly Core means the kernel plus a few
>   > subsystems.)
>
> (OT: Personally I wish kernel was it's own build )
>
>   >
>   >> Will the implementation / API
>   >> provide methods a subsystem can use to help enforce this?
>   >>
>   >
>   > The OperationContext will enforce uniqueness. I don't think a subsystem
>   > will help enforce this; the subsystem authors will just create a
>   > reasonable namespace and stick to it.
>
> I may be thinking of this the opposite way around, or it may be that my
> capabilities are more ingrained with the application server as a whole.
>
> In the case of Elytron I think we have a successful API/SPI separation
> if we can say the Elytron Subsystem is optional, primarily this gives us
> two different situations: -
>    - No capabilities provided and nothing requiring them - essentially a
> completely unsecured server.
>    - An alternative subsystem providing all of the capabilities, maybe
> this is a pure KeyCloak server or maybe an ISV wants the security
> tightly built on their product.
>
> As I type this having the namespace defined by the subsystem is probably
> not an issue provided that every place say a security realm can be
> referenced this is a qualified reference including the namespace.  Also
> the discovery of available security realms would need to take into
> account different namespaces being available.
>

I think it's best to decouple the concepts of capabilities and subsystems.

A capability is a form of API/SPI. It has a name, and it can provide an 
API. (Note that this API is not limited to service injection; we do 
other things in other cases.)

A subsystem can provide a capability, but that doesn't mean it has to 
"own" the capability. There can be a capability named 
org.wildfly.extension.security.security-realm that is owned by the 
WildFly dev team, but that doesn't mean the Elytron subsystem has to own 
it. Someone else could provide it as well. This is logically analogous 
to some library providing an API/SPI and then also an impl.

If the user configures two providers of the same capability in the same 
context, it's a configuration error. The server will reject that. Over 
time hopefully provisioning tooling will come along that will reject it 
in advance.

If some consumer of capabilities just wants Service<SecurityRealm> and 
doesn't care which of a menu of capabilities provides it, I consider 
that to be corner case detail, and something to be handled by that 
consumer (by registering an optional requirement for each and using 
whichever is available.)


> (OT:  Wonder if we should think about access control here, I am waiting
> till I have the majority of the model in place to really look into it
> but we do have the issue of no longer being able to tell which parts of
> security are app and which parts are management)
>
>   >> When it comes to resource definitions the definition can either be
>   >> focused on the implementation behind the service or the type the service
>   >> returns.  My preference is to focus on the implementation.
>   >>
>   >> As an example I have a few different security realm implementations: -
>   >>
>   >> keystore-realm=*
>   >> ldap-realm=*
>   >> jaas-realm=*
>   >>
>   >> All of these would register a service that returns 'SecurityRealm' so
>   >> 'SecurityRealm' would be the capability.
>   >>
>   >> So this is really the basis of my question as now the model does not
>   >> enforce unique names.  The reason for this type of split is so each can
>   >> have it's own set of attribute definitions.
>   >>
>   >> If I turned this on it's head and have: -
>   >>
>   >> security-realm=*
>   >>
>   >> Now the model will enforce unique names within my subsystem but I have
>   >> lost the association of type specific attributes.  A security realm
>   >> could support all attribute types but now it becomes hard to work with
>   >> and understand what does what depending on the type.  Or I could add a
>   >> child resource for type specific settings but that moves away from my
>   >> aim of a 1:1 mapping between resource and service.
>   >>
>   >> Although the model enforces unique names this is specific to my
>   >> subsystem only, if another subsystem is also capable of supplying
>   >> SecurityRealm implementations duplicates are again possible.
>   >>
>   >
>   > Within a given context (i.e. a standalone server or a domain profile)
>   > some other subsystem providing a capability with the same name will not
>   > be allowed. If someone else wants to provide access to
>   > Service<SecurityRealm> for some unrelated reason then they need to
>   > provide their own capability name. If they are actually another
>   > implementation of the same capability, then the user has to pick one or
>   > the other within a context.
>   >
>   >> So overall my preference would be let capabilities and requirements
>   >> worry about naming constraints and leave subsystem implementations to
>   >> focus on understandable typed resources.
>   >>
>   >
>   > That's fine. If keystore-realm=* et al are all providing instances of
>   > the same capability, then the OperationContext can enforce that as part
>   > of model validation by detecting duplicate instance names registered
>   > within a single capability namespace.
>   >
>   > Having keystore-realm=*, ldap-realm=*, jaas-realm=* all registering
>   > instance names in the same capability namespace will add some complexity
>   > to the validation though, so thanks for pointing that use case out. The
>   > complexity is discriminating your use case (legal) from two completely
>   > different subsystems using the same namespace in the same context
>   > (illegal). A possible solution is the parent resource for those is what
>   > declares that it provides capability org.wildfly.extension.xxx and then
>   > the kernel accepts instance name registrations from children, while
>   > rejecting them from non-children.
>   >
>   >> Regards,
>   >> Darran Lofthouse.
>   >>
>   >>
>   >>
>   >>
>   >> On 24/03/15 14:41, Brian Stansberry wrote:
>   >>> On 3/24/15 9:33 AM, Darran Lofthouse wrote:
>   >>>>
>   >>>>
>   >>>> On 24/03/15 14:24, Brian Stansberry wrote:
>   >>>>> On 3/19/15 12:08 PM, Darran Lofthouse wrote:
>   >>>>>> On 19/03/15 10:20, Darran Lofthouse wrote:
>   >>>>>>> Assuming the title still covers the scenarios I have in mind is
> there
>   >>>>>>> anything we can be doing now to prepare for requirements and
>   >>>>>>> capabilities support to make transitioning easier once it is
> available.
>   >>>>>>>
>   >>>>>>> As an example within Elytron we will have a number of services that
>   >>>>>>> define either standard types or types defined by API that we
> want to
>   >>>>>>> inject - is there anything we can do today for subsystems that
> want to
>   >>>>>>> say "I want a type X, named Y injected here" whilst minimising
>   >>>>>>> interaction with and knowledge of the Elytron subsystem.
>   >>>>>>
>   >>>>>> For the service naming issue I have one idea, I create a utility
> class
>   >>>>>> in wildfly-core with the following method: -
>   >>>>>>
>   >>>>>> public static ServiceName createServiceName(Class<?> type,
>   >>>>>>            String simpleName);
>   >>>>>>
>   >>>>>> The type here is the type that the service returns, this methods
>   >>>>>> constructs a ServiceName taking into account the class name of
> the type
>   >>>>>> and the supplied simpleName which really is just it's reference.
>   >>>>>>
>   >>>>>> Within the Elytron subsystem I install services by using this
> method to
>   >>>>>> construct the names.
>   >>>>>>
>   >>>>>> For any other service that depends on one of these types the
> same method
>   >>>>>> is used when creating the dependency.
>   >>>>>>
>   >>>>>> This way details of the Elytron subsystem do not leak out to other
>   >>>>>> subsystems.
>   >>>>>>
>   >>>>>
>   >>>>> I like the notion of both the capability code and the requiring code
>   >>>>> turning over the mechanics of service name creation to the core. I
>   >>>>> expect that will go into the OperationContext though, as it has the
>   >>>>> knowledge of what capabilities exist. If it's purely a mechanical
>   >>>>> function though with no validation required it could just go in some
>   >>>>> static method somewhere, but it's likely in the real use cases there
>   >>>>> will be some validation.
>   >>>>>
>   >>>>> I don't see a type as being valid data for creating a
> ServiceName. There
>   >>>>> isn't a 1:1 correspondence between a type and the various things that
>   >>>>> can provide services whose value is of that type. Simplest case being
>   >>>>> Service<Void>, but I bet we have some Service<String> out there.
>   >>>>>
>   >>>>> If we limit a capability to providing just a single type for
> injections,
>   >>>>> then it can just be:
>   >>>>>
>   >>>>> public ServiceName getServiceName(String capability, String
> instanceName)
>   >>>>>
>   >>>>> A capability provides a namespace, as does the prefix for a
> ServiceName
>   >>>>> so it seems reasonable enough to me to reuse one for the other.
>   >>>>> Particularly if it's all hidden behind a method the core provides.
>   >>>>>
>   >>>>> I was a bit reluctant to limit a capability to providing just a
> single
>   >>>>> injection type, as there are some cases where it's a bit fine
> grained.
>   >>>>> For example IIOP provides both an ORB and a CORBA
> NamingContextExt. But
>   >>>>> I don't think there are enough such cases to outweigh the simplicity
>   >>>>> advantages of having a single injection type per capability.
>   >>>>
>   >>>> +1 Take my suggestion extremely lightly, that was only going to be a
>   >>>> temporary step towards being capability based - from your other e-mail
>   >>>> it sounds like that is going to be actively developed now so I can
> just
>   >>>> use the real thing.
>   >>>>
>   >>>
>   >>> Yes, it will be. I did a fair amount last summer/fall but then hit a
>   >>> point where I wanted to let ideas percolate, plus I had to do a lot of
>   >>> other tasks. But I think enough percolation has happened (including
> your
>   >>> helpful suggestion above) and the list other stuff I've had to do is
>   >>> getting short.
>   >>>
>   >>>> I am at the point now where I am starting to wire things together
> in the
>   >>>> server and have just started an incubation fork of wildfly-core for my
>   >>>> development so let me know if there is anything you want me to try
> out.
>   >>>>
>   >>>
>   >>> Thanks; I'll do that for sure.
>   >>>
>   >>>>>>> Secondly is there anything we can do at the model level regarding
>   >>>>>>> assisting the user with referential integrity, as an example
> say I am
>   >>>>>>> writing an attribute using the CLI called 'keystore', this is
> going to
>   >>>>>>> be a reference to a named KeyStore - how about some form of op
>   >>>>>>> associated with that attribute that can dynamically generate
> the list of
>   >>>>>>> accepted values on demand, e.g. by querying the model and
> finding out
>   >>>>>>> which KeyStores are actually available.
>   >>>>>>>
>   >>>>>>> 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 brian.stansberry at redhat.com  Wed Mar 25 10:35:36 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 25 Mar 2015 09:35:36 -0500
Subject: [wildfly-dev] Preparation for requirements and capabilities.
In-Reply-To: <5512C2E7.50509@redhat.com>
References: <550AA2D9.4040103@jboss.com>	<550B02A9.6050508@jboss.com>	<551173AF.4040101@redhat.com>	<551175A4.1000409@jboss.com>	<5511777F.9040005@redhat.com>	<5511A82D.9000704@jboss.com>	<5511C502.2060306@redhat.com>
	<5512C2E7.50509@redhat.com>
Message-ID: <5512C7B8.80606@redhat.com>

On 3/25/15 9:15 AM, David M. Lloyd wrote:
> On 03/24/2015 03:11 PM, Brian Stansberry wrote:
>> On 3/24/15 1:08 PM, Darran Lofthouse wrote:
>>> My first questions in this area are - What are the constraints going to
>>> be about unique naming of capabilities?
>>
>> They must be namespaced. See
>> https://developer.jboss.org/wiki/CoreAndSubsystemCapabilitiesAndRequirements.
>>
>> The ones we provide must be in the org.wildfly namespace, which is
>> reserved for us. Use org.wildfly.extension.xxxx for stuff this is
>> provided by an extension, and isn't part of the kernel.
>>
>> (OT: I'm going to start using the term 'kernel' to mean what used to be
>> called the 'core' since now WildFly Core means the kernel plus a few
>> subsystems.)
>>
>>> Will the implementation / API
>>> provide methods a subsystem can use to help enforce this?
>>>
>>
>> The OperationContext will enforce uniqueness. I don't think a subsystem
>> will help enforce this; the subsystem authors will just create a
>> reasonable namespace and stick to it.
>>
>>> When it comes to resource definitions the definition can either be
>>> focused on the implementation behind the service or the type the service
>>> returns.  My preference is to focus on the implementation.
>>>
>>> As an example I have a few different security realm implementations: -
>>>
>>> keystore-realm=*
>>> ldap-realm=*
>>> jaas-realm=*
>>>
>>> All of these would register a service that returns 'SecurityRealm' so
>>> 'SecurityRealm' would be the capability.
>>>
>>> So this is really the basis of my question as now the model does not
>>> enforce unique names.  The reason for this type of split is so each can
>>> have it's own set of attribute definitions.
>>>
>>> If I turned this on it's head and have: -
>>>
>>> security-realm=*
>>>
>>> Now the model will enforce unique names within my subsystem but I have
>>> lost the association of type specific attributes.  A security realm
>>> could support all attribute types but now it becomes hard to work with
>>> and understand what does what depending on the type.  Or I could add a
>>> child resource for type specific settings but that moves away from my
>>> aim of a 1:1 mapping between resource and service.
>>>
>>> Although the model enforces unique names this is specific to my
>>> subsystem only, if another subsystem is also capable of supplying
>>> SecurityRealm implementations duplicates are again possible.
>>>
>>
>> Within a given context (i.e. a standalone server or a domain profile)
>> some other subsystem providing a capability with the same name will not
>> be allowed. If someone else wants to provide access to
>> Service<SecurityRealm> for some unrelated reason then they need to
>> provide their own capability name. If they are actually another
>> implementation of the same capability, then the user has to pick one or
>> the other within a context.
>>
>>> So overall my preference would be let capabilities and requirements
>>> worry about naming constraints and leave subsystem implementations to
>>> focus on understandable typed resources.
>>>
>>
>> That's fine. If keystore-realm=* et al are all providing instances of
>> the same capability, then the OperationContext can enforce that as part
>> of model validation by detecting duplicate instance names registered
>> within a single capability namespace.
>>
>> Having keystore-realm=*, ldap-realm=*, jaas-realm=* all registering
>> instance names in the same capability namespace will add some complexity
>> to the validation though, so thanks for pointing that use case out. The
>> complexity is discriminating your use case (legal) from two completely
>> different subsystems using the same namespace in the same context
>> (illegal). A possible solution is the parent resource for those is what
>> declares that it provides capability org.wildfly.extension.xxx and then
>> the kernel accepts instance name registrations from children, while
>> rejecting them from non-children.
>
> The thing is that some things will require specific types and some will
> allow the general type.  So the simple solution is, each realm shall
> register two capabilities, one being the generic security-realm=myname
> and the other being type-specific, ldap-realm=myname.  This way things
> which allow the generic type can use it, whereas things which require
> ldap can require that.  Additional "levels" can be added in the event
> that there is a hierarchy of types.  This allows the simpler mechanism
> to accommodate complex use cases.
>

This can certainly work; there's nothing preventing code registering 
multiple capabilities. The validation issue I mentioned above still 
applies, but I figure we can sort that.

Circling back to the ServiceName discussion, would this be implemented 
via an alias ServiceName? So there would be a Service<LdapRealm> 
registered under org.wildfly.extension.security.ldap-realm.foo but then 
also registered with an alias of 
org.wildfly.extension.security.security-realm.foo? The consumer of the 
latter not concerned about/aware of the fact it provides 
Service<LdapRealm> because LdapRealm is a subtype of SecurityRealm?

A provider could do this other ways as well (just create two services) 
but the above seems feasible.


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

From darran.lofthouse at jboss.com  Wed Mar 25 10:36:55 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Wed, 25 Mar 2015 14:36:55 +0000
Subject: [wildfly-dev] Preparation for requirements and capabilities.
In-Reply-To: <5512C62B.2040007@redhat.com>
References: <550AA2D9.4040103@jboss.com>	<550B02A9.6050508@jboss.com>	<551173AF.4040101@redhat.com>	<551175A4.1000409@jboss.com>	<5511777F.9040005@redhat.com>	<5511A82D.9000704@jboss.com>	<5511C502.2060306@redhat.com>	<5512A3B4.2010609@jboss.com>
	<5512C62B.2040007@redhat.com>
Message-ID: <5512C807.5050500@jboss.com>



On 25/03/15 14:28, Brian Stansberry wrote:
> On 3/25/15 7:01 AM, Darran Lofthouse wrote:
>>
>>
>>
>> On 24/03/15 20:11, Brian Stansberry wrote:
>>    > On 3/24/15 1:08 PM, Darran Lofthouse wrote:
>>    >> My first questions in this area are - What are the constraints going to
>>    >> be about unique naming of capabilities?
>>    >
>>    > They must be namespaced. See
>>    >
>> https://developer.jboss.org/wiki/CoreAndSubsystemCapabilitiesAndRequirements.
>>    >
>>    > The ones we provide must be in the org.wildfly namespace, which is
>>    > reserved for us. Use org.wildfly.extension.xxxx for stuff this is
>>    > provided by an extension, and isn't part of the kernel.
>>    >
>>    > (OT: I'm going to start using the term 'kernel' to mean what used to be
>>    > called the 'core' since now WildFly Core means the kernel plus a few
>>    > subsystems.)
>>
>> (OT: Personally I wish kernel was it's own build )
>>
>>    >
>>    >> Will the implementation / API
>>    >> provide methods a subsystem can use to help enforce this?
>>    >>
>>    >
>>    > The OperationContext will enforce uniqueness. I don't think a subsystem
>>    > will help enforce this; the subsystem authors will just create a
>>    > reasonable namespace and stick to it.
>>
>> I may be thinking of this the opposite way around, or it may be that my
>> capabilities are more ingrained with the application server as a whole.
>>
>> In the case of Elytron I think we have a successful API/SPI separation
>> if we can say the Elytron Subsystem is optional, primarily this gives us
>> two different situations: -
>>     - No capabilities provided and nothing requiring them - essentially a
>> completely unsecured server.
>>     - An alternative subsystem providing all of the capabilities, maybe
>> this is a pure KeyCloak server or maybe an ISV wants the security
>> tightly built on their product.
>>
>> As I type this having the namespace defined by the subsystem is probably
>> not an issue provided that every place say a security realm can be
>> referenced this is a qualified reference including the namespace.  Also
>> the discovery of available security realms would need to take into
>> account different namespaces being available.
>>
>
> I think it's best to decouple the concepts of capabilities and subsystems.
>
> A capability is a form of API/SPI. It has a name, and it can provide an
> API. (Note that this API is not limited to service injection; we do
> other things in other cases.)
>
> A subsystem can provide a capability, but that doesn't mean it has to
> "own" the capability. There can be a capability named
> org.wildfly.extension.security.security-realm that is owned by the
> WildFly dev team, but that doesn't mean the Elytron subsystem has to own
> it. Someone else could provide it as well. This is logically analogous
> to some library providing an API/SPI and then also an impl.

That part sounds perfect for me.  The capabilities we are thinking about 
here will be integral to the whole application server.

> If the user configures two providers of the same capability in the same
> context, it's a configuration error. The server will reject that. Over
> time hopefully provisioning tooling will come along that will reject it
> in advance.

The case I have now is say the Elytron subsystem is installed and the 
KeyCloak subsystem is installed - it is quite conceivable that both 
would provide capabilities for 
'org.wildfly.extension.security.security-realm'

> If some consumer of capabilities just wants Service<SecurityRealm> and
> doesn't care which of a menu of capabilities provides it, I consider
> that to be corner case detail, and something to be handled by that
> consumer (by registering an optional requirement for each and using
> whichever is available.)
>
>
>> (OT:  Wonder if we should think about access control here, I am waiting
>> till I have the majority of the model in place to really look into it
>> but we do have the issue of no longer being able to tell which parts of
>> security are app and which parts are management)
>>
>>    >> When it comes to resource definitions the definition can either be
>>    >> focused on the implementation behind the service or the type the service
>>    >> returns.  My preference is to focus on the implementation.
>>    >>
>>    >> As an example I have a few different security realm implementations: -
>>    >>
>>    >> keystore-realm=*
>>    >> ldap-realm=*
>>    >> jaas-realm=*
>>    >>
>>    >> All of these would register a service that returns 'SecurityRealm' so
>>    >> 'SecurityRealm' would be the capability.
>>    >>
>>    >> So this is really the basis of my question as now the model does not
>>    >> enforce unique names.  The reason for this type of split is so each can
>>    >> have it's own set of attribute definitions.
>>    >>
>>    >> If I turned this on it's head and have: -
>>    >>
>>    >> security-realm=*
>>    >>
>>    >> Now the model will enforce unique names within my subsystem but I have
>>    >> lost the association of type specific attributes.  A security realm
>>    >> could support all attribute types but now it becomes hard to work with
>>    >> and understand what does what depending on the type.  Or I could add a
>>    >> child resource for type specific settings but that moves away from my
>>    >> aim of a 1:1 mapping between resource and service.
>>    >>
>>    >> Although the model enforces unique names this is specific to my
>>    >> subsystem only, if another subsystem is also capable of supplying
>>    >> SecurityRealm implementations duplicates are again possible.
>>    >>
>>    >
>>    > Within a given context (i.e. a standalone server or a domain profile)
>>    > some other subsystem providing a capability with the same name will not
>>    > be allowed. If someone else wants to provide access to
>>    > Service<SecurityRealm> for some unrelated reason then they need to
>>    > provide their own capability name. If they are actually another
>>    > implementation of the same capability, then the user has to pick one or
>>    > the other within a context.
>>    >
>>    >> So overall my preference would be let capabilities and requirements
>>    >> worry about naming constraints and leave subsystem implementations to
>>    >> focus on understandable typed resources.
>>    >>
>>    >
>>    > That's fine. If keystore-realm=* et al are all providing instances of
>>    > the same capability, then the OperationContext can enforce that as part
>>    > of model validation by detecting duplicate instance names registered
>>    > within a single capability namespace.
>>    >
>>    > Having keystore-realm=*, ldap-realm=*, jaas-realm=* all registering
>>    > instance names in the same capability namespace will add some complexity
>>    > to the validation though, so thanks for pointing that use case out. The
>>    > complexity is discriminating your use case (legal) from two completely
>>    > different subsystems using the same namespace in the same context
>>    > (illegal). A possible solution is the parent resource for those is what
>>    > declares that it provides capability org.wildfly.extension.xxx and then
>>    > the kernel accepts instance name registrations from children, while
>>    > rejecting them from non-children.
>>    >
>>    >> Regards,
>>    >> Darran Lofthouse.
>>    >>
>>    >>
>>    >>
>>    >>
>>    >> On 24/03/15 14:41, Brian Stansberry wrote:
>>    >>> On 3/24/15 9:33 AM, Darran Lofthouse wrote:
>>    >>>>
>>    >>>>
>>    >>>> On 24/03/15 14:24, Brian Stansberry wrote:
>>    >>>>> On 3/19/15 12:08 PM, Darran Lofthouse wrote:
>>    >>>>>> On 19/03/15 10:20, Darran Lofthouse wrote:
>>    >>>>>>> Assuming the title still covers the scenarios I have in mind is
>> there
>>    >>>>>>> anything we can be doing now to prepare for requirements and
>>    >>>>>>> capabilities support to make transitioning easier once it is
>> available.
>>    >>>>>>>
>>    >>>>>>> As an example within Elytron we will have a number of services that
>>    >>>>>>> define either standard types or types defined by API that we
>> want to
>>    >>>>>>> inject - is there anything we can do today for subsystems that
>> want to
>>    >>>>>>> say "I want a type X, named Y injected here" whilst minimising
>>    >>>>>>> interaction with and knowledge of the Elytron subsystem.
>>    >>>>>>
>>    >>>>>> For the service naming issue I have one idea, I create a utility
>> class
>>    >>>>>> in wildfly-core with the following method: -
>>    >>>>>>
>>    >>>>>> public static ServiceName createServiceName(Class<?> type,
>>    >>>>>>            String simpleName);
>>    >>>>>>
>>    >>>>>> The type here is the type that the service returns, this methods
>>    >>>>>> constructs a ServiceName taking into account the class name of
>> the type
>>    >>>>>> and the supplied simpleName which really is just it's reference.
>>    >>>>>>
>>    >>>>>> Within the Elytron subsystem I install services by using this
>> method to
>>    >>>>>> construct the names.
>>    >>>>>>
>>    >>>>>> For any other service that depends on one of these types the
>> same method
>>    >>>>>> is used when creating the dependency.
>>    >>>>>>
>>    >>>>>> This way details of the Elytron subsystem do not leak out to other
>>    >>>>>> subsystems.
>>    >>>>>>
>>    >>>>>
>>    >>>>> I like the notion of both the capability code and the requiring code
>>    >>>>> turning over the mechanics of service name creation to the core. I
>>    >>>>> expect that will go into the OperationContext though, as it has the
>>    >>>>> knowledge of what capabilities exist. If it's purely a mechanical
>>    >>>>> function though with no validation required it could just go in some
>>    >>>>> static method somewhere, but it's likely in the real use cases there
>>    >>>>> will be some validation.
>>    >>>>>
>>    >>>>> I don't see a type as being valid data for creating a
>> ServiceName. There
>>    >>>>> isn't a 1:1 correspondence between a type and the various things that
>>    >>>>> can provide services whose value is of that type. Simplest case being
>>    >>>>> Service<Void>, but I bet we have some Service<String> out there.
>>    >>>>>
>>    >>>>> If we limit a capability to providing just a single type for
>> injections,
>>    >>>>> then it can just be:
>>    >>>>>
>>    >>>>> public ServiceName getServiceName(String capability, String
>> instanceName)
>>    >>>>>
>>    >>>>> A capability provides a namespace, as does the prefix for a
>> ServiceName
>>    >>>>> so it seems reasonable enough to me to reuse one for the other.
>>    >>>>> Particularly if it's all hidden behind a method the core provides.
>>    >>>>>
>>    >>>>> I was a bit reluctant to limit a capability to providing just a
>> single
>>    >>>>> injection type, as there are some cases where it's a bit fine
>> grained.
>>    >>>>> For example IIOP provides both an ORB and a CORBA
>> NamingContextExt. But
>>    >>>>> I don't think there are enough such cases to outweigh the simplicity
>>    >>>>> advantages of having a single injection type per capability.
>>    >>>>
>>    >>>> +1 Take my suggestion extremely lightly, that was only going to be a
>>    >>>> temporary step towards being capability based - from your other e-mail
>>    >>>> it sounds like that is going to be actively developed now so I can
>> just
>>    >>>> use the real thing.
>>    >>>>
>>    >>>
>>    >>> Yes, it will be. I did a fair amount last summer/fall but then hit a
>>    >>> point where I wanted to let ideas percolate, plus I had to do a lot of
>>    >>> other tasks. But I think enough percolation has happened (including
>> your
>>    >>> helpful suggestion above) and the list other stuff I've had to do is
>>    >>> getting short.
>>    >>>
>>    >>>> I am at the point now where I am starting to wire things together
>> in the
>>    >>>> server and have just started an incubation fork of wildfly-core for my
>>    >>>> development so let me know if there is anything you want me to try
>> out.
>>    >>>>
>>    >>>
>>    >>> Thanks; I'll do that for sure.
>>    >>>
>>    >>>>>>> Secondly is there anything we can do at the model level regarding
>>    >>>>>>> assisting the user with referential integrity, as an example
>> say I am
>>    >>>>>>> writing an attribute using the CLI called 'keystore', this is
>> going to
>>    >>>>>>> be a reference to a named KeyStore - how about some form of op
>>    >>>>>>> associated with that attribute that can dynamically generate
>> the list of
>>    >>>>>>> accepted values on demand, e.g. by querying the model and
>> finding out
>>    >>>>>>> which KeyStores are actually available.
>>    >>>>>>>
>>    >>>>>>> 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  Wed Mar 25 10:44:41 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 25 Mar 2015 09:44:41 -0500
Subject: [wildfly-dev] Preparation for requirements and capabilities.
In-Reply-To: <5512C807.5050500@jboss.com>
References: <550AA2D9.4040103@jboss.com>	<550B02A9.6050508@jboss.com>	<551173AF.4040101@redhat.com>	<551175A4.1000409@jboss.com>	<5511777F.9040005@redhat.com>	<5511A82D.9000704@jboss.com>	<5511C502.2060306@redhat.com>	<5512A3B4.2010609@jboss.com>	<5512C62B.2040007@redhat.com>
	<5512C807.5050500@jboss.com>
Message-ID: <5512C9D9.4030703@redhat.com>

On 3/25/15 9:36 AM, Darran Lofthouse wrote:
>
>
> On 25/03/15 14:28, Brian Stansberry wrote:
>> On 3/25/15 7:01 AM, Darran Lofthouse wrote:
>>>
>>>
>>>
>>> On 24/03/15 20:11, Brian Stansberry wrote:
>>>     > On 3/24/15 1:08 PM, Darran Lofthouse wrote:
>>>     >> My first questions in this area are - What are the constraints going to
>>>     >> be about unique naming of capabilities?
>>>     >
>>>     > They must be namespaced. See
>>>     >
>>> https://developer.jboss.org/wiki/CoreAndSubsystemCapabilitiesAndRequirements.
>>>     >
>>>     > The ones we provide must be in the org.wildfly namespace, which is
>>>     > reserved for us. Use org.wildfly.extension.xxxx for stuff this is
>>>     > provided by an extension, and isn't part of the kernel.
>>>     >
>>>     > (OT: I'm going to start using the term 'kernel' to mean what used to be
>>>     > called the 'core' since now WildFly Core means the kernel plus a few
>>>     > subsystems.)
>>>
>>> (OT: Personally I wish kernel was it's own build )
>>>
>>>     >
>>>     >> Will the implementation / API
>>>     >> provide methods a subsystem can use to help enforce this?
>>>     >>
>>>     >
>>>     > The OperationContext will enforce uniqueness. I don't think a subsystem
>>>     > will help enforce this; the subsystem authors will just create a
>>>     > reasonable namespace and stick to it.
>>>
>>> I may be thinking of this the opposite way around, or it may be that my
>>> capabilities are more ingrained with the application server as a whole.
>>>
>>> In the case of Elytron I think we have a successful API/SPI separation
>>> if we can say the Elytron Subsystem is optional, primarily this gives us
>>> two different situations: -
>>>      - No capabilities provided and nothing requiring them - essentially a
>>> completely unsecured server.
>>>      - An alternative subsystem providing all of the capabilities, maybe
>>> this is a pure KeyCloak server or maybe an ISV wants the security
>>> tightly built on their product.
>>>
>>> As I type this having the namespace defined by the subsystem is probably
>>> not an issue provided that every place say a security realm can be
>>> referenced this is a qualified reference including the namespace.  Also
>>> the discovery of available security realms would need to take into
>>> account different namespaces being available.
>>>
>>
>> I think it's best to decouple the concepts of capabilities and subsystems.
>>
>> A capability is a form of API/SPI. It has a name, and it can provide an
>> API. (Note that this API is not limited to service injection; we do
>> other things in other cases.)
>>
>> A subsystem can provide a capability, but that doesn't mean it has to
>> "own" the capability. There can be a capability named
>> org.wildfly.extension.security.security-realm that is owned by the
>> WildFly dev team, but that doesn't mean the Elytron subsystem has to own
>> it. Someone else could provide it as well. This is logically analogous
>> to some library providing an API/SPI and then also an impl.
>
> That part sounds perfect for me.  The capabilities we are thinking about
> here will be integral to the whole application server.
>
>> If the user configures two providers of the same capability in the same
>> context, it's a configuration error. The server will reject that. Over
>> time hopefully provisioning tooling will come along that will reject it
>> in advance.
>
> The case I have now is say the Elytron subsystem is installed and the
> KeyCloak subsystem is installed - it is quite conceivable that both
> would provide capabilities for
> 'org.wildfly.extension.security.security-realm'
>

That's fine so long as they don't appear in the configuration in the 
same "context". Context meaning the same profile. A domain can have 
both, just not in the same profile. A standalone server of course only 
has one profile.

>> If some consumer of capabilities just wants Service<SecurityRealm> and
>> doesn't care which of a menu of capabilities provides it, I consider
>> that to be corner case detail, and something to be handled by that
>> consumer (by registering an optional requirement for each and using
>> whichever is available.)
>>
>>
>>> (OT:  Wonder if we should think about access control here, I am waiting
>>> till I have the majority of the model in place to really look into it
>>> but we do have the issue of no longer being able to tell which parts of
>>> security are app and which parts are management)
>>>
>>>     >> When it comes to resource definitions the definition can either be
>>>     >> focused on the implementation behind the service or the type the service
>>>     >> returns.  My preference is to focus on the implementation.
>>>     >>
>>>     >> As an example I have a few different security realm implementations: -
>>>     >>
>>>     >> keystore-realm=*
>>>     >> ldap-realm=*
>>>     >> jaas-realm=*
>>>     >>
>>>     >> All of these would register a service that returns 'SecurityRealm' so
>>>     >> 'SecurityRealm' would be the capability.
>>>     >>
>>>     >> So this is really the basis of my question as now the model does not
>>>     >> enforce unique names.  The reason for this type of split is so each can
>>>     >> have it's own set of attribute definitions.
>>>     >>
>>>     >> If I turned this on it's head and have: -
>>>     >>
>>>     >> security-realm=*
>>>     >>
>>>     >> Now the model will enforce unique names within my subsystem but I have
>>>     >> lost the association of type specific attributes.  A security realm
>>>     >> could support all attribute types but now it becomes hard to work with
>>>     >> and understand what does what depending on the type.  Or I could add a
>>>     >> child resource for type specific settings but that moves away from my
>>>     >> aim of a 1:1 mapping between resource and service.
>>>     >>
>>>     >> Although the model enforces unique names this is specific to my
>>>     >> subsystem only, if another subsystem is also capable of supplying
>>>     >> SecurityRealm implementations duplicates are again possible.
>>>     >>
>>>     >
>>>     > Within a given context (i.e. a standalone server or a domain profile)
>>>     > some other subsystem providing a capability with the same name will not
>>>     > be allowed. If someone else wants to provide access to
>>>     > Service<SecurityRealm> for some unrelated reason then they need to
>>>     > provide their own capability name. If they are actually another
>>>     > implementation of the same capability, then the user has to pick one or
>>>     > the other within a context.
>>>     >
>>>     >> So overall my preference would be let capabilities and requirements
>>>     >> worry about naming constraints and leave subsystem implementations to
>>>     >> focus on understandable typed resources.
>>>     >>
>>>     >
>>>     > That's fine. If keystore-realm=* et al are all providing instances of
>>>     > the same capability, then the OperationContext can enforce that as part
>>>     > of model validation by detecting duplicate instance names registered
>>>     > within a single capability namespace.
>>>     >
>>>     > Having keystore-realm=*, ldap-realm=*, jaas-realm=* all registering
>>>     > instance names in the same capability namespace will add some complexity
>>>     > to the validation though, so thanks for pointing that use case out. The
>>>     > complexity is discriminating your use case (legal) from two completely
>>>     > different subsystems using the same namespace in the same context
>>>     > (illegal). A possible solution is the parent resource for those is what
>>>     > declares that it provides capability org.wildfly.extension.xxx and then
>>>     > the kernel accepts instance name registrations from children, while
>>>     > rejecting them from non-children.
>>>     >
>>>     >> Regards,
>>>     >> Darran Lofthouse.
>>>     >>
>>>     >>
>>>     >>
>>>     >>
>>>     >> On 24/03/15 14:41, Brian Stansberry wrote:
>>>     >>> On 3/24/15 9:33 AM, Darran Lofthouse wrote:
>>>     >>>>
>>>     >>>>
>>>     >>>> On 24/03/15 14:24, Brian Stansberry wrote:
>>>     >>>>> On 3/19/15 12:08 PM, Darran Lofthouse wrote:
>>>     >>>>>> On 19/03/15 10:20, Darran Lofthouse wrote:
>>>     >>>>>>> Assuming the title still covers the scenarios I have in mind is
>>> there
>>>     >>>>>>> anything we can be doing now to prepare for requirements and
>>>     >>>>>>> capabilities support to make transitioning easier once it is
>>> available.
>>>     >>>>>>>
>>>     >>>>>>> As an example within Elytron we will have a number of services that
>>>     >>>>>>> define either standard types or types defined by API that we
>>> want to
>>>     >>>>>>> inject - is there anything we can do today for subsystems that
>>> want to
>>>     >>>>>>> say "I want a type X, named Y injected here" whilst minimising
>>>     >>>>>>> interaction with and knowledge of the Elytron subsystem.
>>>     >>>>>>
>>>     >>>>>> For the service naming issue I have one idea, I create a utility
>>> class
>>>     >>>>>> in wildfly-core with the following method: -
>>>     >>>>>>
>>>     >>>>>> public static ServiceName createServiceName(Class<?> type,
>>>     >>>>>>            String simpleName);
>>>     >>>>>>
>>>     >>>>>> The type here is the type that the service returns, this methods
>>>     >>>>>> constructs a ServiceName taking into account the class name of
>>> the type
>>>     >>>>>> and the supplied simpleName which really is just it's reference.
>>>     >>>>>>
>>>     >>>>>> Within the Elytron subsystem I install services by using this
>>> method to
>>>     >>>>>> construct the names.
>>>     >>>>>>
>>>     >>>>>> For any other service that depends on one of these types the
>>> same method
>>>     >>>>>> is used when creating the dependency.
>>>     >>>>>>
>>>     >>>>>> This way details of the Elytron subsystem do not leak out to other
>>>     >>>>>> subsystems.
>>>     >>>>>>
>>>     >>>>>
>>>     >>>>> I like the notion of both the capability code and the requiring code
>>>     >>>>> turning over the mechanics of service name creation to the core. I
>>>     >>>>> expect that will go into the OperationContext though, as it has the
>>>     >>>>> knowledge of what capabilities exist. If it's purely a mechanical
>>>     >>>>> function though with no validation required it could just go in some
>>>     >>>>> static method somewhere, but it's likely in the real use cases there
>>>     >>>>> will be some validation.
>>>     >>>>>
>>>     >>>>> I don't see a type as being valid data for creating a
>>> ServiceName. There
>>>     >>>>> isn't a 1:1 correspondence between a type and the various things that
>>>     >>>>> can provide services whose value is of that type. Simplest case being
>>>     >>>>> Service<Void>, but I bet we have some Service<String> out there.
>>>     >>>>>
>>>     >>>>> If we limit a capability to providing just a single type for
>>> injections,
>>>     >>>>> then it can just be:
>>>     >>>>>
>>>     >>>>> public ServiceName getServiceName(String capability, String
>>> instanceName)
>>>     >>>>>
>>>     >>>>> A capability provides a namespace, as does the prefix for a
>>> ServiceName
>>>     >>>>> so it seems reasonable enough to me to reuse one for the other.
>>>     >>>>> Particularly if it's all hidden behind a method the core provides.
>>>     >>>>>
>>>     >>>>> I was a bit reluctant to limit a capability to providing just a
>>> single
>>>     >>>>> injection type, as there are some cases where it's a bit fine
>>> grained.
>>>     >>>>> For example IIOP provides both an ORB and a CORBA
>>> NamingContextExt. But
>>>     >>>>> I don't think there are enough such cases to outweigh the simplicity
>>>     >>>>> advantages of having a single injection type per capability.
>>>     >>>>
>>>     >>>> +1 Take my suggestion extremely lightly, that was only going to be a
>>>     >>>> temporary step towards being capability based - from your other e-mail
>>>     >>>> it sounds like that is going to be actively developed now so I can
>>> just
>>>     >>>> use the real thing.
>>>     >>>>
>>>     >>>
>>>     >>> Yes, it will be. I did a fair amount last summer/fall but then hit a
>>>     >>> point where I wanted to let ideas percolate, plus I had to do a lot of
>>>     >>> other tasks. But I think enough percolation has happened (including
>>> your
>>>     >>> helpful suggestion above) and the list other stuff I've had to do is
>>>     >>> getting short.
>>>     >>>
>>>     >>>> I am at the point now where I am starting to wire things together
>>> in the
>>>     >>>> server and have just started an incubation fork of wildfly-core for my
>>>     >>>> development so let me know if there is anything you want me to try
>>> out.
>>>     >>>>
>>>     >>>
>>>     >>> Thanks; I'll do that for sure.
>>>     >>>
>>>     >>>>>>> Secondly is there anything we can do at the model level regarding
>>>     >>>>>>> assisting the user with referential integrity, as an example
>>> say I am
>>>     >>>>>>> writing an attribute using the CLI called 'keystore', this is
>>> going to
>>>     >>>>>>> be a reference to a named KeyStore - how about some form of op
>>>     >>>>>>> associated with that attribute that can dynamically generate
>>> the list of
>>>     >>>>>>> accepted values on demand, e.g. by querying the model and
>>> finding out
>>>     >>>>>>> which KeyStores are actually available.
>>>     >>>>>>>
>>>     >>>>>>> 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 darran.lofthouse at jboss.com  Wed Mar 25 10:54:17 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Wed, 25 Mar 2015 14:54:17 +0000
Subject: [wildfly-dev] Preparation for requirements and capabilities.
In-Reply-To: <5512C9D9.4030703@redhat.com>
References: <550AA2D9.4040103@jboss.com>	<550B02A9.6050508@jboss.com>	<551173AF.4040101@redhat.com>	<551175A4.1000409@jboss.com>	<5511777F.9040005@redhat.com>	<5511A82D.9000704@jboss.com>	<5511C502.2060306@redhat.com>	<5512A3B4.2010609@jboss.com>	<5512C62B.2040007@redhat.com>	<5512C807.5050500@jboss.com>
	<5512C9D9.4030703@redhat.com>
Message-ID: <5512CC19.3000700@jboss.com>



On 25/03/15 14:44, Brian Stansberry wrote:
> On 3/25/15 9:36 AM, Darran Lofthouse wrote:
>> The case I have now is say the Elytron subsystem is installed and the
>> KeyCloak subsystem is installed - it is quite conceivable that both
>> would provide capabilities for
>> 'org.wildfly.extension.security.security-realm'
>>
>
> That's fine so long as they don't appear in the configuration in the
> same "context". Context meaning the same profile. A domain can have
> both, just not in the same profile. A standalone server of course only
> has one profile.

I am kind of thinking these would be the same profile, i.e. you could 
have security realms defined in Elytron used for one set of deployments 
and then KeyCloak could provide a realm used by a different deployment.

Although we may be able to find a way around this example if we step 
back from the realm.

The Elytron subsystem will be exposing SecurityDomains as a capability, 
strictly speaking it is these that secured resources will have a 
dependency on.

A SecurityDomain will reference one or more SecurityRealm instances.  So 
within the Elytron subsystem I need to be able to reference security 
realms defined within the Elytron subsystem - but also have the ability 
to reference security realms defined in other subsystems, but I also 
don't want the Elytron subsystem to need knowledge of the other 
subsystems beyond values that are set in the model.

This pattern could also repeat for KeyStore, KeyManager and TrustManager 
which are also ideal candidates for other subsystems to provide their 
own implementations of.


From brian.stansberry at redhat.com  Wed Mar 25 11:00:55 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 25 Mar 2015 10:00:55 -0500
Subject: [wildfly-dev] Preparation for requirements and capabilities.
In-Reply-To: <5512CC19.3000700@jboss.com>
References: <550AA2D9.4040103@jboss.com>	<550B02A9.6050508@jboss.com>	<551173AF.4040101@redhat.com>	<551175A4.1000409@jboss.com>	<5511777F.9040005@redhat.com>	<5511A82D.9000704@jboss.com>	<5511C502.2060306@redhat.com>	<5512A3B4.2010609@jboss.com>	<5512C62B.2040007@redhat.com>	<5512C807.5050500@jboss.com>	<5512C9D9.4030703@redhat.com>
	<5512CC19.3000700@jboss.com>
Message-ID: <5512CDA7.5050702@redhat.com>

On 3/25/15 9:54 AM, Darran Lofthouse wrote:
>
> On 25/03/15 14:44, Brian Stansberry wrote:
>> On 3/25/15 9:36 AM, Darran Lofthouse wrote:
>>> The case I have now is say the Elytron subsystem is installed and the
>>> KeyCloak subsystem is installed - it is quite conceivable that both
>>> would provide capabilities for
>>> 'org.wildfly.extension.security.security-realm'
>>>
>>
>> That's fine so long as they don't appear in the configuration in the
>> same "context". Context meaning the same profile. A domain can have
>> both, just not in the same profile. A standalone server of course only
>> has one profile.
>
> I am kind of thinking these would be the same profile, i.e. you could
> have security realms defined in Elytron used for one set of deployments
> and then KeyCloak could provide a realm used by a different deployment.
>
> Although we may be able to find a way around this example if we step
> back from the realm.
>
> The Elytron subsystem will be exposing SecurityDomains as a capability,
> strictly speaking it is these that secured resources will have a
> dependency on.
>
> A SecurityDomain will reference one or more SecurityRealm instances.  So
> within the Elytron subsystem I need to be able to reference security
> realms defined within the Elytron subsystem - but also have the ability
> to reference security realms defined in other subsystems, but I also
> don't want the Elytron subsystem to need knowledge of the other
> subsystems beyond values that are set in the model.
>
> This pattern could also repeat for KeyStore, KeyManager and TrustManager
> which are also ideal candidates for other subsystems to provide their
> own implementations of.
>

Hmm, so some sort of non-exclusive capability thing. Or some way that a 
capability can declare the context in which it must be exclusive, one 
option being "NONE".

Just brainstorming here...


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

From david.lloyd at redhat.com  Wed Mar 25 11:03:10 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Wed, 25 Mar 2015 10:03:10 -0500
Subject: [wildfly-dev] Preparation for requirements and capabilities.
In-Reply-To: <5512C7B8.80606@redhat.com>
References: <550AA2D9.4040103@jboss.com>	<550B02A9.6050508@jboss.com>	<551173AF.4040101@redhat.com>	<551175A4.1000409@jboss.com>	<5511777F.9040005@redhat.com>	<5511A82D.9000704@jboss.com>	<5511C502.2060306@redhat.com>	<5512C2E7.50509@redhat.com>
	<5512C7B8.80606@redhat.com>
Message-ID: <5512CE2E.9040005@redhat.com>

On 03/25/2015 09:35 AM, Brian Stansberry wrote:
> On 3/25/15 9:15 AM, David M. Lloyd wrote:
>> On 03/24/2015 03:11 PM, Brian Stansberry wrote:
>>> On 3/24/15 1:08 PM, Darran Lofthouse wrote:
>>>> My first questions in this area are - What are the constraints going to
>>>> be about unique naming of capabilities?
>>>
>>> They must be namespaced. See
>>> https://developer.jboss.org/wiki/CoreAndSubsystemCapabilitiesAndRequirements.
>>>
>>> The ones we provide must be in the org.wildfly namespace, which is
>>> reserved for us. Use org.wildfly.extension.xxxx for stuff this is
>>> provided by an extension, and isn't part of the kernel.
>>>
>>> (OT: I'm going to start using the term 'kernel' to mean what used to be
>>> called the 'core' since now WildFly Core means the kernel plus a few
>>> subsystems.)
>>>
>>>> Will the implementation / API
>>>> provide methods a subsystem can use to help enforce this?
>>>>
>>>
>>> The OperationContext will enforce uniqueness. I don't think a subsystem
>>> will help enforce this; the subsystem authors will just create a
>>> reasonable namespace and stick to it.
>>>
>>>> When it comes to resource definitions the definition can either be
>>>> focused on the implementation behind the service or the type the service
>>>> returns.  My preference is to focus on the implementation.
>>>>
>>>> As an example I have a few different security realm implementations: -
>>>>
>>>> keystore-realm=*
>>>> ldap-realm=*
>>>> jaas-realm=*
>>>>
>>>> All of these would register a service that returns 'SecurityRealm' so
>>>> 'SecurityRealm' would be the capability.
>>>>
>>>> So this is really the basis of my question as now the model does not
>>>> enforce unique names.  The reason for this type of split is so each can
>>>> have it's own set of attribute definitions.
>>>>
>>>> If I turned this on it's head and have: -
>>>>
>>>> security-realm=*
>>>>
>>>> Now the model will enforce unique names within my subsystem but I have
>>>> lost the association of type specific attributes.  A security realm
>>>> could support all attribute types but now it becomes hard to work with
>>>> and understand what does what depending on the type.  Or I could add a
>>>> child resource for type specific settings but that moves away from my
>>>> aim of a 1:1 mapping between resource and service.
>>>>
>>>> Although the model enforces unique names this is specific to my
>>>> subsystem only, if another subsystem is also capable of supplying
>>>> SecurityRealm implementations duplicates are again possible.
>>>>
>>>
>>> Within a given context (i.e. a standalone server or a domain profile)
>>> some other subsystem providing a capability with the same name will not
>>> be allowed. If someone else wants to provide access to
>>> Service<SecurityRealm> for some unrelated reason then they need to
>>> provide their own capability name. If they are actually another
>>> implementation of the same capability, then the user has to pick one or
>>> the other within a context.
>>>
>>>> So overall my preference would be let capabilities and requirements
>>>> worry about naming constraints and leave subsystem implementations to
>>>> focus on understandable typed resources.
>>>>
>>>
>>> That's fine. If keystore-realm=* et al are all providing instances of
>>> the same capability, then the OperationContext can enforce that as part
>>> of model validation by detecting duplicate instance names registered
>>> within a single capability namespace.
>>>
>>> Having keystore-realm=*, ldap-realm=*, jaas-realm=* all registering
>>> instance names in the same capability namespace will add some complexity
>>> to the validation though, so thanks for pointing that use case out. The
>>> complexity is discriminating your use case (legal) from two completely
>>> different subsystems using the same namespace in the same context
>>> (illegal). A possible solution is the parent resource for those is what
>>> declares that it provides capability org.wildfly.extension.xxx and then
>>> the kernel accepts instance name registrations from children, while
>>> rejecting them from non-children.
>>
>> The thing is that some things will require specific types and some will
>> allow the general type.  So the simple solution is, each realm shall
>> register two capabilities, one being the generic security-realm=myname
>> and the other being type-specific, ldap-realm=myname.  This way things
>> which allow the generic type can use it, whereas things which require
>> ldap can require that.  Additional "levels" can be added in the event
>> that there is a hierarchy of types.  This allows the simpler mechanism
>> to accommodate complex use cases.
>>
>
> This can certainly work; there's nothing preventing code registering
> multiple capabilities. The validation issue I mentioned above still
> applies, but I figure we can sort that.
>
> Circling back to the ServiceName discussion, would this be implemented
> via an alias ServiceName? So there would be a Service<LdapRealm>
> registered under org.wildfly.extension.security.ldap-realm.foo but then
> also registered with an alias of
> org.wildfly.extension.security.security-realm.foo? The consumer of the
> latter not concerned about/aware of the fact it provides
> Service<LdapRealm> because LdapRealm is a subtype of SecurityRealm?
>
> A provider could do this other ways as well (just create two services)
> but the above seems feasible.

Is it necessary to have separate MSC namespaces for each capability 
namespace?  Since all security realms would have to ultimately be a 
security-realm, it seems like one MSC namespace could suffice.

-- 
- DML

From darran.lofthouse at jboss.com  Wed Mar 25 11:28:19 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Wed, 25 Mar 2015 15:28:19 +0000
Subject: [wildfly-dev] Preparation for requirements and capabilities.
In-Reply-To: <5512CDA7.5050702@redhat.com>
References: <550AA2D9.4040103@jboss.com>	<550B02A9.6050508@jboss.com>	<551173AF.4040101@redhat.com>	<551175A4.1000409@jboss.com>	<5511777F.9040005@redhat.com>	<5511A82D.9000704@jboss.com>	<5511C502.2060306@redhat.com>	<5512A3B4.2010609@jboss.com>	<5512C62B.2040007@redhat.com>	<5512C807.5050500@jboss.com>	<5512C9D9.4030703@redhat.com>	<5512CC19.3000700@jboss.com>
	<5512CDA7.5050702@redhat.com>
Message-ID: <5512D413.9090307@jboss.com>



On 25/03/15 15:00, Brian Stansberry wrote:
> On 3/25/15 9:54 AM, Darran Lofthouse wrote:
>>
>> On 25/03/15 14:44, Brian Stansberry wrote:
>>> On 3/25/15 9:36 AM, Darran Lofthouse wrote:
>>>> The case I have now is say the Elytron subsystem is installed and the
>>>> KeyCloak subsystem is installed - it is quite conceivable that both
>>>> would provide capabilities for
>>>> 'org.wildfly.extension.security.security-realm'
>>>>
>>>
>>> That's fine so long as they don't appear in the configuration in the
>>> same "context". Context meaning the same profile. A domain can have
>>> both, just not in the same profile. A standalone server of course only
>>> has one profile.
>>
>> I am kind of thinking these would be the same profile, i.e. you could
>> have security realms defined in Elytron used for one set of deployments
>> and then KeyCloak could provide a realm used by a different deployment.
>>
>> Although we may be able to find a way around this example if we step
>> back from the realm.
>>
>> The Elytron subsystem will be exposing SecurityDomains as a capability,
>> strictly speaking it is these that secured resources will have a
>> dependency on.
>>
>> A SecurityDomain will reference one or more SecurityRealm instances.  So
>> within the Elytron subsystem I need to be able to reference security
>> realms defined within the Elytron subsystem - but also have the ability
>> to reference security realms defined in other subsystems, but I also
>> don't want the Elytron subsystem to need knowledge of the other
>> subsystems beyond values that are set in the model.
>>
>> This pattern could also repeat for KeyStore, KeyManager and TrustManager
>> which are also ideal candidates for other subsystems to provide their
>> own implementations of.
>>
>
> Hmm, so some sort of non-exclusive capability thing. Or some way that a
> capability can declare the context in which it must be exclusive, one
> option being "NONE".

For the capabilities we are talking about at the moment we are really 
talking about named capabilities or model references - for these do we 
have examples where exclusivity would be required?

> Just brainstorming here...
>
>


From brian.stansberry at redhat.com  Wed Mar 25 11:31:25 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 25 Mar 2015 10:31:25 -0500
Subject: [wildfly-dev] Preparation for requirements and capabilities.
In-Reply-To: <5512CE2E.9040005@redhat.com>
References: <550AA2D9.4040103@jboss.com>	<550B02A9.6050508@jboss.com>	<551173AF.4040101@redhat.com>	<551175A4.1000409@jboss.com>	<5511777F.9040005@redhat.com>	<5511A82D.9000704@jboss.com>	<5511C502.2060306@redhat.com>	<5512C2E7.50509@redhat.com>	<5512C7B8.80606@redhat.com>
	<5512CE2E.9040005@redhat.com>
Message-ID: <5512D4CD.7090007@redhat.com>

On 3/25/15 10:03 AM, David M. Lloyd wrote:
> On 03/25/2015 09:35 AM, Brian Stansberry wrote:
>> On 3/25/15 9:15 AM, David M. Lloyd wrote:
>>>
>>> The thing is that some things will require specific types and some will
>>> allow the general type.  So the simple solution is, each realm shall
>>> register two capabilities, one being the generic security-realm=myname
>>> and the other being type-specific, ldap-realm=myname.  This way things
>>> which allow the generic type can use it, whereas things which require
>>> ldap can require that.  Additional "levels" can be added in the event
>>> that there is a hierarchy of types.  This allows the simpler mechanism
>>> to accommodate complex use cases.
>>>
>>
>> This can certainly work; there's nothing preventing code registering
>> multiple capabilities. The validation issue I mentioned above still
>> applies, but I figure we can sort that.
>>
>> Circling back to the ServiceName discussion, would this be implemented
>> via an alias ServiceName? So there would be a Service<LdapRealm>
>> registered under org.wildfly.extension.security.ldap-realm.foo but then
>> also registered with an alias of
>> org.wildfly.extension.security.security-realm.foo? The consumer of the
>> latter not concerned about/aware of the fact it provides
>> Service<LdapRealm> because LdapRealm is a subtype of SecurityRealm?
>>
>> A provider could do this other ways as well (just create two services)
>> but the above seems feasible.
>
> Is it necessary to have separate MSC namespaces for each capability
> namespace?  Since all security realms would have to ultimately be a
> security-realm, it seems like one MSC namespace could suffice.
>

No, it's not necessary. This ties into a thought I had early in the 
thread. Not necessarily a good one. See

http://lists.jboss.org/pipermail/wildfly-dev/2015-March/003712.html

This is primarily noodling about ease of use concerns. The way the 
capability/requirement stuff currently in core works, the capability 
registers an instance of an API, and then the requirer accesses that API 
and uses it to do service wiring (e.g. determine or ServiceName or even 
to configure the injection on a ServiceBuilder.) The API can provide 
other methods too if the capability involves more than service 
dependencies/injection.

But for the simple case where all that's needed is a simple injection, 
this approach involves quite a lot of boilerplate. Hence the noodling.

Tomaz has attacked the same problem; see 
https://github.com/ctomc/wildfly-core/commit/572763331f4234c504f6f04faf9b2cf7fb5900fd


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

From brian.stansberry at redhat.com  Wed Mar 25 11:34:25 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 25 Mar 2015 10:34:25 -0500
Subject: [wildfly-dev] Preparation for requirements and capabilities.
In-Reply-To: <5512D413.9090307@jboss.com>
References: <550AA2D9.4040103@jboss.com>	<550B02A9.6050508@jboss.com>	<551173AF.4040101@redhat.com>	<551175A4.1000409@jboss.com>	<5511777F.9040005@redhat.com>	<5511A82D.9000704@jboss.com>	<5511C502.2060306@redhat.com>	<5512A3B4.2010609@jboss.com>	<5512C62B.2040007@redhat.com>	<5512C807.5050500@jboss.com>	<5512C9D9.4030703@redhat.com>	<5512CC19.3000700@jboss.com>	<5512CDA7.5050702@redhat.com>
	<5512D413.9090307@jboss.com>
Message-ID: <5512D581.4080406@redhat.com>

On 3/25/15 10:28 AM, Darran Lofthouse wrote:
>
>
> On 25/03/15 15:00, Brian Stansberry wrote:
>> On 3/25/15 9:54 AM, Darran Lofthouse wrote:
>>>
>>> On 25/03/15 14:44, Brian Stansberry wrote:
>>>> On 3/25/15 9:36 AM, Darran Lofthouse wrote:
>>>>> The case I have now is say the Elytron subsystem is installed and the
>>>>> KeyCloak subsystem is installed - it is quite conceivable that both
>>>>> would provide capabilities for
>>>>> 'org.wildfly.extension.security.security-realm'
>>>>>
>>>>
>>>> That's fine so long as they don't appear in the configuration in the
>>>> same "context". Context meaning the same profile. A domain can have
>>>> both, just not in the same profile. A standalone server of course only
>>>> has one profile.
>>>
>>> I am kind of thinking these would be the same profile, i.e. you could
>>> have security realms defined in Elytron used for one set of deployments
>>> and then KeyCloak could provide a realm used by a different deployment.
>>>
>>> Although we may be able to find a way around this example if we step
>>> back from the realm.
>>>
>>> The Elytron subsystem will be exposing SecurityDomains as a capability,
>>> strictly speaking it is these that secured resources will have a
>>> dependency on.
>>>
>>> A SecurityDomain will reference one or more SecurityRealm instances.  So
>>> within the Elytron subsystem I need to be able to reference security
>>> realms defined within the Elytron subsystem - but also have the ability
>>> to reference security realms defined in other subsystems, but I also
>>> don't want the Elytron subsystem to need knowledge of the other
>>> subsystems beyond values that are set in the model.
>>>
>>> This pattern could also repeat for KeyStore, KeyManager and TrustManager
>>> which are also ideal candidates for other subsystems to provide their
>>> own implementations of.
>>>
>>
>> Hmm, so some sort of non-exclusive capability thing. Or some way that a
>> capability can declare the context in which it must be exclusive, one
>> option being "NONE".
>
> For the capabilities we are talking about at the moment we are really
> talking about named capabilities or model references - for these do we
> have examples where exclusivity would be required?
>

Named capabilities.

Examples where exclusivity is required:

jacorb vs iiop-jdk, both providing IIOP capabilities

web compatibility subsystem vs undertow, both providing various 
HTTP/servlet capabilities

messaging vs the-new-one, both providing JMS


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

From darran.lofthouse at jboss.com  Wed Mar 25 11:41:52 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Wed, 25 Mar 2015 15:41:52 +0000
Subject: [wildfly-dev] Preparation for requirements and capabilities.
In-Reply-To: <5512D581.4080406@redhat.com>
References: <550AA2D9.4040103@jboss.com>	<550B02A9.6050508@jboss.com>	<551173AF.4040101@redhat.com>	<551175A4.1000409@jboss.com>	<5511777F.9040005@redhat.com>	<5511A82D.9000704@jboss.com>	<5511C502.2060306@redhat.com>	<5512A3B4.2010609@jboss.com>	<5512C62B.2040007@redhat.com>	<5512C807.5050500@jboss.com>	<5512C9D9.4030703@redhat.com>	<5512CC19.3000700@jboss.com>	<5512CDA7.5050702@redhat.com>	<5512D413.9090307@jboss.com>
	<5512D581.4080406@redhat.com>
Message-ID: <5512D740.1090108@jboss.com>



On 25/03/15 15:34, Brian Stansberry wrote:
> On 3/25/15 10:28 AM, Darran Lofthouse wrote:
>>
>>
>> On 25/03/15 15:00, Brian Stansberry wrote:
>>> On 3/25/15 9:54 AM, Darran Lofthouse wrote:
>>>>
>>>> On 25/03/15 14:44, Brian Stansberry wrote:
>>>>> On 3/25/15 9:36 AM, Darran Lofthouse wrote:
>>>>>> The case I have now is say the Elytron subsystem is installed and the
>>>>>> KeyCloak subsystem is installed - it is quite conceivable that both
>>>>>> would provide capabilities for
>>>>>> 'org.wildfly.extension.security.security-realm'
>>>>>>
>>>>>
>>>>> That's fine so long as they don't appear in the configuration in the
>>>>> same "context". Context meaning the same profile. A domain can have
>>>>> both, just not in the same profile. A standalone server of course only
>>>>> has one profile.
>>>>
>>>> I am kind of thinking these would be the same profile, i.e. you could
>>>> have security realms defined in Elytron used for one set of deployments
>>>> and then KeyCloak could provide a realm used by a different deployment.
>>>>
>>>> Although we may be able to find a way around this example if we step
>>>> back from the realm.
>>>>
>>>> The Elytron subsystem will be exposing SecurityDomains as a capability,
>>>> strictly speaking it is these that secured resources will have a
>>>> dependency on.
>>>>
>>>> A SecurityDomain will reference one or more SecurityRealm instances.  So
>>>> within the Elytron subsystem I need to be able to reference security
>>>> realms defined within the Elytron subsystem - but also have the ability
>>>> to reference security realms defined in other subsystems, but I also
>>>> don't want the Elytron subsystem to need knowledge of the other
>>>> subsystems beyond values that are set in the model.
>>>>
>>>> This pattern could also repeat for KeyStore, KeyManager and TrustManager
>>>> which are also ideal candidates for other subsystems to provide their
>>>> own implementations of.
>>>>
>>>
>>> Hmm, so some sort of non-exclusive capability thing. Or some way that a
>>> capability can declare the context in which it must be exclusive, one
>>> option being "NONE".
>>
>> For the capabilities we are talking about at the moment we are really
>> talking about named capabilities or model references - for these do we
>> have examples where exclusivity would be required?
>>
>
> Named capabilities.
>
> Examples where exclusivity is required:
>
> jacorb vs iiop-jdk, both providing IIOP capabilities
>
> web compatibility subsystem vs undertow, both providing various
> HTTP/servlet capabilities
>
> messaging vs the-new-one, both providing JMS

What I mean here is, my security realm would have both a name for the 
capability name e.g. org.wildfly.security.security_realm and a name for 
the instance, e.g. CorporateRealm.

For those examples if you don't have an instance name then yes I see 
exclusivity would be needed - those are following the lines of "I am the 
servers IIOP Provider"

>
>


From brian.stansberry at redhat.com  Wed Mar 25 12:01:52 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 25 Mar 2015 11:01:52 -0500
Subject: [wildfly-dev] Preparation for requirements and capabilities.
In-Reply-To: <5512D740.1090108@jboss.com>
References: <550AA2D9.4040103@jboss.com>	<550B02A9.6050508@jboss.com>	<551173AF.4040101@redhat.com>	<551175A4.1000409@jboss.com>	<5511777F.9040005@redhat.com>	<5511A82D.9000704@jboss.com>	<5511C502.2060306@redhat.com>	<5512A3B4.2010609@jboss.com>	<5512C62B.2040007@redhat.com>	<5512C807.5050500@jboss.com>	<5512C9D9.4030703@redhat.com>	<5512CC19.3000700@jboss.com>	<5512CDA7.5050702@redhat.com>	<5512D413.9090307@jboss.com>	<5512D581.4080406@redhat.com>
	<5512D740.1090108@jboss.com>
Message-ID: <5512DBF0.9090507@redhat.com>

On 3/25/15 10:41 AM, Darran Lofthouse wrote:
>
>
> On 25/03/15 15:34, Brian Stansberry wrote:
>> On 3/25/15 10:28 AM, Darran Lofthouse wrote:
 >>>
>>> For the capabilities we are talking about at the moment we are really
>>> talking about named capabilities or model references - for these do we
>>> have examples where exclusivity would be required?
>>>
>>
>> Named capabilities.
>>
>> Examples where exclusivity is required:
>>
>> jacorb vs iiop-jdk, both providing IIOP capabilities
>>
>> web compatibility subsystem vs undertow, both providing various
>> HTTP/servlet capabilities
>>
>> messaging vs the-new-one, both providing JMS
>
> What I mean here is, my security realm would have both a name for the
> capability name e.g. org.wildfly.security.security_realm and a name for
> the instance, e.g. CorporateRealm.
>
> For those examples if you don't have an instance name then yes I see
> exclusivity would be needed - those are following the lines of "I am the
> servers IIOP Provider"
>

Maybe that distinction will work.  It initially felt a bit like 
stretching an abstraction to cover something else. But if you conceive 
of both of these cases as needing to produce a unique name, but in the 
named instance case the last element of the name just happens to be 
dynamic, then it works and seems simpler.

Only one of these is allowed in a context

org.wildfly.extension.iiop
org.wildfly.extension.security.security-realm.foo
org.wildfly.extension.security.security-realm.bar

How those strings are constructed is a separate issue. The first is 
static, the latter two are a static prefix and a dynamic suffix.



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

From darran.lofthouse at jboss.com  Wed Mar 25 12:10:27 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Wed, 25 Mar 2015 16:10:27 +0000
Subject: [wildfly-dev] Preparation for requirements and capabilities.
In-Reply-To: <5512DBF0.9090507@redhat.com>
References: <550AA2D9.4040103@jboss.com>	<550B02A9.6050508@jboss.com>	<551173AF.4040101@redhat.com>	<551175A4.1000409@jboss.com>	<5511777F.9040005@redhat.com>	<5511A82D.9000704@jboss.com>	<5511C502.2060306@redhat.com>	<5512A3B4.2010609@jboss.com>	<5512C62B.2040007@redhat.com>	<5512C807.5050500@jboss.com>	<5512C9D9.4030703@redhat.com>	<5512CC19.3000700@jboss.com>	<5512CDA7.5050702@redhat.com>	<5512D413.9090307@jboss.com>	<5512D581.4080406@redhat.com>	<5512D740.1090108@jboss.com>
	<5512DBF0.9090507@redhat.com>
Message-ID: <5512DDF3.4080609@jboss.com>



On 25/03/15 16:01, Brian Stansberry wrote:
> On 3/25/15 10:41 AM, Darran Lofthouse wrote:
>>
>>
>> On 25/03/15 15:34, Brian Stansberry wrote:
>>> On 3/25/15 10:28 AM, Darran Lofthouse wrote:
>   >>>
>>>> For the capabilities we are talking about at the moment we are really
>>>> talking about named capabilities or model references - for these do we
>>>> have examples where exclusivity would be required?
>>>>
>>>
>>> Named capabilities.
>>>
>>> Examples where exclusivity is required:
>>>
>>> jacorb vs iiop-jdk, both providing IIOP capabilities
>>>
>>> web compatibility subsystem vs undertow, both providing various
>>> HTTP/servlet capabilities
>>>
>>> messaging vs the-new-one, both providing JMS
>>
>> What I mean here is, my security realm would have both a name for the
>> capability name e.g. org.wildfly.security.security_realm and a name for
>> the instance, e.g. CorporateRealm.
>>
>> For those examples if you don't have an instance name then yes I see
>> exclusivity would be needed - those are following the lines of "I am the
>> servers IIOP Provider"
>>
>
> Maybe that distinction will work.  It initially felt a bit like
> stretching an abstraction to cover something else. But if you conceive
> of both of these cases as needing to produce a unique name, but in the
> named instance case the last element of the name just happens to be
> dynamic, then it works and seems simpler.
>
> Only one of these is allowed in a context
>
> org.wildfly.extension.iiop
> org.wildfly.extension.security.security-realm.foo
> org.wildfly.extension.security.security-realm.bar

That seems reasonable to me, any tooling can probably use whatever ops 
are provided to discover existing security realms to assist the user in 
ensuring the name they give their new security realm is actually unique 
across the context.

>
> How those strings are constructed is a separate issue. The first is
> static, the latter two are a static prefix and a dynamic suffix.
>
>
>

From pharaxdev at gmail.com  Thu Mar 26 13:04:25 2015
From: pharaxdev at gmail.com (=?UTF-8?Q?Norbert_B=C3=A1nyai?=)
Date: Thu, 26 Mar 2015 18:04:25 +0100
Subject: [wildfly-dev] How does clustering and session replication work in
	wildfly?
Message-ID: <CANyhksGSYL19K9EO_H2ceix3iUCcUwEAfw7QjFKJuRGO40NPVg@mail.gmail.com>

Hi,

I'm Norbert B?nyai a graduate student at University of Debrecen from
Hungary. I write my thesis about clusters and load-balancing.

I have already set up a cluster working fine, so my question is the next
(as already mentioned in the subject field):

How does the clustering and session replication work in Wildfly?

I would highly appriciate any information. I believe every pinch of new
information would be a great help. Thank you in advance. :)

Yours sincerely,
Norbert B?nyai
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150326/908e0954/attachment.html 

From tomaz.cerar at gmail.com  Thu Mar 26 19:13:06 2015
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Fri, 27 Mar 2015 00:13:06 +0100
Subject: [wildfly-dev] Dropping legacy XSD schemas & its parsers
Message-ID: <CAMquZP4kGzBv+jy_f_P3nmVv=tPXwFFGwbWOzkpAa=vaPJdY0Q@mail.gmail.com>

Hi folks,

we discussed on team meeting in Brno about dropping support for old legacy
host controllers
when running in mixed domain mode (having DC of newer version managing
older version HCs)

We also discussed dropping old xsd sachems & parsers as it would help us
cleanup and simplify code
in many subsystems as there are cases where we support and maintain 5 and
more different
versions of parser. For example currently web subsystem has 8, infinispan
7, ejb  & jackorb have 6, ...
We still have parsers that that ware shipped back in 7.0.0 and became
obsolete in later 7.0.x releases.

Given that we decided that we are dropping support for running mixed domain
mode for host controller
that are older than 7.3.0 (EAP 6.2) as is tracked by
https://issues.jboss.org/browse/WFLY-3564

I would also like to suggest that we do the same for xml schemas & parsers.

*What is the downside?*

Automatic upgrading from JBoss AS 7.1.x/EAP < 6.2 version with using same
standalone.xml won't work anymore.
User would need to upgrade to WildFly 8.x and from there to 9 or 10
(depending when we drop this)
Because of replacement of web subsystem with undertow and introduction of
few other subsystems (io, SM)
this already doesn't work for 7.x-->8+, but we do have plans how to improve
that.


So, are there any objections against this?

--
Toma?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150327/345e4156/attachment.html 

From jason.greene at redhat.com  Fri Mar 27 00:47:11 2015
From: jason.greene at redhat.com (Jason Greene)
Date: Thu, 26 Mar 2015 23:47:11 -0500
Subject: [wildfly-dev] WildFly 9 Beta1 Released
Message-ID: <365D7599-7A2F-4298-AC16-38A881DBFF01@redhat.com>

Hello Everyone,

See my (short) announcement here:
http://wildfly.org/news/2015/03/26/WildFly9-Beta-Released/

Download:
http://wildfly.org/downloads

Release notes:
https://developer.jboss.org/wiki/WildFly900Beta1ReleaseNotes

Also checkout some nice blogs about it:
http://wildfly.org/news/2015/03/13/Offline-CLI/
http://undertow.io/blog/2015/03/26/HTTP2-In-Wildfly.html
http://undertow.io/blog/2015/03/25/Server-Push.html

Stuart has a nice video on combining front end balancing + CLI + domain mode:
https://www.youtube.com/watch?v=xa_gtRDpwyQ 

Thank you all for the hard work!

Now, onto CR1 :)

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


From darran.lofthouse at jboss.com  Fri Mar 27 07:04:30 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Fri, 27 Mar 2015 11:04:30 +0000
Subject: [wildfly-dev] Dropping legacy XSD schemas & its parsers
In-Reply-To: <CAMquZP4kGzBv+jy_f_P3nmVv=tPXwFFGwbWOzkpAa=vaPJdY0Q@mail.gmail.com>
References: <CAMquZP4kGzBv+jy_f_P3nmVv=tPXwFFGwbWOzkpAa=vaPJdY0Q@mail.gmail.com>
Message-ID: <5515393E.8000501@jboss.com>

If we can document a way EAP users can use EAP 6.4 and JBoss AS7 / 
WildFly users can use WildFly 9.0.0.Final in admin only mode to read in 
legacy config and write it as the latest then technically no one should 
be blocked if they happen to use a schema version now removed.

A general issue with parsers is we have them loaded for all versions 
ever supported, could this be an opportunity to switch to some form of 
factory so that appropriate versions can be loaded on demand.

Regards,
Darran Lofthouse.


On 26/03/15 23:13, Toma? Cerar wrote:
> Hi folks,
>
> we discussed on team meeting in Brno about dropping support for old
> legacy host controllers
> when running in mixed domain mode (having DC of newer version managing
> older version HCs)
>
> We also discussed dropping old xsd sachems & parsers as it would help us
> cleanup and simplify code
> in many subsystems as there are cases where we support and maintain 5
> and more different
> versions of parser. For example currently web subsystem has 8,
> infinispan 7, ejb  & jackorb have 6, ...
> We still have parsers that that ware shipped back in 7.0.0 and became
> obsolete in later 7.0.x releases.
>
> Given that we decided that we are dropping support for running mixed
> domain mode for host controller
> that are older than 7.3.0 (EAP 6.2) as is tracked by
> https://issues.jboss.org/browse/WFLY-3564
>
> I would also like to suggest that we do the same for xml schemas & parsers.
>
> *What is the downside?*
>
> Automatic upgrading from JBoss AS 7.1.x/EAP < 6.2 version with using
> same standalone.xml won't work anymore.
> User would need to upgrade to WildFly 8.x and from there to 9 or 10
> (depending when we drop this)
> Because of replacement of web subsystem with undertow and introduction
> of few other subsystems (io, SM)
> this already doesn't work for 7.x-->8+, but we do have plans how to
> improve that.
>
>
> So, are there any objections against this?
>
> --
> Toma?
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From paul.ferraro at redhat.com  Fri Mar 27 08:59:25 2015
From: paul.ferraro at redhat.com (Paul Ferraro)
Date: Fri, 27 Mar 2015 08:59:25 -0400 (EDT)
Subject: [wildfly-dev] How does clustering and session replication work
 in	wildfly?
In-Reply-To: <CANyhksGSYL19K9EO_H2ceix3iUCcUwEAfw7QjFKJuRGO40NPVg@mail.gmail.com>
References: <CANyhksGSYL19K9EO_H2ceix3iUCcUwEAfw7QjFKJuRGO40NPVg@mail.gmail.com>
Message-ID: <676206998.4327167.1427461165378.JavaMail.zimbra@redhat.com>

This list is intended for development discussions.  Please direct questions of this nature to the forums.

----- Original Message -----
> From: "Norbert B?nyai" <pharaxdev at gmail.com>
> To: wildfly-dev at lists.jboss.org
> Sent: Thursday, March 26, 2015 1:04:25 PM
> Subject: [wildfly-dev] How does clustering and session replication work in	wildfly?
> 
> Hi,
> 
> I'm Norbert B?nyai a graduate student at University of Debrecen from Hungary.
> I write my thesis about clusters and load-balancing.
> 
> I have already set up a cluster working fine, so my question is the next (as
> already mentioned in the subject field):
> 
> How does the clustering and session replication work in Wildfly?
> 
> I would highly appriciate any information. I believe every pinch of new
> information would be a great help. Thank you in advance. :)
> 
> Yours sincerely,
> Norbert B?nyai
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From brian.stansberry at redhat.com  Fri Mar 27 11:07:20 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Fri, 27 Mar 2015 10:07:20 -0500
Subject: [wildfly-dev] Dropping legacy XSD schemas & its parsers
In-Reply-To: <CAMquZP4kGzBv+jy_f_P3nmVv=tPXwFFGwbWOzkpAa=vaPJdY0Q@mail.gmail.com>
References: <CAMquZP4kGzBv+jy_f_P3nmVv=tPXwFFGwbWOzkpAa=vaPJdY0Q@mail.gmail.com>
Message-ID: <55157228.2000604@redhat.com>

My only objection is to spending a lot of energy refactoring to rip 
things out, reviewing the refactors, and fixing the unexpected breakage. 
I don't have a problem with the general principle dropping parser 
support for really old versions.

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.

On 3/26/15 6:13 PM, Toma? Cerar wrote:
> Hi folks,
>
> we discussed on team meeting in Brno about dropping support for old
> legacy host controllers
> when running in mixed domain mode (having DC of newer version managing
> older version HCs)
>
> We also discussed dropping old xsd sachems & parsers as it would help us
> cleanup and simplify code
> in many subsystems as there are cases where we support and maintain 5
> and more different
> versions of parser. For example currently web subsystem has 8,
> infinispan 7, ejb  & jackorb have 6, ...
> We still have parsers that that ware shipped back in 7.0.0 and became
> obsolete in later 7.0.x releases.
>
> Given that we decided that we are dropping support for running mixed
> domain mode for host controller
> that are older than 7.3.0 (EAP 6.2) as is tracked by
> https://issues.jboss.org/browse/WFLY-3564
>
> I would also like to suggest that we do the same for xml schemas & parsers.
>
> *What is the downside?*
>
> Automatic upgrading from JBoss AS 7.1.x/EAP < 6.2 version with using
> same standalone.xml won't work anymore.
> User would need to upgrade to WildFly 8.x and from there to 9 or 10
> (depending when we drop this)
> Because of replacement of web subsystem with undertow and introduction
> of few other subsystems (io, SM)
> this already doesn't work for 7.x-->8+, but we do have plans how to
> improve that.
>
>
> So, are there any objections against this?
>
> --
> Toma?
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> 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 Mar 27 11:08:33 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Fri, 27 Mar 2015 10:08:33 -0500
Subject: [wildfly-dev] Dropping legacy XSD schemas & its parsers
In-Reply-To: <55157228.2000604@redhat.com>
References: <CAMquZP4kGzBv+jy_f_P3nmVv=tPXwFFGwbWOzkpAa=vaPJdY0Q@mail.gmail.com>
	<55157228.2000604@redhat.com>
Message-ID: <55157271.7070907@redhat.com>

I forgot to say... is this better dealt with early in 10?

On 3/27/15 10:07 AM, Brian Stansberry wrote:
> My only objection is to spending a lot of energy refactoring to rip
> things out, reviewing the refactors, and fixing the unexpected breakage.
> I don't have a problem with the general principle dropping parser
> support for really old versions.
>
> 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.
>
> On 3/26/15 6:13 PM, Toma? Cerar wrote:
>> Hi folks,
>>
>> we discussed on team meeting in Brno about dropping support for old
>> legacy host controllers
>> when running in mixed domain mode (having DC of newer version managing
>> older version HCs)
>>
>> We also discussed dropping old xsd sachems & parsers as it would help us
>> cleanup and simplify code
>> in many subsystems as there are cases where we support and maintain 5
>> and more different
>> versions of parser. For example currently web subsystem has 8,
>> infinispan 7, ejb  & jackorb have 6, ...
>> We still have parsers that that ware shipped back in 7.0.0 and became
>> obsolete in later 7.0.x releases.
>>
>> Given that we decided that we are dropping support for running mixed
>> domain mode for host controller
>> that are older than 7.3.0 (EAP 6.2) as is tracked by
>> https://issues.jboss.org/browse/WFLY-3564
>>
>> I would also like to suggest that we do the same for xml schemas &
>> parsers.
>>
>> *What is the downside?*
>>
>> Automatic upgrading from JBoss AS 7.1.x/EAP < 6.2 version with using
>> same standalone.xml won't work anymore.
>> User would need to upgrade to WildFly 8.x and from there to 9 or 10
>> (depending when we drop this)
>> Because of replacement of web subsystem with undertow and introduction
>> of few other subsystems (io, SM)
>> this already doesn't work for 7.x-->8+, but we do have plans how to
>> improve that.
>>
>>
>> So, are there any objections against this?
>>
>> --
>> Toma?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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 manderse at redhat.com  Fri Mar 27 11:56:41 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Fri, 27 Mar 2015 16:56:41 +0100
Subject: [wildfly-dev] Dropping legacy XSD schemas & its parsers
In-Reply-To: <CAMquZP4kGzBv+jy_f_P3nmVv=tPXwFFGwbWOzkpAa=vaPJdY0Q@mail.gmail.com>
References: <CAMquZP4kGzBv+jy_f_P3nmVv=tPXwFFGwbWOzkpAa=vaPJdY0Q@mail.gmail.com>
Message-ID: <52B29D05-3997-47E3-853B-9F877ADDB179@redhat.com>

this sounds like a god candidate for rulesets for Windup to help doing 
migrations ?

/max

> Hi folks,
>
> we discussed on team meeting in Brno about dropping support for old 
> legacy
> host controllers
> when running in mixed domain mode (having DC of newer version managing
> older version HCs)
>
> We also discussed dropping old xsd sachems & parsers as it would help 
> us
> cleanup and simplify code
> in many subsystems as there are cases where we support and maintain 5 
> and
> more different
> versions of parser. For example currently web subsystem has 8, 
> infinispan
> 7, ejb  & jackorb have 6, ...
> We still have parsers that that ware shipped back in 7.0.0 and became
> obsolete in later 7.0.x releases.
>
> Given that we decided that we are dropping support for running mixed 
> domain
> mode for host controller
> that are older than 7.3.0 (EAP 6.2) as is tracked by
> https://issues.jboss.org/browse/WFLY-3564
>
> I would also like to suggest that we do the same for xml schemas & 
> parsers.
>
> *What is the downside?*
>
> Automatic upgrading from JBoss AS 7.1.x/EAP < 6.2 version with using 
> same
> standalone.xml won't work anymore.
> User would need to upgrade to WildFly 8.x and from there to 9 or 10
> (depending when we drop this)
> Because of replacement of web subsystem with undertow and introduction 
> of
> few other subsystems (io, SM)
> this already doesn't work for 7.x-->8+, but we do have plans how to 
> improve
> that.
>
>
> So, are there any objections against this?
>
> --
> Toma?
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


/max
http://about.me/maxandersen

From sgilda at redhat.com  Fri Mar 27 14:43:42 2015
From: sgilda at redhat.com (Sande Gilda)
Date: Fri, 27 Mar 2015 14:43:42 -0400
Subject: [wildfly-dev] Dropping legacy XSD schemas & its parsers
In-Reply-To: <52B29D05-3997-47E3-853B-9F877ADDB179@redhat.com>
References: <CAMquZP4kGzBv+jy_f_P3nmVv=tPXwFFGwbWOzkpAa=vaPJdY0Q@mail.gmail.com>
	<52B29D05-3997-47E3-853B-9F877ADDB179@redhat.com>
Message-ID: <5515A4DE.6010501@redhat.com>

Adding the JBoss Migration team. This is good information to track for 
the Windup rules.

On 03/27/2015 11:56 AM, Max Rydahl Andersen wrote:
> this sounds like a god candidate for rulesets for Windup to help doing
> migrations ?
>
> /max
>
>> Hi folks,
>>
>> we discussed on team meeting in Brno about dropping support for old
>> legacy
>> host controllers
>> when running in mixed domain mode (having DC of newer version managing
>> older version HCs)
>>
>> We also discussed dropping old xsd sachems & parsers as it would help
>> us
>> cleanup and simplify code
>> in many subsystems as there are cases where we support and maintain 5
>> and
>> more different
>> versions of parser. For example currently web subsystem has 8,
>> infinispan
>> 7, ejb  & jackorb have 6, ...
>> We still have parsers that that ware shipped back in 7.0.0 and became
>> obsolete in later 7.0.x releases.
>>
>> Given that we decided that we are dropping support for running mixed
>> domain
>> mode for host controller
>> that are older than 7.3.0 (EAP 6.2) as is tracked by
>> https://issues.jboss.org/browse/WFLY-3564
>>
>> I would also like to suggest that we do the same for xml schemas &
>> parsers.
>>
>> *What is the downside?*
>>
>> Automatic upgrading from JBoss AS 7.1.x/EAP < 6.2 version with using
>> same
>> standalone.xml won't work anymore.
>> User would need to upgrade to WildFly 8.x and from there to 9 or 10
>> (depending when we drop this)
>> Because of replacement of web subsystem with undertow and introduction
>> of
>> few other subsystems (io, SM)
>> this already doesn't work for 7.x-->8+, but we do have plans how to
>> improve
>> that.
>>
>>
>> So, are there any objections against this?
>>
>> --
>> Toma?
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> /max
> http://about.me/maxandersen
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From kustos at gmx.net  Sat Mar 28 09:42:28 2015
From: kustos at gmx.net (Philippe Marschall)
Date: Sat, 28 Mar 2015 14:42:28 +0100
Subject: [wildfly-dev] JMX over HTTPS broken
Message-ID: <5516AFC4.40205@gmx.net>

Hi

It looks as if JMX over HTTPS is broken.

Issue, pull request and forum reference below.

https://issues.jboss.org/browse/REMJMX-92
https://github.com/jbossas/remoting-jmx/pull/19
https://developer.jboss.org/thread/253672

Cheers
Philippe

From eduardo.santanadasilva at gmail.com  Sat Mar 28 12:56:07 2015
From: eduardo.santanadasilva at gmail.com (=?UTF-8?Q?Eduardo_Sant=C2=B4Ana_da_Silva?=)
Date: Sat, 28 Mar 2015 13:56:07 -0300
Subject: [wildfly-dev] WFLY-4169 Wildfly doesn't fail on deployment EJB with
	CDI @Transactional
Message-ID: <CAFVp3Z5wMFSfJsbgusjzEu=pE15TOGWP2DUoi42zCPOb2u5cvw@mail.gmail.com>

I'm looking at this issue:
https://issues.jboss.org/browse/WFLY-4169

In the ejb-3_2 specification :
It is illegal to associate JTA transactional interceptors (see [8]) with
Enterprise JavaBeans. The EJB Container should fail deployment of such
applications.[39]

@Transaction annotation was introduced in JTA 1.2,

As Narayana 5.0.0.M3 is now JTA 1.2 compliant, and it was introduced on
Wildfly since version WildFly 8.0.0.Beta1, what should be done?

Because this restriction could be removed in the future versions:

[39] This restriction may be removed in a future release of this
specification

If this is needed, how to proceed? Should be done on Weld subsystem,
something similar with the annotations markers, just to log the problem or
it will be more tricky, since the deployment should be rolled back (by the
specification)?
-- 
__________________________
Eduardo Sant'Ana da Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150328/8c686405/attachment.html 

From jason.greene at redhat.com  Sat Mar 28 14:05:27 2015
From: jason.greene at redhat.com (Jason T. Greene)
Date: Sat, 28 Mar 2015 14:05:27 -0400 (EDT)
Subject: [wildfly-dev] WFLY-4169 Wildfly doesn't fail on deployment EJB
	with	CDI @Transactional
In-Reply-To: <CAFVp3Z5wMFSfJsbgusjzEu=pE15TOGWP2DUoi42zCPOb2u5cvw@mail.gmail.com>
References: <CAFVp3Z5wMFSfJsbgusjzEu=pE15TOGWP2DUoi42zCPOb2u5cvw@mail.gmail.com>
Message-ID: <C8DA6F08-5450-4849-8ED7-714ACCE7B342@redhat.com>

Good question. The easiest solution is probably to change one of the EJB dups that looks at annotations to also check for @Transactional and fail accordingly.

Sent from my iPhone

> On Mar 28, 2015, at 11:56 AM, Eduardo Sant?Ana da Silva <eduardo.santanadasilva at gmail.com> wrote:
> 
> I'm looking at this issue:
> https://issues.jboss.org/browse/WFLY-4169
> 
> In the ejb-3_2 specification :
> It is illegal to associate JTA transactional interceptors (see [8]) with Enterprise JavaBeans. The EJB Container should fail deployment of such applications.[39]
> 
> @Transaction annotation was introduced in JTA 1.2, 
> 
> As Narayana 5.0.0.M3 is now JTA 1.2 compliant, and it was introduced on Wildfly since version WildFly 8.0.0.Beta1, what should be done?
> 
> Because this restriction could be removed in the future versions:
> 
> [39] This restriction may be removed in a future release of this specification
> 
> If this is needed, how to proceed? Should be done on Weld subsystem, something similar with the annotations markers, just to log the problem or it will be more tricky, since the deployment should be rolled back (by the specification)?
> 
> -- 
> __________________________
> Eduardo Sant'Ana da Silva
> 
> _______________________________________________
> 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/20150328/4923eb65/attachment.html 

From eduardo.santanadasilva at gmail.com  Sun Mar 29 06:34:17 2015
From: eduardo.santanadasilva at gmail.com (=?UTF-8?Q?Eduardo_Sant=C2=B4Ana_da_Silva?=)
Date: Sun, 29 Mar 2015 07:34:17 -0300
Subject: [wildfly-dev] WFLY-4169 Wildfly doesn't fail on deployment EJB
 with CDI @Transactional
In-Reply-To: <C8DA6F08-5450-4849-8ED7-714ACCE7B342@redhat.com>
References: <CAFVp3Z5wMFSfJsbgusjzEu=pE15TOGWP2DUoi42zCPOb2u5cvw@mail.gmail.com>
	<C8DA6F08-5450-4849-8ED7-714ACCE7B342@redhat.com>
Message-ID: <CAFVp3Z7WBPFtHa1sfjrPA0_X51n3D9dSVH4Bv1T_KW773rWOog@mail.gmail.com>

Ok,

My approach will be create the following classes:

* ProhibitedEJBAnnotationsAnnotationMarker - Mark the deployment if it has
EJB annotations that are not allowed (Similar to CDI Annotation marker no
Weld)

* ProhibitedEJBAnnotationsDeploymentUnitProcessor - Do the deployment
rollback in case of the marker is present.


Add the proper cleanup of the attachments no EjbCleanUpProcessor

Some auxilar classes to be created:

public enum ProhibitedEJBAnnotations {

    /**
     * javax.transaction.Transactional annotation.

     */

    TRANSACTIONAL(Constants.JAVAX_TRANSACTION, "Transactional"),

...

    private static class Constants {

        /**
         *  package javax.transaction
         */

        public static final DotName JAVAX_TRANSACTION =
DotName.createSimple("javax.transaction");

...

//////////////////////////////////////
/**
 * Marker for deployments that have prohibited EJB annotations present
 */

public final class ProhibitedEJBAnnotationsAnnotationMarker {    (Similar
to CdiAnnotationMarker on Weld)

...

public class ProhibitedEJBAnnotationsDeploymentUnitProcessor implements

DeploymentUnitProcessor {


If you guys came up with  better names it will be good.

I was wondering as well if the CDIAnnotationMarker can be used directly
from the Weld subsystem or it will be better isolate the subsystems?

Thx
__________________________
Eduardo Sant'Ana da Silva

2015-03-28 15:05 GMT-03:00 Jason T. Greene <jason.greene at redhat.com>:

> Good question. The easiest solution is probably to change one of the EJB
> dups that looks at annotations to also check for @Transactional and fail
> accordingly.
>
> Sent from my iPhone
>
> On Mar 28, 2015, at 11:56 AM, Eduardo Sant?Ana da Silva <
> eduardo.santanadasilva at gmail.com> wrote:
>
> I'm looking at this issue:
> https://issues.jboss.org/browse/WFLY-4169
>
> In the ejb-3_2 specification :
> It is illegal to associate JTA transactional interceptors (see [8]) with
> Enterprise JavaBeans. The EJB Container should fail deployment of such
> applications.[39]
>
> @Transaction annotation was introduced in JTA 1.2,
>
> As Narayana 5.0.0.M3 is now JTA 1.2 compliant, and it was introduced on
> Wildfly since version WildFly 8.0.0.Beta1, what should be done?
>
> Because this restriction could be removed in the future versions:
>
> [39] This restriction may be removed in a future release of this
> specification
>
> If this is needed, how to proceed? Should be done on Weld subsystem,
> something similar with the annotations markers, just to log the problem or
> it will be more tricky, since the deployment should be rolled back (by the
> specification)?
> --
> __________________________
> Eduardo Sant'Ana da Silva
>
>  _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>


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

From stuart.w.douglas at gmail.com  Sun Mar 29 18:16:10 2015
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Sun, 29 Mar 2015 22:16:10 +0000
Subject: [wildfly-dev] WFLY-4169 Wildfly doesn't fail on deployment EJB
 with CDI @Transactional
In-Reply-To: <CAFVp3Z7WBPFtHa1sfjrPA0_X51n3D9dSVH4Bv1T_KW773rWOog@mail.gmail.com>
References: <CAFVp3Z5wMFSfJsbgusjzEu=pE15TOGWP2DUoi42zCPOb2u5cvw@mail.gmail.com>
	<C8DA6F08-5450-4849-8ED7-714ACCE7B342@redhat.com>
	<CAFVp3Z7WBPFtHa1sfjrPA0_X51n3D9dSVH4Bv1T_KW773rWOog@mail.gmail.com>
Message-ID: <CAAoo=c6Zhi4ZeXfMvXe4hH_gfQ8AMFccStaZm7HLJzCEn_v4hg@mail.gmail.com>

On Sun, 29 Mar 2015 at 21:34 Eduardo Sant?Ana da Silva <
eduardo.santanadasilva at gmail.com> wrote:

> Ok,
>
> My approach will be create the following classes:
>
> * ProhibitedEJBAnnotationsAnnotationMarker - Mark the deployment if it has
> EJB annotations that are not allowed (Similar to CDI Annotation marker no
> Weld)
>

I don't really see why you would need to mark the deployment if it has
invalid annotations, you should be able to just fail immediately.

I think all you need is a single DUP that looks at every EJB component
description for this annotation, and if it is present throw an exception.

Stuart


> * ProhibitedEJBAnnotationsDeploymentUnitProcessor - Do the deployment
> rollback in case of the marker is present.
>
>
> Add the proper cleanup of the attachments no EjbCleanUpProcessor
>
> Some auxilar classes to be created:
>
> public enum ProhibitedEJBAnnotations {
>
>     /**
>      * javax.transaction.Transactional annotation.
>
>      */
>
>     TRANSACTIONAL(Constants.JAVAX_TRANSACTION, "Transactional"),
>
> ...
>
>     private static class Constants {
>
>         /**
>          *  package javax.transaction
>          */
>
>         public static final DotName JAVAX_TRANSACTION =
> DotName.createSimple("javax.transaction");
>
> ...
>
> //////////////////////////////////////
> /**
>  * Marker for deployments that have prohibited EJB annotations present
>  */
>
> public final class ProhibitedEJBAnnotationsAnnotationMarker {    (Similar
> to CdiAnnotationMarker on Weld)
>
> ...
>
> public class ProhibitedEJBAnnotationsDeploymentUnitProcessor implements
>
> DeploymentUnitProcessor {
>
>
> If you guys came up with  better names it will be good.
>
> I was wondering as well if the CDIAnnotationMarker can be used directly
> from the Weld subsystem or it will be better isolate the subsystems?
>
> Thx
> __________________________
> Eduardo Sant'Ana da Silva
>
> 2015-03-28 15:05 GMT-03:00 Jason T. Greene <jason.greene at redhat.com>:
>
> Good question. The easiest solution is probably to change one of the EJB
>> dups that looks at annotations to also check for @Transactional and fail
>> accordingly.
>>
>> Sent from my iPhone
>>
>> On Mar 28, 2015, at 11:56 AM, Eduardo Sant?Ana da Silva <
>> eduardo.santanadasilva at gmail.com> wrote:
>>
>> I'm looking at this issue:
>> https://issues.jboss.org/browse/WFLY-4169
>>
>> In the ejb-3_2 specification :
>> It is illegal to associate JTA transactional interceptors (see [8]) with
>> Enterprise JavaBeans. The EJB Container should fail deployment of such
>> applications.[39]
>>
>> @Transaction annotation was introduced in JTA 1.2,
>>
>> As Narayana 5.0.0.M3 is now JTA 1.2 compliant, and it was introduced on
>> Wildfly since version WildFly 8.0.0.Beta1, what should be done?
>>
>> Because this restriction could be removed in the future versions:
>>
>> [39] This restriction may be removed in a future release of this
>> specification
>>
>> If this is needed, how to proceed? Should be done on Weld subsystem,
>> something similar with the annotations markers, just to log the problem or
>> it will be more tricky, since the deployment should be rolled back (by the
>> specification)?
>> --
>> __________________________
>> Eduardo Sant'Ana da Silva
>>
>>  _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>
>
> --
> __________________________
> Eduardo Sant'Ana da Silva - Dr.
> Pesquisador / Consultor de TI
>
>  _______________________________________________
> 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/20150329/84d372a0/attachment.html 

From eduardo.santanadasilva at gmail.com  Mon Mar 30 07:01:24 2015
From: eduardo.santanadasilva at gmail.com (=?UTF-8?Q?Eduardo_Sant=C2=B4Ana_da_Silva?=)
Date: Mon, 30 Mar 2015 08:01:24 -0300
Subject: [wildfly-dev] WFLY-4169 Wildfly doesn't fail on deployment EJB
 with CDI @Transactional
In-Reply-To: <CAAoo=c6Zhi4ZeXfMvXe4hH_gfQ8AMFccStaZm7HLJzCEn_v4hg@mail.gmail.com>
References: <CAFVp3Z5wMFSfJsbgusjzEu=pE15TOGWP2DUoi42zCPOb2u5cvw@mail.gmail.com>
	<C8DA6F08-5450-4849-8ED7-714ACCE7B342@redhat.com>
	<CAFVp3Z7WBPFtHa1sfjrPA0_X51n3D9dSVH4Bv1T_KW773rWOog@mail.gmail.com>
	<CAAoo=c6Zhi4ZeXfMvXe4hH_gfQ8AMFccStaZm7HLJzCEn_v4hg@mail.gmail.com>
Message-ID: <CAFVp3Z6vvcG5WMexECBNq-xBz+jQQxpgzSzkEaisR64yf1SjLQ@mail.gmail.com>

Ok.

2015-03-29 19:16 GMT-03:00 Stuart Douglas <stuart.w.douglas at gmail.com>:

>
>
> On Sun, 29 Mar 2015 at 21:34 Eduardo Sant?Ana da Silva <
> eduardo.santanadasilva at gmail.com> wrote:
>
>> Ok,
>>
>> My approach will be create the following classes:
>>
>> * ProhibitedEJBAnnotationsAnnotationMarker - Mark the deployment if it
>> has EJB annotations that are not allowed (Similar to CDI Annotation marker
>> no Weld)
>>
>
> I don't really see why you would need to mark the deployment if it has
> invalid annotations, you should be able to just fail immediately.
>
> I think all you need is a single DUP that looks at every EJB component
> description for this annotation, and if it is present throw an exception.
>
> Stuart
>
>
>> * ProhibitedEJBAnnotationsDeploymentUnitProcessor - Do the deployment
>> rollback in case of the marker is present.
>>
>>
>> Add the proper cleanup of the attachments no EjbCleanUpProcessor
>>
>> Some auxilar classes to be created:
>>
>> public enum ProhibitedEJBAnnotations {
>>
>>     /**
>>      * javax.transaction.Transactional annotation.
>>
>>      */
>>
>>     TRANSACTIONAL(Constants.JAVAX_TRANSACTION, "Transactional"),
>>
>> ...
>>
>>     private static class Constants {
>>
>>         /**
>>          *  package javax.transaction
>>          */
>>
>>         public static final DotName JAVAX_TRANSACTION =
>> DotName.createSimple("javax.transaction");
>>
>> ...
>>
>> //////////////////////////////////////
>> /**
>>  * Marker for deployments that have prohibited EJB annotations present
>>  */
>>
>> public final class ProhibitedEJBAnnotationsAnnotationMarker {
>> (Similar to CdiAnnotationMarker on Weld)
>>
>> ...
>>
>> public class ProhibitedEJBAnnotationsDeploymentUnitProcessor implements
>>
>> DeploymentUnitProcessor {
>>
>>
>> If you guys came up with  better names it will be good.
>>
>> I was wondering as well if the CDIAnnotationMarker can be used directly
>> from the Weld subsystem or it will be better isolate the subsystems?
>>
>> Thx
>> __________________________
>> Eduardo Sant'Ana da Silva
>>
>> 2015-03-28 15:05 GMT-03:00 Jason T. Greene <jason.greene at redhat.com>:
>>
>> Good question. The easiest solution is probably to change one of the EJB
>>> dups that looks at annotations to also check for @Transactional and fail
>>> accordingly.
>>>
>>> Sent from my iPhone
>>>
>>> On Mar 28, 2015, at 11:56 AM, Eduardo Sant?Ana da Silva <
>>> eduardo.santanadasilva at gmail.com> wrote:
>>>
>>> I'm looking at this issue:
>>> https://issues.jboss.org/browse/WFLY-4169
>>>
>>> In the ejb-3_2 specification :
>>> It is illegal to associate JTA transactional interceptors (see [8]) with
>>> Enterprise JavaBeans. The EJB Container should fail deployment of such
>>> applications.[39]
>>>
>>> @Transaction annotation was introduced in JTA 1.2,
>>>
>>> As Narayana 5.0.0.M3 is now JTA 1.2 compliant, and it was introduced on
>>> Wildfly since version WildFly 8.0.0.Beta1, what should be done?
>>>
>>> Because this restriction could be removed in the future versions:
>>>
>>> [39] This restriction may be removed in a future release of this
>>> specification
>>>
>>> If this is needed, how to proceed? Should be done on Weld subsystem,
>>> something similar with the annotations markers, just to log the problem or
>>> it will be more tricky, since the deployment should be rolled back (by the
>>> specification)?
>>> --
>>> __________________________
>>> Eduardo Sant'Ana da Silva
>>>
>>>  _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>>
>>
>> --
>> __________________________
>> Eduardo Sant'Ana da Silva - Dr.
>> Pesquisador / Consultor de TI
>>
>>  _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>


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

From eduardo.santanadasilva at gmail.com  Mon Mar 30 08:05:32 2015
From: eduardo.santanadasilva at gmail.com (=?UTF-8?Q?Eduardo_Sant=C2=B4Ana_da_Silva?=)
Date: Mon, 30 Mar 2015 09:05:32 -0300
Subject: [wildfly-dev] WFLY-4169 Wildfly doesn't fail on deployment EJB
 with CDI @Transactional
In-Reply-To: <CAFVp3Z6vvcG5WMexECBNq-xBz+jQQxpgzSzkEaisR64yf1SjLQ@mail.gmail.com>
References: <CAFVp3Z5wMFSfJsbgusjzEu=pE15TOGWP2DUoi42zCPOb2u5cvw@mail.gmail.com>
	<C8DA6F08-5450-4849-8ED7-714ACCE7B342@redhat.com>
	<CAFVp3Z7WBPFtHa1sfjrPA0_X51n3D9dSVH4Bv1T_KW773rWOog@mail.gmail.com>
	<CAAoo=c6Zhi4ZeXfMvXe4hH_gfQ8AMFccStaZm7HLJzCEn_v4hg@mail.gmail.com>
	<CAFVp3Z6vvcG5WMexECBNq-xBz+jQQxpgzSzkEaisR64yf1SjLQ@mail.gmail.com>
Message-ID: <CAFVp3Z6c2ZquVapx=v28ec8YYNrL7w8Hre7a7fRiXZyhVcs93Q@mail.gmail.com>

What exception should I throw to prevent the deployment? I'm using the
DeploymentUnitProcessingException that seems to allow the deployment to
continue.


08:56:08,487 INFO  [org.jboss.as.server.deployment] (MSC service thread
1-3) WFLYSRV0027: Starting deployment of "WFLY-4169.jar" (runtime-name:
"WFLY-4169.jar")

08:56:08,622 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3)
MSC000001: Failed to start service
jboss.deployment.unit."WFLY-4169.jar".PARSE:
org.jboss.msc.service.StartException in service
jboss.deployment.unit."WFLY-4169.jar".PARSE: WFLYSRV0153: Failed to process
phase PARSE of deployment "WFLY-4169.jar"

at
org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163)

at
org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)

at
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)

at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

at java.lang.Thread.run(Thread.java:745)

Caused by:
org.jboss.as.server.deployment.DeploymentUnitProcessingException:
WFLYEJB0468: Illegal Enterprise JavaBean annotation:
javax.transaction.Transactional

at
org.jboss.as.ejb3.deployment.processors.ProhibitedEJBAnnotationsDeploymentUnitProcessor.deploy(ProhibitedEJBAnnotationsDeploymentUnitProcessor.java:52)

at
org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156)

... 5 more


08:56:08,654 ERROR [org.jboss.as.controller.management-operation]
(DeploymentScanner-threads - 2) WFLYCTL0013: Operation ("deploy") failed -
address: ([("deployment" => "WFLY-4169.jar")]) - failure description:
{"WFLYCTL0080: Failed services" =>
{"jboss.deployment.unit.\"WFLY-4169.jar\".PARSE" =>
"org.jboss.msc.service.StartException in service
jboss.deployment.unit.\"WFLY-4169.jar\".PARSE: WFLYSRV0153: Failed to
process phase PARSE of deployment \"WFLY-4169.jar\"

    Caused by:
org.jboss.as.server.deployment.DeploymentUnitProcessingException:
WFLYEJB0468: Illegal Enterprise JavaBean annotation:
javax.transaction.Transactional"}}

08:56:08,763 INFO  [org.jboss.as.server] (DeploymentScanner-threads - 2)
WFLYSRV0010: Deployed "WFLY-4169.jar" (runtime-name : "WFLY-4169.jar")

08:56:08,764 INFO  [org.jboss.as.controller] (DeploymentScanner-threads -
2) WFLYCTL0183: Service status report

WFLYCTL0186:   Services which failed to start:      service
jboss.deployment.unit."WFLY-4169.jar".PARSE:
org.jboss.msc.service.StartException in service
jboss.deployment.unit."WFLY-4169.jar".PARSE: WFLYSRV0153: Failed to process
phase PARSE of deployment "WFLY-4169.jar"



2015-03-30 8:01 GMT-03:00 Eduardo Sant?Ana da Silva <
eduardo.santanadasilva at gmail.com>:

> Ok.
>
> 2015-03-29 19:16 GMT-03:00 Stuart Douglas <stuart.w.douglas at gmail.com>:
>
>
>>
>> On Sun, 29 Mar 2015 at 21:34 Eduardo Sant?Ana da Silva <
>> eduardo.santanadasilva at gmail.com> wrote:
>>
>>> Ok,
>>>
>>> My approach will be create the following classes:
>>>
>>> * ProhibitedEJBAnnotationsAnnotationMarker - Mark the deployment if it
>>> has EJB annotations that are not allowed (Similar to CDI Annotation marker
>>> no Weld)
>>>
>>
>> I don't really see why you would need to mark the deployment if it has
>> invalid annotations, you should be able to just fail immediately.
>>
>> I think all you need is a single DUP that looks at every EJB component
>> description for this annotation, and if it is present throw an exception.
>>
>> Stuart
>>
>>
>>> * ProhibitedEJBAnnotationsDeploymentUnitProcessor - Do the deployment
>>> rollback in case of the marker is present.
>>>
>>>
>>> Add the proper cleanup of the attachments no EjbCleanUpProcessor
>>>
>>> Some auxilar classes to be created:
>>>
>>> public enum ProhibitedEJBAnnotations {
>>>
>>>     /**
>>>      * javax.transaction.Transactional annotation.
>>>
>>>      */
>>>
>>>     TRANSACTIONAL(Constants.JAVAX_TRANSACTION, "Transactional"),
>>>
>>> ...
>>>
>>>     private static class Constants {
>>>
>>>         /**
>>>          *  package javax.transaction
>>>          */
>>>
>>>         public static final DotName JAVAX_TRANSACTION =
>>> DotName.createSimple("javax.transaction");
>>>
>>> ...
>>>
>>> //////////////////////////////////////
>>> /**
>>>  * Marker for deployments that have prohibited EJB annotations present
>>>  */
>>>
>>> public final class ProhibitedEJBAnnotationsAnnotationMarker {
>>> (Similar to CdiAnnotationMarker on Weld)
>>>
>>> ...
>>>
>>> public class ProhibitedEJBAnnotationsDeploymentUnitProcessor implements
>>>
>>> DeploymentUnitProcessor {
>>>
>>>
>>> If you guys came up with  better names it will be good.
>>>
>>> I was wondering as well if the CDIAnnotationMarker can be used directly
>>> from the Weld subsystem or it will be better isolate the subsystems?
>>>
>>> Thx
>>> __________________________
>>> Eduardo Sant'Ana da Silva
>>>
>>> 2015-03-28 15:05 GMT-03:00 Jason T. Greene <jason.greene at redhat.com>:
>>>
>>> Good question. The easiest solution is probably to change one of the EJB
>>>> dups that looks at annotations to also check for @Transactional and fail
>>>> accordingly.
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Mar 28, 2015, at 11:56 AM, Eduardo Sant?Ana da Silva <
>>>> eduardo.santanadasilva at gmail.com> wrote:
>>>>
>>>> I'm looking at this issue:
>>>> https://issues.jboss.org/browse/WFLY-4169
>>>>
>>>> In the ejb-3_2 specification :
>>>> It is illegal to associate JTA transactional interceptors (see [8])
>>>> with Enterprise JavaBeans. The EJB Container should fail deployment of such
>>>> applications.[39]
>>>>
>>>> @Transaction annotation was introduced in JTA 1.2,
>>>>
>>>> As Narayana 5.0.0.M3 is now JTA 1.2 compliant, and it was introduced on
>>>> Wildfly since version WildFly 8.0.0.Beta1, what should be done?
>>>>
>>>> Because this restriction could be removed in the future versions:
>>>>
>>>> [39] This restriction may be removed in a future release of this
>>>> specification
>>>>
>>>> If this is needed, how to proceed? Should be done on Weld subsystem,
>>>> something similar with the annotations markers, just to log the problem or
>>>> it will be more tricky, since the deployment should be rolled back (by the
>>>> specification)?
>>>> --
>>>> __________________________
>>>> Eduardo Sant'Ana da Silva
>>>>
>>>>  _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>>
>>>
>>>
>>> --
>>> __________________________
>>> Eduardo Sant'Ana da Silva - Dr.
>>> Pesquisador / Consultor de TI
>>>
>>>  _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>
>
> --
> __________________________
> Eduardo Sant'Ana da Silva - Dr.
> Pesquisador / Consultor de TI
>
>


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

From brian.stansberry at redhat.com  Mon Mar 30 09:44:34 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 30 Mar 2015 08:44:34 -0500
Subject: [wildfly-dev] WFLY-4169 Wildfly doesn't fail on deployment EJB
 with CDI @Transactional
In-Reply-To: <CAFVp3Z6c2ZquVapx=v28ec8YYNrL7w8Hre7a7fRiXZyhVcs93Q@mail.gmail.com>
References: <CAFVp3Z5wMFSfJsbgusjzEu=pE15TOGWP2DUoi42zCPOb2u5cvw@mail.gmail.com>	<C8DA6F08-5450-4849-8ED7-714ACCE7B342@redhat.com>	<CAFVp3Z7WBPFtHa1sfjrPA0_X51n3D9dSVH4Bv1T_KW773rWOog@mail.gmail.com>	<CAAoo=c6Zhi4ZeXfMvXe4hH_gfQ8AMFccStaZm7HLJzCEn_v4hg@mail.gmail.com>	<CAFVp3Z6vvcG5WMexECBNq-xBz+jQQxpgzSzkEaisR64yf1SjLQ@mail.gmail.com>
	<CAFVp3Z6c2ZquVapx=v28ec8YYNrL7w8Hre7a7fRiXZyhVcs93Q@mail.gmail.com>
Message-ID: <55195342.3080208@redhat.com>

DeploymentUnitProcessingException is fine. Whether that triggers 
rollback of the deployment or not is not the concern of the DUP.

In this case it doesn't roll back because the deployment scanner is 
configured not to roll back deployment ops on runtime failures:

<deployment-scanner path="deployments" 
relative-to="jboss.server.base.dir" scan-interval="5000" 
runtime-failure-causes-rollback="${jboss.deployment.scanner.rollback.on.failure:false}"/>

Change that last attribute to "true" or use the CLI or console to 
deploy, both of which use 'true' by default and you should see the 
deployment rolled back.

On 3/30/15 7:05 AM, Eduardo Sant?Ana da Silva wrote:
> What exception should I throw to prevent the deployment? I'm using the
> DeploymentUnitProcessingException that seems to allow the deployment to
> continue.
>
>
> 08:56:08,487 INFO  [org.jboss.as.server.deployment] (MSC service thread
> 1-3) WFLYSRV0027: Starting deployment of "WFLY-4169.jar" (runtime-name:
> "WFLY-4169.jar")
>
> 08:56:08,622 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3)
> MSC000001: Failed to start service
> jboss.deployment.unit."WFLY-4169.jar".PARSE:
> org.jboss.msc.service.StartException in service
> jboss.deployment.unit."WFLY-4169.jar".PARSE: WFLYSRV0153: Failed to
> process phase PARSE of deployment "WFLY-4169.jar"
>
> at
> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163)
>
> at
> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
>
> at
> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
>
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>
> at java.lang.Thread.run(Thread.java:745)
>
> Caused by:
> org.jboss.as.server.deployment.DeploymentUnitProcessingException:
> WFLYEJB0468: Illegal Enterprise JavaBean annotation:
> javax.transaction.Transactional
>
> at
> org.jboss.as.ejb3.deployment.processors.ProhibitedEJBAnnotationsDeploymentUnitProcessor.deploy(ProhibitedEJBAnnotationsDeploymentUnitProcessor.java:52)
>
> at
> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156)
>
> ... 5 more
>
>
> 08:56:08,654 ERROR [org.jboss.as.controller.management-operation]
> (DeploymentScanner-threads - 2) WFLYCTL0013: Operation ("deploy") failed
> - address: ([("deployment" => "WFLY-4169.jar")]) - failure description:
> {"WFLYCTL0080: Failed services" =>
> {"jboss.deployment.unit.\"WFLY-4169.jar\".PARSE" =>
> "org.jboss.msc.service.StartException in service
> jboss.deployment.unit.\"WFLY-4169.jar\".PARSE: WFLYSRV0153: Failed to
> process phase PARSE of deployment \"WFLY-4169.jar\"
>
>      Caused by:
> org.jboss.as.server.deployment.DeploymentUnitProcessingException:
> WFLYEJB0468: Illegal Enterprise JavaBean annotation:
> javax.transaction.Transactional"}}
>
> 08:56:08,763 INFO  [org.jboss.as.server] (DeploymentScanner-threads - 2)
> WFLYSRV0010: Deployed "WFLY-4169.jar" (runtime-name : "WFLY-4169.jar")
>
> 08:56:08,764 INFO  [org.jboss.as.controller] (DeploymentScanner-threads
> - 2) WFLYCTL0183: Service status report
>
> WFLYCTL0186:   Services which failed to start:      service
> jboss.deployment.unit."WFLY-4169.jar".PARSE:
> org.jboss.msc.service.StartException in service
> jboss.deployment.unit."WFLY-4169.jar".PARSE: WFLYSRV0153: Failed to
> process phase PARSE of deployment "WFLY-4169.jar"
>
>
>
> 2015-03-30 8:01 GMT-03:00 Eduardo Sant?Ana da Silva
> <eduardo.santanadasilva at gmail.com
> <mailto:eduardo.santanadasilva at gmail.com>>:
>
>     Ok.
>
>     2015-03-29 19:16 GMT-03:00 Stuart Douglas
>     <stuart.w.douglas at gmail.com <mailto:stuart.w.douglas at gmail.com>>:
>
>
>
>         On Sun, 29 Mar 2015 at 21:34 Eduardo Sant?Ana da Silva
>         <eduardo.santanadasilva at gmail.com
>         <mailto:eduardo.santanadasilva at gmail.com>> wrote:
>
>             Ok,
>
>             My approach will be create the following classes:
>
>             * ProhibitedEJBAnnotationsAnnotationMarker - Mark the
>             deployment if it has EJB annotations that are not allowed
>             (Similar to CDI Annotation marker no Weld)
>
>
>         I don't really see why you would need to mark the deployment if
>         it has invalid annotations, you should be able to just fail
>         immediately.
>
>         I think all you need is a single DUP that looks at every EJB
>         component description for this annotation, and if it is present
>         throw an exception.
>
>         Stuart
>
>             * ProhibitedEJBAnnotationsDeploymentUnitProcessor - Do the
>             deployment rollback in case of the marker is present.
>
>
>             Add the proper cleanup of the attachments no EjbCleanUpProcessor
>
>             Some auxilar classes to be created:
>
>             publicenumProhibitedEJBAnnotations{
>
>             /**
>                   * javax.transaction.Transactional annotation.
>
>                   */
>
>             TRANSACTIONAL(Constants.JAVAX_TRANSACTION, "Transactional"),
>
>             ...
>
>             private static class Constants {
>
>             /**
>                       *  package javax.transaction
>                       */
>
>             public static final DotName JAVAX_TRANSACTION =
>             DotName.createSimple("javax.transaction");
>
>             ...
>
>             //////////////////////////////////////
>             /**
>               * Marker for deployments that have prohibited EJB
>             annotations present
>               */
>
>             public final class ProhibitedEJBAnnotationsAnnotationMarker
>             {    (Similar to CdiAnnotationMarker on Weld)
>
>             ...
>
>             public class ProhibitedEJBAnnotationsDeploymentUnitProcessor
>             implements
>
>             DeploymentUnitProcessor {
>
>
>             If you guys came up with  better names it will be good.
>
>             I was wondering as well if the CDIAnnotationMarker can be
>             used directly from the Weld subsystem or it will be better
>             isolate the subsystems?
>
>             Thx
>
>             __________________________
>             Eduardo Sant'Ana da Silva
>
>             2015-03-28 15:05 GMT-03:00 Jason T. Greene
>             <jason.greene at redhat.com <mailto:jason.greene at redhat.com>>:
>
>                 Good question. The easiest solution is probably to
>                 change one of the EJB dups that looks at annotations to
>                 also check for @Transactional and fail accordingly.
>
>                 Sent from my iPhone
>
>                 On Mar 28, 2015, at 11:56 AM, Eduardo Sant?Ana da Silva
>                 <eduardo.santanadasilva at gmail.com
>                 <mailto:eduardo.santanadasilva at gmail.com>> wrote:
>
>>                 I'm looking at this issue:
>>                 https://issues.jboss.org/browse/WFLY-4169
>>
>>                 In the ejb-3_2 specification :
>>                 It is illegal to associate JTA transactional
>>                 interceptors (see [8]) with Enterprise JavaBeans. The
>>                 EJB Container should fail deployment of such
>>                 applications.[39]
>>
>>                 @Transaction annotation was introduced in JTA 1.2,
>>
>>                 As Narayana 5.0.0.M3 is now JTA 1.2 compliant, and it
>>                 was introduced on Wildfly since version WildFly
>>                 8.0.0.Beta1, what should be done?
>>
>>                 Because this restriction could be removed in the
>>                 future versions:
>>
>>                 [39] This restriction may be removed in a future
>>                 release of this specification
>>
>>                 If this is needed, how to proceed? Should be done on
>>                 Weld subsystem, something similar with the annotations
>>                 markers, just to log the problem or it will be more
>>                 tricky, since the deployment should be rolled back (by
>>                 the specification)?
>>
>>                 --
>>                 __________________________
>>                 Eduardo Sant'Ana da Silva
>>
>>                 _______________________________________________
>>                 wildfly-dev mailing list
>>                 wildfly-dev at lists.jboss.org
>>                 <mailto:wildfly-dev at lists.jboss.org>
>>                 https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
>             --
>             __________________________
>             Eduardo Sant'Ana da Silva - Dr.
>             Pesquisador / Consultor de TI
>
>             _________________________________________________
>             wildfly-dev mailing list
>             wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>             https://lists.jboss.org/__mailman/listinfo/wildfly-dev
>             <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>
>
>
>
>     --
>     __________________________
>     Eduardo Sant'Ana da Silva - Dr.
>     Pesquisador / Consultor de TI
>
>
>
>
> --
> __________________________
> Eduardo Sant'Ana da Silva - Dr.
> Pesquisador / Consultor de TI
>
>
>
> _______________________________________________
> 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 fjuma at redhat.com  Mon Mar 30 09:56:21 2015
From: fjuma at redhat.com (Farah Juma)
Date: Mon, 30 Mar 2015 09:56:21 -0400 (EDT)
Subject: [wildfly-dev] WildFly 9 Beta on OpenShift
In-Reply-To: <353524064.2507314.1427306788570.JavaMail.zimbra@redhat.com>
Message-ID: <407154460.4607044.1427723781881.JavaMail.zimbra@redhat.com>

The OpenShift WildFly cartridge has now been updated to provide support for WildFly 9 Beta in addition to the existing support for 8.2.0.Final. Since JDK 8 is now available on OpenShift Online, the WildFly cartridge has been updated to use it directly instead of installing JDK 8 during instance creation. As a result, you should now notice slightly faster instance creation times and there is more quota available for your app.

For details on how to get started with the Beta release, check out the documentation here:

https://github.com/openshift-cartridges/openshift-wildfly-cartridge/tree/wildfly-9

Enjoy!

From tomaz.cerar at gmail.com  Mon Mar 30 11:52:40 2015
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Mon, 30 Mar 2015 17:52:40 +0200
Subject: [wildfly-dev] Dropping legacy XSD schemas & its parsers
In-Reply-To: <55157271.7070907@redhat.com>
References: <CAMquZP4kGzBv+jy_f_P3nmVv=tPXwFFGwbWOzkpAa=vaPJdY0Q@mail.gmail.com>
	<55157228.2000604@redhat.com> <55157271.7070907@redhat.com>
Message-ID: <CAMquZP70-=MV2qM7vDzFRscb2s7fOp+=ZPNaRmdM7R2m4Z0YvA@mail.gmail.com>

On Fri, Mar 27, 2015 at 4:08 PM, Brian Stansberry <
brian.stansberry at redhat.com> wrote:

> I forgot to say... is this better dealt with early in 10?



Doesn't really matter, as long as we have policy/agreement in place, some
could be done for 9 and rest in 10.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150330/50036474/attachment.html 

From tomaz.cerar at gmail.com  Mon Mar 30 11:55:38 2015
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Mon, 30 Mar 2015 17:55:38 +0200
Subject: [wildfly-dev] Dropping legacy XSD schemas & its parsers
In-Reply-To: <5515393E.8000501@jboss.com>
References: <CAMquZP4kGzBv+jy_f_P3nmVv=tPXwFFGwbWOzkpAa=vaPJdY0Q@mail.gmail.com>
	<5515393E.8000501@jboss.com>
Message-ID: <CAMquZP5ZUWFitu3vA_9aVenj1++fTaLZWzFxnWdzNSRwgJ8mBA@mail.gmail.com>

On Fri, Mar 27, 2015 at 12:04 PM, Darran Lofthouse <
darran.lofthouse at jboss.com> wrote:

> If we can document a way EAP users can use EAP 6.4 and JBoss AS7 /
> WildFly users can use WildFly 9.0.0.Final in admin only mode to read in
> legacy config and write it as the latest then technically no one should
> be blocked if they happen to use a schema version now removed.
>

Yes I think documenting migration paths is a way to go. Also Windup project
can help here.


> A general issue with parsers is we have them loaded for all versions
> ever supported, could this be an opportunity to switch to some form of
> factory so that appropriate versions can be loaded on demand.
>

That is good point. We should address this as well as a proper way for
registering transformers,
given that currently only way to do it is via intentionally deprecated API.
Both of this things go to same category, registering / defining extension.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150330/9f68e354/attachment.html 

From tomaz.cerar at gmail.com  Mon Mar 30 11:58:22 2015
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Mon, 30 Mar 2015 17:58:22 +0200
Subject: [wildfly-dev] Dropping legacy XSD schemas & its parsers
In-Reply-To: <55157228.2000604@redhat.com>
References: <CAMquZP4kGzBv+jy_f_P3nmVv=tPXwFFGwbWOzkpAa=vaPJdY0Q@mail.gmail.com>
	<55157228.2000604@redhat.com>
Message-ID: <CAMquZP6COFFdunr-70RLnMe6D=Xw27V6qvCo4Ex3uHQSYXzMFQ@mail.gmail.com>

On Fri, Mar 27, 2015 at 4:07 PM, Brian Stansberry <
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.

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

From brian.stansberry at redhat.com  Mon Mar 30 12:08:05 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 30 Mar 2015 11:08:05 -0500
Subject: [wildfly-dev] Dropping legacy XSD schemas & its parsers
In-Reply-To: <CAMquZP6COFFdunr-70RLnMe6D=Xw27V6qvCo4Ex3uHQSYXzMFQ@mail.gmail.com>
References: <CAMquZP4kGzBv+jy_f_P3nmVv=tPXwFFGwbWOzkpAa=vaPJdY0Q@mail.gmail.com>	<55157228.2000604@redhat.com>
	<CAMquZP6COFFdunr-70RLnMe6D=Xw27V6qvCo4Ex3uHQSYXzMFQ@mail.gmail.com>
Message-ID: <551974E5.1080508@redhat.com>

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

From rory.odonnell at oracle.com  Tue Mar 31 04:17:55 2015
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Tue, 31 Mar 2015 09:17:55 +0100
Subject: [wildfly-dev] Early Access builds for JDK 9 b55 and JDK 8u60 b08
 are available on java.net
Message-ID: <551A5833.9000508@oracle.com>


Hi Jason/Tomaz,

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

Early Access build for JDK 8u60 b08 <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-b08.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/20150331/bb4c1842/attachment-0001.html