From sri.kmb at gmail.com  Sun Feb  1 02:37:07 2015
From: sri.kmb at gmail.com (sri.kmb at gmail.com)
Date: Sun, 1 Feb 2015 13:07:07 +0530
Subject: [wildfly-dev] Serialization issue when using local instance
Message-ID: <CAASVsn=KZCOGF8qMJmOMAA1ZoLbjihCSApLGJ1dfwSWqHZ7s8Q@mail.gmail.com>

Hello Guys,

I've been noticing the following issues in my ear application server in
JBoss AS.

Version : JBoss AS 7.1.1-Final

1) Serialization is happening when using local view of an ejb. Is that
possible?
2) Cdi/weld injection (using @Inject) of ejb within a ear module : local or
remote proxy view? what's expected?
3) How to configure the preference (local or remote) of injection for each
deployment?

I just printed the instance of the injected bean in the log to
differentiate its nature.
1) Local instance  => "Proxy for view class:
com.xxx.yy.core.service.SampleService of EJB: SampleServiceImpl"
2) Remote instance => "Proxy for remote EJB
StatelessEJBLocator{appName='sample', moduleName='core', distinctName='',
beanName='SampleServiceImpl', view='interface
com.xxx.yy.core.service.SampleServiceRemote'}"

Is my above assumption correct?

Sample code (another issue) is in the stackoverflow :
http://stackoverflow.com/questions/28229336/injecting-ejb-bean-using-cdi

I wanted to avoid the unnecessary serialization happening within a module.
I can't disable the jboss serialization, because I've an another ear module
which communicates using the remote view (pass by value).

I also tried to debug/understand the jboss source code but i couldn't,
because there are lot of missing parts. Since It has many modules hosted in
different places, not easy to setup and debug for new developer. Is there a
guide or wiki which talks about how the jboss/wildfly works *internally*.
It would be helpful if someone shares that links (other than
HackingOnWildfly/HackingAS7usingEclipse wiki's).



Thanks

--
~Sriram~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150201/48ede78b/attachment.html 

From hrupp at redhat.com  Mon Feb  2 05:01:21 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 2 Feb 2015 11:01:21 +0100
Subject: [wildfly-dev] WildFly SelfMonitor submodule
In-Reply-To: <1056675231.4456692.1422713779877.JavaMail.zimbra@redhat.com>
References: <54CCCBBF.7090806@redhat.com>
	<1056675231.4456692.1422713779877.JavaMail.zimbra@redhat.com>
Message-ID: <661C4590-9522-414F-9C6E-13636FC03CB5@redhat.com>


> Am 31.01.2015 um 15:16 schrieb John Mazzitelli <mazz at redhat.com>:
> 
> I believe one of the goals of Heiko's wildfly-monitor subsystem was that it would be able to be deployed in Wildfly-Core (thus being able to monitor any wildfly instance) - hence, not allowed to have a dependency on Wildfly's database/datasource (IIRC, wildfly-core doesn't have any DB available out of box)

Yes.
The other goal was to be able to talk to an (external) rhq-metrics/Hawkular/... instance and deliver the data
there.

> 
> ----- Original Message -----
>> Hi all,
>> 
>> a module for self-monitoring of WildFly was the goal of the diploma
>> thesis by Vojtech Schlemmer.
>> 
>> I know that in the meantime, Heiko created a submodule for the same purpose.
>> Still, it could be worth looking at Vojtech's result:
>> https://is.muni.cz/th/325163/fi_m/?furl=%2Fth%2F325163%2Ffi_m%2F;so=nx;lang=en
>> For docs see the text of the thesis (in English), for working configured
>> server download the Appendix.
>> It is configurable through CLI (what to monitor, interval of each
>> monitored metric, aggregation).
>> One distinctive feature is storing into a database using WildFly's
>> datasource (IIRC the other doesn't have it).
>> 
>> Copy on GitHub: https://github.com/OndraZizka/wildfly-selfmonitor
>> 
>> It's a rough prototype, so the implementation of some features is really
>> basic and, so to say, not optimal.
>> 
>> Enjoy :)
>> 
>> _______________________________________________
>> 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

-- 
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, 
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht M?nchen HRB 153243
Gesch?ftsf?hrer: Charles Cachera, Michael Cunningham, Paul Hickey, Charlie Peters



From hbraun at redhat.com  Mon Feb  2 05:16:43 2015
From: hbraun at redhat.com (Heiko Braun)
Date: Mon, 2 Feb 2015 11:16:43 +0100
Subject: [wildfly-dev] WildFly SelfMonitor submodule
In-Reply-To: <54CCCBBF.7090806@redhat.com>
References: <54CCCBBF.7090806@redhat.com>
Message-ID: <6FC1C384-8CBE-4DA5-85F2-FD4806E30EDE@redhat.com>


Congrats Vojtech,

looks like you've created a good end-to-end solution. 

I would suggest you post it to the wildfly mailing lists and circle it with the community.

Regards, Heiko


> On 31 Jan 2015, at 13:34, Ondrej Zizka <ozizka at redhat.com> wrote:
> 
> Hi all,
> 
> a module for self-monitoring of WildFly was the goal of the diploma thesis by Vojtech Schlemmer.
> 
> I know that in the meantime, Heiko created a submodule for the same purpose.
> Still, it could be worth looking at Vojtech's result:
> https://is.muni.cz/th/325163/fi_m/?furl=%2Fth%2F325163%2Ffi_m%2F;so=nx;lang=en
> For docs see the text of the thesis (in English), for working configured server download the Appendix.
> It is configurable through CLI (what to monitor, interval of each monitored metric, aggregation).
> One distinctive feature is storing into a database using WildFly's datasource (IIRC the other doesn't have it).
> 
> Copy on GitHub: https://github.com/OndraZizka/wildfly-selfmonitor
> 
> It's a rough prototype, so the implementation of some features is really basic and, so to say, not optimal.
> 
> Enjoy :)
> 



From ssilvert at redhat.com  Mon Feb  2 11:23:15 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 02 Feb 2015 11:23:15 -0500
Subject: [wildfly-dev] Need ideas.  Calling REST endpoint from a subsystem
Message-ID: <54CFA473.1020704@redhat.com>

* I need to call Keycloak's REST endpoints from a WildFly 9/10 subsystem.
* The endpoints can be local or remote
* Before I make the call, I do know if it is local or remote.

What is the best way to do this?  I'd like to do something better than 
using Apache HTTP Client.

It is also possible that we change Keycloak to expose itself in a 
different way.  I'm just looking for the best overall solution.

Any ideas?

Stan

From brian.stansberry at redhat.com  Mon Feb  2 15:29:16 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 02 Feb 2015 14:29:16 -0600
Subject: [wildfly-dev] Need ideas. Calling REST endpoint from a subsystem
In-Reply-To: <54CFA473.1020704@redhat.com>
References: <54CFA473.1020704@redhat.com>
Message-ID: <54CFDE1C.8080205@redhat.com>

This sounds like something where Keycloak would provide a Java API and 
if you know it's local you wire in a service injection to add make that 
API available.

On 2/2/15 10:23 AM, Stan Silvert wrote:
> * I need to call Keycloak's REST endpoints from a WildFly 9/10 subsystem.
> * The endpoints can be local or remote
> * Before I make the call, I do know if it is local or remote.
>
> What is the best way to do this?  I'd like to do something better than
> using Apache HTTP Client.
>
> It is also possible that we change Keycloak to expose itself in a
> different way.  I'm just looking for the best overall solution.
>
> Any ideas?
>
> Stan
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


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

From jperkins at redhat.com  Tue Feb  3 17:21:23 2015
From: jperkins at redhat.com (James R. Perkins)
Date: Tue, 03 Feb 2015 14:21:23 -0800
Subject: [wildfly-dev] Transactions in Batch (JSR 352)
Message-ID: <54D149E3.6020708@redhat.com>

In the JSR 352 batch specification there are some issues around 
transactions with JCA. These issues would mainly be seen with JDBC item 
readers/writers.

Here is kind of a thought dump from a sit down I had with the JCA team. 
If anyone has any opinions on how this should be handled let's talk it 
out. I would imagine this is a fairly important issue as generally 
speaking batch jobs will likely be legacy jobs and JDBC is probably 
heavily used.



*Batch Transactions with JCA*

*Problem:*
Batch requires that a Transaction.begin() and a Transaction.commit() for 
each open, close and chunk processed. This causes connections from JCA 
to potentially cross transactional boundaries.
     This requires that the JCA CachedConnectionManager (CCM) is enabled 
for the resource in question (Jesper)

*Transaction code should be written like:*
Connection c
Transaction.begin()
c = DataSource.getConnection()
c.close()
Transaction.commit()

*Chunk Processing process:*
Transaction.begin()
ItemReader.open()
ItemWriter.open()
Transaction.commit()

repeat until item reader returns null
     Transaction.begin()
     repeat-on-chunk
         ItemReader.readItem()
         ItemProcessor.processItem()
     ItemWriter.writeItems
     Transaction.commit()

Transaction.begin()
ItemReader.close()
ItemWriter.close()
Transaction.commit()

Where seen:

  * No errors in 8.1+
  * Upstream with the tracking set to true and exception is thrown;
    /subsystem=datasources/data-source=ExampleDS:write-attribute(name=tracking,
    value=true)
  * https://gist.github.com/jamezp/cf39f92913425c83929f
      o This shows where the connection was allocated that is crossing
        the transaction boundary, and hence killed (Jesper)


Questions:

  * Will the tracking attribute be used often?
      o The feature is meant to allow people to find where in their code
        they are making assumptions that isn't true (Jesper)
          + The corner case is just the "c.close()" call (Jesper)



*Possible Fixes:*

  * Leave batch as is. If the tracking attribute is set to true
    exceptions will be thrown
      o Remember that the underlying connection will be killed (Jesper)
  * Add a property to jBeret to use local (fake) transactions. This is
    what we currently do and I feel it's just wrong.
  * Create a deployment descriptor (or possibly a property that can be
    passed when starting the job) to allow different styles for transactions

Example JBoss Way
repeat until item reader returns null
     Transaction.begin()
     ItemReader.open()
     ItemWriter.open()
     repeat-on-chunk
         ItemReader.readItem()
         ItemProcessor.processItem()
     ItemWriter.writeItems()
     ItemReader.close()
     ItemWriter.close()
     Transaction.commit()



-- 
James R. Perkins
JBoss by Red Hat

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

From vasu.manikanta9 at gmail.com  Wed Feb  4 06:51:40 2015
From: vasu.manikanta9 at gmail.com (Manikanta Vasu)
Date: Wed, 4 Feb 2015 17:21:40 +0530
Subject: [wildfly-dev] Propagation of user credentials or user session
	between two WildFly servers
Message-ID: <CAFd-90cxu2exyDC-WQsjaQCmg7req_tywoyeV=3CS7HkWu3tKA@mail.gmail.com>

Hi,

I have two WildFly 8.1.0 instances (A and B) secured by the same custom
SecurityDomain.

Client authenticates on 'server A' and performs invocation of Stateless
Bean on that server. Then, bean on 'server A' performs remote invocation of
a Bean on 'server B'. So the invocation looks like this: Client -> server A
-> server B. All communication is done via http-remoting connection, scoped
EJB client context.

The question is how to propagate client credentials or user session to the
server B?

Is it possible to configure Wildfly server A in the way that context of the
logged user is passed from the client further to the server B? Any ideas?
Is it possible or just bad idea?

I'm not sure if some kind of SSO should be applied here. what are your
thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150204/c0ee84cb/attachment-0001.html 

From claudio at claudius.com.br  Wed Feb  4 13:36:31 2015
From: claudio at claudius.com.br (Claudio Miranda)
Date: Wed, 4 Feb 2015 16:36:31 -0200
Subject: [wildfly-dev] Propagation of user credentials or user session
 between two WildFly servers
In-Reply-To: <CAFd-90cxu2exyDC-WQsjaQCmg7req_tywoyeV=3CS7HkWu3tKA@mail.gmail.com>
References: <CAFd-90cxu2exyDC-WQsjaQCmg7req_tywoyeV=3CS7HkWu3tKA@mail.gmail.com>
Message-ID: <CALbD--pi8DsWOY8-D9twm97TdFNPtfLb-9frxVWKP+me8=8M2w@mail.gmail.com>

On Wed, Feb 4, 2015 at 9:51 AM, Manikanta Vasu
<vasu.manikanta9 at gmail.com> wrote:
>
> Is it possible to configure Wildfly server A in the way that context of the
> logged user is passed from the client further to the server B? Any ideas? Is
> it possible or just bad idea?

There is a quickstart I did for this situation.

https://github.com/jboss-developer/jboss-sandbox-quickstarts/tree/master/ejb-security-propagation




-- 
  Claudio Miranda

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

From jperkins at redhat.com  Wed Feb  4 13:42:09 2015
From: jperkins at redhat.com (James R. Perkins)
Date: Wed, 04 Feb 2015 10:42:09 -0800
Subject: [wildfly-dev] Transactions in Batch (JSR 352)
In-Reply-To: <54D149E3.6020708@redhat.com>
References: <54D149E3.6020708@redhat.com>
Message-ID: <54D26801.4080609@redhat.com>

I'm retracting my email due to my misunderstanding. It's likely most 
item readers will not need a JTA data source. Therefore if you use a 
non-JTA data source you can cache the connection for the readItem() 
method. Any XA resources need to be opened and closed within the scope 
of a single transaction. For example ItemWriter.writeItems(List<Object> 
items) the XA resource must be opened and closed within this method and 
NOT in the ItemWriter.open() and ItemWriter.close() methods.

In other words, there are no changes needed. It just needs to be noted 
one should not cache an XA data source in the open method and attempt to 
reuse it later.

On 02/03/2015 02:21 PM, James R. Perkins wrote:
> In the JSR 352 batch specification there are some issues around 
> transactions with JCA. These issues would mainly be seen with JDBC 
> item readers/writers.
>
> Here is kind of a thought dump from a sit down I had with the JCA 
> team. If anyone has any opinions on how this should be handled let's 
> talk it out. I would imagine this is a fairly important issue as 
> generally speaking batch jobs will likely be legacy jobs and JDBC is 
> probably heavily used.
>
>
>
> *Batch Transactions with JCA*
>
> *Problem:*
> Batch requires that a Transaction.begin() and a Transaction.commit() 
> for each open, close and chunk processed. This causes connections from 
> JCA to potentially cross transactional boundaries.
>     This requires that the JCA CachedConnectionManager (CCM) is 
> enabled for the resource in question (Jesper)
>
> *Transaction code should be written like:*
> Connection c
> Transaction.begin()
> c = DataSource.getConnection()
> c.close()
> Transaction.commit()
>
> *Chunk Processing process:*
> Transaction.begin()
> ItemReader.open()
> ItemWriter.open()
> Transaction.commit()
>
> repeat until item reader returns null
>     Transaction.begin()
>     repeat-on-chunk
>         ItemReader.readItem()
>         ItemProcessor.processItem()
>     ItemWriter.writeItems
>     Transaction.commit()
>
> Transaction.begin()
> ItemReader.close()
> ItemWriter.close()
> Transaction.commit()
>
> Where seen:
>
>   * No errors in 8.1+
>   * Upstream with the tracking set to true and exception is thrown;
>     /subsystem=datasources/data-source=ExampleDS:write-attribute(name=tracking,
>     value=true)
>   * https://gist.github.com/jamezp/cf39f92913425c83929f
>       o This shows where the connection was allocated that is crossing
>         the transaction boundary, and hence killed (Jesper)
>
>
> Questions:
>
>   * Will the tracking attribute be used often?
>       o The feature is meant to allow people to find where in their
>         code they are making assumptions that isn't true (Jesper)
>           + The corner case is just the "c.close()" call (Jesper)
>
>
>
> *Possible Fixes:*
>
>   * Leave batch as is. If the tracking attribute is set to true
>     exceptions will be thrown
>       o Remember that the underlying connection will be killed (Jesper)
>   * Add a property to jBeret to use local (fake) transactions. This is
>     what we currently do and I feel it's just wrong.
>   * Create a deployment descriptor (or possibly a property that can be
>     passed when starting the job) to allow different styles for
>     transactions
>
> Example JBoss Way
> repeat until item reader returns null
>     Transaction.begin()
>     ItemReader.open()
>     ItemWriter.open()
>     repeat-on-chunk
>         ItemReader.readItem()
>         ItemProcessor.processItem()
>     ItemWriter.writeItems()
>     ItemReader.close()
>     ItemWriter.close()
>     Transaction.commit()
>
>
>
> -- 
> James R. Perkins
> JBoss by Red Hat

-- 
James R. Perkins
JBoss by Red Hat

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

From jason.greene at redhat.com  Wed Feb  4 13:46:19 2015
From: jason.greene at redhat.com (Jason Greene)
Date: Wed, 4 Feb 2015 12:46:19 -0600
Subject: [wildfly-dev] Propagation of user credentials or user session
	between two WildFly servers
In-Reply-To: <CALbD--pi8DsWOY8-D9twm97TdFNPtfLb-9frxVWKP+me8=8M2w@mail.gmail.com>
References: <CAFd-90cxu2exyDC-WQsjaQCmg7req_tywoyeV=3CS7HkWu3tKA@mail.gmail.com>
	<CALbD--pi8DsWOY8-D9twm97TdFNPtfLb-9frxVWKP+me8=8M2w@mail.gmail.com>
Message-ID: <B453FA92-66D3-4805-B665-C157868218F1@redhat.com>

BTW just as a general note we are actively working on some significant security improvements with the ?Elytron? project, including transparent auth propagation regardless of authentication mode.

> On Feb 4, 2015, at 12:36 PM, Claudio Miranda <claudio at claudius.com.br> wrote:
> 
> On Wed, Feb 4, 2015 at 9:51 AM, Manikanta Vasu
> <vasu.manikanta9 at gmail.com> wrote:
>> 
>> Is it possible to configure Wildfly server A in the way that context of the
>> logged user is passed from the client further to the server B? Any ideas? Is
>> it possible or just bad idea?
> 
> There is a quickstart I did for this situation.
> 
> https://github.com/jboss-developer/jboss-sandbox-quickstarts/tree/master/ejb-security-propagation
> 
> 
> 
> 
> -- 
>  Claudio Miranda
> 
> claudio at claudius.com.br
> http://www.claudius.com.br
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

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



From jesper.pedersen at redhat.com  Wed Feb  4 13:51:59 2015
From: jesper.pedersen at redhat.com (Jesper Pedersen)
Date: Wed, 04 Feb 2015 13:51:59 -0500
Subject: [wildfly-dev] Transactions in Batch (JSR 352)
In-Reply-To: <54D26801.4080609@redhat.com>
References: <54D149E3.6020708@redhat.com> <54D26801.4080609@redhat.com>
Message-ID: <54D26A4F.8050609@redhat.com>

On 02/04/2015 01:42 PM, James R. Perkins wrote:
> I'm retracting my email due to my misunderstanding. It's likely most
> item readers will not need a JTA data source. Therefore if you use a
> non-JTA data source you can cache the connection for the readItem()
> method. Any XA resources need to be opened and closed within the scope
> of a single transaction. For example ItemWriter.writeItems(List<Object>
> items) the XA resource must be opened and closed within this method and
> NOT in the ItemWriter.open() and ItemWriter.close() methods.
>
> In other words, there are no changes needed. It just needs to be noted
> one should not cache an XA data source in the open method and attempt to
> reuse it later.
>

Just remember that any non-transactional resources (NoTransaction) needs 
an explicit .close() in order to be returned to the connection pool. 
Otherwise you will out of connections fast ;) Scenarios like this can be 
investigated using the IronJacamar leak detector pool,

 
http://www.ironjacamar.org/doc/userguide/1.2/en-US/html/ch04.html#configuration_ironjacamar_leakpool

since there is no transactional boundary to do the check on.

Batch is still a bit up in the air IMHO, and the container is counting 
on the user to do the right thing. Which we all know doesn't always 
happen. So, I think it is a good idea to explore different transactional 
models looking at existing batch frameworks.

Best regards,
  Jesper


From jperkins at redhat.com  Wed Feb  4 13:55:57 2015
From: jperkins at redhat.com (James R. Perkins)
Date: Wed, 04 Feb 2015 10:55:57 -0800
Subject: [wildfly-dev] Transactions in Batch (JSR 352)
In-Reply-To: <54D26A4F.8050609@redhat.com>
References: <54D149E3.6020708@redhat.com> <54D26801.4080609@redhat.com>
	<54D26A4F.8050609@redhat.com>
Message-ID: <54D26B3D.8040301@redhat.com>


On 02/04/2015 10:51 AM, Jesper Pedersen wrote:
> On 02/04/2015 01:42 PM, James R. Perkins wrote:
>> I'm retracting my email due to my misunderstanding. It's likely most
>> item readers will not need a JTA data source. Therefore if you use a
>> non-JTA data source you can cache the connection for the readItem()
>> method. Any XA resources need to be opened and closed within the scope
>> of a single transaction. For example ItemWriter.writeItems(List<Object>
>> items) the XA resource must be opened and closed within this method and
>> NOT in the ItemWriter.open() and ItemWriter.close() methods.
>>
>> In other words, there are no changes needed. It just needs to be noted
>> one should not cache an XA data source in the open method and attempt to
>> reuse it later.
>>
>
> Just remember that any non-transactional resources (NoTransaction) 
> needs an explicit .close() in order to be returned to the connection 
> pool. Otherwise you will out of connections fast ;) Scenarios like 
> this can be investigated using the IronJacamar leak detector pool,
Right and this *should* happen in the Item(Reader|Writer).close() 
correct? Of course the user needs to ensure that happens, but it's 
"safe" assuming they do right?
>
>
> http://www.ironjacamar.org/doc/userguide/1.2/en-US/html/ch04.html#configuration_ironjacamar_leakpool 
>
>
> since there is no transactional boundary to do the check on.
>
> Batch is still a bit up in the air IMHO, and the container is counting 
> on the user to do the right thing. Which we all know doesn't always 
> happen. So, I think it is a good idea to explore different 
> transactional models looking at existing batch frameworks.
I'm not necessarily opposed to this, I'm just as concerned as I was :). 
It might make sense to have another option for users that do need XA 
resources and don't want to open/close them in each readItem().
>
> Best regards,
>  Jesper
>

-- 
James R. Perkins
JBoss by Red Hat


From jesper.pedersen at redhat.com  Wed Feb  4 14:01:29 2015
From: jesper.pedersen at redhat.com (Jesper Pedersen)
Date: Wed, 04 Feb 2015 14:01:29 -0500
Subject: [wildfly-dev] Transactions in Batch (JSR 352)
In-Reply-To: <54D26B3D.8040301@redhat.com>
References: <54D149E3.6020708@redhat.com> <54D26801.4080609@redhat.com>
	<54D26A4F.8050609@redhat.com> <54D26B3D.8040301@redhat.com>
Message-ID: <54D26C89.5060006@redhat.com>

On 02/04/2015 01:55 PM, James R. Perkins wrote:
>> Just remember that any non-transactional resources (NoTransaction)
>> needs an explicit .close() in order to be returned to the connection
>> pool. Otherwise you will out of connections fast ;) Scenarios like
>> this can be investigated using the IronJacamar leak detector pool,
 >
> Right and this *should* happen in the Item(Reader|Writer).close()
> correct? Of course the user needs to ensure that happens, but it's
> "safe" assuming they do right?
>

Yeah, because there are no bugs in applications.

... Of course that doesn't explain why <ccm debug=true> and the leak 
detector pool are needed ... must be something else ...

try/catch/finally is a good thing.

Best regards,
  Jesper


From tadamski at redhat.com  Wed Feb  4 14:42:56 2015
From: tadamski at redhat.com (Tomasz Adamski)
Date: Wed, 4 Feb 2015 14:42:56 -0500 (EST)
Subject: [wildfly-dev] Management model attribute groups
In-Reply-To: <548754D5.9090402@redhat.com>
References: <548754D5.9090402@redhat.com>
Message-ID: <1224726860.7395621.1423078976681.JavaMail.zimbra@redhat.com>

I would like to raise once again the issue of nested attribute groups.

I started rewriting iiop subsystem so that it uses attribute groups and I think that in many cases it would be covenient and more descriptive if we are able to nest attribute groups.

There are two models related to it: subsystem xml description and management api but I believe that both of them may benefit from nested attributes.

Example:

Currently ior-settings xml tag is used to group all ior releted configuration:
<ior-settings>
    
    username_password" (...)/>
    config caller-propagation="supported" (...)/>
ior-settings>

After attribute group refactor it would currently turn to:

username_password" (...)/>
config caller-propagation="supported" (...)/>

It would be nice to be able to group them together once again. This may be achieved by adding methods to PersistentResourceXMLDescription which will make it possible to create more complex xml schema independent of attribute groups. On the other hand, what is beneficial from xml point of view may also be beneficial for management tools: if those three elements have all different groups there they will be displayed separately after sort but if we created a nested groups and do a nested sorting of them then they could be grouped together in management tools too. Moreover, all information about attribute will still be containted in its definition and subsystem creation using PersistentResourceXMLDescription will stay as simple as it is now.

Having that in mind I would suggest extending the group notion from flat to nested and create direct mapping between group parts and xml tags.

In the above example we would have:

AttributeDefinition INTEGRITY = (...).setAttributeGroup("ior-settings.as-context")(...)
AttributeDefinition AUTH_METHOD = (...).setAttributeGroup("ior-settings.sas-context")(...)
AttributeDefinition CALLER_PROPAGATION = (...).setAttributeGroup("ior-settings.transport-config")(...)

PersistentResourceXMLDescription xmlDescription = builder(IIOPResourceDefinition.INSTANCE).addAttributes(IIOPResourceDefinition.INTEGRITY,IIOPResourceDefinition.AUTH_METHOD,IIOPResourceDefinition.CALLER_PROPAGATION)(...)

This would create parser able of parsing:

xmlns="urn:jboss:domain:iiop-openjdk:1.0">
    (...)
    <ior-settings>
        
        username_password" (...)/>
        config caller-propagation="supported" (...)/>
    ior-settings>
    (...)



Problems:
How to represent the group in management api?

LIST vs STRING
:read-attribute-group(group=foo.bar) vs :read-attribute-group(group=[foo,bar])
:read-attribute-group(group=foo) vs :read-attribute-group(group=[foo])

String seem more convenient but there are some consequences of keeping a LIST (which attribute group actually is) in the form of the STRING: some parts of management client code will have to do additional work because of that
(f.e. string parsing), tab completion feature will have to hint string part by part which may be not consistent with other parts of api etc.

----- Original Message -----
From: "Brian Stansberry" <brian.stansberry at redhat.com>
To: wildfly-dev at lists.jboss.org
Sent: Tuesday, December 9, 2014 9:00:21 PM
Subject: [wildfly-dev] Management model attribute groups

Off and on we've had discussions around the idea of "attribute groups". 
We've got some use cases that are crying out for such a thing[1], so I'd 
like to propose doing something concrete but simple for these for WF 9, 
ideally in the next month.

A big part of my goal here is to ensure that whatever we do doesn't 
preclude something more advanced in any next generation management 
stuff, e.g. David's stuff.

PART I Concepts

1) What is an attribute group?

The "attribute group" concept I propose is simply a collection of 
attributes associated with the same resource type that are independently 
configurable but are statically declared to be conceptually related. The 
group has a name, and members. The name provides a brief indication of 
the nature of the relationship.

The goal is to provide information to the user to help them better 
understand the relationship between attributes. In particular, 
management tools could use this information to visually present related 
attributes together, e.g. in a tab or other grouping widget in the web 
console.

2) What isn't an attribute group?

Something relevant to writes.

3) Why would I use a child resource instead of an attribute group?

Because the attributes control a discrete piece of functionality and you 
need to be able to turn that on or off as a unit. So you add/remove the 
resource.

4) Why would I use a complex attribute with a bunch of fields instead of 
n>1 simple attributes in a group.

a) Because the attributes control a discrete piece of functionality and 
you need to be able to turn that off as a unit. So users can undefine 
the complex attribute.

b) Because it's a common use case that modifications to n>1 of the 
fields should be done atomically and you don't want to force users to 
use a CLI batch. So you let them use write-attribute and specify the 
value of all the fields.

5) Why would I use an attribute group instead of a child resource?

Because requiring users to add a child resource just to set a bunch of 
values that are really part of the config of the parent resource forces 
them to use a CLI batch to correctly configure the parent resource.

6) Why would I use an attribute group instead a complex attribute?

Because the various attributes should be independently configurable. In 
particular, wiping out the config for all of them by simply undefining 
the complex attribute isn't appropriate.

PART II Proposed Work

1) The basics

We add a piece of metadata to the read-resource-description output for 
an attribute. Name is 'attribute-group', value type is ModelType.STRING, 
value is the name of the group, with 'undefined' allowed.

The group is simply the set of attributes that share the same string.

To implement this, we add public String 
AttributeDefinition.getAttributeGroup() and add support for setting it 
to the relevant Builder. ReadResourceDescriptionHandler outputs the value.

2) XML parsing/marshalling

Modify PersistentResourceXMLDescription such that attributes in an 
attribute group get persisted in their own child element, whose name is 
the name of the group.

PersistentResourceXMLBuilder exposes a setter to allow users to turn 
this on/off for that resource. Turning it off will allow the addition of 
attribute group settings for a resource without requiring an immediate 
corresponding xsd change.

3) Web console

HAL can make use of the additional metadata at its leisure, and as it 
becomes available.

4) Low level management API

The output of read-resource and read-resource-description is modified 
such that attributes are sorted by group name and then by attribute name.

5) CLI

I'm not clear on exactly what to do here, but my instinct is the output 
of the 'ls -l' command should be modified. Probably add a GROUP column 
to the right and sort the order of attributes by group and then by 
attribute name.

PART III Other possible things to do

A :read-attribute-group(name=<groupname>) operation or an 
"attribute-groups=[<groupname>*]" param to :read-resource, to make it 
convenient to read a set of attributes without needing to read the 
entire resource.

We could also consider adding an "attribute-groups" section to the 
read-resource-description output, where a fuller i18n text description 
of the meaning of the group could be written. If we do this we should 
probably do it in WF 9 as it will likely add some sort of requirement to 
subsystem authors that we expose right from the start.


If you're still awake, comments as always are appreciated.

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

[1] For example, the JDKORB pull request at 
https://github.com/wildfly/wildfly/pull/7008 uses child resources in a 
number of places where it seems like attribute groups are a better fit.

_______________________________________________
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 Feb  4 14:50:10 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Wed, 04 Feb 2015 13:50:10 -0600
Subject: [wildfly-dev] Transactions in Batch (JSR 352)
In-Reply-To: <54D26C89.5060006@redhat.com>
References: <54D149E3.6020708@redhat.com>
	<54D26801.4080609@redhat.com>	<54D26A4F.8050609@redhat.com>
	<54D26B3D.8040301@redhat.com> <54D26C89.5060006@redhat.com>
Message-ID: <54D277F2.1000508@redhat.com>

On 02/04/2015 01:01 PM, Jesper Pedersen wrote:
> On 02/04/2015 01:55 PM, James R. Perkins wrote:
>>> Just remember that any non-transactional resources (NoTransaction)
>>> needs an explicit .close() in order to be returned to the connection
>>> pool. Otherwise you will out of connections fast ;) Scenarios like
>>> this can be investigated using the IronJacamar leak detector pool,
>   >
>> Right and this *should* happen in the Item(Reader|Writer).close()
>> correct? Of course the user needs to ensure that happens, but it's
>> "safe" assuming they do right?
>>
>
> Yeah, because there are no bugs in applications.
>
> ... Of course that doesn't explain why <ccm debug=true> and the leak
> detector pool are needed ... must be something else ...
>
> try/catch/finally is a good thing.

Connection objects are AutoCloseable, so you can even do:

   try (Connection c = ds.getConnection()) {
      // do stuff
   }

Simple and clean.
-- 
- DML

From tadamski at redhat.com  Wed Feb  4 14:51:26 2015
From: tadamski at redhat.com (Tomasz Adamski)
Date: Wed, 4 Feb 2015 14:51:26 -0500 (EST)
Subject: [wildfly-dev]  Management model attribute groups - example fixed
In-Reply-To: <28332813.7398303.1423079423775.JavaMail.zimbra@redhat.com>
References: <28332813.7398303.1423079423775.JavaMail.zimbra@redhat.com>
Message-ID: <1715933565.7398866.1423079486428.JavaMail.zimbra@redhat.com>

Sent once again because of broken examples in previous mail:

I would like to raise once again the issue of nested attribute groups.

I started rewriting iiop subsystem so that it uses attribute groups and I think that in many cases it would be covenient and more descriptive if we are able to nest attribute groups.

There are two models related to it: subsystem xml description and management api but I believe that both of them may benefit from nested attributes.

Example:

Currently ior-settings xml tag is used to group all ior releted configuration:
<ior-settings>
    <as-context integrity="required" (...)/>
    <sas-context auth-method="username_password" (...)/>
    <transport-config caller-propagation="supported" (...)/>
</ior-settings>

After attribute group refactor it would currently turn to:
<as-context integrity="required" (...)/>
<sas-context auth-method="username_password" (...)/>
<transport-config caller-propagation="supported" (...)/>

It would be nice to be able to group them together once again. This may be achieved by adding methods to PersistentResourceXMLDescription which will make it possible to create more complex xml schema independent of attribute groups. On the other hand, what is beneficial from xml point of view may also be beneficial for management tools: if those three elements have all different groups there they could be displayed separately after sort but if we created a nested groups and do a nested sorting of them then they could be grouped together in management tools too. Moreover, all information about attribute will still be containted in its definition and  subsystem creation using PersistentResourceXMLDescription will stay as simple as it is now.

Having that in mind I would suggest extending the group notion from flat to nested and create direct mapping between group parts and xml tags.

In the above example we would have:

AttributeDefinition INTEGRITY = (...).setAttributeGroup("ior-settings.as-context")(...)
AttributeDefinition AUTH_METHOD = (...).setAttributeGroup("ior-settings.sas-context")(...)
AttributeDefinition CALLER_PROPAGATION = (...).setAttributeGroup("ior-settings.transport-config")(...)

PersistentResourceXMLDescription xmlDescription = builder(IIOPResourceDefinition.INSTANCE).addAttributes(IIOPResourceDefinition.INTEGRITY,IIOPResourceDefinition.AUTH_METHOD,IIOPResourceDefinition.CALLER_PROPAGATION)(...)

This would create parser able of parsing:

<subsystem xmlns="urn:jboss:domain:iiop-openjdk:1.0">
    (...)
    <ior-settings>
        <as-context integrity="required" (...)/>
        <sas-context auth-method="username_password" (...)/>
        <transport-config caller-propagation="supported" (...)/>
    </ior-settings>
    (...)
</subsystem>


Problems:
How to represent the group in management api?

LIST vs STRING
:read-attribute-group(group=foo.bar) vs :read-attribute-group(group=[foo,bar])
:read-attribute-group(group=foo) vs :read-attribute-group(group=[foo])

String seem more convenient but there are some consequences of keeping a LIST (which attribute group actually is) in the form of the STRING: some parts of management client code will have to do additional work because of that (f.e. string parsing), tab completion feature will have to hint string part by part which may be not consistent with other parts of api etc.











From jesper.pedersen at redhat.com  Wed Feb  4 14:53:35 2015
From: jesper.pedersen at redhat.com (Jesper Pedersen)
Date: Wed, 04 Feb 2015 14:53:35 -0500
Subject: [wildfly-dev] Transactions in Batch (JSR 352)
In-Reply-To: <54D277F2.1000508@redhat.com>
References: <54D149E3.6020708@redhat.com>	<54D26801.4080609@redhat.com>	<54D26A4F.8050609@redhat.com>	<54D26B3D.8040301@redhat.com>
	<54D26C89.5060006@redhat.com> <54D277F2.1000508@redhat.com>
Message-ID: <54D278BF.70800@redhat.com>

On 02/04/2015 02:50 PM, David M. Lloyd wrote:
>> try/catch/finally is a good thing.
>
> Connection objects are AutoCloseable, so you can even do:
>
>     try (Connection c = ds.getConnection()) {
>        // do stuff
>     }
>
> Simple and clean.

Hopefully it will make it into the JCA spec some day :) We are still 
using bow and arrow in many cases.


From brian.stansberry at redhat.com  Wed Feb  4 20:16:10 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 04 Feb 2015 19:16:10 -0600
Subject: [wildfly-dev] Management model attribute groups - example fixed
In-Reply-To: <1715933565.7398866.1423079486428.JavaMail.zimbra@redhat.com>
References: <28332813.7398303.1423079423775.JavaMail.zimbra@redhat.com>
	<1715933565.7398866.1423079486428.JavaMail.zimbra@redhat.com>
Message-ID: <54D2C45A.7010303@redhat.com>

On 2/4/15 1:51 PM, Tomasz Adamski wrote:
> Sent once again because of broken examples in previous mail:
>
> I would like to raise once again the issue of nested attribute groups.
>
> I started rewriting iiop subsystem so that it uses attribute groups and I think that in many cases it would be covenient and more descriptive if we are able to nest attribute groups.
>
> There are two models related to it: subsystem xml description and management api but I believe that both of them may benefit from nested attributes.
>
> Example:
>
> Currently ior-settings xml tag is used to group all ior releted configuration:
> <ior-settings>
>      <as-context integrity="required" (...)/>
>      <sas-context auth-method="username_password" (...)/>
>      <transport-config caller-propagation="supported" (...)/>
> </ior-settings>
>
> After attribute group refactor it would currently turn to:
> <as-context integrity="required" (...)/>
> <sas-context auth-method="username_password" (...)/>
> <transport-config caller-propagation="supported" (...)/>
>
> It would be nice to be able to group them together once again. This may be achieved by adding methods to PersistentResourceXMLDescription which will make it possible to create more complex xml schema independent of attribute groups. On the other hand, what is beneficial from xml point of view may also be beneficial for management tools: if those three elements have all different groups there they could be displayed separately after sort but if we created a nested groups and do a nested sorting of them then they could be grouped together in management tools too. Moreover, all information about attribute will still be containted in its definition and  subsystem creation using PersistentResourceXMLDescription will stay as simple as it is now.
>
> Having that in mind I would suggest extending the group notion from flat to nested and create direct mapping between group parts and xml tags.
>
> In the above example we would have:
>
> AttributeDefinition INTEGRITY = (...).setAttributeGroup("ior-settings.as-context")(...)
> AttributeDefinition AUTH_METHOD = (...).setAttributeGroup("ior-settings.sas-context")(...)
> AttributeDefinition CALLER_PROPAGATION = (...).setAttributeGroup("ior-settings.transport-config")(...)
>

I think this information would be better reflected in the attribute 
description metadata as a list of string instead of a string with dot 
syntax. If dot syntax is used in the metadata, a management client needs 
to understand how to parse that information, versus having it be more 
obvious.

The AttributeDefinition builder syntax can still be easy by using 
setAttributeGroup(String... group)

> PersistentResourceXMLDescription xmlDescription = builder(IIOPResourceDefinition.INSTANCE).addAttributes(IIOPResourceDefinition.INTEGRITY,IIOPResourceDefinition.AUTH_METHOD,IIOPResourceDefinition.CALLER_PROPAGATION)(...)
>
> This would create parser able of parsing:
>
> <subsystem xmlns="urn:jboss:domain:iiop-openjdk:1.0">
>      (...)
>      <ior-settings>
>          <as-context integrity="required" (...)/>
>          <sas-context auth-method="username_password" (...)/>
>          <transport-config caller-propagation="supported" (...)/>
>      </ior-settings>
>      (...)
> </subsystem>
>
>
> Problems:
> How to represent the group in management api?
>
> LIST vs STRING
> :read-attribute-group(group=foo.bar) vs :read-attribute-group(group=[foo,bar])
> :read-attribute-group(group=foo) vs :read-attribute-group(group=[foo])
>
> String seem more convenient but there are some consequences of keeping a LIST (which attribute group actually is) in the form of the STRING: some parts of management client code will have to do additional work because of that (f.e. string parsing), tab completion feature will have to hint string part by part which may be not consistent with other parts of api etc.
>

The attribute description metadata can be in the form of a LIST without 
requiring that the parameter to read-attribute-group be a LIST. It's an 
inconsistency if they are not, which isn't ideal. But for the simple 
case, having to do group=[foo] would be bad.

>
>
>
>
>
>
>
>
>
> _______________________________________________
> 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 rstryker at redhat.com  Thu Feb  5 02:05:04 2015
From: rstryker at redhat.com (Rob Stryker)
Date: Thu, 05 Feb 2015 15:05:04 +0800
Subject: [wildfly-dev] Making JMX connections to wildfly over ip6
Message-ID: <54D31620.9030706@redhat.com>

Hey all:

JBoss Tools' code to connect to wildfly over JMX seems to work fine 
except when using ip6. Code is simple:


         JMXConnector connector = null;
         try {
             connector = JMXConnectorFactory.connect(new 
JMXServiceURL(url), environment);
             MBeanServerConnection connection = 
connector.getMBeanServerConnection();
             synchronized(this) {
                 this.connectionToConnector.put(connection, connector);
             }
             return connection;
         } catch(IOException ioe) {


The environment is an empty HashMap<String,String>.

The url is: service:jmx:http-remoting-jmx://fe80::5e51:4fff:fee6:e7ea:9990
I've also tried an alternate url such as 
service:jmx:http-remoting-jmx://[fe80::5e51:4fff:fee6:e7ea]:9990


The server was started with the following program args:

-mp 
"/home/rob/apps/jboss/unzipped/wildfly-8.2.0.CR1-SNAPSHOT.zip.expanded/modules" 
-jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -b 
fe80::5e51:4fff:fee6:e7ea --server-config=standalone.xml 
-Djboss.server.base.dir=/home/rob/apps/jboss/unzipped/wildfly-8.2.0.CR1-SNAPSHOT.zip.expanded/standalone 


And the following vm args:

"-Dprogram.name=JBossTools: WildFly 8.x (1)" -server -Xms64m -Xmx512m 
-XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true 
-Djava.net.preferIPv4Stack=false -Dsun.rmi.dgc.client.gcInterval=3600000 
-Dsun.rmi.dgc.server.gcInterval=3600000 
-Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true 
"-Dorg.jboss.boot.log.file=/home/rob/apps/jboss/unzipped/wildfly-8.2.0.CR1-SNAPSHOT.zip.expanded/standalone/log/boot.log" 
"-Dlogging.configuration=file:/home/rob/apps/jboss/unzipped/wildfly-8.2.0.CR1-SNAPSHOT.zip.expanded/standalone/configuration/logging.properties" 
"-Djboss.home.dir=/home/rob/apps/jboss/unzipped/wildfly-8.2.0.CR1-SNAPSHOT.zip.expanded" 
-Dorg.jboss.logmanager.nocolor=true 
-Djboss.bind.address.management=fe80::5e51:4fff:fee6:e7ea


Thanks in advance.

- Rob Stryker

From darran.lofthouse at jboss.com  Thu Feb  5 03:45:26 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Thu, 05 Feb 2015 08:45:26 +0000
Subject: [wildfly-dev] Making JMX connections to wildfly over ip6
In-Reply-To: <54D31620.9030706@redhat.com>
References: <54D31620.9030706@redhat.com>
Message-ID: <54D32DA6.7000606@jboss.com>

If you have tried both forms and it is not working I would suggest raise 
a bug, there should already be testing that picks this up for IPv6 but 
TBH there shouldn't be anything you need to do in addition to the 
options you have tried here.

On 05/02/15 07:05, Rob Stryker wrote:
> Hey all:
>
> JBoss Tools' code to connect to wildfly over JMX seems to work fine
> except when using ip6. Code is simple:
>
>
>           JMXConnector connector = null;
>           try {
>               connector = JMXConnectorFactory.connect(new
> JMXServiceURL(url), environment);
>               MBeanServerConnection connection =
> connector.getMBeanServerConnection();
>               synchronized(this) {
>                   this.connectionToConnector.put(connection, connector);
>               }
>               return connection;
>           } catch(IOException ioe) {
>
>
> The environment is an empty HashMap<String,String>.
>
> The url is: service:jmx:http-remoting-jmx://fe80::5e51:4fff:fee6:e7ea:9990
> I've also tried an alternate url such as
> service:jmx:http-remoting-jmx://[fe80::5e51:4fff:fee6:e7ea]:9990
>
>
> The server was started with the following program args:
>
> -mp
> "/home/rob/apps/jboss/unzipped/wildfly-8.2.0.CR1-SNAPSHOT.zip.expanded/modules"
> -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -b
> fe80::5e51:4fff:fee6:e7ea --server-config=standalone.xml
> -Djboss.server.base.dir=/home/rob/apps/jboss/unzipped/wildfly-8.2.0.CR1-SNAPSHOT.zip.expanded/standalone
>
>
> And the following vm args:
>
> "-Dprogram.name=JBossTools: WildFly 8.x (1)" -server -Xms64m -Xmx512m
> -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true
> -Djava.net.preferIPv4Stack=false -Dsun.rmi.dgc.client.gcInterval=3600000
> -Dsun.rmi.dgc.server.gcInterval=3600000
> -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> "-Dorg.jboss.boot.log.file=/home/rob/apps/jboss/unzipped/wildfly-8.2.0.CR1-SNAPSHOT.zip.expanded/standalone/log/boot.log"
> "-Dlogging.configuration=file:/home/rob/apps/jboss/unzipped/wildfly-8.2.0.CR1-SNAPSHOT.zip.expanded/standalone/configuration/logging.properties"
> "-Djboss.home.dir=/home/rob/apps/jboss/unzipped/wildfly-8.2.0.CR1-SNAPSHOT.zip.expanded"
> -Dorg.jboss.logmanager.nocolor=true
> -Djboss.bind.address.management=fe80::5e51:4fff:fee6:e7ea
>
>
> Thanks in advance.
>
> - Rob Stryker
> _______________________________________________
> 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 Feb  5 04:00:21 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Thu, 05 Feb 2015 09:00:21 +0000
Subject: [wildfly-dev] Administrator Encouragement
Message-ID: <54D33125.3050109@jboss.com>

Last week a few of us started talking about the possibility of adding a 
capability to WildFly that for want of a better name I was calling 
"Administrator Encouragement".

I am not looking for this to be a design thread, that can come later but 
the general principal was that subsystems could register warnings with 
some kind of central service that admin tools could then retrieve later 
to advise administrators that some configuration could be required to 
improve their installation.  Warnings would potentially have a severity 
level and tooling would potentially have the option to guide the user to 
the correct place to resolve the issue.

Anyway the purpose of this thread is that I wanted to try and gather 
together the kinds of warnings that we could be outputting, below is a 
list of some I have thought of already but would be interested in 
hearing any additional ideas.

  - SSL is not configured.
  - SSL certificates are due to expire.
  - Plain text password detected in the configuration.
  - Some form of file based storage in use but growing beyond intended size.
  - Default node name  has not been changed.
  - Patches available but not applied, subsequent releases available.

Anyway these are just a few ideas and interested in hearing any more.

Regards,
Darran Lofthouse.

From lgao at redhat.com  Thu Feb  5 04:12:07 2015
From: lgao at redhat.com (Lin Gao)
Date: Thu, 5 Feb 2015 04:12:07 -0500 (EST)
Subject: [wildfly-dev] Administrator Encouragement
In-Reply-To: <54D33125.3050109@jboss.com>
References: <54D33125.3050109@jboss.com>
Message-ID: <641991963.7040359.1423127527367.JavaMail.zimbra@redhat.com>


like: The war application is using a jar already shipped in the application server, and in some cases the versions of the jars are different.

 :-)

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

----- Original Message -----
> From: "Darran Lofthouse" <darran.lofthouse at jboss.com>
> To: wildfly-dev at lists.jboss.org
> Sent: Thursday, February 5, 2015 5:00:21 PM
> Subject: [wildfly-dev] Administrator Encouragement
> 
> Last week a few of us started talking about the possibility of adding a
> capability to WildFly that for want of a better name I was calling
> "Administrator Encouragement".
> 
> I am not looking for this to be a design thread, that can come later but
> the general principal was that subsystems could register warnings with
> some kind of central service that admin tools could then retrieve later
> to advise administrators that some configuration could be required to
> improve their installation.  Warnings would potentially have a severity
> level and tooling would potentially have the option to guide the user to
> the correct place to resolve the issue.
> 
> Anyway the purpose of this thread is that I wanted to try and gather
> together the kinds of warnings that we could be outputting, below is a
> list of some I have thought of already but would be interested in
> hearing any additional ideas.
> 
>   - SSL is not configured.
>   - SSL certificates are due to expire.
>   - Plain text password detected in the configuration.
>   - Some form of file based storage in use but growing beyond intended size.
>   - Default node name  has not been changed.
>   - Patches available but not applied, subsequent releases available.
> 
> Anyway these are just a few ideas and interested in hearing any more.
> 
> Regards,
> Darran Lofthouse.
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 

From Hielke.Hoeve at topicus.nl  Thu Feb  5 04:58:38 2015
From: Hielke.Hoeve at topicus.nl (Hielke Hoeve)
Date: Thu, 5 Feb 2015 09:58:38 +0000
Subject: [wildfly-dev] Administrator Encouragement
In-Reply-To: <54D33125.3050109@jboss.com>
References: <54D33125.3050109@jboss.com>
Message-ID: <C26AF537-0024-4513-ADEA-D9F97DE4AA6A@topicus.nl>

An awesome idea! Here are some potential other triggers we currently have configured using 3rd party systems. 

- Thread/Connection pools usage (draining?)
- Head/Non Heap usage (maxed out?)
- CPU usage
- Request times


Regards

Hielke Hoeve

> On 05 Feb 2015, at 10:00, Darran Lofthouse <darran.lofthouse at jboss.com> wrote:
> 
> Last week a few of us started talking about the possibility of adding a 
> capability to WildFly that for want of a better name I was calling 
> "Administrator Encouragement".
> 
> I am not looking for this to be a design thread, that can come later but 
> the general principal was that subsystems could register warnings with 
> some kind of central service that admin tools could then retrieve later 
> to advise administrators that some configuration could be required to 
> improve their installation.  Warnings would potentially have a severity 
> level and tooling would potentially have the option to guide the user to 
> the correct place to resolve the issue.
> 
> Anyway the purpose of this thread is that I wanted to try and gather 
> together the kinds of warnings that we could be outputting, below is a 
> list of some I have thought of already but would be interested in 
> hearing any additional ideas.
> 
>  - SSL is not configured.
>  - SSL certificates are due to expire.
>  - Plain text password detected in the configuration.
>  - Some form of file based storage in use but growing beyond intended size.
>  - Default node name  has not been changed.
>  - Patches available but not applied, subsequent releases available.
> 
> Anyway these are just a few ideas and interested in hearing any more.
> 
> Regards,
> Darran Lofthouse.
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



From brian.stansberry at redhat.com  Thu Feb  5 11:39:54 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 05 Feb 2015 10:39:54 -0600
Subject: [wildfly-dev] "Boot time" system props in the managed server's model
Message-ID: <54D39CDA.502@redhat.com>

tl;dr

We have a minor anomaly in system property processing in domain mode 
that we intend to ignore.

long version

While digging into a bug Emmanuel Hugonnet noticed an anomaly. When you 
define a system-property resource in domain.xml or host.xml with 
"boot-time=true", the HC does both of the following when it launches a 
server:

1) Uses -D to set the prop when it starts the server process.

2) Adds an add system-property op to the server's set of boot ops, which 
causes the system property to get set again later during boot.

Really, only 1) should happen; that's what "boot-time=true" means. The 
purpose of boot-time=true is to ensure the value is set at JVM launch, 
not waiting for management ops to execute, which may be too late for 
props that are read early.

The other thing that happens is when you add such a prop to the domain 
or host model, we immediately execute an add op on all relevant running 
servers. This somewhat ignores a possible meaning of "boot-time=true", 
which implies the prop needs to be set at boot. Since that hasn't 
happened, really the server should be put into restart-required state.

But, at this point we intend to leave the behavior as is. It's been this 
way for a long time and people may be unknowingly counting on the prop 
being directly written and the server not going into restart-required.

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

From arun.gupta at gmail.com  Thu Feb  5 12:02:11 2015
From: arun.gupta at gmail.com (Arun Gupta)
Date: Thu, 5 Feb 2015 09:02:11 -0800
Subject: [wildfly-dev] CI build is broken
Message-ID: <CAGBoHQW-td67ke7sdqq0SXg2KXPUX75bw1pT11ciMomLrmsjZw@mail.gmail.com>

CI build at https://ci.jboss.org/hudson/job/WildFly-latest-master/ is broken.

Is somebody looking at it?

Arun

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

From kabir.khan at jboss.com  Thu Feb  5 12:13:57 2015
From: kabir.khan at jboss.com (Kabir Khan)
Date: Thu, 5 Feb 2015 17:13:57 +0000
Subject: [wildfly-dev] "Boot time" system props in the managed server's
	model
In-Reply-To: <54D39CDA.502@redhat.com>
References: <54D39CDA.502@redhat.com>
Message-ID: <ECC4DE0C-20D8-4EFE-BA28-997DB19380F5@jboss.com>


> On 5 Feb 2015, at 16:39, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> 
> tl;dr
> 
> We have a minor anomaly in system property processing in domain mode 
> that we intend to ignore.
> 
> long version
> 
> While digging into a bug Emmanuel Hugonnet noticed an anomaly. When you 
> define a system-property resource in domain.xml or host.xml with 
> "boot-time=true", the HC does both of the following when it launches a 
> server:
> 
> 1) Uses -D to set the prop when it starts the server process.
> 
> 2) Adds an add system-property op to the server's set of boot ops, which 
> causes the system property to get set again later during boot.
> 
> Really, only 1) should happen; that's what "boot-time=true" means. The 
> purpose of boot-time=true is to ensure the value is set at JVM launch, 
> not waiting for management ops to execute, which may be too late for 
> props that are read early.
I am not 100% convinced. 1) should of course happen. But it could be argued that something in the domain management model should always be reflected in the resulting server management model. It feels a bit weird to make random exceptions.
> 
> The other thing that happens is when you add such a prop to the domain 
> or host model, we immediately execute an add op on all relevant running 
> servers. This somewhat ignores a possible meaning of "boot-time=true", 
> which implies the prop needs to be set at boot. Since that hasn't 
> happened, really the server should be put into restart-required state.
> 
> But, at this point we intend to leave the behavior as is. It's been this 
> way for a long time and people may be unknowingly counting on the prop 
> being directly written and the server not going into restart-required.
+1
> 
> -- 
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



From tomaz.cerar at gmail.com  Thu Feb  5 12:18:26 2015
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Thu, 5 Feb 2015 18:18:26 +0100
Subject: [wildfly-dev] CI build is broken
In-Reply-To: <CAGBoHQW-td67ke7sdqq0SXg2KXPUX75bw1pT11ciMomLrmsjZw@mail.gmail.com>
References: <CAGBoHQW-td67ke7sdqq0SXg2KXPUX75bw1pT11ciMomLrmsjZw@mail.gmail.com>
Message-ID: <CAMquZP4XBT10AqQr=T3wh7yiHOzVPMKGLqA6K3BP1jtUO0fKOA@mail.gmail.com>

builds are properly done on internal jenkins instance.
but publish to public instance hang yet again..

"Publishing status: Waiting in queue"

can you ping eng-ops to take a look...


On Thu, Feb 5, 2015 at 6:02 PM, Arun Gupta <arun.gupta at gmail.com> wrote:

> CI build at https://ci.jboss.org/hudson/job/WildFly-latest-master/ is
> broken.
>
> Is somebody looking at it?
>
> Arun
>
> --
> http://blog.arungupta.me
> http://twitter.com/arungupta
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150205/dd60af95/attachment.html 

From arun.gupta at gmail.com  Thu Feb  5 12:19:30 2015
From: arun.gupta at gmail.com (Arun Gupta)
Date: Thu, 5 Feb 2015 09:19:30 -0800
Subject: [wildfly-dev] CI build is broken
In-Reply-To: <CAMquZP4XBT10AqQr=T3wh7yiHOzVPMKGLqA6K3BP1jtUO0fKOA@mail.gmail.com>
References: <CAGBoHQW-td67ke7sdqq0SXg2KXPUX75bw1pT11ciMomLrmsjZw@mail.gmail.com>
	<CAMquZP4XBT10AqQr=T3wh7yiHOzVPMKGLqA6K3BP1jtUO0fKOA@mail.gmail.com>
Message-ID: <CAGBoHQUMGGtAh5kz2yCD73RGtygtsRxxO1NjpUR-Z7bFAEDnog@mail.gmail.com>

Are the builds done internally and then published externally?

Why so, as opposed to build externally?

eng-ops would eng-ops at redhat.com?

On Thu, Feb 5, 2015 at 9:18 AM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
> builds are properly done on internal jenkins instance.
> but publish to public instance hang yet again..
>
> "Publishing status: Waiting in queue"
>
> can you ping eng-ops to take a look...
>
>
> On Thu, Feb 5, 2015 at 6:02 PM, Arun Gupta <arun.gupta at gmail.com> wrote:
>>
>> CI build at https://ci.jboss.org/hudson/job/WildFly-latest-master/ is
>> broken.
>>
>> Is somebody looking at it?
>>
>> Arun
>>
>> --
>> http://blog.arungupta.me
>> http://twitter.com/arungupta
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>



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


From brian.stansberry at redhat.com  Thu Feb  5 12:24:21 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 05 Feb 2015 11:24:21 -0600
Subject: [wildfly-dev] "Boot time" system props in the managed server's
 model
In-Reply-To: <ECC4DE0C-20D8-4EFE-BA28-997DB19380F5@jboss.com>
References: <54D39CDA.502@redhat.com>
	<ECC4DE0C-20D8-4EFE-BA28-997DB19380F5@jboss.com>
Message-ID: <54D3A745.6070308@redhat.com>

On 2/5/15 11:13 AM, Kabir Khan wrote:
>
>> On 5 Feb 2015, at 16:39, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>
>> tl;dr
>>
>> We have a minor anomaly in system property processing in domain mode
>> that we intend to ignore.
>>
>> long version
>>
>> While digging into a bug Emmanuel Hugonnet noticed an anomaly. When you
>> define a system-property resource in domain.xml or host.xml with
>> "boot-time=true", the HC does both of the following when it launches a
>> server:
>>
>> 1) Uses -D to set the prop when it starts the server process.
>>
>> 2) Adds an add system-property op to the server's set of boot ops, which
>> causes the system property to get set again later during boot.
>>
>> Really, only 1) should happen; that's what "boot-time=true" means. The
>> purpose of boot-time=true is to ensure the value is set at JVM launch,
>> not waiting for management ops to execute, which may be too late for
>> props that are read early.
> I am not 100% convinced.

Me neither. :)

1) should of course happen. But it could be argued that something in the 
domain management model should always be reflected in the resulting 
server management model. It feels a bit weird to make random exceptions.

It's similar to a jvm setting. It's a configuration of how the HC behaves.

>>
>> The other thing that happens is when you add such a prop to the domain
>> or host model, we immediately execute an add op on all relevant running
>> servers. This somewhat ignores a possible meaning of "boot-time=true",
>> which implies the prop needs to be set at boot. Since that hasn't
>> happened, really the server should be put into restart-required state.
>>
>> But, at this point we intend to leave the behavior as is. It's been this
>> way for a long time and people may be unknowingly counting on the prop
>> being directly written and the server not going into restart-required.
> +1
>>
>> --
>> Brian Stansberry
>> Senior Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


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

From jason.greene at redhat.com  Thu Feb  5 12:33:51 2015
From: jason.greene at redhat.com (Jason Greene)
Date: Thu, 5 Feb 2015 11:33:51 -0600
Subject: [wildfly-dev] "Boot time" system props in the managed server's
	model
In-Reply-To: <54D3A745.6070308@redhat.com>
References: <54D39CDA.502@redhat.com>
	<ECC4DE0C-20D8-4EFE-BA28-997DB19380F5@jboss.com>
	<54D3A745.6070308@redhat.com>
Message-ID: <2DC2A100-0D0F-4745-A3DF-E7F41F4B9609@redhat.com>


> On Feb 5, 2015, at 11:24 AM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> 
> On 2/5/15 11:13 AM, Kabir Khan wrote:
>> 
>>> On 5 Feb 2015, at 16:39, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>> 
>>> tl;dr
>>> 
>>> We have a minor anomaly in system property processing in domain mode
>>> that we intend to ignore.
>>> 
>>> long version
>>> 
>>> While digging into a bug Emmanuel Hugonnet noticed an anomaly. When you
>>> define a system-property resource in domain.xml or host.xml with
>>> "boot-time=true", the HC does both of the following when it launches a
>>> server:
>>> 
>>> 1) Uses -D to set the prop when it starts the server process.
>>> 
>>> 2) Adds an add system-property op to the server's set of boot ops, which
>>> causes the system property to get set again later during boot.
>>> 
>>> Really, only 1) should happen; that's what "boot-time=true" means. The
>>> purpose of boot-time=true is to ensure the value is set at JVM launch,
>>> not waiting for management ops to execute, which may be too late for
>>> props that are read early.
>> I am not 100% convinced.
> 
> Me neither. :)
> 
> 1) should of course happen. But it could be argued that something in the 
> domain management model should always be reflected in the resulting 
> server management model. It feels a bit weird to make random exceptions.
> 
> It's similar to a jvm setting. It's a configuration of how the HC behaves.

If I understand correctly, the add op generated on all servers sets a system property, which activates at runtime correct?

If so I actually think the behavior is arguably correct, if a bit odd.

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



From tomaz.cerar at gmail.com  Thu Feb  5 12:39:55 2015
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Thu, 5 Feb 2015 18:39:55 +0100
Subject: [wildfly-dev] CI build is broken
In-Reply-To: <CAGBoHQUMGGtAh5kz2yCD73RGtygtsRxxO1NjpUR-Z7bFAEDnog@mail.gmail.com>
References: <CAGBoHQW-td67ke7sdqq0SXg2KXPUX75bw1pT11ciMomLrmsjZw@mail.gmail.com>
	<CAMquZP4XBT10AqQr=T3wh7yiHOzVPMKGLqA6K3BP1jtUO0fKOA@mail.gmail.com>
	<CAGBoHQUMGGtAh5kz2yCD73RGtygtsRxxO1NjpUR-Z7bFAEDnog@mail.gmail.com>
Message-ID: <CAMquZP6gAOsFs0vOfeGKp=fnO4mTehtkhR+f39DFxP-TwE+0BQ@mail.gmail.com>

On Thu, Feb 5, 2015 at 6:19 PM, Arun Gupta <arun.gupta at gmail.com> wrote:

> Are the builds done internally and then published externally?
>
yes

>
> Why so, as opposed to build externally?
>
internally there is whole QE pool of servers available for building which
we don't have on public read only instance

>
> eng-ops would eng-ops at redhat.com?
>
yes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150205/bcb389ae/attachment-0001.html 

From brian.stansberry at redhat.com  Thu Feb  5 12:46:43 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 05 Feb 2015 11:46:43 -0600
Subject: [wildfly-dev] "Boot time" system props in the managed server's
 model
In-Reply-To: <2DC2A100-0D0F-4745-A3DF-E7F41F4B9609@redhat.com>
References: <54D39CDA.502@redhat.com>
	<ECC4DE0C-20D8-4EFE-BA28-997DB19380F5@jboss.com>
	<54D3A745.6070308@redhat.com>
	<2DC2A100-0D0F-4745-A3DF-E7F41F4B9609@redhat.com>
Message-ID: <54D3AC83.6000704@redhat.com>

On 2/5/15 11:33 AM, Jason Greene wrote:
>
>> On Feb 5, 2015, at 11:24 AM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>
>> On 2/5/15 11:13 AM, Kabir Khan wrote:
>>>
>>>> On 5 Feb 2015, at 16:39, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>>>
>>>> tl;dr
>>>>
>>>> We have a minor anomaly in system property processing in domain mode
>>>> that we intend to ignore.
>>>>
>>>> long version
>>>>
>>>> While digging into a bug Emmanuel Hugonnet noticed an anomaly. When you
>>>> define a system-property resource in domain.xml or host.xml with
>>>> "boot-time=true", the HC does both of the following when it launches a
>>>> server:
>>>>
>>>> 1) Uses -D to set the prop when it starts the server process.
>>>>
>>>> 2) Adds an add system-property op to the server's set of boot ops, which
>>>> causes the system property to get set again later during boot.
>>>>
>>>> Really, only 1) should happen; that's what "boot-time=true" means. The
>>>> purpose of boot-time=true is to ensure the value is set at JVM launch,
>>>> not waiting for management ops to execute, which may be too late for
>>>> props that are read early.
>>> I am not 100% convinced.
>>
>> Me neither. :)
>>
>> 1) should of course happen. But it could be argued that something in the
>> domain management model should always be reflected in the resulting
>> server management model. It feels a bit weird to make random exceptions.
>>
>> It's similar to a jvm setting. It's a configuration of how the HC behaves.
>
> If I understand correctly, the add op generated on all servers sets a system property, which activates at runtime correct?
>

Yes, but the property has already been set, via -D when the process was 
started. So it's redundant.

> If so I actually think the behavior is arguably correct, if a bit odd.
>

I don't see this part as much of a problem; it's just odd.

The problem is more the part you cut: when a prop gets added to the 
domain model after a server is running. Say in the CLI:

/system-property=java.net.preferIPv4Address:add(value=true,boot-time=true)

Domain level scope; applicable to all servers. All servers will end up 
getting this op as part of domain rollout of the change:

/system-property=java.net.preferIPv4Address:add(value=true)

Now those server JVMs will have java.net.preferIPv4Address=true

But their actual running behavior will not reflect this. The VM reads 
that prop early and doesn't read it again. You need to set it at VM 
launch for it to take proper effect, which is why we have the 
boot-time=true attribute in the first place.

At this point the server's runtime state is out of sync with the domain 
configuration, but we don't reflect that by putting the server in 
restart-required.

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


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

From kabir.khan at jboss.com  Thu Feb  5 12:51:46 2015
From: kabir.khan at jboss.com (Kabir Khan)
Date: Thu, 5 Feb 2015 17:51:46 +0000
Subject: [wildfly-dev] "Boot time" system props in the managed server's
	model
In-Reply-To: <2DC2A100-0D0F-4745-A3DF-E7F41F4B9609@redhat.com>
References: <54D39CDA.502@redhat.com>
	<ECC4DE0C-20D8-4EFE-BA28-997DB19380F5@jboss.com>
	<54D3A745.6070308@redhat.com>
	<2DC2A100-0D0F-4745-A3DF-E7F41F4B9609@redhat.com>
Message-ID: <0E517BC0-EAE5-4835-A063-BFFFF6DC8E00@jboss.com>


> On 5 Feb 2015, at 17:33, Jason Greene <jason.greene at redhat.com> wrote:
> 
> 
>> On Feb 5, 2015, at 11:24 AM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>> 
>> On 2/5/15 11:13 AM, Kabir Khan wrote:
>>> 
>>>> On 5 Feb 2015, at 16:39, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>>> 
>>>> tl;dr
>>>> 
>>>> We have a minor anomaly in system property processing in domain mode
>>>> that we intend to ignore.
>>>> 
>>>> long version
>>>> 
>>>> While digging into a bug Emmanuel Hugonnet noticed an anomaly. When you
>>>> define a system-property resource in domain.xml or host.xml with
>>>> "boot-time=true", the HC does both of the following when it launches a
>>>> server:
>>>> 
>>>> 1) Uses -D to set the prop when it starts the server process.
>>>> 
>>>> 2) Adds an add system-property op to the server's set of boot ops, which
>>>> causes the system property to get set again later during boot.
>>>> 
>>>> Really, only 1) should happen; that's what "boot-time=true" means. The
>>>> purpose of boot-time=true is to ensure the value is set at JVM launch,
>>>> not waiting for management ops to execute, which may be too late for
>>>> props that are read early.
>>> I am not 100% convinced.
>> 
>> Me neither. :)
>> 
>> 1) should of course happen. But it could be argued that something in the 
>> domain management model should always be reflected in the resulting 
>> server management model. It feels a bit weird to make random exceptions.
>> 
>> It's similar to a jvm setting. It's a configuration of how the HC behaves.
> 
> If I understand correctly, the add op generated on all servers sets a system property, which activates at runtime correct?
> 
> If so I actually think the behavior is arguably correct, if a bit odd.

They will get set in its system properties, although it might be 'too late? e.g. -Djava.security.manager needs to be passed in at boot time (this is a bad example since we?re moving to -secmgr but there are probably others)
Still I think this affects the whole system property idea, there could be other non-boot-time ones which are read on subsystem startup, and affect how a subsystem behaves. Changing those later has no effect. Or a similar example are the properties to toggle ipv4 vs ipv6, I believe once the stack has initialised changing those doesn?t have any effect whatsoever.
> 
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
> 



From arun.gupta at gmail.com  Thu Feb  5 13:02:19 2015
From: arun.gupta at gmail.com (Arun Gupta)
Date: Thu, 5 Feb 2015 10:02:19 -0800
Subject: [wildfly-dev] CI build is broken
In-Reply-To: <CAMquZP6gAOsFs0vOfeGKp=fnO4mTehtkhR+f39DFxP-TwE+0BQ@mail.gmail.com>
References: <CAGBoHQW-td67ke7sdqq0SXg2KXPUX75bw1pT11ciMomLrmsjZw@mail.gmail.com>
	<CAMquZP4XBT10AqQr=T3wh7yiHOzVPMKGLqA6K3BP1jtUO0fKOA@mail.gmail.com>
	<CAGBoHQUMGGtAh5kz2yCD73RGtygtsRxxO1NjpUR-Z7bFAEDnog@mail.gmail.com>
	<CAMquZP6gAOsFs0vOfeGKp=fnO4mTehtkhR+f39DFxP-TwE+0BQ@mail.gmail.com>
Message-ID: <CAGBoHQXJLr_J=LrQWL69OF+KS_drTK3AnAes-G3hH-00hCrLtA@mail.gmail.com>

Email sent, CCed you.

On Thu, Feb 5, 2015 at 9:39 AM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
>
> On Thu, Feb 5, 2015 at 6:19 PM, Arun Gupta <arun.gupta at gmail.com> wrote:
>>
>> Are the builds done internally and then published externally?
>
> yes
>>
>>
>> Why so, as opposed to build externally?
>
> internally there is whole QE pool of servers available for building which we
> don't have on public read only instance
>>
>>
>> eng-ops would eng-ops at redhat.com?
>
> yes
>
>



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


From jason.greene at redhat.com  Thu Feb  5 13:12:42 2015
From: jason.greene at redhat.com (Jason Greene)
Date: Thu, 5 Feb 2015 12:12:42 -0600
Subject: [wildfly-dev] "Boot time" system props in the managed server's
	model
In-Reply-To: <54D3AC83.6000704@redhat.com>
References: <54D39CDA.502@redhat.com>
	<ECC4DE0C-20D8-4EFE-BA28-997DB19380F5@jboss.com>
	<54D3A745.6070308@redhat.com>
	<2DC2A100-0D0F-4745-A3DF-E7F41F4B9609@redhat.com>
	<54D3AC83.6000704@redhat.com>
Message-ID: <140AD650-E2AA-4E84-B862-52411EEEFBBB@redhat.com>


> On Feb 5, 2015, at 11:46 AM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> 
> On 2/5/15 11:33 AM, Jason Greene wrote:
>> 
>>> On Feb 5, 2015, at 11:24 AM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>> 
>>> On 2/5/15 11:13 AM, Kabir Khan wrote:
>>>> 
>>>>> On 5 Feb 2015, at 16:39, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>>>> 
>>>>> tl;dr
>>>>> 
>>>>> We have a minor anomaly in system property processing in domain mode
>>>>> that we intend to ignore.
>>>>> 
>>>>> long version
>>>>> 
>>>>> While digging into a bug Emmanuel Hugonnet noticed an anomaly. When you
>>>>> define a system-property resource in domain.xml or host.xml with
>>>>> "boot-time=true", the HC does both of the following when it launches a
>>>>> server:
>>>>> 
>>>>> 1) Uses -D to set the prop when it starts the server process.
>>>>> 
>>>>> 2) Adds an add system-property op to the server's set of boot ops, which
>>>>> causes the system property to get set again later during boot.
>>>>> 
>>>>> Really, only 1) should happen; that's what "boot-time=true" means. The
>>>>> purpose of boot-time=true is to ensure the value is set at JVM launch,
>>>>> not waiting for management ops to execute, which may be too late for
>>>>> props that are read early.
>>>> I am not 100% convinced.
>>> 
>>> Me neither. :)
>>> 
>>> 1) should of course happen. But it could be argued that something in the
>>> domain management model should always be reflected in the resulting
>>> server management model. It feels a bit weird to make random exceptions.
>>> 
>>> It's similar to a jvm setting. It's a configuration of how the HC behaves.
>> 
>> If I understand correctly, the add op generated on all servers sets a system property, which activates at runtime correct?
>> 
> 
> Yes, but the property has already been set, via -D when the process was started. So it's redundant.
> 
>> 

Well I?m talking about the case where the server is already running and has not yet restarted. Perhaps that is why it does this?

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



From brian.stansberry at redhat.com  Thu Feb  5 13:19:41 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 05 Feb 2015 12:19:41 -0600
Subject: [wildfly-dev] "Boot time" system props in the managed server's
 model
In-Reply-To: <140AD650-E2AA-4E84-B862-52411EEEFBBB@redhat.com>
References: <54D39CDA.502@redhat.com>
	<ECC4DE0C-20D8-4EFE-BA28-997DB19380F5@jboss.com>
	<54D3A745.6070308@redhat.com>
	<2DC2A100-0D0F-4745-A3DF-E7F41F4B9609@redhat.com>
	<54D3AC83.6000704@redhat.com>
	<140AD650-E2AA-4E84-B862-52411EEEFBBB@redhat.com>
Message-ID: <54D3B43D.5050605@redhat.com>

On 2/5/15 12:12 PM, Jason Greene wrote:
>
>> On Feb 5, 2015, at 11:46 AM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>
>> On 2/5/15 11:33 AM, Jason Greene wrote:
>>>
>>>> On Feb 5, 2015, at 11:24 AM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>>>
>>>> On 2/5/15 11:13 AM, Kabir Khan wrote:
>>>>>
>>>>>> On 5 Feb 2015, at 16:39, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>>>>>
>>>>>> tl;dr
>>>>>>
>>>>>> We have a minor anomaly in system property processing in domain mode
>>>>>> that we intend to ignore.
>>>>>>
>>>>>> long version
>>>>>>
>>>>>> While digging into a bug Emmanuel Hugonnet noticed an anomaly. When you
>>>>>> define a system-property resource in domain.xml or host.xml with
>>>>>> "boot-time=true", the HC does both of the following when it launches a
>>>>>> server:
>>>>>>
>>>>>> 1) Uses -D to set the prop when it starts the server process.
>>>>>>
>>>>>> 2) Adds an add system-property op to the server's set of boot ops, which
>>>>>> causes the system property to get set again later during boot.
>>>>>>
>>>>>> Really, only 1) should happen; that's what "boot-time=true" means. The
>>>>>> purpose of boot-time=true is to ensure the value is set at JVM launch,
>>>>>> not waiting for management ops to execute, which may be too late for
>>>>>> props that are read early.
>>>>> I am not 100% convinced.
>>>>
>>>> Me neither. :)
>>>>
>>>> 1) should of course happen. But it could be argued that something in the
>>>> domain management model should always be reflected in the resulting
>>>> server management model. It feels a bit weird to make random exceptions.
>>>>
>>>> It's similar to a jvm setting. It's a configuration of how the HC behaves.
>>>
>>> If I understand correctly, the add op generated on all servers sets a system property, which activates at runtime correct?
>>>
>>
>> Yes, but the property has already been set, via -D when the process was started. So it's redundant.
>>
>>>
>
> Well I?m talking about the case where the server is already running and has not yet restarted. Perhaps that is why it does this?

Ah, I just noticed a detail. The default value of boot-time is true. 
Which makes sense; setting the prop at VM launch is the best way.

If the default is true though, that's pretty invisible to users, who may 
often want the prop set immediately when they configure it.

So, this confirms that I don't want to change this behavior.

Thanks for helping me think it through.

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


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

From dandread at redhat.com  Thu Feb  5 17:07:12 2015
From: dandread at redhat.com (Dimitris Andreadis)
Date: Thu, 05 Feb 2015 23:07:12 +0100
Subject: [wildfly-dev] Administrator Encouragement
In-Reply-To: <54D33125.3050109@jboss.com>
References: <54D33125.3050109@jboss.com>
Message-ID: <54D3E990.4010108@redhat.com>

Oh, the memories

https://developer.jboss.org/wiki/ActiveAlarmTable

On 05/02/2015 10:00, Darran Lofthouse wrote:
> Last week a few of us started talking about the possibility of adding a
> capability to WildFly that for want of a better name I was calling
> "Administrator Encouragement".
>
> I am not looking for this to be a design thread, that can come later but
> the general principal was that subsystems could register warnings with
> some kind of central service that admin tools could then retrieve later
> to advise administrators that some configuration could be required to
> improve their installation.  Warnings would potentially have a severity
> level and tooling would potentially have the option to guide the user to
> the correct place to resolve the issue.
>
> Anyway the purpose of this thread is that I wanted to try and gather
> together the kinds of warnings that we could be outputting, below is a
> list of some I have thought of already but would be interested in
> hearing any additional ideas.
>
>    - SSL is not configured.
>    - SSL certificates are due to expire.
>    - Plain text password detected in the configuration.
>    - Some form of file based storage in use but growing beyond intended size.
>    - Default node name  has not been changed.
>    - Patches available but not applied, subsequent releases available.
>
> Anyway these are just a few ideas and interested in hearing any more.
>
> Regards,
> Darran Lofthouse.
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From jason.greene at redhat.com  Thu Feb  5 17:12:51 2015
From: jason.greene at redhat.com (Jason Greene)
Date: Thu, 5 Feb 2015 16:12:51 -0600
Subject: [wildfly-dev] Administrator Encouragement
In-Reply-To: <54D33125.3050109@jboss.com>
References: <54D33125.3050109@jboss.com>
Message-ID: <54A05F53-3BBC-4E2C-A172-12F8A0290D7E@redhat.com>


> On Feb 5, 2015, at 3:00 AM, Darran Lofthouse <darran.lofthouse at jboss.com> wrote:
> 
> Last week a few of us started talking about the possibility of adding a 
> capability to WildFly that for want of a better name I was calling 
> "Administrator Encouragement?.

Recommendations is a much better term.

When I hear encouragement i keep thinking it says: 

?Wow you are a super awesome Administrator!?
?Looking good!?
?Excellent choice! I would have updated that value too!?
?You can click yes, I?m sure it will all work out!"

> 
> I am not looking for this to be a design thread, that can come later but 
> the general principal was that subsystems could register warnings with 
> some kind of central service that admin tools could then retrieve later 
> to advise administrators that some configuration could be required to 
> improve their installation.  Warnings would potentially have a severity 
> level and tooling would potentially have the option to guide the user to 
> the correct place to resolve the issue.
> 
> Anyway the purpose of this thread is that I wanted to try and gather 
> together the kinds of warnings that we could be outputting, below is a 
> list of some I have thought of already but would be interested in 
> hearing any additional ideas.
> 
>  - SSL is not configured.
>  - SSL certificates are due to expire.
>  - Plain text password detected in the configuration.
>  - Some form of file based storage in use but growing beyond intended size.
>  - Default node name  has not been changed.
>  - Patches available but not applied, subsequent releases available.
> 
> Anyway these are just a few ideas and interested in hearing any more.
> 
> Regards,
> Darran Lofthouse.
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

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



From rodakr at gmx.ch  Thu Feb  5 18:14:58 2015
From: rodakr at gmx.ch (Radoslaw Rodak)
Date: Fri, 6 Feb 2015 00:14:58 +0100
Subject: [wildfly-dev] Administrator Encouragement
In-Reply-To: <54A05F53-3BBC-4E2C-A172-12F8A0290D7E@redhat.com>
References: <54D33125.3050109@jboss.com>
	<54A05F53-3BBC-4E2C-A172-12F8A0290D7E@redhat.com>
Message-ID: <8DD17CD0-CACA-4CA1-BA16-BC72BD3961A1@gmx.ch>

Adding scripting language arround  CLI should do the job :-)

Radek


Am 05.02.2015 um 23:12 schrieb Jason Greene <jason.greene at redhat.com>:

> 
>> On Feb 5, 2015, at 3:00 AM, Darran Lofthouse <darran.lofthouse at jboss.com> wrote:
>> 
>> Last week a few of us started talking about the possibility of adding a 
>> capability to WildFly that for want of a better name I was calling 
>> "Administrator Encouragement?.
> 
> Recommendations is a much better term.
> 
> When I hear encouragement i keep thinking it says: 
> 
> ?Wow you are a super awesome Administrator!?
> ?Looking good!?
> ?Excellent choice! I would have updated that value too!?
> ?You can click yes, I?m sure it will all work out!"
> 
>> 
>> I am not looking for this to be a design thread, that can come later but 
>> the general principal was that subsystems could register warnings with 
>> some kind of central service that admin tools could then retrieve later 
>> to advise administrators that some configuration could be required to 
>> improve their installation.  Warnings would potentially have a severity 
>> level and tooling would potentially have the option to guide the user to 
>> the correct place to resolve the issue.
>> 
>> Anyway the purpose of this thread is that I wanted to try and gather 
>> together the kinds of warnings that we could be outputting, below is a 
>> list of some I have thought of already but would be interested in 
>> hearing any additional ideas.
>> 
>> - SSL is not configured.
>> - SSL certificates are due to expire.
>> - Plain text password detected in the configuration.
>> - Some form of file based storage in use but growing beyond intended size.
>> - Default node name  has not been changed.
>> - Patches available but not applied, subsequent releases available.
>> 
>> Anyway these are just a few ideas and interested in hearing any more.
>> 
>> Regards,
>> Darran Lofthouse.
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



From darran.lofthouse at jboss.com  Fri Feb  6 04:31:15 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Fri, 06 Feb 2015 09:31:15 +0000
Subject: [wildfly-dev] Administrator Encouragement
In-Reply-To: <54A05F53-3BBC-4E2C-A172-12F8A0290D7E@redhat.com>
References: <54D33125.3050109@jboss.com>
	<54A05F53-3BBC-4E2C-A172-12F8A0290D7E@redhat.com>
Message-ID: <54D489E3.7040500@jboss.com>



On 05/02/15 22:12, Jason Greene wrote:
>
>> On Feb 5, 2015, at 3:00 AM, Darran Lofthouse <darran.lofthouse at jboss.com> wrote:
>>
>> Last week a few of us started talking about the possibility of adding a
>> capability to WildFly that for want of a better name I was calling
>> "Administrator Encouragement?.
>
> Recommendations is a much better term.
>
> When I hear encouragement i keep thinking it says:
>
> ?Wow you are a super awesome Administrator!?
> ?Looking good!?
> ?Excellent choice! I would have updated that value too!?
> ?You can click yes, I?m sure it will all work out!"

If someone wants some experience writing a subsystem they could even use 
this capability to contact a remote service and download an 
inspirational message for the day to present to their administrators ;-)

>>
>> I am not looking for this to be a design thread, that can come later but
>> the general principal was that subsystems could register warnings with
>> some kind of central service that admin tools could then retrieve later
>> to advise administrators that some configuration could be required to
>> improve their installation.  Warnings would potentially have a severity
>> level and tooling would potentially have the option to guide the user to
>> the correct place to resolve the issue.
>>
>> Anyway the purpose of this thread is that I wanted to try and gather
>> together the kinds of warnings that we could be outputting, below is a
>> list of some I have thought of already but would be interested in
>> hearing any additional ideas.
>>
>>   - SSL is not configured.
>>   - SSL certificates are due to expire.
>>   - Plain text password detected in the configuration.
>>   - Some form of file based storage in use but growing beyond intended size.
>>   - Default node name  has not been changed.
>>   - Patches available but not applied, subsequent releases available.
>>
>> Anyway these are just a few ideas and interested in hearing any more.
>>
>> Regards,
>> Darran Lofthouse.
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>

From darran.lofthouse at jboss.com  Fri Feb  6 04:37:17 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Fri, 06 Feb 2015 09:37:17 +0000
Subject: [wildfly-dev] Administrator Encouragement
In-Reply-To: <54D3E990.4010108@redhat.com>
References: <54D33125.3050109@jboss.com> <54D3E990.4010108@redhat.com>
Message-ID: <54D48B4D.2080607@jboss.com>

On 05/02/15 22:07, Dimitris Andreadis wrote:
> Oh, the memories
>
> https://developer.jboss.org/wiki/ActiveAlarmTable

And we have our first contributor ;-)


> On 05/02/2015 10:00, Darran Lofthouse wrote:
>> Last week a few of us started talking about the possibility of adding a
>> capability to WildFly that for want of a better name I was calling
>> "Administrator Encouragement".
>>
>> I am not looking for this to be a design thread, that can come later but
>> the general principal was that subsystems could register warnings with
>> some kind of central service that admin tools could then retrieve later
>> to advise administrators that some configuration could be required to
>> improve their installation.  Warnings would potentially have a severity
>> level and tooling would potentially have the option to guide the user to
>> the correct place to resolve the issue.
>>
>> Anyway the purpose of this thread is that I wanted to try and gather
>> together the kinds of warnings that we could be outputting, below is a
>> list of some I have thought of already but would be interested in
>> hearing any additional ideas.
>>
>>     - SSL is not configured.
>>     - SSL certificates are due to expire.
>>     - Plain text password detected in the configuration.
>>     - Some form of file based storage in use but growing beyond intended size.
>>     - Default node name  has not been changed.
>>     - Patches available but not applied, subsequent releases available.
>>
>> Anyway these are just a few ideas and interested in hearing any more.
>>
>> 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 rory.odonnell at oracle.com  Fri Feb  6 06:29:57 2015
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Fri, 06 Feb 2015 11:29:57 +0000
Subject: [wildfly-dev] Early Access builds for JDK 9 b48,
 JDK 8u40 b23 & JDK 7u80 b05 are available on java.net
Message-ID: <54D4A5B5.7050807@oracle.com>

Hi Jason/Tomaz,

Now that JDK 9 Early Access build images are modular [1], there is a fresh
Early Access build for JDK 9 b48 <https://jdk9.java.net/download/> 
available on java.net.
The summary of  changes are listed here 
<http://www.java.net/download/jdk9/changes/jdk9-b48.html>

In addition, there are new Early Access builds for the ongoing update 
releases.

The Early Access build for JDK 8u40 b23 
<http://jdk8.java.net/download.html> is available on java.net, with the
summary of changes listed here. 
<http://www.java.net/download/jdk8u40/changes/jdk8u40-b23.html>

Finally, the Early Access build for JDK 7u80 b05 
<https://jdk7.java.net/download.html>is available on java.net,
with the summary of changes listed here. 
<http://download.java.net/jdk7u80/changes/jdk7u80-b05.html>

As we enter the later phases of development for JDK 7u80 & JDK 8u40,
please log any show stoppers as soon as possible.

Rgds,Rory

[1] http://mreinhold.org/blog/jigsaw-modular-images

-- 
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/20150206/66cd7bfd/attachment.html 

From ssilvert at redhat.com  Fri Feb  6 07:37:00 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 06 Feb 2015 07:37:00 -0500
Subject: [wildfly-dev] Administrator Encouragement
In-Reply-To: <8DD17CD0-CACA-4CA1-BA16-BC72BD3961A1@gmx.ch>
References: <54D33125.3050109@jboss.com>
	<54A05F53-3BBC-4E2C-A172-12F8A0290D7E@redhat.com>
	<8DD17CD0-CACA-4CA1-BA16-BC72BD3961A1@gmx.ch>
Message-ID: <54D4B56C.6020904@redhat.com>

On 2/5/2015 6:14 PM, Radoslaw Rodak wrote:
> Adding scripting language arround  CLI should do the job :-)
You mean this? 
https://developer.jboss.org/wiki/AdvancedCLIScriptingWithGroovyRhinoJythonEtc

I'm not sure what you mean.
>
> Radek
>
>
> Am 05.02.2015 um 23:12 schrieb Jason Greene <jason.greene at redhat.com>:
>
>>> On Feb 5, 2015, at 3:00 AM, Darran Lofthouse <darran.lofthouse at jboss.com> wrote:
>>>
>>> Last week a few of us started talking about the possibility of adding a
>>> capability to WildFly that for want of a better name I was calling
>>> "Administrator Encouragement?.
>> Recommendations is a much better term.
>>
>> When I hear encouragement i keep thinking it says:
>>
>> ?Wow you are a super awesome Administrator!?
>> ?Looking good!?
>> ?Excellent choice! I would have updated that value too!?
>> ?You can click yes, I?m sure it will all work out!"
>>
>>> I am not looking for this to be a design thread, that can come later but
>>> the general principal was that subsystems could register warnings with
>>> some kind of central service that admin tools could then retrieve later
>>> to advise administrators that some configuration could be required to
>>> improve their installation.  Warnings would potentially have a severity
>>> level and tooling would potentially have the option to guide the user to
>>> the correct place to resolve the issue.
>>>
>>> Anyway the purpose of this thread is that I wanted to try and gather
>>> together the kinds of warnings that we could be outputting, below is a
>>> list of some I have thought of already but would be interested in
>>> hearing any additional ideas.
>>>
>>> - SSL is not configured.
>>> - SSL certificates are due to expire.
>>> - Plain text password detected in the configuration.
>>> - Some form of file based storage in use but growing beyond intended size.
>>> - Default node name  has not been changed.
>>> - Patches available but not applied, subsequent releases available.
>>>
>>> Anyway these are just a few ideas and interested in hearing any more.
>>>
>>> Regards,
>>> Darran Lofthouse.
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> --
>> Jason T. Greene
>> WildFly Lead / JBoss EAP Platform Architect
>> JBoss, a division of Red Hat
>>
>>
>> _______________________________________________
>> 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 rodakr at gmx.ch  Fri Feb  6 15:58:27 2015
From: rodakr at gmx.ch (Radoslaw Rodak)
Date: Fri, 6 Feb 2015 21:58:27 +0100
Subject: [wildfly-dev] Administrator Encouragement
In-Reply-To: <54D4B56C.6020904@redhat.com>
References: <54D33125.3050109@jboss.com>
	<54A05F53-3BBC-4E2C-A172-12F8A0290D7E@redhat.com>
	<8DD17CD0-CACA-4CA1-BA16-BC72BD3961A1@gmx.ch>
	<54D4B56C.6020904@redhat.com>
Message-ID: <D3360FF2-908E-4392-8EBF-11BDA111B577@gmx.ch>

Yes!

Very Nice!

1+

Am 06.02.2015 um 13:37 schrieb Stan Silvert <ssilvert at redhat.com>:

> On 2/5/2015 6:14 PM, Radoslaw Rodak wrote:
>> Adding scripting language arround  CLI should do the job :-)
> You mean this? 
> https://developer.jboss.org/wiki/AdvancedCLIScriptingWithGroovyRhinoJythonEtc
> 
> I'm not sure what you mean.
>> 
>> Radek
>> 
>> 
>> Am 05.02.2015 um 23:12 schrieb Jason Greene <jason.greene at redhat.com>:
>> 
>>>> On Feb 5, 2015, at 3:00 AM, Darran Lofthouse <darran.lofthouse at jboss.com> wrote:
>>>> 
>>>> Last week a few of us started talking about the possibility of adding a
>>>> capability to WildFly that for want of a better name I was calling
>>>> "Administrator Encouragement?.
>>> Recommendations is a much better term.
>>> 
>>> When I hear encouragement i keep thinking it says:
>>> 
>>> ?Wow you are a super awesome Administrator!?
>>> ?Looking good!?
>>> ?Excellent choice! I would have updated that value too!?
>>> ?You can click yes, I?m sure it will all work out!"
>>> 
>>>> I am not looking for this to be a design thread, that can come later but
>>>> the general principal was that subsystems could register warnings with
>>>> some kind of central service that admin tools could then retrieve later
>>>> to advise administrators that some configuration could be required to
>>>> improve their installation.  Warnings would potentially have a severity
>>>> level and tooling would potentially have the option to guide the user to
>>>> the correct place to resolve the issue.
>>>> 
>>>> Anyway the purpose of this thread is that I wanted to try and gather
>>>> together the kinds of warnings that we could be outputting, below is a
>>>> list of some I have thought of already but would be interested in
>>>> hearing any additional ideas.
>>>> 
>>>> - SSL is not configured.
>>>> - SSL certificates are due to expire.
>>>> - Plain text password detected in the configuration.
>>>> - Some form of file based storage in use but growing beyond intended size.
>>>> - Default node name  has not been changed.
>>>> - Patches available but not applied, subsequent releases available.
>>>> 
>>>> Anyway these are just a few ideas and interested in hearing any more.
>>>> 
>>>> Regards,
>>>> Darran Lofthouse.
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> --
>>> Jason T. Greene
>>> WildFly Lead / JBoss EAP Platform Architect
>>> JBoss, a division of Red Hat
>>> 
>>> 
>>> _______________________________________________
>>> 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 jlivings at redhat.com  Sun Feb  8 17:28:21 2015
From: jlivings at redhat.com (James Livingston)
Date: Mon, 09 Feb 2015 08:28:21 +1000
Subject: [wildfly-dev] Administrator Encouragement
In-Reply-To: <54D33125.3050109@jboss.com>
References: <54D33125.3050109@jboss.com>
Message-ID: <1423434501.9597.6.camel@redhat.com>

On Thu, 2015-02-05 at 09:00 +0000, Darran Lofthouse wrote:
> Anyway the purpose of this thread is that I wanted to try and gather 
> together the kinds of warnings that we could be outputting, below is a 
> list of some I have thought of already but would be interested in 
> hearing any additional ideas.
> 
>   - SSL is not configured.
>   - SSL certificates are due to expire.
>   - Plain text password detected in the configuration.
>   - Some form of file based storage in use but growing beyond intended size.
>   - Default node name  has not been changed.
>   - Patches available but not applied, subsequent releases available.

If you're thinking about runtime warnings, as opposed to plain
administrative actions that should be taken, there are some things which
are WARN/ERROR in logs that may be good to show too so they don't get
lost. For example timeouts acquiring pooled resources, such as EJBs
instances or JDBC connections, which may indicate problems or
mis-configuration.

I have a half-baked idea about detecting excessive GC pauses in managed
servers, which if it worked could make a useful runtime warning.


-- 
James Livingston
JBoss Support Engineering Group


From lthon at redhat.com  Mon Feb  9 02:56:03 2015
From: lthon at redhat.com (Ladislav Thon)
Date: Mon, 09 Feb 2015 08:56:03 +0100
Subject: [wildfly-dev] Administrator Encouragement
In-Reply-To: <1423434501.9597.6.camel@redhat.com>
References: <54D33125.3050109@jboss.com> <1423434501.9597.6.camel@redhat.com>
Message-ID: <54D86813.5050005@redhat.com>

On 8.2.2015 23:28, James Livingston wrote:
> On Thu, 2015-02-05 at 09:00 +0000, Darran Lofthouse wrote:
>> Anyway the purpose of this thread is that I wanted to try and gather 
>> together the kinds of warnings that we could be outputting, below is a 
>> list of some I have thought of already but would be interested in 
>> hearing any additional ideas.
>>
>>   - SSL is not configured.
>>   - SSL certificates are due to expire.
>>   - Plain text password detected in the configuration.
>>   - Some form of file based storage in use but growing beyond intended size.
>>   - Default node name  has not been changed.
>>   - Patches available but not applied, subsequent releases available.
> 
> If you're thinking about runtime warnings, as opposed to plain
> administrative actions that should be taken, there are some things which
> are WARN/ERROR in logs that may be good to show too so they don't get
> lost. For example timeouts acquiring pooled resources, such as EJBs
> instances or JDBC connections, which may indicate problems or
> mis-configuration.
> 
> I have a half-baked idea about detecting excessive GC pauses in managed
> servers, which if it worked could make a useful runtime warning.

Can't you just use jHiccup?

LT

From theute at redhat.com  Mon Feb  9 04:29:31 2015
From: theute at redhat.com (Thomas Heute)
Date: Mon, 09 Feb 2015 10:29:31 +0100
Subject: [wildfly-dev] Administrator Encouragement
In-Reply-To: <54D33125.3050109@jboss.com>
References: <54D33125.3050109@jboss.com>
Message-ID: <54D87DFB.709@redhat.com>

Sounds good, please make it consumable by 3rd party solutions ;)

This would be great in combination with predictable alerts that we have 
on our todo. ("At this rate your disk will be full in 1 month, time to 
do something")

Thomas

On 02/05/2015 10:00 AM, Darran Lofthouse wrote:
> Last week a few of us started talking about the possibility of adding a
> capability to WildFly that for want of a better name I was calling
> "Administrator Encouragement".
>
> I am not looking for this to be a design thread, that can come later but
> the general principal was that subsystems could register warnings with
> some kind of central service that admin tools could then retrieve later
> to advise administrators that some configuration could be required to
> improve their installation.  Warnings would potentially have a severity
> level and tooling would potentially have the option to guide the user to
> the correct place to resolve the issue.
>
> Anyway the purpose of this thread is that I wanted to try and gather
> together the kinds of warnings that we could be outputting, below is a
> list of some I have thought of already but would be interested in
> hearing any additional ideas.
>
>    - SSL is not configured.
>    - SSL certificates are due to expire.
>    - Plain text password detected in the configuration.
>    - Some form of file based storage in use but growing beyond intended size.
>    - Default node name  has not been changed.
>    - Patches available but not applied, subsequent releases available.
>
> Anyway these are just a few ideas and interested in hearing any more.
>
> 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  Mon Feb  9 09:40:21 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 09 Feb 2015 08:40:21 -0600
Subject: [wildfly-dev] Administrator Encouragement
In-Reply-To: <1423434501.9597.6.camel@redhat.com>
References: <54D33125.3050109@jboss.com> <1423434501.9597.6.camel@redhat.com>
Message-ID: <54D8C6D5.1040701@redhat.com>

On 2/8/15 4:28 PM, James Livingston wrote:
> On Thu, 2015-02-05 at 09:00 +0000, Darran Lofthouse wrote:
>> Anyway the purpose of this thread is that I wanted to try and gather
>> together the kinds of warnings that we could be outputting, below is a
>> list of some I have thought of already but would be interested in
>> hearing any additional ideas.
>>
>>    - SSL is not configured.
>>    - SSL certificates are due to expire.
>>    - Plain text password detected in the configuration.
>>    - Some form of file based storage in use but growing beyond intended size.
>>    - Default node name  has not been changed.
>>    - Patches available but not applied, subsequent releases available.
>
> If you're thinking about runtime warnings, as opposed to plain
> administrative actions that should be taken, there are some things which
> are WARN/ERROR in logs that may be good to show too so they don't get
> lost. For example timeouts acquiring pooled resources, such as EJBs
> instances or JDBC connections, which may indicate problems or
> mis-configuration.
>
> I have a half-baked idea about detecting excessive GC pauses in managed
> servers, which if it worked could make a useful runtime warning.
>

This is drifting into a general notification and alerting tool, which is 
a natural direction to go.

Darran, do you have any thoughts on the boundaries between what you 
envisioned and full fledged notification and/or alerting tool?



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

From darran.lofthouse at jboss.com  Mon Feb  9 09:47:31 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Mon, 09 Feb 2015 14:47:31 +0000
Subject: [wildfly-dev] Administrator Encouragement
In-Reply-To: <54D8C6D5.1040701@redhat.com>
References: <54D33125.3050109@jboss.com> <1423434501.9597.6.camel@redhat.com>
	<54D8C6D5.1040701@redhat.com>
Message-ID: <54D8C883.1060000@jboss.com>

On 09/02/15 14:40, Brian Stansberry wrote:
> On 2/8/15 4:28 PM, James Livingston wrote:
>> On Thu, 2015-02-05 at 09:00 +0000, Darran Lofthouse wrote:
>>> Anyway the purpose of this thread is that I wanted to try and gather
>>> together the kinds of warnings that we could be outputting, below is a
>>> list of some I have thought of already but would be interested in
>>> hearing any additional ideas.
>>>
>>>     - SSL is not configured.
>>>     - SSL certificates are due to expire.
>>>     - Plain text password detected in the configuration.
>>>     - Some form of file based storage in use but growing beyond intended size.
>>>     - Default node name  has not been changed.
>>>     - Patches available but not applied, subsequent releases available.
>>
>> If you're thinking about runtime warnings, as opposed to plain
>> administrative actions that should be taken, there are some things which
>> are WARN/ERROR in logs that may be good to show too so they don't get
>> lost. For example timeouts acquiring pooled resources, such as EJBs
>> instances or JDBC connections, which may indicate problems or
>> mis-configuration.
>>
>> I have a half-baked idea about detecting excessive GC pauses in managed
>> servers, which if it worked could make a useful runtime warning.
>>
>
> This is drifting into a general notification and alerting tool, which is
> a natural direction to go.
>
> Darran, do you have any thoughts on the boundaries between what you
> envisioned and full fledged notification and/or alerting tool?

That is kind of what I am trying to explore with this thread.  The types 
of notifications I know I need are fairly simple for me to design 
something around but I am trying to see the other kinds of notifications 
we could consider so we don't design ourselves away from being able to 
add them in the future.

>
>
>

From david.lloyd at redhat.com  Mon Feb  9 12:06:41 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Mon, 09 Feb 2015 11:06:41 -0600
Subject: [wildfly-dev] WildFly Client Configuration 1.0.0.Alpha1
Message-ID: <54D8E921.3070905@redhat.com>

I've tagged and released version 1.0.0.Alpha1 of the WildFly Client 
Configuration library.  It is on GitHub [1] and in Maven as 
org.wildfly.client:wildfly-client-config.  It requires Java 8.

This library will be the basis of the common client configuration file 
that will be shared by (at a minimum) Remoting, EJB, remote JNDI, remote 
JTA, and Elytron.  It is my hope that we will also migrate other clients 
to this as well before the WildFly 10 release.

There are some similarities between this project and StAXMapper so it's 
possible (but not necessary) that at some point in the future we may 
want to try and combine the two projects.  This can be a later discussion.

[1] https://github.com/wildfly/wildfly-client-config
-- 
- DML

From brian.stansberry at redhat.com  Mon Feb  9 13:23:54 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 09 Feb 2015 12:23:54 -0600
Subject: [wildfly-dev] WildFly Core Alpha17 released
Message-ID: <54D8FB3A.7000903@redhat.com>

The latest in our roughly weekly series of WildFly Core alphas has been 
released and merged into full WildFly's master branch.

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

From tomaz.cerar at gmail.com  Mon Feb  9 16:19:28 2015
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Mon, 9 Feb 2015 22:19:28 +0100
Subject: [wildfly-dev] Moving WildFly 9 to Java 8?
Message-ID: <CAMquZP74p17yOuWFtK3YXwCyA2Ps1N7bEZ4nNzwekqt0qNyCcQ@mail.gmail.com>

Hi folks,

we agreed that WildFly 10+ is going to require Java 8, given that its
release date is planned well after JDK7 will be EOL-ed. [1]

Looking at all discussion and new projects / components already require
JDK8 (Eltryon, new WildFly client, Weld 3,...) for development.
I was wondering if we could move WildFly 9 to Java 8 as well?

According to current release plan WF9 should be release around the same
time JDK7 is EOL-ed (April 2015) [1]

Pros of moving to JDK8 early:
- components can use JDK8 eariler --> better testing
- supporting JDK9 will be easier (-XX:MaxPermSize fails to start JVM on 9)
- support for TLS SNI (think of it as virtual hosts for SSL)
- better ciphers and many other security related improvements
- nashorn (fast javascript engine)
- better concurrency libs
- easier testing, one less JDK combo to test on CI

and of course all of the language improvements, lambda ftw!

Cons of moving early

- back porting of code could be impaired
- there is currently no non beta release of IBM JDK8

There are probably other pros & cons but in general I think it would be
better to upgrade early as there will be many
hidden issues with new Java 8 features people want to use but are server
doesn't understand currently, mostly here
are features like enhanced type annotations and default methods.

This problem are and will creep up more and more often as adoption of Java
8 is quite good already [2] and still rising.

so what do you guys think? Should we move for WildFly or should we wait for
10 as planned?

--
tomaz


[1] http://www.oracle.com/technetwork/java/eol-135779.html
[2] http://jaxenter.com/java-2-111936.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150209/08726a9f/attachment.html 

From jperkins at redhat.com  Mon Feb  9 16:46:42 2015
From: jperkins at redhat.com (James R. Perkins)
Date: Mon, 09 Feb 2015 13:46:42 -0800
Subject: [wildfly-dev] Moving WildFly 9 to Java 8?
In-Reply-To: <CAMquZP74p17yOuWFtK3YXwCyA2Ps1N7bEZ4nNzwekqt0qNyCcQ@mail.gmail.com>
References: <CAMquZP74p17yOuWFtK3YXwCyA2Ps1N7bEZ4nNzwekqt0qNyCcQ@mail.gmail.com>
Message-ID: <54D92AC2.3090302@redhat.com>

I'd vote no. We've already done the core split for 9. I think adding 
another major change like this is a bad idea at this stage.

On 02/09/2015 01:19 PM, Toma? Cerar wrote:
> Hi folks,
>
> we agreed that WildFly 10+ is going to require Java 8, given that its 
> release date is planned well after JDK7 will be EOL-ed. [1]
>
> Looking at all discussion and new projects / components already 
> require JDK8 (Eltryon, new WildFly client, Weld 3,...) for development.
> I was wondering if we could move WildFly 9 to Java 8 as well?
>
> According to current release plan WF9 should be release around the 
> same time JDK7 is EOL-ed (April 2015) [1]
>
> Pros of moving to JDK8 early:
> - components can use JDK8 eariler --> better testing
> - supporting JDK9 will be easier (-XX:MaxPermSize fails to start JVM on 9)
> - support for TLS SNI (think of it as virtual hosts for SSL)
> - better ciphers and many other security related improvements
> - nashorn (fast javascript engine)
> - better concurrency libs
> - easier testing, one less JDK combo to test on CI
>
> and of course all of the language improvements, lambda ftw!
>
> Cons of moving early
>
> - back porting of code could be impaired
> - there is currently no non beta release of IBM JDK8
>
> There are probably other pros & cons but in general I think it would 
> be better to upgrade early as there will be many
> hidden issues with new Java 8 features people want to use but are 
> server doesn't understand currently, mostly here
> are features like enhanced type annotations and default methods.
>
> This problem are and will creep up more and more often as adoption of 
> Java 8 is quite good already [2] and still rising.
>
> so what do you guys think? Should we move for WildFly or should we 
> wait for 10 as planned?
>
> --
> tomaz
>
>
> [1] http://www.oracle.com/technetwork/java/eol-135779.html
> [2] http://jaxenter.com/java-2-111936.html
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-- 
James R. Perkins
JBoss by Red Hat

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

From hbraun at redhat.com  Tue Feb 10 04:20:15 2015
From: hbraun at redhat.com (Heiko Braun)
Date: Tue, 10 Feb 2015 10:20:15 +0100
Subject: [wildfly-dev] WildFly Core Alpha17 released
In-Reply-To: <54D8FB3A.7000903@redhat.com>
References: <54D8FB3A.7000903@redhat.com>
Message-ID: <AA5D9C65-E188-4143-ADFA-C70ED665A4A6@redhat.com>

Cool, that means CORS is now included, right?

> On 09 Feb 2015, at 19:23, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> 
> The latest in our roughly weekly series of WildFly Core alphas has been 
> released and merged into full WildFly's master branch.
> 
> -- 
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



From dandread at redhat.com  Tue Feb 10 08:20:27 2015
From: dandread at redhat.com (Dimitris Andreadis)
Date: Tue, 10 Feb 2015 14:20:27 +0100
Subject: [wildfly-dev] Moving WildFly 9 to Java 8?
In-Reply-To: <54D92AC2.3090302@redhat.com>
References: <CAMquZP74p17yOuWFtK3YXwCyA2Ps1N7bEZ4nNzwekqt0qNyCcQ@mail.gmail.com>
	<54D92AC2.3090302@redhat.com>
Message-ID: <54DA059B.2070706@redhat.com>

There is also the TCK that would have to re-pass with jdk8.

On 09/02/2015 22:46, James R. Perkins wrote:
> I'd vote no. We've already done the core split for 9. I think adding another major change
> like this is a bad idea at this stage.
>
> On 02/09/2015 01:19 PM, Toma? Cerar wrote:
>> Hi folks,
>>
>> we agreed that WildFly 10+ is going to require Java 8, given that its release date is
>> planned well after JDK7 will be EOL-ed. [1]
>>
>> Looking at all discussion and new projects / components already require JDK8 (Eltryon, new
>> WildFly client, Weld 3,...) for development.
>> I was wondering if we could move WildFly 9 to Java 8 as well?
>>
>> According to current release plan WF9 should be release around the same time JDK7 is
>> EOL-ed (April 2015) [1]
>>
>> Pros of moving to JDK8 early:
>> - components can use JDK8 eariler --> better testing
>> - supporting JDK9 will be easier (-XX:MaxPermSize fails to start JVM on 9)
>> - support for TLS SNI (think of it as virtual hosts for SSL)
>> - better ciphers and many other security related improvements
>> - nashorn (fast javascript engine)
>> - better concurrency libs
>> - easier testing, one less JDK combo to test on CI
>>
>> and of course all of the language improvements, lambda ftw!
>>
>> Cons of moving early
>>
>> - back porting of code could be impaired
>> - there is currently no non beta release of IBM JDK8
>>
>> There are probably other pros & cons but in general I think it would be better to upgrade
>> early as there will be many
>> hidden issues with new Java 8 features people want to use but are server doesn't
>> understand currently, mostly here
>> are features like enhanced type annotations and default methods.
>>
>> This problem are and will creep up more and more often as adoption of Java 8 is quite good
>> already [2] and still rising.
>>
>> so what do you guys think? Should we move for WildFly or should we wait for 10 as planned?
>>
>> --
>> tomaz
>>
>>
>> [1] http://www.oracle.com/technetwork/java/eol-135779.html
>> [2] http://jaxenter.com/java-2-111936.html
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> --
> James R. Perkins
> JBoss by Red Hat
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From tomaz.cerar at gmail.com  Tue Feb 10 08:44:09 2015
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Tue, 10 Feb 2015 14:44:09 +0100
Subject: [wildfly-dev] Moving WildFly 9 to Java 8?
In-Reply-To: <54DA059B.2070706@redhat.com>
References: <CAMquZP74p17yOuWFtK3YXwCyA2Ps1N7bEZ4nNzwekqt0qNyCcQ@mail.gmail.com>
	<54D92AC2.3090302@redhat.com> <54DA059B.2070706@redhat.com>
Message-ID: <CAMquZP5kiWptkCHomSo8KthBdE-Gt-RXq0CV3MB4XsCWQt54ww@mail.gmail.com>

On Tue, Feb 10, 2015 at 2:20 PM, Dimitris Andreadis <dandread at redhat.com>
wrote:

> There is also the TCK that would have to re-pass with jdk8.



Absolutely, but AFAIR, we got tck update that works on Java 8.

Scott, can you confirm this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150210/585793c2/attachment.html 

From brian.stansberry at redhat.com  Tue Feb 10 09:22:09 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 10 Feb 2015 08:22:09 -0600
Subject: [wildfly-dev] WildFly Core Alpha17 released
In-Reply-To: <AA5D9C65-E188-4143-ADFA-C70ED665A4A6@redhat.com>
References: <54D8FB3A.7000903@redhat.com>
	<AA5D9C65-E188-4143-ADFA-C70ED665A4A6@redhat.com>
Message-ID: <54DA1411.6040102@redhat.com>

This is included:

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

On 2/10/15 3:20 AM, Heiko Braun wrote:
> Cool, that means CORS is now included, right?
>
>> On 09 Feb 2015, at 19:23, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>
>> The latest in our roughly weekly series of WildFly Core alphas has been
>> released and merged into full WildFly's master branch.
>>
>> --
>> Brian Stansberry
>> Senior Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


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

From hpehl at redhat.com  Tue Feb 10 12:00:12 2015
From: hpehl at redhat.com (Harald Pehl)
Date: Tue, 10 Feb 2015 18:00:12 +0100
Subject: [wildfly-dev] WildFly Core Alpha17 released
In-Reply-To: <54DA1411.6040102@redhat.com>
References: <54D8FB3A.7000903@redhat.com>
	<AA5D9C65-E188-4143-ADFA-C70ED665A4A6@redhat.com>
	<54DA1411.6040102@redhat.com>
Message-ID: <89ED1C2E-016E-48C8-B4EB-B51D91018741@redhat.com>

Great we finally have CORS support. However the defaults for allowed origins are missing. I filed [1] to address this. 

[1] https://issues.jboss.org/browse/WFCORE-535

> Am 10.02.2015 um 15:22 schrieb Brian Stansberry <brian.stansberry at redhat.com>:
> 
> This is included:
> 
> https://github.com/wildfly/wildfly-core/pull/423
> 
> On 2/10/15 3:20 AM, Heiko Braun wrote:
>> Cool, that means CORS is now included, right?
>> 
>>> On 09 Feb 2015, at 19:23, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>> 
>>> The latest in our roughly weekly series of WildFly Core alphas has been
>>> released and merged into full WildFly's master branch.
>>> 
>>> --
>>> Brian Stansberry
>>> Senior Principal Software Engineer
>>> JBoss by Red Hat
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> 
> 
> 
> -- 
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

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



From brian.stansberry at redhat.com  Tue Feb 10 16:12:18 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 10 Feb 2015 15:12:18 -0600
Subject: [wildfly-dev] Embedding a WF instance in the CLI
In-Reply-To: <1734718658.5454347.1400079220862.JavaMail.zimbra@redhat.com>
References: <JIRA.12539089.1398430273000.24526.1398433475922@jira02.app.mwc.hst.phx2.redhat.com>
	<535A88CE.3010503@redhat.com> <535A8D25.5020507@redhat.com>
	<535A920E.5090607@redhat.com> <535E6DF8.1030507@redhat.com>
	<53728668.4040007@redhat.com> <5373758E.9060700@redhat.com>
	<53738129.30709@redhat.com>
	<1734718658.5454347.1400079220862.JavaMail.zimbra@redhat.com>
Message-ID: <54DA7432.8080207@redhat.com>

I had some time over the holidays and on planes to progress quite a bit 
on this. A standalone server protype is at [1]. A fairly in depth 
description is on the WildFly Development wiki at [2].

I tried pretty hard to have clean commits on that branch, one per issue 
I faced. So looking at the commits is worthwhile to get a better 
understanding of particular aspects.

Some notes on what I did / issues to discuss:

1) I semi-ported the "embedded" module from WildFly full to WildFly 
Core. "Semi" in the sense that the code is now in both places, under 
different maven GAVs and ending up in differently named modules in full. 
We need to regularize this; decide if there's any point in a "full" 
version of embedded, decide what to do about any APIs we don't want in 
the core version. (There are some deprecated methods, and one method 
"Context getContext()" that doesn't mean much in core, which has no JNDI.)

2) The CLI's use of stdio needed to be tweaked a bit to make it possible 
to control what the embedded server does with stdout. That's in the 
"Remove direct use of System.out by most CLI code" commit at [1].

3) I needed to deal with some general embedding issues in the server; 
i.e. things that would probably pop up in any embedded use case:

a) controlling the LogContext so the embedded server logging can be 
managed independent of the embedding app. See "Let apps that embed 
WildFly control the LogContext" commit at [1].

I don't think this is real solid though. For example, I expect CLI-side 
loggers that happen to get created after the embedded server starts will 
end up using the server LogContext.

b) the server was calling System.exit in some places. See "[WFCORE-528] 
Use SystemExiter, not System.exit" commit at [1].

c) the embedded server code didn't deal with reload, leaving behind a 
broken ModelControllerClient. See "[WFCORE-511] Support reload in the 
embedded server" commit at [1].

4) The modular vs non-modular environment aspects discussed at "Modular 
vs Non-Modular Classloading and JBOSS_HOME" in [2] are not ideal. I'm 
not sure how far we can/should go in improving this though.

5) This is painfully lacking in tests!

Comments and suggestions are welcome!

Cheers,
Brian

[1] https://github.com/bstansberry/wildfly-core/commits/cli-embed-server

[2] https://developer.jboss.org/docs/DOC-53050

On 5/14/14 9:53 AM, John Mazzitelli wrote:
> How topical :) The RHQ installer could use this - just this very second I'm debugging and trying to figure out why the RHQ installer can't connect to the running app server instance to do its initial config setup - having to try to figure out what port its running on and why I can't connect is a pain.
>
> ----- Original Message -----
>> Moving a thread to the dev list.
>>
>> This is about some prototyping I've been doing on weekends 'cause I'm
>> bored with my regular tasks. I've been playing with direct local
>> administration of a WF installation via the CLI without requiring a
>> socket-based connection. The general use case is initial setup type
>> activities where the user doesn't want to have to launch a WF server or
>> HC process and potentially have it be visible on the network.
>> https://issues.jboss.org/browse/WFLY-3288 is one use case; another is a
>> desire some folks have expressed in being able to do configuration
>> without first having to edit any xml to avoid port conflicts on 9990 or
>> 9999.
>>
>> This isn't a major initiative or big priority or anything at this point.
>> Just something I find interesting and perhaps you will too.
>>
>> On 5/14/14, 8:54 AM, Alexey Loubyansky wrote:
>>> Neat :) Yes, figuring out the module path is biting everywhere.
>>> For file system path command line arguments there is a specialized
>>> FileSystemPathArgument.
>>>
>>
>> Thanks; I'll switch to that.
>>
>>>
>>> On 05/13/2014 10:54 PM, Brian Stansberry wrote:
>>>> Copying Heiko Braun as he expressed some interest in the topic.
>>>>
>>>> BTW, I played with this a bit more last weekend and was able to start an
>>>> embedded server inside the CLI easily enough. See [1] for very raw
>>>> prototype stuff. You can run bin/jboss-cli.sh (no -c) and then
>>>>
>>>> [disconnected/] embed-server
>>>>
>>>> There are a couple issues I see, besides the HC stuff I mentioned in my
>>>> last message.
>>>>
>>>> 1) If the CLI is started in a non-modular environment via java -jar
>>>> bin/client/jboss-cli-client.jar, we'd have to shade jboss-modules into
>>>> the jar. And then the embed-server command would need params specifying
>>>> the location of JBOSS_HOME, possibly module path etc. But it could embed
>>>> a server installed in any accessible filesystem location.
>>>>
>>>> But what I did at [1] is based on bin/jboss-cli.sh, where the CLI is
>>>> running from a WF dist in a modular environment and the embedded server
>>>> modules are coming from the CLI's own module path. It would be more
>>>> effort to support embedding a server based on some other module path.
>>>> Maybe it's no big deal; maybe it's really hard. :)
>>>>
>>>> 2) The console logging from the embedded server goes to stdout mixed in
>>>> with the CLI output. Maybe that's good, maybe it's bad.
>>>>
>>>> [1] https://github.com/bstansberry/wildfly/tree/cli-embed
>>>>
>>>> On 4/28/14, 10:04 AM, Brian Stansberry wrote:
>>>>> I was poking around at this for an hour or so over the weekend.
>>>>>
>>>>> The standalone case seems pretty straightforward. Seems the existing
>>>>> embedded server API could work readily enough. The
>>>>> org.jboss.as.embedded.StandaloneServer interface already provides a
>>>>> ModelControllerClient.
>>>>>
>>>>> The domain case is much harder, as the CLI wants a HostController, not a
>>>>> ProcessController. I'd really like this to use an in-VM client, not a
>>>>> remote one, so I don't like having the CLI embed a PC and then the HC is
>>>>> an external process. My thoughts of the morning are to allow inverting
>>>>> the HC/PC relationship for this kind of usage. That is, remove
>>>>> controlling the HC lifecycle from the charge of the PC component. CLI
>>>>> launches HC, and then the HC creates an in-process PC-ish component (not
>>>>> a separate process) to manage the server lifecycles. There could be all
>>>>> sorts of problems with that; it's just the thought for the morning.
>>>>>
>>>>> On 4/25/14, 11:49 AM, Alexey Loubyansky wrote:
>>>>>> Embedding the AS is the best starting point to achieve that! And more
>>>>>> fun, I agree :)
>>>>>>
>>>>>> On 04/25/2014 06:28 PM, Darran Lofthouse wrote:
>>>>>>> And to think my reason for opening the Jira was just for a common
>>>>>>> way to
>>>>>>> mask password inputs where java.io.Console is not available ;-)
>>>>>>>
>>>>>>> On 25/04/14 17:09, Brian Stansberry wrote:
>>>>>>>> On 4/25/14, 10:40 AM, Alexey Loubyansky wrote:
>>>>>>>>> Wow! Indeed :)
>>>>>>>>>
>>>>>>>>> There could be an embedded scope - true, i.e. commands available
>>>>>>>>> only
>>>>>>>>> this mode, like add-user, module mgmt related stuff, etc.
>>>>>>>>
>>>>>>>> Those commands wouldn't need to be only in that mode though. The
>>>>>>>> implementation of all of them would be based in the server; the
>>>>>>>> "client"
>>>>>>>> aspect of the CLI would just use the management interface. The
>>>>>>>> difference between an embedded mode and what we have now would
>>>>>>>> just be
>>>>>>>> in how the "client" side gets its ModelControllerClient -- what we
>>>>>>>> have
>>>>>>>> now vs starting an embedded server and getting some sort of in-vm
>>>>>>>> client.
>>>>>>>>
>>>>>>>>> But it would still mean the server/controller would have to actually
>>>>>>>>> provide implementations of that functionality and expose it to the
>>>>>>>>> management tools like the CLI in the embedded mode.
>>>>>>>>
>>>>>>>> Yep.
>>>>>>>>
>>>>>>>>> I like this idea as a concept - direct local management. W/o any
>>>>>>>>> remote
>>>>>>>>> connect/re-connect/disconnect burden.
>>>>>>>>>
>>>>>>>>> Extending the CLI with custom modules is on the list too. It's
>>>>>>>>> probably
>>>>>>>>> easier to implement at this point.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Likely so, but maybe less fun. ;) I copied you on a PRD-related
>>>>>>>> thread
>>>>>>>> where I briefly get into this general area too.
>>>>>>>>
>>>>>>>>> Alexey
>>>>>>>>>
>>>>>>>>> On 04/25/2014 05:00 PM, Brian Stansberry wrote:
>>>>>>>>>> Hi Alexey,
>>>>>>>>>>
>>>>>>>>>> Wanted to point the discussion on this JIRA out to you as it gets
>>>>>>>>>> into
>>>>>>>>>> some fairly fundamental brainstorming that you may find
>>>>>>>>>> interesting.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -------- Original Message --------
>>>>>>>>>> Subject: [JBoss JIRA] (WFLY-3288) Update add-user to use AESH or
>>>>>>>>>> move it
>>>>>>>>>> into the CLI
>>>>>>>>>> Date: Fri, 25 Apr 2014 09:44:35 -0400 (EDT)
>>>>>>>>>> From: Darran Lofthouse (JIRA) <issues at jboss.org>
>>>>>>>>>> To: brian.stansberry at redhat.com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>       [
>>>>>>>>>> https://issues.jboss.org/browse/WFLY-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12963854#comment-12963854
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ]
>>>>>>>>>>
>>>>>>>>>> Darran Lofthouse commented on WFLY-3288:
>>>>>>>>>> ----------------------------------------
>>>>>>>>>>
>>>>>>>>>> That could be very interested, won't go into too much detail in
>>>>>>>>>> this
>>>>>>>>>> Jira as it is not directly related shortly I am switching to the
>>>>>>>>>> SSL
>>>>>>>>>> related tasks we have outstanding including the out of the box
>>>>>>>>>> enablement we talked about in Brno - managing an embedded instance
>>>>>>>>>> could
>>>>>>>>>> be useful there as well to get it all op based.
>>>>>>>>>>
>>>>>>>>>> I can see this task may end up coming back my way combined with the
>>>>>>>>>> other stuff ;-)
>>>>>>>>>>
>>>>>>>>>>> Update add-user to use AESH or move it into the CLI
>>>>>>>>>>> ---------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>>                  Key: WFLY-3288
>>>>>>>>>>>                  URL: https://issues.jboss.org/browse/WFLY-3288
>>>>>>>>>>>              Project: WildFly
>>>>>>>>>>>           Issue Type: Feature Request
>>>>>>>>>>>       Security Level: Public(Everyone can see)
>>>>>>>>>>>           Components: Domain Management, Scripts
>>>>>>>>>>>             Reporter: Darran Lofthouse
>>>>>>>>>>>              Fix For: Awaiting Volunteers
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Within the add-user utility it is difficult to handle situations
>>>>>>>>>>> where
>>>>>>>>>>> we do not have access to a java.io.Console which is the easiest
>>>>>>>>>>> way to
>>>>>>>>>>> handle password reading without an echo to the user e.g. in Cygwin
>>>>>>>>>>> Switching to AESH would allow us to use the implementation
>>>>>>>>>>> there to
>>>>>>>>>>> handle this.
>>>>>>>>>>> Alternatively it may actually make sense to make add-user a
>>>>>>>>>>> special
>>>>>>>>>>> mode of the CLI, we may at some point want to switch to runtime
>>>>>>>>>>> operations being executed on the server so porting to the CLI
>>>>>>>>>>> could be
>>>>>>>>>>> the first step to make this possible.
>>>>>>>>>>> Overall this is going to require further discussion so the
>>>>>>>>>>> comments
>>>>>>>>>>> here are just a starting point.
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> This message is automatically generated by JIRA.
>>>>>>>>>> If you think it was sent incorrectly, please contact your JIRA
>>>>>>>>>> administrators
>>>>>>>>>> For more information on JIRA, see:
>>>>>>>>>> http://www.atlassian.com/software/jira
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>
>>
>> --
>> Brian Stansberry
>> Senior Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>


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

From brian.stansberry at redhat.com  Tue Feb 10 16:22:11 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 10 Feb 2015 15:22:11 -0600
Subject: [wildfly-dev] Embedding a WF instance in the CLI
In-Reply-To: <54DA7432.8080207@redhat.com>
References: <JIRA.12539089.1398430273000.24526.1398433475922@jira02.app.mwc.hst.phx2.redhat.com>
	<535A88CE.3010503@redhat.com> <535A8D25.5020507@redhat.com>
	<535A920E.5090607@redhat.com> <535E6DF8.1030507@redhat.com>
	<53728668.4040007@redhat.com> <5373758E.9060700@redhat.com>
	<53738129.30709@redhat.com>
	<1734718658.5454347.1400079220862.JavaMail.zimbra@redhat.com>
	<54DA7432.8080207@redhat.com>
Message-ID: <54DA7683.6060204@redhat.com>

One other issue I forgot to mention: security

A user running the CLI this way essentially has RBAC SuperUser rights.

To use this, the user would have to have access to the local system, 
with necessary read/write filesystem permissions. Such a user would have 
other means to mess with the server config, but still, this is another.

This is somewhat like the case with $local authentication. But with 
that, the user organization can modify the config and turn of that 
authentication mechanism. Perhaps we can do something similar here; e.g. 
an "embeddable" setting in the config, which if false will cause boot 
abort in an embedded server.

On 2/10/15 3:12 PM, Brian Stansberry wrote:
> I had some time over the holidays and on planes to progress quite a bit
> on this. A standalone server protype is at [1]. A fairly in depth
> description is on the WildFly Development wiki at [2].
>
> I tried pretty hard to have clean commits on that branch, one per issue
> I faced. So looking at the commits is worthwhile to get a better
> understanding of particular aspects.
>
> Some notes on what I did / issues to discuss:
>
> 1) I semi-ported the "embedded" module from WildFly full to WildFly
> Core. "Semi" in the sense that the code is now in both places, under
> different maven GAVs and ending up in differently named modules in full.
> We need to regularize this; decide if there's any point in a "full"
> version of embedded, decide what to do about any APIs we don't want in
> the core version. (There are some deprecated methods, and one method
> "Context getContext()" that doesn't mean much in core, which has no JNDI.)
>
> 2) The CLI's use of stdio needed to be tweaked a bit to make it possible
> to control what the embedded server does with stdout. That's in the
> "Remove direct use of System.out by most CLI code" commit at [1].
>
> 3) I needed to deal with some general embedding issues in the server;
> i.e. things that would probably pop up in any embedded use case:
>
> a) controlling the LogContext so the embedded server logging can be
> managed independent of the embedding app. See "Let apps that embed
> WildFly control the LogContext" commit at [1].
>
> I don't think this is real solid though. For example, I expect CLI-side
> loggers that happen to get created after the embedded server starts will
> end up using the server LogContext.
>
> b) the server was calling System.exit in some places. See "[WFCORE-528]
> Use SystemExiter, not System.exit" commit at [1].
>
> c) the embedded server code didn't deal with reload, leaving behind a
> broken ModelControllerClient. See "[WFCORE-511] Support reload in the
> embedded server" commit at [1].
>
> 4) The modular vs non-modular environment aspects discussed at "Modular
> vs Non-Modular Classloading and JBOSS_HOME" in [2] are not ideal. I'm
> not sure how far we can/should go in improving this though.
>
> 5) This is painfully lacking in tests!
>
> Comments and suggestions are welcome!
>
> Cheers,
> Brian
>
> [1] https://github.com/bstansberry/wildfly-core/commits/cli-embed-server
>
> [2] https://developer.jboss.org/docs/DOC-53050
>
> On 5/14/14 9:53 AM, John Mazzitelli wrote:
>> How topical :) The RHQ installer could use this - just this very
>> second I'm debugging and trying to figure out why the RHQ installer
>> can't connect to the running app server instance to do its initial
>> config setup - having to try to figure out what port its running on
>> and why I can't connect is a pain.
>>
>> ----- Original Message -----
>>> Moving a thread to the dev list.
>>>
>>> This is about some prototyping I've been doing on weekends 'cause I'm
>>> bored with my regular tasks. I've been playing with direct local
>>> administration of a WF installation via the CLI without requiring a
>>> socket-based connection. The general use case is initial setup type
>>> activities where the user doesn't want to have to launch a WF server or
>>> HC process and potentially have it be visible on the network.
>>> https://issues.jboss.org/browse/WFLY-3288 is one use case; another is a
>>> desire some folks have expressed in being able to do configuration
>>> without first having to edit any xml to avoid port conflicts on 9990 or
>>> 9999.
>>>
>>> This isn't a major initiative or big priority or anything at this point.
>>> Just something I find interesting and perhaps you will too.
>>>
>>> On 5/14/14, 8:54 AM, Alexey Loubyansky wrote:
>>>> Neat :) Yes, figuring out the module path is biting everywhere.
>>>> For file system path command line arguments there is a specialized
>>>> FileSystemPathArgument.
>>>>
>>>
>>> Thanks; I'll switch to that.
>>>
>>>>
>>>> On 05/13/2014 10:54 PM, Brian Stansberry wrote:
>>>>> Copying Heiko Braun as he expressed some interest in the topic.
>>>>>
>>>>> BTW, I played with this a bit more last weekend and was able to
>>>>> start an
>>>>> embedded server inside the CLI easily enough. See [1] for very raw
>>>>> prototype stuff. You can run bin/jboss-cli.sh (no -c) and then
>>>>>
>>>>> [disconnected/] embed-server
>>>>>
>>>>> There are a couple issues I see, besides the HC stuff I mentioned
>>>>> in my
>>>>> last message.
>>>>>
>>>>> 1) If the CLI is started in a non-modular environment via java -jar
>>>>> bin/client/jboss-cli-client.jar, we'd have to shade jboss-modules into
>>>>> the jar. And then the embed-server command would need params
>>>>> specifying
>>>>> the location of JBOSS_HOME, possibly module path etc. But it could
>>>>> embed
>>>>> a server installed in any accessible filesystem location.
>>>>>
>>>>> But what I did at [1] is based on bin/jboss-cli.sh, where the CLI is
>>>>> running from a WF dist in a modular environment and the embedded
>>>>> server
>>>>> modules are coming from the CLI's own module path. It would be more
>>>>> effort to support embedding a server based on some other module path.
>>>>> Maybe it's no big deal; maybe it's really hard. :)
>>>>>
>>>>> 2) The console logging from the embedded server goes to stdout
>>>>> mixed in
>>>>> with the CLI output. Maybe that's good, maybe it's bad.
>>>>>
>>>>> [1] https://github.com/bstansberry/wildfly/tree/cli-embed
>>>>>
>>>>> On 4/28/14, 10:04 AM, Brian Stansberry wrote:
>>>>>> I was poking around at this for an hour or so over the weekend.
>>>>>>
>>>>>> The standalone case seems pretty straightforward. Seems the existing
>>>>>> embedded server API could work readily enough. The
>>>>>> org.jboss.as.embedded.StandaloneServer interface already provides a
>>>>>> ModelControllerClient.
>>>>>>
>>>>>> The domain case is much harder, as the CLI wants a HostController,
>>>>>> not a
>>>>>> ProcessController. I'd really like this to use an in-VM client, not a
>>>>>> remote one, so I don't like having the CLI embed a PC and then the
>>>>>> HC is
>>>>>> an external process. My thoughts of the morning are to allow
>>>>>> inverting
>>>>>> the HC/PC relationship for this kind of usage. That is, remove
>>>>>> controlling the HC lifecycle from the charge of the PC component. CLI
>>>>>> launches HC, and then the HC creates an in-process PC-ish
>>>>>> component (not
>>>>>> a separate process) to manage the server lifecycles. There could
>>>>>> be all
>>>>>> sorts of problems with that; it's just the thought for the morning.
>>>>>>
>>>>>> On 4/25/14, 11:49 AM, Alexey Loubyansky wrote:
>>>>>>> Embedding the AS is the best starting point to achieve that! And
>>>>>>> more
>>>>>>> fun, I agree :)
>>>>>>>
>>>>>>> On 04/25/2014 06:28 PM, Darran Lofthouse wrote:
>>>>>>>> And to think my reason for opening the Jira was just for a common
>>>>>>>> way to
>>>>>>>> mask password inputs where java.io.Console is not available ;-)
>>>>>>>>
>>>>>>>> On 25/04/14 17:09, Brian Stansberry wrote:
>>>>>>>>> On 4/25/14, 10:40 AM, Alexey Loubyansky wrote:
>>>>>>>>>> Wow! Indeed :)
>>>>>>>>>>
>>>>>>>>>> There could be an embedded scope - true, i.e. commands available
>>>>>>>>>> only
>>>>>>>>>> this mode, like add-user, module mgmt related stuff, etc.
>>>>>>>>>
>>>>>>>>> Those commands wouldn't need to be only in that mode though. The
>>>>>>>>> implementation of all of them would be based in the server; the
>>>>>>>>> "client"
>>>>>>>>> aspect of the CLI would just use the management interface. The
>>>>>>>>> difference between an embedded mode and what we have now would
>>>>>>>>> just be
>>>>>>>>> in how the "client" side gets its ModelControllerClient -- what we
>>>>>>>>> have
>>>>>>>>> now vs starting an embedded server and getting some sort of in-vm
>>>>>>>>> client.
>>>>>>>>>
>>>>>>>>>> But it would still mean the server/controller would have to
>>>>>>>>>> actually
>>>>>>>>>> provide implementations of that functionality and expose it to
>>>>>>>>>> the
>>>>>>>>>> management tools like the CLI in the embedded mode.
>>>>>>>>>
>>>>>>>>> Yep.
>>>>>>>>>
>>>>>>>>>> I like this idea as a concept - direct local management. W/o any
>>>>>>>>>> remote
>>>>>>>>>> connect/re-connect/disconnect burden.
>>>>>>>>>>
>>>>>>>>>> Extending the CLI with custom modules is on the list too. It's
>>>>>>>>>> probably
>>>>>>>>>> easier to implement at this point.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Likely so, but maybe less fun. ;) I copied you on a PRD-related
>>>>>>>>> thread
>>>>>>>>> where I briefly get into this general area too.
>>>>>>>>>
>>>>>>>>>> Alexey
>>>>>>>>>>
>>>>>>>>>> On 04/25/2014 05:00 PM, Brian Stansberry wrote:
>>>>>>>>>>> Hi Alexey,
>>>>>>>>>>>
>>>>>>>>>>> Wanted to point the discussion on this JIRA out to you as it
>>>>>>>>>>> gets
>>>>>>>>>>> into
>>>>>>>>>>> some fairly fundamental brainstorming that you may find
>>>>>>>>>>> interesting.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -------- Original Message --------
>>>>>>>>>>> Subject: [JBoss JIRA] (WFLY-3288) Update add-user to use AESH or
>>>>>>>>>>> move it
>>>>>>>>>>> into the CLI
>>>>>>>>>>> Date: Fri, 25 Apr 2014 09:44:35 -0400 (EDT)
>>>>>>>>>>> From: Darran Lofthouse (JIRA) <issues at jboss.org>
>>>>>>>>>>> To: brian.stansberry at redhat.com
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>       [
>>>>>>>>>>> https://issues.jboss.org/browse/WFLY-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12963854#comment-12963854
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ]
>>>>>>>>>>>
>>>>>>>>>>> Darran Lofthouse commented on WFLY-3288:
>>>>>>>>>>> ----------------------------------------
>>>>>>>>>>>
>>>>>>>>>>> That could be very interested, won't go into too much detail in
>>>>>>>>>>> this
>>>>>>>>>>> Jira as it is not directly related shortly I am switching to the
>>>>>>>>>>> SSL
>>>>>>>>>>> related tasks we have outstanding including the out of the box
>>>>>>>>>>> enablement we talked about in Brno - managing an embedded
>>>>>>>>>>> instance
>>>>>>>>>>> could
>>>>>>>>>>> be useful there as well to get it all op based.
>>>>>>>>>>>
>>>>>>>>>>> I can see this task may end up coming back my way combined
>>>>>>>>>>> with the
>>>>>>>>>>> other stuff ;-)
>>>>>>>>>>>
>>>>>>>>>>>> Update add-user to use AESH or move it into the CLI
>>>>>>>>>>>> ---------------------------------------------------
>>>>>>>>>>>>
>>>>>>>>>>>>                  Key: WFLY-3288
>>>>>>>>>>>>                  URL: https://issues.jboss.org/browse/WFLY-3288
>>>>>>>>>>>>              Project: WildFly
>>>>>>>>>>>>           Issue Type: Feature Request
>>>>>>>>>>>>       Security Level: Public(Everyone can see)
>>>>>>>>>>>>           Components: Domain Management, Scripts
>>>>>>>>>>>>             Reporter: Darran Lofthouse
>>>>>>>>>>>>              Fix For: Awaiting Volunteers
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Within the add-user utility it is difficult to handle
>>>>>>>>>>>> situations
>>>>>>>>>>>> where
>>>>>>>>>>>> we do not have access to a java.io.Console which is the easiest
>>>>>>>>>>>> way to
>>>>>>>>>>>> handle password reading without an echo to the user e.g. in
>>>>>>>>>>>> Cygwin
>>>>>>>>>>>> Switching to AESH would allow us to use the implementation
>>>>>>>>>>>> there to
>>>>>>>>>>>> handle this.
>>>>>>>>>>>> Alternatively it may actually make sense to make add-user a
>>>>>>>>>>>> special
>>>>>>>>>>>> mode of the CLI, we may at some point want to switch to runtime
>>>>>>>>>>>> operations being executed on the server so porting to the CLI
>>>>>>>>>>>> could be
>>>>>>>>>>>> the first step to make this possible.
>>>>>>>>>>>> Overall this is going to require further discussion so the
>>>>>>>>>>>> comments
>>>>>>>>>>>> here are just a starting point.
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> This message is automatically generated by JIRA.
>>>>>>>>>>> If you think it was sent incorrectly, please contact your JIRA
>>>>>>>>>>> administrators
>>>>>>>>>>> For more information on JIRA, see:
>>>>>>>>>>> http://www.atlassian.com/software/jira
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
>>> --
>>> Brian Stansberry
>>> Senior Principal Software Engineer
>>> JBoss by Red Hat
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>
>


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

From smarlow at redhat.com  Tue Feb 10 16:52:47 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 10 Feb 2015 16:52:47 -0500
Subject: [wildfly-dev] Moving WildFly 9 to Java 8?
In-Reply-To: <CAMquZP5kiWptkCHomSo8KthBdE-Gt-RXq0CV3MB4XsCWQt54ww@mail.gmail.com>
References: <CAMquZP74p17yOuWFtK3YXwCyA2Ps1N7bEZ4nNzwekqt0qNyCcQ@mail.gmail.com>	<54D92AC2.3090302@redhat.com>
	<54DA059B.2070706@redhat.com>
	<CAMquZP5kiWptkCHomSo8KthBdE-Gt-RXq0CV3MB4XsCWQt54ww@mail.gmail.com>
Message-ID: <54DA7DAF.4060102@redhat.com>



On 02/10/2015 08:44 AM, Toma? Cerar wrote:
>
> On Tue, Feb 10, 2015 at 2:20 PM, Dimitris Andreadis <dandread at redhat.com
> <mailto:dandread at redhat.com>> wrote:
>
>     There is also the TCK that would have to re-pass with jdk8.
>
>
>
> Absolutely, but AFAIR, we got tck update that works on Java 8.

The Java 8 TCK update is for EE 6, not EE 7.  The EE 7 TCK might also 
pass with Java 8 (we should try that independent of which Java version 
we require).

>
> Scott, can you confirm this?

 From the EE 7 platform specification:

"
EE.9.5

Requirements for All Java EE Profiles

The Java Platform, Standard Edition 7 is the required foundation for any 
Java EE 7 profile.
"

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

From tomaz.cerar at gmail.com  Tue Feb 10 17:03:36 2015
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Tue, 10 Feb 2015 23:03:36 +0100
Subject: [wildfly-dev] Moving WildFly 9 to Java 8?
In-Reply-To: <54DA7DAF.4060102@redhat.com>
References: <CAMquZP74p17yOuWFtK3YXwCyA2Ps1N7bEZ4nNzwekqt0qNyCcQ@mail.gmail.com>
	<54D92AC2.3090302@redhat.com> <54DA059B.2070706@redhat.com>
	<CAMquZP5kiWptkCHomSo8KthBdE-Gt-RXq0CV3MB4XsCWQt54ww@mail.gmail.com>
	<54DA7DAF.4060102@redhat.com>
Message-ID: <CAMquZP6suP_2Y2CMJhNV4cjDwrfCsJU3sBz4OAPt4n18Ju+v3w@mail.gmail.com>

On Tue, Feb 10, 2015 at 10:52 PM, Scott Marlow <smarlow at redhat.com> wrote:

>
> The Java 8 TCK update is for EE 6, not EE 7.  The EE 7 TCK might also pass
> with Java 8 (we should try that independent of which Java version we
> require).
>
> Aha, this is what i was interested in.
Any chance you can try with JDK8 against current master?

>
>> Scott, can you confirm this?
>>
>
> From the EE 7 platform specification:
>
> "
> EE.9.5
>
> Requirements for All Java EE Profiles
>
> The Java Platform, Standard Edition 7 is the required foundation for any
> Java EE 7 profile.

Yes, but that doesn't say that is the only version that is required.

*EE.2.4.1 Container Requirements*
"This specification requires that containers provide a Java Compatible?
runtime environment, as defined by the Java Platform, Standard Edition, v7
specification (Java SE)."

Which means any Java runtime that is compatible with v7 is fine, and as far
as we know 8 is backward compatible, as it provides all v7 does and more.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150210/bcf18709/attachment.html 

From hbraun at redhat.com  Wed Feb 11 01:49:48 2015
From: hbraun at redhat.com (Heiko Braun)
Date: Wed, 11 Feb 2015 07:49:48 +0100
Subject: [wildfly-dev] Embedding a WF instance in the CLI
In-Reply-To: <54DA7432.8080207@redhat.com>
References: <JIRA.12539089.1398430273000.24526.1398433475922@jira02.app.mwc.hst.phx2.redhat.com>
	<535A88CE.3010503@redhat.com> <535A8D25.5020507@redhat.com>
	<535A920E.5090607@redhat.com> <535E6DF8.1030507@redhat.com>
	<53728668.4040007@redhat.com> <5373758E.9060700@redhat.com>
	<53738129.30709@redhat.com>
	<1734718658.5454347.1400079220862.JavaMail.zimbra@redhat.com>
	<54DA7432.8080207@redhat.com>
Message-ID: <9C8CD903-88E3-4525-A610-BC05DE0DC171@redhat.com>

What's again the rational behind this? 




> Am 10.02.2015 um 22:12 schrieb Brian Stansberry <brian.stansberry at redhat.com>:
> 
> I had some time over the holidays and on planes to progress quite a bit 
> on this. A standalone server protype is at [1]. A fairly in depth 
> description is on the WildFly Development wiki at [2].
> 
> I tried pretty hard to have clean commits on that branch, one per issue 
> I faced. So looking at the commits is worthwhile to get a better 
> understanding of particular aspects.
> 
> Some notes on what I did / issues to discuss:
> 
> 1) I semi-ported the "embedded" module from WildFly full to WildFly 
> Core. "Semi" in the sense that the code is now in both places, under 
> different maven GAVs and ending up in differently named modules in full. 
> We need to regularize this; decide if there's any point in a "full" 
> version of embedded, decide what to do about any APIs we don't want in 
> the core version. (There are some deprecated methods, and one method 
> "Context getContext()" that doesn't mean much in core, which has no JNDI.)
> 
> 2) The CLI's use of stdio needed to be tweaked a bit to make it possible 
> to control what the embedded server does with stdout. That's in the 
> "Remove direct use of System.out by most CLI code" commit at [1].
> 
> 3) I needed to deal with some general embedding issues in the server; 
> i.e. things that would probably pop up in any embedded use case:
> 
> a) controlling the LogContext so the embedded server logging can be 
> managed independent of the embedding app. See "Let apps that embed 
> WildFly control the LogContext" commit at [1].
> 
> I don't think this is real solid though. For example, I expect CLI-side 
> loggers that happen to get created after the embedded server starts will 
> end up using the server LogContext.
> 
> b) the server was calling System.exit in some places. See "[WFCORE-528] 
> Use SystemExiter, not System.exit" commit at [1].
> 
> c) the embedded server code didn't deal with reload, leaving behind a 
> broken ModelControllerClient. See "[WFCORE-511] Support reload in the 
> embedded server" commit at [1].
> 
> 4) The modular vs non-modular environment aspects discussed at "Modular 
> vs Non-Modular Classloading and JBOSS_HOME" in [2] are not ideal. I'm 
> not sure how far we can/should go in improving this though.
> 
> 5) This is painfully lacking in tests!
> 
> Comments and suggestions are welcome!
> 
> Cheers,
> Brian
> 
> [1] https://github.com/bstansberry/wildfly-core/commits/cli-embed-server
> 
> [2] https://developer.jboss.org/docs/DOC-53050
> 
>> On 5/14/14 9:53 AM, John Mazzitelli wrote:
>> How topical :) The RHQ installer could use this - just this very second I'm debugging and trying to figure out why the RHQ installer can't connect to the running app server instance to do its initial config setup - having to try to figure out what port its running on and why I can't connect is a pain.
>> 
>> ----- Original Message -----
>>> Moving a thread to the dev list.
>>> 
>>> This is about some prototyping I've been doing on weekends 'cause I'm
>>> bored with my regular tasks. I've been playing with direct local
>>> administration of a WF installation via the CLI without requiring a
>>> socket-based connection. The general use case is initial setup type
>>> activities where the user doesn't want to have to launch a WF server or
>>> HC process and potentially have it be visible on the network.
>>> https://issues.jboss.org/browse/WFLY-3288 is one use case; another is a
>>> desire some folks have expressed in being able to do configuration
>>> without first having to edit any xml to avoid port conflicts on 9990 or
>>> 9999.
>>> 
>>> This isn't a major initiative or big priority or anything at this point.
>>> Just something I find interesting and perhaps you will too.
>>> 
>>>> On 5/14/14, 8:54 AM, Alexey Loubyansky wrote:
>>>> Neat :) Yes, figuring out the module path is biting everywhere.
>>>> For file system path command line arguments there is a specialized
>>>> FileSystemPathArgument.
>>> 
>>> Thanks; I'll switch to that.
>>> 
>>>> 
>>>>> On 05/13/2014 10:54 PM, Brian Stansberry wrote:
>>>>> Copying Heiko Braun as he expressed some interest in the topic.
>>>>> 
>>>>> BTW, I played with this a bit more last weekend and was able to start an
>>>>> embedded server inside the CLI easily enough. See [1] for very raw
>>>>> prototype stuff. You can run bin/jboss-cli.sh (no -c) and then
>>>>> 
>>>>> [disconnected/] embed-server
>>>>> 
>>>>> There are a couple issues I see, besides the HC stuff I mentioned in my
>>>>> last message.
>>>>> 
>>>>> 1) If the CLI is started in a non-modular environment via java -jar
>>>>> bin/client/jboss-cli-client.jar, we'd have to shade jboss-modules into
>>>>> the jar. And then the embed-server command would need params specifying
>>>>> the location of JBOSS_HOME, possibly module path etc. But it could embed
>>>>> a server installed in any accessible filesystem location.
>>>>> 
>>>>> But what I did at [1] is based on bin/jboss-cli.sh, where the CLI is
>>>>> running from a WF dist in a modular environment and the embedded server
>>>>> modules are coming from the CLI's own module path. It would be more
>>>>> effort to support embedding a server based on some other module path.
>>>>> Maybe it's no big deal; maybe it's really hard. :)
>>>>> 
>>>>> 2) The console logging from the embedded server goes to stdout mixed in
>>>>> with the CLI output. Maybe that's good, maybe it's bad.
>>>>> 
>>>>> [1] https://github.com/bstansberry/wildfly/tree/cli-embed
>>>>> 
>>>>>> On 4/28/14, 10:04 AM, Brian Stansberry wrote:
>>>>>> I was poking around at this for an hour or so over the weekend.
>>>>>> 
>>>>>> The standalone case seems pretty straightforward. Seems the existing
>>>>>> embedded server API could work readily enough. The
>>>>>> org.jboss.as.embedded.StandaloneServer interface already provides a
>>>>>> ModelControllerClient.
>>>>>> 
>>>>>> The domain case is much harder, as the CLI wants a HostController, not a
>>>>>> ProcessController. I'd really like this to use an in-VM client, not a
>>>>>> remote one, so I don't like having the CLI embed a PC and then the HC is
>>>>>> an external process. My thoughts of the morning are to allow inverting
>>>>>> the HC/PC relationship for this kind of usage. That is, remove
>>>>>> controlling the HC lifecycle from the charge of the PC component. CLI
>>>>>> launches HC, and then the HC creates an in-process PC-ish component (not
>>>>>> a separate process) to manage the server lifecycles. There could be all
>>>>>> sorts of problems with that; it's just the thought for the morning.
>>>>>> 
>>>>>>> On 4/25/14, 11:49 AM, Alexey Loubyansky wrote:
>>>>>>> Embedding the AS is the best starting point to achieve that! And more
>>>>>>> fun, I agree :)
>>>>>>> 
>>>>>>>> On 04/25/2014 06:28 PM, Darran Lofthouse wrote:
>>>>>>>> And to think my reason for opening the Jira was just for a common
>>>>>>>> way to
>>>>>>>> mask password inputs where java.io.Console is not available ;-)
>>>>>>>> 
>>>>>>>>> On 25/04/14 17:09, Brian Stansberry wrote:
>>>>>>>>>> On 4/25/14, 10:40 AM, Alexey Loubyansky wrote:
>>>>>>>>>> Wow! Indeed :)
>>>>>>>>>> 
>>>>>>>>>> There could be an embedded scope - true, i.e. commands available
>>>>>>>>>> only
>>>>>>>>>> this mode, like add-user, module mgmt related stuff, etc.
>>>>>>>>> 
>>>>>>>>> Those commands wouldn't need to be only in that mode though. The
>>>>>>>>> implementation of all of them would be based in the server; the
>>>>>>>>> "client"
>>>>>>>>> aspect of the CLI would just use the management interface. The
>>>>>>>>> difference between an embedded mode and what we have now would
>>>>>>>>> just be
>>>>>>>>> in how the "client" side gets its ModelControllerClient -- what we
>>>>>>>>> have
>>>>>>>>> now vs starting an embedded server and getting some sort of in-vm
>>>>>>>>> client.
>>>>>>>>> 
>>>>>>>>>> But it would still mean the server/controller would have to actually
>>>>>>>>>> provide implementations of that functionality and expose it to the
>>>>>>>>>> management tools like the CLI in the embedded mode.
>>>>>>>>> 
>>>>>>>>> Yep.
>>>>>>>>> 
>>>>>>>>>> I like this idea as a concept - direct local management. W/o any
>>>>>>>>>> remote
>>>>>>>>>> connect/re-connect/disconnect burden.
>>>>>>>>>> 
>>>>>>>>>> Extending the CLI with custom modules is on the list too. It's
>>>>>>>>>> probably
>>>>>>>>>> easier to implement at this point.
>>>>>>>>> 
>>>>>>>>> Likely so, but maybe less fun. ;) I copied you on a PRD-related
>>>>>>>>> thread
>>>>>>>>> where I briefly get into this general area too.
>>>>>>>>> 
>>>>>>>>>> Alexey
>>>>>>>>>> 
>>>>>>>>>>> On 04/25/2014 05:00 PM, Brian Stansberry wrote:
>>>>>>>>>>> Hi Alexey,
>>>>>>>>>>> 
>>>>>>>>>>> Wanted to point the discussion on this JIRA out to you as it gets
>>>>>>>>>>> into
>>>>>>>>>>> some fairly fundamental brainstorming that you may find
>>>>>>>>>>> interesting.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> -------- Original Message --------
>>>>>>>>>>> Subject: [JBoss JIRA] (WFLY-3288) Update add-user to use AESH or
>>>>>>>>>>> move it
>>>>>>>>>>> into the CLI
>>>>>>>>>>> Date: Fri, 25 Apr 2014 09:44:35 -0400 (EDT)
>>>>>>>>>>> From: Darran Lofthouse (JIRA) <issues at jboss.org>
>>>>>>>>>>> To: brian.stansberry at redhat.com
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>      [
>>>>>>>>>>> https://issues.jboss.org/browse/WFLY-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12963854#comment-12963854
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> ]
>>>>>>>>>>> 
>>>>>>>>>>> Darran Lofthouse commented on WFLY-3288:
>>>>>>>>>>> ----------------------------------------
>>>>>>>>>>> 
>>>>>>>>>>> That could be very interested, won't go into too much detail in
>>>>>>>>>>> this
>>>>>>>>>>> Jira as it is not directly related shortly I am switching to the
>>>>>>>>>>> SSL
>>>>>>>>>>> related tasks we have outstanding including the out of the box
>>>>>>>>>>> enablement we talked about in Brno - managing an embedded instance
>>>>>>>>>>> could
>>>>>>>>>>> be useful there as well to get it all op based.
>>>>>>>>>>> 
>>>>>>>>>>> I can see this task may end up coming back my way combined with the
>>>>>>>>>>> other stuff ;-)
>>>>>>>>>>> 
>>>>>>>>>>>> Update add-user to use AESH or move it into the CLI
>>>>>>>>>>>> ---------------------------------------------------
>>>>>>>>>>>> 
>>>>>>>>>>>>                 Key: WFLY-3288
>>>>>>>>>>>>                 URL: https://issues.jboss.org/browse/WFLY-3288
>>>>>>>>>>>>             Project: WildFly
>>>>>>>>>>>>          Issue Type: Feature Request
>>>>>>>>>>>>      Security Level: Public(Everyone can see)
>>>>>>>>>>>>          Components: Domain Management, Scripts
>>>>>>>>>>>>            Reporter: Darran Lofthouse
>>>>>>>>>>>>             Fix For: Awaiting Volunteers
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Within the add-user utility it is difficult to handle situations
>>>>>>>>>>>> where
>>>>>>>>>>>> we do not have access to a java.io.Console which is the easiest
>>>>>>>>>>>> way to
>>>>>>>>>>>> handle password reading without an echo to the user e.g. in Cygwin
>>>>>>>>>>>> Switching to AESH would allow us to use the implementation
>>>>>>>>>>>> there to
>>>>>>>>>>>> handle this.
>>>>>>>>>>>> Alternatively it may actually make sense to make add-user a
>>>>>>>>>>>> special
>>>>>>>>>>>> mode of the CLI, we may at some point want to switch to runtime
>>>>>>>>>>>> operations being executed on the server so porting to the CLI
>>>>>>>>>>>> could be
>>>>>>>>>>>> the first step to make this possible.
>>>>>>>>>>>> Overall this is going to require further discussion so the
>>>>>>>>>>>> comments
>>>>>>>>>>>> here are just a starting point.
>>>>>>>>>>> 
>>>>>>>>>>> --
>>>>>>>>>>> This message is automatically generated by JIRA.
>>>>>>>>>>> If you think it was sent incorrectly, please contact your JIRA
>>>>>>>>>>> administrators
>>>>>>>>>>> For more information on JIRA, see:
>>>>>>>>>>> http://www.atlassian.com/software/jira
>>> 
>>> 
>>> --
>>> Brian Stansberry
>>> Senior Principal Software Engineer
>>> JBoss by Red Hat
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> 
> -- 
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From ehugonne at redhat.com  Wed Feb 11 03:51:07 2015
From: ehugonne at redhat.com (Emmanuel Hugonnet)
Date: Wed, 11 Feb 2015 09:51:07 +0100
Subject: [wildfly-dev] WildFly Core Alpha17 released
In-Reply-To: <89ED1C2E-016E-48C8-B4EB-B51D91018741@redhat.com>
References: <54D8FB3A.7000903@redhat.com>	<AA5D9C65-E188-4143-ADFA-C70ED665A4A6@redhat.com>	<54DA1411.6040102@redhat.com>
	<89ED1C2E-016E-48C8-B4EB-B51D91018741@redhat.com>
Message-ID: <54DB17FB.5050309@redhat.com>

There is a bug with the port being set twice on the default origin (WFCORE-536 fixes it and makes the origin matching more resilient by
sanitizing the default port number).
In the meanwhile a 'simple' workaround is to add http://localhost:9990 in the allowed origins list.
Cheers,
Emmmanuel

Le 10/02/2015 18:00, Harald Pehl a ?crit :
> Great we finally have CORS support. However the defaults for allowed origins are missing. I filed [1] to address this. 
> 
> [1] https://issues.jboss.org/browse/WFCORE-535
> 
>> Am 10.02.2015 um 15:22 schrieb Brian Stansberry <brian.stansberry at redhat.com>:
>>
>> This is included:
>>
>> https://github.com/wildfly/wildfly-core/pull/423
>>
>> On 2/10/15 3:20 AM, Heiko Braun wrote:
>>> Cool, that means CORS is now included, right?
>>>
>>>> On 09 Feb 2015, at 19:23, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>>>
>>>> The latest in our roughly weekly series of WildFly Core alphas has been
>>>> released and merged into full WildFly's master branch.
>>>>
>>>> --
>>>> Brian Stansberry
>>>> Senior Principal Software Engineer
>>>> JBoss by Red Hat
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>
>> -- 
>> Brian Stansberry
>> Senior Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> ---
> Harald Pehl
> JBoss by Red Hat
> http://hpehl.info
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 

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

From cdewolf at redhat.com  Wed Feb 11 05:50:26 2015
From: cdewolf at redhat.com (Carlo de Wolf)
Date: Wed, 11 Feb 2015 11:50:26 +0100
Subject: [wildfly-dev] Moving WildFly 9 to Java 8?
In-Reply-To: <CAMquZP6suP_2Y2CMJhNV4cjDwrfCsJU3sBz4OAPt4n18Ju+v3w@mail.gmail.com>
References: <CAMquZP74p17yOuWFtK3YXwCyA2Ps1N7bEZ4nNzwekqt0qNyCcQ@mail.gmail.com>	<54D92AC2.3090302@redhat.com>
	<54DA059B.2070706@redhat.com>	<CAMquZP5kiWptkCHomSo8KthBdE-Gt-RXq0CV3MB4XsCWQt54ww@mail.gmail.com>	<54DA7DAF.4060102@redhat.com>
	<CAMquZP6suP_2Y2CMJhNV4cjDwrfCsJU3sBz4OAPt4n18Ju+v3w@mail.gmail.com>
Message-ID: <54DB33F2.20108@redhat.com>

On 02/10/2015 11:03 PM, Toma? Cerar wrote:
>
> On Tue, Feb 10, 2015 at 10:52 PM, Scott Marlow <smarlow at redhat.com 
> <mailto:smarlow at redhat.com>> wrote:
>
>
>     The Java 8 TCK update is for EE 6, not EE 7.  The EE 7 TCK might
>     also pass with Java 8 (we should try that independent of which
>     Java version we require).
>
> Aha, this is what i was interested in.
> Any chance you can try with JDK8 against current master?
>
>
>         Scott, can you confirm this?
>
>
>     >From the EE 7 platform specification:
>
>     "
>     EE.9.5
>
>     Requirements for All Java EE Profiles
>
>     The Java Platform, Standard Edition 7 is the required foundation
>     for any Java EE 7 profile.
>
> Yes, but that doesn't say that is the only version that is required.
>
> *EE.2.4.1 Container Requirements*
> "This specification requires that containers provide a Java 
> Compatible? runtime environment, as defined by the Java Platform, 
> Standard Edition, v7 specification (Java SE)."
>
> Which means any Java runtime that is compatible with v7 is fine, and 
> as far as we know 8 is backward compatible, as it provides all v7 does 
> and more.
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
[carlo at palantir tmp]$ /opt/oracle/jdk1.8.0/bin/javac -target 1.8 
HelloWorld.java
[carlo at palantir tmp]$ /opt/oracle/jdk1.7.0/bin/java HelloWorld
Exception in thread "main" java.lang.UnsupportedClassVersionError: 
HelloWorld : Unsupported major.minor version 52.0

Crock... :-)

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

From tomaz.cerar at gmail.com  Wed Feb 11 07:34:38 2015
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Wed, 11 Feb 2015 13:34:38 +0100
Subject: [wildfly-dev] Moving WildFly 9 to Java 8?
In-Reply-To: <54DB33F2.20108@redhat.com>
References: <CAMquZP74p17yOuWFtK3YXwCyA2Ps1N7bEZ4nNzwekqt0qNyCcQ@mail.gmail.com>
	<54D92AC2.3090302@redhat.com> <54DA059B.2070706@redhat.com>
	<CAMquZP5kiWptkCHomSo8KthBdE-Gt-RXq0CV3MB4XsCWQt54ww@mail.gmail.com>
	<54DA7DAF.4060102@redhat.com>
	<CAMquZP6suP_2Y2CMJhNV4cjDwrfCsJU3sBz4OAPt4n18Ju+v3w@mail.gmail.com>
	<54DB33F2.20108@redhat.com>
Message-ID: <CAMquZP6gY65FGWDeoyrqjHAtmR6m_jJ8d3MAaUdqCoxca4NGXg@mail.gmail.com>

On Wed, Feb 11, 2015 at 11:50 AM, Carlo de Wolf <cdewolf at redhat.com> wrote:

> [carlo at palantir tmp]$ /opt/oracle/jdk1.8.0/bin/javac -target 1.8
> HelloWorld.java
> [carlo at palantir tmp]$ /opt/oracle/jdk1.7.0/bin/java HelloWorld
> Exception in thread "main" java.lang.UnsupportedClassVersionError:
> HelloWorld : Unsupported major.minor version 52.0
>
> Crock... :-)
>


Yes my wording was bad, JDK8 supports all JDK7 constructs and more, not
other way around.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150211/a853a0a5/attachment.html 

From darran.lofthouse at jboss.com  Wed Feb 11 09:47:46 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Wed, 11 Feb 2015 14:47:46 +0000
Subject: [wildfly-dev] Embedding a WF instance in the CLI
In-Reply-To: <54DA7683.6060204@redhat.com>
References: <JIRA.12539089.1398430273000.24526.1398433475922@jira02.app.mwc.hst.phx2.redhat.com>
	<535A88CE.3010503@redhat.com> <535A8D25.5020507@redhat.com>
	<535A920E.5090607@redhat.com> <535E6DF8.1030507@redhat.com>
	<53728668.4040007@redhat.com> <5373758E.9060700@redhat.com>
	<53738129.30709@redhat.com>
	<1734718658.5454347.1400079220862.JavaMail.zimbra@redhat.com>
	<54DA7432.8080207@redhat.com> <54DA7683.6060204@redhat.com>
Message-ID: <54DB6B92.6090007@jboss.com>

TBH that sounds correct, if a user should not have super user access 
they should not have read/write access to the server configuration 
anyway and to run the server they have that access.

IMO embedded in CLI is just an alternative way to edit the config file 
and editing that config directly is super user access.

The $local authentication mechanism can still be configured with 
appropriate file system permissions so that other users on the same 
machine can auth locally with reduced permissions but for that to be 
effective those users should not have read/write access to the actual 
config.

Regards,
Darran Lofthouse.


On 10/02/15 21:22, Brian Stansberry wrote:
> One other issue I forgot to mention: security
>
> A user running the CLI this way essentially has RBAC SuperUser rights.
>
> To use this, the user would have to have access to the local system,
> with necessary read/write filesystem permissions. Such a user would have
> other means to mess with the server config, but still, this is another.
>
> This is somewhat like the case with $local authentication. But with
> that, the user organization can modify the config and turn of that
> authentication mechanism. Perhaps we can do something similar here; e.g.
> an "embeddable" setting in the config, which if false will cause boot
> abort in an embedded server.
>
> On 2/10/15 3:12 PM, Brian Stansberry wrote:
>> I had some time over the holidays and on planes to progress quite a bit
>> on this. A standalone server protype is at [1]. A fairly in depth
>> description is on the WildFly Development wiki at [2].
>>
>> I tried pretty hard to have clean commits on that branch, one per issue
>> I faced. So looking at the commits is worthwhile to get a better
>> understanding of particular aspects.
>>
>> Some notes on what I did / issues to discuss:
>>
>> 1) I semi-ported the "embedded" module from WildFly full to WildFly
>> Core. "Semi" in the sense that the code is now in both places, under
>> different maven GAVs and ending up in differently named modules in full.
>> We need to regularize this; decide if there's any point in a "full"
>> version of embedded, decide what to do about any APIs we don't want in
>> the core version. (There are some deprecated methods, and one method
>> "Context getContext()" that doesn't mean much in core, which has no
>> JNDI.)
>>
>> 2) The CLI's use of stdio needed to be tweaked a bit to make it possible
>> to control what the embedded server does with stdout. That's in the
>> "Remove direct use of System.out by most CLI code" commit at [1].
>>
>> 3) I needed to deal with some general embedding issues in the server;
>> i.e. things that would probably pop up in any embedded use case:
>>
>> a) controlling the LogContext so the embedded server logging can be
>> managed independent of the embedding app. See "Let apps that embed
>> WildFly control the LogContext" commit at [1].
>>
>> I don't think this is real solid though. For example, I expect CLI-side
>> loggers that happen to get created after the embedded server starts will
>> end up using the server LogContext.
>>
>> b) the server was calling System.exit in some places. See "[WFCORE-528]
>> Use SystemExiter, not System.exit" commit at [1].
>>
>> c) the embedded server code didn't deal with reload, leaving behind a
>> broken ModelControllerClient. See "[WFCORE-511] Support reload in the
>> embedded server" commit at [1].
>>
>> 4) The modular vs non-modular environment aspects discussed at "Modular
>> vs Non-Modular Classloading and JBOSS_HOME" in [2] are not ideal. I'm
>> not sure how far we can/should go in improving this though.
>>
>> 5) This is painfully lacking in tests!
>>
>> Comments and suggestions are welcome!
>>
>> Cheers,
>> Brian
>>
>> [1] https://github.com/bstansberry/wildfly-core/commits/cli-embed-server
>>
>> [2] https://developer.jboss.org/docs/DOC-53050
>>
>> On 5/14/14 9:53 AM, John Mazzitelli wrote:
>>> How topical :) The RHQ installer could use this - just this very
>>> second I'm debugging and trying to figure out why the RHQ installer
>>> can't connect to the running app server instance to do its initial
>>> config setup - having to try to figure out what port its running on
>>> and why I can't connect is a pain.
>>>
>>> ----- Original Message -----
>>>> Moving a thread to the dev list.
>>>>
>>>> This is about some prototyping I've been doing on weekends 'cause I'm
>>>> bored with my regular tasks. I've been playing with direct local
>>>> administration of a WF installation via the CLI without requiring a
>>>> socket-based connection. The general use case is initial setup type
>>>> activities where the user doesn't want to have to launch a WF server or
>>>> HC process and potentially have it be visible on the network.
>>>> https://issues.jboss.org/browse/WFLY-3288 is one use case; another is a
>>>> desire some folks have expressed in being able to do configuration
>>>> without first having to edit any xml to avoid port conflicts on 9990 or
>>>> 9999.
>>>>
>>>> This isn't a major initiative or big priority or anything at this
>>>> point.
>>>> Just something I find interesting and perhaps you will too.
>>>>
>>>> On 5/14/14, 8:54 AM, Alexey Loubyansky wrote:
>>>>> Neat :) Yes, figuring out the module path is biting everywhere.
>>>>> For file system path command line arguments there is a specialized
>>>>> FileSystemPathArgument.
>>>>>
>>>>
>>>> Thanks; I'll switch to that.
>>>>
>>>>>
>>>>> On 05/13/2014 10:54 PM, Brian Stansberry wrote:
>>>>>> Copying Heiko Braun as he expressed some interest in the topic.
>>>>>>
>>>>>> BTW, I played with this a bit more last weekend and was able to
>>>>>> start an
>>>>>> embedded server inside the CLI easily enough. See [1] for very raw
>>>>>> prototype stuff. You can run bin/jboss-cli.sh (no -c) and then
>>>>>>
>>>>>> [disconnected/] embed-server
>>>>>>
>>>>>> There are a couple issues I see, besides the HC stuff I mentioned
>>>>>> in my
>>>>>> last message.
>>>>>>
>>>>>> 1) If the CLI is started in a non-modular environment via java -jar
>>>>>> bin/client/jboss-cli-client.jar, we'd have to shade jboss-modules
>>>>>> into
>>>>>> the jar. And then the embed-server command would need params
>>>>>> specifying
>>>>>> the location of JBOSS_HOME, possibly module path etc. But it could
>>>>>> embed
>>>>>> a server installed in any accessible filesystem location.
>>>>>>
>>>>>> But what I did at [1] is based on bin/jboss-cli.sh, where the CLI is
>>>>>> running from a WF dist in a modular environment and the embedded
>>>>>> server
>>>>>> modules are coming from the CLI's own module path. It would be more
>>>>>> effort to support embedding a server based on some other module path.
>>>>>> Maybe it's no big deal; maybe it's really hard. :)
>>>>>>
>>>>>> 2) The console logging from the embedded server goes to stdout
>>>>>> mixed in
>>>>>> with the CLI output. Maybe that's good, maybe it's bad.
>>>>>>
>>>>>> [1] https://github.com/bstansberry/wildfly/tree/cli-embed
>>>>>>
>>>>>> On 4/28/14, 10:04 AM, Brian Stansberry wrote:
>>>>>>> I was poking around at this for an hour or so over the weekend.
>>>>>>>
>>>>>>> The standalone case seems pretty straightforward. Seems the existing
>>>>>>> embedded server API could work readily enough. The
>>>>>>> org.jboss.as.embedded.StandaloneServer interface already provides a
>>>>>>> ModelControllerClient.
>>>>>>>
>>>>>>> The domain case is much harder, as the CLI wants a HostController,
>>>>>>> not a
>>>>>>> ProcessController. I'd really like this to use an in-VM client,
>>>>>>> not a
>>>>>>> remote one, so I don't like having the CLI embed a PC and then the
>>>>>>> HC is
>>>>>>> an external process. My thoughts of the morning are to allow
>>>>>>> inverting
>>>>>>> the HC/PC relationship for this kind of usage. That is, remove
>>>>>>> controlling the HC lifecycle from the charge of the PC component.
>>>>>>> CLI
>>>>>>> launches HC, and then the HC creates an in-process PC-ish
>>>>>>> component (not
>>>>>>> a separate process) to manage the server lifecycles. There could
>>>>>>> be all
>>>>>>> sorts of problems with that; it's just the thought for the morning.
>>>>>>>
>>>>>>> On 4/25/14, 11:49 AM, Alexey Loubyansky wrote:
>>>>>>>> Embedding the AS is the best starting point to achieve that! And
>>>>>>>> more
>>>>>>>> fun, I agree :)
>>>>>>>>
>>>>>>>> On 04/25/2014 06:28 PM, Darran Lofthouse wrote:
>>>>>>>>> And to think my reason for opening the Jira was just for a common
>>>>>>>>> way to
>>>>>>>>> mask password inputs where java.io.Console is not available ;-)
>>>>>>>>>
>>>>>>>>> On 25/04/14 17:09, Brian Stansberry wrote:
>>>>>>>>>> On 4/25/14, 10:40 AM, Alexey Loubyansky wrote:
>>>>>>>>>>> Wow! Indeed :)
>>>>>>>>>>>
>>>>>>>>>>> There could be an embedded scope - true, i.e. commands available
>>>>>>>>>>> only
>>>>>>>>>>> this mode, like add-user, module mgmt related stuff, etc.
>>>>>>>>>>
>>>>>>>>>> Those commands wouldn't need to be only in that mode though. The
>>>>>>>>>> implementation of all of them would be based in the server; the
>>>>>>>>>> "client"
>>>>>>>>>> aspect of the CLI would just use the management interface. The
>>>>>>>>>> difference between an embedded mode and what we have now would
>>>>>>>>>> just be
>>>>>>>>>> in how the "client" side gets its ModelControllerClient --
>>>>>>>>>> what we
>>>>>>>>>> have
>>>>>>>>>> now vs starting an embedded server and getting some sort of in-vm
>>>>>>>>>> client.
>>>>>>>>>>
>>>>>>>>>>> But it would still mean the server/controller would have to
>>>>>>>>>>> actually
>>>>>>>>>>> provide implementations of that functionality and expose it to
>>>>>>>>>>> the
>>>>>>>>>>> management tools like the CLI in the embedded mode.
>>>>>>>>>>
>>>>>>>>>> Yep.
>>>>>>>>>>
>>>>>>>>>>> I like this idea as a concept - direct local management. W/o any
>>>>>>>>>>> remote
>>>>>>>>>>> connect/re-connect/disconnect burden.
>>>>>>>>>>>
>>>>>>>>>>> Extending the CLI with custom modules is on the list too. It's
>>>>>>>>>>> probably
>>>>>>>>>>> easier to implement at this point.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Likely so, but maybe less fun. ;) I copied you on a PRD-related
>>>>>>>>>> thread
>>>>>>>>>> where I briefly get into this general area too.
>>>>>>>>>>
>>>>>>>>>>> Alexey
>>>>>>>>>>>
>>>>>>>>>>> On 04/25/2014 05:00 PM, Brian Stansberry wrote:
>>>>>>>>>>>> Hi Alexey,
>>>>>>>>>>>>
>>>>>>>>>>>> Wanted to point the discussion on this JIRA out to you as it
>>>>>>>>>>>> gets
>>>>>>>>>>>> into
>>>>>>>>>>>> some fairly fundamental brainstorming that you may find
>>>>>>>>>>>> interesting.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -------- Original Message --------
>>>>>>>>>>>> Subject: [JBoss JIRA] (WFLY-3288) Update add-user to use
>>>>>>>>>>>> AESH or
>>>>>>>>>>>> move it
>>>>>>>>>>>> into the CLI
>>>>>>>>>>>> Date: Fri, 25 Apr 2014 09:44:35 -0400 (EDT)
>>>>>>>>>>>> From: Darran Lofthouse (JIRA) <issues at jboss.org>
>>>>>>>>>>>> To: brian.stansberry at redhat.com
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>       [
>>>>>>>>>>>> https://issues.jboss.org/browse/WFLY-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12963854#comment-12963854
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ]
>>>>>>>>>>>>
>>>>>>>>>>>> Darran Lofthouse commented on WFLY-3288:
>>>>>>>>>>>> ----------------------------------------
>>>>>>>>>>>>
>>>>>>>>>>>> That could be very interested, won't go into too much detail in
>>>>>>>>>>>> this
>>>>>>>>>>>> Jira as it is not directly related shortly I am switching to
>>>>>>>>>>>> the
>>>>>>>>>>>> SSL
>>>>>>>>>>>> related tasks we have outstanding including the out of the box
>>>>>>>>>>>> enablement we talked about in Brno - managing an embedded
>>>>>>>>>>>> instance
>>>>>>>>>>>> could
>>>>>>>>>>>> be useful there as well to get it all op based.
>>>>>>>>>>>>
>>>>>>>>>>>> I can see this task may end up coming back my way combined
>>>>>>>>>>>> with the
>>>>>>>>>>>> other stuff ;-)
>>>>>>>>>>>>
>>>>>>>>>>>>> Update add-user to use AESH or move it into the CLI
>>>>>>>>>>>>> ---------------------------------------------------
>>>>>>>>>>>>>
>>>>>>>>>>>>>                  Key: WFLY-3288
>>>>>>>>>>>>>                  URL:
>>>>>>>>>>>>> https://issues.jboss.org/browse/WFLY-3288
>>>>>>>>>>>>>              Project: WildFly
>>>>>>>>>>>>>           Issue Type: Feature Request
>>>>>>>>>>>>>       Security Level: Public(Everyone can see)
>>>>>>>>>>>>>           Components: Domain Management, Scripts
>>>>>>>>>>>>>             Reporter: Darran Lofthouse
>>>>>>>>>>>>>              Fix For: Awaiting Volunteers
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Within the add-user utility it is difficult to handle
>>>>>>>>>>>>> situations
>>>>>>>>>>>>> where
>>>>>>>>>>>>> we do not have access to a java.io.Console which is the
>>>>>>>>>>>>> easiest
>>>>>>>>>>>>> way to
>>>>>>>>>>>>> handle password reading without an echo to the user e.g. in
>>>>>>>>>>>>> Cygwin
>>>>>>>>>>>>> Switching to AESH would allow us to use the implementation
>>>>>>>>>>>>> there to
>>>>>>>>>>>>> handle this.
>>>>>>>>>>>>> Alternatively it may actually make sense to make add-user a
>>>>>>>>>>>>> special
>>>>>>>>>>>>> mode of the CLI, we may at some point want to switch to
>>>>>>>>>>>>> runtime
>>>>>>>>>>>>> operations being executed on the server so porting to the CLI
>>>>>>>>>>>>> could be
>>>>>>>>>>>>> the first step to make this possible.
>>>>>>>>>>>>> Overall this is going to require further discussion so the
>>>>>>>>>>>>> comments
>>>>>>>>>>>>> here are just a starting point.
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> This message is automatically generated by JIRA.
>>>>>>>>>>>> If you think it was sent incorrectly, please contact your JIRA
>>>>>>>>>>>> administrators
>>>>>>>>>>>> For more information on JIRA, see:
>>>>>>>>>>>> http://www.atlassian.com/software/jira
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>> --
>>>> Brian Stansberry
>>>> Senior Principal Software Engineer
>>>> JBoss by Red Hat
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>
>>
>
>

From ssilvert at redhat.com  Wed Feb 11 10:19:03 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 11 Feb 2015 10:19:03 -0500
Subject: [wildfly-dev] Embedding a WF instance in the CLI
In-Reply-To: <54DA7432.8080207@redhat.com>
References: <JIRA.12539089.1398430273000.24526.1398433475922@jira02.app.mwc.hst.phx2.redhat.com>
	<535A88CE.3010503@redhat.com> <535A8D25.5020507@redhat.com>
	<535A920E.5090607@redhat.com> <535E6DF8.1030507@redhat.com>
	<53728668.4040007@redhat.com> <5373758E.9060700@redhat.com>
	<53738129.30709@redhat.com>
	<1734718658.5454347.1400079220862.JavaMail.zimbra@redhat.com>
	<54DA7432.8080207@redhat.com>
Message-ID: <54DB72E7.4030505@redhat.com>

Can you upload deployments and overlays in offline mode?  That would 
make this something that you can't do by just editing the standalone.xml.

On 2/10/2015 4:12 PM, Brian Stansberry wrote:
> I had some time over the holidays and on planes to progress quite a bit
> on this. A standalone server protype is at [1]. A fairly in depth
> description is on the WildFly Development wiki at [2].
>
> I tried pretty hard to have clean commits on that branch, one per issue
> I faced. So looking at the commits is worthwhile to get a better
> understanding of particular aspects.
>
> Some notes on what I did / issues to discuss:
>
> 1) I semi-ported the "embedded" module from WildFly full to WildFly
> Core. "Semi" in the sense that the code is now in both places, under
> different maven GAVs and ending up in differently named modules in full.
> We need to regularize this; decide if there's any point in a "full"
> version of embedded, decide what to do about any APIs we don't want in
> the core version. (There are some deprecated methods, and one method
> "Context getContext()" that doesn't mean much in core, which has no JNDI.)
>
> 2) The CLI's use of stdio needed to be tweaked a bit to make it possible
> to control what the embedded server does with stdout. That's in the
> "Remove direct use of System.out by most CLI code" commit at [1].
>
> 3) I needed to deal with some general embedding issues in the server;
> i.e. things that would probably pop up in any embedded use case:
>
> a) controlling the LogContext so the embedded server logging can be
> managed independent of the embedding app. See "Let apps that embed
> WildFly control the LogContext" commit at [1].
>
> I don't think this is real solid though. For example, I expect CLI-side
> loggers that happen to get created after the embedded server starts will
> end up using the server LogContext.
>
> b) the server was calling System.exit in some places. See "[WFCORE-528]
> Use SystemExiter, not System.exit" commit at [1].
>
> c) the embedded server code didn't deal with reload, leaving behind a
> broken ModelControllerClient. See "[WFCORE-511] Support reload in the
> embedded server" commit at [1].
>
> 4) The modular vs non-modular environment aspects discussed at "Modular
> vs Non-Modular Classloading and JBOSS_HOME" in [2] are not ideal. I'm
> not sure how far we can/should go in improving this though.
>
> 5) This is painfully lacking in tests!
>
> Comments and suggestions are welcome!
>
> Cheers,
> Brian
>
> [1] https://github.com/bstansberry/wildfly-core/commits/cli-embed-server
>
> [2] https://developer.jboss.org/docs/DOC-53050
>
> On 5/14/14 9:53 AM, John Mazzitelli wrote:
>> How topical :) The RHQ installer could use this - just this very second I'm debugging and trying to figure out why the RHQ installer can't connect to the running app server instance to do its initial config setup - having to try to figure out what port its running on and why I can't connect is a pain.
>>
>> ----- Original Message -----
>>> Moving a thread to the dev list.
>>>
>>> This is about some prototyping I've been doing on weekends 'cause I'm
>>> bored with my regular tasks. I've been playing with direct local
>>> administration of a WF installation via the CLI without requiring a
>>> socket-based connection. The general use case is initial setup type
>>> activities where the user doesn't want to have to launch a WF server or
>>> HC process and potentially have it be visible on the network.
>>> https://issues.jboss.org/browse/WFLY-3288 is one use case; another is a
>>> desire some folks have expressed in being able to do configuration
>>> without first having to edit any xml to avoid port conflicts on 9990 or
>>> 9999.
>>>
>>> This isn't a major initiative or big priority or anything at this point.
>>> Just something I find interesting and perhaps you will too.
>>>
>>> On 5/14/14, 8:54 AM, Alexey Loubyansky wrote:
>>>> Neat :) Yes, figuring out the module path is biting everywhere.
>>>> For file system path command line arguments there is a specialized
>>>> FileSystemPathArgument.
>>>>
>>> Thanks; I'll switch to that.
>>>
>>>> On 05/13/2014 10:54 PM, Brian Stansberry wrote:
>>>>> Copying Heiko Braun as he expressed some interest in the topic.
>>>>>
>>>>> BTW, I played with this a bit more last weekend and was able to start an
>>>>> embedded server inside the CLI easily enough. See [1] for very raw
>>>>> prototype stuff. You can run bin/jboss-cli.sh (no -c) and then
>>>>>
>>>>> [disconnected/] embed-server
>>>>>
>>>>> There are a couple issues I see, besides the HC stuff I mentioned in my
>>>>> last message.
>>>>>
>>>>> 1) If the CLI is started in a non-modular environment via java -jar
>>>>> bin/client/jboss-cli-client.jar, we'd have to shade jboss-modules into
>>>>> the jar. And then the embed-server command would need params specifying
>>>>> the location of JBOSS_HOME, possibly module path etc. But it could embed
>>>>> a server installed in any accessible filesystem location.
>>>>>
>>>>> But what I did at [1] is based on bin/jboss-cli.sh, where the CLI is
>>>>> running from a WF dist in a modular environment and the embedded server
>>>>> modules are coming from the CLI's own module path. It would be more
>>>>> effort to support embedding a server based on some other module path.
>>>>> Maybe it's no big deal; maybe it's really hard. :)
>>>>>
>>>>> 2) The console logging from the embedded server goes to stdout mixed in
>>>>> with the CLI output. Maybe that's good, maybe it's bad.
>>>>>
>>>>> [1] https://github.com/bstansberry/wildfly/tree/cli-embed
>>>>>
>>>>> On 4/28/14, 10:04 AM, Brian Stansberry wrote:
>>>>>> I was poking around at this for an hour or so over the weekend.
>>>>>>
>>>>>> The standalone case seems pretty straightforward. Seems the existing
>>>>>> embedded server API could work readily enough. The
>>>>>> org.jboss.as.embedded.StandaloneServer interface already provides a
>>>>>> ModelControllerClient.
>>>>>>
>>>>>> The domain case is much harder, as the CLI wants a HostController, not a
>>>>>> ProcessController. I'd really like this to use an in-VM client, not a
>>>>>> remote one, so I don't like having the CLI embed a PC and then the HC is
>>>>>> an external process. My thoughts of the morning are to allow inverting
>>>>>> the HC/PC relationship for this kind of usage. That is, remove
>>>>>> controlling the HC lifecycle from the charge of the PC component. CLI
>>>>>> launches HC, and then the HC creates an in-process PC-ish component (not
>>>>>> a separate process) to manage the server lifecycles. There could be all
>>>>>> sorts of problems with that; it's just the thought for the morning.
>>>>>>
>>>>>> On 4/25/14, 11:49 AM, Alexey Loubyansky wrote:
>>>>>>> Embedding the AS is the best starting point to achieve that! And more
>>>>>>> fun, I agree :)
>>>>>>>
>>>>>>> On 04/25/2014 06:28 PM, Darran Lofthouse wrote:
>>>>>>>> And to think my reason for opening the Jira was just for a common
>>>>>>>> way to
>>>>>>>> mask password inputs where java.io.Console is not available ;-)
>>>>>>>>
>>>>>>>> On 25/04/14 17:09, Brian Stansberry wrote:
>>>>>>>>> On 4/25/14, 10:40 AM, Alexey Loubyansky wrote:
>>>>>>>>>> Wow! Indeed :)
>>>>>>>>>>
>>>>>>>>>> There could be an embedded scope - true, i.e. commands available
>>>>>>>>>> only
>>>>>>>>>> this mode, like add-user, module mgmt related stuff, etc.
>>>>>>>>> Those commands wouldn't need to be only in that mode though. The
>>>>>>>>> implementation of all of them would be based in the server; the
>>>>>>>>> "client"
>>>>>>>>> aspect of the CLI would just use the management interface. The
>>>>>>>>> difference between an embedded mode and what we have now would
>>>>>>>>> just be
>>>>>>>>> in how the "client" side gets its ModelControllerClient -- what we
>>>>>>>>> have
>>>>>>>>> now vs starting an embedded server and getting some sort of in-vm
>>>>>>>>> client.
>>>>>>>>>
>>>>>>>>>> But it would still mean the server/controller would have to actually
>>>>>>>>>> provide implementations of that functionality and expose it to the
>>>>>>>>>> management tools like the CLI in the embedded mode.
>>>>>>>>> Yep.
>>>>>>>>>
>>>>>>>>>> I like this idea as a concept - direct local management. W/o any
>>>>>>>>>> remote
>>>>>>>>>> connect/re-connect/disconnect burden.
>>>>>>>>>>
>>>>>>>>>> Extending the CLI with custom modules is on the list too. It's
>>>>>>>>>> probably
>>>>>>>>>> easier to implement at this point.
>>>>>>>>>>
>>>>>>>>> Likely so, but maybe less fun. ;) I copied you on a PRD-related
>>>>>>>>> thread
>>>>>>>>> where I briefly get into this general area too.
>>>>>>>>>
>>>>>>>>>> Alexey
>>>>>>>>>>
>>>>>>>>>> On 04/25/2014 05:00 PM, Brian Stansberry wrote:
>>>>>>>>>>> Hi Alexey,
>>>>>>>>>>>
>>>>>>>>>>> Wanted to point the discussion on this JIRA out to you as it gets
>>>>>>>>>>> into
>>>>>>>>>>> some fairly fundamental brainstorming that you may find
>>>>>>>>>>> interesting.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -------- Original Message --------
>>>>>>>>>>> Subject: [JBoss JIRA] (WFLY-3288) Update add-user to use AESH or
>>>>>>>>>>> move it
>>>>>>>>>>> into the CLI
>>>>>>>>>>> Date: Fri, 25 Apr 2014 09:44:35 -0400 (EDT)
>>>>>>>>>>> From: Darran Lofthouse (JIRA) <issues at jboss.org>
>>>>>>>>>>> To: brian.stansberry at redhat.com
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>        [
>>>>>>>>>>> https://issues.jboss.org/browse/WFLY-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12963854#comment-12963854
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ]
>>>>>>>>>>>
>>>>>>>>>>> Darran Lofthouse commented on WFLY-3288:
>>>>>>>>>>> ----------------------------------------
>>>>>>>>>>>
>>>>>>>>>>> That could be very interested, won't go into too much detail in
>>>>>>>>>>> this
>>>>>>>>>>> Jira as it is not directly related shortly I am switching to the
>>>>>>>>>>> SSL
>>>>>>>>>>> related tasks we have outstanding including the out of the box
>>>>>>>>>>> enablement we talked about in Brno - managing an embedded instance
>>>>>>>>>>> could
>>>>>>>>>>> be useful there as well to get it all op based.
>>>>>>>>>>>
>>>>>>>>>>> I can see this task may end up coming back my way combined with the
>>>>>>>>>>> other stuff ;-)
>>>>>>>>>>>
>>>>>>>>>>>> Update add-user to use AESH or move it into the CLI
>>>>>>>>>>>> ---------------------------------------------------
>>>>>>>>>>>>
>>>>>>>>>>>>                   Key: WFLY-3288
>>>>>>>>>>>>                   URL: https://issues.jboss.org/browse/WFLY-3288
>>>>>>>>>>>>               Project: WildFly
>>>>>>>>>>>>            Issue Type: Feature Request
>>>>>>>>>>>>        Security Level: Public(Everyone can see)
>>>>>>>>>>>>            Components: Domain Management, Scripts
>>>>>>>>>>>>              Reporter: Darran Lofthouse
>>>>>>>>>>>>               Fix For: Awaiting Volunteers
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Within the add-user utility it is difficult to handle situations
>>>>>>>>>>>> where
>>>>>>>>>>>> we do not have access to a java.io.Console which is the easiest
>>>>>>>>>>>> way to
>>>>>>>>>>>> handle password reading without an echo to the user e.g. in Cygwin
>>>>>>>>>>>> Switching to AESH would allow us to use the implementation
>>>>>>>>>>>> there to
>>>>>>>>>>>> handle this.
>>>>>>>>>>>> Alternatively it may actually make sense to make add-user a
>>>>>>>>>>>> special
>>>>>>>>>>>> mode of the CLI, we may at some point want to switch to runtime
>>>>>>>>>>>> operations being executed on the server so porting to the CLI
>>>>>>>>>>>> could be
>>>>>>>>>>>> the first step to make this possible.
>>>>>>>>>>>> Overall this is going to require further discussion so the
>>>>>>>>>>>> comments
>>>>>>>>>>>> here are just a starting point.
>>>>>>>>>>> --
>>>>>>>>>>> This message is automatically generated by JIRA.
>>>>>>>>>>> If you think it was sent incorrectly, please contact your JIRA
>>>>>>>>>>> administrators
>>>>>>>>>>> For more information on JIRA, see:
>>>>>>>>>>> http://www.atlassian.com/software/jira
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>
>>>
>>> --
>>> Brian Stansberry
>>> Senior Principal Software Engineer
>>> JBoss by Red Hat
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>


From brian.stansberry at redhat.com  Wed Feb 11 11:11:07 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 11 Feb 2015 10:11:07 -0600
Subject: [wildfly-dev] Embedding a WF instance in the CLI
In-Reply-To: <54DB6B92.6090007@jboss.com>
References: <JIRA.12539089.1398430273000.24526.1398433475922@jira02.app.mwc.hst.phx2.redhat.com>
	<535A88CE.3010503@redhat.com> <535A8D25.5020507@redhat.com>
	<535A920E.5090607@redhat.com> <535E6DF8.1030507@redhat.com>
	<53728668.4040007@redhat.com> <5373758E.9060700@redhat.com>
	<53738129.30709@redhat.com>
	<1734718658.5454347.1400079220862.JavaMail.zimbra@redhat.com>
	<54DA7432.8080207@redhat.com> <54DA7683.6060204@redhat.com>
	<54DB6B92.6090007@jboss.com>
Message-ID: <54DB7F1B.1050403@redhat.com>

Agreed. OK, I won't worry about this; thanks.

On 2/11/15 8:47 AM, Darran Lofthouse wrote:
> TBH that sounds correct, if a user should not have super user access
> they should not have read/write access to the server configuration
> anyway and to run the server they have that access.
>
> IMO embedded in CLI is just an alternative way to edit the config file
> and editing that config directly is super user access.
>
> The $local authentication mechanism can still be configured with
> appropriate file system permissions so that other users on the same
> machine can auth locally with reduced permissions but for that to be
> effective those users should not have read/write access to the actual
> config.
>
> Regards,
> Darran Lofthouse.
>
>
> On 10/02/15 21:22, Brian Stansberry wrote:
>> One other issue I forgot to mention: security
>>
>> A user running the CLI this way essentially has RBAC SuperUser rights.
>>
>> To use this, the user would have to have access to the local system,
>> with necessary read/write filesystem permissions. Such a user would have
>> other means to mess with the server config, but still, this is another.
>>
>> This is somewhat like the case with $local authentication. But with
>> that, the user organization can modify the config and turn of that
>> authentication mechanism. Perhaps we can do something similar here; e.g.
>> an "embeddable" setting in the config, which if false will cause boot
>> abort in an embedded server.
>>
>> On 2/10/15 3:12 PM, Brian Stansberry wrote:
>>> I had some time over the holidays and on planes to progress quite a bit
>>> on this. A standalone server protype is at [1]. A fairly in depth
>>> description is on the WildFly Development wiki at [2].
>>>
>>> I tried pretty hard to have clean commits on that branch, one per issue
>>> I faced. So looking at the commits is worthwhile to get a better
>>> understanding of particular aspects.
>>>
>>> Some notes on what I did / issues to discuss:
>>>
>>> 1) I semi-ported the "embedded" module from WildFly full to WildFly
>>> Core. "Semi" in the sense that the code is now in both places, under
>>> different maven GAVs and ending up in differently named modules in full.
>>> We need to regularize this; decide if there's any point in a "full"
>>> version of embedded, decide what to do about any APIs we don't want in
>>> the core version. (There are some deprecated methods, and one method
>>> "Context getContext()" that doesn't mean much in core, which has no
>>> JNDI.)
>>>
>>> 2) The CLI's use of stdio needed to be tweaked a bit to make it possible
>>> to control what the embedded server does with stdout. That's in the
>>> "Remove direct use of System.out by most CLI code" commit at [1].
>>>
>>> 3) I needed to deal with some general embedding issues in the server;
>>> i.e. things that would probably pop up in any embedded use case:
>>>
>>> a) controlling the LogContext so the embedded server logging can be
>>> managed independent of the embedding app. See "Let apps that embed
>>> WildFly control the LogContext" commit at [1].
>>>
>>> I don't think this is real solid though. For example, I expect CLI-side
>>> loggers that happen to get created after the embedded server starts will
>>> end up using the server LogContext.
>>>
>>> b) the server was calling System.exit in some places. See "[WFCORE-528]
>>> Use SystemExiter, not System.exit" commit at [1].
>>>
>>> c) the embedded server code didn't deal with reload, leaving behind a
>>> broken ModelControllerClient. See "[WFCORE-511] Support reload in the
>>> embedded server" commit at [1].
>>>
>>> 4) The modular vs non-modular environment aspects discussed at "Modular
>>> vs Non-Modular Classloading and JBOSS_HOME" in [2] are not ideal. I'm
>>> not sure how far we can/should go in improving this though.
>>>
>>> 5) This is painfully lacking in tests!
>>>
>>> Comments and suggestions are welcome!
>>>
>>> Cheers,
>>> Brian
>>>
>>> [1] https://github.com/bstansberry/wildfly-core/commits/cli-embed-server
>>>
>>> [2] https://developer.jboss.org/docs/DOC-53050
>>>
>>> On 5/14/14 9:53 AM, John Mazzitelli wrote:
>>>> How topical :) The RHQ installer could use this - just this very
>>>> second I'm debugging and trying to figure out why the RHQ installer
>>>> can't connect to the running app server instance to do its initial
>>>> config setup - having to try to figure out what port its running on
>>>> and why I can't connect is a pain.
>>>>
>>>> ----- Original Message -----
>>>>> Moving a thread to the dev list.
>>>>>
>>>>> This is about some prototyping I've been doing on weekends 'cause I'm
>>>>> bored with my regular tasks. I've been playing with direct local
>>>>> administration of a WF installation via the CLI without requiring a
>>>>> socket-based connection. The general use case is initial setup type
>>>>> activities where the user doesn't want to have to launch a WF
>>>>> server or
>>>>> HC process and potentially have it be visible on the network.
>>>>> https://issues.jboss.org/browse/WFLY-3288 is one use case; another
>>>>> is a
>>>>> desire some folks have expressed in being able to do configuration
>>>>> without first having to edit any xml to avoid port conflicts on
>>>>> 9990 or
>>>>> 9999.
>>>>>
>>>>> This isn't a major initiative or big priority or anything at this
>>>>> point.
>>>>> Just something I find interesting and perhaps you will too.
>>>>>
>>>>> On 5/14/14, 8:54 AM, Alexey Loubyansky wrote:
>>>>>> Neat :) Yes, figuring out the module path is biting everywhere.
>>>>>> For file system path command line arguments there is a specialized
>>>>>> FileSystemPathArgument.
>>>>>>
>>>>>
>>>>> Thanks; I'll switch to that.
>>>>>
>>>>>>
>>>>>> On 05/13/2014 10:54 PM, Brian Stansberry wrote:
>>>>>>> Copying Heiko Braun as he expressed some interest in the topic.
>>>>>>>
>>>>>>> BTW, I played with this a bit more last weekend and was able to
>>>>>>> start an
>>>>>>> embedded server inside the CLI easily enough. See [1] for very raw
>>>>>>> prototype stuff. You can run bin/jboss-cli.sh (no -c) and then
>>>>>>>
>>>>>>> [disconnected/] embed-server
>>>>>>>
>>>>>>> There are a couple issues I see, besides the HC stuff I mentioned
>>>>>>> in my
>>>>>>> last message.
>>>>>>>
>>>>>>> 1) If the CLI is started in a non-modular environment via java -jar
>>>>>>> bin/client/jboss-cli-client.jar, we'd have to shade jboss-modules
>>>>>>> into
>>>>>>> the jar. And then the embed-server command would need params
>>>>>>> specifying
>>>>>>> the location of JBOSS_HOME, possibly module path etc. But it could
>>>>>>> embed
>>>>>>> a server installed in any accessible filesystem location.
>>>>>>>
>>>>>>> But what I did at [1] is based on bin/jboss-cli.sh, where the CLI is
>>>>>>> running from a WF dist in a modular environment and the embedded
>>>>>>> server
>>>>>>> modules are coming from the CLI's own module path. It would be more
>>>>>>> effort to support embedding a server based on some other module
>>>>>>> path.
>>>>>>> Maybe it's no big deal; maybe it's really hard. :)
>>>>>>>
>>>>>>> 2) The console logging from the embedded server goes to stdout
>>>>>>> mixed in
>>>>>>> with the CLI output. Maybe that's good, maybe it's bad.
>>>>>>>
>>>>>>> [1] https://github.com/bstansberry/wildfly/tree/cli-embed
>>>>>>>
>>>>>>> On 4/28/14, 10:04 AM, Brian Stansberry wrote:
>>>>>>>> I was poking around at this for an hour or so over the weekend.
>>>>>>>>
>>>>>>>> The standalone case seems pretty straightforward. Seems the
>>>>>>>> existing
>>>>>>>> embedded server API could work readily enough. The
>>>>>>>> org.jboss.as.embedded.StandaloneServer interface already provides a
>>>>>>>> ModelControllerClient.
>>>>>>>>
>>>>>>>> The domain case is much harder, as the CLI wants a HostController,
>>>>>>>> not a
>>>>>>>> ProcessController. I'd really like this to use an in-VM client,
>>>>>>>> not a
>>>>>>>> remote one, so I don't like having the CLI embed a PC and then the
>>>>>>>> HC is
>>>>>>>> an external process. My thoughts of the morning are to allow
>>>>>>>> inverting
>>>>>>>> the HC/PC relationship for this kind of usage. That is, remove
>>>>>>>> controlling the HC lifecycle from the charge of the PC component.
>>>>>>>> CLI
>>>>>>>> launches HC, and then the HC creates an in-process PC-ish
>>>>>>>> component (not
>>>>>>>> a separate process) to manage the server lifecycles. There could
>>>>>>>> be all
>>>>>>>> sorts of problems with that; it's just the thought for the morning.
>>>>>>>>
>>>>>>>> On 4/25/14, 11:49 AM, Alexey Loubyansky wrote:
>>>>>>>>> Embedding the AS is the best starting point to achieve that! And
>>>>>>>>> more
>>>>>>>>> fun, I agree :)
>>>>>>>>>
>>>>>>>>> On 04/25/2014 06:28 PM, Darran Lofthouse wrote:
>>>>>>>>>> And to think my reason for opening the Jira was just for a common
>>>>>>>>>> way to
>>>>>>>>>> mask password inputs where java.io.Console is not available ;-)
>>>>>>>>>>
>>>>>>>>>> On 25/04/14 17:09, Brian Stansberry wrote:
>>>>>>>>>>> On 4/25/14, 10:40 AM, Alexey Loubyansky wrote:
>>>>>>>>>>>> Wow! Indeed :)
>>>>>>>>>>>>
>>>>>>>>>>>> There could be an embedded scope - true, i.e. commands
>>>>>>>>>>>> available
>>>>>>>>>>>> only
>>>>>>>>>>>> this mode, like add-user, module mgmt related stuff, etc.
>>>>>>>>>>>
>>>>>>>>>>> Those commands wouldn't need to be only in that mode though. The
>>>>>>>>>>> implementation of all of them would be based in the server; the
>>>>>>>>>>> "client"
>>>>>>>>>>> aspect of the CLI would just use the management interface. The
>>>>>>>>>>> difference between an embedded mode and what we have now would
>>>>>>>>>>> just be
>>>>>>>>>>> in how the "client" side gets its ModelControllerClient --
>>>>>>>>>>> what we
>>>>>>>>>>> have
>>>>>>>>>>> now vs starting an embedded server and getting some sort of
>>>>>>>>>>> in-vm
>>>>>>>>>>> client.
>>>>>>>>>>>
>>>>>>>>>>>> But it would still mean the server/controller would have to
>>>>>>>>>>>> actually
>>>>>>>>>>>> provide implementations of that functionality and expose it to
>>>>>>>>>>>> the
>>>>>>>>>>>> management tools like the CLI in the embedded mode.
>>>>>>>>>>>
>>>>>>>>>>> Yep.
>>>>>>>>>>>
>>>>>>>>>>>> I like this idea as a concept - direct local management. W/o
>>>>>>>>>>>> any
>>>>>>>>>>>> remote
>>>>>>>>>>>> connect/re-connect/disconnect burden.
>>>>>>>>>>>>
>>>>>>>>>>>> Extending the CLI with custom modules is on the list too. It's
>>>>>>>>>>>> probably
>>>>>>>>>>>> easier to implement at this point.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Likely so, but maybe less fun. ;) I copied you on a PRD-related
>>>>>>>>>>> thread
>>>>>>>>>>> where I briefly get into this general area too.
>>>>>>>>>>>
>>>>>>>>>>>> Alexey
>>>>>>>>>>>>
>>>>>>>>>>>> On 04/25/2014 05:00 PM, Brian Stansberry wrote:
>>>>>>>>>>>>> Hi Alexey,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Wanted to point the discussion on this JIRA out to you as it
>>>>>>>>>>>>> gets
>>>>>>>>>>>>> into
>>>>>>>>>>>>> some fairly fundamental brainstorming that you may find
>>>>>>>>>>>>> interesting.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> -------- Original Message --------
>>>>>>>>>>>>> Subject: [JBoss JIRA] (WFLY-3288) Update add-user to use
>>>>>>>>>>>>> AESH or
>>>>>>>>>>>>> move it
>>>>>>>>>>>>> into the CLI
>>>>>>>>>>>>> Date: Fri, 25 Apr 2014 09:44:35 -0400 (EDT)
>>>>>>>>>>>>> From: Darran Lofthouse (JIRA) <issues at jboss.org>
>>>>>>>>>>>>> To: brian.stansberry at redhat.com
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>       [
>>>>>>>>>>>>> https://issues.jboss.org/browse/WFLY-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12963854#comment-12963854
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ]
>>>>>>>>>>>>>
>>>>>>>>>>>>> Darran Lofthouse commented on WFLY-3288:
>>>>>>>>>>>>> ----------------------------------------
>>>>>>>>>>>>>
>>>>>>>>>>>>> That could be very interested, won't go into too much
>>>>>>>>>>>>> detail in
>>>>>>>>>>>>> this
>>>>>>>>>>>>> Jira as it is not directly related shortly I am switching to
>>>>>>>>>>>>> the
>>>>>>>>>>>>> SSL
>>>>>>>>>>>>> related tasks we have outstanding including the out of the box
>>>>>>>>>>>>> enablement we talked about in Brno - managing an embedded
>>>>>>>>>>>>> instance
>>>>>>>>>>>>> could
>>>>>>>>>>>>> be useful there as well to get it all op based.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I can see this task may end up coming back my way combined
>>>>>>>>>>>>> with the
>>>>>>>>>>>>> other stuff ;-)
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Update add-user to use AESH or move it into the CLI
>>>>>>>>>>>>>> ---------------------------------------------------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                  Key: WFLY-3288
>>>>>>>>>>>>>>                  URL:
>>>>>>>>>>>>>> https://issues.jboss.org/browse/WFLY-3288
>>>>>>>>>>>>>>              Project: WildFly
>>>>>>>>>>>>>>           Issue Type: Feature Request
>>>>>>>>>>>>>>       Security Level: Public(Everyone can see)
>>>>>>>>>>>>>>           Components: Domain Management, Scripts
>>>>>>>>>>>>>>             Reporter: Darran Lofthouse
>>>>>>>>>>>>>>              Fix For: Awaiting Volunteers
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Within the add-user utility it is difficult to handle
>>>>>>>>>>>>>> situations
>>>>>>>>>>>>>> where
>>>>>>>>>>>>>> we do not have access to a java.io.Console which is the
>>>>>>>>>>>>>> easiest
>>>>>>>>>>>>>> way to
>>>>>>>>>>>>>> handle password reading without an echo to the user e.g. in
>>>>>>>>>>>>>> Cygwin
>>>>>>>>>>>>>> Switching to AESH would allow us to use the implementation
>>>>>>>>>>>>>> there to
>>>>>>>>>>>>>> handle this.
>>>>>>>>>>>>>> Alternatively it may actually make sense to make add-user a
>>>>>>>>>>>>>> special
>>>>>>>>>>>>>> mode of the CLI, we may at some point want to switch to
>>>>>>>>>>>>>> runtime
>>>>>>>>>>>>>> operations being executed on the server so porting to the CLI
>>>>>>>>>>>>>> could be
>>>>>>>>>>>>>> the first step to make this possible.
>>>>>>>>>>>>>> Overall this is going to require further discussion so the
>>>>>>>>>>>>>> comments
>>>>>>>>>>>>>> here are just a starting point.
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> This message is automatically generated by JIRA.
>>>>>>>>>>>>> If you think it was sent incorrectly, please contact your JIRA
>>>>>>>>>>>>> administrators
>>>>>>>>>>>>> For more information on JIRA, see:
>>>>>>>>>>>>> http://www.atlassian.com/software/jira
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Brian Stansberry
>>>>> Senior Principal Software Engineer
>>>>> JBoss by Red Hat
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>
>>>
>>
>>


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

From brian.stansberry at redhat.com  Wed Feb 11 11:14:42 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 11 Feb 2015 10:14:42 -0600
Subject: [wildfly-dev] Embedding a WF instance in the CLI
In-Reply-To: <9C8CD903-88E3-4525-A610-BC05DE0DC171@redhat.com>
References: <JIRA.12539089.1398430273000.24526.1398433475922@jira02.app.mwc.hst.phx2.redhat.com>
	<535A88CE.3010503@redhat.com> <535A8D25.5020507@redhat.com>
	<535A920E.5090607@redhat.com> <535E6DF8.1030507@redhat.com>
	<53728668.4040007@redhat.com> <5373758E.9060700@redhat.com>
	<53738129.30709@redhat.com>
	<1734718658.5454347.1400079220862.JavaMail.zimbra@redhat.com>
	<54DA7432.8080207@redhat.com>
	<9C8CD903-88E3-4525-A610-BC05DE0DC171@redhat.com>
Message-ID: <54DB7FF2.3060501@redhat.com>

Direct local administration of a WildFly Core-based installation via the 
CLI without requiring a socket-based connection. The general use case is 
initial setup type activities where the user doesn't want to have to 
launch a WF server or HC process and potentially have it be visible on 
the network. https://issues.jboss.org/browse/WFLY-3288 is one use case; 
another is a desire some folks (Red Hat SEs in particular) have 
expressed in being able to do configuration without first having to edit 
any xml to avoid port conflicts on 9990 or 9999.

As the CLI is itself embeddable, this also opens up the possibility of 
embedding the CLI inside some other process (say a test class, a 
provisioning tool or a jar with a main) and then launching the embedded 
server and using the embedded CLI as a convenient management tool. Such 
a process could just embed the server directly, but then it would have 
to deal with ModelControllerClient itself.

On 2/11/15 12:49 AM, Heiko Braun wrote:
> What's again the rational behind this?
>
>
>
>
>> Am 10.02.2015 um 22:12 schrieb Brian Stansberry <brian.stansberry at redhat.com>:
>>
>> I had some time over the holidays and on planes to progress quite a bit
>> on this. A standalone server protype is at [1]. A fairly in depth
>> description is on the WildFly Development wiki at [2].
>>
>> I tried pretty hard to have clean commits on that branch, one per issue
>> I faced. So looking at the commits is worthwhile to get a better
>> understanding of particular aspects.
>>
>> Some notes on what I did / issues to discuss:
>>
>> 1) I semi-ported the "embedded" module from WildFly full to WildFly
>> Core. "Semi" in the sense that the code is now in both places, under
>> different maven GAVs and ending up in differently named modules in full.
>> We need to regularize this; decide if there's any point in a "full"
>> version of embedded, decide what to do about any APIs we don't want in
>> the core version. (There are some deprecated methods, and one method
>> "Context getContext()" that doesn't mean much in core, which has no JNDI.)
>>
>> 2) The CLI's use of stdio needed to be tweaked a bit to make it possible
>> to control what the embedded server does with stdout. That's in the
>> "Remove direct use of System.out by most CLI code" commit at [1].
>>
>> 3) I needed to deal with some general embedding issues in the server;
>> i.e. things that would probably pop up in any embedded use case:
>>
>> a) controlling the LogContext so the embedded server logging can be
>> managed independent of the embedding app. See "Let apps that embed
>> WildFly control the LogContext" commit at [1].
>>
>> I don't think this is real solid though. For example, I expect CLI-side
>> loggers that happen to get created after the embedded server starts will
>> end up using the server LogContext.
>>
>> b) the server was calling System.exit in some places. See "[WFCORE-528]
>> Use SystemExiter, not System.exit" commit at [1].
>>
>> c) the embedded server code didn't deal with reload, leaving behind a
>> broken ModelControllerClient. See "[WFCORE-511] Support reload in the
>> embedded server" commit at [1].
>>
>> 4) The modular vs non-modular environment aspects discussed at "Modular
>> vs Non-Modular Classloading and JBOSS_HOME" in [2] are not ideal. I'm
>> not sure how far we can/should go in improving this though.
>>
>> 5) This is painfully lacking in tests!
>>
>> Comments and suggestions are welcome!
>>
>> Cheers,
>> Brian
>>
>> [1] https://github.com/bstansberry/wildfly-core/commits/cli-embed-server
>>
>> [2] https://developer.jboss.org/docs/DOC-53050
>>
>>> On 5/14/14 9:53 AM, John Mazzitelli wrote:
>>> How topical :) The RHQ installer could use this - just this very second I'm debugging and trying to figure out why the RHQ installer can't connect to the running app server instance to do its initial config setup - having to try to figure out what port its running on and why I can't connect is a pain.
>>>
>>> ----- Original Message -----
>>>> Moving a thread to the dev list.
>>>>
>>>> This is about some prototyping I've been doing on weekends 'cause I'm
>>>> bored with my regular tasks. I've been playing with direct local
>>>> administration of a WF installation via the CLI without requiring a
>>>> socket-based connection. The general use case is initial setup type
>>>> activities where the user doesn't want to have to launch a WF server or
>>>> HC process and potentially have it be visible on the network.
>>>> https://issues.jboss.org/browse/WFLY-3288 is one use case; another is a
>>>> desire some folks have expressed in being able to do configuration
>>>> without first having to edit any xml to avoid port conflicts on 9990 or
>>>> 9999.
>>>>
>>>> This isn't a major initiative or big priority or anything at this point.
>>>> Just something I find interesting and perhaps you will too.
>>>>
>>>>> On 5/14/14, 8:54 AM, Alexey Loubyansky wrote:
>>>>> Neat :) Yes, figuring out the module path is biting everywhere.
>>>>> For file system path command line arguments there is a specialized
>>>>> FileSystemPathArgument.
>>>>
>>>> Thanks; I'll switch to that.
>>>>
>>>>>
>>>>>> On 05/13/2014 10:54 PM, Brian Stansberry wrote:
>>>>>> Copying Heiko Braun as he expressed some interest in the topic.
>>>>>>
>>>>>> BTW, I played with this a bit more last weekend and was able to start an
>>>>>> embedded server inside the CLI easily enough. See [1] for very raw
>>>>>> prototype stuff. You can run bin/jboss-cli.sh (no -c) and then
>>>>>>
>>>>>> [disconnected/] embed-server
>>>>>>
>>>>>> There are a couple issues I see, besides the HC stuff I mentioned in my
>>>>>> last message.
>>>>>>
>>>>>> 1) If the CLI is started in a non-modular environment via java -jar
>>>>>> bin/client/jboss-cli-client.jar, we'd have to shade jboss-modules into
>>>>>> the jar. And then the embed-server command would need params specifying
>>>>>> the location of JBOSS_HOME, possibly module path etc. But it could embed
>>>>>> a server installed in any accessible filesystem location.
>>>>>>
>>>>>> But what I did at [1] is based on bin/jboss-cli.sh, where the CLI is
>>>>>> running from a WF dist in a modular environment and the embedded server
>>>>>> modules are coming from the CLI's own module path. It would be more
>>>>>> effort to support embedding a server based on some other module path.
>>>>>> Maybe it's no big deal; maybe it's really hard. :)
>>>>>>
>>>>>> 2) The console logging from the embedded server goes to stdout mixed in
>>>>>> with the CLI output. Maybe that's good, maybe it's bad.
>>>>>>
>>>>>> [1] https://github.com/bstansberry/wildfly/tree/cli-embed
>>>>>>
>>>>>>> On 4/28/14, 10:04 AM, Brian Stansberry wrote:
>>>>>>> I was poking around at this for an hour or so over the weekend.
>>>>>>>
>>>>>>> The standalone case seems pretty straightforward. Seems the existing
>>>>>>> embedded server API could work readily enough. The
>>>>>>> org.jboss.as.embedded.StandaloneServer interface already provides a
>>>>>>> ModelControllerClient.
>>>>>>>
>>>>>>> The domain case is much harder, as the CLI wants a HostController, not a
>>>>>>> ProcessController. I'd really like this to use an in-VM client, not a
>>>>>>> remote one, so I don't like having the CLI embed a PC and then the HC is
>>>>>>> an external process. My thoughts of the morning are to allow inverting
>>>>>>> the HC/PC relationship for this kind of usage. That is, remove
>>>>>>> controlling the HC lifecycle from the charge of the PC component. CLI
>>>>>>> launches HC, and then the HC creates an in-process PC-ish component (not
>>>>>>> a separate process) to manage the server lifecycles. There could be all
>>>>>>> sorts of problems with that; it's just the thought for the morning.
>>>>>>>
>>>>>>>> On 4/25/14, 11:49 AM, Alexey Loubyansky wrote:
>>>>>>>> Embedding the AS is the best starting point to achieve that! And more
>>>>>>>> fun, I agree :)
>>>>>>>>
>>>>>>>>> On 04/25/2014 06:28 PM, Darran Lofthouse wrote:
>>>>>>>>> And to think my reason for opening the Jira was just for a common
>>>>>>>>> way to
>>>>>>>>> mask password inputs where java.io.Console is not available ;-)
>>>>>>>>>
>>>>>>>>>> On 25/04/14 17:09, Brian Stansberry wrote:
>>>>>>>>>>> On 4/25/14, 10:40 AM, Alexey Loubyansky wrote:
>>>>>>>>>>> Wow! Indeed :)
>>>>>>>>>>>
>>>>>>>>>>> There could be an embedded scope - true, i.e. commands available
>>>>>>>>>>> only
>>>>>>>>>>> this mode, like add-user, module mgmt related stuff, etc.
>>>>>>>>>>
>>>>>>>>>> Those commands wouldn't need to be only in that mode though. The
>>>>>>>>>> implementation of all of them would be based in the server; the
>>>>>>>>>> "client"
>>>>>>>>>> aspect of the CLI would just use the management interface. The
>>>>>>>>>> difference between an embedded mode and what we have now would
>>>>>>>>>> just be
>>>>>>>>>> in how the "client" side gets its ModelControllerClient -- what we
>>>>>>>>>> have
>>>>>>>>>> now vs starting an embedded server and getting some sort of in-vm
>>>>>>>>>> client.
>>>>>>>>>>
>>>>>>>>>>> But it would still mean the server/controller would have to actually
>>>>>>>>>>> provide implementations of that functionality and expose it to the
>>>>>>>>>>> management tools like the CLI in the embedded mode.
>>>>>>>>>>
>>>>>>>>>> Yep.
>>>>>>>>>>
>>>>>>>>>>> I like this idea as a concept - direct local management. W/o any
>>>>>>>>>>> remote
>>>>>>>>>>> connect/re-connect/disconnect burden.
>>>>>>>>>>>
>>>>>>>>>>> Extending the CLI with custom modules is on the list too. It's
>>>>>>>>>>> probably
>>>>>>>>>>> easier to implement at this point.
>>>>>>>>>>
>>>>>>>>>> Likely so, but maybe less fun. ;) I copied you on a PRD-related
>>>>>>>>>> thread
>>>>>>>>>> where I briefly get into this general area too.
>>>>>>>>>>
>>>>>>>>>>> Alexey
>>>>>>>>>>>
>>>>>>>>>>>> On 04/25/2014 05:00 PM, Brian Stansberry wrote:
>>>>>>>>>>>> Hi Alexey,
>>>>>>>>>>>>
>>>>>>>>>>>> Wanted to point the discussion on this JIRA out to you as it gets
>>>>>>>>>>>> into
>>>>>>>>>>>> some fairly fundamental brainstorming that you may find
>>>>>>>>>>>> interesting.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -------- Original Message --------
>>>>>>>>>>>> Subject: [JBoss JIRA] (WFLY-3288) Update add-user to use AESH or
>>>>>>>>>>>> move it
>>>>>>>>>>>> into the CLI
>>>>>>>>>>>> Date: Fri, 25 Apr 2014 09:44:35 -0400 (EDT)
>>>>>>>>>>>> From: Darran Lofthouse (JIRA) <issues at jboss.org>
>>>>>>>>>>>> To: brian.stansberry at redhat.com
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>       [
>>>>>>>>>>>> https://issues.jboss.org/browse/WFLY-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12963854#comment-12963854
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ]
>>>>>>>>>>>>
>>>>>>>>>>>> Darran Lofthouse commented on WFLY-3288:
>>>>>>>>>>>> ----------------------------------------
>>>>>>>>>>>>
>>>>>>>>>>>> That could be very interested, won't go into too much detail in
>>>>>>>>>>>> this
>>>>>>>>>>>> Jira as it is not directly related shortly I am switching to the
>>>>>>>>>>>> SSL
>>>>>>>>>>>> related tasks we have outstanding including the out of the box
>>>>>>>>>>>> enablement we talked about in Brno - managing an embedded instance
>>>>>>>>>>>> could
>>>>>>>>>>>> be useful there as well to get it all op based.
>>>>>>>>>>>>
>>>>>>>>>>>> I can see this task may end up coming back my way combined with the
>>>>>>>>>>>> other stuff ;-)
>>>>>>>>>>>>
>>>>>>>>>>>>> Update add-user to use AESH or move it into the CLI
>>>>>>>>>>>>> ---------------------------------------------------
>>>>>>>>>>>>>
>>>>>>>>>>>>>                  Key: WFLY-3288
>>>>>>>>>>>>>                  URL: https://issues.jboss.org/browse/WFLY-3288
>>>>>>>>>>>>>              Project: WildFly
>>>>>>>>>>>>>           Issue Type: Feature Request
>>>>>>>>>>>>>       Security Level: Public(Everyone can see)
>>>>>>>>>>>>>           Components: Domain Management, Scripts
>>>>>>>>>>>>>             Reporter: Darran Lofthouse
>>>>>>>>>>>>>              Fix For: Awaiting Volunteers
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Within the add-user utility it is difficult to handle situations
>>>>>>>>>>>>> where
>>>>>>>>>>>>> we do not have access to a java.io.Console which is the easiest
>>>>>>>>>>>>> way to
>>>>>>>>>>>>> handle password reading without an echo to the user e.g. in Cygwin
>>>>>>>>>>>>> Switching to AESH would allow us to use the implementation
>>>>>>>>>>>>> there to
>>>>>>>>>>>>> handle this.
>>>>>>>>>>>>> Alternatively it may actually make sense to make add-user a
>>>>>>>>>>>>> special
>>>>>>>>>>>>> mode of the CLI, we may at some point want to switch to runtime
>>>>>>>>>>>>> operations being executed on the server so porting to the CLI
>>>>>>>>>>>>> could be
>>>>>>>>>>>>> the first step to make this possible.
>>>>>>>>>>>>> Overall this is going to require further discussion so the
>>>>>>>>>>>>> comments
>>>>>>>>>>>>> here are just a starting point.
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> This message is automatically generated by JIRA.
>>>>>>>>>>>> If you think it was sent incorrectly, please contact your JIRA
>>>>>>>>>>>> administrators
>>>>>>>>>>>> For more information on JIRA, see:
>>>>>>>>>>>> http://www.atlassian.com/software/jira
>>>>
>>>>
>>>> --
>>>> Brian Stansberry
>>>> Senior Principal Software Engineer
>>>> JBoss by Red Hat
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>> --
>> Brian Stansberry
>> Senior Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev


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

From jason.greene at redhat.com  Wed Feb 11 11:15:24 2015
From: jason.greene at redhat.com (Jason Greene)
Date: Wed, 11 Feb 2015 10:15:24 -0600
Subject: [wildfly-dev] Embedding a WF instance in the CLI
In-Reply-To: <9C8CD903-88E3-4525-A610-BC05DE0DC171@redhat.com>
References: <JIRA.12539089.1398430273000.24526.1398433475922@jira02.app.mwc.hst.phx2.redhat.com>
	<535A88CE.3010503@redhat.com> <535A8D25.5020507@redhat.com>
	<535A920E.5090607@redhat.com> <535E6DF8.1030507@redhat.com>
	<53728668.4040007@redhat.com> <5373758E.9060700@redhat.com>
	<53738129.30709@redhat.com>
	<1734718658.5454347.1400079220862.JavaMail.zimbra@redhat.com>
	<54DA7432.8080207@redhat.com>
	<9C8CD903-88E3-4525-A610-BC05DE0DC171@redhat.com>
Message-ID: <55C7009A-2B4B-44C2-B705-41488017E5EB@redhat.com>

To be able to manage the server without it running and without a TCP port. A key use case is that you can script a server from scratch with cli commands.
> On Feb 11, 2015, at 12:49 AM, Heiko Braun <hbraun at redhat.com> wrote:
> 
> What's again the rational behind this? 
> 
> 
> 
> 
>> Am 10.02.2015 um 22:12 schrieb Brian Stansberry <brian.stansberry at redhat.com>:
>> 
>> I had some time over the holidays and on planes to progress quite a bit 
>> on this. A standalone server protype is at [1]. A fairly in depth 
>> description is on the WildFly Development wiki at [2].
>> 
>> I tried pretty hard to have clean commits on that branch, one per issue 
>> I faced. So looking at the commits is worthwhile to get a better 
>> understanding of particular aspects.
>> 
>> Some notes on what I did / issues to discuss:
>> 
>> 1) I semi-ported the "embedded" module from WildFly full to WildFly 
>> Core. "Semi" in the sense that the code is now in both places, under 
>> different maven GAVs and ending up in differently named modules in full. 
>> We need to regularize this; decide if there's any point in a "full" 
>> version of embedded, decide what to do about any APIs we don't want in 
>> the core version. (There are some deprecated methods, and one method 
>> "Context getContext()" that doesn't mean much in core, which has no JNDI.)
>> 
>> 2) The CLI's use of stdio needed to be tweaked a bit to make it possible 
>> to control what the embedded server does with stdout. That's in the 
>> "Remove direct use of System.out by most CLI code" commit at [1].
>> 
>> 3) I needed to deal with some general embedding issues in the server; 
>> i.e. things that would probably pop up in any embedded use case:
>> 
>> a) controlling the LogContext so the embedded server logging can be 
>> managed independent of the embedding app. See "Let apps that embed 
>> WildFly control the LogContext" commit at [1].
>> 
>> I don't think this is real solid though. For example, I expect CLI-side 
>> loggers that happen to get created after the embedded server starts will 
>> end up using the server LogContext.
>> 
>> b) the server was calling System.exit in some places. See "[WFCORE-528] 
>> Use SystemExiter, not System.exit" commit at [1].
>> 
>> c) the embedded server code didn't deal with reload, leaving behind a 
>> broken ModelControllerClient. See "[WFCORE-511] Support reload in the 
>> embedded server" commit at [1].
>> 
>> 4) The modular vs non-modular environment aspects discussed at "Modular 
>> vs Non-Modular Classloading and JBOSS_HOME" in [2] are not ideal. I'm 
>> not sure how far we can/should go in improving this though.
>> 
>> 5) This is painfully lacking in tests!
>> 
>> Comments and suggestions are welcome!
>> 
>> Cheers,
>> Brian
>> 
>> [1] https://github.com/bstansberry/wildfly-core/commits/cli-embed-server
>> 
>> [2] https://developer.jboss.org/docs/DOC-53050
>> 
>>> On 5/14/14 9:53 AM, John Mazzitelli wrote:
>>> How topical :) The RHQ installer could use this - just this very second I'm debugging and trying to figure out why the RHQ installer can't connect to the running app server instance to do its initial config setup - having to try to figure out what port its running on and why I can't connect is a pain.
>>> 
>>> ----- Original Message -----
>>>> Moving a thread to the dev list.
>>>> 
>>>> This is about some prototyping I've been doing on weekends 'cause I'm
>>>> bored with my regular tasks. I've been playing with direct local
>>>> administration of a WF installation via the CLI without requiring a
>>>> socket-based connection. The general use case is initial setup type
>>>> activities where the user doesn't want to have to launch a WF server or
>>>> HC process and potentially have it be visible on the network.
>>>> https://issues.jboss.org/browse/WFLY-3288 is one use case; another is a
>>>> desire some folks have expressed in being able to do configuration
>>>> without first having to edit any xml to avoid port conflicts on 9990 or
>>>> 9999.
>>>> 
>>>> This isn't a major initiative or big priority or anything at this point.
>>>> Just something I find interesting and perhaps you will too.
>>>> 
>>>>> On 5/14/14, 8:54 AM, Alexey Loubyansky wrote:
>>>>> Neat :) Yes, figuring out the module path is biting everywhere.
>>>>> For file system path command line arguments there is a specialized
>>>>> FileSystemPathArgument.
>>>> 
>>>> Thanks; I'll switch to that.
>>>> 
>>>>> 
>>>>>> On 05/13/2014 10:54 PM, Brian Stansberry wrote:
>>>>>> Copying Heiko Braun as he expressed some interest in the topic.
>>>>>> 
>>>>>> BTW, I played with this a bit more last weekend and was able to start an
>>>>>> embedded server inside the CLI easily enough. See [1] for very raw
>>>>>> prototype stuff. You can run bin/jboss-cli.sh (no -c) and then
>>>>>> 
>>>>>> [disconnected/] embed-server
>>>>>> 
>>>>>> There are a couple issues I see, besides the HC stuff I mentioned in my
>>>>>> last message.
>>>>>> 
>>>>>> 1) If the CLI is started in a non-modular environment via java -jar
>>>>>> bin/client/jboss-cli-client.jar, we'd have to shade jboss-modules into
>>>>>> the jar. And then the embed-server command would need params specifying
>>>>>> the location of JBOSS_HOME, possibly module path etc. But it could embed
>>>>>> a server installed in any accessible filesystem location.
>>>>>> 
>>>>>> But what I did at [1] is based on bin/jboss-cli.sh, where the CLI is
>>>>>> running from a WF dist in a modular environment and the embedded server
>>>>>> modules are coming from the CLI's own module path. It would be more
>>>>>> effort to support embedding a server based on some other module path.
>>>>>> Maybe it's no big deal; maybe it's really hard. :)
>>>>>> 
>>>>>> 2) The console logging from the embedded server goes to stdout mixed in
>>>>>> with the CLI output. Maybe that's good, maybe it's bad.
>>>>>> 
>>>>>> [1] https://github.com/bstansberry/wildfly/tree/cli-embed
>>>>>> 
>>>>>>> On 4/28/14, 10:04 AM, Brian Stansberry wrote:
>>>>>>> I was poking around at this for an hour or so over the weekend.
>>>>>>> 
>>>>>>> The standalone case seems pretty straightforward. Seems the existing
>>>>>>> embedded server API could work readily enough. The
>>>>>>> org.jboss.as.embedded.StandaloneServer interface already provides a
>>>>>>> ModelControllerClient.
>>>>>>> 
>>>>>>> The domain case is much harder, as the CLI wants a HostController, not a
>>>>>>> ProcessController. I'd really like this to use an in-VM client, not a
>>>>>>> remote one, so I don't like having the CLI embed a PC and then the HC is
>>>>>>> an external process. My thoughts of the morning are to allow inverting
>>>>>>> the HC/PC relationship for this kind of usage. That is, remove
>>>>>>> controlling the HC lifecycle from the charge of the PC component. CLI
>>>>>>> launches HC, and then the HC creates an in-process PC-ish component (not
>>>>>>> a separate process) to manage the server lifecycles. There could be all
>>>>>>> sorts of problems with that; it's just the thought for the morning.
>>>>>>> 
>>>>>>>> On 4/25/14, 11:49 AM, Alexey Loubyansky wrote:
>>>>>>>> Embedding the AS is the best starting point to achieve that! And more
>>>>>>>> fun, I agree :)
>>>>>>>> 
>>>>>>>>> On 04/25/2014 06:28 PM, Darran Lofthouse wrote:
>>>>>>>>> And to think my reason for opening the Jira was just for a common
>>>>>>>>> way to
>>>>>>>>> mask password inputs where java.io.Console is not available ;-)
>>>>>>>>> 
>>>>>>>>>> On 25/04/14 17:09, Brian Stansberry wrote:
>>>>>>>>>>> On 4/25/14, 10:40 AM, Alexey Loubyansky wrote:
>>>>>>>>>>> Wow! Indeed :)
>>>>>>>>>>> 
>>>>>>>>>>> There could be an embedded scope - true, i.e. commands available
>>>>>>>>>>> only
>>>>>>>>>>> this mode, like add-user, module mgmt related stuff, etc.
>>>>>>>>>> 
>>>>>>>>>> Those commands wouldn't need to be only in that mode though. The
>>>>>>>>>> implementation of all of them would be based in the server; the
>>>>>>>>>> "client"
>>>>>>>>>> aspect of the CLI would just use the management interface. The
>>>>>>>>>> difference between an embedded mode and what we have now would
>>>>>>>>>> just be
>>>>>>>>>> in how the "client" side gets its ModelControllerClient -- what we
>>>>>>>>>> have
>>>>>>>>>> now vs starting an embedded server and getting some sort of in-vm
>>>>>>>>>> client.
>>>>>>>>>> 
>>>>>>>>>>> But it would still mean the server/controller would have to actually
>>>>>>>>>>> provide implementations of that functionality and expose it to the
>>>>>>>>>>> management tools like the CLI in the embedded mode.
>>>>>>>>>> 
>>>>>>>>>> Yep.
>>>>>>>>>> 
>>>>>>>>>>> I like this idea as a concept - direct local management. W/o any
>>>>>>>>>>> remote
>>>>>>>>>>> connect/re-connect/disconnect burden.
>>>>>>>>>>> 
>>>>>>>>>>> Extending the CLI with custom modules is on the list too. It's
>>>>>>>>>>> probably
>>>>>>>>>>> easier to implement at this point.
>>>>>>>>>> 
>>>>>>>>>> Likely so, but maybe less fun. ;) I copied you on a PRD-related
>>>>>>>>>> thread
>>>>>>>>>> where I briefly get into this general area too.
>>>>>>>>>> 
>>>>>>>>>>> Alexey
>>>>>>>>>>> 
>>>>>>>>>>>> On 04/25/2014 05:00 PM, Brian Stansberry wrote:
>>>>>>>>>>>> Hi Alexey,
>>>>>>>>>>>> 
>>>>>>>>>>>> Wanted to point the discussion on this JIRA out to you as it gets
>>>>>>>>>>>> into
>>>>>>>>>>>> some fairly fundamental brainstorming that you may find
>>>>>>>>>>>> interesting.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> -------- Original Message --------
>>>>>>>>>>>> Subject: [JBoss JIRA] (WFLY-3288) Update add-user to use AESH or
>>>>>>>>>>>> move it
>>>>>>>>>>>> into the CLI
>>>>>>>>>>>> Date: Fri, 25 Apr 2014 09:44:35 -0400 (EDT)
>>>>>>>>>>>> From: Darran Lofthouse (JIRA) <issues at jboss.org>
>>>>>>>>>>>> To: brian.stansberry at redhat.com
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>     [
>>>>>>>>>>>> https://issues.jboss.org/browse/WFLY-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12963854#comment-12963854
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> ]
>>>>>>>>>>>> 
>>>>>>>>>>>> Darran Lofthouse commented on WFLY-3288:
>>>>>>>>>>>> ----------------------------------------
>>>>>>>>>>>> 
>>>>>>>>>>>> That could be very interested, won't go into too much detail in
>>>>>>>>>>>> this
>>>>>>>>>>>> Jira as it is not directly related shortly I am switching to the
>>>>>>>>>>>> SSL
>>>>>>>>>>>> related tasks we have outstanding including the out of the box
>>>>>>>>>>>> enablement we talked about in Brno - managing an embedded instance
>>>>>>>>>>>> could
>>>>>>>>>>>> be useful there as well to get it all op based.
>>>>>>>>>>>> 
>>>>>>>>>>>> I can see this task may end up coming back my way combined with the
>>>>>>>>>>>> other stuff ;-)
>>>>>>>>>>>> 
>>>>>>>>>>>>> Update add-user to use AESH or move it into the CLI
>>>>>>>>>>>>> ---------------------------------------------------
>>>>>>>>>>>>> 
>>>>>>>>>>>>>                Key: WFLY-3288
>>>>>>>>>>>>>                URL: https://issues.jboss.org/browse/WFLY-3288
>>>>>>>>>>>>>            Project: WildFly
>>>>>>>>>>>>>         Issue Type: Feature Request
>>>>>>>>>>>>>     Security Level: Public(Everyone can see)
>>>>>>>>>>>>>         Components: Domain Management, Scripts
>>>>>>>>>>>>>           Reporter: Darran Lofthouse
>>>>>>>>>>>>>            Fix For: Awaiting Volunteers
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Within the add-user utility it is difficult to handle situations
>>>>>>>>>>>>> where
>>>>>>>>>>>>> we do not have access to a java.io.Console which is the easiest
>>>>>>>>>>>>> way to
>>>>>>>>>>>>> handle password reading without an echo to the user e.g. in Cygwin
>>>>>>>>>>>>> Switching to AESH would allow us to use the implementation
>>>>>>>>>>>>> there to
>>>>>>>>>>>>> handle this.
>>>>>>>>>>>>> Alternatively it may actually make sense to make add-user a
>>>>>>>>>>>>> special
>>>>>>>>>>>>> mode of the CLI, we may at some point want to switch to runtime
>>>>>>>>>>>>> operations being executed on the server so porting to the CLI
>>>>>>>>>>>>> could be
>>>>>>>>>>>>> the first step to make this possible.
>>>>>>>>>>>>> Overall this is going to require further discussion so the
>>>>>>>>>>>>> comments
>>>>>>>>>>>>> here are just a starting point.
>>>>>>>>>>>> 
>>>>>>>>>>>> --
>>>>>>>>>>>> This message is automatically generated by JIRA.
>>>>>>>>>>>> If you think it was sent incorrectly, please contact your JIRA
>>>>>>>>>>>> administrators
>>>>>>>>>>>> For more information on JIRA, see:
>>>>>>>>>>>> http://www.atlassian.com/software/jira
>>>> 
>>>> 
>>>> --
>>>> Brian Stansberry
>>>> Senior Principal Software Engineer
>>>> JBoss by Red Hat
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> 
>> 
>> -- 
>> Brian Stansberry
>> Senior Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> 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

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



From brian.stansberry at redhat.com  Wed Feb 11 11:21:59 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 11 Feb 2015 10:21:59 -0600
Subject: [wildfly-dev] Embedding a WF instance in the CLI
In-Reply-To: <54DB72E7.4030505@redhat.com>
References: <JIRA.12539089.1398430273000.24526.1398433475922@jira02.app.mwc.hst.phx2.redhat.com>	<535A88CE.3010503@redhat.com>
	<535A8D25.5020507@redhat.com>	<535A920E.5090607@redhat.com>
	<535E6DF8.1030507@redhat.com>	<53728668.4040007@redhat.com>
	<5373758E.9060700@redhat.com>	<53738129.30709@redhat.com>	<1734718658.5454347.1400079220862.JavaMail.zimbra@redhat.com>	<54DA7432.8080207@redhat.com>
	<54DB72E7.4030505@redhat.com>
Message-ID: <54DB81A7.9020401@redhat.com>

Yes; you should be able to do basically anything you could do with the 
CLI with a remote standalone server.

Only exception that comes to mind is

shutdown --restart=true

That relies on the startup scripts to relaunch the process. Could be 
done inside the CLI, but I don't think it's worth making it a priority.

On 2/11/15 9:19 AM, Stan Silvert wrote:
> Can you upload deployments and overlays in offline mode?  That would
> make this something that you can't do by just editing the standalone.xml.
>
> On 2/10/2015 4:12 PM, Brian Stansberry wrote:
>> I had some time over the holidays and on planes to progress quite a bit
>> on this. A standalone server protype is at [1]. A fairly in depth
>> description is on the WildFly Development wiki at [2].
>>
>> I tried pretty hard to have clean commits on that branch, one per issue
>> I faced. So looking at the commits is worthwhile to get a better
>> understanding of particular aspects.
>>
>> Some notes on what I did / issues to discuss:
>>
>> 1) I semi-ported the "embedded" module from WildFly full to WildFly
>> Core. "Semi" in the sense that the code is now in both places, under
>> different maven GAVs and ending up in differently named modules in full.
>> We need to regularize this; decide if there's any point in a "full"
>> version of embedded, decide what to do about any APIs we don't want in
>> the core version. (There are some deprecated methods, and one method
>> "Context getContext()" that doesn't mean much in core, which has no JNDI.)
>>
>> 2) The CLI's use of stdio needed to be tweaked a bit to make it possible
>> to control what the embedded server does with stdout. That's in the
>> "Remove direct use of System.out by most CLI code" commit at [1].
>>
>> 3) I needed to deal with some general embedding issues in the server;
>> i.e. things that would probably pop up in any embedded use case:
>>
>> a) controlling the LogContext so the embedded server logging can be
>> managed independent of the embedding app. See "Let apps that embed
>> WildFly control the LogContext" commit at [1].
>>
>> I don't think this is real solid though. For example, I expect CLI-side
>> loggers that happen to get created after the embedded server starts will
>> end up using the server LogContext.
>>
>> b) the server was calling System.exit in some places. See "[WFCORE-528]
>> Use SystemExiter, not System.exit" commit at [1].
>>
>> c) the embedded server code didn't deal with reload, leaving behind a
>> broken ModelControllerClient. See "[WFCORE-511] Support reload in the
>> embedded server" commit at [1].
>>
>> 4) The modular vs non-modular environment aspects discussed at "Modular
>> vs Non-Modular Classloading and JBOSS_HOME" in [2] are not ideal. I'm
>> not sure how far we can/should go in improving this though.
>>
>> 5) This is painfully lacking in tests!
>>
>> Comments and suggestions are welcome!
>>
>> Cheers,
>> Brian
>>
>> [1] https://github.com/bstansberry/wildfly-core/commits/cli-embed-server
>>
>> [2] https://developer.jboss.org/docs/DOC-53050
>>
>> On 5/14/14 9:53 AM, John Mazzitelli wrote:
>>> How topical :) The RHQ installer could use this - just this very second I'm debugging and trying to figure out why the RHQ installer can't connect to the running app server instance to do its initial config setup - having to try to figure out what port its running on and why I can't connect is a pain.
>>>
>>> ----- Original Message -----
>>>> Moving a thread to the dev list.
>>>>
>>>> This is about some prototyping I've been doing on weekends 'cause I'm
>>>> bored with my regular tasks. I've been playing with direct local
>>>> administration of a WF installation via the CLI without requiring a
>>>> socket-based connection. The general use case is initial setup type
>>>> activities where the user doesn't want to have to launch a WF server or
>>>> HC process and potentially have it be visible on the network.
>>>> https://issues.jboss.org/browse/WFLY-3288 is one use case; another is a
>>>> desire some folks have expressed in being able to do configuration
>>>> without first having to edit any xml to avoid port conflicts on 9990 or
>>>> 9999.
>>>>
>>>> This isn't a major initiative or big priority or anything at this point.
>>>> Just something I find interesting and perhaps you will too.
>>>>
>>>> On 5/14/14, 8:54 AM, Alexey Loubyansky wrote:
>>>>> Neat :) Yes, figuring out the module path is biting everywhere.
>>>>> For file system path command line arguments there is a specialized
>>>>> FileSystemPathArgument.
>>>>>
>>>> Thanks; I'll switch to that.
>>>>
>>>>> On 05/13/2014 10:54 PM, Brian Stansberry wrote:
>>>>>> Copying Heiko Braun as he expressed some interest in the topic.
>>>>>>
>>>>>> BTW, I played with this a bit more last weekend and was able to start an
>>>>>> embedded server inside the CLI easily enough. See [1] for very raw
>>>>>> prototype stuff. You can run bin/jboss-cli.sh (no -c) and then
>>>>>>
>>>>>> [disconnected/] embed-server
>>>>>>
>>>>>> There are a couple issues I see, besides the HC stuff I mentioned in my
>>>>>> last message.
>>>>>>
>>>>>> 1) If the CLI is started in a non-modular environment via java -jar
>>>>>> bin/client/jboss-cli-client.jar, we'd have to shade jboss-modules into
>>>>>> the jar. And then the embed-server command would need params specifying
>>>>>> the location of JBOSS_HOME, possibly module path etc. But it could embed
>>>>>> a server installed in any accessible filesystem location.
>>>>>>
>>>>>> But what I did at [1] is based on bin/jboss-cli.sh, where the CLI is
>>>>>> running from a WF dist in a modular environment and the embedded server
>>>>>> modules are coming from the CLI's own module path. It would be more
>>>>>> effort to support embedding a server based on some other module path.
>>>>>> Maybe it's no big deal; maybe it's really hard. :)
>>>>>>
>>>>>> 2) The console logging from the embedded server goes to stdout mixed in
>>>>>> with the CLI output. Maybe that's good, maybe it's bad.
>>>>>>
>>>>>> [1] https://github.com/bstansberry/wildfly/tree/cli-embed
>>>>>>
>>>>>> On 4/28/14, 10:04 AM, Brian Stansberry wrote:
>>>>>>> I was poking around at this for an hour or so over the weekend.
>>>>>>>
>>>>>>> The standalone case seems pretty straightforward. Seems the existing
>>>>>>> embedded server API could work readily enough. The
>>>>>>> org.jboss.as.embedded.StandaloneServer interface already provides a
>>>>>>> ModelControllerClient.
>>>>>>>
>>>>>>> The domain case is much harder, as the CLI wants a HostController, not a
>>>>>>> ProcessController. I'd really like this to use an in-VM client, not a
>>>>>>> remote one, so I don't like having the CLI embed a PC and then the HC is
>>>>>>> an external process. My thoughts of the morning are to allow inverting
>>>>>>> the HC/PC relationship for this kind of usage. That is, remove
>>>>>>> controlling the HC lifecycle from the charge of the PC component. CLI
>>>>>>> launches HC, and then the HC creates an in-process PC-ish component (not
>>>>>>> a separate process) to manage the server lifecycles. There could be all
>>>>>>> sorts of problems with that; it's just the thought for the morning.
>>>>>>>
>>>>>>> On 4/25/14, 11:49 AM, Alexey Loubyansky wrote:
>>>>>>>> Embedding the AS is the best starting point to achieve that! And more
>>>>>>>> fun, I agree :)
>>>>>>>>
>>>>>>>> On 04/25/2014 06:28 PM, Darran Lofthouse wrote:
>>>>>>>>> And to think my reason for opening the Jira was just for a common
>>>>>>>>> way to
>>>>>>>>> mask password inputs where java.io.Console is not available ;-)
>>>>>>>>>
>>>>>>>>> On 25/04/14 17:09, Brian Stansberry wrote:
>>>>>>>>>> On 4/25/14, 10:40 AM, Alexey Loubyansky wrote:
>>>>>>>>>>> Wow! Indeed :)
>>>>>>>>>>>
>>>>>>>>>>> There could be an embedded scope - true, i.e. commands available
>>>>>>>>>>> only
>>>>>>>>>>> this mode, like add-user, module mgmt related stuff, etc.
>>>>>>>>>> Those commands wouldn't need to be only in that mode though. The
>>>>>>>>>> implementation of all of them would be based in the server; the
>>>>>>>>>> "client"
>>>>>>>>>> aspect of the CLI would just use the management interface. The
>>>>>>>>>> difference between an embedded mode and what we have now would
>>>>>>>>>> just be
>>>>>>>>>> in how the "client" side gets its ModelControllerClient -- what we
>>>>>>>>>> have
>>>>>>>>>> now vs starting an embedded server and getting some sort of in-vm
>>>>>>>>>> client.
>>>>>>>>>>
>>>>>>>>>>> But it would still mean the server/controller would have to actually
>>>>>>>>>>> provide implementations of that functionality and expose it to the
>>>>>>>>>>> management tools like the CLI in the embedded mode.
>>>>>>>>>> Yep.
>>>>>>>>>>
>>>>>>>>>>> I like this idea as a concept - direct local management. W/o any
>>>>>>>>>>> remote
>>>>>>>>>>> connect/re-connect/disconnect burden.
>>>>>>>>>>>
>>>>>>>>>>> Extending the CLI with custom modules is on the list too. It's
>>>>>>>>>>> probably
>>>>>>>>>>> easier to implement at this point.
>>>>>>>>>>>
>>>>>>>>>> Likely so, but maybe less fun. ;) I copied you on a PRD-related
>>>>>>>>>> thread
>>>>>>>>>> where I briefly get into this general area too.
>>>>>>>>>>
>>>>>>>>>>> Alexey
>>>>>>>>>>>
>>>>>>>>>>> On 04/25/2014 05:00 PM, Brian Stansberry wrote:
>>>>>>>>>>>> Hi Alexey,
>>>>>>>>>>>>
>>>>>>>>>>>> Wanted to point the discussion on this JIRA out to you as it gets
>>>>>>>>>>>> into
>>>>>>>>>>>> some fairly fundamental brainstorming that you may find
>>>>>>>>>>>> interesting.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -------- Original Message --------
>>>>>>>>>>>> Subject: [JBoss JIRA] (WFLY-3288) Update add-user to use AESH or
>>>>>>>>>>>> move it
>>>>>>>>>>>> into the CLI
>>>>>>>>>>>> Date: Fri, 25 Apr 2014 09:44:35 -0400 (EDT)
>>>>>>>>>>>> From: Darran Lofthouse (JIRA) <issues at jboss.org>
>>>>>>>>>>>> To: brian.stansberry at redhat.com
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>         [
>>>>>>>>>>>> https://issues.jboss.org/browse/WFLY-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12963854#comment-12963854
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ]
>>>>>>>>>>>>
>>>>>>>>>>>> Darran Lofthouse commented on WFLY-3288:
>>>>>>>>>>>> ----------------------------------------
>>>>>>>>>>>>
>>>>>>>>>>>> That could be very interested, won't go into too much detail in
>>>>>>>>>>>> this
>>>>>>>>>>>> Jira as it is not directly related shortly I am switching to the
>>>>>>>>>>>> SSL
>>>>>>>>>>>> related tasks we have outstanding including the out of the box
>>>>>>>>>>>> enablement we talked about in Brno - managing an embedded instance
>>>>>>>>>>>> could
>>>>>>>>>>>> be useful there as well to get it all op based.
>>>>>>>>>>>>
>>>>>>>>>>>> I can see this task may end up coming back my way combined with the
>>>>>>>>>>>> other stuff ;-)
>>>>>>>>>>>>
>>>>>>>>>>>>> Update add-user to use AESH or move it into the CLI
>>>>>>>>>>>>> ---------------------------------------------------
>>>>>>>>>>>>>
>>>>>>>>>>>>>                    Key: WFLY-3288
>>>>>>>>>>>>>                    URL: https://issues.jboss.org/browse/WFLY-3288
>>>>>>>>>>>>>                Project: WildFly
>>>>>>>>>>>>>             Issue Type: Feature Request
>>>>>>>>>>>>>         Security Level: Public(Everyone can see)
>>>>>>>>>>>>>             Components: Domain Management, Scripts
>>>>>>>>>>>>>               Reporter: Darran Lofthouse
>>>>>>>>>>>>>                Fix For: Awaiting Volunteers
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Within the add-user utility it is difficult to handle situations
>>>>>>>>>>>>> where
>>>>>>>>>>>>> we do not have access to a java.io.Console which is the easiest
>>>>>>>>>>>>> way to
>>>>>>>>>>>>> handle password reading without an echo to the user e.g. in Cygwin
>>>>>>>>>>>>> Switching to AESH would allow us to use the implementation
>>>>>>>>>>>>> there to
>>>>>>>>>>>>> handle this.
>>>>>>>>>>>>> Alternatively it may actually make sense to make add-user a
>>>>>>>>>>>>> special
>>>>>>>>>>>>> mode of the CLI, we may at some point want to switch to runtime
>>>>>>>>>>>>> operations being executed on the server so porting to the CLI
>>>>>>>>>>>>> could be
>>>>>>>>>>>>> the first step to make this possible.
>>>>>>>>>>>>> Overall this is going to require further discussion so the
>>>>>>>>>>>>> comments
>>>>>>>>>>>>> here are just a starting point.
>>>>>>>>>>>> --
>>>>>>>>>>>> This message is automatically generated by JIRA.
>>>>>>>>>>>> If you think it was sent incorrectly, please contact your JIRA
>>>>>>>>>>>> administrators
>>>>>>>>>>>> For more information on JIRA, see:
>>>>>>>>>>>> http://www.atlassian.com/software/jira
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>> --
>>>> Brian Stansberry
>>>> Senior Principal Software Engineer
>>>> JBoss by Red Hat
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


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

From smarlow at redhat.com  Wed Feb 11 17:23:30 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 11 Feb 2015 17:23:30 -0500
Subject: [wildfly-dev] Moving WildFly 9 to Java 8?
In-Reply-To: <CAMquZP6suP_2Y2CMJhNV4cjDwrfCsJU3sBz4OAPt4n18Ju+v3w@mail.gmail.com>
References: <CAMquZP74p17yOuWFtK3YXwCyA2Ps1N7bEZ4nNzwekqt0qNyCcQ@mail.gmail.com>	<54D92AC2.3090302@redhat.com>
	<54DA059B.2070706@redhat.com>	<CAMquZP5kiWptkCHomSo8KthBdE-Gt-RXq0CV3MB4XsCWQt54ww@mail.gmail.com>	<54DA7DAF.4060102@redhat.com>
	<CAMquZP6suP_2Y2CMJhNV4cjDwrfCsJU3sBz4OAPt4n18Ju+v3w@mail.gmail.com>
Message-ID: <54DBD662.4060603@redhat.com>



On 02/10/2015 05:03 PM, Toma? Cerar wrote:
>
> On Tue, Feb 10, 2015 at 10:52 PM, Scott Marlow <smarlow at redhat.com
> <mailto:smarlow at redhat.com>> wrote:
>
>
>     The Java 8 TCK update is for EE 6, not EE 7.  The EE 7 TCK might
>     also pass with Java 8 (we should try that independent of which Java
>     version we require).
>
> Aha, this is what i was interested in.
> Any chance you can try with JDK8 against current master?

Doing this now.

>
>
>         Scott, can you confirm this?
>
>
>      >From the EE 7 platform specification:
>
>     "
>     EE.9.5
>
>     Requirements for All Java EE Profiles
>
>     The Java Platform, Standard Edition 7 is the required foundation for
>     any Java EE 7 profile.
>
> Yes, but that doesn't say that is the only version that is required.
>
> *EE.2.4.1 Container Requirements*
> "This specification requires that containers provide a Java Compatible?
> runtime environment, as defined by the Java Platform, Standard Edition,
> v7 specification (Java SE)."
>
> Which means any Java runtime that is compatible with v7 is fine, and as
> far as we know 8 is backward compatible, as it provides all v7 does and
> more.

Being able to run with Java 7 is what I get out of either the profile or 
the container requirements, both seem to state the requirement for V7. 
This sounds like a question for the EE 7 expert group (perhaps they 
didn't really mean that Java 7 could be used to run an EE 7 implementation).

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

From rodakr at gmx.ch  Wed Feb 11 18:27:20 2015
From: rodakr at gmx.ch (Radoslaw Rodak)
Date: Thu, 12 Feb 2015 00:27:20 +0100
Subject: [wildfly-dev] Moving WildFly 9 to Java 8?
In-Reply-To: <54DBD662.4060603@redhat.com>
References: <CAMquZP74p17yOuWFtK3YXwCyA2Ps1N7bEZ4nNzwekqt0qNyCcQ@mail.gmail.com>	<54D92AC2.3090302@redhat.com>
	<54DA059B.2070706@redhat.com>	<CAMquZP5kiWptkCHomSo8KthBdE-Gt-RXq0CV3MB4XsCWQt54ww@mail.gmail.com>	<54DA7DAF.4060102@redhat.com>
	<CAMquZP6suP_2Y2CMJhNV4cjDwrfCsJU3sBz4OAPt4n18Ju+v3w@mail.gmail.com>
	<54DBD662.4060603@redhat.com>
Message-ID: <ADD4C454-FBF3-405E-B48C-8F75ED132465@gmx.ch>

Mabe this could help? 

javac -source 1.7 -target 1.7 -bootclasspath /usr/lib/jvm/java-7-oracle/jre/lib/rt.jar 



Am 11.02.2015 um 23:23 schrieb Scott Marlow <smarlow at redhat.com>:

> 
> 
> On 02/10/2015 05:03 PM, Toma? Cerar wrote:
>> 
>> On Tue, Feb 10, 2015 at 10:52 PM, Scott Marlow <smarlow at redhat.com
>> <mailto:smarlow at redhat.com>> wrote:
>> 
>> 
>>    The Java 8 TCK update is for EE 6, not EE 7.  The EE 7 TCK might
>>    also pass with Java 8 (we should try that independent of which Java
>>    version we require).
>> 
>> Aha, this is what i was interested in.
>> Any chance you can try with JDK8 against current master?
> 
> Doing this now.
> 
>> 
>> 
>>        Scott, can you confirm this?
>> 
>> 
>>> From the EE 7 platform specification:
>> 
>>    "
>>    EE.9.5
>> 
>>    Requirements for All Java EE Profiles
>> 
>>    The Java Platform, Standard Edition 7 is the required foundation for
>>    any Java EE 7 profile.
>> 
>> Yes, but that doesn't say that is the only version that is required.
>> 
>> *EE.2.4.1 Container Requirements*
>> "This specification requires that containers provide a Java Compatible?
>> runtime environment, as defined by the Java Platform, Standard Edition,
>> v7 specification (Java SE)."
>> 
>> Which means any Java runtime that is compatible with v7 is fine, and as
>> far as we know 8 is backward compatible, as it provides all v7 does and
>> more.
> 
> Being able to run with Java 7 is what I get out of either the profile or 
> the container requirements, both seem to state the requirement for V7. 
> This sounds like a question for the EE 7 expert group (perhaps they 
> didn't really mean that Java 7 could be used to run an EE 7 implementation).
> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> 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/20150212/693ea522/attachment.html 

From tomaz.cerar at gmail.com  Wed Feb 11 18:34:05 2015
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Thu, 12 Feb 2015 00:34:05 +0100
Subject: [wildfly-dev] Moving WildFly 9 to Java 8?
In-Reply-To: <ADD4C454-FBF3-405E-B48C-8F75ED132465@gmx.ch>
References: <CAMquZP74p17yOuWFtK3YXwCyA2Ps1N7bEZ4nNzwekqt0qNyCcQ@mail.gmail.com>
	<54D92AC2.3090302@redhat.com> <54DA059B.2070706@redhat.com>
	<CAMquZP5kiWptkCHomSo8KthBdE-Gt-RXq0CV3MB4XsCWQt54ww@mail.gmail.com>
	<54DA7DAF.4060102@redhat.com>
	<CAMquZP6suP_2Y2CMJhNV4cjDwrfCsJU3sBz4OAPt4n18Ju+v3w@mail.gmail.com>
	<54DBD662.4060603@redhat.com>
	<ADD4C454-FBF3-405E-B48C-8F75ED132465@gmx.ch>
Message-ID: <CAMquZP7JXy3wrSJukAdHTZazgcUHURjPz9LHOf2e8ARaF9hyOw@mail.gmail.com>

On Thu, Feb 12, 2015 at 12:27 AM, Radoslaw Rodak <rodakr at gmx.ch> wrote:

> Mabe this could help?
>
> javac -source 1.7 -target 1.7 -bootclasspath
> /usr/lib/jvm/java-7-oracle/jre/lib/rt.jar
>


that already works, you can run WildFly without any problems (that we know
of) on JDK 8.
We also run CI jobs to make sure of that.

But WildFly is still compiled for -target 1.7, my original question is
whether should we move to -target 1.8

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

From rodakr at gmx.ch  Wed Feb 11 18:52:00 2015
From: rodakr at gmx.ch (Radoslaw Rodak)
Date: Thu, 12 Feb 2015 00:52:00 +0100
Subject: [wildfly-dev] Moving WildFly 9 to Java 8?
In-Reply-To: <CAMquZP7JXy3wrSJukAdHTZazgcUHURjPz9LHOf2e8ARaF9hyOw@mail.gmail.com>
References: <CAMquZP74p17yOuWFtK3YXwCyA2Ps1N7bEZ4nNzwekqt0qNyCcQ@mail.gmail.com>
	<54D92AC2.3090302@redhat.com> <54DA059B.2070706@redhat.com>
	<CAMquZP5kiWptkCHomSo8KthBdE-Gt-RXq0CV3MB4XsCWQt54ww@mail.gmail.com>
	<54DA7DAF.4060102@redhat.com>
	<CAMquZP6suP_2Y2CMJhNV4cjDwrfCsJU3sBz4OAPt4n18Ju+v3w@mail.gmail.com>
	<54DBD662.4060603@redhat.com>
	<ADD4C454-FBF3-405E-B48C-8F75ED132465@gmx.ch>
	<CAMquZP7JXy3wrSJukAdHTZazgcUHURjPz9LHOf2e8ARaF9hyOw@mail.gmail.com>
Message-ID: <0CE886CB-6B3B-47BD-B29D-14C4F3176980@gmx.ch>

Which means,  dropping Java 7 which is EOL in 2 Months ?


Am 12.02.2015 um 00:34 schrieb Toma? Cerar <tomaz.cerar at gmail.com>:

> 
> On Thu, Feb 12, 2015 at 12:27 AM, Radoslaw Rodak <rodakr at gmx.ch> wrote:
> Mabe this could help? 
> 
> javac -source 1.7 -target 1.7 -bootclasspath /usr/lib/jvm/java-7-oracle/jre/lib/rt.jar 
> 
> 
> that already works, you can run WildFly without any problems (that we know of) on JDK 8.
> We also run CI jobs to make sure of that.
> 
> But WildFly is still compiled for -target 1.7, my original question is whether should we move to -target 1.8
> 
> --
> tomaz

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

From jason.greene at redhat.com  Wed Feb 11 19:08:32 2015
From: jason.greene at redhat.com (Jason T. Greene)
Date: Wed, 11 Feb 2015 19:08:32 -0500 (EST)
Subject: [wildfly-dev] Moving WildFly 9 to Java 8?
In-Reply-To: <CAMquZP74p17yOuWFtK3YXwCyA2Ps1N7bEZ4nNzwekqt0qNyCcQ@mail.gmail.com>
References: <CAMquZP74p17yOuWFtK3YXwCyA2Ps1N7bEZ4nNzwekqt0qNyCcQ@mail.gmail.com>
Message-ID: <9C0624D6-47E3-4C73-A2C9-366620523F23@redhat.com>

I don't understand the hurry.

> On Feb 9, 2015, at 3:20 PM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
> 
> Hi folks,
> 
> we agreed that WildFly 10+ is going to require Java 8, given that its release date is planned well after JDK7 will be EOL-ed. [1]
> 
> Looking at all discussion and new projects / components already require JDK8 (Eltryon, new WildFly client, Weld 3,...) for development.
> I was wondering if we could move WildFly 9 to Java 8 as well? 
> 
> According to current release plan WF9 should be release around the same time JDK7 is EOL-ed (April 2015) [1]
> 
> Pros of moving to JDK8 early:
> - components can use JDK8 eariler --> better testing 
> - supporting JDK9 will be easier (-XX:MaxPermSize fails to start JVM on 9)
> - support for TLS SNI (think of it as virtual hosts for SSL)
> - better ciphers and many other security related improvements
> - nashorn (fast javascript engine)
> - better concurrency libs
> - easier testing, one less JDK combo to test on CI
> 
> and of course all of the language improvements, lambda ftw!
> 
> Cons of moving early
> 
> - back porting of code could be impaired 
> - there is currently no non beta release of IBM JDK8 
> 
> There are probably other pros & cons but in general I think it would be better to upgrade early as there will be many
> hidden issues with new Java 8 features people want to use but are server doesn't understand currently, mostly here
> are features like enhanced type annotations and default methods.
> 
> This problem are and will creep up more and more often as adoption of Java 8 is quite good already [2] and still rising.
> 
> so what do you guys think? Should we move for WildFly or should we wait for 10 as planned?
> 
> --
> tomaz
> 
> 
> [1] http://www.oracle.com/technetwork/java/eol-135779.html
> [2] http://jaxenter.com/java-2-111936.html
> _______________________________________________
> 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/20150211/b02b0a8d/attachment-0001.html 

From Hielke.Hoeve at topicus.nl  Thu Feb 12 03:02:27 2015
From: Hielke.Hoeve at topicus.nl (Hielke Hoeve)
Date: Thu, 12 Feb 2015 08:02:27 +0000
Subject: [wildfly-dev] Moving WildFly 9 to Java 8?
In-Reply-To: <CAMquZP7JXy3wrSJukAdHTZazgcUHURjPz9LHOf2e8ARaF9hyOw@mail.gmail.com>
References: <CAMquZP74p17yOuWFtK3YXwCyA2Ps1N7bEZ4nNzwekqt0qNyCcQ@mail.gmail.com>
	<54D92AC2.3090302@redhat.com> <54DA059B.2070706@redhat.com>
	<CAMquZP5kiWptkCHomSo8KthBdE-Gt-RXq0CV3MB4XsCWQt54ww@mail.gmail.com>
	<54DA7DAF.4060102@redhat.com>
	<CAMquZP6suP_2Y2CMJhNV4cjDwrfCsJU3sBz4OAPt4n18Ju+v3w@mail.gmail.com>
	<54DBD662.4060603@redhat.com>
	<ADD4C454-FBF3-405E-B48C-8F75ED132465@gmx.ch>
	<CAMquZP7JXy3wrSJukAdHTZazgcUHURjPz9LHOf2e8ARaF9hyOw@mail.gmail.com>
Message-ID: <3F3F24BE-0C19-4EEF-ACBB-DDBE8588FEF5@topicus.nl>

We are currently running multiple projects in Wildly using Oracles Java 8.31 without any problems. So why hurry and change the target so quickly?

Regards,

Hielke Hoeve

On 12 Feb 2015, at 00:34, Toma? Cerar <tomaz.cerar at gmail.com<mailto:tomaz.cerar at gmail.com>> wrote:


On Thu, Feb 12, 2015 at 12:27 AM, Radoslaw Rodak <rodakr at gmx.ch<mailto:rodakr at gmx.ch>> wrote:
Mabe this could help?

javac -source 1.7 -target 1.7 -bootclasspath /usr/lib/jvm/java-7-oracle/jre/lib/rt.jar


that already works, you can run WildFly without any problems (that we know of) on JDK 8.
We also run CI jobs to make sure of that.

But WildFly is still compiled for -target 1.7, my original question is whether should we move to -target 1.8

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

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

From tomaz.cerar at gmail.com  Thu Feb 12 08:31:07 2015
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Thu, 12 Feb 2015 14:31:07 +0100
Subject: [wildfly-dev] Arquillian-core 1.1.7 is now in master
Message-ID: <CAMquZP6NQt34c4rs38xgPMGWS5C8D_bqDSjREr3+N9A4-VCfzg@mail.gmail.com>

He guys,

just heads up that arquillian-core was upgraded from our fork of 1.1.2 to
latest official 1.1.7.Final.

Everything should still work and even work better.
But if you do see any problems in our testsuite that resulted as part of
this let me know.


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

From vtunka at redhat.com  Thu Feb 12 10:17:52 2015
From: vtunka at redhat.com (Vaclav Tunka)
Date: Thu, 12 Feb 2015 16:17:52 +0100
Subject: [wildfly-dev] WildFly Core Alpha17 released
In-Reply-To: <54D8FB3A.7000903@redhat.com>
References: <54D8FB3A.7000903@redhat.com>
Message-ID: <54DCC420.6030207@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Congratulations!

On 9.2.2015 19:23, Brian Stansberry wrote:
> The latest in our roughly weekly series of WildFly Core alphas has
> been released and merged into full WildFly's master branch.
> 

- -- 
Vaclav Tunka
Application Platforms Engineering
Red Hat JBoss Middleware
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJU3MQgAAoJEESFXW/gx7jYG7cP/ipnOI0KII4WqQElVes9XeEk
ICY/t8z+9adXDf7P2b6uex8OKLI7yNry+4V2uwXV1NumKWrccpCD5kmc0GyNyqpD
N5SrmMAvNobptlj8bk65Tx9hQYHUH7XRobHEm7SGuLQMlvyU5gmBtGfT5gjWNGdW
KdSdzJb5XR/5pYqjuJLjjJUSnPnzblRNWM99RLMEY9ytg4TCWpGLHmAxrbL2hk6a
XnQveSGMwazGht1CfFQmu4G3u0M0Zvf4UPFUXROVuUYlHL/qzbDdRtQ7GvaAjmus
dbthloXxyUEcGmYytyE4wA5PDwy0yNKMZRE1VrFk9fN8A4Hrmkbcpxm3hm3uROrJ
B0OKmJlrDkE9zOiZnCeyNpTAR5PqwmIGlKU/TNlYS6G7R6H8UYsUOtwJ7Ht87AH0
EqS+GUO7Rx4JBZUkMlgCJrQPmHsG8G5V6sWPI5hlSDwWDdGUDDtz+a3ZgnUK4kA8
e19GGFOXgyZ60RHytuOiBMTG/2/r2qtqWqBenTocmqpE0/8d0HvbYp+0Xi8mVG6O
JnIGqgWM+XSYYVe9nMCvaK/Ei8fW0MH8w4CdMOd/w9/shUImIbkLGz/bToQGN147
s7IX4FTRoPk/+tRw/Q3UJGDcVe1lfa0HzyodTx9lWUsYC4uehuFeVhy0cflkeCOI
m545RTH28HlOwdgP4PWI
=qJAb
-----END PGP SIGNATURE-----

From jason.greene at redhat.com  Thu Feb 12 10:26:18 2015
From: jason.greene at redhat.com (Jason T. Greene)
Date: Thu, 12 Feb 2015 10:26:18 -0500 (EST)
Subject: [wildfly-dev] Moving WildFly 9 to Java 8?
In-Reply-To: <9C0624D6-47E3-4C73-A2C9-366620523F23@redhat.com>
References: <CAMquZP74p17yOuWFtK3YXwCyA2Ps1N7bEZ4nNzwekqt0qNyCcQ@mail.gmail.com>
	<9C0624D6-47E3-4C73-A2C9-366620523F23@redhat.com>
Message-ID: <1D0B3A4E-C3D8-4E2E-9526-83A03C104048@redhat.com>

Why don't we start with just moving the PR testing stuff to 8? And then have a one off 7 run. 


Sent from my iPhone

> On Feb 11, 2015, at 6:15 PM, Jason T. Greene <jason.greene at redhat.com> wrote:
> 
> I don't understand the hurry.
> 
>> On Feb 9, 2015, at 3:20 PM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
>> 
>> Hi folks,
>> 
>> we agreed that WildFly 10+ is going to require Java 8, given that its release date is planned well after JDK7 will be EOL-ed. [1]
>> 
>> Looking at all discussion and new projects / components already require JDK8 (Eltryon, new WildFly client, Weld 3,...) for development.
>> I was wondering if we could move WildFly 9 to Java 8 as well? 
>> 
>> According to current release plan WF9 should be release around the same time JDK7 is EOL-ed (April 2015) [1]
>> 
>> Pros of moving to JDK8 early:
>> - components can use JDK8 eariler --> better testing 
>> - supporting JDK9 will be easier (-XX:MaxPermSize fails to start JVM on 9)
>> - support for TLS SNI (think of it as virtual hosts for SSL)
>> - better ciphers and many other security related improvements
>> - nashorn (fast javascript engine)
>> - better concurrency libs
>> - easier testing, one less JDK combo to test on CI
>> 
>> and of course all of the language improvements, lambda ftw!
>> 
>> Cons of moving early
>> 
>> - back porting of code could be impaired 
>> - there is currently no non beta release of IBM JDK8 
>> 
>> There are probably other pros & cons but in general I think it would be better to upgrade early as there will be many
>> hidden issues with new Java 8 features people want to use but are server doesn't understand currently, mostly here
>> are features like enhanced type annotations and default methods.
>> 
>> This problem are and will creep up more and more often as adoption of Java 8 is quite good already [2] and still rising.
>> 
>> so what do you guys think? Should we move for WildFly or should we wait for 10 as planned?
>> 
>> --
>> tomaz
>> 
>> 
>> [1] http://www.oracle.com/technetwork/java/eol-135779.html
>> [2] http://jaxenter.com/java-2-111936.html
>> _______________________________________________
>> 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/20150212/e73f9a86/attachment.html 

From tomaz.cerar at gmail.com  Thu Feb 12 16:06:01 2015
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Thu, 12 Feb 2015 22:06:01 +0100
Subject: [wildfly-dev] Moving WildFly 9 to Java 8?
In-Reply-To: <1D0B3A4E-C3D8-4E2E-9526-83A03C104048@redhat.com>
References: <CAMquZP74p17yOuWFtK3YXwCyA2Ps1N7bEZ4nNzwekqt0qNyCcQ@mail.gmail.com>
	<9C0624D6-47E3-4C73-A2C9-366620523F23@redhat.com>
	<1D0B3A4E-C3D8-4E2E-9526-83A03C104048@redhat.com>
Message-ID: <CAMquZP62=oi-cRk2B3Fp5AknCMKSRsih=+sR7CN9P3J-6QFZog@mail.gmail.com>

That won't really change much, we could do that now and there wouldn't be
any issues.

Thing is that our testsuite won't catch anything more as our testsuite will
still be using JDK7 features
and as such wont really test how server behaves when JDK8 lang/jdk features
are in use in deployments.

I guess first step would be to move PR processing to JDK8 while still use
JDK7 for master & master-ignore

On Thu, Feb 12, 2015 at 4:26 PM, Jason T. Greene <jason.greene at redhat.com>
wrote:

> Why don't we start with just moving the PR testing stuff to 8? And then
> have a one off 7 run.
>
>
> Sent from my iPhone
>
> On Feb 11, 2015, at 6:15 PM, Jason T. Greene <jason.greene at redhat.com>
> wrote:
>
> I don't understand the hurry.
>
> On Feb 9, 2015, at 3:20 PM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
>
> Hi folks,
>
> we agreed that WildFly 10+ is going to require Java 8, given that its
> release date is planned well after JDK7 will be EOL-ed. [1]
>
> Looking at all discussion and new projects / components already require
> JDK8 (Eltryon, new WildFly client, Weld 3,...) for development.
> I was wondering if we could move WildFly 9 to Java 8 as well?
>
> According to current release plan WF9 should be release around the same
> time JDK7 is EOL-ed (April 2015) [1]
>
> Pros of moving to JDK8 early:
> - components can use JDK8 eariler --> better testing
> - supporting JDK9 will be easier (-XX:MaxPermSize fails to start JVM on 9)
> - support for TLS SNI (think of it as virtual hosts for SSL)
> - better ciphers and many other security related improvements
> - nashorn (fast javascript engine)
> - better concurrency libs
> - easier testing, one less JDK combo to test on CI
>
> and of course all of the language improvements, lambda ftw!
>
> Cons of moving early
>
> - back porting of code could be impaired
> - there is currently no non beta release of IBM JDK8
>
> There are probably other pros & cons but in general I think it would be
> better to upgrade early as there will be many
> hidden issues with new Java 8 features people want to use but are server
> doesn't understand currently, mostly here
> are features like enhanced type annotations and default methods.
>
> This problem are and will creep up more and more often as adoption of Java
> 8 is quite good already [2] and still rising.
>
> so what do you guys think? Should we move for WildFly or should we wait
> for 10 as planned?
>
> --
> tomaz
>
>
> [1] http://www.oracle.com/technetwork/java/eol-135779.html
> [2] http://jaxenter.com/java-2-111936.html
>
> _______________________________________________
> 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/20150212/f7955212/attachment-0001.html 

From jason.greene at redhat.com  Thu Feb 12 16:22:39 2015
From: jason.greene at redhat.com (Jason Greene)
Date: Thu, 12 Feb 2015 15:22:39 -0600
Subject: [wildfly-dev] Moving WildFly 9 to Java 8?
In-Reply-To: <CAMquZP62=oi-cRk2B3Fp5AknCMKSRsih=+sR7CN9P3J-6QFZog@mail.gmail.com>
References: <CAMquZP74p17yOuWFtK3YXwCyA2Ps1N7bEZ4nNzwekqt0qNyCcQ@mail.gmail.com>
	<9C0624D6-47E3-4C73-A2C9-366620523F23@redhat.com>
	<1D0B3A4E-C3D8-4E2E-9526-83A03C104048@redhat.com>
	<CAMquZP62=oi-cRk2B3Fp5AknCMKSRsih=+sR7CN9P3J-6QFZog@mail.gmail.com>
Message-ID: <EF83ABD3-6B73-476D-8A14-6C1C692D6895@redhat.com>


> On Feb 12, 2015, at 3:06 PM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
> 
> That won't really change much, we could do that now and there wouldn't be any issues.
> 
> Thing is that our testsuite won't catch anything more as our testsuite will still be using JDK7 features
> and as such wont really test how server behaves when JDK8 lang/jdk features are in use in deployments.

Sure but that will be the same whether we are on 8 or not, because we won?t have time to go adding lots of 8 code everywhere.

> 
> I guess first step would be to move PR processing to JDK8 while still use JDK7 for master & master-ignore
> 
> On Thu, Feb 12, 2015 at 4:26 PM, Jason T. Greene <jason.greene at redhat.com> wrote:
> Why don't we start with just moving the PR testing stuff to 8? And then have a one off 7 run. 
> 
> 
> Sent from my iPhone
> 
> On Feb 11, 2015, at 6:15 PM, Jason T. Greene <jason.greene at redhat.com> wrote:
> 
>> I don't understand the hurry.
>> 
>> On Feb 9, 2015, at 3:20 PM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
>> 
>>> Hi folks,
>>> 
>>> we agreed that WildFly 10+ is going to require Java 8, given that its release date is planned well after JDK7 will be EOL-ed. [1]
>>> 
>>> Looking at all discussion and new projects / components already require JDK8 (Eltryon, new WildFly client, Weld 3,...) for development.
>>> I was wondering if we could move WildFly 9 to Java 8 as well? 
>>> 
>>> According to current release plan WF9 should be release around the same time JDK7 is EOL-ed (April 2015) [1]
>>> 
>>> Pros of moving to JDK8 early:
>>> - components can use JDK8 eariler --> better testing 
>>> - supporting JDK9 will be easier (-XX:MaxPermSize fails to start JVM on 9)
>>> - support for TLS SNI (think of it as virtual hosts for SSL)
>>> - better ciphers and many other security related improvements
>>> - nashorn (fast javascript engine)
>>> - better concurrency libs
>>> - easier testing, one less JDK combo to test on CI
>>> 
>>> and of course all of the language improvements, lambda ftw!
>>> 
>>> Cons of moving early
>>> 
>>> - back porting of code could be impaired 
>>> - there is currently no non beta release of IBM JDK8 
>>> 
>>> There are probably other pros & cons but in general I think it would be better to upgrade early as there will be many
>>> hidden issues with new Java 8 features people want to use but are server doesn't understand currently, mostly here
>>> are features like enhanced type annotations and default methods.
>>> 
>>> This problem are and will creep up more and more often as adoption of Java 8 is quite good already [2] and still rising.
>>> 
>>> so what do you guys think? Should we move for WildFly or should we wait for 10 as planned?
>>> 
>>> --
>>> tomaz
>>> 
>>> 
>>> [1] http://www.oracle.com/technetwork/java/eol-135779.html
>>> [2] http://jaxenter.com/java-2-111936.html
>>> _______________________________________________
>>> 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
> 

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



From brian.stansberry at redhat.com  Fri Feb 13 14:22:16 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Fri, 13 Feb 2015 13:22:16 -0600
Subject: [wildfly-dev] Customizing a provisioned server
In-Reply-To: <540A00D3.2050608@redhat.com>
References: <5407E7AF.6060701@redhat.com>	<CAMquZP5RUtaE4rxpVyS02N1jWmT3_jUwyyMfPKcKePoYeFLw0g@mail.gmail.com>	<5408D6D8.4050305@gmail.com>	<CAMquZP7u2y17aLnBr-zbksRiuaN3UfGTgfCK2aw10zDVsJoZTA@mail.gmail.com>	<721DBB09-04FF-45DF-BAEA-4024C59805F1@jboss.com>	<540986CD.6010709@redhat.com>	<A1E515AB-D0BC-45F9-A246-16CBB5BF32F5@redhat.com>
	<540A00D3.2050608@redhat.com>
Message-ID: <54DE4EE8.9030407@redhat.com>

On 9/5/14 1:28 PM, Brian Stansberry wrote:
> On 9/5/14, 12:42 PM, Jason Greene wrote:
>> The nice thing about expressing this in DMR as that you could have one consistent data model vs nesting a bunch of different ones (DMR inside of CLI syntax inside of XML syntax). We could also just add path support into the management API, just parse the equivalent string.
>>
>> {
>>     ?install-feature-list? => [?io?, ?something-else"],
>>
>>     ?tasks? => [
>>       {
>>         ?address? => ?/subsystem=io/worker=new-worker1?,
>
> Regardless of this provisioning tool discussion, this is a good idea.
>
> We have a bug to fix where passing "address" => ""  (instead of
> "address" => []) results in useless failure instead of a proper failure,
> and the fix for that would likely involve some highly central point
> where we validate the address param. That point could easily deal with
> this too.
>

FYI, Emmanuel Hugonnet has a pull request with ^^^:

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

>>         ?operation? => ?add?
>>       },
>>       {
>>         ?address? => ?/subsystem=io/worker=new-worker2?,
>>         ?operation? => ?add?
>>       },
>>       {
>>         ?address? => ?/subsystem=io/worker=new-worker3?,
>>         ?operation? => ?add?
>>       }
>>     ]
>> }
>>
>>
>> Note that the CLI doesn?t hide DMR, in particular with an add operation. So the difference will be pretty small imo.
>>
>>
>>
>> On Sep 5, 2014, at 4:47 AM, Emmanuel Hugonnet <ehugonne at redhat.com> wrote:
>>
>>> Can't the provisionning "build tool" convert the cli scripts in dmr in building the feature pack ?
>>> Thus dmr would be the lingua franca of the provisionning itself.
>>> That might mean more rebuilding during the feature pack creation / configuration from  a user point of view.
>>> Emmanuel
>>>
>>> Le 05/09/2014 11:22, Kabir Khan a ?crit :
>>>>
>>>> On 5 Sep 2014, at 09:59, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
>>>>
>>>>>
>>>>> On Thu, Sep 4, 2014 at 11:17 PM, Stuart Douglas <stuart.w.douglas at gmail.com> wrote:
>>>>> The problem with 3 is that for the most part users do not use DMR directly, they use the CLI, and all our documentation reflects this. If we use DMR directly for this it just one more thing that we require our users to learn.
>>>>>
>>>>>
>>>>> 90%+ of what users do in CLI is direct DMR.
>>>>> Things that CLI adds that are not part of native DMR are handlers like:
>>>>>
>>>>> - ls (instead of :read-resource),
>>>>> - reload (instead of :reload)
>>>>> - try,catch
>>>>> - batch*
>>>>> - if, else
>>>>> - clear, quit
>>>>> + some others
>>>>>
>>>>> but in general most of the commands people write are direct DMR.
>>>>> CLI only adds lots of usability features on top of them like tab completion.
>>>>>
>>>>> for example
>>>>> /subsystem=io/worker=new-worker:add()
>>>>> is 100% dmr operation.
>>>> Yes, but isn?t the issue that it is nicer for end users, who are used to the CLI to write this rather than either using the serialized forms of the  the DMR representation, e.g. either (raw DMR)
>>>> 	{
>>>> 	    "address" => [
>>>> 	        ("subsystem" => "io"),
>>>> 	        ("worker" => "new-worker")
>>>> 	    ],
>>>> 	    "operation" => ?add?
>>>> 	}
>>>> or (JSON)
>>>> 	{
>>>> 	    "address" : [
>>>>          	{
>>>> 	            "subsystem" : "io"
>>>>          	},
>>>> 	        {
>>>>          	    "worker" : "new-worker"
>>>> 	        }
>>>> 	    ],
>>>> 	    "operation" : "add"
>>>> 	}
>>>> is is a lot more usable to just be able to say
>>>> 	/subsystem=io/worker=new-worker:add()
>>>>
>>>>
>>>>>
>>>>> In any case if we go with WildFly embedded in CLI mode all this discussion is non issue.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>
>> --
>> Jason T. Greene
>> WildFly Lead / JBoss EAP Platform Architect
>> JBoss, a division of Red Hat
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>


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

From brian.stansberry at redhat.com  Fri Feb 13 18:14:26 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Fri, 13 Feb 2015 17:14:26 -0600
Subject: [wildfly-dev] WildFly Core 1.0.0.Alpha18 Released
Message-ID: <54DE8552.1070408@redhat.com>

The latest in our roughly weekly series of WildFly Core alphas has been 
released and merged into full WildFly's master branch.

Fixed issues:

https://issues.jboss.org/issues/?jql=fixVersion%20%3D%201.0.0.Alpha18%20AND%20project%20%3D%20WFCORE

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

From ceharris414 at me.com  Tue Feb 17 10:34:57 2015
From: ceharris414 at me.com (Carl Harris)
Date: Tue, 17 Feb 2015 10:34:57 -0500
Subject: [wildfly-dev] add a module dependency in a DeploymentUnitProcessor
Message-ID: <75B55E6D-6E2C-4503-96A2-3D966B3CBF9F@me.com>

I?ve written an extension in which I would like to make add a module dependency to a deployment (as if the dependency had been included in the Dependencies manifest header or jboss-deployment-structure.xml).

I?m assuming that this needs to happen in a DeploymentUnitProcessor.  Looking at how the ManifestDeploymentProcessor in wildfly-core works, it seems I should be able to do something like this in a deployment processor that runs in the PARSE phase:

    ModuleIdentifier moduleId = ModuleIdentifier.create(?org.example.api?);
    ModuleLoader loader = Module.getBootModuleLoader();
    ModuleDependency dependency = new ModuleDependency(loader, moduleId, false, false, false, false);
    phaseContext.addToAttachmentList(Attachments.MANIFEST_DEPENDENCIES, dependency);

This isn?t working ? the deployment unit processor runs without error, but when I try to reference classes provided by the module, I get NoClassDefFoundError.

Of course, If I add the same module identifier to the Dependencies manifest header in the deployment itself, all is well.

Perhaps this isn?t the way to approach this problem?

Thanks in advance for any tips/guidance,

carl





From tomaz.cerar at gmail.com  Tue Feb 17 10:57:05 2015
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Tue, 17 Feb 2015 16:57:05 +0100
Subject: [wildfly-dev] add a module dependency in a
	DeploymentUnitProcessor
In-Reply-To: <75B55E6D-6E2C-4503-96A2-3D966B3CBF9F@me.com>
References: <75B55E6D-6E2C-4503-96A2-3D966B3CBF9F@me.com>
Message-ID: <CAMquZP7AZduU3tH_ebL46cVEmmBAFnn6uvCuUZ9fbePOP=gjMw@mail.gmail.com>

Hi,

you should change code a bit, to something like this

final ModuleSpecification moduleSpec =
phaseContext.getDeploymentUnit().getAttachment(Attachments.MODULE_SPECIFICATION);
moduleSpec.addSystemDependency(dependency);

and you should run your DUP in  Phase.DEPENDENCIES

--
tomaz


On Tue, Feb 17, 2015 at 4:34 PM, Carl Harris <ceharris414 at me.com> wrote:

> I?ve written an extension in which I would like to make add a module
> dependency to a deployment (as if the dependency had been included in the
> Dependencies manifest header or jboss-deployment-structure.xml).
>
> I?m assuming that this needs to happen in a DeploymentUnitProcessor.
> Looking at how the ManifestDeploymentProcessor in wildfly-core works, it
> seems I should be able to do something like this in a deployment processor
> that runs in the PARSE phase:
>
>     ModuleIdentifier moduleId = ModuleIdentifier.create(?org.example.api?);
>     ModuleLoader loader = Module.getBootModuleLoader();
>     ModuleDependency dependency = new ModuleDependency(loader, moduleId,
> false, false, false, false);
>     phaseContext.addToAttachmentList(Attachments.MANIFEST_DEPENDENCIES,
> dependency);
>
> This isn?t working ? the deployment unit processor runs without error, but
> when I try to reference classes provided by the module, I get
> NoClassDefFoundError.
>
> Of course, If I add the same module identifier to the Dependencies
> manifest header in the deployment itself, all is well.
>
> Perhaps this isn?t the way to approach this problem?
>
> Thanks in advance for any tips/guidance,
>
> carl
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150217/56861773/attachment.html 

From tomaz.cerar at gmail.com  Wed Feb 18 08:24:22 2015
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Wed, 18 Feb 2015 14:24:22 +0100
Subject: [wildfly-dev] CI build is broken
In-Reply-To: <CAGBoHQXJLr_J=LrQWL69OF+KS_drTK3AnAes-G3hH-00hCrLtA@mail.gmail.com>
References: <CAGBoHQW-td67ke7sdqq0SXg2KXPUX75bw1pT11ciMomLrmsjZw@mail.gmail.com>
	<CAMquZP4XBT10AqQr=T3wh7yiHOzVPMKGLqA6K3BP1jtUO0fKOA@mail.gmail.com>
	<CAGBoHQUMGGtAh5kz2yCD73RGtygtsRxxO1NjpUR-Z7bFAEDnog@mail.gmail.com>
	<CAMquZP6gAOsFs0vOfeGKp=fnO4mTehtkhR+f39DFxP-TwE+0BQ@mail.gmail.com>
	<CAGBoHQXJLr_J=LrQWL69OF+KS_drTK3AnAes-G3hH-00hCrLtA@mail.gmail.com>
Message-ID: <CAMquZP58L8H+1zrh=Fg9mt-DiNcNp9XSp+FLdiFdMvO2R_f-Fg@mail.gmail.com>

Just FYI guys,
nightly builds are fixed and again promptly available at
https://ci.jboss.org/hudson/job/WildFly-latest-master/lastBuild/

--
tomaz

On Thu, Feb 5, 2015 at 7:02 PM, Arun Gupta <arun.gupta at gmail.com> wrote:

> Email sent, CCed you.
>
> On Thu, Feb 5, 2015 at 9:39 AM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
> >
> > On Thu, Feb 5, 2015 at 6:19 PM, Arun Gupta <arun.gupta at gmail.com> wrote:
> >>
> >> Are the builds done internally and then published externally?
> >
> > yes
> >>
> >>
> >> Why so, as opposed to build externally?
> >
> > internally there is whole QE pool of servers available for building
> which we
> > don't have on public read only instance
> >>
> >>
> >> eng-ops would eng-ops at redhat.com?
> >
> > yes
> >
> >
>
>
>
> --
> http://blog.arungupta.me
> http://twitter.com/arungupta
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150218/8a054a6c/attachment.html 

From arun.gupta at gmail.com  Wed Feb 18 09:47:45 2015
From: arun.gupta at gmail.com (Arun Gupta)
Date: Wed, 18 Feb 2015 06:47:45 -0800
Subject: [wildfly-dev] CI build is broken
In-Reply-To: <CAMquZP58L8H+1zrh=Fg9mt-DiNcNp9XSp+FLdiFdMvO2R_f-Fg@mail.gmail.com>
References: <CAGBoHQW-td67ke7sdqq0SXg2KXPUX75bw1pT11ciMomLrmsjZw@mail.gmail.com>
	<CAMquZP4XBT10AqQr=T3wh7yiHOzVPMKGLqA6K3BP1jtUO0fKOA@mail.gmail.com>
	<CAGBoHQUMGGtAh5kz2yCD73RGtygtsRxxO1NjpUR-Z7bFAEDnog@mail.gmail.com>
	<CAMquZP6gAOsFs0vOfeGKp=fnO4mTehtkhR+f39DFxP-TwE+0BQ@mail.gmail.com>
	<CAGBoHQXJLr_J=LrQWL69OF+KS_drTK3AnAes-G3hH-00hCrLtA@mail.gmail.com>
	<CAMquZP58L8H+1zrh=Fg9mt-DiNcNp9XSp+FLdiFdMvO2R_f-Fg@mail.gmail.com>
Message-ID: <CAGBoHQX66jhfkcY9_5f=HdYEbjcF7u3ueoWuyF9bsG1dRbsEEQ@mail.gmail.com>

The last build is dated Feb 13th, broken again?

On Wed, Feb 18, 2015 at 5:24 AM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
> Just FYI guys,
> nightly builds are fixed and again promptly available at
> https://ci.jboss.org/hudson/job/WildFly-latest-master/lastBuild/
>
> --
> tomaz
>
> On Thu, Feb 5, 2015 at 7:02 PM, Arun Gupta <arun.gupta at gmail.com> wrote:
>>
>> Email sent, CCed you.
>>
>> On Thu, Feb 5, 2015 at 9:39 AM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
>> >
>> > On Thu, Feb 5, 2015 at 6:19 PM, Arun Gupta <arun.gupta at gmail.com> wrote:
>> >>
>> >> Are the builds done internally and then published externally?
>> >
>> > yes
>> >>
>> >>
>> >> Why so, as opposed to build externally?
>> >
>> > internally there is whole QE pool of servers available for building
>> > which we
>> > don't have on public read only instance
>> >>
>> >>
>> >> eng-ops would eng-ops at redhat.com?
>> >
>> > yes
>> >
>> >
>>
>>
>>
>> --
>> http://blog.arungupta.me
>> http://twitter.com/arungupta
>
>



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


From tomaz.cerar at gmail.com  Wed Feb 18 10:02:01 2015
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Wed, 18 Feb 2015 16:02:01 +0100
Subject: [wildfly-dev] CI build is broken
In-Reply-To: <CAGBoHQX66jhfkcY9_5f=HdYEbjcF7u3ueoWuyF9bsG1dRbsEEQ@mail.gmail.com>
References: <CAGBoHQW-td67ke7sdqq0SXg2KXPUX75bw1pT11ciMomLrmsjZw@mail.gmail.com>
	<CAMquZP4XBT10AqQr=T3wh7yiHOzVPMKGLqA6K3BP1jtUO0fKOA@mail.gmail.com>
	<CAGBoHQUMGGtAh5kz2yCD73RGtygtsRxxO1NjpUR-Z7bFAEDnog@mail.gmail.com>
	<CAMquZP6gAOsFs0vOfeGKp=fnO4mTehtkhR+f39DFxP-TwE+0BQ@mail.gmail.com>
	<CAGBoHQXJLr_J=LrQWL69OF+KS_drTK3AnAes-G3hH-00hCrLtA@mail.gmail.com>
	<CAMquZP58L8H+1zrh=Fg9mt-DiNcNp9XSp+FLdiFdMvO2R_f-Fg@mail.gmail.com>
	<CAGBoHQX66jhfkcY9_5f=HdYEbjcF7u3ueoWuyF9bsG1dRbsEEQ@mail.gmail.com>
Message-ID: <CAMquZP7=yZa559xG38048So9OQ193pKLbcLs_qsMoMAwO47-7A@mail.gmail.com>

No,

just catching up the publishing new builds, as the publish queue is huge :-)
Once it catches up it will be faster with publishing more promptly.

On Wed, Feb 18, 2015 at 3:47 PM, Arun Gupta <arun.gupta at gmail.com> wrote:

> The last build is dated Feb 13th, broken again?
>
> On Wed, Feb 18, 2015 at 5:24 AM, Toma? Cerar <tomaz.cerar at gmail.com>
> wrote:
> > Just FYI guys,
> > nightly builds are fixed and again promptly available at
> > https://ci.jboss.org/hudson/job/WildFly-latest-master/lastBuild/
> >
> > --
> > tomaz
> >
> > On Thu, Feb 5, 2015 at 7:02 PM, Arun Gupta <arun.gupta at gmail.com> wrote:
> >>
> >> Email sent, CCed you.
> >>
> >> On Thu, Feb 5, 2015 at 9:39 AM, Toma? Cerar <tomaz.cerar at gmail.com>
> wrote:
> >> >
> >> > On Thu, Feb 5, 2015 at 6:19 PM, Arun Gupta <arun.gupta at gmail.com>
> wrote:
> >> >>
> >> >> Are the builds done internally and then published externally?
> >> >
> >> > yes
> >> >>
> >> >>
> >> >> Why so, as opposed to build externally?
> >> >
> >> > internally there is whole QE pool of servers available for building
> >> > which we
> >> > don't have on public read only instance
> >> >>
> >> >>
> >> >> eng-ops would eng-ops at redhat.com?
> >> >
> >> > yes
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> http://blog.arungupta.me
> >> http://twitter.com/arungupta
> >
> >
>
>
>
> --
> http://blog.arungupta.me
> http://twitter.com/arungupta
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150218/3cd3227a/attachment.html 

From arun.gupta at gmail.com  Wed Feb 18 11:25:07 2015
From: arun.gupta at gmail.com (Arun Gupta)
Date: Wed, 18 Feb 2015 08:25:07 -0800
Subject: [wildfly-dev] CI build is broken
In-Reply-To: <CAMquZP7=yZa559xG38048So9OQ193pKLbcLs_qsMoMAwO47-7A@mail.gmail.com>
References: <CAGBoHQW-td67ke7sdqq0SXg2KXPUX75bw1pT11ciMomLrmsjZw@mail.gmail.com>
	<CAMquZP4XBT10AqQr=T3wh7yiHOzVPMKGLqA6K3BP1jtUO0fKOA@mail.gmail.com>
	<CAGBoHQUMGGtAh5kz2yCD73RGtygtsRxxO1NjpUR-Z7bFAEDnog@mail.gmail.com>
	<CAMquZP6gAOsFs0vOfeGKp=fnO4mTehtkhR+f39DFxP-TwE+0BQ@mail.gmail.com>
	<CAGBoHQXJLr_J=LrQWL69OF+KS_drTK3AnAes-G3hH-00hCrLtA@mail.gmail.com>
	<CAMquZP58L8H+1zrh=Fg9mt-DiNcNp9XSp+FLdiFdMvO2R_f-Fg@mail.gmail.com>
	<CAGBoHQX66jhfkcY9_5f=HdYEbjcF7u3ueoWuyF9bsG1dRbsEEQ@mail.gmail.com>
	<CAMquZP7=yZa559xG38048So9OQ193pKLbcLs_qsMoMAwO47-7A@mail.gmail.com>
Message-ID: <CAGBoHQXpwoOLBf266crVT=BaHvO8M6tJu5EM1xzX2pP=M-0J3g@mail.gmail.com>

Can we skip the queue and jump to a more recent build? Anyway last 10
builds are archived only.

Arun

On Wed, Feb 18, 2015 at 7:02 AM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
> No,
>
> just catching up the publishing new builds, as the publish queue is huge :-)
> Once it catches up it will be faster with publishing more promptly.
>
> On Wed, Feb 18, 2015 at 3:47 PM, Arun Gupta <arun.gupta at gmail.com> wrote:
>>
>> The last build is dated Feb 13th, broken again?
>>
>> On Wed, Feb 18, 2015 at 5:24 AM, Toma? Cerar <tomaz.cerar at gmail.com>
>> wrote:
>> > Just FYI guys,
>> > nightly builds are fixed and again promptly available at
>> > https://ci.jboss.org/hudson/job/WildFly-latest-master/lastBuild/
>> >
>> > --
>> > tomaz
>> >
>> > On Thu, Feb 5, 2015 at 7:02 PM, Arun Gupta <arun.gupta at gmail.com> wrote:
>> >>
>> >> Email sent, CCed you.
>> >>
>> >> On Thu, Feb 5, 2015 at 9:39 AM, Toma? Cerar <tomaz.cerar at gmail.com>
>> >> wrote:
>> >> >
>> >> > On Thu, Feb 5, 2015 at 6:19 PM, Arun Gupta <arun.gupta at gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> Are the builds done internally and then published externally?
>> >> >
>> >> > yes
>> >> >>
>> >> >>
>> >> >> Why so, as opposed to build externally?
>> >> >
>> >> > internally there is whole QE pool of servers available for building
>> >> > which we
>> >> > don't have on public read only instance
>> >> >>
>> >> >>
>> >> >> eng-ops would eng-ops at redhat.com?
>> >> >
>> >> > yes
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> http://blog.arungupta.me
>> >> http://twitter.com/arungupta
>> >
>> >
>>
>>
>>
>> --
>> http://blog.arungupta.me
>> http://twitter.com/arungupta
>
>



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


From tsegismo at redhat.com  Thu Feb 19 04:59:54 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Thu, 19 Feb 2015 10:59:54 +0100
Subject: [wildfly-dev] [Wildfly Maven Plugin] Skip start and shutdown
Message-ID: <54E5B41A.2030500@redhat.com>

Hi,

Recently I've sent a pull request[1] so that the Wildfly Maven plugin 
can skip start and shutdown.

In RHQ and Hawkular metrics projects, we use the Wildfly Maven plugin to 
start a server and deploy an application for integration testing.

To sum up, we attach the following goals to different build phases:
* pre-integration-test -> start
* pre-integration-test -> deploy
* post-integration-test -> shutdown

The deploy goal has a skip parameter[2]. But the start and shutdown 
goals haven't. So when we disable tests, we can skip the deploy phase 
but Maven will still start and stop the Wildfly server.

I've tested a local build of the plugin with the changes. On the 
Hawkular metrics rest-tests module, build time goes from 15 seconds down 
to 5 seconds when start and stop goal are skipped.

Can somebody please have a look at the PR?

Thanks,
Thomas

[1] https://github.com/wildfly/wildfly-maven-plugin/issues/26
[2] 
https://docs.jboss.org/wildfly/plugins/maven/latest/deploy-mojo.html#skip

From jperkins at redhat.com  Thu Feb 19 11:12:28 2015
From: jperkins at redhat.com (James R. Perkins)
Date: Thu, 19 Feb 2015 08:12:28 -0800
Subject: [wildfly-dev] [Wildfly Maven Plugin] Skip start and shutdown
In-Reply-To: <54E5B41A.2030500@redhat.com>
References: <54E5B41A.2030500@redhat.com>
Message-ID: <54E60B6C.8020804@redhat.com>

I'll try to have a look at it today.

As a work around you could always use a profile.

On 02/19/2015 01:59 AM, Thomas Segismont wrote:
> Hi,
>
> Recently I've sent a pull request[1] so that the Wildfly Maven plugin
> can skip start and shutdown.
>
> In RHQ and Hawkular metrics projects, we use the Wildfly Maven plugin to
> start a server and deploy an application for integration testing.
>
> To sum up, we attach the following goals to different build phases:
> * pre-integration-test -> start
> * pre-integration-test -> deploy
> * post-integration-test -> shutdown
>
> The deploy goal has a skip parameter[2]. But the start and shutdown
> goals haven't. So when we disable tests, we can skip the deploy phase
> but Maven will still start and stop the Wildfly server.
>
> I've tested a local build of the plugin with the changes. On the
> Hawkular metrics rest-tests module, build time goes from 15 seconds down
> to 5 seconds when start and stop goal are skipped.
>
> Can somebody please have a look at the PR?
>
> Thanks,
> Thomas
>
> [1] https://github.com/wildfly/wildfly-maven-plugin/issues/26
> [2]
> https://docs.jboss.org/wildfly/plugins/maven/latest/deploy-mojo.html#skip
> _______________________________________________
> 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 tsegismo at redhat.com  Thu Feb 19 11:48:16 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Thu, 19 Feb 2015 17:48:16 +0100
Subject: [wildfly-dev] [Wildfly Maven Plugin] Skip start and shutdown
In-Reply-To: <54E60B6C.8020804@redhat.com>
References: <54E5B41A.2030500@redhat.com> <54E60B6C.8020804@redhat.com>
Message-ID: <54E613D0.4010606@redhat.com>

Thanks!

Le 19/02/2015 17:12, James R. Perkins a ?crit :
> I'll try to have a look at it today.
>
> As a work around you could always use a profile.
>
> On 02/19/2015 01:59 AM, Thomas Segismont wrote:
>> Hi,
>>
>> Recently I've sent a pull request[1] so that the Wildfly Maven plugin
>> can skip start and shutdown.
>>
>> In RHQ and Hawkular metrics projects, we use the Wildfly Maven plugin to
>> start a server and deploy an application for integration testing.
>>
>> To sum up, we attach the following goals to different build phases:
>> * pre-integration-test -> start
>> * pre-integration-test -> deploy
>> * post-integration-test -> shutdown
>>
>> The deploy goal has a skip parameter[2]. But the start and shutdown
>> goals haven't. So when we disable tests, we can skip the deploy phase
>> but Maven will still start and stop the Wildfly server.
>>
>> I've tested a local build of the plugin with the changes. On the
>> Hawkular metrics rest-tests module, build time goes from 15 seconds down
>> to 5 seconds when start and stop goal are skipped.
>>
>> Can somebody please have a look at the PR?
>>
>> Thanks,
>> Thomas
>>
>> [1] https://github.com/wildfly/wildfly-maven-plugin/issues/26
>> [2]
>> https://docs.jboss.org/wildfly/plugins/maven/latest/deploy-mojo.html#skip
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


From jperkins at redhat.com  Thu Feb 19 11:49:37 2015
From: jperkins at redhat.com (James R. Perkins)
Date: Thu, 19 Feb 2015 08:49:37 -0800
Subject: [wildfly-dev] Batch Deployments
Message-ID: <54E61421.5060309@redhat.com>

I'm working on allowing batch jobs to be viewed in the management model 
and I'm running into some issues.

Batch jobs require a XML file to start. Per the batch spec that the XML 
files can be found outside of the archive, for example somewhere on the 
file system. If the job XML isn't found there it looks in the 
META-INF/batch-jobs directory for the job XML.

Batch repositories are global for all applications. All deployments can 
see all other deployments job status and query information about the 
jobs. They can't start or restart jobs for other deployments, but 
they're viewable.

Here lies the problem. It seems batch jobs, at least from the management 
view, should be limited to the deployment the job was run on. I'm 
considering only allowing job XML files in the META-INF/batch-jobs to be 
viewable via management. Though there is still a chance two different 
deployments could use the same job name (the name of the job XML file) 
which would show the jobs run by the two different deployments with the 
same job name.

I can't think of another way to isolate jobs from the repository to link 
to a deployment. If anyone else has any ideas let me know. There is no 
spec for the repository so we can do whatever we want really.

-- 
James R. Perkins
JBoss by Red Hat


From kyle at nailedtothex.org  Thu Feb 19 18:13:15 2015
From: kyle at nailedtothex.org (Kohei Nozaki)
Date: Fri, 20 Feb 2015 08:13:15 +0900
Subject: [wildfly-dev] Batch Deployments
In-Reply-To: <54E61421.5060309@redhat.com>
References: <54E61421.5060309@redhat.com>
Message-ID: <287DD17D-073D-4F92-8BAD-BBA2CF87B8C0@nailedtothex.org>

As to querying history of execution, job_instance.applicationname would help distinguish between deployments.

On Feb 20, 2015, at 1:49, James R. Perkins <jperkins at redhat.com> wrote:

> I'm working on allowing batch jobs to be viewed in the management model 
> and I'm running into some issues.
> 
> Batch jobs require a XML file to start. Per the batch spec that the XML 
> files can be found outside of the archive, for example somewhere on the 
> file system. If the job XML isn't found there it looks in the 
> META-INF/batch-jobs directory for the job XML.
> 
> Batch repositories are global for all applications. All deployments can 
> see all other deployments job status and query information about the 
> jobs. They can't start or restart jobs for other deployments, but 
> they're viewable.
> 
> Here lies the problem. It seems batch jobs, at least from the management 
> view, should be limited to the deployment the job was run on. I'm 
> considering only allowing job XML files in the META-INF/batch-jobs to be 
> viewable via management. Though there is still a chance two different 
> deployments could use the same job name (the name of the job XML file) 
> which would show the jobs run by the two different deployments with the 
> same job name.
> 
> I can't think of another way to isolate jobs from the repository to link 
> to a deployment. If anyone else has any ideas let me know. There is no 
> spec for the repository so we can do whatever we want really.
> 
> -- 
> James R. Perkins
> JBoss by Red Hat
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



From jperkins at redhat.com  Thu Feb 19 19:29:45 2015
From: jperkins at redhat.com (James R. Perkins)
Date: Thu, 19 Feb 2015 16:29:45 -0800
Subject: [wildfly-dev] Batch Deployments
In-Reply-To: <287DD17D-073D-4F92-8BAD-BBA2CF87B8C0@nailedtothex.org>
References: <54E61421.5060309@redhat.com>
	<287DD17D-073D-4F92-8BAD-BBA2CF87B8C0@nailedtothex.org>
Message-ID: <54E67FF9.8030304@redhat.com>

I'm not sure I could use that. It would likely be a performance impact 
doing a JNDI lookup on each JobInstance. Also if the name of the app 
changes, for example it's deployed with a suffix of 1.0.1 and then 
1.0.2, you'd lose  previously run jobs for the app.

Unless of course I'm misunderstanding what you meant :)

On 02/19/2015 03:13 PM, Kohei Nozaki wrote:
> As to querying history of execution, job_instance.applicationname would help distinguish between deployments.
>
> On Feb 20, 2015, at 1:49, James R. Perkins <jperkins at redhat.com> wrote:
>
>> I'm working on allowing batch jobs to be viewed in the management model
>> and I'm running into some issues.
>>
>> Batch jobs require a XML file to start. Per the batch spec that the XML
>> files can be found outside of the archive, for example somewhere on the
>> file system. If the job XML isn't found there it looks in the
>> META-INF/batch-jobs directory for the job XML.
>>
>> Batch repositories are global for all applications. All deployments can
>> see all other deployments job status and query information about the
>> jobs. They can't start or restart jobs for other deployments, but
>> they're viewable.
>>
>> Here lies the problem. It seems batch jobs, at least from the management
>> view, should be limited to the deployment the job was run on. I'm
>> considering only allowing job XML files in the META-INF/batch-jobs to be
>> viewable via management. Though there is still a chance two different
>> deployments could use the same job name (the name of the job XML file)
>> which would show the jobs run by the two different deployments with the
>> same job name.
>>
>> I can't think of another way to isolate jobs from the repository to link
>> to a deployment. If anyone else has any ideas let me know. There is no
>> spec for the repository so we can do whatever we want really.
>>
>> -- 
>> 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

-- 
James R. Perkins
JBoss by Red Hat


From cfang at redhat.com  Thu Feb 19 21:02:56 2015
From: cfang at redhat.com (Cheng Fang)
Date: Thu, 19 Feb 2015 21:02:56 -0500
Subject: [wildfly-dev] Batch Deployments
In-Reply-To: <54E67FF9.8030304@redhat.com>
References: <54E61421.5060309@redhat.com>	<287DD17D-073D-4F92-8BAD-BBA2CF87B8C0@nailedtothex.org>
	<54E67FF9.8030304@redhat.com>
Message-ID: <54E695D0.3060102@redhat.com>

applicationName in JobInstance or JOB_INSTANCE table, along with 
jobName, should be able to uniquely identify a job.  applicationName is 
set when the jobInstance is created.  There may be some internal API to 
obtain it instead of JNDI lookup to avoid any performance hit, though we 
currently don't know how big it will be.

If a deployment's name changes, e.g., thru versioning, then I would 
think the intent is to separate it from previous versions, and in that 
case, any historical job data should only belong to the previous ones, 
and not visible to the deployment with the new name.

Just my 2 cents.

Cheng

On 2/19/15 7:29 PM, James R. Perkins wrote:
> I'm not sure I could use that. It would likely be a performance impact
> doing a JNDI lookup on each JobInstance. Also if the name of the app
> changes, for example it's deployed with a suffix of 1.0.1 and then
> 1.0.2, you'd lose  previously run jobs for the app.
>
> Unless of course I'm misunderstanding what you meant :)
>
> On 02/19/2015 03:13 PM, Kohei Nozaki wrote:
>> As to querying history of execution, job_instance.applicationname would help distinguish between deployments.
>>
>> On Feb 20, 2015, at 1:49, James R. Perkins <jperkins at redhat.com> wrote:
>>
>>> I'm working on allowing batch jobs to be viewed in the management model
>>> and I'm running into some issues.
>>>
>>> Batch jobs require a XML file to start. Per the batch spec that the XML
>>> files can be found outside of the archive, for example somewhere on the
>>> file system. If the job XML isn't found there it looks in the
>>> META-INF/batch-jobs directory for the job XML.
>>>
>>> Batch repositories are global for all applications. All deployments can
>>> see all other deployments job status and query information about the
>>> jobs. They can't start or restart jobs for other deployments, but
>>> they're viewable.
>>>
>>> Here lies the problem. It seems batch jobs, at least from the management
>>> view, should be limited to the deployment the job was run on. I'm
>>> considering only allowing job XML files in the META-INF/batch-jobs to be
>>> viewable via management. Though there is still a chance two different
>>> deployments could use the same job name (the name of the job XML file)
>>> which would show the jobs run by the two different deployments with the
>>> same job name.
>>>
>>> I can't think of another way to isolate jobs from the repository to link
>>> to a deployment. If anyone else has any ideas let me know. There is no
>>> spec for the repository so we can do whatever we want really.
>>>
>>> -- 
>>> 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


From david.lloyd at redhat.com  Fri Feb 20 13:43:51 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Fri, 20 Feb 2015 12:43:51 -0600
Subject: [wildfly-dev] WildFly Common 1.0.0.Alpha1 has been released...
Message-ID: <54E78067.9060806@redhat.com>

So I finally went ahead and published/released WildFly Common 
1.0.0.Alpha1.  It contains the following:

? Assertions and validations with standard messages (and IDs) for common 
conditions such as:
     ? Null method parameters
     ? Assertions for holding/not holding monitor objects
     ? Assertions for nullability of values
     ? Exceptions for unreachable code and impossible switch statements
? Utilities for reference types that are cleaned in a background thread
? Utilities for defining and using selector pattern Selectors (i.e. 
where you have to locate an object like a service provider from a static 
context)

Here's the info on how to get/use it:

? License: ASL 2.0
? JDK: 1.7 or higher
? Maven: org.wildfly.common:wildfly-common:1.0.0.Alpha1
? GitHub: https://github.com/wildfly/wildfly-common
? JavaDoc: http://wildfly.github.io/wildfly-common/
? JIRA: None at present, just use 
https://github.com/wildfly/wildfly-common/issues for now and I'll 
revisit later

More info about the project:

? http://dmlloyd.github.io/presentations/wildfly-common/index.html

-- 
- DML

From ceharris414 at me.com  Sat Feb 21 12:47:18 2015
From: ceharris414 at me.com (Carl Harris)
Date: Sat, 21 Feb 2015 12:47:18 -0500
Subject: [wildfly-dev] timer service for extension modules?
Message-ID: <0BB8F253-10D7-4811-B402-ACC8EC617ABA@me.com>

My extension module creates a (MSC) service that needs to get periodic timer callbacks to clean up cruft that accumulates while it is being used by a deployed application.  I could create a java.util.Timer when the service is created and cancel it when the service is removed, but I?m wondering of there already a timer service that I should be using for this sort of thing.

Thanks for any tips or guidance,

carl



From stuart.w.douglas at gmail.com  Sun Feb 22 21:19:36 2015
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Mon, 23 Feb 2015 02:19:36 +0000
Subject: [wildfly-dev] timer service for extension modules?
References: <0BB8F253-10D7-4811-B402-ACC8EC617ABA@me.com>
Message-ID: <CAAoo=c4BT35PX94mArX9sGR9PFVZiYTmgi5VwADeBvo2Q_vT=Q@mail.gmail.com>

Not really. There is a timer service that is used by EJB, but it is not
really intended for public consumption.

Creating your own Timer object is the way to go.

Stuart


On Sun Feb 22 2015 at 1:47:54 AM Carl Harris <ceharris414 at me.com> wrote:

> My extension module creates a (MSC) service that needs to get periodic
> timer callbacks to clean up cruft that accumulates while it is being used
> by a deployed application.  I could create a java.util.Timer when the
> service is created and cancel it when the service is removed, but I?m
> wondering of there already a timer service that I should be using for this
> sort of thing.
>
> Thanks for any tips or guidance,
>
> carl
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150223/c196a2a6/attachment.html 

From brian.stansberry at redhat.com  Mon Feb 23 10:34:39 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 23 Feb 2015 09:34:39 -0600
Subject: [wildfly-dev] timer service for extension modules?
In-Reply-To: <0BB8F253-10D7-4811-B402-ACC8EC617ABA@me.com>
References: <0BB8F253-10D7-4811-B402-ACC8EC617ABA@me.com>
Message-ID: <54EB488F.2060505@redhat.com>

No, there is no shared timer service provided by WildFly Core. EJB3 has 
timers but those are created via deployments and subsystem services 
should not depend on deployments. Plus I assume your stuff is meant to 
work regardless of whether EJB3 is part of the configuration.

On 2/21/15 11:47 AM, Carl Harris wrote:
> My extension module creates a (MSC) service that needs to get periodic timer callbacks to clean up cruft that accumulates while it is being used by a deployed application.  I could create a java.util.Timer when the service is created and cancel it when the service is removed, but I?m wondering of there already a timer service that I should be using for this sort of thing.
>
> Thanks for any tips or guidance,
>
> carl
>
>
> _______________________________________________
> 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 arun.gupta at gmail.com  Mon Feb 23 12:07:02 2015
From: arun.gupta at gmail.com (Arun Gupta)
Date: Mon, 23 Feb 2015 09:07:02 -0800
Subject: [wildfly-dev] Fwd: [javaee7-samples] Added test to see if a logout
 from the web propagates to EJB (#290)
In-Reply-To: <javaee-samples/javaee7-samples/pull/290@github.com>
References: <javaee-samples/javaee7-samples/pull/290@github.com>
Message-ID: <CAGBoHQVPqDjkA4fO6gvczzjXFU-0Y44j=UpeFmxk+Nor=o_YNQ@mail.gmail.com>

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/20150223/5442cbb3/attachment.html 

From jperkins at redhat.com  Mon Feb 23 12:19:43 2015
From: jperkins at redhat.com (James R. Perkins)
Date: Mon, 23 Feb 2015 09:19:43 -0800
Subject: [wildfly-dev] Batch Deployments
In-Reply-To: <54E695D0.3060102@redhat.com>
References: <54E61421.5060309@redhat.com>	<287DD17D-073D-4F92-8BAD-BBA2CF87B8C0@nailedtothex.org>	<54E67FF9.8030304@redhat.com>
	<54E695D0.3060102@redhat.com>
Message-ID: <54EB612F.1050408@redhat.com>

If we use the application name we lose some performance as everything 
needs to be dynamic. We'll have to query the job names and determine 
which jobs can be displayed for the deployment each time a read 
operation is done on the /deployment=some.war/subsystem=batch/job=* 
resource. We also may lose the visibility to batch jobs that have run 
previously if the application name changes.

If we use the job XML files from the META-INF/batch-jobs we get better 
performance because we know the job names during deployment processing 
and we can register those resources during processing rather than having 
them dynamic. We do however lose visibility over batch jobs where the 
job XML lives outside the deployment. We could also run into collisions 
where two deployments have the same job name, though that seems like it 
would be rather rare.

I'm not really sure how often job XML files will be used that are stored 
outside the deployment. If we knew it was going to be quite often, I'd 
lean towards the first option. If it's rare I'd lean towards the second 
option.

On 02/19/2015 06:02 PM, Cheng Fang wrote:
> applicationName in JobInstance or JOB_INSTANCE table, along with
> jobName, should be able to uniquely identify a job.  applicationName is
> set when the jobInstance is created.  There may be some internal API to
> obtain it instead of JNDI lookup to avoid any performance hit, though we
> currently don't know how big it will be.
>
> If a deployment's name changes, e.g., thru versioning, then I would
> think the intent is to separate it from previous versions, and in that
> case, any historical job data should only belong to the previous ones,
> and not visible to the deployment with the new name.
>
> Just my 2 cents.
>
> Cheng
>
> On 2/19/15 7:29 PM, James R. Perkins wrote:
>> I'm not sure I could use that. It would likely be a performance impact
>> doing a JNDI lookup on each JobInstance. Also if the name of the app
>> changes, for example it's deployed with a suffix of 1.0.1 and then
>> 1.0.2, you'd lose  previously run jobs for the app.
>>
>> Unless of course I'm misunderstanding what you meant :)
>>
>> On 02/19/2015 03:13 PM, Kohei Nozaki wrote:
>>> As to querying history of execution, job_instance.applicationname would help distinguish between deployments.
>>>
>>> On Feb 20, 2015, at 1:49, James R. Perkins <jperkins at redhat.com> wrote:
>>>
>>>> I'm working on allowing batch jobs to be viewed in the management model
>>>> and I'm running into some issues.
>>>>
>>>> Batch jobs require a XML file to start. Per the batch spec that the XML
>>>> files can be found outside of the archive, for example somewhere on the
>>>> file system. If the job XML isn't found there it looks in the
>>>> META-INF/batch-jobs directory for the job XML.
>>>>
>>>> Batch repositories are global for all applications. All deployments can
>>>> see all other deployments job status and query information about the
>>>> jobs. They can't start or restart jobs for other deployments, but
>>>> they're viewable.
>>>>
>>>> Here lies the problem. It seems batch jobs, at least from the management
>>>> view, should be limited to the deployment the job was run on. I'm
>>>> considering only allowing job XML files in the META-INF/batch-jobs to be
>>>> viewable via management. Though there is still a chance two different
>>>> deployments could use the same job name (the name of the job XML file)
>>>> which would show the jobs run by the two different deployments with the
>>>> same job name.
>>>>
>>>> I can't think of another way to isolate jobs from the repository to link
>>>> to a deployment. If anyone else has any ideas let me know. There is no
>>>> spec for the repository so we can do whatever we want really.
>>>>
>>>> -- 
>>>> 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

-- 
James R. Perkins
JBoss by Red Hat


From arjan.tijms at gmail.com  Mon Feb 23 13:05:18 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Mon, 23 Feb 2015 19:05:18 +0100
Subject: [wildfly-dev] [javaee7-samples] Added test to see if a logout
 from the web propagates to EJB (#290)
In-Reply-To: <CAGBoHQVPqDjkA4fO6gvczzjXFU-0Y44j=UpeFmxk+Nor=o_YNQ@mail.gmail.com>
References: <javaee-samples/javaee7-samples/pull/290@github.com>
	<CAGBoHQVPqDjkA4fO6gvczzjXFU-0Y44j=UpeFmxk+Nor=o_YNQ@mail.gmail.com>
Message-ID: <CAE=-AhCew+7nTsCcj17k5Zoog6_w6poJ073r9OHGS3y5_z90AQ@mail.gmail.com>

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
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','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/20150223/35a78b41/attachment.html 

From tdiesler at redhat.com  Tue Feb 24 09:29:17 2015
From: tdiesler at redhat.com (Thomas Diesler)
Date: Tue, 24 Feb 2015 15:29:17 +0100
Subject: [wildfly-dev] Making camel deployment config part of jboss-all.xml
Message-ID: <F80C3607-C1BB-47AF-AD15-5494FF9FB905@redhat.com>

Hi Jason,

it has been suggested to make camel specific deployment config (processed by the camel subsystem) part of jboss-all.xml. Would that be acceptable?

Relates to: https://github.com/wildfly-extras/wildfly-camel/issues/199 <https://github.com/wildfly-extras/wildfly-camel/issues/199>

cheers
?thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150224/c9a4cbf4/attachment.html 

From dev.bilalis at gmail.com  Tue Feb 24 09:40:56 2015
From: dev.bilalis at gmail.com (Michael Bilalis)
Date: Tue, 24 Feb 2015 15:40:56 +0100
Subject: [wildfly-dev] JBoss AS 7 - JDK8 compatibility
Message-ID: <86C85F5E-4878-4453-B81E-53A0EA3BC369@gmail.com>

Hello,

We have some existing legacy app-server running JBoss AS 7 and I would like to know if AS 7 is JDK8 compatible or are there some issues with it ?


Kind Regards

Michael

From tomaz.cerar at gmail.com  Tue Feb 24 09:45:31 2015
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Tue, 24 Feb 2015 15:45:31 +0100
Subject: [wildfly-dev] JBoss AS 7 - JDK8 compatibility
In-Reply-To: <86C85F5E-4878-4453-B81E-53A0EA3BC369@gmail.com>
References: <86C85F5E-4878-4453-B81E-53A0EA3BC369@gmail.com>
Message-ID: <CAMquZP4zQhWeDGHAouNOMWHLw8GeAD_DLk_EfwrJfUyhpcVP1A@mail.gmail.com>

Hi Michael,

AS7.1.1 won't boot on JDK8.

You would need to upgrade to WildFly 8.x to get it properly working.

Of if that is too much of the change, you could migrate to our commercially
supported EAP 6.3.x / 6.4 that are getting official JDK8 support.

On Tue, Feb 24, 2015 at 3:40 PM, Michael Bilalis <dev.bilalis at gmail.com>
wrote:

> Hello,
>
> We have some existing legacy app-server running JBoss AS 7 and I would
> like to know if AS 7 is JDK8 compatible or are there some issues with it ?
>
>
> Kind Regards
>
> Michael
> _______________________________________________
> 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/20150224/a9db580f/attachment.html 

From stuart.w.douglas at gmail.com  Tue Feb 24 10:36:41 2015
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Tue, 24 Feb 2015 15:36:41 +0000
Subject: [wildfly-dev] Making camel deployment config part of
	jboss-all.xml
References: <F80C3607-C1BB-47AF-AD15-5494FF9FB905@redhat.com>
Message-ID: <CAAoo=c7Bp9CksaLC6HXDwOdPgJ+UuM5iCfqOCcTddb6fxqa0hg@mail.gmail.com>

jboss-all.xml is pluggable, any subsystem can hook into it. It delegates to
the appropriate parser based on the namespace, the same way standalone.XML
does.

Stuart

On Tue, 24 Feb 2015 10:29 pm Thomas Diesler <tdiesler at redhat.com> wrote:

> Hi Jason,
>
> it has been suggested to make camel specific deployment config (processed
> by the camel subsystem) part of jboss-all.xml. Would that be acceptable?
>
> Relates to: https://github.com/wildfly-extras/wildfly-camel/issues/199
>
> cheers
> ?thomas
> _______________________________________________
> 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/20150224/7b941ba3/attachment.html 

From tdiesler at redhat.com  Wed Feb 25 02:46:16 2015
From: tdiesler at redhat.com (Thomas Diesler)
Date: Wed, 25 Feb 2015 08:46:16 +0100
Subject: [wildfly-dev] Making camel deployment config part of
	jboss-all.xml
In-Reply-To: <CAAoo=c7Bp9CksaLC6HXDwOdPgJ+UuM5iCfqOCcTddb6fxqa0hg@mail.gmail.com>
References: <F80C3607-C1BB-47AF-AD15-5494FF9FB905@redhat.com>
	<CAAoo=c7Bp9CksaLC6HXDwOdPgJ+UuM5iCfqOCcTddb6fxqa0hg@mail.gmail.com>
Message-ID: <40CBD2BE-C461-4F51-82CB-70D89B26C6C1@redhat.com>

Ok, thanks. Should we still support a standalone descriptor (i.e. jboss-camel.xml) or is it sufficient to go with jboss-all.xml?

?thomas

> On 24 Feb 2015, at 16:36, Stuart Douglas <stuart.w.douglas at gmail.com> wrote:
> 
> jboss-all.xml is pluggable, any subsystem can hook into it. It delegates to the appropriate parser based on the namespace, the same way standalone.XML does.
> 
> Stuart
> 
> On Tue, 24 Feb 2015 10:29 pm Thomas Diesler <tdiesler at redhat.com <mailto:tdiesler at redhat.com>> wrote:
> Hi Jason,
> 
> it has been suggested to make camel specific deployment config (processed by the camel subsystem) part of jboss-all.xml. Would that be acceptable?
> 
> Relates to: https://github.com/wildfly-extras/wildfly-camel/issues/199 <https://github.com/wildfly-extras/wildfly-camel/issues/199>
> 
> cheers
> ?thomas
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>_______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

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

From mgandikota at westechmed.com  Wed Feb 25 15:40:54 2015
From: mgandikota at westechmed.com (Gandikota, Murthy)
Date: Wed, 25 Feb 2015 20:40:54 +0000
Subject: [wildfly-dev] ConcurrentAccessTimeoutException with JBPM demo
Message-ID: <300155EADBAD7948B33FE136A4BF600D019870BD@CBD02CEXCH02.westdevinc.com>

Hi All

I am trying to run the JBPM2 demo on WildFly using "ant start.demo" and getting a bunch of errors  :

2015-02-25 12:38:03,365 ERROR [org.jboss.as.ejb3.invocation] (EJB default - 2) JBAS014134: EJB Invocation failed on component SimpleAsyncExecutorService for method public void org.uberfire.commons.async.SimpleAsyncExecutorService.execute(java.lang.Runnable): javax.ejb.ConcurrentAccessTimeoutException: JBAS014373: EJB 3.1 PFD2 4.8.5.5.1 concurrent access timeout on org.jboss.invocation.InterceptorContext$Invocation at 5af21532 - could not obtain lock within 5000MILLISECONDS


2015-02-25 12:38:03,532 ERROR [org.jboss.as.ejb3.invocation] (EJB default - 3) JBAS014134: EJB Invocation failed on component SimpleAsyncExecutorService for method public void org.uberfire.commons.async.SimpleAsyncExecutorService.execute(java.lang.Runnable): javax.ejb.ConcurrentAccessTimeoutException: JBAS014373: EJB 3.1 PFD2 4.8.5.5.1 concurrent access timeout on org.jboss.invocation.InterceptorContext$Invocation at 114dac71 - could not obtain lock within 5000MILLISECONDS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150225/25e6ce4f/attachment-0001.html 

From eduardo.santanadasilva at gmail.com  Wed Feb 25 15:58:27 2015
From: eduardo.santanadasilva at gmail.com (Eduardo Sant'Ana da Silva)
Date: Wed, 25 Feb 2015 17:58:27 -0300
Subject: [wildfly-dev] ConcurrentAccessTimeoutException with JBPM demo
In-Reply-To: <300155EADBAD7948B33FE136A4BF600D019870BD@CBD02CEXCH02.westdevinc.com>
References: <300155EADBAD7948B33FE136A4BF600D019870BD@CBD02CEXCH02.westdevinc.com>
Message-ID: <D2933874-02F7-4F57-870F-5C373DE70CA8@gmail.com>

Seems that something similar was already reported:

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


On Feb 25, 2015, at 5:40 PM, Gandikota, Murthy <mgandikota at westechmed.com> wrote:

> org.uberfire.commons.async.SimpleAsyncExecutorService

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

From mgandikota at westechmed.com  Wed Feb 25 16:11:33 2015
From: mgandikota at westechmed.com (Gandikota, Murthy)
Date: Wed, 25 Feb 2015 21:11:33 +0000
Subject: [wildfly-dev] ConcurrentAccessTimeoutException with JBPM demo
In-Reply-To: <D2933874-02F7-4F57-870F-5C373DE70CA8@gmail.com>
References: <300155EADBAD7948B33FE136A4BF600D019870BD@CBD02CEXCH02.westdevinc.com>
	<D2933874-02F7-4F57-870F-5C373DE70CA8@gmail.com>
Message-ID: <300155EADBAD7948B33FE136A4BF600D019872FF@CBD02CEXCH02.westdevinc.com>

Thank you Eduardo. In my case the c:\ProgramData\Oracle\Java\javapath symlinks were missing.

From: Eduardo Sant'Ana da Silva [mailto:eduardo.santanadasilva at gmail.com]
Sent: Wednesday, February 25, 2015 12:58 PM
To: Gandikota, Murthy
Cc: wildfly-dev at lists.jboss.org
Subject: Re: [wildfly-dev] ConcurrentAccessTimeoutException with JBPM demo

Seems that something similar was already reported:

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


On Feb 25, 2015, at 5:40 PM, Gandikota, Murthy <mgandikota at westechmed.com<mailto:mgandikota at westechmed.com>> wrote:


org.uberfire.commons.async.SimpleAsyncExecutorService

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

From tomaz.cerar at gmail.com  Thu Feb 26 10:59:26 2015
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Thu, 26 Feb 2015 16:59:26 +0100
Subject: [wildfly-dev] WildFly CI processing moved to Java 8
Message-ID: <CAMquZP5CZjScz1Bo6pw-S5=-DaiG_hxLaUnSz2-_vcYD+gGHnw@mail.gmail.com>

Hi folks,


Pull processing for WildFly and WildFly core was just moved to JDK 8.

This was done as part of effort allow testing also java 8 features as part
of testsuite.

PR https://github.com/wildfly/wildfly/pull/7183 adds "java8" integration
testsuite module.
This module uses java 8 as source & target where all tests utilizing java8
features should be added.

WildFly source level is still at 7 with exception of this new module ^^
Master & Master-ignore jobs on brontes will still use JDK7 for running
to make sure no JDK8 APIs slip into code base by mistake.


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

From rory.odonnell at oracle.com  Fri Feb 27 06:07:02 2015
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Fri, 27 Feb 2015 11:07:02 +0000
Subject: [wildfly-dev] Early Access builds for JDK 9 b51 are available on
	java.net
Message-ID: <54F04FD6.8000505@oracle.com>


Hi Jason/Tomaz,

Early Access build for JDK 9 b51 <https://jdk9.java.net/download/> 
available on java.net, summary of  changes are listed here 
<http://www.java.net/download/jdk9/changes/jdk9-b51.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/20150227/0b32fb89/attachment.html 

From sanne at hibernate.org  Fri Feb 27 15:08:00 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 27 Feb 2015 20:08:00 +0000
Subject: [wildfly-dev] Heads up on JBoss Logger 3.2 : more changed than what
	it looks like
Message-ID: <CAFm4XO2wnBqZywOkgDjhM=p-UDn6nintBpGS73PU+yPO_fSfgA@mail.gmail.com>

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

From jperkins at redhat.com  Fri Feb 27 18:50:45 2015
From: jperkins at redhat.com (James R. Perkins)
Date: Fri, 27 Feb 2015 15:50:45 -0800
Subject: [wildfly-dev] Heads up on JBoss Logger 3.2 : more changed than
 what it looks like
In-Reply-To: <CAFm4XO2wnBqZywOkgDjhM=p-UDn6nintBpGS73PU+yPO_fSfgA@mail.gmail.com>
References: <CAFm4XO2wnBqZywOkgDjhM=p-UDn6nintBpGS73PU+yPO_fSfgA@mail.gmail.com>
Message-ID: <54F102D5.80005@redhat.com>

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


From eduardo.santanadasilva at gmail.com  Sat Feb 28 10:25:41 2015
From: eduardo.santanadasilva at gmail.com (Eduardo Sant'Ana da Silva)
Date: Sat, 28 Feb 2015 12:25:41 -0300
Subject: [wildfly-dev] Heads up on JBoss Logger 3.2 : more changed than
	what it looks like
In-Reply-To: <54F102D5.80005@redhat.com>
References: <CAFm4XO2wnBqZywOkgDjhM=p-UDn6nintBpGS73PU+yPO_fSfgA@mail.gmail.com>
	<54F102D5.80005@redhat.com>
Message-ID: <329392AD-687F-42F2-8BDE-4FE86C9751A7@gmail.com>

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);

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

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