From stuart.w.douglas at gmail.com  Tue Mar  4 01:37:37 2014
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Tue, 04 Mar 2014 17:37:37 +1100
Subject: [wildfly-dev] smaller footprints
In-Reply-To: <530B508F.5040409@redhat.com>
References: <53075BEA.8030608@redhat.com>	<CAMquZP4RPXFgAPsCnnOLvH=XTkeQJ2bno5ms5yimD3gK6erkbw@mail.gmail.com>	<53076F18.3020603@redhat.com>
	<5307737C.2080603@redhat.com>	<53077867.3050600@redhat.com>	<3807F2B2-87E9-43F8-9A5C-E60340C748FF@redhat.com>
	<CAAoo=c7rWYObqRGQN2g34PR0bdP6YLeFCaoi3E5f7PuMQkav7Q@mail.gmail.com>
	<530B508F.5040409@redhat.com>
Message-ID: <531574B1.5080404@gmail.com>

I have made a start on this split, and I think the solution I am working 
on will meet all the use cases, including users that want to cut down an 
existing server, and users that want to re-use the jars in their maven 
repo using Bill's changes to JBoss Modules. It still needs a bit more 
work and a lot of cleanup, however it seems to work:

https://github.com/stuartwdouglas/wildfly/compare/wildfly-build-plugin

So basically the core of it is a maven plugin that builds a Wildfly 
distribution, either from scratch or use other distributions as a base.

It also supports building servers that use the new <artifact> 
functionality in jboss modules, and cutting down an existing server into 
a smaller server with only the specified modules (and their transitive 
dependencies).

The way this will work in practice is that each Wildfly sub project will 
produce two different server artifacts, one of which is a server without 
any jars using artifact references, and a more traditional version with 
jars packaged in the module directory. Downstream projects will consume 
the smaller version without all the jars, so when a version changes the 
download should be less than 5mb rather than larger than 100mb (the 
plugin has the ability to turn a server that uses artifact references 
into a server that contains the jars in the modules dir).

Basically the upshot is that it should be basically possible to build 
whatever configuration of server you want once this is part of our build 
process, and we should also be publishing lightweight server artifacts 
that use the jars in the maven repo as well as our traditional 
'everything and the kitchen sink' build.

It is anticipated that 3rd party projects build on Wildfly would also 
use this plugin (I think at the moment the standard approach has been to 
copy and modify our ant scripts).

This is still very much a work in progress, so nothing is set in stone 
yet and any comments are welcome.

Stuart


Bill Burke wrote:
> A lot of users want that ability, would you rather have them roll Netty
> + whatever?
>
> On 2/23/2014 9:10 PM, Stuart Douglas wrote:
>> No, because that means we essentially have to support and test every
>> possible combination that someone might select.
>>
>> Stuart
>>
>>
>> On Mon, Feb 24, 2014 at 7:13 AM, Misty Stanley-Jones<misty at redhat.com
>> <mailto:misty at redhat.com>>  wrote:
>>
>>      I know you guys aren?t there yet, but can we think about wrapping a
>>      GUI around this, so that the developer only needs to tick the boxes
>>      for what he does/doesn?t want, with dependencies sorted out
>>      automatically? Maybe some default profiles that select a group of
>>      things, but the ability to go in and add or remove individual
>>      subsystems as needed? Maybe this could be part of the installer but
>>      could optionally be run post-install as well.
>>
>>      On Feb 22, 2014, at 2:01 AM, Brian Stansberry
>>      <brian.stansberry at redhat.com<mailto:brian.stansberry at redhat.com>>
>>      wrote:
>>
>>       >  When I said "Web" I meant the thing described on that wiki page Tomaz
>>       >  linked:
>>       >
>>       >  "Web
>>       >
>>       >  Undertow subsystem, and all related dependencies, including a small
>>       >  subset of EE and JNDI. This is basically just a Servlet
>>      container, and
>>       >  will provide a platform for people that want to create web based
>>       >  appliances or applications, and don't need all the additional
>>       >  functionality that Wildfly provides. We should end up with
>>      something as
>>       >  lightweight as Tomcat or Jetty, but with all our advanced management
>>       >  functionality."
>>       >
>>       >  On 2/21/14, 9:40 AM, Bill Burke wrote:
>>       >>  Its also "Web" minus some stuff.  For my project I want just
>>      Servlet,
>>       >>  JAX-RS, JPA, and datasources.   Its very very hard to figure out
>>      how to
>>       >>  remove a subsystem and all its associated modules.
>>       >>
>>       >>  BTW, I think my maven artifact thing got into JBoss Modules. So it
>>       >>  would be possible to load jars on demand, or at least use it as
>>      a way to
>>       >>  figure out which modules aren't being used ;).
>>       >>
>>       >>
>>       >>  On 2/21/2014 10:22 AM, Brian Stansberry wrote:
>>       >>>  This will move things in the right direction, but not all the
>>      way there
>>       >>>  yet. Note the set of capabilities Bill mention: web, CDI,
>>      JAX-RS, JPA.
>>       >>>  That sounds like our "Web" variant, plus some stuff. It's the
>>      easy "plus
>>       >>>  some stuff" part that needs sorting at some point.
>>       >>>
>>       >>>  On 2/21/14, 9:08 AM, Toma? Cerar wrote:
>>       >>>>  Bill,
>>       >>>>
>>       >>>>  that is exactly idea we have in mind of 9.
>>       >>>>  We already started with producing WildFly core distribution in
>>      that is
>>       >>>>  WildFly with no subsystems, upon which you can build you own
>>      wildfly.
>>       >>>>  It is only 15mb and contains whole mgmt capabilites (CLI,
>>      standalone,
>>       >>>>  domain,...) you can grab it at:
>>       >>>>
>>      http://download.jboss.org/wildfly/8.0.0.Final/core/wildfly-core-8.0.0.Final.zip
>>       >>>>
>>       >>>>  For 9 we have plans to move things bit further and have
>>      decided that we
>>       >>>>  will also do split codebase for core, ee, web, .. and other
>>      distributions.
>>       >>>>
>>       >>>>  Current idea on code split up is here
>>       >>>>  https://community.jboss.org/wiki/SplittingUpTheWildflyCodeBase
>>       >>>>
>>       >>>>  --
>>       >>>>  tomaz
>>       >>>>
>>       >>>>
>>       >>>>
>>       >>>>  On Fri, Feb 21, 2014 at 3:00 PM, Bill Burke<bburke at redhat.com
>>      <mailto:bburke at redhat.com>
>>       >>>>  <mailto:bburke at redhat.com<mailto:bburke at redhat.com>>>  wrote:
>>       >>>>
>>       >>>>       On Resteasy list I have a few people "rolling their own
>>      app server"
>>       >>>>       using Netty, Weld, Resteasy and JPA.  I asked one of them
>>      "I don't
>>       >>>>       understand why you are rolling your own app server" response:
>>       >>>>
>>       >>>>       "It's actually a lot more lightweight.  The minimum I can
>>      run the
>>       >>>>       equivalent on AS7 on is ~ 180 mb in binaries, but
>>      throwing this
>>       >>>>       together is about 32 mb (and compresses further when its
>>      packaged).
>>       >>>>       I'm able to start the JVM on the bare minimum (~100mb on
>>      my linux VM)
>>       >>>>       but AS7 with all I need is about 756mb.  When rolling out
>>      in the
>>       >>>>       cloud, where all of my REST APIs are stateless, running
>>      with this
>>       >>>>       configuration helps us get a lot more per node."
>>       >>>>
>>       >>>>       I'm not complaining :), just something to think about. It
>>      might be
>>       >>>>       really valuable to focus a bit in Wildfly 9 to make it
>>      easier to create
>>       >>>>       custom profiles or even different packaging options for
>>      the app server
>>       >>>>       instead of the exploded style we currently have.
>>       >>>>       --
>>       >>>>       Bill Burke
>>       >>>>       JBoss, a division of Red Hat
>>       >>>>  http://bill.burkecentral.com
>>       >>>>       _______________________________________________
>>       >>>>       wildfly-dev mailing list
>>       >>>>  wildfly-dev at lists.jboss.org
>>      <mailto:wildfly-dev at lists.jboss.org>
>>      <mailto:wildfly-dev at lists.jboss.org
>>      <mailto:wildfly-dev at lists.jboss.org>>
>>       >>>>  https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>       >>>>
>>       >>>>
>>       >>>>
>>       >>>>
>>       >>>>  _______________________________________________
>>       >>>>  wildfly-dev mailing list
>>       >>>>  wildfly-dev at lists.jboss.org<mailto:wildfly-dev at lists.jboss.org>
>>       >>>>  https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>       >>>>
>>       >>>
>>       >>>
>>       >>
>>       >
>>       >
>>       >  --
>>       >  Brian Stansberry
>>       >  Senior Principal Software Engineer
>>       >  JBoss by Red Hat
>>       >  _______________________________________________
>>       >  wildfly-dev mailing list
>>       >  wildfly-dev at lists.jboss.org<mailto:wildfly-dev at lists.jboss.org>
>>       >  https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>      Misty Stanley-Jones, RHCE
>>      Manager, Content Services (Middleware)
>>      Direct: + 61 7 3514 8105<tel:%2B%2061%207%203514%208105>  / Mobile:
>>      +61 429 595 932<tel:%2B61%20429%20595%20932>   (TZ: GMT+10)
>>      IRC: misty (Freenode / RH)
>>
>>
>>      _______________________________________________
>>      wildfly-dev mailing list
>>      wildfly-dev at lists.jboss.org<mailto:wildfly-dev at lists.jboss.org>
>>      https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>

-- 
Sent using Postbox:
http://www.getpostbox.com

From hpehl at redhat.com  Tue Mar  4 07:17:23 2014
From: hpehl at redhat.com (Harald Pehl)
Date: Tue, 4 Mar 2014 13:17:23 +0100
Subject: [wildfly-dev] Admin Console / Homepage / Sidebar links
Message-ID: <77B44DAE-08C0-4663-ADF5-C0F067D82D98@redhat.com>

I'm working on the new homepage for the Admin Console. The homepage will contain a sidebar with links to various related topics. The links are grouped into 3-4 sections, where each section should contain not more than 4-5 links. For EAP there are links to the knowledge base, training courses, consulting, ...

I was wondering what links make sense for upstream and came up with this proposal:

--------------------------------------------------
[General Resources]
WildFly Documentation: https://docs.jboss.org/author/display/WFLY8/Documentation
Admin Guide: https://docs.jboss.org/author/display/WFLY8/Admin+Guide
Issues: https://issues.jboss.org/browse/WFLY
Latest News: http://wildfly.org/news/

[Get Help]
User Forums: https://community.jboss.org/en/wildfly?view=discussions
IRC: irc://freenode.org/#wildfly
Developers Mailing List: https://lists.jboss.org/mailman/listinfo/wildfly-dev

[Contribute]
Source Code: https://github.com/wildfly
Hacking On WildFly Guide: https://community.jboss.org/wiki/HackingOnWildFly
Extending WildFly: https://docs.jboss.org/author/display/WFLY8/Extending+WildFly+8
--------------------------------------------------

What do you think? Is something missing?

.: Harald

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



From kabir.khan at jboss.com  Tue Mar  4 07:36:02 2014
From: kabir.khan at jboss.com (Kabir Khan)
Date: Tue, 4 Mar 2014 12:36:02 +0000
Subject: [wildfly-dev] Admin Console / Homepage / Sidebar links
In-Reply-To: <77B44DAE-08C0-4663-ADF5-C0F067D82D98@redhat.com>
References: <77B44DAE-08C0-4663-ADF5-C0F067D82D98@redhat.com>
Message-ID: <712F08DC-6307-4B27-9149-93C803CFF2AD@jboss.com>


On 4 Mar 2014, at 12:17, Harald Pehl <hpehl at redhat.com> wrote:

> I'm working on the new homepage for the Admin Console. The homepage will contain a sidebar with links to various related topics. The links are grouped into 3-4 sections, where each section should contain not more than 4-5 links. For EAP there are links to the knowledge base, training courses, consulting, ...
> 
> I was wondering what links make sense for upstream and came up with this proposal:
> 
> --------------------------------------------------
> [General Resources]
> WildFly Documentation: https://docs.jboss.org/author/display/WFLY8/Documentation
> Admin Guide: https://docs.jboss.org/author/display/WFLY8/Admin+Guide
> Issues: https://issues.jboss.org/browse/WFLY
Perhaps also a link to the plain http://wildfly.org as well?
> 
> Latest News: http://wildfly.org/news/
> 
> [Get Help]
> User Forums: https://community.jboss.org/en/wildfly?view=discussions
> IRC: irc://freenode.org/#wildfly
> Developers Mailing List: https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> [Contribute]
> Source Code: https://github.com/wildfly
Should ^^ be https://github.com/wildfly/wildfly instead? That is the main WF project. For a beginner the list of all the other projects might be a bit confusing
> Hacking On WildFly Guide: https://community.jboss.org/wiki/HackingOnWildFly
> Extending WildFly: https://docs.jboss.org/author/display/WFLY8/Extending+WildFly+8
> --------------------------------------------------
> 
> What do you think? Is something missing?
> 
> .: Harald
> 
> ---
> 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



From hpehl at redhat.com  Tue Mar  4 07:38:11 2014
From: hpehl at redhat.com (Harald Pehl)
Date: Tue, 4 Mar 2014 13:38:11 +0100
Subject: [wildfly-dev] Admin Console / Homepage / Sidebar links
In-Reply-To: <712F08DC-6307-4B27-9149-93C803CFF2AD@jboss.com>
References: <77B44DAE-08C0-4663-ADF5-C0F067D82D98@redhat.com>
	<712F08DC-6307-4B27-9149-93C803CFF2AD@jboss.com>
Message-ID: <1E4D0274-6BFA-4D0E-A70D-F76C770ECC1E@redhat.com>


Am 04.03.2014 um 13:36 schrieb Kabir Khan <kabir.khan at jboss.com>:

> 
> On 4 Mar 2014, at 12:17, Harald Pehl <hpehl at redhat.com> wrote:
> 
>> I'm working on the new homepage for the Admin Console. The homepage will contain a sidebar with links to various related topics. The links are grouped into 3-4 sections, where each section should contain not more than 4-5 links. For EAP there are links to the knowledge base, training courses, consulting, ...
>> 
>> I was wondering what links make sense for upstream and came up with this proposal:
>> 
>> --------------------------------------------------
>> [General Resources]
>> WildFly Documentation: https://docs.jboss.org/author/display/WFLY8/Documentation
>> Admin Guide: https://docs.jboss.org/author/display/WFLY8/Admin+Guide
>> Issues: https://issues.jboss.org/browse/WFLY
> Perhaps also a link to the plain http://wildfly.org as well?

Yes, makes sense.

>> 
>> Latest News: http://wildfly.org/news/
>> 
>> [Get Help]
>> User Forums: https://community.jboss.org/en/wildfly?view=discussions
>> IRC: irc://freenode.org/#wildfly
>> Developers Mailing List: https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> 
>> [Contribute]
>> Source Code: https://github.com/wildfly
> Should ^^ be https://github.com/wildfly/wildfly instead? That is the main WF project. For a beginner the list of all the other projects might be a bit confusing

Thanks for the fix.

>> Hacking On WildFly Guide: https://community.jboss.org/wiki/HackingOnWildFly
>> Extending WildFly: https://docs.jboss.org/author/display/WFLY8/Extending+WildFly+8
>> --------------------------------------------------
>> 
>> What do you think? Is something missing?
>> 
>> .: Harald
>> 
>> ---
>> 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
> 

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



From tomaz.cerar at gmail.com  Tue Mar  4 08:47:01 2014
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Tue, 4 Mar 2014 14:47:01 +0100
Subject: [wildfly-dev] Admin Console / Homepage / Sidebar links
In-Reply-To: <1E4D0274-6BFA-4D0E-A70D-F76C770ECC1E@redhat.com>
References: <77B44DAE-08C0-4663-ADF5-C0F067D82D98@redhat.com>
	<712F08DC-6307-4B27-9149-93C803CFF2AD@jboss.com>
	<1E4D0274-6BFA-4D0E-A70D-F76C770ECC1E@redhat.com>
Message-ID: <CAMquZP5h+KVWoN0VcPeWCfRG9xUSci64h4kpJEnaH-ZsBFOYpA@mail.gmail.com>

Also please add link to http://wildscribe.github.io/

--
tomaz


On Tue, Mar 4, 2014 at 1:38 PM, Harald Pehl <hpehl at redhat.com> wrote:

>
> Am 04.03.2014 um 13:36 schrieb Kabir Khan <kabir.khan at jboss.com>:
>
> >
> > On 4 Mar 2014, at 12:17, Harald Pehl <hpehl at redhat.com> wrote:
> >
> >> I'm working on the new homepage for the Admin Console. The homepage
> will contain a sidebar with links to various related topics. The links are
> grouped into 3-4 sections, where each section should contain not more than
> 4-5 links. For EAP there are links to the knowledge base, training courses,
> consulting, ...
> >>
> >> I was wondering what links make sense for upstream and came up with
> this proposal:
> >>
> >> --------------------------------------------------
> >> [General Resources]
> >> WildFly Documentation:
> https://docs.jboss.org/author/display/WFLY8/Documentation
> >> Admin Guide: https://docs.jboss.org/author/display/WFLY8/Admin+Guide
> >> Issues: https://issues.jboss.org/browse/WFLY
> > Perhaps also a link to the plain http://wildfly.org as well?
>
> Yes, makes sense.
>
> >>
> >> Latest News: http://wildfly.org/news/
> >>
> >> [Get Help]
> >> User Forums: https://community.jboss.org/en/wildfly?view=discussions
> >> IRC: irc://freenode.org/#wildfly
> >> Developers Mailing List:
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>
> >> [Contribute]
> >> Source Code: https://github.com/wildfly
> > Should ^^ be https://github.com/wildfly/wildfly instead? That is the
> main WF project. For a beginner the list of all the other projects might be
> a bit confusing
>
> Thanks for the fix.
>
> >> Hacking On WildFly Guide:
> https://community.jboss.org/wiki/HackingOnWildFly
> >> Extending WildFly:
> https://docs.jboss.org/author/display/WFLY8/Extending+WildFly+8
> >> --------------------------------------------------
> >>
> >> What do you think? Is something missing?
> >>
> >> .: Harald
> >>
> >> ---
> >> 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
> >
>
> ---
> Harald Pehl
> JBoss by Red Hat
> http://hpehl.info
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140304/d50517a4/attachment.html 

From giriraj.sharma27 at gmail.com  Tue Mar  4 08:51:32 2014
From: giriraj.sharma27 at gmail.com (Giriraj Sharma)
Date: Tue, 4 Mar 2014 19:21:32 +0530
Subject: [wildfly-dev] GSoc aspirant wishing to seek valuable guide
 regarding JBoss AS 7(wildfly) quickstarts project.
Message-ID: <CAB5vuUyGM3UZ2kL2YixRvvKLpSGeXepykcAGfLarhzY7By51RQ@mail.gmail.com>

Hii,I am Giriraj Sharma, a dedicated GSoc'14 aspirant(3 years' experience
in JavaSE+1.5 year's experience in JavaEE) from Dept. of Computer Science,
National Institute of Technology, HP, India, interested in making valuable
contribution to the project* JBoss AS Quickstarts  : JBoss AS
management,services and modules*(
https://community.jboss.org/wiki/GSOC14Ideas?_sscc=t<https://community.jboss.org/docs/DOC-52233?_sscc=t>)
listed in JBoss GSoc 2014 ideas Page.



I was initially interested in contributing quickstarts for hibernate ORM
with JBoss AS. It was mentioned as a proposed project on the ideas page. I
forked *jboss-developer/jboss-eap-quickstarts* repository from github a few
weeks back and I read the guide to contributing to a quickstart (
http://www.jboss.org/jdf/quickstarts/get-involved/).* I have been actively
committing on git repository
(https://github.com/jboss-developer/jboss-eap-quickstarts
<https://github.com/jboss-developer/jboss-eap-quickstarts>) since past
15-20 days. One of my commit has been merged  and my several other(11)
commits are under code review.* But,I recently came to know that hibernate
quickstarts have been removed form GSoc 2014 JBoss project ideas page.The
mentors told me that it was listed in GSoc 2014 ideas page because it was
copy-pasted from GSoc 2013 ideas page but is not a part of GSoc 2014
ideas.This project is removed in the new modified list of GSoc 2014 ideas.



The project proposal *JBoss AS Quickstarts  : JBoss AS management,services
and modules *is still a part of *GSoc 2014 JBoss ideas* Page.I am really
enthusiastic about contributing quickstarts for JBoss AS as it will let me
help in understanding the architecture and scripting down the server. I am
currently reading through the documentation of JBoss AS *Admin Guide*
*https://docs.jboss.org/author/display/AS7/Documentation
<https://docs.jboss.org/author/display/AS7/Documentation>. *I have also
forked up the wildfly/wildfly repository (wildfly/wildfly ?
GitHub<https://github.com/wildfly/wildfly>)
and read contribution guide (Hacking on
AS7<https://community.jboss.org/docs/DOC-15596>
).

Basically, I am a newbie but, an application developer for J2EE
technologies. I have used JBoss AS 7 for my past projects but here I shall
be dealing with JBoss AS itself.* I wish to have a bit of your guidance so
as how to start up working upon JBoss AS quickstarts and is the project
proposal about working on quickstarts(demo applications) or is it about
actually writing code/patches for JBoss AS. Please give me brief details
about how I may start up contributing for this project proposal.*

-- 
Giriraj Sharma,
Department of Computer Science
National Institute of Technology Hamirpur
http://girirajsharma27.wix.com/giriraj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140304/469bcd5f/attachment.html 

From hpehl at redhat.com  Tue Mar  4 09:04:22 2014
From: hpehl at redhat.com (Harald Pehl)
Date: Tue, 4 Mar 2014 15:04:22 +0100
Subject: [wildfly-dev] Admin Console / Homepage / Sidebar links
In-Reply-To: <CAMquZP5h+KVWoN0VcPeWCfRG9xUSci64h4kpJEnaH-ZsBFOYpA@mail.gmail.com>
References: <77B44DAE-08C0-4663-ADF5-C0F067D82D98@redhat.com>
	<712F08DC-6307-4B27-9149-93C803CFF2AD@jboss.com>
	<1E4D0274-6BFA-4D0E-A70D-F76C770ECC1E@redhat.com>
	<CAMquZP5h+KVWoN0VcPeWCfRG9xUSci64h4kpJEnaH-ZsBFOYpA@mail.gmail.com>
Message-ID: <57E7966B-EE23-4DFC-9A77-36E8D0742A80@redhat.com>


Am 04.03.2014 um 14:47 schrieb Toma? Cerar <tomaz.cerar at gmail.com>:

> Also please add link to http://wildscribe.github.io/

Always forget about that. Will add it.

> 
> --
> tomaz
> 
> 
> On Tue, Mar 4, 2014 at 1:38 PM, Harald Pehl <hpehl at redhat.com> wrote:
> 
> Am 04.03.2014 um 13:36 schrieb Kabir Khan <kabir.khan at jboss.com>:
> 
> >
> > On 4 Mar 2014, at 12:17, Harald Pehl <hpehl at redhat.com> wrote:
> >
> >> I'm working on the new homepage for the Admin Console. The homepage will contain a sidebar with links to various related topics. The links are grouped into 3-4 sections, where each section should contain not more than 4-5 links. For EAP there are links to the knowledge base, training courses, consulting, ...
> >>
> >> I was wondering what links make sense for upstream and came up with this proposal:
> >>
> >> --------------------------------------------------
> >> [General Resources]
> >> WildFly Documentation: https://docs.jboss.org/author/display/WFLY8/Documentation
> >> Admin Guide: https://docs.jboss.org/author/display/WFLY8/Admin+Guide
> >> Issues: https://issues.jboss.org/browse/WFLY
> > Perhaps also a link to the plain http://wildfly.org as well?
> 
> Yes, makes sense.
> 
> >>
> >> Latest News: http://wildfly.org/news/
> >>
> >> [Get Help]
> >> User Forums: https://community.jboss.org/en/wildfly?view=discussions
> >> IRC: irc://freenode.org/#wildfly
> >> Developers Mailing List: https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>
> >> [Contribute]
> >> Source Code: https://github.com/wildfly
> > Should ^^ be https://github.com/wildfly/wildfly instead? That is the main WF project. For a beginner the list of all the other projects might be a bit confusing
> 
> Thanks for the fix.
> 
> >> Hacking On WildFly Guide: https://community.jboss.org/wiki/HackingOnWildFly
> >> Extending WildFly: https://docs.jboss.org/author/display/WFLY8/Extending+WildFly+8
> >> --------------------------------------------------
> >>
> >> What do you think? Is something missing?
> >>
> >> .: Harald
> >>
> >> ---
> >> 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
> >
> 
> ---
> 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
> 

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

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

From arun.gupta at gmail.com  Tue Mar  4 09:11:41 2014
From: arun.gupta at gmail.com (Arun Gupta)
Date: Tue, 4 Mar 2014 06:11:41 -0800
Subject: [wildfly-dev] Admin Console / Homepage / Sidebar links
In-Reply-To: <77B44DAE-08C0-4663-ADF5-C0F067D82D98@redhat.com>
References: <77B44DAE-08C0-4663-ADF5-C0F067D82D98@redhat.com>
Message-ID: <CAGBoHQU1PnYua8SCYtG6Fp5euoVc58T+=hLzkEm+RrExdOofUg@mail.gmail.com>

Is there a way to add a "call home" feature using a script in this
panel as well ?

This will send a geo ping from where ever the admin console is
launched which can then be plotted in a map mashup to show "active
users" ?

Arun

On Tue, Mar 4, 2014 at 4:17 AM, Harald Pehl <hpehl at redhat.com> wrote:
> I'm working on the new homepage for the Admin Console. The homepage will contain a sidebar with links to various related topics. The links are grouped into 3-4 sections, where each section should contain not more than 4-5 links. For EAP there are links to the knowledge base, training courses, consulting, ...
>
> I was wondering what links make sense for upstream and came up with this proposal:
>
> --------------------------------------------------
> [General Resources]
> WildFly Documentation: https://docs.jboss.org/author/display/WFLY8/Documentation
> Admin Guide: https://docs.jboss.org/author/display/WFLY8/Admin+Guide
> Issues: https://issues.jboss.org/browse/WFLY
> Latest News: http://wildfly.org/news/
>
> [Get Help]
> User Forums: https://community.jboss.org/en/wildfly?view=discussions
> IRC: irc://freenode.org/#wildfly
> Developers Mailing List: https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> [Contribute]
> Source Code: https://github.com/wildfly
> Hacking On WildFly Guide: https://community.jboss.org/wiki/HackingOnWildFly
> Extending WildFly: https://docs.jboss.org/author/display/WFLY8/Extending+WildFly+8
> --------------------------------------------------
>
> What do you think? Is something missing?
>
> .: Harald
>
> ---
> 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



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


From tomaz.cerar at gmail.com  Tue Mar  4 09:19:30 2014
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Tue, 4 Mar 2014 15:19:30 +0100
Subject: [wildfly-dev] Admin Console / Homepage / Sidebar links
In-Reply-To: <CAGBoHQU1PnYua8SCYtG6Fp5euoVc58T+=hLzkEm+RrExdOofUg@mail.gmail.com>
References: <77B44DAE-08C0-4663-ADF5-C0F067D82D98@redhat.com>
	<CAGBoHQU1PnYua8SCYtG6Fp5euoVc58T+=hLzkEm+RrExdOofUg@mail.gmail.com>
Message-ID: <CAMquZP6BPjjZtq=m-D0BYrbYyfmkkdRU9eMGr8i6D7GT+vswgQ@mail.gmail.com>

On Tue, Mar 4, 2014 at 3:11 PM, Arun Gupta <arun.gupta at gmail.com> wrote:

> Is there a way to add a "call home" feature using a script in this
> panel as well ?
>
> This will send a geo ping from where ever the admin console is
> launched which can then be plotted in a map mashup to show "active
> users" ?
>


There is noting that devs hate more than extra tracking. It will backfire
at us...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140304/b20cae79/attachment.html 

From brian.stansberry at redhat.com  Tue Mar  4 09:21:26 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 04 Mar 2014 08:21:26 -0600
Subject: [wildfly-dev] Admin Console / Homepage / Sidebar links
In-Reply-To: <77B44DAE-08C0-4663-ADF5-C0F067D82D98@redhat.com>
References: <77B44DAE-08C0-4663-ADF5-C0F067D82D98@redhat.com>
Message-ID: <5315E166.4070607@redhat.com>

On 3/4/14, 6:17 AM, Harald Pehl wrote:
> I'm working on the new homepage for the Admin Console. The homepage will contain a sidebar with links to various related topics. The links are grouped into 3-4 sections, where each section should contain not more than 4-5 links. For EAP there are links to the knowledge base, training courses, consulting, ...
>
> I was wondering what links make sense for upstream and came up with this proposal:
>
> --------------------------------------------------
> [General Resources]
> WildFly Documentation: https://docs.jboss.org/author/display/WFLY8/Documentation
> Admin Guide: https://docs.jboss.org/author/display/WFLY8/Admin+Guide
> Issues: https://issues.jboss.org/browse/WFLY
> Latest News: http://wildfly.org/news/
>
> [Get Help]
> User Forums: https://community.jboss.org/en/wildfly?view=discussions
> IRC: irc://freenode.org/#wildfly
> Developers Mailing List: https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> [Contribute]
> Source Code: https://github.com/wildfly
> Hacking On WildFly Guide: https://community.jboss.org/wiki/HackingOnWildFly
> Extending WildFly: https://docs.jboss.org/author/display/WFLY8/Extending+WildFly+8

I don't think this one belongs on the list. This is a specialty topic 
not particularly more broadly relevant than many other topics in the docs.

> --------------------------------------------------


>
> What do you think? Is something missing?
>
> .: Harald
>
> ---
> Harald Pehl
> JBoss by Red Hat
> http://hpehl.info
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


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

From hpehl at redhat.com  Tue Mar  4 09:22:08 2014
From: hpehl at redhat.com (Harald Pehl)
Date: Tue, 4 Mar 2014 15:22:08 +0100
Subject: [wildfly-dev] Admin Console / Homepage / Sidebar links
In-Reply-To: <CAGBoHQU1PnYua8SCYtG6Fp5euoVc58T+=hLzkEm+RrExdOofUg@mail.gmail.com>
References: <77B44DAE-08C0-4663-ADF5-C0F067D82D98@redhat.com>
	<CAGBoHQU1PnYua8SCYtG6Fp5euoVc58T+=hLzkEm+RrExdOofUg@mail.gmail.com>
Message-ID: <85231E9E-BD39-4597-B69C-D938AF0107E5@redhat.com>


Am 04.03.2014 um 15:11 schrieb Arun Gupta <arun.gupta at gmail.com>:

> Is there a way to add a "call home" feature using a script in this
> panel as well ?

What use case do you have in mind?

> 
> This will send a geo ping from where ever the admin console is
> launched which can then be plotted in a map mashup to show "active
> users" ?

That would be quite similar to the Google Analytics report where you can see live visitors broken down by county, region and city. Don't know whether you can share specific GA reports, though. 

.: Harald

> 
> Arun
> 
> On Tue, Mar 4, 2014 at 4:17 AM, Harald Pehl <hpehl at redhat.com> wrote:
>> I'm working on the new homepage for the Admin Console. The homepage will contain a sidebar with links to various related topics. The links are grouped into 3-4 sections, where each section should contain not more than 4-5 links. For EAP there are links to the knowledge base, training courses, consulting, ...
>> 
>> I was wondering what links make sense for upstream and came up with this proposal:
>> 
>> --------------------------------------------------
>> [General Resources]
>> WildFly Documentation: https://docs.jboss.org/author/display/WFLY8/Documentation
>> Admin Guide: https://docs.jboss.org/author/display/WFLY8/Admin+Guide
>> Issues: https://issues.jboss.org/browse/WFLY
>> Latest News: http://wildfly.org/news/
>> 
>> [Get Help]
>> User Forums: https://community.jboss.org/en/wildfly?view=discussions
>> IRC: irc://freenode.org/#wildfly
>> Developers Mailing List: https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> 
>> [Contribute]
>> Source Code: https://github.com/wildfly
>> Hacking On WildFly Guide: https://community.jboss.org/wiki/HackingOnWildFly
>> Extending WildFly: https://docs.jboss.org/author/display/WFLY8/Extending+WildFly+8
>> --------------------------------------------------
>> 
>> What do you think? Is something missing?
>> 
>> .: Harald
>> 
>> ---
>> 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
> 
> 
> 
> -- 
> http://blog.arungupta.me
> http://twitter.com/arungupta

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



From hbraun at redhat.com  Tue Mar  4 09:30:41 2014
From: hbraun at redhat.com (Heiko Braun)
Date: Tue, 4 Mar 2014 15:30:41 +0100
Subject: [wildfly-dev] Admin Console / Homepage / Sidebar links
In-Reply-To: <CAGBoHQU1PnYua8SCYtG6Fp5euoVc58T+=hLzkEm+RrExdOofUg@mail.gmail.com>
References: <77B44DAE-08C0-4663-ADF5-C0F067D82D98@redhat.com>
	<CAGBoHQU1PnYua8SCYtG6Fp5euoVc58T+=hLzkEm+RrExdOofUg@mail.gmail.com>
Message-ID: <9C1FBE2B-859F-48B6-9FEF-FFA201380C15@redhat.com>



WF has google analytics enabled. We get much more info then that.

On 04 Mar 2014, at 15:11, Arun Gupta <arun.gupta at gmail.com> wrote:

> This will send a geo ping 

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

From jorsol at gmail.com  Tue Mar  4 09:31:29 2014
From: jorsol at gmail.com (=?ISO-8859-1?Q?Jorge_Sol=F3rzano?=)
Date: Tue, 4 Mar 2014 08:31:29 -0600
Subject: [wildfly-dev] Admin Console / Homepage / Sidebar links
In-Reply-To: <CAMquZP6BPjjZtq=m-D0BYrbYyfmkkdRU9eMGr8i6D7GT+vswgQ@mail.gmail.com>
References: <77B44DAE-08C0-4663-ADF5-C0F067D82D98@redhat.com>
	<CAGBoHQU1PnYua8SCYtG6Fp5euoVc58T+=hLzkEm+RrExdOofUg@mail.gmail.com>
	<CAMquZP6BPjjZtq=m-D0BYrbYyfmkkdRU9eMGr8i6D7GT+vswgQ@mail.gmail.com>
Message-ID: <CA+cVU8O7en_QEenbuMhrRN4Ra1A0xNi2esQfMnqL_A=fByeTCA@mail.gmail.com>

That's right... the tracking is not a good idea at all... if you intend to
add tracking, please make it out-in not opt-out.


Jorge Sol?rzano
http://www.jorsol.com


On Tue, Mar 4, 2014 at 8:19 AM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:

>
> On Tue, Mar 4, 2014 at 3:11 PM, Arun Gupta <arun.gupta at gmail.com> wrote:
>
>> Is there a way to add a "call home" feature using a script in this
>> panel as well ?
>>
>> This will send a geo ping from where ever the admin console is
>> launched which can then be plotted in a map mashup to show "active
>> users" ?
>>
>
>
> ??
> There is noting that devs hate more than extr
> ??
> a tracking. It will backfire at us...
>
> _______________________________________________
> 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/20140304/f96e7c05/attachment.html 

From bburke at redhat.com  Tue Mar  4 09:35:22 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 04 Mar 2014 09:35:22 -0500
Subject: [wildfly-dev] smaller footprints
In-Reply-To: <531574B1.5080404@gmail.com>
References: <53075BEA.8030608@redhat.com>	<CAMquZP4RPXFgAPsCnnOLvH=XTkeQJ2bno5ms5yimD3gK6erkbw@mail.gmail.com>	<53076F18.3020603@redhat.com>
	<5307737C.2080603@redhat.com>	<53077867.3050600@redhat.com>	<3807F2B2-87E9-43F8-9A5C-E60340C748FF@redhat.com>
	<CAAoo=c7rWYObqRGQN2g34PR0bdP6YLeFCaoi3E5f7PuMQkav7Q@mail.gmail.com>
	<530B508F.5040409@redhat.com> <531574B1.5080404@gmail.com>
Message-ID: <5315E4AA.1070603@redhat.com>

Great work Stuart!  I'm really happy somebody is taking initiative on 
this because I really think it will help a lot with Wildfly adoption. 
Is it ready to use?  I'm willing to try it out RIGHT NOW.

I've expressed some of these thoughts months ago when I introduced the 
JBoss Modules artifact features, but here was my vision:

* maven repos would become to Wildfly as /lib /usr/local/lib directory 
structures are to unix.
* The JBoss Module artifact feature would become the preferred way to 
deploy Wildfly/JBoss.  This would make it really easy to support 
multiple versions as well as different distro's of JBoss/Wildfly on the 
same machine and save huge amounts of disk space.  If we could get a JVM 
that could share JAR instances between processes to save on RAM, the win 
would be even bigger!  Think of the cloud implications!
* JBoss Module definitions could eventually be defined in one large XML 
file.  We would have maven/ant plugins to help build this large XML file.
* This single JBoss Module XML file could be bundled within a 
JBoss/Wildfly "executable jar".
* This "executable jar" could be overlayed with external JBoss Module 
XML files or directory structures.
* Finally, you could create this "executable jar" for any Java project.




On 3/4/2014 1:37 AM, Stuart Douglas wrote:
> I have made a start on this split, and I think the solution I am working
> on will meet all the use cases, including users that want to cut down an
> existing server, and users that want to re-use the jars in their maven
> repo using Bill's changes to JBoss Modules. It still needs a bit more
> work and a lot of cleanup, however it seems to work:
>
> https://github.com/stuartwdouglas/wildfly/compare/wildfly-build-plugin
>
> So basically the core of it is a maven plugin that builds a Wildfly
> distribution, either from scratch or use other distributions as a base.
>
> It also supports building servers that use the new <artifact>
> functionality in jboss modules, and cutting down an existing server into
> a smaller server with only the specified modules (and their transitive
> dependencies).
>
> The way this will work in practice is that each Wildfly sub project will
> produce two different server artifacts, one of which is a server without
> any jars using artifact references, and a more traditional version with
> jars packaged in the module directory. Downstream projects will consume
> the smaller version without all the jars, so when a version changes the
> download should be less than 5mb rather than larger than 100mb (the
> plugin has the ability to turn a server that uses artifact references
> into a server that contains the jars in the modules dir).
>
> Basically the upshot is that it should be basically possible to build
> whatever configuration of server you want once this is part of our build
> process, and we should also be publishing lightweight server artifacts
> that use the jars in the maven repo as well as our traditional
> 'everything and the kitchen sink' build.
>
> It is anticipated that 3rd party projects build on Wildfly would also
> use this plugin (I think at the moment the standard approach has been to
> copy and modify our ant scripts).
>
> This is still very much a work in progress, so nothing is set in stone
> yet and any comments are welcome.
>
> Stuart
>
>
> Bill Burke wrote:
>> A lot of users want that ability, would you rather have them roll Netty
>> + whatever?
>>
>> On 2/23/2014 9:10 PM, Stuart Douglas wrote:
>>> No, because that means we essentially have to support and test every
>>> possible combination that someone might select.
>>>
>>> Stuart
>>>
>>>
>>> On Mon, Feb 24, 2014 at 7:13 AM, Misty Stanley-Jones<misty at redhat.com
>>> <mailto:misty at redhat.com>>  wrote:
>>>
>>>      I know you guys aren?t there yet, but can we think about wrapping a
>>>      GUI around this, so that the developer only needs to tick the boxes
>>>      for what he does/doesn?t want, with dependencies sorted out
>>>      automatically? Maybe some default profiles that select a group of
>>>      things, but the ability to go in and add or remove individual
>>>      subsystems as needed? Maybe this could be part of the installer but
>>>      could optionally be run post-install as well.
>>>
>>>      On Feb 22, 2014, at 2:01 AM, Brian Stansberry
>>>      <brian.stansberry at redhat.com<mailto:brian.stansberry at redhat.com>>
>>>      wrote:
>>>
>>>       >  When I said "Web" I meant the thing described on that wiki
>>> page Tomaz
>>>       >  linked:
>>>       >
>>>       >  "Web
>>>       >
>>>       >  Undertow subsystem, and all related dependencies, including
>>> a small
>>>       >  subset of EE and JNDI. This is basically just a Servlet
>>>      container, and
>>>       >  will provide a platform for people that want to create web
>>> based
>>>       >  appliances or applications, and don't need all the additional
>>>       >  functionality that Wildfly provides. We should end up with
>>>      something as
>>>       >  lightweight as Tomcat or Jetty, but with all our advanced
>>> management
>>>       >  functionality."
>>>       >
>>>       >  On 2/21/14, 9:40 AM, Bill Burke wrote:
>>>       >>  Its also "Web" minus some stuff.  For my project I want just
>>>      Servlet,
>>>       >>  JAX-RS, JPA, and datasources.   Its very very hard to
>>> figure out
>>>      how to
>>>       >>  remove a subsystem and all its associated modules.
>>>       >>
>>>       >>  BTW, I think my maven artifact thing got into JBoss
>>> Modules. So it
>>>       >>  would be possible to load jars on demand, or at least use
>>> it as
>>>      a way to
>>>       >>  figure out which modules aren't being used ;).
>>>       >>
>>>       >>
>>>       >>  On 2/21/2014 10:22 AM, Brian Stansberry wrote:
>>>       >>>  This will move things in the right direction, but not all the
>>>      way there
>>>       >>>  yet. Note the set of capabilities Bill mention: web, CDI,
>>>      JAX-RS, JPA.
>>>       >>>  That sounds like our "Web" variant, plus some stuff. It's the
>>>      easy "plus
>>>       >>>  some stuff" part that needs sorting at some point.
>>>       >>>
>>>       >>>  On 2/21/14, 9:08 AM, Toma? Cerar wrote:
>>>       >>>>  Bill,
>>>       >>>>
>>>       >>>>  that is exactly idea we have in mind of 9.
>>>       >>>>  We already started with producing WildFly core
>>> distribution in
>>>      that is
>>>       >>>>  WildFly with no subsystems, upon which you can build you own
>>>      wildfly.
>>>       >>>>  It is only 15mb and contains whole mgmt capabilites (CLI,
>>>      standalone,
>>>       >>>>  domain,...) you can grab it at:
>>>       >>>>
>>>
>>> http://download.jboss.org/wildfly/8.0.0.Final/core/wildfly-core-8.0.0.Final.zip
>>>
>>>       >>>>
>>>       >>>>  For 9 we have plans to move things bit further and have
>>>      decided that we
>>>       >>>>  will also do split codebase for core, ee, web, .. and other
>>>      distributions.
>>>       >>>>
>>>       >>>>  Current idea on code split up is here
>>>       >>>>
>>> https://community.jboss.org/wiki/SplittingUpTheWildflyCodeBase
>>>       >>>>
>>>       >>>>  --
>>>       >>>>  tomaz
>>>       >>>>
>>>       >>>>
>>>       >>>>
>>>       >>>>  On Fri, Feb 21, 2014 at 3:00 PM, Bill
>>> Burke<bburke at redhat.com
>>>      <mailto:bburke at redhat.com>
>>>       >>>>  <mailto:bburke at redhat.com<mailto:bburke at redhat.com>>>
>>> wrote:
>>>       >>>>
>>>       >>>>       On Resteasy list I have a few people "rolling their own
>>>      app server"
>>>       >>>>       using Netty, Weld, Resteasy and JPA.  I asked one of
>>> them
>>>      "I don't
>>>       >>>>       understand why you are rolling your own app server"
>>> response:
>>>       >>>>
>>>       >>>>       "It's actually a lot more lightweight.  The minimum
>>> I can
>>>      run the
>>>       >>>>       equivalent on AS7 on is ~ 180 mb in binaries, but
>>>      throwing this
>>>       >>>>       together is about 32 mb (and compresses further when
>>> its
>>>      packaged).
>>>       >>>>       I'm able to start the JVM on the bare minimum
>>> (~100mb on
>>>      my linux VM)
>>>       >>>>       but AS7 with all I need is about 756mb.  When
>>> rolling out
>>>      in the
>>>       >>>>       cloud, where all of my REST APIs are stateless, running
>>>      with this
>>>       >>>>       configuration helps us get a lot more per node."
>>>       >>>>
>>>       >>>>       I'm not complaining :), just something to think
>>> about. It
>>>      might be
>>>       >>>>       really valuable to focus a bit in Wildfly 9 to make it
>>>      easier to create
>>>       >>>>       custom profiles or even different packaging options for
>>>      the app server
>>>       >>>>       instead of the exploded style we currently have.
>>>       >>>>       --
>>>       >>>>       Bill Burke
>>>       >>>>       JBoss, a division of Red Hat
>>>       >>>>  http://bill.burkecentral.com
>>>       >>>>       _______________________________________________
>>>       >>>>       wildfly-dev mailing list
>>>       >>>>  wildfly-dev at lists.jboss.org
>>>      <mailto:wildfly-dev at lists.jboss.org>
>>>      <mailto:wildfly-dev at lists.jboss.org
>>>      <mailto:wildfly-dev at lists.jboss.org>>
>>>       >>>>  https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>       >>>>
>>>       >>>>
>>>       >>>>
>>>       >>>>
>>>       >>>>  _______________________________________________
>>>       >>>>  wildfly-dev mailing list
>>>       >>>>
>>> wildfly-dev at lists.jboss.org<mailto:wildfly-dev at lists.jboss.org>
>>>       >>>>  https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>       >>>>
>>>       >>>
>>>       >>>
>>>       >>
>>>       >
>>>       >
>>>       >  --
>>>       >  Brian Stansberry
>>>       >  Senior Principal Software Engineer
>>>       >  JBoss by Red Hat
>>>       >  _______________________________________________
>>>       >  wildfly-dev mailing list
>>>       >  wildfly-dev at lists.jboss.org<mailto:wildfly-dev at lists.jboss.org>
>>>       >  https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>      Misty Stanley-Jones, RHCE
>>>      Manager, Content Services (Middleware)
>>>      Direct: + 61 7 3514 8105<tel:%2B%2061%207%203514%208105>  / Mobile:
>>>      +61 429 595 932<tel:%2B61%20429%20595%20932>   (TZ: GMT+10)
>>>      IRC: misty (Freenode / RH)
>>>
>>>
>>>      _______________________________________________
>>>      wildfly-dev mailing list
>>>      wildfly-dev at lists.jboss.org<mailto:wildfly-dev at lists.jboss.org>
>>>      https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bbrowning at redhat.com  Tue Mar  4 09:48:10 2014
From: bbrowning at redhat.com (Ben Browning)
Date: Tue, 04 Mar 2014 09:48:10 -0500
Subject: [wildfly-dev] Admin Console / Homepage / Sidebar links
In-Reply-To: <CA+cVU8O7en_QEenbuMhrRN4Ra1A0xNi2esQfMnqL_A=fByeTCA@mail.gmail.com>
References: <77B44DAE-08C0-4663-ADF5-C0F067D82D98@redhat.com>	<CAGBoHQU1PnYua8SCYtG6Fp5euoVc58T+=hLzkEm+RrExdOofUg@mail.gmail.com>	<CAMquZP6BPjjZtq=m-D0BYrbYyfmkkdRU9eMGr8i6D7GT+vswgQ@mail.gmail.com>
	<CA+cVU8O7en_QEenbuMhrRN4Ra1A0xNi2esQfMnqL_A=fByeTCA@mail.gmail.com>
Message-ID: <5315E7AA.2000804@redhat.com>

WildFly already has tracking inside the admin console. Every time you 
visit it, it pings Google Analytics.

I'm not sure if there's a way to opt out of this or not, other than just 
not using the admin console.

Ben

On 03/04/2014 09:31 AM, Jorge Sol?rzano wrote:
> That's right... the tracking is not a good idea at all... if you intend
> to add tracking, please make it out-in not opt-out.
>
>
> Jorge Sol?rzano
> http://www.jorsol.com
>
>
> On Tue, Mar 4, 2014 at 8:19 AM, Toma? Cerar <tomaz.cerar at gmail.com
> <mailto:tomaz.cerar at gmail.com>> wrote:
>
>
>     On Tue, Mar 4, 2014 at 3:11 PM, Arun Gupta <arun.gupta at gmail.com
>     <mailto:arun.gupta at gmail.com>> wrote:
>
>         Is there a way to add a "call home" feature using a script in this
>         panel as well ?
>
>         This will send a geo ping from where ever the admin console is
>         launched which can then be plotted in a map mashup to show "active
>         users" ?
>
>
>
>     ??
>     There is noting that devs hate more than extr
>     ??
>     a tracking. It will backfire at us...
>
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From hpehl at redhat.com  Tue Mar  4 09:51:51 2014
From: hpehl at redhat.com (Harald Pehl)
Date: Tue, 4 Mar 2014 15:51:51 +0100
Subject: [wildfly-dev] Admin Console / Homepage / Sidebar links
In-Reply-To: <5315E7AA.2000804@redhat.com>
References: <77B44DAE-08C0-4663-ADF5-C0F067D82D98@redhat.com>	<CAGBoHQU1PnYua8SCYtG6Fp5euoVc58T+=hLzkEm+RrExdOofUg@mail.gmail.com>	<CAMquZP6BPjjZtq=m-D0BYrbYyfmkkdRU9eMGr8i6D7GT+vswgQ@mail.gmail.com>
	<CA+cVU8O7en_QEenbuMhrRN4Ra1A0xNi2esQfMnqL_A=fByeTCA@mail.gmail.com>
	<5315E7AA.2000804@redhat.com>
Message-ID: <DF494F12-4BDA-4270-88C3-06B29C5740A5@redhat.com>


Am 04.03.2014 um 15:48 schrieb Ben Browning <bbrowning at redhat.com>:

> WildFly already has tracking inside the admin console. Every time you 
> visit it, it pings Google Analytics.
> 
> I'm not sure if there's a way to opt out of this or not, other than just 
> not using the admin console.
> 

For WF google analytics is enabled by default. You can disable it in the settings.

.: Harald

> Ben
> 
> On 03/04/2014 09:31 AM, Jorge Sol?rzano wrote:
>> That's right... the tracking is not a good idea at all... if you intend
>> to add tracking, please make it out-in not opt-out.
>> 
>> 
>> Jorge Sol?rzano
>> http://www.jorsol.com
>> 
>> 
>> On Tue, Mar 4, 2014 at 8:19 AM, Toma? Cerar <tomaz.cerar at gmail.com
>> <mailto:tomaz.cerar at gmail.com>> wrote:
>> 
>> 
>>    On Tue, Mar 4, 2014 at 3:11 PM, Arun Gupta <arun.gupta at gmail.com
>>    <mailto:arun.gupta at gmail.com>> wrote:
>> 
>>        Is there a way to add a "call home" feature using a script in this
>>        panel as well ?
>> 
>>        This will send a geo ping from where ever the admin console is
>>        launched which can then be plotted in a map mashup to show "active
>>        users" ?
>> 
>> 
>> 
>>    ??
>>    There is noting that devs hate more than extr
>>    ??
>>    a tracking. It will backfire at us...
>> 
>>    _______________________________________________
>>    wildfly-dev mailing list
>>    wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>    https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> 
>> 
>> 
>> 
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> 
> _______________________________________________
> 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 arun.gupta at gmail.com  Tue Mar  4 10:58:44 2014
From: arun.gupta at gmail.com (Arun Gupta)
Date: Tue, 4 Mar 2014 07:58:44 -0800
Subject: [wildfly-dev] Admin Console / Homepage / Sidebar links
In-Reply-To: <9C1FBE2B-859F-48B6-9FEF-FFA201380C15@redhat.com>
References: <77B44DAE-08C0-4663-ADF5-C0F067D82D98@redhat.com>
	<CAGBoHQU1PnYua8SCYtG6Fp5euoVc58T+=hLzkEm+RrExdOofUg@mail.gmail.com>
	<9C1FBE2B-859F-48B6-9FEF-FFA201380C15@redhat.com>
Message-ID: <CAGBoHQXHOe61wnN3TK5Ljcm8J1mMfR87hVLmo0vYu1_gBCYhZA@mail.gmail.com>

How is that google analytics data collected ? And where can I see that data ?

Does it give us a measure of our active users ? Not just download
data, but developers who are using it actively.

Arun

On Tue, Mar 4, 2014 at 6:30 AM, Heiko Braun <hbraun at redhat.com> wrote:
>
>
> WF has google analytics enabled. We get much more info then that.
>
> On 04 Mar 2014, at 15:11, Arun Gupta <arun.gupta at gmail.com> wrote:
>
> This will send a geo ping
>
>



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

From hpehl at redhat.com  Tue Mar  4 11:03:59 2014
From: hpehl at redhat.com (Harald Pehl)
Date: Tue, 4 Mar 2014 17:03:59 +0100
Subject: [wildfly-dev] Admin Console / Homepage / Sidebar links
In-Reply-To: <CAGBoHQXHOe61wnN3TK5Ljcm8J1mMfR87hVLmo0vYu1_gBCYhZA@mail.gmail.com>
References: <77B44DAE-08C0-4663-ADF5-C0F067D82D98@redhat.com>
	<CAGBoHQU1PnYua8SCYtG6Fp5euoVc58T+=hLzkEm+RrExdOofUg@mail.gmail.com>
	<9C1FBE2B-859F-48B6-9FEF-FFA201380C15@redhat.com>
	<CAGBoHQXHOe61wnN3TK5Ljcm8J1mMfR87hVLmo0vYu1_gBCYhZA@mail.gmail.com>
Message-ID: <33C8DC1E-BD57-491B-9ABF-0F1EF1915230@redhat.com>


Am 04.03.2014 um 16:58 schrieb Arun Gupta <arun.gupta at gmail.com>:

> How is that google analytics data collected ? And where can I see that data ?

You should have access to the GA site: https://www.google.com/analytics/web/?#report/visitors-overview/a35829315w63735551p65393289/

> 
> Does it give us a measure of our active users ? Not just download
> data, but developers who are using it actively.

There are tons of reports. For example there's a real time view showing the users who are running the console right now.

.: Harald
 

> 
> Arun
> 
> On Tue, Mar 4, 2014 at 6:30 AM, Heiko Braun <hbraun at redhat.com> wrote:
>> 
>> 
>> WF has google analytics enabled. We get much more info then that.
>> 
>> On 04 Mar 2014, at 15:11, Arun Gupta <arun.gupta at gmail.com> wrote:
>> 
>> This will send a geo ping
>> 
>> 
> 
> 
> 
> -- 
> http://blog.arungupta.me
> http://twitter.com/arungupta

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

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

From arun.gupta at gmail.com  Tue Mar  4 11:09:35 2014
From: arun.gupta at gmail.com (Arun Gupta)
Date: Tue, 4 Mar 2014 08:09:35 -0800
Subject: [wildfly-dev] Admin Console / Homepage / Sidebar links
In-Reply-To: <33C8DC1E-BD57-491B-9ABF-0F1EF1915230@redhat.com>
References: <77B44DAE-08C0-4663-ADF5-C0F067D82D98@redhat.com>
	<CAGBoHQU1PnYua8SCYtG6Fp5euoVc58T+=hLzkEm+RrExdOofUg@mail.gmail.com>
	<9C1FBE2B-859F-48B6-9FEF-FFA201380C15@redhat.com>
	<CAGBoHQXHOe61wnN3TK5Ljcm8J1mMfR87hVLmo0vYu1_gBCYhZA@mail.gmail.com>
	<33C8DC1E-BD57-491B-9ABF-0F1EF1915230@redhat.com>
Message-ID: <CAGBoHQVkUVs==GUTL_Gw97d2GvA8tYbtihoWvaCg+4PUfxU_og@mail.gmail.com>

Cool, thanks!

On Tue, Mar 4, 2014 at 8:03 AM, Harald Pehl <hpehl at redhat.com> wrote:
>
> Am 04.03.2014 um 16:58 schrieb Arun Gupta <arun.gupta at gmail.com>:
>
> How is that google analytics data collected ? And where can I see that data
> ?
>
>
> You should have access to the GA site:
> https://www.google.com/analytics/web/?#report/visitors-overview/a35829315w63735551p65393289/
>
>
> Does it give us a measure of our active users ? Not just download
> data, but developers who are using it actively.
>
>
> There are tons of reports. For example there's a real time view showing the
> users who are running the console right now.
>
> .: Harald
>
>
>
> Arun
>
> On Tue, Mar 4, 2014 at 6:30 AM, Heiko Braun <hbraun at redhat.com> wrote:
>
>
>
> WF has google analytics enabled. We get much more info then that.
>
> On 04 Mar 2014, at 15:11, Arun Gupta <arun.gupta at gmail.com> wrote:
>
> This will send a geo ping
>
>
>
>
>
> --
> http://blog.arungupta.me
> http://twitter.com/arungupta
>
>
> ---
> Harald Pehl
> JBoss by Red Hat
> http://hpehl.info
>



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

From smarlow at redhat.com  Tue Mar  4 11:21:47 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 04 Mar 2014 11:21:47 -0500
Subject: [wildfly-dev] Admin Console / Homepage / Sidebar links
In-Reply-To: <77B44DAE-08C0-4663-ADF5-C0F067D82D98@redhat.com>
References: <77B44DAE-08C0-4663-ADF5-C0F067D82D98@redhat.com>
Message-ID: <5315FD9B.7040203@redhat.com>

On 03/04/2014 07:17 AM, Harald Pehl wrote:
> I'm working on the new homepage for the Admin Console. The homepage will contain a sidebar with links to various related topics. The links are grouped into 3-4 sections, where each section should contain not more than 4-5 links. For EAP there are links to the knowledge base, training courses, consulting, ...
>
> I was wondering what links make sense for upstream and came up with this proposal:
>
> --------------------------------------------------
> [General Resources]
> WildFly Documentation: https://docs.jboss.org/author/display/WFLY8/Documentation
> Admin Guide: https://docs.jboss.org/author/display/WFLY8/Admin+Guide
> Issues: https://issues.jboss.org/browse/WFLY
> Latest News: http://wildfly.org/news/
>
> [Get Help]
> User Forums: https://community.jboss.org/en/wildfly?view=discussions
> IRC: irc://freenode.org/#wildfly
> Developers Mailing List: https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> [Contribute]
> Source Code: https://github.com/wildfly
> Hacking On WildFly Guide: https://community.jboss.org/wiki/HackingOnWildFly
> Extending WildFly: https://docs.jboss.org/author/display/WFLY8/Extending+WildFly+8
> --------------------------------------------------
>
> What do you think? Is something missing?

If we update https://community.jboss.org/wiki/AS7Projects for WildFly 8 
(lists project website, source, irc, jira links), is there enough room 
to list sub-project info also?

>
> .: Harald
>
> ---
> 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
>


From jperkins at redhat.com  Tue Mar  4 11:28:03 2014
From: jperkins at redhat.com (James R. Perkins)
Date: Tue, 04 Mar 2014 08:28:03 -0800
Subject: [wildfly-dev] smaller footprints
In-Reply-To: <531574B1.5080404@gmail.com>
References: <53075BEA.8030608@redhat.com>	<CAMquZP4RPXFgAPsCnnOLvH=XTkeQJ2bno5ms5yimD3gK6erkbw@mail.gmail.com>	<53076F18.3020603@redhat.com>	<5307737C.2080603@redhat.com>	<53077867.3050600@redhat.com>	<3807F2B2-87E9-43F8-9A5C-E60340C748FF@redhat.com>	<CAAoo=c7rWYObqRGQN2g34PR0bdP6YLeFCaoi3E5f7PuMQkav7Q@mail.gmail.com>	<530B508F.5040409@redhat.com>
	<531574B1.5080404@gmail.com>
Message-ID: <5315FF13.3090204@redhat.com>

Since the logging subsystem is in the core distro, I'm wondering if the  
default DUP's to add logging dependencies and search for logging 
configuration files in deployments should be disabled. There are 
attributes to disable these now which are should remain enabled in 
WildFly, but it seems the opposite might be preferable in a core-distro. 
I've not really thought about how to do that or looked over Stuarts 
branch with great detail, but just kind of throwing it out there to get 
opinions on it.

On 03/03/2014 10:37 PM, Stuart Douglas wrote:
> I have made a start on this split, and I think the solution I am working
> on will meet all the use cases, including users that want to cut down an
> existing server, and users that want to re-use the jars in their maven
> repo using Bill's changes to JBoss Modules. It still needs a bit more
> work and a lot of cleanup, however it seems to work:
>
> https://github.com/stuartwdouglas/wildfly/compare/wildfly-build-plugin
>
> So basically the core of it is a maven plugin that builds a Wildfly
> distribution, either from scratch or use other distributions as a base.
>
> It also supports building servers that use the new <artifact>
> functionality in jboss modules, and cutting down an existing server into
> a smaller server with only the specified modules (and their transitive
> dependencies).
>
> The way this will work in practice is that each Wildfly sub project will
> produce two different server artifacts, one of which is a server without
> any jars using artifact references, and a more traditional version with
> jars packaged in the module directory. Downstream projects will consume
> the smaller version without all the jars, so when a version changes the
> download should be less than 5mb rather than larger than 100mb (the
> plugin has the ability to turn a server that uses artifact references
> into a server that contains the jars in the modules dir).
>
> Basically the upshot is that it should be basically possible to build
> whatever configuration of server you want once this is part of our build
> process, and we should also be publishing lightweight server artifacts
> that use the jars in the maven repo as well as our traditional
> 'everything and the kitchen sink' build.
>
> It is anticipated that 3rd party projects build on Wildfly would also
> use this plugin (I think at the moment the standard approach has been to
> copy and modify our ant scripts).
>
> This is still very much a work in progress, so nothing is set in stone
> yet and any comments are welcome.
>
> Stuart
>
>
> Bill Burke wrote:
>> A lot of users want that ability, would you rather have them roll Netty
>> + whatever?
>>
>> On 2/23/2014 9:10 PM, Stuart Douglas wrote:
>>> No, because that means we essentially have to support and test every
>>> possible combination that someone might select.
>>>
>>> Stuart
>>>
>>>
>>> On Mon, Feb 24, 2014 at 7:13 AM, Misty Stanley-Jones<misty at redhat.com
>>> <mailto:misty at redhat.com>>  wrote:
>>>
>>>       I know you guys aren?t there yet, but can we think about wrapping a
>>>       GUI around this, so that the developer only needs to tick the boxes
>>>       for what he does/doesn?t want, with dependencies sorted out
>>>       automatically? Maybe some default profiles that select a group of
>>>       things, but the ability to go in and add or remove individual
>>>       subsystems as needed? Maybe this could be part of the installer but
>>>       could optionally be run post-install as well.
>>>
>>>       On Feb 22, 2014, at 2:01 AM, Brian Stansberry
>>>       <brian.stansberry at redhat.com<mailto:brian.stansberry at redhat.com>>
>>>       wrote:
>>>
>>>        >  When I said "Web" I meant the thing described on that wiki page Tomaz
>>>        >  linked:
>>>        >
>>>        >  "Web
>>>        >
>>>        >  Undertow subsystem, and all related dependencies, including a small
>>>        >  subset of EE and JNDI. This is basically just a Servlet
>>>       container, and
>>>        >  will provide a platform for people that want to create web based
>>>        >  appliances or applications, and don't need all the additional
>>>        >  functionality that Wildfly provides. We should end up with
>>>       something as
>>>        >  lightweight as Tomcat or Jetty, but with all our advanced management
>>>        >  functionality."
>>>        >
>>>        >  On 2/21/14, 9:40 AM, Bill Burke wrote:
>>>        >>  Its also "Web" minus some stuff.  For my project I want just
>>>       Servlet,
>>>        >>  JAX-RS, JPA, and datasources.   Its very very hard to figure out
>>>       how to
>>>        >>  remove a subsystem and all its associated modules.
>>>        >>
>>>        >>  BTW, I think my maven artifact thing got into JBoss Modules. So it
>>>        >>  would be possible to load jars on demand, or at least use it as
>>>       a way to
>>>        >>  figure out which modules aren't being used ;).
>>>        >>
>>>        >>
>>>        >>  On 2/21/2014 10:22 AM, Brian Stansberry wrote:
>>>        >>>  This will move things in the right direction, but not all the
>>>       way there
>>>        >>>  yet. Note the set of capabilities Bill mention: web, CDI,
>>>       JAX-RS, JPA.
>>>        >>>  That sounds like our "Web" variant, plus some stuff. It's the
>>>       easy "plus
>>>        >>>  some stuff" part that needs sorting at some point.
>>>        >>>
>>>        >>>  On 2/21/14, 9:08 AM, Toma? Cerar wrote:
>>>        >>>>  Bill,
>>>        >>>>
>>>        >>>>  that is exactly idea we have in mind of 9.
>>>        >>>>  We already started with producing WildFly core distribution in
>>>       that is
>>>        >>>>  WildFly with no subsystems, upon which you can build you own
>>>       wildfly.
>>>        >>>>  It is only 15mb and contains whole mgmt capabilites (CLI,
>>>       standalone,
>>>        >>>>  domain,...) you can grab it at:
>>>        >>>>
>>>       http://download.jboss.org/wildfly/8.0.0.Final/core/wildfly-core-8.0.0.Final.zip
>>>        >>>>
>>>        >>>>  For 9 we have plans to move things bit further and have
>>>       decided that we
>>>        >>>>  will also do split codebase for core, ee, web, .. and other
>>>       distributions.
>>>        >>>>
>>>        >>>>  Current idea on code split up is here
>>>        >>>>  https://community.jboss.org/wiki/SplittingUpTheWildflyCodeBase
>>>        >>>>
>>>        >>>>  --
>>>        >>>>  tomaz
>>>        >>>>
>>>        >>>>
>>>        >>>>
>>>        >>>>  On Fri, Feb 21, 2014 at 3:00 PM, Bill Burke<bburke at redhat.com
>>>       <mailto:bburke at redhat.com>
>>>        >>>>  <mailto:bburke at redhat.com<mailto:bburke at redhat.com>>>  wrote:
>>>        >>>>
>>>        >>>>       On Resteasy list I have a few people "rolling their own
>>>       app server"
>>>        >>>>       using Netty, Weld, Resteasy and JPA.  I asked one of them
>>>       "I don't
>>>        >>>>       understand why you are rolling your own app server" response:
>>>        >>>>
>>>        >>>>       "It's actually a lot more lightweight.  The minimum I can
>>>       run the
>>>        >>>>       equivalent on AS7 on is ~ 180 mb in binaries, but
>>>       throwing this
>>>        >>>>       together is about 32 mb (and compresses further when its
>>>       packaged).
>>>        >>>>       I'm able to start the JVM on the bare minimum (~100mb on
>>>       my linux VM)
>>>        >>>>       but AS7 with all I need is about 756mb.  When rolling out
>>>       in the
>>>        >>>>       cloud, where all of my REST APIs are stateless, running
>>>       with this
>>>        >>>>       configuration helps us get a lot more per node."
>>>        >>>>
>>>        >>>>       I'm not complaining :), just something to think about. It
>>>       might be
>>>        >>>>       really valuable to focus a bit in Wildfly 9 to make it
>>>       easier to create
>>>        >>>>       custom profiles or even different packaging options for
>>>       the app server
>>>        >>>>       instead of the exploded style we currently have.
>>>        >>>>       --
>>>        >>>>       Bill Burke
>>>        >>>>       JBoss, a division of Red Hat
>>>        >>>>  http://bill.burkecentral.com
>>>        >>>>       _______________________________________________
>>>        >>>>       wildfly-dev mailing list
>>>        >>>>  wildfly-dev at lists.jboss.org
>>>       <mailto:wildfly-dev at lists.jboss.org>
>>>       <mailto:wildfly-dev at lists.jboss.org
>>>       <mailto:wildfly-dev at lists.jboss.org>>
>>>        >>>>  https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>        >>>>
>>>        >>>>
>>>        >>>>
>>>        >>>>
>>>        >>>>  _______________________________________________
>>>        >>>>  wildfly-dev mailing list
>>>        >>>>  wildfly-dev at lists.jboss.org<mailto:wildfly-dev at lists.jboss.org>
>>>        >>>>  https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>        >>>>
>>>        >>>
>>>        >>>
>>>        >>
>>>        >
>>>        >
>>>        >  --
>>>        >  Brian Stansberry
>>>        >  Senior Principal Software Engineer
>>>        >  JBoss by Red Hat
>>>        >  _______________________________________________
>>>        >  wildfly-dev mailing list
>>>        >  wildfly-dev at lists.jboss.org<mailto:wildfly-dev at lists.jboss.org>
>>>        >  https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>       Misty Stanley-Jones, RHCE
>>>       Manager, Content Services (Middleware)
>>>       Direct: + 61 7 3514 8105<tel:%2B%2061%207%203514%208105>  / Mobile:
>>>       +61 429 595 932<tel:%2B61%20429%20595%20932>   (TZ: GMT+10)
>>>       IRC: misty (Freenode / RH)
>>>
>>>
>>>       _______________________________________________
>>>       wildfly-dev mailing list
>>>       wildfly-dev at lists.jboss.org<mailto:wildfly-dev at lists.jboss.org>
>>>       https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>

-- 
James R. Perkins
Red Hat JBoss Middleware


From david.lloyd at redhat.com  Tue Mar  4 11:39:55 2014
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Tue, 04 Mar 2014 10:39:55 -0600
Subject: [wildfly-dev] smaller footprints
In-Reply-To: <5315E4AA.1070603@redhat.com>
References: <53075BEA.8030608@redhat.com>	<CAMquZP4RPXFgAPsCnnOLvH=XTkeQJ2bno5ms5yimD3gK6erkbw@mail.gmail.com>	<53076F18.3020603@redhat.com>	<5307737C.2080603@redhat.com>	<53077867.3050600@redhat.com>	<3807F2B2-87E9-43F8-9A5C-E60340C748FF@redhat.com>	<CAAoo=c7rWYObqRGQN2g34PR0bdP6YLeFCaoi3E5f7PuMQkav7Q@mail.gmail.com>	<530B508F.5040409@redhat.com>
	<531574B1.5080404@gmail.com> <5315E4AA.1070603@redhat.com>
Message-ID: <531601DB.5000304@redhat.com>

You might want to look at the work described in 
https://issues.jboss.org/browse/MODULES-146 which essentially would let 
you keep your modules directory completely remote on a server, with 
local caching, if you wanted to.

On 03/04/2014 08:35 AM, Bill Burke wrote:
> Great work Stuart!  I'm really happy somebody is taking initiative on
> this because I really think it will help a lot with Wildfly adoption.
> Is it ready to use?  I'm willing to try it out RIGHT NOW.
>
> I've expressed some of these thoughts months ago when I introduced the
> JBoss Modules artifact features, but here was my vision:
>
> * maven repos would become to Wildfly as /lib /usr/local/lib directory
> structures are to unix.
> * The JBoss Module artifact feature would become the preferred way to
> deploy Wildfly/JBoss.  This would make it really easy to support
> multiple versions as well as different distro's of JBoss/Wildfly on the
> same machine and save huge amounts of disk space.  If we could get a JVM
> that could share JAR instances between processes to save on RAM, the win
> would be even bigger!  Think of the cloud implications!
> * JBoss Module definitions could eventually be defined in one large XML
> file.  We would have maven/ant plugins to help build this large XML file.
> * This single JBoss Module XML file could be bundled within a
> JBoss/Wildfly "executable jar".
> * This "executable jar" could be overlayed with external JBoss Module
> XML files or directory structures.
> * Finally, you could create this "executable jar" for any Java project.
>
>
>
>
> On 3/4/2014 1:37 AM, Stuart Douglas wrote:
>> I have made a start on this split, and I think the solution I am working
>> on will meet all the use cases, including users that want to cut down an
>> existing server, and users that want to re-use the jars in their maven
>> repo using Bill's changes to JBoss Modules. It still needs a bit more
>> work and a lot of cleanup, however it seems to work:
>>
>> https://github.com/stuartwdouglas/wildfly/compare/wildfly-build-plugin
>>
>> So basically the core of it is a maven plugin that builds a Wildfly
>> distribution, either from scratch or use other distributions as a base.
>>
>> It also supports building servers that use the new <artifact>
>> functionality in jboss modules, and cutting down an existing server into
>> a smaller server with only the specified modules (and their transitive
>> dependencies).
>>
>> The way this will work in practice is that each Wildfly sub project will
>> produce two different server artifacts, one of which is a server without
>> any jars using artifact references, and a more traditional version with
>> jars packaged in the module directory. Downstream projects will consume
>> the smaller version without all the jars, so when a version changes the
>> download should be less than 5mb rather than larger than 100mb (the
>> plugin has the ability to turn a server that uses artifact references
>> into a server that contains the jars in the modules dir).
>>
>> Basically the upshot is that it should be basically possible to build
>> whatever configuration of server you want once this is part of our build
>> process, and we should also be publishing lightweight server artifacts
>> that use the jars in the maven repo as well as our traditional
>> 'everything and the kitchen sink' build.
>>
>> It is anticipated that 3rd party projects build on Wildfly would also
>> use this plugin (I think at the moment the standard approach has been to
>> copy and modify our ant scripts).
>>
>> This is still very much a work in progress, so nothing is set in stone
>> yet and any comments are welcome.
>>
>> Stuart
>>
>>
>> Bill Burke wrote:
>>> A lot of users want that ability, would you rather have them roll Netty
>>> + whatever?
>>>
>>> On 2/23/2014 9:10 PM, Stuart Douglas wrote:
>>>> No, because that means we essentially have to support and test every
>>>> possible combination that someone might select.
>>>>
>>>> Stuart
>>>>
>>>>
>>>> On Mon, Feb 24, 2014 at 7:13 AM, Misty Stanley-Jones<misty at redhat.com
>>>> <mailto:misty at redhat.com>>  wrote:
>>>>
>>>>       I know you guys aren?t there yet, but can we think about wrapping a
>>>>       GUI around this, so that the developer only needs to tick the boxes
>>>>       for what he does/doesn?t want, with dependencies sorted out
>>>>       automatically? Maybe some default profiles that select a group of
>>>>       things, but the ability to go in and add or remove individual
>>>>       subsystems as needed? Maybe this could be part of the installer but
>>>>       could optionally be run post-install as well.
>>>>
>>>>       On Feb 22, 2014, at 2:01 AM, Brian Stansberry
>>>>       <brian.stansberry at redhat.com<mailto:brian.stansberry at redhat.com>>
>>>>       wrote:
>>>>
>>>>        >  When I said "Web" I meant the thing described on that wiki
>>>> page Tomaz
>>>>        >  linked:
>>>>        >
>>>>        >  "Web
>>>>        >
>>>>        >  Undertow subsystem, and all related dependencies, including
>>>> a small
>>>>        >  subset of EE and JNDI. This is basically just a Servlet
>>>>       container, and
>>>>        >  will provide a platform for people that want to create web
>>>> based
>>>>        >  appliances or applications, and don't need all the additional
>>>>        >  functionality that Wildfly provides. We should end up with
>>>>       something as
>>>>        >  lightweight as Tomcat or Jetty, but with all our advanced
>>>> management
>>>>        >  functionality."
>>>>        >
>>>>        >  On 2/21/14, 9:40 AM, Bill Burke wrote:
>>>>        >>  Its also "Web" minus some stuff.  For my project I want just
>>>>       Servlet,
>>>>        >>  JAX-RS, JPA, and datasources.   Its very very hard to
>>>> figure out
>>>>       how to
>>>>        >>  remove a subsystem and all its associated modules.
>>>>        >>
>>>>        >>  BTW, I think my maven artifact thing got into JBoss
>>>> Modules. So it
>>>>        >>  would be possible to load jars on demand, or at least use
>>>> it as
>>>>       a way to
>>>>        >>  figure out which modules aren't being used ;).
>>>>        >>
>>>>        >>
>>>>        >>  On 2/21/2014 10:22 AM, Brian Stansberry wrote:
>>>>        >>>  This will move things in the right direction, but not all the
>>>>       way there
>>>>        >>>  yet. Note the set of capabilities Bill mention: web, CDI,
>>>>       JAX-RS, JPA.
>>>>        >>>  That sounds like our "Web" variant, plus some stuff. It's the
>>>>       easy "plus
>>>>        >>>  some stuff" part that needs sorting at some point.
>>>>        >>>
>>>>        >>>  On 2/21/14, 9:08 AM, Toma? Cerar wrote:
>>>>        >>>>  Bill,
>>>>        >>>>
>>>>        >>>>  that is exactly idea we have in mind of 9.
>>>>        >>>>  We already started with producing WildFly core
>>>> distribution in
>>>>       that is
>>>>        >>>>  WildFly with no subsystems, upon which you can build you own
>>>>       wildfly.
>>>>        >>>>  It is only 15mb and contains whole mgmt capabilites (CLI,
>>>>       standalone,
>>>>        >>>>  domain,...) you can grab it at:
>>>>        >>>>
>>>>
>>>> http://download.jboss.org/wildfly/8.0.0.Final/core/wildfly-core-8.0.0.Final.zip
>>>>
>>>>        >>>>
>>>>        >>>>  For 9 we have plans to move things bit further and have
>>>>       decided that we
>>>>        >>>>  will also do split codebase for core, ee, web, .. and other
>>>>       distributions.
>>>>        >>>>
>>>>        >>>>  Current idea on code split up is here
>>>>        >>>>
>>>> https://community.jboss.org/wiki/SplittingUpTheWildflyCodeBase
>>>>        >>>>
>>>>        >>>>  --
>>>>        >>>>  tomaz
>>>>        >>>>
>>>>        >>>>
>>>>        >>>>
>>>>        >>>>  On Fri, Feb 21, 2014 at 3:00 PM, Bill
>>>> Burke<bburke at redhat.com
>>>>       <mailto:bburke at redhat.com>
>>>>        >>>>  <mailto:bburke at redhat.com<mailto:bburke at redhat.com>>>
>>>> wrote:
>>>>        >>>>
>>>>        >>>>       On Resteasy list I have a few people "rolling their own
>>>>       app server"
>>>>        >>>>       using Netty, Weld, Resteasy and JPA.  I asked one of
>>>> them
>>>>       "I don't
>>>>        >>>>       understand why you are rolling your own app server"
>>>> response:
>>>>        >>>>
>>>>        >>>>       "It's actually a lot more lightweight.  The minimum
>>>> I can
>>>>       run the
>>>>        >>>>       equivalent on AS7 on is ~ 180 mb in binaries, but
>>>>       throwing this
>>>>        >>>>       together is about 32 mb (and compresses further when
>>>> its
>>>>       packaged).
>>>>        >>>>       I'm able to start the JVM on the bare minimum
>>>> (~100mb on
>>>>       my linux VM)
>>>>        >>>>       but AS7 with all I need is about 756mb.  When
>>>> rolling out
>>>>       in the
>>>>        >>>>       cloud, where all of my REST APIs are stateless, running
>>>>       with this
>>>>        >>>>       configuration helps us get a lot more per node."
>>>>        >>>>
>>>>        >>>>       I'm not complaining :), just something to think
>>>> about. It
>>>>       might be
>>>>        >>>>       really valuable to focus a bit in Wildfly 9 to make it
>>>>       easier to create
>>>>        >>>>       custom profiles or even different packaging options for
>>>>       the app server
>>>>        >>>>       instead of the exploded style we currently have.
>>>>        >>>>       --
>>>>        >>>>       Bill Burke
>>>>        >>>>       JBoss, a division of Red Hat
>>>>        >>>>  http://bill.burkecentral.com
>>>>        >>>>       _______________________________________________
>>>>        >>>>       wildfly-dev mailing list
>>>>        >>>>  wildfly-dev at lists.jboss.org
>>>>       <mailto:wildfly-dev at lists.jboss.org>
>>>>       <mailto:wildfly-dev at lists.jboss.org
>>>>       <mailto:wildfly-dev at lists.jboss.org>>
>>>>        >>>>  https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>        >>>>
>>>>        >>>>
>>>>        >>>>
>>>>        >>>>
>>>>        >>>>  _______________________________________________
>>>>        >>>>  wildfly-dev mailing list
>>>>        >>>>
>>>> wildfly-dev at lists.jboss.org<mailto:wildfly-dev at lists.jboss.org>
>>>>        >>>>  https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>        >>>>
>>>>        >>>
>>>>        >>>
>>>>        >>
>>>>        >
>>>>        >
>>>>        >  --
>>>>        >  Brian Stansberry
>>>>        >  Senior Principal Software Engineer
>>>>        >  JBoss by Red Hat
>>>>        >  _______________________________________________
>>>>        >  wildfly-dev mailing list
>>>>        >  wildfly-dev at lists.jboss.org<mailto:wildfly-dev at lists.jboss.org>
>>>>        >  https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>>       Misty Stanley-Jones, RHCE
>>>>       Manager, Content Services (Middleware)
>>>>       Direct: + 61 7 3514 8105<tel:%2B%2061%207%203514%208105>  / Mobile:
>>>>       +61 429 595 932<tel:%2B61%20429%20595%20932>   (TZ: GMT+10)
>>>>       IRC: misty (Freenode / RH)
>>>>
>>>>
>>>>       _______________________________________________
>>>>       wildfly-dev mailing list
>>>>       wildfly-dev at lists.jboss.org<mailto:wildfly-dev at lists.jboss.org>
>>>>       https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>
>>
>


-- 
- DML

From david.lloyd at redhat.com  Tue Mar  4 11:46:01 2014
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Tue, 04 Mar 2014 10:46:01 -0600
Subject: [wildfly-dev] smaller footprints
In-Reply-To: <5315FF13.3090204@redhat.com>
References: <53075BEA.8030608@redhat.com>	<CAMquZP4RPXFgAPsCnnOLvH=XTkeQJ2bno5ms5yimD3gK6erkbw@mail.gmail.com>	<53076F18.3020603@redhat.com>	<5307737C.2080603@redhat.com>	<53077867.3050600@redhat.com>	<3807F2B2-87E9-43F8-9A5C-E60340C748FF@redhat.com>	<CAAoo=c7rWYObqRGQN2g34PR0bdP6YLeFCaoi3E5f7PuMQkav7Q@mail.gmail.com>	<530B508F.5040409@redhat.com>	<531574B1.5080404@gmail.com>
	<5315FF13.3090204@redhat.com>
Message-ID: <53160349.8030109@redhat.com>

As long as we don't break deployments which use the container 
dependencies, anything is fine.

On 03/04/2014 10:28 AM, James R. Perkins wrote:
> Since the logging subsystem is in the core distro, I'm wondering if the
> default DUP's to add logging dependencies and search for logging
> configuration files in deployments should be disabled. There are
> attributes to disable these now which are should remain enabled in
> WildFly, but it seems the opposite might be preferable in a core-distro.
> I've not really thought about how to do that or looked over Stuarts
> branch with great detail, but just kind of throwing it out there to get
> opinions on it.
>
> On 03/03/2014 10:37 PM, Stuart Douglas wrote:
>> I have made a start on this split, and I think the solution I am working
>> on will meet all the use cases, including users that want to cut down an
>> existing server, and users that want to re-use the jars in their maven
>> repo using Bill's changes to JBoss Modules. It still needs a bit more
>> work and a lot of cleanup, however it seems to work:
>>
>> https://github.com/stuartwdouglas/wildfly/compare/wildfly-build-plugin
>>
>> So basically the core of it is a maven plugin that builds a Wildfly
>> distribution, either from scratch or use other distributions as a base.
>>
>> It also supports building servers that use the new <artifact>
>> functionality in jboss modules, and cutting down an existing server into
>> a smaller server with only the specified modules (and their transitive
>> dependencies).
>>
>> The way this will work in practice is that each Wildfly sub project will
>> produce two different server artifacts, one of which is a server without
>> any jars using artifact references, and a more traditional version with
>> jars packaged in the module directory. Downstream projects will consume
>> the smaller version without all the jars, so when a version changes the
>> download should be less than 5mb rather than larger than 100mb (the
>> plugin has the ability to turn a server that uses artifact references
>> into a server that contains the jars in the modules dir).
>>
>> Basically the upshot is that it should be basically possible to build
>> whatever configuration of server you want once this is part of our build
>> process, and we should also be publishing lightweight server artifacts
>> that use the jars in the maven repo as well as our traditional
>> 'everything and the kitchen sink' build.
>>
>> It is anticipated that 3rd party projects build on Wildfly would also
>> use this plugin (I think at the moment the standard approach has been to
>> copy and modify our ant scripts).
>>
>> This is still very much a work in progress, so nothing is set in stone
>> yet and any comments are welcome.
>>
>> Stuart
>>
>>
>> Bill Burke wrote:
>>> A lot of users want that ability, would you rather have them roll Netty
>>> + whatever?
>>>
>>> On 2/23/2014 9:10 PM, Stuart Douglas wrote:
>>>> No, because that means we essentially have to support and test every
>>>> possible combination that someone might select.
>>>>
>>>> Stuart
>>>>
>>>>
>>>> On Mon, Feb 24, 2014 at 7:13 AM, Misty Stanley-Jones<misty at redhat.com
>>>> <mailto:misty at redhat.com>>  wrote:
>>>>
>>>>        I know you guys aren?t there yet, but can we think about wrapping a
>>>>        GUI around this, so that the developer only needs to tick the boxes
>>>>        for what he does/doesn?t want, with dependencies sorted out
>>>>        automatically? Maybe some default profiles that select a group of
>>>>        things, but the ability to go in and add or remove individual
>>>>        subsystems as needed? Maybe this could be part of the installer but
>>>>        could optionally be run post-install as well.
>>>>
>>>>        On Feb 22, 2014, at 2:01 AM, Brian Stansberry
>>>>        <brian.stansberry at redhat.com<mailto:brian.stansberry at redhat.com>>
>>>>        wrote:
>>>>
>>>>         >  When I said "Web" I meant the thing described on that wiki page Tomaz
>>>>         >  linked:
>>>>         >
>>>>         >  "Web
>>>>         >
>>>>         >  Undertow subsystem, and all related dependencies, including a small
>>>>         >  subset of EE and JNDI. This is basically just a Servlet
>>>>        container, and
>>>>         >  will provide a platform for people that want to create web based
>>>>         >  appliances or applications, and don't need all the additional
>>>>         >  functionality that Wildfly provides. We should end up with
>>>>        something as
>>>>         >  lightweight as Tomcat or Jetty, but with all our advanced management
>>>>         >  functionality."
>>>>         >
>>>>         >  On 2/21/14, 9:40 AM, Bill Burke wrote:
>>>>         >>  Its also "Web" minus some stuff.  For my project I want just
>>>>        Servlet,
>>>>         >>  JAX-RS, JPA, and datasources.   Its very very hard to figure out
>>>>        how to
>>>>         >>  remove a subsystem and all its associated modules.
>>>>         >>
>>>>         >>  BTW, I think my maven artifact thing got into JBoss Modules. So it
>>>>         >>  would be possible to load jars on demand, or at least use it as
>>>>        a way to
>>>>         >>  figure out which modules aren't being used ;).
>>>>         >>
>>>>         >>
>>>>         >>  On 2/21/2014 10:22 AM, Brian Stansberry wrote:
>>>>         >>>  This will move things in the right direction, but not all the
>>>>        way there
>>>>         >>>  yet. Note the set of capabilities Bill mention: web, CDI,
>>>>        JAX-RS, JPA.
>>>>         >>>  That sounds like our "Web" variant, plus some stuff. It's the
>>>>        easy "plus
>>>>         >>>  some stuff" part that needs sorting at some point.
>>>>         >>>
>>>>         >>>  On 2/21/14, 9:08 AM, Toma? Cerar wrote:
>>>>         >>>>  Bill,
>>>>         >>>>
>>>>         >>>>  that is exactly idea we have in mind of 9.
>>>>         >>>>  We already started with producing WildFly core distribution in
>>>>        that is
>>>>         >>>>  WildFly with no subsystems, upon which you can build you own
>>>>        wildfly.
>>>>         >>>>  It is only 15mb and contains whole mgmt capabilites (CLI,
>>>>        standalone,
>>>>         >>>>  domain,...) you can grab it at:
>>>>         >>>>
>>>>        http://download.jboss.org/wildfly/8.0.0.Final/core/wildfly-core-8.0.0.Final.zip
>>>>         >>>>
>>>>         >>>>  For 9 we have plans to move things bit further and have
>>>>        decided that we
>>>>         >>>>  will also do split codebase for core, ee, web, .. and other
>>>>        distributions.
>>>>         >>>>
>>>>         >>>>  Current idea on code split up is here
>>>>         >>>>  https://community.jboss.org/wiki/SplittingUpTheWildflyCodeBase
>>>>         >>>>
>>>>         >>>>  --
>>>>         >>>>  tomaz
>>>>         >>>>
>>>>         >>>>
>>>>         >>>>
>>>>         >>>>  On Fri, Feb 21, 2014 at 3:00 PM, Bill Burke<bburke at redhat.com
>>>>        <mailto:bburke at redhat.com>
>>>>         >>>>  <mailto:bburke at redhat.com<mailto:bburke at redhat.com>>>  wrote:
>>>>         >>>>
>>>>         >>>>       On Resteasy list I have a few people "rolling their own
>>>>        app server"
>>>>         >>>>       using Netty, Weld, Resteasy and JPA.  I asked one of them
>>>>        "I don't
>>>>         >>>>       understand why you are rolling your own app server" response:
>>>>         >>>>
>>>>         >>>>       "It's actually a lot more lightweight.  The minimum I can
>>>>        run the
>>>>         >>>>       equivalent on AS7 on is ~ 180 mb in binaries, but
>>>>        throwing this
>>>>         >>>>       together is about 32 mb (and compresses further when its
>>>>        packaged).
>>>>         >>>>       I'm able to start the JVM on the bare minimum (~100mb on
>>>>        my linux VM)
>>>>         >>>>       but AS7 with all I need is about 756mb.  When rolling out
>>>>        in the
>>>>         >>>>       cloud, where all of my REST APIs are stateless, running
>>>>        with this
>>>>         >>>>       configuration helps us get a lot more per node."
>>>>         >>>>
>>>>         >>>>       I'm not complaining :), just something to think about. It
>>>>        might be
>>>>         >>>>       really valuable to focus a bit in Wildfly 9 to make it
>>>>        easier to create
>>>>         >>>>       custom profiles or even different packaging options for
>>>>        the app server
>>>>         >>>>       instead of the exploded style we currently have.
>>>>         >>>>       --
>>>>         >>>>       Bill Burke
>>>>         >>>>       JBoss, a division of Red Hat
>>>>         >>>>  http://bill.burkecentral.com
>>>>         >>>>       _______________________________________________
>>>>         >>>>       wildfly-dev mailing list
>>>>         >>>>  wildfly-dev at lists.jboss.org
>>>>        <mailto:wildfly-dev at lists.jboss.org>
>>>>        <mailto:wildfly-dev at lists.jboss.org
>>>>        <mailto:wildfly-dev at lists.jboss.org>>
>>>>         >>>>  https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>         >>>>
>>>>         >>>>
>>>>         >>>>
>>>>         >>>>
>>>>         >>>>  _______________________________________________
>>>>         >>>>  wildfly-dev mailing list
>>>>         >>>>  wildfly-dev at lists.jboss.org<mailto:wildfly-dev at lists.jboss.org>
>>>>         >>>>  https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>         >>>>
>>>>         >>>
>>>>         >>>
>>>>         >>
>>>>         >
>>>>         >
>>>>         >  --
>>>>         >  Brian Stansberry
>>>>         >  Senior Principal Software Engineer
>>>>         >  JBoss by Red Hat
>>>>         >  _______________________________________________
>>>>         >  wildfly-dev mailing list
>>>>         >  wildfly-dev at lists.jboss.org<mailto:wildfly-dev at lists.jboss.org>
>>>>         >  https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>>        Misty Stanley-Jones, RHCE
>>>>        Manager, Content Services (Middleware)
>>>>        Direct: + 61 7 3514 8105<tel:%2B%2061%207%203514%208105>  / Mobile:
>>>>        +61 429 595 932<tel:%2B61%20429%20595%20932>   (TZ: GMT+10)
>>>>        IRC: misty (Freenode / RH)
>>>>
>>>>
>>>>        _______________________________________________
>>>>        wildfly-dev mailing list
>>>>        wildfly-dev at lists.jboss.org<mailto:wildfly-dev at lists.jboss.org>
>>>>        https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>


-- 
- DML

From bburke at redhat.com  Tue Mar  4 12:05:28 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 04 Mar 2014 12:05:28 -0500
Subject: [wildfly-dev] smaller footprints
In-Reply-To: <531601DB.5000304@redhat.com>
References: <53075BEA.8030608@redhat.com>	<CAMquZP4RPXFgAPsCnnOLvH=XTkeQJ2bno5ms5yimD3gK6erkbw@mail.gmail.com>	<53076F18.3020603@redhat.com>	<5307737C.2080603@redhat.com>	<53077867.3050600@redhat.com>	<3807F2B2-87E9-43F8-9A5C-E60340C748FF@redhat.com>	<CAAoo=c7rWYObqRGQN2g34PR0bdP6YLeFCaoi3E5f7PuMQkav7Q@mail.gmail.com>	<530B508F.5040409@redhat.com>	<531574B1.5080404@gmail.com>
	<5315E4AA.1070603@redhat.com> <531601DB.5000304@redhat.com>
Message-ID: <531607D8.4000400@redhat.com>



On 3/4/2014 11:39 AM, David M. Lloyd wrote:
> You might want to look at the work described in
> https://issues.jboss.org/browse/MODULES-146 which essentially would let
> you keep your modules directory completely remote on a server, with
> local caching, if you wanted to.
>

For distributing jars, I like the artifact approach better as you don't 
have to maintain two types of repos.  You can use a maven repo for both 
building apps and running Wildfly.  I can't remember exactly, but the 
full size of all module.xml files in a Wildfly distro was 200-800k after 
you strip out all the comments.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From brian.stansberry at redhat.com  Tue Mar  4 12:27:43 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 04 Mar 2014 11:27:43 -0600
Subject: [wildfly-dev] smaller footprints
In-Reply-To: <53160349.8030109@redhat.com>
References: <53075BEA.8030608@redhat.com>	<CAMquZP4RPXFgAPsCnnOLvH=XTkeQJ2bno5ms5yimD3gK6erkbw@mail.gmail.com>	<53076F18.3020603@redhat.com>	<5307737C.2080603@redhat.com>	<53077867.3050600@redhat.com>	<3807F2B2-87E9-43F8-9A5C-E60340C748FF@redhat.com>	<CAAoo=c7rWYObqRGQN2g34PR0bdP6YLeFCaoi3E5f7PuMQkav7Q@mail.gmail.com>	<530B508F.5040409@redhat.com>	<531574B1.5080404@gmail.com>	<5315FF13.3090204@redhat.com>
	<53160349.8030109@redhat.com>
Message-ID: <53160D0F.6000301@redhat.com>

It's an interesting question how a particular child server build will be 
able to override a standard config snippet from a depended upon server 
build. I know Stuart was thinking about that a bit. It's been at least 
28 hours so I'm sure he has it sorted. ;)

On 3/4/14, 10:46 AM, David M. Lloyd wrote:
> As long as we don't break deployments which use the container
> dependencies, anything is fine.
>
> On 03/04/2014 10:28 AM, James R. Perkins wrote:
>> Since the logging subsystem is in the core distro, I'm wondering if the
>> default DUP's to add logging dependencies and search for logging
>> configuration files in deployments should be disabled. There are
>> attributes to disable these now which are should remain enabled in
>> WildFly, but it seems the opposite might be preferable in a core-distro.
>> I've not really thought about how to do that or looked over Stuarts
>> branch with great detail, but just kind of throwing it out there to get
>> opinions on it.
>>
>> On 03/03/2014 10:37 PM, Stuart Douglas wrote:
>>> I have made a start on this split, and I think the solution I am working
>>> on will meet all the use cases, including users that want to cut down an
>>> existing server, and users that want to re-use the jars in their maven
>>> repo using Bill's changes to JBoss Modules. It still needs a bit more
>>> work and a lot of cleanup, however it seems to work:
>>>
>>> https://github.com/stuartwdouglas/wildfly/compare/wildfly-build-plugin
>>>
>>> So basically the core of it is a maven plugin that builds a Wildfly
>>> distribution, either from scratch or use other distributions as a base.
>>>
>>> It also supports building servers that use the new <artifact>
>>> functionality in jboss modules, and cutting down an existing server into
>>> a smaller server with only the specified modules (and their transitive
>>> dependencies).
>>>
>>> The way this will work in practice is that each Wildfly sub project will
>>> produce two different server artifacts, one of which is a server without
>>> any jars using artifact references, and a more traditional version with
>>> jars packaged in the module directory. Downstream projects will consume
>>> the smaller version without all the jars, so when a version changes the
>>> download should be less than 5mb rather than larger than 100mb (the
>>> plugin has the ability to turn a server that uses artifact references
>>> into a server that contains the jars in the modules dir).
>>>
>>> Basically the upshot is that it should be basically possible to build
>>> whatever configuration of server you want once this is part of our build
>>> process, and we should also be publishing lightweight server artifacts
>>> that use the jars in the maven repo as well as our traditional
>>> 'everything and the kitchen sink' build.
>>>
>>> It is anticipated that 3rd party projects build on Wildfly would also
>>> use this plugin (I think at the moment the standard approach has been to
>>> copy and modify our ant scripts).
>>>
>>> This is still very much a work in progress, so nothing is set in stone
>>> yet and any comments are welcome.
>>>
>>> Stuart
>>>
>>>
>>> Bill Burke wrote:
>>>> A lot of users want that ability, would you rather have them roll Netty
>>>> + whatever?
>>>>
>>>> On 2/23/2014 9:10 PM, Stuart Douglas wrote:
>>>>> No, because that means we essentially have to support and test every
>>>>> possible combination that someone might select.
>>>>>
>>>>> Stuart
>>>>>
>>>>>
>>>>> On Mon, Feb 24, 2014 at 7:13 AM, Misty Stanley-Jones<misty at redhat.com
>>>>> <mailto:misty at redhat.com>>  wrote:
>>>>>
>>>>>         I know you guys aren?t there yet, but can we think about wrapping a
>>>>>         GUI around this, so that the developer only needs to tick the boxes
>>>>>         for what he does/doesn?t want, with dependencies sorted out
>>>>>         automatically? Maybe some default profiles that select a group of
>>>>>         things, but the ability to go in and add or remove individual
>>>>>         subsystems as needed? Maybe this could be part of the installer but
>>>>>         could optionally be run post-install as well.
>>>>>
>>>>>         On Feb 22, 2014, at 2:01 AM, Brian Stansberry
>>>>>         <brian.stansberry at redhat.com<mailto:brian.stansberry at redhat.com>>
>>>>>         wrote:
>>>>>
>>>>>          >  When I said "Web" I meant the thing described on that wiki page Tomaz
>>>>>          >  linked:
>>>>>          >
>>>>>          >  "Web
>>>>>          >
>>>>>          >  Undertow subsystem, and all related dependencies, including a small
>>>>>          >  subset of EE and JNDI. This is basically just a Servlet
>>>>>         container, and
>>>>>          >  will provide a platform for people that want to create web based
>>>>>          >  appliances or applications, and don't need all the additional
>>>>>          >  functionality that Wildfly provides. We should end up with
>>>>>         something as
>>>>>          >  lightweight as Tomcat or Jetty, but with all our advanced management
>>>>>          >  functionality."
>>>>>          >
>>>>>          >  On 2/21/14, 9:40 AM, Bill Burke wrote:
>>>>>          >>  Its also "Web" minus some stuff.  For my project I want just
>>>>>         Servlet,
>>>>>          >>  JAX-RS, JPA, and datasources.   Its very very hard to figure out
>>>>>         how to
>>>>>          >>  remove a subsystem and all its associated modules.
>>>>>          >>
>>>>>          >>  BTW, I think my maven artifact thing got into JBoss Modules. So it
>>>>>          >>  would be possible to load jars on demand, or at least use it as
>>>>>         a way to
>>>>>          >>  figure out which modules aren't being used ;).
>>>>>          >>
>>>>>          >>
>>>>>          >>  On 2/21/2014 10:22 AM, Brian Stansberry wrote:
>>>>>          >>>  This will move things in the right direction, but not all the
>>>>>         way there
>>>>>          >>>  yet. Note the set of capabilities Bill mention: web, CDI,
>>>>>         JAX-RS, JPA.
>>>>>          >>>  That sounds like our "Web" variant, plus some stuff. It's the
>>>>>         easy "plus
>>>>>          >>>  some stuff" part that needs sorting at some point.
>>>>>          >>>
>>>>>          >>>  On 2/21/14, 9:08 AM, Toma? Cerar wrote:
>>>>>          >>>>  Bill,
>>>>>          >>>>
>>>>>          >>>>  that is exactly idea we have in mind of 9.
>>>>>          >>>>  We already started with producing WildFly core distribution in
>>>>>         that is
>>>>>          >>>>  WildFly with no subsystems, upon which you can build you own
>>>>>         wildfly.
>>>>>          >>>>  It is only 15mb and contains whole mgmt capabilites (CLI,
>>>>>         standalone,
>>>>>          >>>>  domain,...) you can grab it at:
>>>>>          >>>>
>>>>>         http://download.jboss.org/wildfly/8.0.0.Final/core/wildfly-core-8.0.0.Final.zip
>>>>>          >>>>
>>>>>          >>>>  For 9 we have plans to move things bit further and have
>>>>>         decided that we
>>>>>          >>>>  will also do split codebase for core, ee, web, .. and other
>>>>>         distributions.
>>>>>          >>>>
>>>>>          >>>>  Current idea on code split up is here
>>>>>          >>>>  https://community.jboss.org/wiki/SplittingUpTheWildflyCodeBase
>>>>>          >>>>
>>>>>          >>>>  --
>>>>>          >>>>  tomaz
>>>>>          >>>>
>>>>>          >>>>
>>>>>          >>>>
>>>>>          >>>>  On Fri, Feb 21, 2014 at 3:00 PM, Bill Burke<bburke at redhat.com
>>>>>         <mailto:bburke at redhat.com>
>>>>>          >>>>  <mailto:bburke at redhat.com<mailto:bburke at redhat.com>>>  wrote:
>>>>>          >>>>
>>>>>          >>>>       On Resteasy list I have a few people "rolling their own
>>>>>         app server"
>>>>>          >>>>       using Netty, Weld, Resteasy and JPA.  I asked one of them
>>>>>         "I don't
>>>>>          >>>>       understand why you are rolling your own app server" response:
>>>>>          >>>>
>>>>>          >>>>       "It's actually a lot more lightweight.  The minimum I can
>>>>>         run the
>>>>>          >>>>       equivalent on AS7 on is ~ 180 mb in binaries, but
>>>>>         throwing this
>>>>>          >>>>       together is about 32 mb (and compresses further when its
>>>>>         packaged).
>>>>>          >>>>       I'm able to start the JVM on the bare minimum (~100mb on
>>>>>         my linux VM)
>>>>>          >>>>       but AS7 with all I need is about 756mb.  When rolling out
>>>>>         in the
>>>>>          >>>>       cloud, where all of my REST APIs are stateless, running
>>>>>         with this
>>>>>          >>>>       configuration helps us get a lot more per node."
>>>>>          >>>>
>>>>>          >>>>       I'm not complaining :), just something to think about. It
>>>>>         might be
>>>>>          >>>>       really valuable to focus a bit in Wildfly 9 to make it
>>>>>         easier to create
>>>>>          >>>>       custom profiles or even different packaging options for
>>>>>         the app server
>>>>>          >>>>       instead of the exploded style we currently have.
>>>>>          >>>>       --
>>>>>          >>>>       Bill Burke
>>>>>          >>>>       JBoss, a division of Red Hat
>>>>>          >>>>  http://bill.burkecentral.com
>>>>>          >>>>       _______________________________________________
>>>>>          >>>>       wildfly-dev mailing list
>>>>>          >>>>  wildfly-dev at lists.jboss.org
>>>>>         <mailto:wildfly-dev at lists.jboss.org>
>>>>>         <mailto:wildfly-dev at lists.jboss.org
>>>>>         <mailto:wildfly-dev at lists.jboss.org>>
>>>>>          >>>>  https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>          >>>>
>>>>>          >>>>
>>>>>          >>>>
>>>>>          >>>>
>>>>>          >>>>  _______________________________________________
>>>>>          >>>>  wildfly-dev mailing list
>>>>>          >>>>  wildfly-dev at lists.jboss.org<mailto:wildfly-dev at lists.jboss.org>
>>>>>          >>>>  https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>          >>>>
>>>>>          >>>
>>>>>          >>>
>>>>>          >>
>>>>>          >
>>>>>          >
>>>>>          >  --
>>>>>          >  Brian Stansberry
>>>>>          >  Senior Principal Software Engineer
>>>>>          >  JBoss by Red Hat
>>>>>          >  _______________________________________________
>>>>>          >  wildfly-dev mailing list
>>>>>          >  wildfly-dev at lists.jboss.org<mailto:wildfly-dev at lists.jboss.org>
>>>>>          >  https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>>         Misty Stanley-Jones, RHCE
>>>>>         Manager, Content Services (Middleware)
>>>>>         Direct: + 61 7 3514 8105<tel:%2B%2061%207%203514%208105>  / Mobile:
>>>>>         +61 429 595 932<tel:%2B61%20429%20595%20932>   (TZ: GMT+10)
>>>>>         IRC: misty (Freenode / RH)
>>>>>
>>>>>
>>>>>         _______________________________________________
>>>>>         wildfly-dev mailing list
>>>>>         wildfly-dev at lists.jboss.org<mailto:wildfly-dev at lists.jboss.org>
>>>>>         https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>
>
>


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

From david.lloyd at redhat.com  Tue Mar  4 12:56:43 2014
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Tue, 04 Mar 2014 11:56:43 -0600
Subject: [wildfly-dev] smaller footprints
In-Reply-To: <531607D8.4000400@redhat.com>
References: <53075BEA.8030608@redhat.com>	<CAMquZP4RPXFgAPsCnnOLvH=XTkeQJ2bno5ms5yimD3gK6erkbw@mail.gmail.com>	<53076F18.3020603@redhat.com>	<5307737C.2080603@redhat.com>	<53077867.3050600@redhat.com>	<3807F2B2-87E9-43F8-9A5C-E60340C748FF@redhat.com>	<CAAoo=c7rWYObqRGQN2g34PR0bdP6YLeFCaoi3E5f7PuMQkav7Q@mail.gmail.com>	<530B508F.5040409@redhat.com>	<531574B1.5080404@gmail.com>	<5315E4AA.1070603@redhat.com>
	<531601DB.5000304@redhat.com> <531607D8.4000400@redhat.com>
Message-ID: <531613DB.40902@redhat.com>

On 03/04/2014 11:05 AM, Bill Burke wrote:
>
>
> On 3/4/2014 11:39 AM, David M. Lloyd wrote:
>> You might want to look at the work described in
>> https://issues.jboss.org/browse/MODULES-146 which essentially would let
>> you keep your modules directory completely remote on a server, with
>> local caching, if you wanted to.
>>
>
> For distributing jars, I like the artifact approach better as you don't
> have to maintain two types of repos.  You can use a maven repo for both
> building apps and running Wildfly.  I can't remember exactly, but the
> full size of all module.xml files in a Wildfly distro was 200-800k after
> you strip out all the comments.

It is possible that you misunderstood me.  It's not necessarily 
one-or-the-other; you could have the remote repository hold the module 
descriptors which are downloaded on demand.  That will save you even 
more space and you don't even have to strip out comments.

Other thoughts however will come on another branch.
-- 
- DML

From david.lloyd at redhat.com  Tue Mar  4 13:22:44 2014
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Tue, 04 Mar 2014 12:22:44 -0600
Subject: [wildfly-dev] smaller footprints
In-Reply-To: <5315E4AA.1070603@redhat.com>
References: <53075BEA.8030608@redhat.com>	<CAMquZP4RPXFgAPsCnnOLvH=XTkeQJ2bno5ms5yimD3gK6erkbw@mail.gmail.com>	<53076F18.3020603@redhat.com>	<5307737C.2080603@redhat.com>	<53077867.3050600@redhat.com>	<3807F2B2-87E9-43F8-9A5C-E60340C748FF@redhat.com>	<CAAoo=c7rWYObqRGQN2g34PR0bdP6YLeFCaoi3E5f7PuMQkav7Q@mail.gmail.com>	<530B508F.5040409@redhat.com>
	<531574B1.5080404@gmail.com> <5315E4AA.1070603@redhat.com>
Message-ID: <531619F4.7040009@redhat.com>

On 03/04/2014 08:35 AM, Bill Burke wrote:
> Great work Stuart!  I'm really happy somebody is taking initiative on
> this because I really think it will help a lot with Wildfly adoption.
> Is it ready to use?  I'm willing to try it out RIGHT NOW.
>
> I've expressed some of these thoughts months ago when I introduced the
> JBoss Modules artifact features, but here was my vision:
>
> * maven repos would become to Wildfly as /lib /usr/local/lib directory
> structures are to unix.

I'm not sure how tightly you're gripping to this metaphor, but it can 
not be exactly this because the maven dependencies do not semantically 
have the right dependency information to function 100% correctly at run 
time, which is the point of JBoss Modules and its dependency 
infrastructure in the first place.

> * The JBoss Module artifact feature would become the preferred way to
> deploy Wildfly/JBoss.  This would make it really easy to support
> multiple versions as well as different distro's of JBoss/Wildfly on the
> same machine and save huge amounts of disk space.  If we could get a JVM
> that could share JAR instances between processes to save on RAM, the win
> would be even bigger!  Think of the cloud implications!

Deploy, maybe in certain cases, but I don't think that using Maven repos 
is going to be preferred in the data center case or even the cloud case. 
  In both cases, in any non-trivially sized environment, the systems are 
generally going to be either built up by packages long before deployment 
time, simply replicated in whole off an image, or built up by high-level 
tooling in such a way that it doesn't really pay to "buy in" to the 
Maven repository format, which would be more useful perhaps during 
development.  In many cases, the public Internet isn't even accessible 
and a local image is necessary.  I think the usefulness of Maven is 
heavily, heavily overstated here.

> * JBoss Module definitions could eventually be defined in one large XML
> file.  We would have maven/ant plugins to help build this large XML file.

This would be a step backwards, especially if we ever want to support 
third-party add-ins in a uniform manner.

> * This single JBoss Module XML file could be bundled within a
> JBoss/Wildfly "executable jar".
> * This "executable jar" could be overlayed with external JBoss Module
> XML files or directory structures.
> * Finally, you could create this "executable jar" for any Java project.

I guess you're looking at it from the perspective of "every Java 
application is a monolithic thing" instead of "I have an installation 
which has N applications in it", which is more what my world view is.

And I have in the past, and continue to believe that build and run time 
are very distinct.  At build time, you have a giant, single universe of 
artifacts which include versioned dependency information which is used 
for build repeatability purposes.  At run time, you have one or more 
"environments" of selected artifacts which include versionless 
dependency information, that are tested together and certified, which 
can be (theoretically anyway) updated, installed, and removed 
individually without rebuild (only a one-time, centralized retest in the 
updates case).  This is actually much closer to both the Jigsaw/MR ethos 
as well as the way that UNIX-ish /lib works today, and I think is more 
in line with what we want to have in the 5+ year time frame (if we 
cannot manage it sooner than that).

-- 
- DML

From bburke at redhat.com  Tue Mar  4 15:16:21 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 04 Mar 2014 15:16:21 -0500
Subject: [wildfly-dev] smaller footprints
In-Reply-To: <531619F4.7040009@redhat.com>
References: <53075BEA.8030608@redhat.com>	<CAMquZP4RPXFgAPsCnnOLvH=XTkeQJ2bno5ms5yimD3gK6erkbw@mail.gmail.com>	<53076F18.3020603@redhat.com>	<5307737C.2080603@redhat.com>	<53077867.3050600@redhat.com>	<3807F2B2-87E9-43F8-9A5C-E60340C748FF@redhat.com>	<CAAoo=c7rWYObqRGQN2g34PR0bdP6YLeFCaoi3E5f7PuMQkav7Q@mail.gmail.com>	<530B508F.5040409@redhat.com>	<531574B1.5080404@gmail.com>
	<5315E4AA.1070603@redhat.com> <531619F4.7040009@redhat.com>
Message-ID: <53163495.6040706@redhat.com>



On 3/4/2014 1:22 PM, David M. Lloyd wrote:
> On 03/04/2014 08:35 AM, Bill Burke wrote:
>> Great work Stuart!  I'm really happy somebody is taking initiative on
>> this because I really think it will help a lot with Wildfly adoption.
>> Is it ready to use?  I'm willing to try it out RIGHT NOW.
>>
>> I've expressed some of these thoughts months ago when I introduced the
>> JBoss Modules artifact features, but here was my vision:
>>
>> * maven repos would become to Wildfly as /lib /usr/local/lib directory
>> structures are to unix.
>
> I'm not sure how tightly you're gripping to this metaphor, but it can
> not be exactly this because the maven dependencies do not semantically
> have the right dependency information to function 100% correctly at run
> time, which is the point of JBoss Modules and its dependency
> infrastructure in the first place.
>

I'm talking about the maven repo directory structure, not the poms! 
Being able to resolve an artifact given a base URL, artifact name, and 
version is pretty damn powerful.  Trivial, but powerful.

JBoss Modules + Maven Repo = "something better"

>> * The JBoss Module artifact feature would become the preferred way to
>> deploy Wildfly/JBoss.  This would make it really easy to support
>> multiple versions as well as different distro's of JBoss/Wildfly on the
>> same machine and save huge amounts of disk space.  If we could get a JVM
>> that could share JAR instances between processes to save on RAM, the win
>> would be even bigger!  Think of the cloud implications!
>
> Deploy, maybe in certain cases, but I don't think that using Maven repos
> is going to be preferred in the data center case or even the cloud case.
>    In both cases, in any non-trivially sized environment, the systems are
> generally going to be either built up by packages long before deployment
> time, simply replicated in whole off an image, or built up by high-level
> tooling in such a way that it doesn't really pay to "buy in" to the
> Maven repository format, which would be more useful perhaps during
> development.  In many cases, the public Internet isn't even accessible
> and a local image is necessary.  I think the usefulness of Maven is
> heavily, heavily overstated here.
>

I wasn't talking about using a *remote* maven repo to share disk space. 
  I was talking about a local repo.  You would install Wildfly jar 
dependencies into the OS image's local maven directory.  Then, different 
OS VMs could share the same disk space.


>> * JBoss Module definitions could eventually be defined in one large XML
>> file.  We would have maven/ant plugins to help build this large XML file.
>
> This would be a step backwards, especially if we ever want to support
> third-party add-ins in a uniform manner.
>
>> * This single JBoss Module XML file could be bundled within a
>> JBoss/Wildfly "executable jar".
>> * This "executable jar" could be overlayed with external JBoss Module
>> XML files or directory structures.
>> * Finally, you could create this "executable jar" for any Java project.
>
> I guess you're looking at it from the perspective of "every Java
> application is a monolithic thing" instead of "I have an installation
> which has N applications in it", which is more what my world view is.
>

I wasn't advocating one approach over another.  I'd like to be able to 
do both.  While we already have a platform that can have "N applications 
in it", we don't have a great way to bundle a "monolithic thing".  The 
ironic thing is that the users I've talked to who want the ability to 
create a "monolithic thing" are talking about applications that are at 
least 100+ meg smaller than the current Wildfly distro. :)

If Wildfly and other non-Wildfly apps used a local maven repo (or remote 
one I guess), you'd have a common cross-environment way of sharing 
dependencies on the same machine.  I'm talking more of using JBoss 
Modules as a way to create an "exeutable" for non-Wildfly applications.

> And I have in the past, and continue to believe that build and run time
> are very distinct.

And I don't think they need to be completely distinct and separate. 
Maven repo for building.  JBoss modules to bridge between the 
"versionless runtime" and the repo, to provide a logical unversioned 
view/grouping of dependencies.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stuart.w.douglas at gmail.com  Tue Mar  4 16:16:07 2014
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Wed, 05 Mar 2014 08:16:07 +1100
Subject: [wildfly-dev] smaller footprints
In-Reply-To: <5315E4AA.1070603@redhat.com>
References: <53075BEA.8030608@redhat.com>	<CAMquZP4RPXFgAPsCnnOLvH=XTkeQJ2bno5ms5yimD3gK6erkbw@mail.gmail.com>	<53076F18.3020603@redhat.com>
	<5307737C.2080603@redhat.com>	<53077867.3050600@redhat.com>	<3807F2B2-87E9-43F8-9A5C-E60340C748FF@redhat.com>
	<CAAoo=c7rWYObqRGQN2g34PR0bdP6YLeFCaoi3E5f7PuMQkav7Q@mail.gmail.com>
	<530B508F.5040409@redhat.com> <531574B1.5080404@gmail.com>
	<5315E4AA.1070603@redhat.com>
Message-ID: <53164297.8020405@gmail.com>



Bill Burke wrote:
> Great work Stuart! I'm really happy somebody is taking initiative on
> this because I really think it will help a lot with Wildfly adoption. Is
> it ready to use? I'm willing to try it out RIGHT NOW.

Sort of. You can build from my wildfly-build-plugin branch and it should 
work, but at the moment it is creating a build that includes all the 
jars. If you want to create a build that uses <artifact> you will need 
to modify the copy-module-artifacts attribute in ./build/server-build.xml .

Eventually we will produce both versions, I should get to this some time 
today.

Also this is very new, and may not work, but if you want to try it out 
feel free. Hopefully I will have something a lot more polished by the 
end of the week.

>
> I've expressed some of these thoughts months ago when I introduced the
> JBoss Modules artifact features, but here was my vision:
>
> * maven repos would become to Wildfly as /lib /usr/local/lib directory
> structures are to unix.
> * The JBoss Module artifact feature would become the preferred way to
> deploy Wildfly/JBoss. This would make it really easy to support multiple
> versions as well as different distro's of JBoss/Wildfly on the same
> machine and save huge amounts of disk space. If we could get a JVM that
> could share JAR instances between processes to save on RAM, the win
> would be even bigger! Think of the cloud implications!

I think we would need some kind of tool to make sure that a repo is 
fully downloaded if people wanted to use this in production. Even though 
download on demand is cool, you would not want a production server 
hanging as it attempts to download a jar. Not sure what sort of form 
this tool would take.

Stuart

> * JBoss Module definitions could eventually be defined in one large XML
> file. We would have maven/ant plugins to help build this large XML file.
> * This single JBoss Module XML file could be bundled within a
> JBoss/Wildfly "executable jar".
> * This "executable jar" could be overlayed with external JBoss Module
> XML files or directory structures.
> * Finally, you could create this "executable jar" for any Java project.
>
>
>
>
> On 3/4/2014 1:37 AM, Stuart Douglas wrote:
>> I have made a start on this split, and I think the solution I am working
>> on will meet all the use cases, including users that want to cut down an
>> existing server, and users that want to re-use the jars in their maven
>> repo using Bill's changes to JBoss Modules. It still needs a bit more
>> work and a lot of cleanup, however it seems to work:
>>
>> https://github.com/stuartwdouglas/wildfly/compare/wildfly-build-plugin
>>
>> So basically the core of it is a maven plugin that builds a Wildfly
>> distribution, either from scratch or use other distributions as a base.
>>
>> It also supports building servers that use the new <artifact>
>> functionality in jboss modules, and cutting down an existing server into
>> a smaller server with only the specified modules (and their transitive
>> dependencies).
>>
>> The way this will work in practice is that each Wildfly sub project will
>> produce two different server artifacts, one of which is a server without
>> any jars using artifact references, and a more traditional version with
>> jars packaged in the module directory. Downstream projects will consume
>> the smaller version without all the jars, so when a version changes the
>> download should be less than 5mb rather than larger than 100mb (the
>> plugin has the ability to turn a server that uses artifact references
>> into a server that contains the jars in the modules dir).
>>
>> Basically the upshot is that it should be basically possible to build
>> whatever configuration of server you want once this is part of our build
>> process, and we should also be publishing lightweight server artifacts
>> that use the jars in the maven repo as well as our traditional
>> 'everything and the kitchen sink' build.
>>
>> It is anticipated that 3rd party projects build on Wildfly would also
>> use this plugin (I think at the moment the standard approach has been to
>> copy and modify our ant scripts).
>>
>> This is still very much a work in progress, so nothing is set in stone
>> yet and any comments are welcome.
>>
>> Stuart
>>
>>
>> Bill Burke wrote:
>>> A lot of users want that ability, would you rather have them roll Netty
>>> + whatever?
>>>
>>> On 2/23/2014 9:10 PM, Stuart Douglas wrote:
>>>> No, because that means we essentially have to support and test every
>>>> possible combination that someone might select.
>>>>
>>>> Stuart
>>>>
>>>>
>>>> On Mon, Feb 24, 2014 at 7:13 AM, Misty Stanley-Jones<misty at redhat.com
>>>> <mailto:misty at redhat.com>> wrote:
>>>>
>>>> I know you guys aren?t there yet, but can we think about wrapping a
>>>> GUI around this, so that the developer only needs to tick the boxes
>>>> for what he does/doesn?t want, with dependencies sorted out
>>>> automatically? Maybe some default profiles that select a group of
>>>> things, but the ability to go in and add or remove individual
>>>> subsystems as needed? Maybe this could be part of the installer but
>>>> could optionally be run post-install as well.
>>>>
>>>> On Feb 22, 2014, at 2:01 AM, Brian Stansberry
>>>> <brian.stansberry at redhat.com<mailto:brian.stansberry at redhat.com>>
>>>> wrote:
>>>>
>>>> > When I said "Web" I meant the thing described on that wiki
>>>> page Tomaz
>>>> > linked:
>>>> >
>>>> > "Web
>>>> >
>>>> > Undertow subsystem, and all related dependencies, including
>>>> a small
>>>> > subset of EE and JNDI. This is basically just a Servlet
>>>> container, and
>>>> > will provide a platform for people that want to create web
>>>> based
>>>> > appliances or applications, and don't need all the additional
>>>> > functionality that Wildfly provides. We should end up with
>>>> something as
>>>> > lightweight as Tomcat or Jetty, but with all our advanced
>>>> management
>>>> > functionality."
>>>> >
>>>> > On 2/21/14, 9:40 AM, Bill Burke wrote:
>>>> >> Its also "Web" minus some stuff. For my project I want just
>>>> Servlet,
>>>> >> JAX-RS, JPA, and datasources. Its very very hard to
>>>> figure out
>>>> how to
>>>> >> remove a subsystem and all its associated modules.
>>>> >>
>>>> >> BTW, I think my maven artifact thing got into JBoss
>>>> Modules. So it
>>>> >> would be possible to load jars on demand, or at least use
>>>> it as
>>>> a way to
>>>> >> figure out which modules aren't being used ;).
>>>> >>
>>>> >>
>>>> >> On 2/21/2014 10:22 AM, Brian Stansberry wrote:
>>>> >>> This will move things in the right direction, but not all the
>>>> way there
>>>> >>> yet. Note the set of capabilities Bill mention: web, CDI,
>>>> JAX-RS, JPA.
>>>> >>> That sounds like our "Web" variant, plus some stuff. It's the
>>>> easy "plus
>>>> >>> some stuff" part that needs sorting at some point.
>>>> >>>
>>>> >>> On 2/21/14, 9:08 AM, Toma? Cerar wrote:
>>>> >>>> Bill,
>>>> >>>>
>>>> >>>> that is exactly idea we have in mind of 9.
>>>> >>>> We already started with producing WildFly core
>>>> distribution in
>>>> that is
>>>> >>>> WildFly with no subsystems, upon which you can build you own
>>>> wildfly.
>>>> >>>> It is only 15mb and contains whole mgmt capabilites (CLI,
>>>> standalone,
>>>> >>>> domain,...) you can grab it at:
>>>> >>>>
>>>>
>>>> http://download.jboss.org/wildfly/8.0.0.Final/core/wildfly-core-8.0.0.Final.zip
>>>>
>>>>
>>>> >>>>
>>>> >>>> For 9 we have plans to move things bit further and have
>>>> decided that we
>>>> >>>> will also do split codebase for core, ee, web, .. and other
>>>> distributions.
>>>> >>>>
>>>> >>>> Current idea on code split up is here
>>>> >>>>
>>>> https://community.jboss.org/wiki/SplittingUpTheWildflyCodeBase
>>>> >>>>
>>>> >>>> --
>>>> >>>> tomaz
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> On Fri, Feb 21, 2014 at 3:00 PM, Bill
>>>> Burke<bburke at redhat.com
>>>> <mailto:bburke at redhat.com>
>>>> >>>> <mailto:bburke at redhat.com<mailto:bburke at redhat.com>>>
>>>> wrote:
>>>> >>>>
>>>> >>>> On Resteasy list I have a few people "rolling their own
>>>> app server"
>>>> >>>> using Netty, Weld, Resteasy and JPA. I asked one of
>>>> them
>>>> "I don't
>>>> >>>> understand why you are rolling your own app server"
>>>> response:
>>>> >>>>
>>>> >>>> "It's actually a lot more lightweight. The minimum
>>>> I can
>>>> run the
>>>> >>>> equivalent on AS7 on is ~ 180 mb in binaries, but
>>>> throwing this
>>>> >>>> together is about 32 mb (and compresses further when
>>>> its
>>>> packaged).
>>>> >>>> I'm able to start the JVM on the bare minimum
>>>> (~100mb on
>>>> my linux VM)
>>>> >>>> but AS7 with all I need is about 756mb. When
>>>> rolling out
>>>> in the
>>>> >>>> cloud, where all of my REST APIs are stateless, running
>>>> with this
>>>> >>>> configuration helps us get a lot more per node."
>>>> >>>>
>>>> >>>> I'm not complaining :), just something to think
>>>> about. It
>>>> might be
>>>> >>>> really valuable to focus a bit in Wildfly 9 to make it
>>>> easier to create
>>>> >>>> custom profiles or even different packaging options for
>>>> the app server
>>>> >>>> instead of the exploded style we currently have.
>>>> >>>> --
>>>> >>>> Bill Burke
>>>> >>>> JBoss, a division of Red Hat
>>>> >>>> http://bill.burkecentral.com
>>>> >>>> _______________________________________________
>>>> >>>> wildfly-dev mailing list
>>>> >>>> wildfly-dev at lists.jboss.org
>>>> <mailto:wildfly-dev at lists.jboss.org>
>>>> <mailto:wildfly-dev at lists.jboss.org
>>>> <mailto:wildfly-dev at lists.jboss.org>>
>>>> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> _______________________________________________
>>>> >>>> wildfly-dev mailing list
>>>> >>>>
>>>> wildfly-dev at lists.jboss.org<mailto:wildfly-dev at lists.jboss.org>
>>>> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>> >>>>
>>>> >>>
>>>> >>>
>>>> >>
>>>> >
>>>> >
>>>> > --
>>>> > Brian Stansberry
>>>> > Senior Principal Software Engineer
>>>> > JBoss by Red Hat
>>>> > _______________________________________________
>>>> > wildfly-dev mailing list
>>>> > wildfly-dev at lists.jboss.org<mailto:wildfly-dev at lists.jboss.org>
>>>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>> Misty Stanley-Jones, RHCE
>>>> Manager, Content Services (Middleware)
>>>> Direct: + 61 7 3514 8105<tel:%2B%2061%207%203514%208105> / Mobile:
>>>> +61 429 595 932<tel:%2B61%20429%20595%20932> (TZ: GMT+10)
>>>> IRC: misty (Freenode / RH)
>>>>
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org<mailto:wildfly-dev at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>
>>
>

-- 
Sent using Postbox:
http://www.getpostbox.com

From jlivings at redhat.com  Tue Mar  4 19:49:16 2014
From: jlivings at redhat.com (James Livingston)
Date: Wed, 05 Mar 2014 10:49:16 +1000
Subject: [wildfly-dev] Gathering diagnostic data
In-Reply-To: <530DE0E8.7070807@redhat.com>
References: <1393385206.5235.31.camel@dhcp-0-235.bne.redhat.com>
	<530D5FEE.3030300@redhat.com> <530D6963.80606@redhat.com>
	<1393389503.5235.41.camel@dhcp-0-235.bne.redhat.com>
	<530DE0E8.7070807@redhat.com>
Message-ID: <1393980556.4918.6.camel@dhcp-0-235.bne.redhat.com>

On Wed, 2014-02-26 at 06:41 -0600, Brian Stansberry wrote:
> You either need to provide 2 ops, or the details with no fallback, or 
> just the unstructured text. It can't be a single op that provides well 
> structured data except if something goes wrong in which case it provides 
> unstructured text. The metadata for an op describes the structure of the 
> return data, and that description can't be ambiguous.
> 
> I think starting with a just-text op is best and then let your users 
> help drive your roadmap.

Thanks, I'll do that and see what everyone wants to use it for.


To me, the obvious place for these kind of server-specific ops in domain
mode would be under /host=*/server=*/ probably under sub-model since
there could be a non-trivial number of useful operations. Operations
there get routed to the server to execute, but I need code run on the HC
instead.

I've seen the HOST_CONTROLLER_ONLY flag which sounds like what I want,
but that doesn't affect /host/server ops. Am I mis-understanding the
flag and that's not what it's for, or should it work?

PrepareStepHandler uses isServerOperation() to direct operations under a
server to the instance without regard for HOST_CONTROLLER_ONLY, and
OperationRouting.determineRouting() only checks the flag if it's not in
that location.


-- 
James "Doc" Livingston
JBoss Support Engineering Group


From stuart.w.douglas at gmail.com  Tue Mar  4 23:55:58 2014
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Wed, 05 Mar 2014 15:55:58 +1100
Subject: [wildfly-dev] smaller footprints
In-Reply-To: <53164297.8020405@gmail.com>
References: <53075BEA.8030608@redhat.com>	<CAMquZP4RPXFgAPsCnnOLvH=XTkeQJ2bno5ms5yimD3gK6erkbw@mail.gmail.com>	<53076F18.3020603@redhat.com>
	<5307737C.2080603@redhat.com>	<53077867.3050600@redhat.com>	<3807F2B2-87E9-43F8-9A5C-E60340C748FF@redhat.com>
	<CAAoo=c7rWYObqRGQN2g34PR0bdP6YLeFCaoi3E5f7PuMQkav7Q@mail.gmail.com>
	<530B508F.5040409@redhat.com> <531574B1.5080404@gmail.com>
	<5315E4AA.1070603@redhat.com> <53164297.8020405@gmail.com>
Message-ID: <5316AE5E.8050708@gmail.com>

So now onto one of the hard problems, naming things...

As a result of splitting up the server we are going to end up with a lot 
more artifacts. Basically each repo will produce at least two servers, a 
cut down server that uses the maven repo and a full server that is 
similar to what we have at the moment, and we are going to need some 
kind of consistent name for them.

I am thinking maybe something like:

wildfly-core-build (cut down server core build)
wildfly-core-build-dist (core + all jars)
wildfly-web-build (cut down wildfly server with just the Undertow subsystem)
wildfly-web-build-dist (as above, but with jars)
wildfly-build (cut down full server)
wildfly-build-dist (as above)

Does anyone have any better ideas about what to call this stuff?

One side effect of the above would be that the build directory will no 
longer contain the full Wildfly server (just a version with no jars 
present), and the full server would be in the dist directory instead.

Stuart

Stuart Douglas wrote:
>
>
> Bill Burke wrote:
>> Great work Stuart! I'm really happy somebody is taking initiative on
>> this because I really think it will help a lot with Wildfly adoption. Is
>> it ready to use? I'm willing to try it out RIGHT NOW.
>
> Sort of. You can build from my wildfly-build-plugin branch and it should
> work, but at the moment it is creating a build that includes all the
> jars. If you want to create a build that uses <artifact> you will need
> to modify the copy-module-artifacts attribute in ./build/server-build.xml .
>
> Eventually we will produce both versions, I should get to this some time
> today.
>
> Also this is very new, and may not work, but if you want to try it out
> feel free. Hopefully I will have something a lot more polished by the
> end of the week.
>
>>
>> I've expressed some of these thoughts months ago when I introduced the
>> JBoss Modules artifact features, but here was my vision:
>>
>> * maven repos would become to Wildfly as /lib /usr/local/lib directory
>> structures are to unix.
>> * The JBoss Module artifact feature would become the preferred way to
>> deploy Wildfly/JBoss. This would make it really easy to support multiple
>> versions as well as different distro's of JBoss/Wildfly on the same
>> machine and save huge amounts of disk space. If we could get a JVM that
>> could share JAR instances between processes to save on RAM, the win
>> would be even bigger! Think of the cloud implications!
>
> I think we would need some kind of tool to make sure that a repo is
> fully downloaded if people wanted to use this in production. Even though
> download on demand is cool, you would not want a production server
> hanging as it attempts to download a jar. Not sure what sort of form
> this tool would take.
>
> Stuart
>
>> * JBoss Module definitions could eventually be defined in one large XML
>> file. We would have maven/ant plugins to help build this large XML file.
>> * This single JBoss Module XML file could be bundled within a
>> JBoss/Wildfly "executable jar".
>> * This "executable jar" could be overlayed with external JBoss Module
>> XML files or directory structures.
>> * Finally, you could create this "executable jar" for any Java project.
>>
>>
>>
>>
>> On 3/4/2014 1:37 AM, Stuart Douglas wrote:
>>> I have made a start on this split, and I think the solution I am working
>>> on will meet all the use cases, including users that want to cut down an
>>> existing server, and users that want to re-use the jars in their maven
>>> repo using Bill's changes to JBoss Modules. It still needs a bit more
>>> work and a lot of cleanup, however it seems to work:
>>>
>>> https://github.com/stuartwdouglas/wildfly/compare/wildfly-build-plugin
>>>
>>> So basically the core of it is a maven plugin that builds a Wildfly
>>> distribution, either from scratch or use other distributions as a base.
>>>
>>> It also supports building servers that use the new <artifact>
>>> functionality in jboss modules, and cutting down an existing server into
>>> a smaller server with only the specified modules (and their transitive
>>> dependencies).
>>>
>>> The way this will work in practice is that each Wildfly sub project will
>>> produce two different server artifacts, one of which is a server without
>>> any jars using artifact references, and a more traditional version with
>>> jars packaged in the module directory. Downstream projects will consume
>>> the smaller version without all the jars, so when a version changes the
>>> download should be less than 5mb rather than larger than 100mb (the
>>> plugin has the ability to turn a server that uses artifact references
>>> into a server that contains the jars in the modules dir).
>>>
>>> Basically the upshot is that it should be basically possible to build
>>> whatever configuration of server you want once this is part of our build
>>> process, and we should also be publishing lightweight server artifacts
>>> that use the jars in the maven repo as well as our traditional
>>> 'everything and the kitchen sink' build.
>>>
>>> It is anticipated that 3rd party projects build on Wildfly would also
>>> use this plugin (I think at the moment the standard approach has been to
>>> copy and modify our ant scripts).
>>>
>>> This is still very much a work in progress, so nothing is set in stone
>>> yet and any comments are welcome.
>>>
>>> Stuart
>>>
>>>
>>> Bill Burke wrote:
>>>> A lot of users want that ability, would you rather have them roll Netty
>>>> + whatever?
>>>>
>>>> On 2/23/2014 9:10 PM, Stuart Douglas wrote:
>>>>> No, because that means we essentially have to support and test every
>>>>> possible combination that someone might select.
>>>>>
>>>>> Stuart
>>>>>
>>>>>
>>>>> On Mon, Feb 24, 2014 at 7:13 AM, Misty Stanley-Jones<misty at redhat.com
>>>>> <mailto:misty at redhat.com>> wrote:
>>>>>
>>>>> I know you guys aren?t there yet, but can we think about wrapping a
>>>>> GUI around this, so that the developer only needs to tick the boxes
>>>>> for what he does/doesn?t want, with dependencies sorted out
>>>>> automatically? Maybe some default profiles that select a group of
>>>>> things, but the ability to go in and add or remove individual
>>>>> subsystems as needed? Maybe this could be part of the installer but
>>>>> could optionally be run post-install as well.
>>>>>
>>>>> On Feb 22, 2014, at 2:01 AM, Brian Stansberry
>>>>> <brian.stansberry at redhat.com<mailto:brian.stansberry at redhat.com>>
>>>>> wrote:
>>>>>
>>>>> > When I said "Web" I meant the thing described on that wiki
>>>>> page Tomaz
>>>>> > linked:
>>>>> >
>>>>> > "Web
>>>>> >
>>>>> > Undertow subsystem, and all related dependencies, including
>>>>> a small
>>>>> > subset of EE and JNDI. This is basically just a Servlet
>>>>> container, and
>>>>> > will provide a platform for people that want to create web
>>>>> based
>>>>> > appliances or applications, and don't need all the additional
>>>>> > functionality that Wildfly provides. We should end up with
>>>>> something as
>>>>> > lightweight as Tomcat or Jetty, but with all our advanced
>>>>> management
>>>>> > functionality."
>>>>> >
>>>>> > On 2/21/14, 9:40 AM, Bill Burke wrote:
>>>>> >> Its also "Web" minus some stuff. For my project I want just
>>>>> Servlet,
>>>>> >> JAX-RS, JPA, and datasources. Its very very hard to
>>>>> figure out
>>>>> how to
>>>>> >> remove a subsystem and all its associated modules.
>>>>> >>
>>>>> >> BTW, I think my maven artifact thing got into JBoss
>>>>> Modules. So it
>>>>> >> would be possible to load jars on demand, or at least use
>>>>> it as
>>>>> a way to
>>>>> >> figure out which modules aren't being used ;).
>>>>> >>
>>>>> >>
>>>>> >> On 2/21/2014 10:22 AM, Brian Stansberry wrote:
>>>>> >>> This will move things in the right direction, but not all the
>>>>> way there
>>>>> >>> yet. Note the set of capabilities Bill mention: web, CDI,
>>>>> JAX-RS, JPA.
>>>>> >>> That sounds like our "Web" variant, plus some stuff. It's the
>>>>> easy "plus
>>>>> >>> some stuff" part that needs sorting at some point.
>>>>> >>>
>>>>> >>> On 2/21/14, 9:08 AM, Toma? Cerar wrote:
>>>>> >>>> Bill,
>>>>> >>>>
>>>>> >>>> that is exactly idea we have in mind of 9.
>>>>> >>>> We already started with producing WildFly core
>>>>> distribution in
>>>>> that is
>>>>> >>>> WildFly with no subsystems, upon which you can build you own
>>>>> wildfly.
>>>>> >>>> It is only 15mb and contains whole mgmt capabilites (CLI,
>>>>> standalone,
>>>>> >>>> domain,...) you can grab it at:
>>>>> >>>>
>>>>>
>>>>> http://download.jboss.org/wildfly/8.0.0.Final/core/wildfly-core-8.0.0.Final.zip
>>>>>
>>>>>
>>>>>
>>>>> >>>>
>>>>> >>>> For 9 we have plans to move things bit further and have
>>>>> decided that we
>>>>> >>>> will also do split codebase for core, ee, web, .. and other
>>>>> distributions.
>>>>> >>>>
>>>>> >>>> Current idea on code split up is here
>>>>> >>>>
>>>>> https://community.jboss.org/wiki/SplittingUpTheWildflyCodeBase
>>>>> >>>>
>>>>> >>>> --
>>>>> >>>> tomaz
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> On Fri, Feb 21, 2014 at 3:00 PM, Bill
>>>>> Burke<bburke at redhat.com
>>>>> <mailto:bburke at redhat.com>
>>>>> >>>> <mailto:bburke at redhat.com<mailto:bburke at redhat.com>>>
>>>>> wrote:
>>>>> >>>>
>>>>> >>>> On Resteasy list I have a few people "rolling their own
>>>>> app server"
>>>>> >>>> using Netty, Weld, Resteasy and JPA. I asked one of
>>>>> them
>>>>> "I don't
>>>>> >>>> understand why you are rolling your own app server"
>>>>> response:
>>>>> >>>>
>>>>> >>>> "It's actually a lot more lightweight. The minimum
>>>>> I can
>>>>> run the
>>>>> >>>> equivalent on AS7 on is ~ 180 mb in binaries, but
>>>>> throwing this
>>>>> >>>> together is about 32 mb (and compresses further when
>>>>> its
>>>>> packaged).
>>>>> >>>> I'm able to start the JVM on the bare minimum
>>>>> (~100mb on
>>>>> my linux VM)
>>>>> >>>> but AS7 with all I need is about 756mb. When
>>>>> rolling out
>>>>> in the
>>>>> >>>> cloud, where all of my REST APIs are stateless, running
>>>>> with this
>>>>> >>>> configuration helps us get a lot more per node."
>>>>> >>>>
>>>>> >>>> I'm not complaining :), just something to think
>>>>> about. It
>>>>> might be
>>>>> >>>> really valuable to focus a bit in Wildfly 9 to make it
>>>>> easier to create
>>>>> >>>> custom profiles or even different packaging options for
>>>>> the app server
>>>>> >>>> instead of the exploded style we currently have.
>>>>> >>>> --
>>>>> >>>> Bill Burke
>>>>> >>>> JBoss, a division of Red Hat
>>>>> >>>> http://bill.burkecentral.com
>>>>> >>>> _______________________________________________
>>>>> >>>> wildfly-dev mailing list
>>>>> >>>> wildfly-dev at lists.jboss.org
>>>>> <mailto:wildfly-dev at lists.jboss.org>
>>>>> <mailto:wildfly-dev at lists.jboss.org
>>>>> <mailto:wildfly-dev at lists.jboss.org>>
>>>>> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> _______________________________________________
>>>>> >>>> wildfly-dev mailing list
>>>>> >>>>
>>>>> wildfly-dev at lists.jboss.org<mailto:wildfly-dev at lists.jboss.org>
>>>>> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>> >>>>
>>>>> >>>
>>>>> >>>
>>>>> >>
>>>>> >
>>>>> >
>>>>> > --
>>>>> > Brian Stansberry
>>>>> > Senior Principal Software Engineer
>>>>> > JBoss by Red Hat
>>>>> > _______________________________________________
>>>>> > wildfly-dev mailing list
>>>>> > wildfly-dev at lists.jboss.org<mailto:wildfly-dev at lists.jboss.org>
>>>>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>> Misty Stanley-Jones, RHCE
>>>>> Manager, Content Services (Middleware)
>>>>> Direct: + 61 7 3514 8105<tel:%2B%2061%207%203514%208105> / Mobile:
>>>>> +61 429 595 932<tel:%2B61%20429%20595%20932> (TZ: GMT+10)
>>>>> IRC: misty (Freenode / RH)
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org<mailto:wildfly-dev at lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>
>>>
>>
>

From tomaz.cerar at gmail.com  Wed Mar  5 04:27:48 2014
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Wed, 5 Mar 2014 10:27:48 +0100
Subject: [wildfly-dev] smaller footprints
In-Reply-To: <5316AE5E.8050708@gmail.com>
References: <53075BEA.8030608@redhat.com>
	<CAMquZP4RPXFgAPsCnnOLvH=XTkeQJ2bno5ms5yimD3gK6erkbw@mail.gmail.com>
	<53076F18.3020603@redhat.com> <5307737C.2080603@redhat.com>
	<53077867.3050600@redhat.com>
	<3807F2B2-87E9-43F8-9A5C-E60340C748FF@redhat.com>
	<CAAoo=c7rWYObqRGQN2g34PR0bdP6YLeFCaoi3E5f7PuMQkav7Q@mail.gmail.com>
	<530B508F.5040409@redhat.com> <531574B1.5080404@gmail.com>
	<5315E4AA.1070603@redhat.com> <53164297.8020405@gmail.com>
	<5316AE5E.8050708@gmail.com>
Message-ID: <CAMquZP4=OZNUXPSbNQzk1ZMXQ=GOhcJKiKY3mB5XZ9kfYWgzhQ@mail.gmail.com>

What about bit shorter for dist, removing "-build-" part

wildfly-core-build (cut down server core build)
wildfly-core-dist (core + all jars)
wildfly-web-build (cut down wildfly server with just the Undertow subsystem)
wildfly-web-dist (as above, but with jars)
wildfly-build (cut down full server)
wildfly-dist (as above)




On Wed, Mar 5, 2014 at 5:55 AM, Stuart Douglas
<stuart.w.douglas at gmail.com>wrote:

> So now onto one of the hard problems, naming things...
>
> As a result of splitting up the server we are going to end up with a lot
> more artifacts. Basically each repo will produce at least two servers, a
> cut down server that uses the maven repo and a full server that is
> similar to what we have at the moment, and we are going to need some
> kind of consistent name for them.
>
> I am thinking maybe something like:
>
> wildfly-core-build (cut down server core build)
> wildfly-core-build-dist (core + all jars)
> wildfly-web-build (cut down wildfly server with just the Undertow
> subsystem)
> wildfly-web-build-dist (as above, but with jars)
> wildfly-build (cut down full server)
> wildfly-build-dist (as above)
>
> Does anyone have any better ideas about what to call this stuff?
>
> One side effect of the above would be that the build directory will no
> longer contain the full Wildfly server (just a version with no jars
> present), and the full server would be in the dist directory instead.
>
> Stuart
>
> Stuart Douglas wrote:
> >
> >
> > Bill Burke wrote:
> >> Great work Stuart! I'm really happy somebody is taking initiative on
> >> this because I really think it will help a lot with Wildfly adoption. Is
> >> it ready to use? I'm willing to try it out RIGHT NOW.
> >
> > Sort of. You can build from my wildfly-build-plugin branch and it should
> > work, but at the moment it is creating a build that includes all the
> > jars. If you want to create a build that uses <artifact> you will need
> > to modify the copy-module-artifacts attribute in
> ./build/server-build.xml .
> >
> > Eventually we will produce both versions, I should get to this some time
> > today.
> >
> > Also this is very new, and may not work, but if you want to try it out
> > feel free. Hopefully I will have something a lot more polished by the
> > end of the week.
> >
> >>
> >> I've expressed some of these thoughts months ago when I introduced the
> >> JBoss Modules artifact features, but here was my vision:
> >>
> >> * maven repos would become to Wildfly as /lib /usr/local/lib directory
> >> structures are to unix.
> >> * The JBoss Module artifact feature would become the preferred way to
> >> deploy Wildfly/JBoss. This would make it really easy to support multiple
> >> versions as well as different distro's of JBoss/Wildfly on the same
> >> machine and save huge amounts of disk space. If we could get a JVM that
> >> could share JAR instances between processes to save on RAM, the win
> >> would be even bigger! Think of the cloud implications!
> >
> > I think we would need some kind of tool to make sure that a repo is
> > fully downloaded if people wanted to use this in production. Even though
> > download on demand is cool, you would not want a production server
> > hanging as it attempts to download a jar. Not sure what sort of form
> > this tool would take.
> >
> > Stuart
> >
> >> * JBoss Module definitions could eventually be defined in one large XML
> >> file. We would have maven/ant plugins to help build this large XML file.
> >> * This single JBoss Module XML file could be bundled within a
> >> JBoss/Wildfly "executable jar".
> >> * This "executable jar" could be overlayed with external JBoss Module
> >> XML files or directory structures.
> >> * Finally, you could create this "executable jar" for any Java project.
> >>
> >>
> >>
> >>
> >> On 3/4/2014 1:37 AM, Stuart Douglas wrote:
> >>> I have made a start on this split, and I think the solution I am
> working
> >>> on will meet all the use cases, including users that want to cut down
> an
> >>> existing server, and users that want to re-use the jars in their maven
> >>> repo using Bill's changes to JBoss Modules. It still needs a bit more
> >>> work and a lot of cleanup, however it seems to work:
> >>>
> >>> https://github.com/stuartwdouglas/wildfly/compare/wildfly-build-plugin
> >>>
> >>> So basically the core of it is a maven plugin that builds a Wildfly
> >>> distribution, either from scratch or use other distributions as a base.
> >>>
> >>> It also supports building servers that use the new <artifact>
> >>> functionality in jboss modules, and cutting down an existing server
> into
> >>> a smaller server with only the specified modules (and their transitive
> >>> dependencies).
> >>>
> >>> The way this will work in practice is that each Wildfly sub project
> will
> >>> produce two different server artifacts, one of which is a server
> without
> >>> any jars using artifact references, and a more traditional version with
> >>> jars packaged in the module directory. Downstream projects will consume
> >>> the smaller version without all the jars, so when a version changes the
> >>> download should be less than 5mb rather than larger than 100mb (the
> >>> plugin has the ability to turn a server that uses artifact references
> >>> into a server that contains the jars in the modules dir).
> >>>
> >>> Basically the upshot is that it should be basically possible to build
> >>> whatever configuration of server you want once this is part of our
> build
> >>> process, and we should also be publishing lightweight server artifacts
> >>> that use the jars in the maven repo as well as our traditional
> >>> 'everything and the kitchen sink' build.
> >>>
> >>> It is anticipated that 3rd party projects build on Wildfly would also
> >>> use this plugin (I think at the moment the standard approach has been
> to
> >>> copy and modify our ant scripts).
> >>>
> >>> This is still very much a work in progress, so nothing is set in stone
> >>> yet and any comments are welcome.
> >>>
> >>> Stuart
> >>>
> >>>
> >>> Bill Burke wrote:
> >>>> A lot of users want that ability, would you rather have them roll
> Netty
> >>>> + whatever?
> >>>>
> >>>> On 2/23/2014 9:10 PM, Stuart Douglas wrote:
> >>>>> No, because that means we essentially have to support and test every
> >>>>> possible combination that someone might select.
> >>>>>
> >>>>> Stuart
> >>>>>
> >>>>>
> >>>>> On Mon, Feb 24, 2014 at 7:13 AM, Misty Stanley-Jones<
> misty at redhat.com
> >>>>> <mailto:misty at redhat.com>> wrote:
> >>>>>
> >>>>> I know you guys aren?t there yet, but can we think about wrapping a
> >>>>> GUI around this, so that the developer only needs to tick the boxes
> >>>>> for what he does/doesn?t want, with dependencies sorted out
> >>>>> automatically? Maybe some default profiles that select a group of
> >>>>> things, but the ability to go in and add or remove individual
> >>>>> subsystems as needed? Maybe this could be part of the installer but
> >>>>> could optionally be run post-install as well.
> >>>>>
> >>>>> On Feb 22, 2014, at 2:01 AM, Brian Stansberry
> >>>>> <brian.stansberry at redhat.com<mailto:brian.stansberry at redhat.com>>
> >>>>> wrote:
> >>>>>
> >>>>> > When I said "Web" I meant the thing described on that wiki
> >>>>> page Tomaz
> >>>>> > linked:
> >>>>> >
> >>>>> > "Web
> >>>>> >
> >>>>> > Undertow subsystem, and all related dependencies, including
> >>>>> a small
> >>>>> > subset of EE and JNDI. This is basically just a Servlet
> >>>>> container, and
> >>>>> > will provide a platform for people that want to create web
> >>>>> based
> >>>>> > appliances or applications, and don't need all the additional
> >>>>> > functionality that Wildfly provides. We should end up with
> >>>>> something as
> >>>>> > lightweight as Tomcat or Jetty, but with all our advanced
> >>>>> management
> >>>>> > functionality."
> >>>>> >
> >>>>> > On 2/21/14, 9:40 AM, Bill Burke wrote:
> >>>>> >> Its also "Web" minus some stuff. For my project I want just
> >>>>> Servlet,
> >>>>> >> JAX-RS, JPA, and datasources. Its very very hard to
> >>>>> figure out
> >>>>> how to
> >>>>> >> remove a subsystem and all its associated modules.
> >>>>> >>
> >>>>> >> BTW, I think my maven artifact thing got into JBoss
> >>>>> Modules. So it
> >>>>> >> would be possible to load jars on demand, or at least use
> >>>>> it as
> >>>>> a way to
> >>>>> >> figure out which modules aren't being used ;).
> >>>>> >>
> >>>>> >>
> >>>>> >> On 2/21/2014 10:22 AM, Brian Stansberry wrote:
> >>>>> >>> This will move things in the right direction, but not all the
> >>>>> way there
> >>>>> >>> yet. Note the set of capabilities Bill mention: web, CDI,
> >>>>> JAX-RS, JPA.
> >>>>> >>> That sounds like our "Web" variant, plus some stuff. It's the
> >>>>> easy "plus
> >>>>> >>> some stuff" part that needs sorting at some point.
> >>>>> >>>
> >>>>> >>> On 2/21/14, 9:08 AM, Toma? Cerar wrote:
> >>>>> >>>> Bill,
> >>>>> >>>>
> >>>>> >>>> that is exactly idea we have in mind of 9.
> >>>>> >>>> We already started with producing WildFly core
> >>>>> distribution in
> >>>>> that is
> >>>>> >>>> WildFly with no subsystems, upon which you can build you own
> >>>>> wildfly.
> >>>>> >>>> It is only 15mb and contains whole mgmt capabilites (CLI,
> >>>>> standalone,
> >>>>> >>>> domain,...) you can grab it at:
> >>>>> >>>>
> >>>>>
> >>>>>
> http://download.jboss.org/wildfly/8.0.0.Final/core/wildfly-core-8.0.0.Final.zip
> >>>>>
> >>>>>
> >>>>>
> >>>>> >>>>
> >>>>> >>>> For 9 we have plans to move things bit further and have
> >>>>> decided that we
> >>>>> >>>> will also do split codebase for core, ee, web, .. and other
> >>>>> distributions.
> >>>>> >>>>
> >>>>> >>>> Current idea on code split up is here
> >>>>> >>>>
> >>>>> https://community.jboss.org/wiki/SplittingUpTheWildflyCodeBase
> >>>>> >>>>
> >>>>> >>>> --
> >>>>> >>>> tomaz
> >>>>> >>>>
> >>>>> >>>>
> >>>>> >>>>
> >>>>> >>>> On Fri, Feb 21, 2014 at 3:00 PM, Bill
> >>>>> Burke<bburke at redhat.com
> >>>>> <mailto:bburke at redhat.com>
> >>>>> >>>> <mailto:bburke at redhat.com<mailto:bburke at redhat.com>>>
> >>>>> wrote:
> >>>>> >>>>
> >>>>> >>>> On Resteasy list I have a few people "rolling their own
> >>>>> app server"
> >>>>> >>>> using Netty, Weld, Resteasy and JPA. I asked one of
> >>>>> them
> >>>>> "I don't
> >>>>> >>>> understand why you are rolling your own app server"
> >>>>> response:
> >>>>> >>>>
> >>>>> >>>> "It's actually a lot more lightweight. The minimum
> >>>>> I can
> >>>>> run the
> >>>>> >>>> equivalent on AS7 on is ~ 180 mb in binaries, but
> >>>>> throwing this
> >>>>> >>>> together is about 32 mb (and compresses further when
> >>>>> its
> >>>>> packaged).
> >>>>> >>>> I'm able to start the JVM on the bare minimum
> >>>>> (~100mb on
> >>>>> my linux VM)
> >>>>> >>>> but AS7 with all I need is about 756mb. When
> >>>>> rolling out
> >>>>> in the
> >>>>> >>>> cloud, where all of my REST APIs are stateless, running
> >>>>> with this
> >>>>> >>>> configuration helps us get a lot more per node."
> >>>>> >>>>
> >>>>> >>>> I'm not complaining :), just something to think
> >>>>> about. It
> >>>>> might be
> >>>>> >>>> really valuable to focus a bit in Wildfly 9 to make it
> >>>>> easier to create
> >>>>> >>>> custom profiles or even different packaging options for
> >>>>> the app server
> >>>>> >>>> instead of the exploded style we currently have.
> >>>>> >>>> --
> >>>>> >>>> Bill Burke
> >>>>> >>>> JBoss, a division of Red Hat
> >>>>> >>>> http://bill.burkecentral.com
> >>>>> >>>> _______________________________________________
> >>>>> >>>> wildfly-dev mailing list
> >>>>> >>>> wildfly-dev at lists.jboss.org
> >>>>> <mailto:wildfly-dev at lists.jboss.org>
> >>>>> <mailto:wildfly-dev at lists.jboss.org
> >>>>> <mailto:wildfly-dev at lists.jboss.org>>
> >>>>> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>>>> >>>>
> >>>>> >>>>
> >>>>> >>>>
> >>>>> >>>>
> >>>>> >>>> _______________________________________________
> >>>>> >>>> wildfly-dev mailing list
> >>>>> >>>>
> >>>>> wildfly-dev at lists.jboss.org<mailto:wildfly-dev at lists.jboss.org>
> >>>>> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>>>> >>>>
> >>>>> >>>
> >>>>> >>>
> >>>>> >>
> >>>>> >
> >>>>> >
> >>>>> > --
> >>>>> > Brian Stansberry
> >>>>> > Senior Principal Software Engineer
> >>>>> > JBoss by Red Hat
> >>>>> > _______________________________________________
> >>>>> > wildfly-dev mailing list
> >>>>> > wildfly-dev at lists.jboss.org<mailto:wildfly-dev at lists.jboss.org>
> >>>>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>>>>
> >>>>> Misty Stanley-Jones, RHCE
> >>>>> Manager, Content Services (Middleware)
> >>>>> Direct: + 61 7 3514 8105<tel:%2B%2061%207%203514%208105> / Mobile:
> >>>>> +61 429 595 932<tel:%2B61%20429%20595%20932> (TZ: GMT+10)
> >>>>> IRC: misty (Freenode / RH)
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> wildfly-dev mailing list
> >>>>> wildfly-dev at lists.jboss.org<mailto:wildfly-dev at lists.jboss.org>
> >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> wildfly-dev mailing list
> >>>>> wildfly-dev at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>>>>
> >>>>
> >>>
> >>
> >
> _______________________________________________
> 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/20140305/e1f1eb15/attachment-0001.html 

From jmesnil at redhat.com  Wed Mar  5 05:29:44 2014
From: jmesnil at redhat.com (Jeff Mesnil)
Date: Wed, 5 Mar 2014 11:29:44 +0100
Subject: [wildfly-dev] Issue with HTTP upgrade for remote naming on
	OpenShift?
In-Reply-To: <CFCE13EA-6085-4FCA-8E7A-EA88E8A9BD80@redhat.com>
References: <4FFCB7B5-4DA7-4687-9502-FD8DFD065447@redhat.com>
	<CAAoo=c5ieuV1st5cP7Z+N+ASMFcc4gs6NB8SuA3p-U2d74pHjQ@mail.gmail.com>
	<CAMquZP6OZ_mJXbRu4DB-bsztWEr=WXQwKqT8PBna5jd5xgn3Cg@mail.gmail.com>
	<641DBC94-03F4-4D2A-948C-42994B7CF0D5@redhat.com>
	<1242021429.9408539.1392758353840.JavaMail.zimbra@redhat.com>
	<CFCE13EA-6085-4FCA-8E7A-EA88E8A9BD80@redhat.com>
Message-ID: <270821F6-005C-4C4C-B108-283186E60DE7@redhat.com>

I?ve spent some time running WildFly on OpenShift and playing with it.

* I?ve added a quickstart using WebSocket API[1] and it works fine on OpenShift. 
=> note however that OpenShift requires to use a different port for WebSocket (8000) than for HTTP (80) even though both are mapped to WildFly?s 8080 internal port.

* OpenShift does not support custom protocols for HTTP upgrade beside web socket[2][3]
=> all the quick starts using remote naming, EJB, JMS from external clients will not work unless port-forwarding is enabled.

jeff

[1] https://github.com/wildfly/quickstart/tree/master/helloworld-websocket
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1071862
[3] https://trello.com/c/swGjabeH

jeff
 
On 19 Feb 2014, at 09:15, Jeff Mesnil <jmesnil at redhat.com> wrote:

> 
> On 18 Feb 2014, at 22:19, Farah Juma <fjuma at redhat.com> wrote:
> 
>> I'm looking into this as well to see if there's a way to make this work. When using port forwarding, I'm finding that an error still occurs:
> 
> At this stage, port forwarding works. Thanks Farah.
> 
> The remaining issue is the way HornetQ configures its connectors.
> 
> HornetQ connectors are the bits that are retrieved using JNDI and contains the informations to connect to the HornetQ server (embedded with WildFly in our case).
> The ugly ugly part of it is that the connector must know the host of the server to connect to.
> In WildFly, we resolve the socket-binding (http in this case) to get this address[1]. When using OpenShift, the HornetQ connectors will use the OpenShift server address (127.5.118.129).
> If I use port forwarding, the remote naming will work and I will retrieve a connector that wants to connect to 127.5.118.129 from my local machine and this does not work.
> 
> The HornetQ team has some features planned for the cloud. I?ll let them know about this.
> 
> [1] https://github.com/wildfly/wildfly/blob/master/messaging/src/main/java/org/jboss/as/messaging/HornetQService.java#L181
> 
> -- 
> Jeff Mesnil
> JBoss, a division of Red Hat
> http://jmesnil.net/
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

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



From jgreene at redhat.com  Wed Mar  5 12:10:08 2014
From: jgreene at redhat.com (Jason T. Greene)
Date: Wed, 5 Mar 2014 12:10:08 -0500 (EST)
Subject: [wildfly-dev] Issue with HTTP upgrade for remote naming
	on	OpenShift?
In-Reply-To: <270821F6-005C-4C4C-B108-283186E60DE7@redhat.com>
References: <4FFCB7B5-4DA7-4687-9502-FD8DFD065447@redhat.com>
	<CAAoo=c5ieuV1st5cP7Z+N+ASMFcc4gs6NB8SuA3p-U2d74pHjQ@mail.gmail.com>
	<CAMquZP6OZ_mJXbRu4DB-bsztWEr=WXQwKqT8PBna5jd5xgn3Cg@mail.gmail.com>
	<641DBC94-03F4-4D2A-948C-42994B7CF0D5@redhat.com>
	<1242021429.9408539.1392758353840.JavaMail.zimbra@redhat.com>
	<CFCE13EA-6085-4FCA-8E7A-EA88E8A9BD80@redhat.com>
	<270821F6-005C-4C4C-B108-283186E60DE7@redhat.com>
Message-ID: <10564328-00F3-4D82-B1E3-336545C5B6C8@redhat.com>

Thanks for looking into it.

We should start a discussion with the openshift team on that. 

> On Mar 5, 2014, at 4:31 AM, Jeff Mesnil <jmesnil at redhat.com> wrote:
> 
> I?ve spent some time running WildFly on OpenShift and playing with it.
> 
> * I?ve added a quickstart using WebSocket API[1] and it works fine on OpenShift. 
> => note however that OpenShift requires to use a different port for WebSocket (8000) than for HTTP (80) even though both are mapped to WildFly?s 8080 internal port.
> 
> * OpenShift does not support custom protocols for HTTP upgrade beside web socket[2][3]
> => all the quick starts using remote naming, EJB, JMS from external clients will not work unless port-forwarding is enabled.
> 
> jeff
> 
> [1] https://github.com/wildfly/quickstart/tree/master/helloworld-websocket
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1071862
> [3] https://trello.com/c/swGjabeH
> 
> jeff
> 
>> On 19 Feb 2014, at 09:15, Jeff Mesnil <jmesnil at redhat.com> wrote:
>> 
>> 
>>> On 18 Feb 2014, at 22:19, Farah Juma <fjuma at redhat.com> wrote:
>>> 
>>> I'm looking into this as well to see if there's a way to make this work. When using port forwarding, I'm finding that an error still occurs:
>> 
>> At this stage, port forwarding works. Thanks Farah.
>> 
>> The remaining issue is the way HornetQ configures its connectors.
>> 
>> HornetQ connectors are the bits that are retrieved using JNDI and contains the informations to connect to the HornetQ server (embedded with WildFly in our case).
>> The ugly ugly part of it is that the connector must know the host of the server to connect to.
>> In WildFly, we resolve the socket-binding (http in this case) to get this address[1]. When using OpenShift, the HornetQ connectors will use the OpenShift server address (127.5.118.129).
>> If I use port forwarding, the remote naming will work and I will retrieve a connector that wants to connect to 127.5.118.129 from my local machine and this does not work.
>> 
>> The HornetQ team has some features planned for the cloud. I?ll let them know about this.
>> 
>> [1] https://github.com/wildfly/wildfly/blob/master/messaging/src/main/java/org/jboss/as/messaging/HornetQService.java#L181
>> 
>> -- 
>> Jeff Mesnil
>> JBoss, a division of Red Hat
>> http://jmesnil.net/
>> 
>> 
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> -- 
> Jeff Mesnil
> JBoss, a division of Red Hat
> http://jmesnil.net/
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From stuart.w.douglas at gmail.com  Wed Mar  5 15:04:28 2014
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Thu, 06 Mar 2014 07:04:28 +1100
Subject: [wildfly-dev] smaller footprints
In-Reply-To: <CAMquZP4=OZNUXPSbNQzk1ZMXQ=GOhcJKiKY3mB5XZ9kfYWgzhQ@mail.gmail.com>
References: <53075BEA.8030608@redhat.com>
	<CAMquZP4RPXFgAPsCnnOLvH=XTkeQJ2bno5ms5yimD3gK6erkbw@mail.gmail.com>
	<53076F18.3020603@redhat.com> <5307737C.2080603@redhat.com>
	<53077867.3050600@redhat.com>
	<3807F2B2-87E9-43F8-9A5C-E60340C748FF@redhat.com>
	<CAAoo=c7rWYObqRGQN2g34PR0bdP6YLeFCaoi3E5f7PuMQkav7Q@mail.gmail.com>
	<530B508F.5040409@redhat.com> <531574B1.5080404@gmail.com>
	<5315E4AA.1070603@redhat.com> <53164297.8020405@gmail.com>
	<5316AE5E.8050708@gmail.com>
	<CAMquZP4=OZNUXPSbNQzk1ZMXQ=GOhcJKiKY3mB5XZ9kfYWgzhQ@mail.gmail.com>
Message-ID: <5317834C.2010803@gmail.com>

That sounds fine to me. In the absence of any other suggestions I will 
go with this for now.

Stuart

Toma? Cerar wrote:
> What about bit shorter for dist, removing "-build-" part
>
> wildfly-core-build (cut down server core build)
> wildfly-core-dist (core + all jars)
> wildfly-web-build (cut down wildfly server with just the Undertow subsystem)
> wildfly-web-dist (as above, but with jars)
> wildfly-build (cut down full server)
> wildfly-dist (as above)
>
>
>
>
> On Wed, Mar 5, 2014 at 5:55 AM, Stuart Douglas
> <stuart.w.douglas at gmail.com <mailto:stuart.w.douglas at gmail.com>> wrote:
>
>     So now onto one of the hard problems, naming things...
>
>     As a result of splitting up the server we are going to end up with a lot
>     more artifacts. Basically each repo will produce at least two servers, a
>     cut down server that uses the maven repo and a full server that is
>     similar to what we have at the moment, and we are going to need some
>     kind of consistent name for them.
>
>     I am thinking maybe something like:
>
>     wildfly-core-build (cut down server core build)
>     wildfly-core-build-dist (core + all jars)
>     wildfly-web-build (cut down wildfly server with just the Undertow
>     subsystem)
>     wildfly-web-build-dist (as above, but with jars)
>     wildfly-build (cut down full server)
>     wildfly-build-dist (as above)
>
>     Does anyone have any better ideas about what to call this stuff?
>
>     One side effect of the above would be that the build directory will no
>     longer contain the full Wildfly server (just a version with no jars
>     present), and the full server would be in the dist directory instead.
>
>     Stuart
>
>     Stuart Douglas wrote:
>      >
>      >
>      > Bill Burke wrote:
>      >> Great work Stuart! I'm really happy somebody is taking initiative on
>      >> this because I really think it will help a lot with Wildfly
>     adoption. Is
>      >> it ready to use? I'm willing to try it out RIGHT NOW.
>      >
>      > Sort of. You can build from my wildfly-build-plugin branch and it
>     should
>      > work, but at the moment it is creating a build that includes all the
>      > jars. If you want to create a build that uses <artifact> you will
>     need
>      > to modify the copy-module-artifacts attribute in
>     ./build/server-build.xml .
>      >
>      > Eventually we will produce both versions, I should get to this
>     some time
>      > today.
>      >
>      > Also this is very new, and may not work, but if you want to try
>     it out
>      > feel free. Hopefully I will have something a lot more polished by the
>      > end of the week.
>      >
>      >>
>      >> I've expressed some of these thoughts months ago when I
>     introduced the
>      >> JBoss Modules artifact features, but here was my vision:
>      >>
>      >> * maven repos would become to Wildfly as /lib /usr/local/lib
>     directory
>      >> structures are to unix.
>      >> * The JBoss Module artifact feature would become the preferred
>     way to
>      >> deploy Wildfly/JBoss. This would make it really easy to support
>     multiple
>      >> versions as well as different distro's of JBoss/Wildfly on the same
>      >> machine and save huge amounts of disk space. If we could get a
>     JVM that
>      >> could share JAR instances between processes to save on RAM, the win
>      >> would be even bigger! Think of the cloud implications!
>      >
>      > I think we would need some kind of tool to make sure that a repo is
>      > fully downloaded if people wanted to use this in production. Even
>     though
>      > download on demand is cool, you would not want a production server
>      > hanging as it attempts to download a jar. Not sure what sort of form
>      > this tool would take.
>      >
>      > Stuart
>      >
>      >> * JBoss Module definitions could eventually be defined in one
>     large XML
>      >> file. We would have maven/ant plugins to help build this large
>     XML file.
>      >> * This single JBoss Module XML file could be bundled within a
>      >> JBoss/Wildfly "executable jar".
>      >> * This "executable jar" could be overlayed with external JBoss
>     Module
>      >> XML files or directory structures.
>      >> * Finally, you could create this "executable jar" for any Java
>     project.
>      >>
>      >>
>      >>
>      >>
>      >> On 3/4/2014 1:37 AM, Stuart Douglas wrote:
>      >>> I have made a start on this split, and I think the solution I
>     am working
>      >>> on will meet all the use cases, including users that want to
>     cut down an
>      >>> existing server, and users that want to re-use the jars in
>     their maven
>      >>> repo using Bill's changes to JBoss Modules. It still needs a
>     bit more
>      >>> work and a lot of cleanup, however it seems to work:
>      >>>
>      >>>
>     https://github.com/stuartwdouglas/wildfly/compare/wildfly-build-plugin
>      >>>
>      >>> So basically the core of it is a maven plugin that builds a Wildfly
>      >>> distribution, either from scratch or use other distributions as
>     a base.
>      >>>
>      >>> It also supports building servers that use the new <artifact>
>      >>> functionality in jboss modules, and cutting down an existing
>     server into
>      >>> a smaller server with only the specified modules (and their
>     transitive
>      >>> dependencies).
>      >>>
>      >>> The way this will work in practice is that each Wildfly sub
>     project will
>      >>> produce two different server artifacts, one of which is a
>     server without
>      >>> any jars using artifact references, and a more traditional
>     version with
>      >>> jars packaged in the module directory. Downstream projects will
>     consume
>      >>> the smaller version without all the jars, so when a version
>     changes the
>      >>> download should be less than 5mb rather than larger than 100mb (the
>      >>> plugin has the ability to turn a server that uses artifact
>     references
>      >>> into a server that contains the jars in the modules dir).
>      >>>
>      >>> Basically the upshot is that it should be basically possible to
>     build
>      >>> whatever configuration of server you want once this is part of
>     our build
>      >>> process, and we should also be publishing lightweight server
>     artifacts
>      >>> that use the jars in the maven repo as well as our traditional
>      >>> 'everything and the kitchen sink' build.
>      >>>
>      >>> It is anticipated that 3rd party projects build on Wildfly
>     would also
>      >>> use this plugin (I think at the moment the standard approach
>     has been to
>      >>> copy and modify our ant scripts).
>      >>>
>      >>> This is still very much a work in progress, so nothing is set
>     in stone
>      >>> yet and any comments are welcome.
>      >>>
>      >>> Stuart
>      >>>
>      >>>
>      >>> Bill Burke wrote:
>      >>>> A lot of users want that ability, would you rather have them
>     roll Netty
>      >>>> + whatever?
>      >>>>
>      >>>> On 2/23/2014 9:10 PM, Stuart Douglas wrote:
>      >>>>> No, because that means we essentially have to support and
>     test every
>      >>>>> possible combination that someone might select.
>      >>>>>
>      >>>>> Stuart
>      >>>>>
>      >>>>>
>      >>>>> On Mon, Feb 24, 2014 at 7:13 AM, Misty
>     Stanley-Jones<misty at redhat.com <mailto:misty at redhat.com>
>      >>>>> <mailto:misty at redhat.com <mailto:misty at redhat.com>>> wrote:
>      >>>>>
>      >>>>> I know you guys aren?t there yet, but can we think about
>     wrapping a
>      >>>>> GUI around this, so that the developer only needs to tick the
>     boxes
>      >>>>> for what he does/doesn?t want, with dependencies sorted out
>      >>>>> automatically? Maybe some default profiles that select a group of
>      >>>>> things, but the ability to go in and add or remove individual
>      >>>>> subsystems as needed? Maybe this could be part of the
>     installer but
>      >>>>> could optionally be run post-install as well.
>      >>>>>
>      >>>>> On Feb 22, 2014, at 2:01 AM, Brian Stansberry
>      >>>>> <brian.stansberry at redhat.com
>     <mailto:brian.stansberry at redhat.com><mailto:brian.stansberry at redhat.com
>     <mailto:brian.stansberry at redhat.com>>>
>      >>>>> wrote:
>      >>>>>
>      >>>>> > When I said "Web" I meant the thing described on that wiki
>      >>>>> page Tomaz
>      >>>>> > linked:
>      >>>>> >
>      >>>>> > "Web
>      >>>>> >
>      >>>>> > Undertow subsystem, and all related dependencies, including
>      >>>>> a small
>      >>>>> > subset of EE and JNDI. This is basically just a Servlet
>      >>>>> container, and
>      >>>>> > will provide a platform for people that want to create web
>      >>>>> based
>      >>>>> > appliances or applications, and don't need all the additional
>      >>>>> > functionality that Wildfly provides. We should end up with
>      >>>>> something as
>      >>>>> > lightweight as Tomcat or Jetty, but with all our advanced
>      >>>>> management
>      >>>>> > functionality."
>      >>>>> >
>      >>>>> > On 2/21/14, 9:40 AM, Bill Burke wrote:
>      >>>>> >> Its also "Web" minus some stuff. For my project I want just
>      >>>>> Servlet,
>      >>>>> >> JAX-RS, JPA, and datasources. Its very very hard to
>      >>>>> figure out
>      >>>>> how to
>      >>>>> >> remove a subsystem and all its associated modules.
>      >>>>> >>
>      >>>>> >> BTW, I think my maven artifact thing got into JBoss
>      >>>>> Modules. So it
>      >>>>> >> would be possible to load jars on demand, or at least use
>      >>>>> it as
>      >>>>> a way to
>      >>>>> >> figure out which modules aren't being used ;).
>      >>>>> >>
>      >>>>> >>
>      >>>>> >> On 2/21/2014 10:22 AM, Brian Stansberry wrote:
>      >>>>> >>> This will move things in the right direction, but not all the
>      >>>>> way there
>      >>>>> >>> yet. Note the set of capabilities Bill mention: web, CDI,
>      >>>>> JAX-RS, JPA.
>      >>>>> >>> That sounds like our "Web" variant, plus some stuff. It's the
>      >>>>> easy "plus
>      >>>>> >>> some stuff" part that needs sorting at some point.
>      >>>>> >>>
>      >>>>> >>> On 2/21/14, 9:08 AM, Toma? Cerar wrote:
>      >>>>> >>>> Bill,
>      >>>>> >>>>
>      >>>>> >>>> that is exactly idea we have in mind of 9.
>      >>>>> >>>> We already started with producing WildFly core
>      >>>>> distribution in
>      >>>>> that is
>      >>>>> >>>> WildFly with no subsystems, upon which you can build you own
>      >>>>> wildfly.
>      >>>>> >>>> It is only 15mb and contains whole mgmt capabilites (CLI,
>      >>>>> standalone,
>      >>>>> >>>> domain,...) you can grab it at:
>      >>>>> >>>>
>      >>>>>
>      >>>>>
>     http://download.jboss.org/wildfly/8.0.0.Final/core/wildfly-core-8.0.0.Final.zip
>      >>>>>
>      >>>>>
>      >>>>>
>      >>>>> >>>>
>      >>>>> >>>> For 9 we have plans to move things bit further and have
>      >>>>> decided that we
>      >>>>> >>>> will also do split codebase for core, ee, web, .. and other
>      >>>>> distributions.
>      >>>>> >>>>
>      >>>>> >>>> Current idea on code split up is here
>      >>>>> >>>>
>      >>>>> https://community.jboss.org/wiki/SplittingUpTheWildflyCodeBase
>      >>>>> >>>>
>      >>>>> >>>> --
>      >>>>> >>>> tomaz
>      >>>>> >>>>
>      >>>>> >>>>
>      >>>>> >>>>
>      >>>>> >>>> On Fri, Feb 21, 2014 at 3:00 PM, Bill
>      >>>>> Burke<bburke at redhat.com <mailto:bburke at redhat.com>
>      >>>>> <mailto:bburke at redhat.com <mailto:bburke at redhat.com>>
>      >>>>> >>>> <mailto:bburke at redhat.com
>     <mailto:bburke at redhat.com><mailto:bburke at redhat.com
>     <mailto:bburke at redhat.com>>>>
>      >>>>> wrote:
>      >>>>> >>>>
>      >>>>> >>>> On Resteasy list I have a few people "rolling their own
>      >>>>> app server"
>      >>>>> >>>> using Netty, Weld, Resteasy and JPA. I asked one of
>      >>>>> them
>      >>>>> "I don't
>      >>>>> >>>> understand why you are rolling your own app server"
>      >>>>> response:
>      >>>>> >>>>
>      >>>>> >>>> "It's actually a lot more lightweight. The minimum
>      >>>>> I can
>      >>>>> run the
>      >>>>> >>>> equivalent on AS7 on is ~ 180 mb in binaries, but
>      >>>>> throwing this
>      >>>>> >>>> together is about 32 mb (and compresses further when
>      >>>>> its
>      >>>>> packaged).
>      >>>>> >>>> I'm able to start the JVM on the bare minimum
>      >>>>> (~100mb on
>      >>>>> my linux VM)
>      >>>>> >>>> but AS7 with all I need is about 756mb. When
>      >>>>> rolling out
>      >>>>> in the
>      >>>>> >>>> cloud, where all of my REST APIs are stateless, running
>      >>>>> with this
>      >>>>> >>>> configuration helps us get a lot more per node."
>      >>>>> >>>>
>      >>>>> >>>> I'm not complaining :), just something to think
>      >>>>> about. It
>      >>>>> might be
>      >>>>> >>>> really valuable to focus a bit in Wildfly 9 to make it
>      >>>>> easier to create
>      >>>>> >>>> custom profiles or even different packaging options for
>      >>>>> the app server
>      >>>>> >>>> instead of the exploded style we currently have.
>      >>>>> >>>> --
>      >>>>> >>>> Bill Burke
>      >>>>> >>>> JBoss, a division of Red Hat
>      >>>>> >>>> http://bill.burkecentral.com
>      >>>>> >>>> _______________________________________________
>      >>>>> >>>> wildfly-dev mailing list
>      >>>>> >>>> wildfly-dev at lists.jboss.org
>     <mailto:wildfly-dev at lists.jboss.org>
>      >>>>> <mailto:wildfly-dev at lists.jboss.org
>     <mailto:wildfly-dev at lists.jboss.org>>
>      >>>>> <mailto:wildfly-dev at lists.jboss.org
>     <mailto:wildfly-dev at lists.jboss.org>
>      >>>>> <mailto:wildfly-dev at lists.jboss.org
>     <mailto:wildfly-dev at lists.jboss.org>>>
>      >>>>> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>      >>>>> >>>>
>      >>>>> >>>>
>      >>>>> >>>>
>      >>>>> >>>>
>      >>>>> >>>> _______________________________________________
>      >>>>> >>>> wildfly-dev mailing list
>      >>>>> >>>>
>      >>>>> wildfly-dev at lists.jboss.org
>     <mailto:wildfly-dev at lists.jboss.org><mailto:wildfly-dev at lists.jboss.org
>     <mailto: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
>     <mailto:wildfly-dev at lists.jboss.org><mailto:wildfly-dev at lists.jboss.org
>     <mailto:wildfly-dev at lists.jboss.org>>
>      >>>>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>      >>>>>
>      >>>>> Misty Stanley-Jones, RHCE
>      >>>>> Manager, Content Services (Middleware)
>      >>>>> Direct: + 61 7 3514 8105
>     <tel:%2B%2061%207%203514%208105><tel:%2B%2061%207%203514%208105> /
>     Mobile:
>      >>>>> +61 429 595 932
>     <tel:%2B61%20429%20595%20932><tel:%2B61%20429%20595%20932> (TZ: GMT+10)
>      >>>>> IRC: misty (Freenode / RH)
>      >>>>>
>      >>>>>
>      >>>>> _______________________________________________
>      >>>>> wildfly-dev mailing list
>      >>>>> wildfly-dev at lists.jboss.org
>     <mailto:wildfly-dev at lists.jboss.org><mailto:wildfly-dev at lists.jboss.org
>     <mailto:wildfly-dev at lists.jboss.org>>
>      >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>      >>>>>
>      >>>>>
>      >>>>>
>      >>>>>
>      >>>>> _______________________________________________
>      >>>>> wildfly-dev mailing list
>      >>>>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>      >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>      >>>>>
>      >>>>
>      >>>
>      >>
>      >
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>

From brian.stansberry at redhat.com  Wed Mar  5 16:34:32 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 05 Mar 2014 15:34:32 -0600
Subject: [wildfly-dev] Gathering diagnostic data
In-Reply-To: <1393980556.4918.6.camel@dhcp-0-235.bne.redhat.com>
References: <1393385206.5235.31.camel@dhcp-0-235.bne.redhat.com>	<530D5FEE.3030300@redhat.com>
	<530D6963.80606@redhat.com>	<1393389503.5235.41.camel@dhcp-0-235.bne.redhat.com>	<530DE0E8.7070807@redhat.com>
	<1393980556.4918.6.camel@dhcp-0-235.bne.redhat.com>
Message-ID: <53179868.9060508@redhat.com>

On 3/4/14, 6:49 PM, James Livingston wrote:
> On Wed, 2014-02-26 at 06:41 -0600, Brian Stansberry wrote:
>> You either need to provide 2 ops, or the details with no fallback, or
>> just the unstructured text. It can't be a single op that provides well
>> structured data except if something goes wrong in which case it provides
>> unstructured text. The metadata for an op describes the structure of the
>> return data, and that description can't be ambiguous.
>>
>> I think starting with a just-text op is best and then let your users
>> help drive your roadmap.
>
> Thanks, I'll do that and see what everyone wants to use it for.
>
>
> To me, the obvious place for these kind of server-specific ops in domain
> mode would be under /host=*/server=*/ probably under sub-model

Doing this in a sub-resource would be very difficult as it significantly 
complicates the issues I'll discuss below.

> since
> there could be a non-trivial number of useful operations. Operations
> there get routed to the server to execute, but I need code run on the HC
> instead.
>

Yes, this is a general problem; the /host=*/server=* resource actually 
resides on the server process; on the host process at that address all 
there is is some proxy code that proxies the request to the server.

If you look at DomainModelControllerService.registerRunningServer() you 
can see where it adds some extra ops to the resource registration for 
the server address:

// Register local operation overrides
         final ManagementResourceRegistration serverRegistration = 
hostRegistration.getSubModel(PathAddress.EMPTY_ADDRESS.append(pe));
 
ServerConfigResourceDefinition.registerServerLifecycleOperations(serverRegistration, 
serverInventory);

That's ok for that single case, but we need to find a slicker mechanism 
for doing this kind of thing. I don't want DomainModelControllerService 
to end up full of this kind of logic.

If you want to add in another call like that 
ServerConfigResourceDefinition.registerServerLifecycleOperations call 
for now to keep progressing though, that's fine. We'll just need to come 
up with something better before we're done.

> I've seen the HOST_CONTROLLER_ONLY flag which sounds like what I want,
> but that doesn't affect /host/server ops. Am I mis-understanding the
> flag and that's not what it's for, or should it work?
>

That's not what it's for. :) It's for preventing 2-step behavior when it 
would otherwise occur, but in this case 2-step behavior isn't desired.

> PrepareStepHandler uses isServerOperation() to direct operations under a
> server to the instance without regard for HOST_CONTROLLER_ONLY, and
> OperationRouting.determineRouting() only checks the flag if it's not in
> that location.
>

The routing is correct -- the call should execute direct and not go into 
the 2 phase logic used for stuff that applies locally and then gets 
rolled out to servers. This needs to be solved via some more 
sophisticated behavior in the HC process at the /host=*/server=* address.


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

From brian.stansberry at redhat.com  Wed Mar  5 16:48:27 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 05 Mar 2014 15:48:27 -0600
Subject: [wildfly-dev] Gathering diagnostic data
In-Reply-To: <53179868.9060508@redhat.com>
References: <1393385206.5235.31.camel@dhcp-0-235.bne.redhat.com>	<530D5FEE.3030300@redhat.com>	<530D6963.80606@redhat.com>	<1393389503.5235.41.camel@dhcp-0-235.bne.redhat.com>	<530DE0E8.7070807@redhat.com>	<1393980556.4918.6.camel@dhcp-0-235.bne.redhat.com>
	<53179868.9060508@redhat.com>
Message-ID: <53179BAB.5080404@redhat.com>

Emanuel (or anyone),

in-line...

On 3/5/14, 3:34 PM, Brian Stansberry wrote:
> On 3/4/14, 6:49 PM, James Livingston wrote:
>> To me, the obvious place for these kind of server-specific ops in domain
>> mode would be under /host=*/server=*/ probably under sub-model
>
> Doing this in a sub-resource would be very difficult as it significantly
> complicates the issues I'll discuss below.
>
>> since
>> there could be a non-trivial number of useful operations. Operations
>> there get routed to the server to execute, but I need code run on the HC
>> instead.
>>
>
> Yes, this is a general problem; the /host=*/server=* resource actually
> resides on the server process; on the host process at that address all
> there is is some proxy code that proxies the request to the server.
>
> If you look at DomainModelControllerService.registerRunningServer() you
> can see where it adds some extra ops to the resource registration for
> the server address:
>
> // Register local operation overrides
>           final ManagementResourceRegistration serverRegistration =
> hostRegistration.getSubModel(PathAddress.EMPTY_ADDRESS.append(pe));
>
> ServerConfigResourceDefinition.registerServerLifecycleOperations(serverRegistration,
> serverInventory);
>
> That's ok for that single case, but we need to find a slicker mechanism
> for doing this kind of thing. I don't want DomainModelControllerService
> to end up full of this kind of logic.
>
> If you want to add in another call like that
> ServerConfigResourceDefinition.registerServerLifecycleOperations call
> for now to keep progressing though, that's fine. We'll just need to come
> up with something better before we're done.
>

Looking at ConcreteResourceRegistration.registerProxyController, what 
happens is it ignores the existing child registration at server=* and 
goes ahead and registers the proxy controller because it's address is 
server=foo. So thereafter "foo" essentially masks "*" when the request 
is for "foo".

If this worked more like the override model stuff instead of a complete 
mask, then operations registered for "*" would be visible. 
StoppedServerResource is what currently registers these.

WDYT?


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

From jlivings at redhat.com  Wed Mar  5 18:52:57 2014
From: jlivings at redhat.com (James Livingston)
Date: Thu, 06 Mar 2014 09:52:57 +1000
Subject: [wildfly-dev] Gathering diagnostic data
In-Reply-To: <53179868.9060508@redhat.com>
References: <1393385206.5235.31.camel@dhcp-0-235.bne.redhat.com>
	<530D5FEE.3030300@redhat.com> <530D6963.80606@redhat.com>
	<1393389503.5235.41.camel@dhcp-0-235.bne.redhat.com>
	<530DE0E8.7070807@redhat.com>
	<1393980556.4918.6.camel@dhcp-0-235.bne.redhat.com>
	<53179868.9060508@redhat.com>
Message-ID: <1394063577.1770.8.camel@dhcp-0-235.bne.redhat.com>

On Wed, 2014-03-05 at 15:34 -0600, Brian Stansberry wrote:
> Yes, this is a general problem; the /host=*/server=* resource actually 
> resides on the server process; on the host process at that address all 
> there is is some proxy code that proxies the request to the server.

That makes sense, and matches what I was seeing when I was stepping
through in a debugger yesterday. I originally thought that it proxied
the operations not the whole sub-model.


> That's ok for that single case, but we need to find a slicker mechanism 
> for doing this kind of thing. I don't want DomainModelControllerService 
> to end up full of this kind of logic.
> 
> If you want to add in another call like that 
> ServerConfigResourceDefinition.registerServerLifecycleOperations call 
> for now to keep progressing though, that's fine. We'll just need to come 
> up with something better before we're done.

For now I've just stuck it on as /host=*:thread-dump(server=*), which
works fine for developing the more interesting bits.

I think these kind of per-server things logically belong under the
server, so I'll see what gets thought up in the other branch of the
thread.


-- 
James "Doc" Livingston
JBoss Support Engineering Group


From emuckenh at redhat.com  Thu Mar  6 06:07:01 2014
From: emuckenh at redhat.com (Emanuel Muckenhuber)
Date: Thu, 06 Mar 2014 12:07:01 +0100
Subject: [wildfly-dev] Gathering diagnostic data
In-Reply-To: <53179BAB.5080404@redhat.com>
References: <1393385206.5235.31.camel@dhcp-0-235.bne.redhat.com>	<530D5FEE.3030300@redhat.com>	<530D6963.80606@redhat.com>	<1393389503.5235.41.camel@dhcp-0-235.bne.redhat.com>	<530DE0E8.7070807@redhat.com>	<1393980556.4918.6.camel@dhcp-0-235.bne.redhat.com>
	<53179868.9060508@redhat.com> <53179BAB.5080404@redhat.com>
Message-ID: <531856D5.3030407@redhat.com>


On 03/05/2014 10:48 PM, Brian Stansberry wrote:
> in-line...
>
> On 3/5/14, 3:34 PM, Brian Stansberry wrote:
>> On 3/4/14, 6:49 PM, James Livingston wrote:
>>> To me, the obvious place for these kind of server-specific ops in domain
>>> mode would be under /host=*/server=*/ probably under sub-model
>>
>> Doing this in a sub-resource would be very difficult as it significantly
>> complicates the issues I'll discuss below.
>>
>>> since
>>> there could be a non-trivial number of useful operations. Operations
>>> there get routed to the server to execute, but I need code run on the HC
>>> instead.
>>>
>>
>> Yes, this is a general problem; the /host=*/server=* resource actually
>> resides on the server process; on the host process at that address all
>> there is is some proxy code that proxies the request to the server.
>>
>> If you look at DomainModelControllerService.registerRunningServer() you
>> can see where it adds some extra ops to the resource registration for
>> the server address:
>>
>> // Register local operation overrides
>>           final ManagementResourceRegistration serverRegistration =
>> hostRegistration.getSubModel(PathAddress.EMPTY_ADDRESS.append(pe));
>>
>> ServerConfigResourceDefinition.registerServerLifecycleOperations(serverRegistration,
>>
>> serverInventory);
>>
>> That's ok for that single case, but we need to find a slicker mechanism
>> for doing this kind of thing. I don't want DomainModelControllerService
>> to end up full of this kind of logic.
>>
>> If you want to add in another call like that
>> ServerConfigResourceDefinition.registerServerLifecycleOperations call
>> for now to keep progressing though, that's fine. We'll just need to come
>> up with something better before we're done.
>>
>
> Looking at ConcreteResourceRegistration.registerProxyController, what
> happens is it ignores the existing child registration at server=* and
> goes ahead and registers the proxy controller because it's address is
> server=foo. So thereafter "foo" essentially masks "*" when the request
> is for "foo".
>
> If this worked more like the override model stuff instead of a complete
> mask, then operations registered for "*" would be visible.
> StoppedServerResource is what currently registers these.
>
> WDYT?
>

Yeah, something like that would make sense. At least for operations 
which should be there regardless whether the server is started or 
stopped. Where probably the gathering diagnostics data should only be 
available when the server is started?

I agree that the #registerRunningServer() should be done differently. I 
am actually surprised that this is there, i thought it's just sitting in 
a branch of mine. At least the descriptions are not exposed, so it 
should not be usable atm.

IIRC there is another problem that the actual "*" registration should be 
something like a local proxy controller, to be able to dispatch 
operations properly. I think i do have something like this sitting in 
one of my branches, i'll see if i find it again.

Emanuel


From brian.stansberry at redhat.com  Thu Mar  6 10:34:28 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 06 Mar 2014 09:34:28 -0600
Subject: [wildfly-dev] Gathering diagnostic data
In-Reply-To: <1394063577.1770.8.camel@dhcp-0-235.bne.redhat.com>
References: <1393385206.5235.31.camel@dhcp-0-235.bne.redhat.com>	<530D5FEE.3030300@redhat.com>
	<530D6963.80606@redhat.com>	<1393389503.5235.41.camel@dhcp-0-235.bne.redhat.com>	<530DE0E8.7070807@redhat.com>	<1393980556.4918.6.camel@dhcp-0-235.bne.redhat.com>	<53179868.9060508@redhat.com>
	<1394063577.1770.8.camel@dhcp-0-235.bne.redhat.com>
Message-ID: <53189584.2000900@redhat.com>

On 3/5/14, 5:52 PM, James Livingston wrote:
> On Wed, 2014-03-05 at 15:34 -0600, Brian Stansberry wrote:
>> Yes, this is a general problem; the /host=*/server=* resource actually
>> resides on the server process; on the host process at that address all
>> there is is some proxy code that proxies the request to the server.
>
> That makes sense, and matches what I was seeing when I was stepping
> through in a debugger yesterday. I originally thought that it proxied
> the operations not the whole sub-model.
>
>
>> That's ok for that single case, but we need to find a slicker mechanism
>> for doing this kind of thing. I don't want DomainModelControllerService
>> to end up full of this kind of logic.
>>
>> If you want to add in another call like that
>> ServerConfigResourceDefinition.registerServerLifecycleOperations call
>> for now to keep progressing though, that's fine. We'll just need to come
>> up with something better before we're done.
>
> For now I've just stuck it on as /host=*:thread-dump(server=*), which
> works fine for developing the more interesting bits.
>
> I think these kind of per-server things logically belong under the
> server, so I'll see what gets thought up in the other branch of the
> thread.
>

Just FYI, other of these kinds of things are now under 
/host=*/server-config=*. That's the resource for the <host><server> 
config data in host.xml. These server runtime control ops don't really 
belong there; that's just where they got placed initially because we had 
no time to solve this problem.


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

From brian.stansberry at redhat.com  Thu Mar  6 10:49:46 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 06 Mar 2014 09:49:46 -0600
Subject: [wildfly-dev] Gathering diagnostic data
In-Reply-To: <531856D5.3030407@redhat.com>
References: <1393385206.5235.31.camel@dhcp-0-235.bne.redhat.com>	<530D5FEE.3030300@redhat.com>	<530D6963.80606@redhat.com>	<1393389503.5235.41.camel@dhcp-0-235.bne.redhat.com>	<530DE0E8.7070807@redhat.com>	<1393980556.4918.6.camel@dhcp-0-235.bne.redhat.com>
	<53179868.9060508@redhat.com> <53179BAB.5080404@redhat.com>
	<531856D5.3030407@redhat.com>
Message-ID: <5318991A.2060301@redhat.com>

On 3/6/14, 5:07 AM, Emanuel Muckenhuber wrote:
>
> On 03/05/2014 10:48 PM, Brian Stansberry wrote:
>>
>> Looking at ConcreteResourceRegistration.registerProxyController, what
>> happens is it ignores the existing child registration at server=* and
>> goes ahead and registers the proxy controller because it's address is
>> server=foo. So thereafter "foo" essentially masks "*" when the request
>> is for "foo".
>>
>> If this worked more like the override model stuff instead of a complete
>> mask, then operations registered for "*" would be visible.
>> StoppedServerResource is what currently registers these.
>>
>> WDYT?
>>
>
> Yeah, something like that would make sense. At least for operations
> which should be there regardless whether the server is started or
> stopped. Where probably the gathering diagnostics data should only be
> available when the server is started?
>

Ideally yes, although that would require something different than the 
current override model mechanism, since the base ops would be in the * 
registration, thus always available, while the "if server is running" 
ops would be in the proxy registration.

I don't think having ops only be available if the server is started is 
necessarily a blocker though. I'm sure we have plenty of other static 
ops that make no sense in particular states. Just guessing, may not be 
an issue, things like test-connection on a DS, start/stop on a 
server-config come to mind.

> I agree that the #registerRunningServer() should be done differently. I
> am actually surprised that this is there, i thought it's just sitting in
> a branch of mine. At least the descriptions are not exposed, so it
> should not be usable atm.
>
> IIRC there is another problem that the actual "*" registration should be
> something like a local proxy controller, to be able to dispatch
> operations properly. I think i do have something like this sitting in
> one of my branches, i'll see if i find it again.
>
> Emanuel
>


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

From rory.odonnell at oracle.com  Thu Mar  6 12:55:36 2014
From: rory.odonnell at oracle.com (Rory O'Donnell Oracle, Dublin Ireland)
Date: Thu, 06 Mar 2014 17:55:36 +0000
Subject: [wildfly-dev] JDK 8 : Third Release Candidate - Build 132 is
	available on java.net
Message-ID: <5318B698.5080303@oracle.com>

Hi Guys,

JDK 8 Third Release Candidate , Build 132 is now available for download 
<http://jdk8.java.net/download.html> & test.
Please log all show stopper issues as soon as possible.

Rgds,Rory

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

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

From arun.gupta at gmail.com  Fri Mar  7 13:05:14 2014
From: arun.gupta at gmail.com (Arun Gupta)
Date: Fri, 7 Mar 2014 10:05:14 -0800
Subject: [wildfly-dev] Fwd: [Arun]Proposal for reviewing a book on 'Wildfly:
 New Features' for Packt Publishing
In-Reply-To: <53196A5A.4020105@packtpub.com>
References: <53196A5A.4020105@packtpub.com>
Message-ID: <CAGBoHQVTSs3RGHhYjaABB=_T4nk1xiWbRST4QvpgTPMDQmzC7Q@mail.gmail.com>

Anybody interested in reviewing this book ?

Let me know and I'll connect.


---------- Forwarded message ----------
From: Deepti Thore <deeptit at packtpub.com>
Date: Thu, Mar 6, 2014 at 10:42 PM
Subject: [Arun]Proposal for reviewing a book on 'Wildfly: New
Features' for Packt Publishing
To: arun.gupta at gmail.com


Hi Arun,

Pleased to meet you!

I am Deepti Thore, an Author Acquisition Executive at Packt. Packt
Publishing is a print-on-demand publishing company which specializes
in publishing books based on specific technologies and solutions. You
can find more information about us at http://www.packtpub.com.

This mail is regarding the proposal for Reviewing a book. The title of
the book is "Wildfly: New Features".

The total page count of the book would be approximately 100 pages.

I researched your profile, and felt that you would be an ideal person
to review this book for us.

The reader of this book will learn about all the new features of
Wildfly with small coded examples.

The target audience for the book would be JBOss AS7 developers who
want to know all the new features of Wildfly.

As a token of thanks, your name and biography would be included in the
"About the Reviewer" section in the first few pages of the book.

You will also be receiving two copies of the book: one eBook or print
copy of the book you review and an eBook of your choice from our
catalogue.

For more details regarding reviewing, please visit
http://www.packtpub.com/author_reviewing_for_packt.

If you are interested in this proposal, then please let me know at the
earliest. I would be happy to answer any questions you may have.

Kind Regards,

--

Deepti Thore
Author Acquisition Executive|Packt Publishing| www.packtpub.com
Tweet: @packtauthors
Interested in becoming an author? Visit http://authors.packtpub.com
for all the information you need about writing for Packt.


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

From brian.stansberry at redhat.com  Fri Mar  7 14:00:23 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Fri, 07 Mar 2014 13:00:23 -0600
Subject: [wildfly-dev] [jboss-as7-dev] Domain mode server launch command
In-Reply-To: <53199C33.3050407@redhat.com>
References: <502A81B2.8040607@redhat.com>
	<502A84CC.8070302@redhat.com>	<502A8AB8.7040803@redhat.com>
	<502A9589.4030601@redhat.com>	<502BD08A.2060409@redhat.com>	<C99FEE03-30C6-4A25-9755-41366B1F0CEE@jboss.com>	<502C6057.1020602@redhat.com>
	<503CD14A.10509@redhat.com>	<A11B26BD-C4E0-4D7A-AF01-5D583F267ABE@jboss.com>	<503E1B90.4030702@redhat.com>
	<503F40D6.4040102@redhat.com> <5310F8DA.50507@redhat.com>
	<53110D44.6030203@redhat.com> <5314C97D.6070604@redhat.com>
	<53182B56.3020808@redhat.com> <5318B26F.6020206@redhat.com>
	<53199C33.3050407@redhat.com>
Message-ID: <531A1747.8050901@redhat.com>

Hi John,

I copied the wildfly-dev list.

I prefer the <jvm> approach. We already have logic for combining jvm 
configs set at different levels (server-group, host, server) so people 
can set this at whatever level they prefer, and then if they want 
something different for a particular server they can override.

Cheers,

- Brian

On 3/7/14, 4:15 AM, John O'Hara wrote:
> Brian,
>
> I was talking to Kabir about incorporating this feature into the
> host-controller model. We discussed different options for places to
> define the launch command, and we came to the conclusion that it could
> be placed in one of two locations in host.xml. The options discussed were;
>
>  1. Incorporate the command as an attribute of the existing <jvm>
>     element. This would allow for the same lanuch command to be applied
>     to all servers in the domain and only have to define it once e.g.
>     running the server process under a different user id.  The launch
>     command can also be overwritten or defined for each server allowing
>     separate launch commands for each server e.g. pinning jvm to
>     particular numa nodes.
>  2. Creating a new <server-launch-command> element under the <server>
>     elements. Users would need to define the server launch command for
>     each server separately.
>
> I had originally defined the host schema with a <server-launch-command>
> element under the <server>element.  However, it might provide more
> flexibility to define the launch command in the <jvm> element.
>
> Kabir suggested that I run this by you, so your thoughts on where to
> define this in hosts.xml would be greatly appreciated.
>
> Thanks
>
> John

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

From jason.greene at redhat.com  Mon Mar 10 07:20:54 2014
From: jason.greene at redhat.com (Jason Greene)
Date: Mon, 10 Mar 2014 11:20:54 +0000
Subject: [wildfly-dev] smaller footprints
In-Reply-To: <5316AE5E.8050708@gmail.com>
References: <53075BEA.8030608@redhat.com>	<CAMquZP4RPXFgAPsCnnOLvH=XTkeQJ2bno5ms5yimD3gK6erkbw@mail.gmail.com>	<53076F18.3020603@redhat.com>
	<5307737C.2080603@redhat.com>	<53077867.3050600@redhat.com>	<3807F2B2-87E9-43F8-9A5C-E60340C748FF@redhat.com>
	<CAAoo=c7rWYObqRGQN2g34PR0bdP6YLeFCaoi3E5f7PuMQkav7Q@mail.gmail.com>
	<530B508F.5040409@redhat.com> <531574B1.5080404@gmail.com>
	<5315E4AA.1070603@redhat.com> <53164297.8020405@gmail.com>
	<5316AE5E.8050708@gmail.com>
Message-ID: <C47B4EF9-880F-4399-A8BE-D3D80905BE00@redhat.com>

In the original plan/writeup we had a separate clustering layer and EE layer. I guess the biggest limiting factor for those is cleaning up our dependencies.

On Mar 5, 2014, at 4:55 AM, Stuart Douglas <stuart.w.douglas at gmail.com> wrote:

> So now onto one of the hard problems, naming things...
> 
> As a result of splitting up the server we are going to end up with a lot 
> more artifacts. Basically each repo will produce at least two servers, a 
> cut down server that uses the maven repo and a full server that is 
> similar to what we have at the moment, and we are going to need some 
> kind of consistent name for them.
> 
> I am thinking maybe something like:
> 
> wildfly-core-build (cut down server core build)
> wildfly-core-build-dist (core + all jars)
> wildfly-web-build (cut down wildfly server with just the Undertow subsystem)
> wildfly-web-build-dist (as above, but with jars)
> wildfly-build (cut down full server)
> wildfly-build-dist (as above)
> 
> Does anyone have any better ideas about what to call this stuff?
> 
> One side effect of the above would be that the build directory will no 
> longer contain the full Wildfly server (just a version with no jars 
> present), and the full server would be in the dist directory instead.
> 
> Stuart
> 
> Stuart Douglas wrote:
>> 
>> 
>> Bill Burke wrote:
>>> Great work Stuart! I'm really happy somebody is taking initiative on
>>> this because I really think it will help a lot with Wildfly adoption. Is
>>> it ready to use? I'm willing to try it out RIGHT NOW.
>> 
>> Sort of. You can build from my wildfly-build-plugin branch and it should
>> work, but at the moment it is creating a build that includes all the
>> jars. If you want to create a build that uses <artifact> you will need
>> to modify the copy-module-artifacts attribute in ./build/server-build.xml .
>> 
>> Eventually we will produce both versions, I should get to this some time
>> today.
>> 
>> Also this is very new, and may not work, but if you want to try it out
>> feel free. Hopefully I will have something a lot more polished by the
>> end of the week.
>> 
>>> 
>>> I've expressed some of these thoughts months ago when I introduced the
>>> JBoss Modules artifact features, but here was my vision:
>>> 
>>> * maven repos would become to Wildfly as /lib /usr/local/lib directory
>>> structures are to unix.
>>> * The JBoss Module artifact feature would become the preferred way to
>>> deploy Wildfly/JBoss. This would make it really easy to support multiple
>>> versions as well as different distro's of JBoss/Wildfly on the same
>>> machine and save huge amounts of disk space. If we could get a JVM that
>>> could share JAR instances between processes to save on RAM, the win
>>> would be even bigger! Think of the cloud implications!
>> 
>> I think we would need some kind of tool to make sure that a repo is
>> fully downloaded if people wanted to use this in production. Even though
>> download on demand is cool, you would not want a production server
>> hanging as it attempts to download a jar. Not sure what sort of form
>> this tool would take.
>> 
>> Stuart
>> 
>>> * JBoss Module definitions could eventually be defined in one large XML
>>> file. We would have maven/ant plugins to help build this large XML file.
>>> * This single JBoss Module XML file could be bundled within a
>>> JBoss/Wildfly "executable jar".
>>> * This "executable jar" could be overlayed with external JBoss Module
>>> XML files or directory structures.
>>> * Finally, you could create this "executable jar" for any Java project.
>>> 
>>> 
>>> 
>>> 
>>> On 3/4/2014 1:37 AM, Stuart Douglas wrote:
>>>> I have made a start on this split, and I think the solution I am working
>>>> on will meet all the use cases, including users that want to cut down an
>>>> existing server, and users that want to re-use the jars in their maven
>>>> repo using Bill's changes to JBoss Modules. It still needs a bit more
>>>> work and a lot of cleanup, however it seems to work:
>>>> 
>>>> https://github.com/stuartwdouglas/wildfly/compare/wildfly-build-plugin
>>>> 
>>>> So basically the core of it is a maven plugin that builds a Wildfly
>>>> distribution, either from scratch or use other distributions as a base.
>>>> 
>>>> It also supports building servers that use the new <artifact>
>>>> functionality in jboss modules, and cutting down an existing server into
>>>> a smaller server with only the specified modules (and their transitive
>>>> dependencies).
>>>> 
>>>> The way this will work in practice is that each Wildfly sub project will
>>>> produce two different server artifacts, one of which is a server without
>>>> any jars using artifact references, and a more traditional version with
>>>> jars packaged in the module directory. Downstream projects will consume
>>>> the smaller version without all the jars, so when a version changes the
>>>> download should be less than 5mb rather than larger than 100mb (the
>>>> plugin has the ability to turn a server that uses artifact references
>>>> into a server that contains the jars in the modules dir).
>>>> 
>>>> Basically the upshot is that it should be basically possible to build
>>>> whatever configuration of server you want once this is part of our build
>>>> process, and we should also be publishing lightweight server artifacts
>>>> that use the jars in the maven repo as well as our traditional
>>>> 'everything and the kitchen sink' build.
>>>> 
>>>> It is anticipated that 3rd party projects build on Wildfly would also
>>>> use this plugin (I think at the moment the standard approach has been to
>>>> copy and modify our ant scripts).
>>>> 
>>>> This is still very much a work in progress, so nothing is set in stone
>>>> yet and any comments are welcome.
>>>> 
>>>> Stuart
>>>> 
>>>> 
>>>> Bill Burke wrote:
>>>>> A lot of users want that ability, would you rather have them roll Netty
>>>>> + whatever?
>>>>> 
>>>>> On 2/23/2014 9:10 PM, Stuart Douglas wrote:
>>>>>> No, because that means we essentially have to support and test every
>>>>>> possible combination that someone might select.
>>>>>> 
>>>>>> Stuart
>>>>>> 
>>>>>> 
>>>>>> On Mon, Feb 24, 2014 at 7:13 AM, Misty Stanley-Jones<misty at redhat.com
>>>>>> <mailto:misty at redhat.com>> wrote:
>>>>>> 
>>>>>> I know you guys aren?t there yet, but can we think about wrapping a
>>>>>> GUI around this, so that the developer only needs to tick the boxes
>>>>>> for what he does/doesn?t want, with dependencies sorted out
>>>>>> automatically? Maybe some default profiles that select a group of
>>>>>> things, but the ability to go in and add or remove individual
>>>>>> subsystems as needed? Maybe this could be part of the installer but
>>>>>> could optionally be run post-install as well.
>>>>>> 
>>>>>> On Feb 22, 2014, at 2:01 AM, Brian Stansberry
>>>>>> <brian.stansberry at redhat.com<mailto:brian.stansberry at redhat.com>>
>>>>>> wrote:
>>>>>> 
>>>>>>> When I said "Web" I meant the thing described on that wiki
>>>>>> page Tomaz
>>>>>>> linked:
>>>>>>> 
>>>>>>> "Web
>>>>>>> 
>>>>>>> Undertow subsystem, and all related dependencies, including
>>>>>> a small
>>>>>>> subset of EE and JNDI. This is basically just a Servlet
>>>>>> container, and
>>>>>>> will provide a platform for people that want to create web
>>>>>> based
>>>>>>> appliances or applications, and don't need all the additional
>>>>>>> functionality that Wildfly provides. We should end up with
>>>>>> something as
>>>>>>> lightweight as Tomcat or Jetty, but with all our advanced
>>>>>> management
>>>>>>> functionality."
>>>>>>> 
>>>>>>> On 2/21/14, 9:40 AM, Bill Burke wrote:
>>>>>>>> Its also "Web" minus some stuff. For my project I want just
>>>>>> Servlet,
>>>>>>>> JAX-RS, JPA, and datasources. Its very very hard to
>>>>>> figure out
>>>>>> how to
>>>>>>>> remove a subsystem and all its associated modules.
>>>>>>>> 
>>>>>>>> BTW, I think my maven artifact thing got into JBoss
>>>>>> Modules. So it
>>>>>>>> would be possible to load jars on demand, or at least use
>>>>>> it as
>>>>>> a way to
>>>>>>>> figure out which modules aren't being used ;).
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 2/21/2014 10:22 AM, Brian Stansberry wrote:
>>>>>>>>> This will move things in the right direction, but not all the
>>>>>> way there
>>>>>>>>> yet. Note the set of capabilities Bill mention: web, CDI,
>>>>>> JAX-RS, JPA.
>>>>>>>>> That sounds like our "Web" variant, plus some stuff. It's the
>>>>>> easy "plus
>>>>>>>>> some stuff" part that needs sorting at some point.
>>>>>>>>> 
>>>>>>>>> On 2/21/14, 9:08 AM, Toma? Cerar wrote:
>>>>>>>>>> Bill,
>>>>>>>>>> 
>>>>>>>>>> that is exactly idea we have in mind of 9.
>>>>>>>>>> We already started with producing WildFly core
>>>>>> distribution in
>>>>>> that is
>>>>>>>>>> WildFly with no subsystems, upon which you can build you own
>>>>>> wildfly.
>>>>>>>>>> It is only 15mb and contains whole mgmt capabilites (CLI,
>>>>>> standalone,
>>>>>>>>>> domain,...) you can grab it at:
>>>>>>>>>> 
>>>>>> 
>>>>>> http://download.jboss.org/wildfly/8.0.0.Final/core/wildfly-core-8.0.0.Final.zip
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> For 9 we have plans to move things bit further and have
>>>>>> decided that we
>>>>>>>>>> will also do split codebase for core, ee, web, .. and other
>>>>>> distributions.
>>>>>>>>>> 
>>>>>>>>>> Current idea on code split up is here
>>>>>>>>>> 
>>>>>> https://community.jboss.org/wiki/SplittingUpTheWildflyCodeBase
>>>>>>>>>> 
>>>>>>>>>> --
>>>>>>>>>> tomaz
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Fri, Feb 21, 2014 at 3:00 PM, Bill
>>>>>> Burke<bburke at redhat.com
>>>>>> <mailto:bburke at redhat.com>
>>>>>>>>>> <mailto:bburke at redhat.com<mailto:bburke at redhat.com>>>
>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> On Resteasy list I have a few people "rolling their own
>>>>>> app server"
>>>>>>>>>> using Netty, Weld, Resteasy and JPA. I asked one of
>>>>>> them
>>>>>> "I don't
>>>>>>>>>> understand why you are rolling your own app server"
>>>>>> response:
>>>>>>>>>> 
>>>>>>>>>> "It's actually a lot more lightweight. The minimum
>>>>>> I can
>>>>>> run the
>>>>>>>>>> equivalent on AS7 on is ~ 180 mb in binaries, but
>>>>>> throwing this
>>>>>>>>>> together is about 32 mb (and compresses further when
>>>>>> its
>>>>>> packaged).
>>>>>>>>>> I'm able to start the JVM on the bare minimum
>>>>>> (~100mb on
>>>>>> my linux VM)
>>>>>>>>>> but AS7 with all I need is about 756mb. When
>>>>>> rolling out
>>>>>> in the
>>>>>>>>>> cloud, where all of my REST APIs are stateless, running
>>>>>> with this
>>>>>>>>>> configuration helps us get a lot more per node."
>>>>>>>>>> 
>>>>>>>>>> I'm not complaining :), just something to think
>>>>>> about. It
>>>>>> might be
>>>>>>>>>> really valuable to focus a bit in Wildfly 9 to make it
>>>>>> easier to create
>>>>>>>>>> custom profiles or even different packaging options for
>>>>>> the app server
>>>>>>>>>> instead of the exploded style we currently have.
>>>>>>>>>> --
>>>>>>>>>> Bill Burke
>>>>>>>>>> JBoss, a division of Red Hat
>>>>>>>>>> http://bill.burkecentral.com
>>>>>>>>>> _______________________________________________
>>>>>>>>>> wildfly-dev mailing list
>>>>>>>>>> wildfly-dev at lists.jboss.org
>>>>>> <mailto:wildfly-dev at lists.jboss.org>
>>>>>> <mailto:wildfly-dev at lists.jboss.org
>>>>>> <mailto:wildfly-dev at lists.jboss.org>>
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> _______________________________________________
>>>>>>>>>> wildfly-dev mailing list
>>>>>>>>>> 
>>>>>> wildfly-dev at lists.jboss.org<mailto:wildfly-dev at lists.jboss.org>
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Brian Stansberry
>>>>>>> Senior Principal Software Engineer
>>>>>>> JBoss by Red Hat
>>>>>>> _______________________________________________
>>>>>>> wildfly-dev mailing list
>>>>>>> wildfly-dev at lists.jboss.org<mailto:wildfly-dev at lists.jboss.org>
>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>> 
>>>>>> Misty Stanley-Jones, RHCE
>>>>>> Manager, Content Services (Middleware)
>>>>>> Direct: + 61 7 3514 8105<tel:%2B%2061%207%203514%208105> / Mobile:
>>>>>> +61 429 595 932<tel:%2B61%20429%20595%20932> (TZ: GMT+10)
>>>>>> IRC: misty (Freenode / RH)
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> wildfly-dev mailing list
>>>>>> wildfly-dev at lists.jboss.org<mailto:wildfly-dev at lists.jboss.org>
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> wildfly-dev mailing list
>>>>>> wildfly-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

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



From stuart.w.douglas at gmail.com  Mon Mar 10 16:19:43 2014
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Tue, 11 Mar 2014 07:19:43 +1100
Subject: [wildfly-dev] smaller footprints
In-Reply-To: <C47B4EF9-880F-4399-A8BE-D3D80905BE00@redhat.com>
References: <53075BEA.8030608@redhat.com>	<CAMquZP4RPXFgAPsCnnOLvH=XTkeQJ2bno5ms5yimD3gK6erkbw@mail.gmail.com>	<53076F18.3020603@redhat.com>
	<5307737C.2080603@redhat.com>	<53077867.3050600@redhat.com>	<3807F2B2-87E9-43F8-9A5C-E60340C748FF@redhat.com>
	<CAAoo=c7rWYObqRGQN2g34PR0bdP6YLeFCaoi3E5f7PuMQkav7Q@mail.gmail.com>
	<530B508F.5040409@redhat.com> <531574B1.5080404@gmail.com>
	<5315E4AA.1070603@redhat.com> <53164297.8020405@gmail.com>
	<5316AE5E.8050708@gmail.com>
	<C47B4EF9-880F-4399-A8BE-D3D80905BE00@redhat.com>
Message-ID: <531E1E5F.40500@gmail.com>

I was just talking about the naming pattern and picked a few examples. I 
was not suggesting that these are all the modules we would have.

Stuart

Jason Greene wrote:
> In the original plan/writeup we had a separate clustering layer and EE layer. I guess the biggest limiting factor for those is cleaning up our dependencies.
>
> On Mar 5, 2014, at 4:55 AM, Stuart Douglas<stuart.w.douglas at gmail.com>  wrote:
>
>> So now onto one of the hard problems, naming things...
>>
>> As a result of splitting up the server we are going to end up with a lot
>> more artifacts. Basically each repo will produce at least two servers, a
>> cut down server that uses the maven repo and a full server that is
>> similar to what we have at the moment, and we are going to need some
>> kind of consistent name for them.
>>
>> I am thinking maybe something like:
>>
>> wildfly-core-build (cut down server core build)
>> wildfly-core-build-dist (core + all jars)
>> wildfly-web-build (cut down wildfly server with just the Undertow subsystem)
>> wildfly-web-build-dist (as above, but with jars)
>> wildfly-build (cut down full server)
>> wildfly-build-dist (as above)
>>
>> Does anyone have any better ideas about what to call this stuff?
>>
>> One side effect of the above would be that the build directory will no
>> longer contain the full Wildfly server (just a version with no jars
>> present), and the full server would be in the dist directory instead.
>>
>> Stuart
>>
>> Stuart Douglas wrote:
>>>
>>> Bill Burke wrote:
>>>> Great work Stuart! I'm really happy somebody is taking initiative on
>>>> this because I really think it will help a lot with Wildfly adoption. Is
>>>> it ready to use? I'm willing to try it out RIGHT NOW.
>>> Sort of. You can build from my wildfly-build-plugin branch and it should
>>> work, but at the moment it is creating a build that includes all the
>>> jars. If you want to create a build that uses<artifact>  you will need
>>> to modify the copy-module-artifacts attribute in ./build/server-build.xml .
>>>
>>> Eventually we will produce both versions, I should get to this some time
>>> today.
>>>
>>> Also this is very new, and may not work, but if you want to try it out
>>> feel free. Hopefully I will have something a lot more polished by the
>>> end of the week.
>>>
>>>> I've expressed some of these thoughts months ago when I introduced the
>>>> JBoss Modules artifact features, but here was my vision:
>>>>
>>>> * maven repos would become to Wildfly as /lib /usr/local/lib directory
>>>> structures are to unix.
>>>> * The JBoss Module artifact feature would become the preferred way to
>>>> deploy Wildfly/JBoss. This would make it really easy to support multiple
>>>> versions as well as different distro's of JBoss/Wildfly on the same
>>>> machine and save huge amounts of disk space. If we could get a JVM that
>>>> could share JAR instances between processes to save on RAM, the win
>>>> would be even bigger! Think of the cloud implications!
>>> I think we would need some kind of tool to make sure that a repo is
>>> fully downloaded if people wanted to use this in production. Even though
>>> download on demand is cool, you would not want a production server
>>> hanging as it attempts to download a jar. Not sure what sort of form
>>> this tool would take.
>>>
>>> Stuart
>>>
>>>> * JBoss Module definitions could eventually be defined in one large XML
>>>> file. We would have maven/ant plugins to help build this large XML file.
>>>> * This single JBoss Module XML file could be bundled within a
>>>> JBoss/Wildfly "executable jar".
>>>> * This "executable jar" could be overlayed with external JBoss Module
>>>> XML files or directory structures.
>>>> * Finally, you could create this "executable jar" for any Java project.
>>>>
>>>>
>>>>
>>>>
>>>> On 3/4/2014 1:37 AM, Stuart Douglas wrote:
>>>>> I have made a start on this split, and I think the solution I am working
>>>>> on will meet all the use cases, including users that want to cut down an
>>>>> existing server, and users that want to re-use the jars in their maven
>>>>> repo using Bill's changes to JBoss Modules. It still needs a bit more
>>>>> work and a lot of cleanup, however it seems to work:
>>>>>
>>>>> https://github.com/stuartwdouglas/wildfly/compare/wildfly-build-plugin
>>>>>
>>>>> So basically the core of it is a maven plugin that builds a Wildfly
>>>>> distribution, either from scratch or use other distributions as a base.
>>>>>
>>>>> It also supports building servers that use the new<artifact>
>>>>> functionality in jboss modules, and cutting down an existing server into
>>>>> a smaller server with only the specified modules (and their transitive
>>>>> dependencies).
>>>>>
>>>>> The way this will work in practice is that each Wildfly sub project will
>>>>> produce two different server artifacts, one of which is a server without
>>>>> any jars using artifact references, and a more traditional version with
>>>>> jars packaged in the module directory. Downstream projects will consume
>>>>> the smaller version without all the jars, so when a version changes the
>>>>> download should be less than 5mb rather than larger than 100mb (the
>>>>> plugin has the ability to turn a server that uses artifact references
>>>>> into a server that contains the jars in the modules dir).
>>>>>
>>>>> Basically the upshot is that it should be basically possible to build
>>>>> whatever configuration of server you want once this is part of our build
>>>>> process, and we should also be publishing lightweight server artifacts
>>>>> that use the jars in the maven repo as well as our traditional
>>>>> 'everything and the kitchen sink' build.
>>>>>
>>>>> It is anticipated that 3rd party projects build on Wildfly would also
>>>>> use this plugin (I think at the moment the standard approach has been to
>>>>> copy and modify our ant scripts).
>>>>>
>>>>> This is still very much a work in progress, so nothing is set in stone
>>>>> yet and any comments are welcome.
>>>>>
>>>>> Stuart
>>>>>
>>>>>
>>>>> Bill Burke wrote:
>>>>>> A lot of users want that ability, would you rather have them roll Netty
>>>>>> + whatever?
>>>>>>
>>>>>> On 2/23/2014 9:10 PM, Stuart Douglas wrote:
>>>>>>> No, because that means we essentially have to support and test every
>>>>>>> possible combination that someone might select.
>>>>>>>
>>>>>>> Stuart
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Feb 24, 2014 at 7:13 AM, Misty Stanley-Jones<misty at redhat.com
>>>>>>> <mailto:misty at redhat.com>>  wrote:
>>>>>>>
>>>>>>> I know you guys aren?t there yet, but can we think about wrapping a
>>>>>>> GUI around this, so that the developer only needs to tick the boxes
>>>>>>> for what he does/doesn?t want, with dependencies sorted out
>>>>>>> automatically? Maybe some default profiles that select a group of
>>>>>>> things, but the ability to go in and add or remove individual
>>>>>>> subsystems as needed? Maybe this could be part of the installer but
>>>>>>> could optionally be run post-install as well.
>>>>>>>
>>>>>>> On Feb 22, 2014, at 2:01 AM, Brian Stansberry
>>>>>>> <brian.stansberry at redhat.com<mailto:brian.stansberry at redhat.com>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> When I said "Web" I meant the thing described on that wiki
>>>>>>> page Tomaz
>>>>>>>> linked:
>>>>>>>>
>>>>>>>> "Web
>>>>>>>>
>>>>>>>> Undertow subsystem, and all related dependencies, including
>>>>>>> a small
>>>>>>>> subset of EE and JNDI. This is basically just a Servlet
>>>>>>> container, and
>>>>>>>> will provide a platform for people that want to create web
>>>>>>> based
>>>>>>>> appliances or applications, and don't need all the additional
>>>>>>>> functionality that Wildfly provides. We should end up with
>>>>>>> something as
>>>>>>>> lightweight as Tomcat or Jetty, but with all our advanced
>>>>>>> management
>>>>>>>> functionality."
>>>>>>>>
>>>>>>>> On 2/21/14, 9:40 AM, Bill Burke wrote:
>>>>>>>>> Its also "Web" minus some stuff. For my project I want just
>>>>>>> Servlet,
>>>>>>>>> JAX-RS, JPA, and datasources. Its very very hard to
>>>>>>> figure out
>>>>>>> how to
>>>>>>>>> remove a subsystem and all its associated modules.
>>>>>>>>>
>>>>>>>>> BTW, I think my maven artifact thing got into JBoss
>>>>>>> Modules. So it
>>>>>>>>> would be possible to load jars on demand, or at least use
>>>>>>> it as
>>>>>>> a way to
>>>>>>>>> figure out which modules aren't being used ;).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 2/21/2014 10:22 AM, Brian Stansberry wrote:
>>>>>>>>>> This will move things in the right direction, but not all the
>>>>>>> way there
>>>>>>>>>> yet. Note the set of capabilities Bill mention: web, CDI,
>>>>>>> JAX-RS, JPA.
>>>>>>>>>> That sounds like our "Web" variant, plus some stuff. It's the
>>>>>>> easy "plus
>>>>>>>>>> some stuff" part that needs sorting at some point.
>>>>>>>>>>
>>>>>>>>>> On 2/21/14, 9:08 AM, Toma? Cerar wrote:
>>>>>>>>>>> Bill,
>>>>>>>>>>>
>>>>>>>>>>> that is exactly idea we have in mind of 9.
>>>>>>>>>>> We already started with producing WildFly core
>>>>>>> distribution in
>>>>>>> that is
>>>>>>>>>>> WildFly with no subsystems, upon which you can build you own
>>>>>>> wildfly.
>>>>>>>>>>> It is only 15mb and contains whole mgmt capabilites (CLI,
>>>>>>> standalone,
>>>>>>>>>>> domain,...) you can grab it at:
>>>>>>>>>>>
>>>>>>> http://download.jboss.org/wildfly/8.0.0.Final/core/wildfly-core-8.0.0.Final.zip
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>> For 9 we have plans to move things bit further and have
>>>>>>> decided that we
>>>>>>>>>>> will also do split codebase for core, ee, web, .. and other
>>>>>>> distributions.
>>>>>>>>>>> Current idea on code split up is here
>>>>>>>>>>>
>>>>>>> https://community.jboss.org/wiki/SplittingUpTheWildflyCodeBase
>>>>>>>>>>> --
>>>>>>>>>>> tomaz
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Feb 21, 2014 at 3:00 PM, Bill
>>>>>>> Burke<bburke at redhat.com
>>>>>>> <mailto:bburke at redhat.com>
>>>>>>>>>>> <mailto:bburke at redhat.com<mailto:bburke at redhat.com>>>
>>>>>>> wrote:
>>>>>>>>>>> On Resteasy list I have a few people "rolling their own
>>>>>>> app server"
>>>>>>>>>>> using Netty, Weld, Resteasy and JPA. I asked one of
>>>>>>> them
>>>>>>> "I don't
>>>>>>>>>>> understand why you are rolling your own app server"
>>>>>>> response:
>>>>>>>>>>> "It's actually a lot more lightweight. The minimum
>>>>>>> I can
>>>>>>> run the
>>>>>>>>>>> equivalent on AS7 on is ~ 180 mb in binaries, but
>>>>>>> throwing this
>>>>>>>>>>> together is about 32 mb (and compresses further when
>>>>>>> its
>>>>>>> packaged).
>>>>>>>>>>> I'm able to start the JVM on the bare minimum
>>>>>>> (~100mb on
>>>>>>> my linux VM)
>>>>>>>>>>> but AS7 with all I need is about 756mb. When
>>>>>>> rolling out
>>>>>>> in the
>>>>>>>>>>> cloud, where all of my REST APIs are stateless, running
>>>>>>> with this
>>>>>>>>>>> configuration helps us get a lot more per node."
>>>>>>>>>>>
>>>>>>>>>>> I'm not complaining :), just something to think
>>>>>>> about. It
>>>>>>> might be
>>>>>>>>>>> really valuable to focus a bit in Wildfly 9 to make it
>>>>>>> easier to create
>>>>>>>>>>> custom profiles or even different packaging options for
>>>>>>> the app server
>>>>>>>>>>> instead of the exploded style we currently have.
>>>>>>>>>>> --
>>>>>>>>>>> Bill Burke
>>>>>>>>>>> JBoss, a division of Red Hat
>>>>>>>>>>> http://bill.burkecentral.com
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> wildfly-dev mailing list
>>>>>>>>>>> wildfly-dev at lists.jboss.org
>>>>>>> <mailto:wildfly-dev at lists.jboss.org>
>>>>>>> <mailto:wildfly-dev at lists.jboss.org
>>>>>>> <mailto:wildfly-dev at lists.jboss.org>>
>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> wildfly-dev mailing list
>>>>>>>>>>>
>>>>>>> wildfly-dev at lists.jboss.org<mailto:wildfly-dev at lists.jboss.org>
>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Brian Stansberry
>>>>>>>> Senior Principal Software Engineer
>>>>>>>> JBoss by Red Hat
>>>>>>>> _______________________________________________
>>>>>>>> wildfly-dev mailing list
>>>>>>>> wildfly-dev at lists.jboss.org<mailto:wildfly-dev at lists.jboss.org>
>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>> Misty Stanley-Jones, RHCE
>>>>>>> Manager, Content Services (Middleware)
>>>>>>> Direct: + 61 7 3514 8105<tel:%2B%2061%207%203514%208105>  / Mobile:
>>>>>>> +61 429 595 932<tel:%2B61%20429%20595%20932>  (TZ: GMT+10)
>>>>>>> IRC: misty (Freenode / RH)
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> wildfly-dev mailing list
>>>>>>> wildfly-dev at lists.jboss.org<mailto:wildfly-dev at lists.jboss.org>
>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> wildfly-dev mailing list
>>>>>>> wildfly-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>
>> _______________________________________________
>> 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 arun.gupta at gmail.com  Tue Mar 11 19:35:42 2014
From: arun.gupta at gmail.com (Arun Gupta)
Date: Tue, 11 Mar 2014 16:35:42 -0700
Subject: [wildfly-dev] Clustering in WildFly 8
Message-ID: <CAGBoHQWGSy2z=tgvUPKiE8KRQ0mPxD6fTNSGmUY=trZi4RndTQ@mail.gmail.com>

I've started playing with clustering in WildFly 8 and been able to
create a simple sample that shows HTTP session failover.

The sample is at:

https://github.com/arun-gupta/wildfly-samples/tree/master/clustering/http

I'll be sharing a blog post on this soon.

In the mean while here is some initial feedback:

1). Starting domain.sh automatically starts two WildFly instances on
8080 and 8230. Clicking on "Administration Console" shows the message
" if you are running a domain the http interface can not be
automatically detected so check the host.xml configuration and connect
directly.".

I think this message can be improved by saying what needs to be done
in order to access the console.

2). If a WildFly instance needs to run on multiple hosts then it seems
like it needs to be manually copied over to each machine. Is there a
mechanism where a zip bundle can be sftp/ssh copied over to the remote
machine ? This would simplify setting up a cluster.

3). Changed server-two auto-start="false" and server-three
auto-start="true". Running domain.sh gives the following error:

[Server:server-three] 15:17:03,924 INFO  [org.jboss.messaging] (MSC
service thread 1-12) JBAS011615: Registered HTTP upgrade for
hornetq-remoting protocol handled by http-acceptor-throughput acceptor
[Server:server-three] 15:17:03,978 ERROR [org.hornetq.core.server]
(Thread-0 (HornetQ-scheduled-threads-45430818)) HQ224033: Failed to
broadcast connector configs: java.io.IOException: Can't assign
requested address
[Server:server-three] at java.net.PlainDatagramSocketImpl.send(Native
Method) [rt.jar:1.7.0_45]
[Server:server-three] at
java.net.DatagramSocket.send(DatagramSocket.java:676)
[rt.jar:1.7.0_45]
[Server:server-three] at
org.hornetq.api.core.UDPBroadcastGroupConfiguration$UDPBroadcastEndpoint.broadcast(UDPBroadcastGroupConfiguration.java:135)
[hornetq-core-client-2.4.1.Final.jar:]
[Server:server-three] at
org.hornetq.core.server.cluster.impl.BroadcastGroupImpl.broadcastConnectors(BroadcastGroupImpl.java:215)
[hornetq-server-2.4.1.Final.jar:]
[Server:server-three] at
org.hornetq.core.server.cluster.impl.BroadcastGroupImpl.run(BroadcastGroupImpl.java:227)
[hornetq-server-2.4.1.Final.jar:]
[Server:server-three] at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
[rt.jar:1.7.0_45]

Is there something else that needs to be configured ?

Thanks
Arun

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

From jmesnil at redhat.com  Wed Mar 12 06:04:23 2014
From: jmesnil at redhat.com (Jeff Mesnil)
Date: Wed, 12 Mar 2014 11:04:23 +0100
Subject: [wildfly-dev] Clustering in WildFly 8
In-Reply-To: <CAGBoHQWGSy2z=tgvUPKiE8KRQ0mPxD6fTNSGmUY=trZi4RndTQ@mail.gmail.com>
References: <CAGBoHQWGSy2z=tgvUPKiE8KRQ0mPxD6fTNSGmUY=trZi4RndTQ@mail.gmail.com>
Message-ID: <AC47D053-42E4-410E-9300-81ED144902AD@redhat.com>


On 12 Mar 2014, at 00:35, Arun Gupta <arun.gupta at gmail.com> wrote:
> 3). Changed server-two auto-start="false" and server-three
> auto-start="true". Running domain.sh gives the following error:
> 
> [Server:server-three] 15:17:03,924 INFO  [org.jboss.messaging] (MSC
> service thread 1-12) JBAS011615: Registered HTTP upgrade for
> hornetq-remoting protocol handled by http-acceptor-throughput acceptor
> [Server:server-three] 15:17:03,978 ERROR [org.hornetq.core.server]
> (Thread-0 (HornetQ-scheduled-threads-45430818)) HQ224033: Failed to
> broadcast connector configs: java.io.IOException: Can't assign
> requested address
> 
> Is there something else that needs to be configured ?

server-two uses the full profile, server-three uses the full-ha profile that add discovery support to its hornetq-server.

This error likely occurs when you run multiple host on the same machine: https://community.jboss.org/wiki/RunningAHornetQClusterUsingDiscoveryDoesntWork
To use this setup, you need to add a multicast route to the loopback interface (on my mac, I have to run "sudo route add 224.0.0.0 127.0.0.1 -netmask 240.0.0.0"

jeff

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



From bburke at redhat.com  Wed Mar 12 09:16:26 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 12 Mar 2014 09:16:26 -0400
Subject: [wildfly-dev] inheriting security domain
Message-ID: <53205E2A.7030700@redhat.com>

I noticed that if you define a WAR's security domain and then define an 
EJB within WEB-INF/classes, that EJB's default security domain is 
"other" and not the WAR's security domain.

Don't you think it would be more user friendly and intuitive for nested 
components' security domain to be inherited from their parent container 
rather than defaulting to "other"?


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From Anil.Saldhana at redhat.com  Wed Mar 12 10:39:45 2014
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Wed, 12 Mar 2014 09:39:45 -0500
Subject: [wildfly-dev] inheriting security domain
In-Reply-To: <53205E2A.7030700@redhat.com>
References: <53205E2A.7030700@redhat.com>
Message-ID: <532071B1.1050202@redhat.com>

It is subjective about assuming reasonable defaults.

In the case of EARs, historically, we used the security domain
at the EAR level for all the containing web,ejbs that were missing 
explicit security domains.

A security domain is an abstract concept to define boundaries for 
authentication, authorization, mapping,audit etc.
So a web app may use different security domain compared to an EJB 
application.

In the case of web archives containing EJB applications, the options are:
a) Make the EJB define the security domain explicitly to be the one used 
by the web app.
b) Make the EJB inherit the security domain used by the web app if missing.
c) Make the EJB default to "other" if a security domain is missing.

If we go with c) like it is now, a developer can test his application 
and see that his EJB application is not working
as he intends. Then he can either opt for a) or leave it as c)

The danger with option b) is if someone put the war in production and 
the EJB application does not 'fail fast'.

But if people on this list feel that b) is the better usable solution, 
then we should go for it.

On 03/12/2014 08:16 AM, Bill Burke wrote:
> I noticed that if you define a WAR's security domain and then define an
> EJB within WEB-INF/classes, that EJB's default security domain is
> "other" and not the WAR's security domain.
>
> Don't you think it would be more user friendly and intuitive for nested
> components' security domain to be inherited from their parent container
> rather than defaulting to "other"?
>
>


From jgreene at redhat.com  Wed Mar 12 12:20:09 2014
From: jgreene at redhat.com (Jason T. Greene)
Date: Wed, 12 Mar 2014 12:20:09 -0400 (EDT)
Subject: [wildfly-dev] inheriting security domain
In-Reply-To: <532071B1.1050202@redhat.com>
References: <53205E2A.7030700@redhat.com> <532071B1.1050202@redhat.com>
Message-ID: <F97E76D1-78CB-410B-8E12-A2FBDDEA73D7@redhat.com>

I see your point, but I have to agree with Bill that it's not what a user expects. We should let DUPs push/pop the specified domain in an attachment.

Sent from my iPhone

> On Mar 12, 2014, at 2:40 PM, Anil Saldhana <Anil.Saldhana at redhat.com> wrote:
> 
> It is subjective about assuming reasonable defaults.
> 
> In the case of EARs, historically, we used the security domain
> at the EAR level for all the containing web,ejbs that were missing 
> explicit security domains.
> 
> A security domain is an abstract concept to define boundaries for 
> authentication, authorization, mapping,audit etc.
> So a web app may use different security domain compared to an EJB 
> application.
> 
> In the case of web archives containing EJB applications, the options are:
> a) Make the EJB define the security domain explicitly to be the one used 
> by the web app.
> b) Make the EJB inherit the security domain used by the web app if missing.
> c) Make the EJB default to "other" if a security domain is missing.
> 
> If we go with c) like it is now, a developer can test his application 
> and see that his EJB application is not working
> as he intends. Then he can either opt for a) or leave it as c)
> 
> The danger with option b) is if someone put the war in production and 
> the EJB application does not 'fail fast'.
> 
> But if people on this list feel that b) is the better usable solution, 
> then we should go for it.
> 
>> On 03/12/2014 08:16 AM, Bill Burke wrote:
>> I noticed that if you define a WAR's security domain and then define an
>> EJB within WEB-INF/classes, that EJB's default security domain is
>> "other" and not the WAR's security domain.
>> 
>> Don't you think it would be more user friendly and intuitive for nested
>> components' security domain to be inherited from their parent container
>> rather than defaulting to "other"?
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From cristiano.s.andrade at gmail.com  Wed Mar 12 18:47:06 2014
From: cristiano.s.andrade at gmail.com (Cristiano Andrade)
Date: Wed, 12 Mar 2014 19:47:06 -0300
Subject: [wildfly-dev] Clustering with CLIENT-CERT auth Jaas
Message-ID: <5320E3EA.700@gmail.com>

Hi,

Someone here already configured a Wildfly cluster with client-cert auth ?

I tried, but no sucess, wildfly always throw a 403 http message on first 
request.  When I press f5 it works.

Tks

Cristiano


From johara at redhat.com  Thu Mar 13 11:09:35 2014
From: johara at redhat.com (John O'Hara)
Date: Thu, 13 Mar 2014 15:09:35 +0000
Subject: [wildfly-dev] [jboss-as7-dev] Domain mode server launch command
In-Reply-To: <531A1747.8050901@redhat.com>
References: <502A81B2.8040607@redhat.com>
	<502A84CC.8070302@redhat.com>	<502A8AB8.7040803@redhat.com>
	<502A9589.4030601@redhat.com>	<502BD08A.2060409@redhat.com>	<C99FEE03-30C6-4A25-9755-41366B1F0CEE@jboss.com>	<502C6057.1020602@redhat.com>
	<503CD14A.10509@redhat.com>	<A11B26BD-C4E0-4D7A-AF01-5D583F267ABE@jboss.com>	<503E1B90.4030702@redhat.com>
	<503F40D6.4040102@redhat.com> <5310F8DA.50507@redhat.com>
	<53110D44.6030203@redhat.com> <5314C97D.6070604@redhat.com>
	<53182B56.3020808@redhat.com> <5318B26F.6020206@redhat.com>
	<53199C33.3050407@redhat.com> <531A1747.8050901@redhat.com>
Message-ID: <5321CA2F.30003@redhat.com>

Brian,

Has there been any feedback on this so far?

Thanks

John

On 03/07/2014 07:00 PM, Brian Stansberry wrote:
> Hi John,
>
> I copied the wildfly-dev list.
>
> I prefer the <jvm> approach. We already have logic for combining jvm 
> configs set at different levels (server-group, host, server) so people 
> can set this at whatever level they prefer, and then if they want 
> something different for a particular server they can override.
>
> Cheers,
>
> - Brian
>
> On 3/7/14, 4:15 AM, John O'Hara wrote:
>> Brian,
>>
>> I was talking to Kabir about incorporating this feature into the
>> host-controller model. We discussed different options for places to
>> define the launch command, and we came to the conclusion that it could
>> be placed in one of two locations in host.xml. The options discussed 
>> were;
>>
>>  1. Incorporate the command as an attribute of the existing <jvm>
>>     element. This would allow for the same lanuch command to be applied
>>     to all servers in the domain and only have to define it once e.g.
>>     running the server process under a different user id.  The launch
>>     command can also be overwritten or defined for each server allowing
>>     separate launch commands for each server e.g. pinning jvm to
>>     particular numa nodes.
>>  2. Creating a new <server-launch-command> element under the <server>
>>     elements. Users would need to define the server launch command for
>>     each server separately.
>>
>> I had originally defined the host schema with a <server-launch-command>
>> element under the <server>element.  However, it might provide more
>> flexibility to define the launch command in the <jvm> element.
>>
>> Kabir suggested that I run this by you, so your thoughts on where to
>> define this in hosts.xml would be greatly appreciated.
>>
>> Thanks
>>
>> John
>


-- 
John O'Hara
johara at redhat.com

JBoss, by Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Brendan Lane (Ireland).


From brian.stansberry at redhat.com  Thu Mar 13 11:19:22 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 13 Mar 2014 15:19:22 +0000
Subject: [wildfly-dev] [jboss-as7-dev] Domain mode server launch command
In-Reply-To: <5321CA2F.30003@redhat.com>
References: <502A81B2.8040607@redhat.com>
	<502A84CC.8070302@redhat.com>	<502A8AB8.7040803@redhat.com>
	<502A9589.4030601@redhat.com>	<502BD08A.2060409@redhat.com>	<C99FEE03-30C6-4A25-9755-41366B1F0CEE@jboss.com>	<502C6057.1020602@redhat.com>
	<503CD14A.10509@redhat.com>	<A11B26BD-C4E0-4D7A-AF01-5D583F267ABE@jboss.com>	<503E1B90.4030702@redhat.com>
	<503F40D6.4040102@redhat.com> <5310F8DA.50507@redhat.com>
	<53110D44.6030203@redhat.com> <5314C97D.6070604@redhat.com>
	<53182B56.3020808@redhat.com> <5318B26F.6020206@redhat.com>
	<53199C33.3050407@redhat.com> <531A1747.8050901@redhat.com>
	<5321CA2F.30003@redhat.com>
Message-ID: <5321CC7A.1000704@redhat.com>

No other feedback, so let's go with the <jvm> approach.

On 3/13/14, 3:09 PM, John O'Hara wrote:
> Brian,
>
> Has there been any feedback on this so far?
>
> Thanks
>
> John
>
> On 03/07/2014 07:00 PM, Brian Stansberry wrote:
>> Hi John,
>>
>> I copied the wildfly-dev list.
>>
>> I prefer the <jvm> approach. We already have logic for combining jvm
>> configs set at different levels (server-group, host, server) so people
>> can set this at whatever level they prefer, and then if they want
>> something different for a particular server they can override.
>>
>> Cheers,
>>
>> - Brian
>>
>> On 3/7/14, 4:15 AM, John O'Hara wrote:
>>> Brian,
>>>
>>> I was talking to Kabir about incorporating this feature into the
>>> host-controller model. We discussed different options for places to
>>> define the launch command, and we came to the conclusion that it could
>>> be placed in one of two locations in host.xml. The options discussed
>>> were;
>>>
>>>  1. Incorporate the command as an attribute of the existing <jvm>
>>>     element. This would allow for the same lanuch command to be applied
>>>     to all servers in the domain and only have to define it once e.g.
>>>     running the server process under a different user id.  The launch
>>>     command can also be overwritten or defined for each server allowing
>>>     separate launch commands for each server e.g. pinning jvm to
>>>     particular numa nodes.
>>>  2. Creating a new <server-launch-command> element under the <server>
>>>     elements. Users would need to define the server launch command for
>>>     each server separately.
>>>
>>> I had originally defined the host schema with a <server-launch-command>
>>> element under the <server>element.  However, it might provide more
>>> flexibility to define the launch command in the <jvm> element.
>>>
>>> Kabir suggested that I run this by you, so your thoughts on where to
>>> define this in hosts.xml would be greatly appreciated.
>>>
>>> Thanks
>>>
>>> John
>>
>
>


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

From arun.gupta at gmail.com  Fri Mar 14 21:36:06 2014
From: arun.gupta at gmail.com (Arun Gupta)
Date: Fri, 14 Mar 2014 18:36:06 -0700
Subject: [wildfly-dev] Node determination in WildFly cluster
Message-ID: <CAGBoHQXVjFAgRxvrxsR294HL7A-B8_3c0f3ygjPT7FgScTJY=Q@mail.gmail.com>

Couple of questions on WildFly clustering ...

- How is the node for session replication determined ? Is that configurable ?

- How many nodes is the session replicated to ?

Arun

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

From Anil.Saldhana at redhat.com  Mon Mar 17 09:59:41 2014
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Mon, 17 Mar 2014 08:59:41 -0500
Subject: [wildfly-dev] inheriting security domain
In-Reply-To: <F97E76D1-78CB-410B-8E12-A2FBDDEA73D7@redhat.com>
References: <53205E2A.7030700@redhat.com> <532071B1.1050202@redhat.com>
	<F97E76D1-78CB-410B-8E12-A2FBDDEA73D7@redhat.com>
Message-ID: <5326FFCD.7050704@redhat.com>

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

On 03/12/2014 11:20 AM, Jason T. Greene wrote:
> I see your point, but I have to agree with Bill that it's not what a user expects. We should let DUPs push/pop the specified domain in an attachment.
>
> Sent from my iPhone
>
>> On Mar 12, 2014, at 2:40 PM, Anil Saldhana <Anil.Saldhana at redhat.com> wrote:
>>
>> It is subjective about assuming reasonable defaults.
>>
>> In the case of EARs, historically, we used the security domain
>> at the EAR level for all the containing web,ejbs that were missing
>> explicit security domains.
>>
>> A security domain is an abstract concept to define boundaries for
>> authentication, authorization, mapping,audit etc.
>> So a web app may use different security domain compared to an EJB
>> application.
>>
>> In the case of web archives containing EJB applications, the options are:
>> a) Make the EJB define the security domain explicitly to be the one used
>> by the web app.
>> b) Make the EJB inherit the security domain used by the web app if missing.
>> c) Make the EJB default to "other" if a security domain is missing.
>>
>> If we go with c) like it is now, a developer can test his application
>> and see that his EJB application is not working
>> as he intends. Then he can either opt for a) or leave it as c)
>>
>> The danger with option b) is if someone put the war in production and
>> the EJB application does not 'fail fast'.
>>
>> But if people on this list feel that b) is the better usable solution,
>> then we should go for it.
>>
>>> On 03/12/2014 08:16 AM, Bill Burke wrote:
>>> I noticed that if you define a WAR's security domain and then define an
>>> EJB within WEB-INF/classes, that EJB's default security domain is
>>> "other" and not the WAR's security domain.
>>>
>>> Don't you think it would be more user friendly and intuitive for nested
>>> components' security domain to be inherited from their parent container
>>> rather than defaulting to "other"?
>>

From david.lloyd at redhat.com  Mon Mar 17 14:54:26 2014
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Mon, 17 Mar 2014 13:54:26 -0500
Subject: [wildfly-dev] Thoughts on alternative security managers
Message-ID: <532744E2.3040909@redhat.com>

It is possible to implement a security manager which behaves differently 
than the default AccessController-based security manager.  I am 
wondering if we should maybe explore some options here.

AccessControlContext (ACC) permission checks are expensive.  The 
assembled context can consist of many object instances, many of which 
may be constructed on the fly, in order to check a permission against 
every invocation frame on the call stack (including going through thread 
start points to earlier, snapshotted thread stacks) down to the most 
recent doPrivileged() invocation.  The theory is to ensure that 
permissions can never escalate without an explicit action.  However, few 
frameworks use doPrivileged() properly, resulting in too many 
permissions being assigned to the user deployment anyway.

Option 0: Status quo
--------------------
To mitigate some of this cost, our current security manager has 
"checked" and "unchecked" modes for the current thread.  When running 
trusted code, we switch to "unchecked" mode which is functionally 
similar to a privileged block, except (a) it is much faster as expensive 
permission checks are simply bypassed and (b) it is the responsibility 
of the container to ensure that checked mode is re-enabled before 
calling back in to user code.

When checked mode is enabled, all permission checks happen in the usual 
way with ACC.  Privileged blocks are necessary for code that runs in 
checked mode (i.e. user libraries and many of our APIs that do not have 
direct support for WildFlySecurityManager).

Option 1: Fast and simple
-------------------------
We could completely switch the SecurityManager's (SM's) security context 
object to be a per-deployment context of some sort.  Permissions would 
be checked based on whatever deployment is currently active; checked and 
unchecked modes would still be used in this case.

In this option, the permissions that are currently checked are *always* 
the active deployment, which is particularly relevant in the case that 
the deployment calls into some other deployment without using container 
facilities.

We could still support standard security policies to assign additional 
permissions to the current Principal.

Privileged blocks in this case would be completely ignored.

This could be a very fast approach as no objects need be constructed to 
perform a permission check; however, it is also perhaps harder to create 
fine-grained restrictions on things.

Option 2: Call stack (simplified version)
-----------------------------------------
Alternatively, we could examine the call stack on each invocation to 
locate the most recent enclosing "untrusted" class loader.  This 
involves acquiring and traversing the invocation call stack (which may 
be cheaper in Java 8 or 9).  While expensive, this operation should be 
less expensive than constructing an ACC.

Privileged blocks in this case would also be completely ignored, and all 
the other above benefits would hold.  For the relative performance cost 
we would pay over Option 1, we'd regain the ability to establish 
fine-grained restrictions.

Option 3: Call stack (advanced version)
---------------------------------------
In this option we essentially duplicate what ACC does, but using the 
presumably less-expensive SM method of acquiring and examining the call 
stack.  Privileged blocks probably would not work, but if not, we'd have 
an alternative mechanism for establishing bounds on the set of 
permissions to check per call.  We would still support checked/unchecked 
mode.

All three of these options would not be compatible with DomainCombiners, 
if that matters.

Any thoughts?
-- 
- DML

From stuart.w.douglas at gmail.com  Mon Mar 17 15:28:25 2014
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Tue, 18 Mar 2014 06:28:25 +1100
Subject: [wildfly-dev] Thoughts on alternative security managers
In-Reply-To: <532744E2.3040909@redhat.com>
References: <532744E2.3040909@redhat.com>
Message-ID: <53274CD9.4010802@gmail.com>

So is the only real issue here performance when running under a security manager? 

If so I think that we should just go with option 0. There is still plenty of other low hanging fruit that we could address performance wise, and I think it would be better to spend time on that rather than optimizing for the very small percentage of users who use a security manager. 

I also have a feeling that users that want to use a security manager will probably want it to behave like a traditional SecurityManager, rather than some kind of custom behavior.

Stuart

David M. Lloyd wrote:
> It is possible to implement a security manager which behaves differently
> than the default AccessController-based security manager.  I am
> wondering if we should maybe explore some options here.
>
> AccessControlContext (ACC) permission checks are expensive.  The
> assembled context can consist of many object instances, many of which
> may be constructed on the fly, in order to check a permission against
> every invocation frame on the call stack (including going through thread
> start points to earlier, snapshotted thread stacks) down to the most
> recent doPrivileged() invocation.  The theory is to ensure that
> permissions can never escalate without an explicit action.  However, few
> frameworks use doPrivileged() properly, resulting in too many
> permissions being assigned to the user deployment anyway.
>
> Option 0: Status quo
> --------------------
> To mitigate some of this cost, our current security manager has
> "checked" and "unchecked" modes for the current thread.  When running
> trusted code, we switch to "unchecked" mode which is functionally
> similar to a privileged block, except (a) it is much faster as expensive
> permission checks are simply bypassed and (b) it is the responsibility
> of the container to ensure that checked mode is re-enabled before
> calling back in to user code.
>
> When checked mode is enabled, all permission checks happen in the usual
> way with ACC.  Privileged blocks are necessary for code that runs in
> checked mode (i.e. user libraries and many of our APIs that do not have
> direct support for WildFlySecurityManager).
>
> Option 1: Fast and simple
> -------------------------
> We could completely switch the SecurityManager's (SM's) security context
> object to be a per-deployment context of some sort.  Permissions would
> be checked based on whatever deployment is currently active; checked and
> unchecked modes would still be used in this case.
>
> In this option, the permissions that are currently checked are *always*
> the active deployment, which is particularly relevant in the case that
> the deployment calls into some other deployment without using container
> facilities.
>
> We could still support standard security policies to assign additional
> permissions to the current Principal.
>
> Privileged blocks in this case would be completely ignored.
>
> This could be a very fast approach as no objects need be constructed to
> perform a permission check; however, it is also perhaps harder to create
> fine-grained restrictions on things.
>
> Option 2: Call stack (simplified version)
> -----------------------------------------
> Alternatively, we could examine the call stack on each invocation to
> locate the most recent enclosing "untrusted" class loader.  This
> involves acquiring and traversing the invocation call stack (which may
> be cheaper in Java 8 or 9).  While expensive, this operation should be
> less expensive than constructing an ACC.
>
> Privileged blocks in this case would also be completely ignored, and all
> the other above benefits would hold.  For the relative performance cost
> we would pay over Option 1, we'd regain the ability to establish
> fine-grained restrictions.
>
> Option 3: Call stack (advanced version)
> ---------------------------------------
> In this option we essentially duplicate what ACC does, but using the
> presumably less-expensive SM method of acquiring and examining the call
> stack.  Privileged blocks probably would not work, but if not, we'd have
> an alternative mechanism for establishing bounds on the set of
> permissions to check per call.  We would still support checked/unchecked
> mode.
>
> All three of these options would not be compatible with DomainCombiners,
> if that matters.
>
> Any thoughts?

From Anil.Saldhana at redhat.com  Mon Mar 17 15:42:44 2014
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Mon, 17 Mar 2014 14:42:44 -0500
Subject: [wildfly-dev] Thoughts on alternative security managers
In-Reply-To: <53274CD9.4010802@gmail.com>
References: <532744E2.3040909@redhat.com> <53274CD9.4010802@gmail.com>
Message-ID: <53275034.1050502@redhat.com>

David - tough one. :)

If WildFly is going to run with the security manager on by default, then 
we should explore the options that can have impact on the performance. 
If it is not going to be on by default, then I agree with Stuart that we 
are better off using the default JSM behavior (Option 0) considering 
very few users want to use the JSM.

Another option is to convert a regular doPrivileged(privilegedaction) 
call into a doPrivileged(privilegedaction, ACC) where the ACC is 
dynamically constructed by the SM module such that the intersection of 
the caller's permissions and the dynamicACC is large enough.  [The 
trusted vs untrusted usecase]

The challenge with tackling the topic of security managers is that if 
the SM fails to protect an unauthorized call due to custom behavior, 
then we have to deal with vulnerability reporting/patching etc.

On 03/17/2014 02:28 PM, Stuart Douglas wrote:
> So is the only real issue here performance when running under a security manager?
>
> If so I think that we should just go with option 0. There is still plenty of other low hanging fruit that we could address performance wise, and I think it would be better to spend time on that rather than optimizing for the very small percentage of users who use a security manager.
>
> I also have a feeling that users that want to use a security manager will probably want it to behave like a traditional SecurityManager, rather than some kind of custom behavior.
>
> Stuart
>
> David M. Lloyd wrote:
>> It is possible to implement a security manager which behaves differently
>> than the default AccessController-based security manager.  I am
>> wondering if we should maybe explore some options here.
>>
>> AccessControlContext (ACC) permission checks are expensive.  The
>> assembled context can consist of many object instances, many of which
>> may be constructed on the fly, in order to check a permission against
>> every invocation frame on the call stack (including going through thread
>> start points to earlier, snapshotted thread stacks) down to the most
>> recent doPrivileged() invocation.  The theory is to ensure that
>> permissions can never escalate without an explicit action.  However, few
>> frameworks use doPrivileged() properly, resulting in too many
>> permissions being assigned to the user deployment anyway.
>>
>> Option 0: Status quo
>> --------------------
>> To mitigate some of this cost, our current security manager has
>> "checked" and "unchecked" modes for the current thread.  When running
>> trusted code, we switch to "unchecked" mode which is functionally
>> similar to a privileged block, except (a) it is much faster as expensive
>> permission checks are simply bypassed and (b) it is the responsibility
>> of the container to ensure that checked mode is re-enabled before
>> calling back in to user code.
>>
>> When checked mode is enabled, all permission checks happen in the usual
>> way with ACC.  Privileged blocks are necessary for code that runs in
>> checked mode (i.e. user libraries and many of our APIs that do not have
>> direct support for WildFlySecurityManager).
>>
>> Option 1: Fast and simple
>> -------------------------
>> We could completely switch the SecurityManager's (SM's) security context
>> object to be a per-deployment context of some sort.  Permissions would
>> be checked based on whatever deployment is currently active; checked and
>> unchecked modes would still be used in this case.
>>
>> In this option, the permissions that are currently checked are *always*
>> the active deployment, which is particularly relevant in the case that
>> the deployment calls into some other deployment without using container
>> facilities.
>>
>> We could still support standard security policies to assign additional
>> permissions to the current Principal.
>>
>> Privileged blocks in this case would be completely ignored.
>>
>> This could be a very fast approach as no objects need be constructed to
>> perform a permission check; however, it is also perhaps harder to create
>> fine-grained restrictions on things.
>>
>> Option 2: Call stack (simplified version)
>> -----------------------------------------
>> Alternatively, we could examine the call stack on each invocation to
>> locate the most recent enclosing "untrusted" class loader.  This
>> involves acquiring and traversing the invocation call stack (which may
>> be cheaper in Java 8 or 9).  While expensive, this operation should be
>> less expensive than constructing an ACC.
>>
>> Privileged blocks in this case would also be completely ignored, and all
>> the other above benefits would hold.  For the relative performance cost
>> we would pay over Option 1, we'd regain the ability to establish
>> fine-grained restrictions.
>>
>> Option 3: Call stack (advanced version)
>> ---------------------------------------
>> In this option we essentially duplicate what ACC does, but using the
>> presumably less-expensive SM method of acquiring and examining the call
>> stack.  Privileged blocks probably would not work, but if not, we'd have
>> an alternative mechanism for establishing bounds on the set of
>> permissions to check per call.  We would still support checked/unchecked
>> mode.
>>
>> All three of these options would not be compatible with DomainCombiners,
>> if that matters.
>>
>> Any thoughts?
>>

From marek.zupnik at gmail.com  Tue Mar 18 09:59:47 2014
From: marek.zupnik at gmail.com (=?ISO-8859-2?Q?Marek_=AFupnik?=)
Date: Tue, 18 Mar 2014 14:59:47 +0100
Subject: [wildfly-dev] Support for PKCS12 keystores in Security Realms
Message-ID: <CAGk6hheh0PcOFszcsq4EGV6SqY3NCWYC3A-XaV8B3b6bCTnROg@mail.gmail.com>

Hi,

I'm Marek Zupnik. It's my first message for this list but for some time
I've been keeping my eyes on what's happening in wildfly development.

I'm writing regarding to the issue about lack of support for PKCS12
keystores in security realms (https://issues.jboss.org/browse/WFLY-2229). I
wanted to migrate my system to Wildfly but in my case it is a blocking
issue. I have to use keystore in PKCS12 format in which I'm storing, among
others, https private key.

I forked Wildfly on github and made a simple fix for this issue which
consists in additional parameter "keystore-type" for keystore
configuration. Based on this parameter I'm able to create appropriate
keystore type.

Config sample:
<keystore path="keystore.p12" relative-to="jboss.server.config.dir"
keystore-password="xxx" keystore-type="PKCS12" alias="https"/>

The changes are in my fork on github (keystore_type branch):
https://github.com/mzupnik/wildfly/tree/keystore_type

Before I will try to do push request, could you answer me if it is
acceptable solution according to your architecture concept? If not, could
you give me some tips how to resolve it in other way? I care about this fix
before 9. release.

Kind Regards,
Marek Zupnik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140318/9bf05913/attachment.html 

From darran.lofthouse at jboss.com  Tue Mar 18 10:56:36 2014
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Tue, 18 Mar 2014 14:56:36 +0000
Subject: [wildfly-dev] Support for PKCS12 keystores in Security Realms
In-Reply-To: <CAGk6hheh0PcOFszcsq4EGV6SqY3NCWYC3A-XaV8B3b6bCTnROg@mail.gmail.com>
References: <CAGk6hheh0PcOFszcsq4EGV6SqY3NCWYC3A-XaV8B3b6bCTnROg@mail.gmail.com>
Message-ID: <53285EA4.8070109@jboss.com>

This whole area is on the verge of being overhauled, feel free to put 
this information in WFLY-2229 and I will take a look at the same time.

Regards,
Darran Lofthouse.


On 18/03/14 13:59, Marek ?upnik wrote:
> Hi,
>
> I'm Marek Zupnik. It's my first message for this list but for some time
> I've been keeping my eyes on what's happening in wildfly development.
>
> I'm writing regarding to the issue about lack of support for PKCS12
> keystores in security realms
> (https://issues.jboss.org/browse/WFLY-2229). I wanted to migrate my
> system to Wildfly but in my case it is a blocking issue. I have to use
> keystore in PKCS12 format in which I'm storing, among others, https
> private key.
>
> I forked Wildfly on github and made a simple fix for this issue which
> consists in additional parameter "keystore-type" for keystore
> configuration. Based on this parameter I'm able to create appropriate
> keystore type.
>
> Config sample:
> <keystore path="keystore.p12" relative-to="jboss.server.config.dir"
> keystore-password="xxx" keystore-type="PKCS12" alias="https"/>
>
> The changes are in my fork on github (keystore_type branch):
> https://github.com/mzupnik/wildfly/tree/keystore_type
>
> Before I will try to do push request, could you answer me if it is
> acceptable solution according to your architecture concept? If not,
> could you give me some tips how to resolve it in other way? I care about
> this fix before 9. release.
>
> Kind Regards,
> Marek Zupnik
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From darran.lofthouse at jboss.com  Tue Mar 18 11:30:42 2014
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Tue, 18 Mar 2014 15:30:42 +0000
Subject: [wildfly-dev] Support for PKCS12 keystores in Security Realms
In-Reply-To: <53285EA4.8070109@jboss.com>
References: <CAGk6hheh0PcOFszcsq4EGV6SqY3NCWYC3A-XaV8B3b6bCTnROg@mail.gmail.com>
	<53285EA4.8070109@jboss.com>
Message-ID: <532866A2.4030504@jboss.com>

Should just clarify about 80% of the code change suggested has already 
made it into the WildFly development branch - there is only a small 
portion to finish off to complete the loading of a file based PKCS#12 
keystore in WildFly 9 but that will come under the overhaul.

Regards,
Darran Lofthouse.


On 18/03/14 14:56, Darran Lofthouse wrote:
> This whole area is on the verge of being overhauled, feel free to put
> this information in WFLY-2229 and I will take a look at the same time.
>
> Regards,
> Darran Lofthouse.
>
>
> On 18/03/14 13:59, Marek ?upnik wrote:
>> Hi,
>>
>> I'm Marek Zupnik. It's my first message for this list but for some time
>> I've been keeping my eyes on what's happening in wildfly development.
>>
>> I'm writing regarding to the issue about lack of support for PKCS12
>> keystores in security realms
>> (https://issues.jboss.org/browse/WFLY-2229). I wanted to migrate my
>> system to Wildfly but in my case it is a blocking issue. I have to use
>> keystore in PKCS12 format in which I'm storing, among others, https
>> private key.
>>
>> I forked Wildfly on github and made a simple fix for this issue which
>> consists in additional parameter "keystore-type" for keystore
>> configuration. Based on this parameter I'm able to create appropriate
>> keystore type.
>>
>> Config sample:
>> <keystore path="keystore.p12" relative-to="jboss.server.config.dir"
>> keystore-password="xxx" keystore-type="PKCS12" alias="https"/>
>>
>> The changes are in my fork on github (keystore_type branch):
>> https://github.com/mzupnik/wildfly/tree/keystore_type
>>
>> Before I will try to do push request, could you answer me if it is
>> acceptable solution according to your architecture concept? If not,
>> could you give me some tips how to resolve it in other way? I care about
>> this fix before 9. release.
>>
>> Kind Regards,
>> Marek Zupnik
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From brian.stansberry at redhat.com  Tue Mar 18 11:20:13 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 18 Mar 2014 10:20:13 -0500
Subject: [wildfly-dev] Support for PKCS12 keystores in Security Realms
In-Reply-To: <CAGk6hheh0PcOFszcsq4EGV6SqY3NCWYC3A-XaV8B3b6bCTnROg@mail.gmail.com>
References: <CAGk6hheh0PcOFszcsq4EGV6SqY3NCWYC3A-XaV8B3b6bCTnROg@mail.gmail.com>
Message-ID: <5328642D.100@redhat.com>

Hi Marek,

Welcome!

I'm going to make a few comments on github re: some minor details of 
your commit. But please keep an eye on this list for your more general 
question about whether this is how we want to go about this. I believe 
Darran Lofthouse was planning some work in this area so he may have some 
input.

Cheers,

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

On 3/18/14, 8:59 AM, Marek ?upnik wrote:
> Hi,
>
> I'm Marek Zupnik. It's my first message for this list but for some time
> I've been keeping my eyes on what's happening in wildfly development.
>
> I'm writing regarding to the issue about lack of support for PKCS12
> keystores in security realms
> (https://issues.jboss.org/browse/WFLY-2229). I wanted to migrate my
> system to Wildfly but in my case it is a blocking issue. I have to use
> keystore in PKCS12 format in which I'm storing, among others, https
> private key.
>
> I forked Wildfly on github and made a simple fix for this issue which
> consists in additional parameter "keystore-type" for keystore
> configuration. Based on this parameter I'm able to create appropriate
> keystore type.
>
> Config sample:
> <keystore path="keystore.p12" relative-to="jboss.server.config.dir"
> keystore-password="xxx" keystore-type="PKCS12" alias="https"/>
>
> The changes are in my fork on github (keystore_type branch):
> https://github.com/mzupnik/wildfly/tree/keystore_type
>
> Before I will try to do push request, could you answer me if it is
> acceptable solution according to your architecture concept? If not,
> could you give me some tips how to resolve it in other way? I care about
> this fix before 9. release.
>
> Kind Regards,
> Marek Zupnik
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>



From marek.zupnik at gmail.com  Tue Mar 18 12:30:14 2014
From: marek.zupnik at gmail.com (=?ISO-8859-2?Q?Marek_=AFupnik?=)
Date: Tue, 18 Mar 2014 17:30:14 +0100
Subject: [wildfly-dev] Support for PKCS12 keystores in Security Realms
In-Reply-To: <5328642D.100@redhat.com>
References: <CAGk6hheh0PcOFszcsq4EGV6SqY3NCWYC3A-XaV8B3b6bCTnROg@mail.gmail.com>
	<5328642D.100@redhat.com>
Message-ID: <CAGk6hhcVCuymoQtXcLnu3wjtfW6yec+QNdszj9BQM3W9mOdq7g@mail.gmail.com>

Hi,

Thank You Brian for your comments. I'll try to apply them to my code. I ask
if I will have further questions about it.

@Darran, I have a question for you. I wasn't looking into development
branch so I haven't known about the changes. Is it possible that pkcs12
support will be merged in Wildfly 8? If not, could my change be merged
earlier? Otherwise, I'm forced to maintain my version of Wildfly untill no
9 will be released.

Kind Regards,
Marek Zupnik


2014-03-18 16:20 GMT+01:00 Brian Stansberry <brian.stansberry at redhat.com>:

> Hi Marek,
>
> Welcome!
>
> I'm going to make a few comments on github re: some minor details of
> your commit. But please keep an eye on this list for your more general
> question about whether this is how we want to go about this. I believe
> Darran Lofthouse was planning some work in this area so he may have some
> input.
>
> Cheers,
>
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
>
> On 3/18/14, 8:59 AM, Marek ?upnik wrote:
> > Hi,
> >
> > I'm Marek Zupnik. It's my first message for this list but for some time
> > I've been keeping my eyes on what's happening in wildfly development.
> >
> > I'm writing regarding to the issue about lack of support for PKCS12
> > keystores in security realms
> > (https://issues.jboss.org/browse/WFLY-2229). I wanted to migrate my
> > system to Wildfly but in my case it is a blocking issue. I have to use
> > keystore in PKCS12 format in which I'm storing, among others, https
> > private key.
> >
> > I forked Wildfly on github and made a simple fix for this issue which
> > consists in additional parameter "keystore-type" for keystore
> > configuration. Based on this parameter I'm able to create appropriate
> > keystore type.
> >
> > Config sample:
> > <keystore path="keystore.p12" relative-to="jboss.server.config.dir"
> > keystore-password="xxx" keystore-type="PKCS12" alias="https"/>
> >
> > The changes are in my fork on github (keystore_type branch):
> > https://github.com/mzupnik/wildfly/tree/keystore_type
> >
> > Before I will try to do push request, could you answer me if it is
> > acceptable solution according to your architecture concept? If not,
> > could you give me some tips how to resolve it in other way? I care about
> > this fix before 9. release.
> >
> > Kind Regards,
> > Marek Zupnik
> >
> >
> > _______________________________________________
> > 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/20140318/6e6e1864/attachment.html 

From darran.lofthouse at jboss.com  Tue Mar 18 13:10:48 2014
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Tue, 18 Mar 2014 17:10:48 +0000
Subject: [wildfly-dev] Support for PKCS12 keystores in Security Realms
In-Reply-To: <CAGk6hhcVCuymoQtXcLnu3wjtfW6yec+QNdszj9BQM3W9mOdq7g@mail.gmail.com>
References: <CAGk6hheh0PcOFszcsq4EGV6SqY3NCWYC3A-XaV8B3b6bCTnROg@mail.gmail.com>	<5328642D.100@redhat.com>
	<CAGk6hhcVCuymoQtXcLnu3wjtfW6yec+QNdszj9BQM3W9mOdq7g@mail.gmail.com>
Message-ID: <53287E18.4080900@jboss.com>

I will have another look if I get a chance to get something into 8 but 
in reality a related change in this area (that completely conflicts with 
your changes) was pushed to 9 as the consensus was we did not want the 
configuration model in this area changing before WildFLy 9.

On 18/03/14 16:30, Marek ?upnik wrote:
> Hi,
>
> Thank You Brian for your comments. I'll try to apply them to my code. I
> ask if I will have further questions about it.
>
> @Darran, I have a question for you. I wasn't looking into development
> branch so I haven't known about the changes. Is it possible that pkcs12
> support will be merged in Wildfly 8? If not, could my change be merged
> earlier? Otherwise, I'm forced to maintain my version of Wildfly untill
> no 9 will be released.
>
> Kind Regards,
> Marek Zupnik
>
>
> 2014-03-18 16:20 GMT+01:00 Brian Stansberry <brian.stansberry at redhat.com
> <mailto:brian.stansberry at redhat.com>>:
>
>     Hi Marek,
>
>     Welcome!
>
>     I'm going to make a few comments on github re: some minor details of
>     your commit. But please keep an eye on this list for your more general
>     question about whether this is how we want to go about this. I believe
>     Darran Lofthouse was planning some work in this area so he may have some
>     input.
>
>     Cheers,
>
>     --
>     Brian Stansberry
>     Senior Principal Software Engineer
>     JBoss by Red Hat
>
>     On 3/18/14, 8:59 AM, Marek ?upnik wrote:
>      > Hi,
>      >
>      > I'm Marek Zupnik. It's my first message for this list but for
>     some time
>      > I've been keeping my eyes on what's happening in wildfly development.
>      >
>      > I'm writing regarding to the issue about lack of support for PKCS12
>      > keystores in security realms
>      > (https://issues.jboss.org/browse/WFLY-2229). I wanted to migrate my
>      > system to Wildfly but in my case it is a blocking issue. I have
>     to use
>      > keystore in PKCS12 format in which I'm storing, among others, https
>      > private key.
>      >
>      > I forked Wildfly on github and made a simple fix for this issue which
>      > consists in additional parameter "keystore-type" for keystore
>      > configuration. Based on this parameter I'm able to create appropriate
>      > keystore type.
>      >
>      > Config sample:
>      > <keystore path="keystore.p12" relative-to="jboss.server.config.dir"
>      > keystore-password="xxx" keystore-type="PKCS12" alias="https"/>
>      >
>      > The changes are in my fork on github (keystore_type branch):
>      > https://github.com/mzupnik/wildfly/tree/keystore_type
>      >
>      > Before I will try to do push request, could you answer me if it is
>      > acceptable solution according to your architecture concept? If not,
>      > could you give me some tips how to resolve it in other way? I
>     care about
>      > this fix before 9. release.
>      >
>      > Kind Regards,
>      > Marek Zupnik
>      >
>      >
>      > _______________________________________________
>      > wildfly-dev mailing list
>      > wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>      > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>      >
>
>
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From brian.stansberry at redhat.com  Tue Mar 18 18:23:06 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 18 Mar 2014 17:23:06 -0500
Subject: [wildfly-dev] Intermittent failures in EE injection tests
Message-ID: <5328C74A.6020608@redhat.com>

The set of five failures reported at [1] happens intermittently but 
fairly frequently. It's been going on for months now.

Can someone sort these tests?

Thanks.

[1] 
http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=12551&buildTypeId=WF_MasterIgnoreLinux

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

From emartins at redhat.com  Tue Mar 18 18:24:47 2014
From: emartins at redhat.com (Eduardo Martins)
Date: Tue, 18 Mar 2014 18:24:47 -0400 (EDT)
Subject: [wildfly-dev] Intermittent failures in EE injection tests
In-Reply-To: <5328C74A.6020608@redhat.com>
References: <5328C74A.6020608@redhat.com>
Message-ID: <7BEE71C1-D62B-4851-8512-4383F0B5ED6F@redhat.com>

Will look at these.

--E

> On 18 Mar 2014, at 22:23, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> 
> The set of five failures reported at [1] happens intermittently but 
> fairly frequently. It's been going on for months now.
> 
> Can someone sort these tests?
> 
> Thanks.
> 
> [1] 
> http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=12551&buildTypeId=WF_MasterIgnoreLinux
> 
> -- 
> 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  Tue Mar 18 18:26:38 2014
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Tue, 18 Mar 2014 23:26:38 +0100
Subject: [wildfly-dev] Intermittent failures in EE injection tests
In-Reply-To: <7BEE71C1-D62B-4851-8512-4383F0B5ED6F@redhat.com>
References: <5328C74A.6020608@redhat.com>
	<7BEE71C1-D62B-4851-8512-4383F0B5ED6F@redhat.com>
Message-ID: <CAMquZP6m-55dyM8tt2JJ6f=vAZNpTBJfh8vMnKp7YeL6H_-QSA@mail.gmail.com>

This is not problem with test, but with test framework, namely the way
arquillian handles ExpectedExceptions and the way junit 4.11 changed some
behavior around it.

In short, this is one of the reasons we did one-off release of arquillian
for wildfly...


On Tue, Mar 18, 2014 at 11:24 PM, Eduardo Martins <emartins at redhat.com>wrote:

> Will look at these.
>
> --E
>
> > On 18 Mar 2014, at 22:23, Brian Stansberry <brian.stansberry at redhat.com>
> wrote:
> >
> > The set of five failures reported at [1] happens intermittently but
> > fairly frequently. It's been going on for months now.
> >
> > Can someone sort these tests?
> >
> > Thanks.
> >
> > [1]
> >
> http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=12551&buildTypeId=WF_MasterIgnoreLinux
> >
> > --
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140318/8fd22499/attachment.html 

From brian.stansberry at redhat.com  Tue Mar 18 18:42:36 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 18 Mar 2014 17:42:36 -0500
Subject: [wildfly-dev] Intermittent failures in EE injection tests
In-Reply-To: <CAMquZP6m-55dyM8tt2JJ6f=vAZNpTBJfh8vMnKp7YeL6H_-QSA@mail.gmail.com>
References: <5328C74A.6020608@redhat.com>	<7BEE71C1-D62B-4851-8512-4383F0B5ED6F@redhat.com>
	<CAMquZP6m-55dyM8tt2JJ6f=vAZNpTBJfh8vMnKp7YeL6H_-QSA@mail.gmail.com>
Message-ID: <5328CBDC.9000809@redhat.com>

So why does the test intermittently fail?

On 3/18/14, 5:26 PM, Toma? Cerar wrote:
> This is not problem with test, but with test framework, namely the way
> arquillian handles ExpectedExceptions and the way junit 4.11 changed
> some behavior around it.
>
> In short, this is one of the reasons we did one-off release of
> arquillian for wildfly...
>
>
> On Tue, Mar 18, 2014 at 11:24 PM, Eduardo Martins <emartins at redhat.com
> <mailto:emartins at redhat.com>> wrote:
>
>     Will look at these.
>
>     --E
>
>      > On 18 Mar 2014, at 22:23, Brian Stansberry
>     <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>>
>     wrote:
>      >
>      > The set of five failures reported at [1] happens intermittently but
>      > fairly frequently. It's been going on for months now.
>      >
>      > Can someone sort these tests?
>      >
>      > Thanks.
>      >
>      > [1]
>      >
>     http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=12551&buildTypeId=WF_MasterIgnoreLinux
>      >
>      > --
>      > Brian Stansberry
>      > Senior Principal Software Engineer
>      > JBoss by Red Hat
>      > _______________________________________________
>      > wildfly-dev mailing list
>      > wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>      > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto: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 stuart.w.douglas at gmail.com  Tue Mar 18 20:40:18 2014
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Wed, 19 Mar 2014 11:40:18 +1100
Subject: [wildfly-dev] Intermittent failures in EE injection tests
In-Reply-To: <CAMquZP6m-55dyM8tt2JJ6f=vAZNpTBJfh8vMnKp7YeL6H_-QSA@mail.gmail.com>
References: <5328C74A.6020608@redhat.com>
	<7BEE71C1-D62B-4851-8512-4383F0B5ED6F@redhat.com>
	<CAMquZP6m-55dyM8tt2JJ6f=vAZNpTBJfh8vMnKp7YeL6H_-QSA@mail.gmail.com>
Message-ID: <5328E772.6000704@gmail.com>

It that is all it is then this should fix them: 
https://github.com/wildfly/wildfly/pull/6054

Stuart

Toma? Cerar wrote:
> This is not problem with test, but with test framework, namely the way
> arquillian handles ExpectedExceptions and the way junit 4.11 changed
> some behavior around it.
>
> In short, this is one of the reasons we did one-off release of
> arquillian for wildfly...
>
>
> On Tue, Mar 18, 2014 at 11:24 PM, Eduardo Martins <emartins at redhat.com
> <mailto:emartins at redhat.com>> wrote:
>
>     Will look at these.
>
>     --E
>
>      > On 18 Mar 2014, at 22:23, Brian Stansberry
>     <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>>
>     wrote:
>      >
>      > The set of five failures reported at [1] happens intermittently but
>      > fairly frequently. It's been going on for months now.
>      >
>      > Can someone sort these tests?
>      >
>      > Thanks.
>      >
>      > [1]
>      >
>     http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=12551&buildTypeId=WF_MasterIgnoreLinux
>     <http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=12551&buildTypeId=WF_MasterIgnoreLinux>
>      >
>      > --
>      > Brian Stansberry
>      > Senior Principal Software Engineer
>      > JBoss by Red Hat
>      > _______________________________________________
>      > wildfly-dev mailing list
>      > wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>      > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

From brian.stansberry at redhat.com  Tue Mar 18 22:38:12 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 18 Mar 2014 21:38:12 -0500
Subject: [wildfly-dev] Intermittent failures in EE injection tests
In-Reply-To: <5328E772.6000704@gmail.com>
References: <5328C74A.6020608@redhat.com>	<7BEE71C1-D62B-4851-8512-4383F0B5ED6F@redhat.com>	<CAMquZP6m-55dyM8tt2JJ6f=vAZNpTBJfh8vMnKp7YeL6H_-QSA@mail.gmail.com>
	<5328E772.6000704@gmail.com>
Message-ID: <53290314.8010400@redhat.com>

Thanks, Stuart.

On 3/18/14, 7:40 PM, Stuart Douglas wrote:
> It that is all it is then this should fix them:
> https://github.com/wildfly/wildfly/pull/6054
>
> Stuart
>
> Toma? Cerar wrote:
>> This is not problem with test, but with test framework, namely the way
>> arquillian handles ExpectedExceptions and the way junit 4.11 changed
>> some behavior around it.
>>
>> In short, this is one of the reasons we did one-off release of
>> arquillian for wildfly...
>>
>>
>> On Tue, Mar 18, 2014 at 11:24 PM, Eduardo Martins <emartins at redhat.com
>> <mailto:emartins at redhat.com>> wrote:
>>
>>      Will look at these.
>>
>>      --E
>>
>>       > On 18 Mar 2014, at 22:23, Brian Stansberry
>>      <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>>
>>      wrote:
>>       >
>>       > The set of five failures reported at [1] happens intermittently but
>>       > fairly frequently. It's been going on for months now.
>>       >
>>       > Can someone sort these tests?
>>       >
>>       > Thanks.
>>       >
>>       > [1]
>>       >
>>      http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=12551&buildTypeId=WF_MasterIgnoreLinux
>>      <http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=12551&buildTypeId=WF_MasterIgnoreLinux>
>>       >
>>       > --
>>       > Brian Stansberry
>>       > Senior Principal Software Engineer
>>       > JBoss by Red Hat
>>       > _______________________________________________
>>       > wildfly-dev mailing list
>>       > wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>       > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>      _______________________________________________
>>      wildfly-dev mailing list
>>      wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>      https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


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

From rory.odonnell at oracle.com  Wed Mar 19 05:56:51 2014
From: rory.odonnell at oracle.com (Rory O'Donnell Oracle, Dublin Ireland)
Date: Wed, 19 Mar 2014 09:56:51 +0000
Subject: [wildfly-dev] JDK 8 Update 20 build 05 & JDK 7 Update 60 build 10
 are available on java.net
Message-ID: <532969E3.5070704@oracle.com>

Hi Guys,

Mark Reinhold announced yesterday JDK 8: General Availability here 
<http://mreinhold.org/blog/jdk8-ga>

<http://mreinhold.org/blog/jdk8-ga>JDK 8 u20 Build 05 Early Access Build 
is now available for download <http://jdk8.java.net/download.html> & test.
JDK 7 u60 Build 10 Early Access Build is also available for download 
<https://jdk7.java.net/download.html>& test.


Rgds, Rory

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

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

From tomaz.cerar at gmail.com  Wed Mar 19 06:36:41 2014
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Wed, 19 Mar 2014 11:36:41 +0100
Subject: [wildfly-dev] Intermittent failures in EE injection tests
In-Reply-To: <5328E772.6000704@gmail.com>
References: <5328C74A.6020608@redhat.com>
	<7BEE71C1-D62B-4851-8512-4383F0B5ED6F@redhat.com>
	<CAMquZP6m-55dyM8tt2JJ6f=vAZNpTBJfh8vMnKp7YeL6H_-QSA@mail.gmail.com>
	<5328E772.6000704@gmail.com>
Message-ID: <CAMquZP6jeMtzSajmYb1=k28qNPKmRyjkiSOnBANqUw0v=wmffQ@mail.gmail.com>

On Wed, Mar 19, 2014 at 1:40 AM, Stuart Douglas
<stuart.w.douglas at gmail.com>wrote:

> It that is all it is then this should fix them:
> https://github.com/wildfly/wildfly/pull/6054
>


Only problem is see with this is that we use so many(100+)
ExpectedExceptions all around the testsuite,
that we will just eventually just need to replace all of them.

Junit 4.12 should address part of this problem, other part should be fixed
in arquillian core itself..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140319/5376ec07/attachment.html 

From brian.stansberry at redhat.com  Wed Mar 19 15:29:27 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 19 Mar 2014 14:29:27 -0500
Subject: [wildfly-dev] Intermittent failures in EE injection tests
In-Reply-To: <CAMquZP6jeMtzSajmYb1=k28qNPKmRyjkiSOnBANqUw0v=wmffQ@mail.gmail.com>
References: <5328C74A.6020608@redhat.com>	<7BEE71C1-D62B-4851-8512-4383F0B5ED6F@redhat.com>	<CAMquZP6m-55dyM8tt2JJ6f=vAZNpTBJfh8vMnKp7YeL6H_-QSA@mail.gmail.com>	<5328E772.6000704@gmail.com>
	<CAMquZP6jeMtzSajmYb1=k28qNPKmRyjkiSOnBANqUw0v=wmffQ@mail.gmail.com>
Message-ID: <5329F017.3090309@redhat.com>

I grepped for uses of that and with a quick eye scan they didn't seem 
like the tests that regularly fail. These 5 tests fail as a set quite 
often. I have no idea why they are special. I'll just cross my fingers 
and hope that they just work now. :)

On 3/19/14, 5:36 AM, Toma? Cerar wrote:
>
> On Wed, Mar 19, 2014 at 1:40 AM, Stuart Douglas
> <stuart.w.douglas at gmail.com <mailto:stuart.w.douglas at gmail.com>> wrote:
>
>     It that is all it is then this should fix them:
>     https://github.com/wildfly/__wildfly/pull/6054
>     <https://github.com/wildfly/wildfly/pull/6054>
>
>
>
> Only problem is see with this is that we use so many(100+)
> ExpectedExceptions all around the testsuite,
> that we will just eventually just need to replace all of them.
>
> Junit 4.12 should address part of this problem, other part should be
> fixed in arquillian core itself..
>
>
> _______________________________________________
> 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 marek.zupnik at gmail.com  Wed Mar 19 18:42:18 2014
From: marek.zupnik at gmail.com (=?ISO-8859-2?Q?Marek_=AFupnik?=)
Date: Wed, 19 Mar 2014 23:42:18 +0100
Subject: [wildfly-dev] Support for PKCS12 keystores in Security Realms
In-Reply-To: <53287E18.4080900@jboss.com>
References: <CAGk6hheh0PcOFszcsq4EGV6SqY3NCWYC3A-XaV8B3b6bCTnROg@mail.gmail.com>
	<5328642D.100@redhat.com>
	<CAGk6hhcVCuymoQtXcLnu3wjtfW6yec+QNdszj9BQM3W9mOdq7g@mail.gmail.com>
	<53287E18.4080900@jboss.com>
Message-ID: <CAGk6hheSozAbreWMyeEA4P5zx+t1y4stfbBxyn6Hr4_Wcc_LeA@mail.gmail.com>

Hi,

Darran, I understand your point of view, but stable version of 9 will be
not released tomorrow. Lack of pkcs12 support in 8 is a major issue, not to
mention that in AS 7 I was able to use this format for https private key. I
think it will be useful to fix it yet in 8, even thought the code with a
fix will be thrown away in 9.

I made a pull request with a fix (
https://github.com/wildfly/wildfly/pull/6062). It is up to you what you do
with it.

Thank you for your answers and clarifications.

Kind Regards,
Marek Zupnik


2014-03-18 18:10 GMT+01:00 Darran Lofthouse <darran.lofthouse at jboss.com>:

> I will have another look if I get a chance to get something into 8 but
> in reality a related change in this area (that completely conflicts with
> your changes) was pushed to 9 as the consensus was we did not want the
> configuration model in this area changing before WildFLy 9.
>
> On 18/03/14 16:30, Marek ?upnik wrote:
> > Hi,
> >
> > Thank You Brian for your comments. I'll try to apply them to my code. I
> > ask if I will have further questions about it.
> >
> > @Darran, I have a question for you. I wasn't looking into development
> > branch so I haven't known about the changes. Is it possible that pkcs12
> > support will be merged in Wildfly 8? If not, could my change be merged
> > earlier? Otherwise, I'm forced to maintain my version of Wildfly untill
> > no 9 will be released.
> >
> > Kind Regards,
> > Marek Zupnik
> >
> >
> > 2014-03-18 16:20 GMT+01:00 Brian Stansberry <brian.stansberry at redhat.com
> > <mailto:brian.stansberry at redhat.com>>:
> >
> >     Hi Marek,
> >
> >     Welcome!
> >
> >     I'm going to make a few comments on github re: some minor details of
> >     your commit. But please keep an eye on this list for your more
> general
> >     question about whether this is how we want to go about this. I
> believe
> >     Darran Lofthouse was planning some work in this area so he may have
> some
> >     input.
> >
> >     Cheers,
> >
> >     --
> >     Brian Stansberry
> >     Senior Principal Software Engineer
> >     JBoss by Red Hat
> >
> >     On 3/18/14, 8:59 AM, Marek ?upnik wrote:
> >      > Hi,
> >      >
> >      > I'm Marek Zupnik. It's my first message for this list but for
> >     some time
> >      > I've been keeping my eyes on what's happening in wildfly
> development.
> >      >
> >      > I'm writing regarding to the issue about lack of support for
> PKCS12
> >      > keystores in security realms
> >      > (https://issues.jboss.org/browse/WFLY-2229). I wanted to migrate
> my
> >      > system to Wildfly but in my case it is a blocking issue. I have
> >     to use
> >      > keystore in PKCS12 format in which I'm storing, among others,
> https
> >      > private key.
> >      >
> >      > I forked Wildfly on github and made a simple fix for this issue
> which
> >      > consists in additional parameter "keystore-type" for keystore
> >      > configuration. Based on this parameter I'm able to create
> appropriate
> >      > keystore type.
> >      >
> >      > Config sample:
> >      > <keystore path="keystore.p12"
> relative-to="jboss.server.config.dir"
> >      > keystore-password="xxx" keystore-type="PKCS12" alias="https"/>
> >      >
> >      > The changes are in my fork on github (keystore_type branch):
> >      > https://github.com/mzupnik/wildfly/tree/keystore_type
> >      >
> >      > Before I will try to do push request, could you answer me if it is
> >      > acceptable solution according to your architecture concept? If
> not,
> >      > could you give me some tips how to resolve it in other way? I
> >     care about
> >      > this fix before 9. release.
> >      >
> >      > Kind Regards,
> >      > Marek Zupnik
> >      >
> >      >
> >      > _______________________________________________
> >      > wildfly-dev mailing list
> >      > wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
> >      > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >      >
> >
> >
> >     _______________________________________________
> >     wildfly-dev mailing list
> >     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
> >     https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> >
> >
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> _______________________________________________
> 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/20140319/5a7a938a/attachment-0001.html 

From hpehl at redhat.com  Wed Mar 19 19:20:06 2014
From: hpehl at redhat.com (Harald Pehl)
Date: Thu, 20 Mar 2014 00:20:06 +0100
Subject: [wildfly-dev] Local Search for the Admin Console
Message-ID: <104DC106-FA37-4DB0-9867-6B8B75B91A5F@redhat.com>

During the F2F meeting in Brno Heiko and I started a little experiment: Local search for the Admin Console. The idea is to have a search index in the browser's local storage which is used to enable a "search as you type" feature. 

With the introduction of RBAC, all views were annotated with resource addresses. We reuse this information to setup an index over those addresses. The description of the r-r-d operation is extracted, tokenized and stored in the index. In addition it's possible to programmatically assign keywords to selected views. Keywords are a way to boost views in the search results. We did that for prominent views like the deployment browser.   

The index is built lazily when the user enters the search for the first time. In a typical environment this takes only a few seconds. Once the index is ready, it is stored in the local storage using the language, the operation mode (standalone / domain) and the model version as key. The size of the index is about 70 KB (for domain mode).

Under the hood the index is built using [1]. As a little extra you can reach the local search using a shortcut (Cmd+. / Ctrl+.) - therefore [2] is used. 

I found some time to polish the local search and am quite happy with the result. I'd like to add this feature to WildFly 8.0.1. If you want to take a look, grab the latest snapshot from [3] and replace the default console resources under <WF_HOME>/modules/system/layers/base/org/jboss/as/console/main/. 

What do you think?

[1] https://github.com/olivernn/lunr.js
[2] https://github.com/ccampbell/mousetrap
[3] https://repository.jboss.org/nexus/service/local/artifact/maven/redirect?r=snapshots&g=org.jboss.as&a=jboss-as-console&v=2.3.0-SNAPSHOT&e=jar&c=resources

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



From jgreene at redhat.com  Wed Mar 19 21:32:25 2014
From: jgreene at redhat.com (Jason T. Greene)
Date: Wed, 19 Mar 2014 21:32:25 -0400 (EDT)
Subject: [wildfly-dev] Support for PKCS12 keystores in Security Realms
In-Reply-To: <CAGk6hheSozAbreWMyeEA4P5zx+t1y4stfbBxyn6Hr4_Wcc_LeA@mail.gmail.com>
References: <CAGk6hheh0PcOFszcsq4EGV6SqY3NCWYC3A-XaV8B3b6bCTnROg@mail.gmail.com>
	<5328642D.100@redhat.com>
	<CAGk6hhcVCuymoQtXcLnu3wjtfW6yec+QNdszj9BQM3W9mOdq7g@mail.gmail.com>
	<53287E18.4080900@jboss.com>
	<CAGk6hheSozAbreWMyeEA4P5zx+t1y4stfbBxyn6Hr4_Wcc_LeA@mail.gmail.com>
Message-ID: <A5C3337F-B8F8-4919-AFAC-63F90BFDAC2C@redhat.com>

Since this change looks minor, and it comes from a community member I am inclined to allow into 8.0.1.

How bad is the conflict for the other change you are referring to Darran?

> On Mar 19, 2014, at 5:43 PM, Marek ?upnik <marek.zupnik at gmail.com> wrote:
> 
> Hi,
> 
> Darran, I understand your point of view, but stable version of 9 will be not released tomorrow. Lack of pkcs12 support in 8 is a major issue, not to mention that in AS 7 I was able to use this format for https private key. I think it will be useful to fix it yet in 8, even thought the code with a fix will be thrown away in 9.
> 
> I made a pull request with a fix (https://github.com/wildfly/wildfly/pull/6062). It is up to you what you do with it.
> 
> Thank you for your answers and clarifications.
> 
> Kind Regards,
> Marek Zupnik
> 
> 
> 2014-03-18 18:10 GMT+01:00 Darran Lofthouse <darran.lofthouse at jboss.com>:
>> I will have another look if I get a chance to get something into 8 but
>> in reality a related change in this area (that completely conflicts with
>> your changes) was pushed to 9 as the consensus was we did not want the
>> configuration model in this area changing before WildFLy 9.
>> 
>> On 18/03/14 16:30, Marek ?upnik wrote:
>> > Hi,
>> >
>> > Thank You Brian for your comments. I'll try to apply them to my code. I
>> > ask if I will have further questions about it.
>> >
>> > @Darran, I have a question for you. I wasn't looking into development
>> > branch so I haven't known about the changes. Is it possible that pkcs12
>> > support will be merged in Wildfly 8? If not, could my change be merged
>> > earlier? Otherwise, I'm forced to maintain my version of Wildfly untill
>> > no 9 will be released.
>> >
>> > Kind Regards,
>> > Marek Zupnik
>> >
>> >
>> > 2014-03-18 16:20 GMT+01:00 Brian Stansberry <brian.stansberry at redhat.com
>> > <mailto:brian.stansberry at redhat.com>>:
>> >
>> >     Hi Marek,
>> >
>> >     Welcome!
>> >
>> >     I'm going to make a few comments on github re: some minor details of
>> >     your commit. But please keep an eye on this list for your more general
>> >     question about whether this is how we want to go about this. I believe
>> >     Darran Lofthouse was planning some work in this area so he may have some
>> >     input.
>> >
>> >     Cheers,
>> >
>> >     --
>> >     Brian Stansberry
>> >     Senior Principal Software Engineer
>> >     JBoss by Red Hat
>> >
>> >     On 3/18/14, 8:59 AM, Marek ?upnik wrote:
>> >      > Hi,
>> >      >
>> >      > I'm Marek Zupnik. It's my first message for this list but for
>> >     some time
>> >      > I've been keeping my eyes on what's happening in wildfly development.
>> >      >
>> >      > I'm writing regarding to the issue about lack of support for PKCS12
>> >      > keystores in security realms
>> >      > (https://issues.jboss.org/browse/WFLY-2229). I wanted to migrate my
>> >      > system to Wildfly but in my case it is a blocking issue. I have
>> >     to use
>> >      > keystore in PKCS12 format in which I'm storing, among others, https
>> >      > private key.
>> >      >
>> >      > I forked Wildfly on github and made a simple fix for this issue which
>> >      > consists in additional parameter "keystore-type" for keystore
>> >      > configuration. Based on this parameter I'm able to create appropriate
>> >      > keystore type.
>> >      >
>> >      > Config sample:
>> >      > <keystore path="keystore.p12" relative-to="jboss.server.config.dir"
>> >      > keystore-password="xxx" keystore-type="PKCS12" alias="https"/>
>> >      >
>> >      > The changes are in my fork on github (keystore_type branch):
>> >      > https://github.com/mzupnik/wildfly/tree/keystore_type
>> >      >
>> >      > Before I will try to do push request, could you answer me if it is
>> >      > acceptable solution according to your architecture concept? If not,
>> >      > could you give me some tips how to resolve it in other way? I
>> >     care about
>> >      > this fix before 9. release.
>> >      >
>> >      > Kind Regards,
>> >      > Marek Zupnik
>> >      >
>> >      >
>> >      > _______________________________________________
>> >      > wildfly-dev mailing list
>> >      > wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>> >      > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >      >
>> >
>> >
>> >     _______________________________________________
>> >     wildfly-dev mailing list
>> >     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>> >     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > wildfly-dev mailing list
>> > wildfly-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >
>> _______________________________________________
>> 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/20140319/389fb842/attachment.html 

From jgreene at redhat.com  Wed Mar 19 21:35:27 2014
From: jgreene at redhat.com (Jason T. Greene)
Date: Wed, 19 Mar 2014 21:35:27 -0400 (EDT)
Subject: [wildfly-dev] Local Search for the Admin Console
In-Reply-To: <104DC106-FA37-4DB0-9867-6B8B75B91A5F@redhat.com>
References: <104DC106-FA37-4DB0-9867-6B8B75B91A5F@redhat.com>
Message-ID: <2392340E-B83C-4CE2-97E1-C0B3D7E41421@redhat.com>

Sounds good to me, as long as you are confident in the stability of the version we upgrade to.

> On Mar 19, 2014, at 6:21 PM, Harald Pehl <hpehl at redhat.com> wrote:
> 
> During the F2F meeting in Brno Heiko and I started a little experiment: Local search for the Admin Console. The idea is to have a search index in the browser's local storage which is used to enable a "search as you type" feature. 
> 
> With the introduction of RBAC, all views were annotated with resource addresses. We reuse this information to setup an index over those addresses. The description of the r-r-d operation is extracted, tokenized and stored in the index. In addition it's possible to programmatically assign keywords to selected views. Keywords are a way to boost views in the search results. We did that for prominent views like the deployment browser.   
> 
> The index is built lazily when the user enters the search for the first time. In a typical environment this takes only a few seconds. Once the index is ready, it is stored in the local storage using the language, the operation mode (standalone / domain) and the model version as key. The size of the index is about 70 KB (for domain mode).
> 
> Under the hood the index is built using [1]. As a little extra you can reach the local search using a shortcut (Cmd+. / Ctrl+.) - therefore [2] is used. 
> 
> I found some time to polish the local search and am quite happy with the result. I'd like to add this feature to WildFly 8.0.1. If you want to take a look, grab the latest snapshot from [3] and replace the default console resources under <WF_HOME>/modules/system/layers/base/org/jboss/as/console/main/.
> 
> What do you think?
> 
> [1] https://github.com/olivernn/lunr.js
> [2] https://github.com/ccampbell/mousetrap
> [3] https://repository.jboss.org/nexus/service/local/artifact/maven/redirect?r=snapshots&g=org.jboss.as&a=jboss-as-console&v=2.3.0-SNAPSHOT&e=jar&c=resources
> 
> ---
> 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


From brian.stansberry at redhat.com  Wed Mar 19 22:31:28 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 19 Mar 2014 21:31:28 -0500
Subject: [wildfly-dev] Support for PKCS12 keystores in Security Realms
In-Reply-To: <A5C3337F-B8F8-4919-AFAC-63F90BFDAC2C@redhat.com>
References: <CAGk6hheh0PcOFszcsq4EGV6SqY3NCWYC3A-XaV8B3b6bCTnROg@mail.gmail.com>	<5328642D.100@redhat.com>	<CAGk6hhcVCuymoQtXcLnu3wjtfW6yec+QNdszj9BQM3W9mOdq7g@mail.gmail.com>	<53287E18.4080900@jboss.com>	<CAGk6hheSozAbreWMyeEA4P5zx+t1y4stfbBxyn6Hr4_Wcc_LeA@mail.gmail.com>
	<A5C3337F-B8F8-4919-AFAC-63F90BFDAC2C@redhat.com>
Message-ID: <532A5300.1050706@redhat.com>

It's very similar to the existing commit for WF9/EAP6.3 [1], so if we 
want the feature in 8.0.1 we should just merge the open PR to bump the 
core schema versions[2] and then backport that commit.

[1] 
https://github.com/kabir/wildfly/commit/3f22fcfa81975bf9951003889c4d4af1d2dbd319

[2] https://github.com/wildfly/wildfly/pull/5913

On 3/19/14, 8:32 PM, Jason T. Greene wrote:
> Since this change looks minor, and it comes from a community member I am
> inclined to allow into 8.0.1.
>
> How bad is the conflict for the other change you are referring to Darran?
>
> On Mar 19, 2014, at 5:43 PM, Marek ?upnik <marek.zupnik at gmail.com
> <mailto:marek.zupnik at gmail.com>> wrote:
>
>> Hi,
>>
>> Darran, I understand your point of view, but stable version of 9 will
>> be not released tomorrow. Lack of pkcs12 support in 8 is a major
>> issue, not to mention that in AS 7 I was able to use this format for
>> https private key. I think it will be useful to fix it yet in 8, even
>> thought the code with a fix will be thrown away in 9.
>>
>> I made a pull request with a fix
>> (https://github.com/wildfly/wildfly/pull/6062). It is up to you what
>> you do with it.
>>
>> Thank you for your answers and clarifications.
>>
>> Kind Regards,
>> Marek Zupnik
>>
>>
>> 2014-03-18 18:10 GMT+01:00 Darran Lofthouse
>> <darran.lofthouse at jboss.com <mailto:darran.lofthouse at jboss.com>>:
>>
>>     I will have another look if I get a chance to get something into 8 but
>>     in reality a related change in this area (that completely
>>     conflicts with
>>     your changes) was pushed to 9 as the consensus was we did not want the
>>     configuration model in this area changing before WildFLy 9.
>>
>>     On 18/03/14 16:30, Marek ?upnik wrote:
>>     > Hi,
>>     >
>>     > Thank You Brian for your comments. I'll try to apply them to my
>>     code. I
>>     > ask if I will have further questions about it.
>>     >
>>     > @Darran, I have a question for you. I wasn't looking into
>>     development
>>     > branch so I haven't known about the changes. Is it possible that
>>     pkcs12
>>     > support will be merged in Wildfly 8? If not, could my change be
>>     merged
>>     > earlier? Otherwise, I'm forced to maintain my version of Wildfly
>>     untill
>>     > no 9 will be released.
>>     >
>>     > Kind Regards,
>>     > Marek Zupnik
>>     >
>>     >
>>     > 2014-03-18 16:20 GMT+01:00 Brian Stansberry
>>     <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>
>>     > <mailto:brian.stansberry at redhat.com
>>     <mailto:brian.stansberry at redhat.com>>>:
>>     >
>>     >     Hi Marek,
>>     >
>>     >     Welcome!
>>     >
>>     >     I'm going to make a few comments on github re: some minor
>>     details of
>>     >     your commit. But please keep an eye on this list for your
>>     more general
>>     >     question about whether this is how we want to go about this.
>>     I believe
>>     >     Darran Lofthouse was planning some work in this area so he
>>     may have some
>>     >     input.
>>     >
>>     >     Cheers,
>>     >
>>     >     --
>>     >     Brian Stansberry
>>     >     Senior Principal Software Engineer
>>     >     JBoss by Red Hat
>>     >
>>     >     On 3/18/14, 8:59 AM, Marek ?upnik wrote:
>>     >      > Hi,
>>     >      >
>>     >      > I'm Marek Zupnik. It's my first message for this list but for
>>     >     some time
>>     >      > I've been keeping my eyes on what's happening in wildfly
>>     development.
>>     >      >
>>     >      > I'm writing regarding to the issue about lack of support
>>     for PKCS12
>>     >      > keystores in security realms
>>     >      > (https://issues.jboss.org/browse/WFLY-2229). I wanted to
>>     migrate my
>>     >      > system to Wildfly but in my case it is a blocking issue.
>>     I have
>>     >     to use
>>     >      > keystore in PKCS12 format in which I'm storing, among
>>     others, https
>>     >      > private key.
>>     >      >
>>     >      > I forked Wildfly on github and made a simple fix for this
>>     issue which
>>     >      > consists in additional parameter "keystore-type" for keystore
>>     >      > configuration. Based on this parameter I'm able to create
>>     appropriate
>>     >      > keystore type.
>>     >      >
>>     >      > Config sample:
>>     >      > <keystore path="keystore.p12"
>>     relative-to="jboss.server.config.dir"
>>     >      > keystore-password="xxx" keystore-type="PKCS12"
>>     alias="https"/>
>>     >      >
>>     >      > The changes are in my fork on github (keystore_type branch):
>>     >      > https://github.com/mzupnik/wildfly/tree/keystore_type
>>     >      >
>>     >      > Before I will try to do push request, could you answer me
>>     if it is
>>     >      > acceptable solution according to your architecture
>>     concept? If not,
>>     >      > could you give me some tips how to resolve it in other way? I
>>     >     care about
>>     >      > this fix before 9. release.
>>     >      >
>>     >      > Kind Regards,
>>     >      > Marek Zupnik
>>     >      >
>>     >      >
>>     >      > _______________________________________________
>>     >      > wildfly-dev mailing list
>>     >      > wildfly-dev at lists.jboss.org
>>     <mailto:wildfly-dev at lists.jboss.org>
>>     <mailto:wildfly-dev at lists.jboss.org
>>     <mailto:wildfly-dev at lists.jboss.org>>
>>     >      > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>     >      >
>>     >
>>     >
>>     >     _______________________________________________
>>     >     wildfly-dev mailing list
>>     > wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>     <mailto:wildfly-dev at lists.jboss.org
>>     <mailto:wildfly-dev at lists.jboss.org>>
>>     > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>     >
>>     >
>>     >
>>     >
>>     > _______________________________________________
>>     > wildfly-dev mailing list
>>     > wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>     > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>     >
>>     _______________________________________________
>>     wildfly-dev mailing list
>>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


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

From darran.lofthouse at jboss.com  Thu Mar 20 07:18:27 2014
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Thu, 20 Mar 2014 11:18:27 +0000
Subject: [wildfly-dev] Support for PKCS12 keystores in Security Realms
In-Reply-To: <532A5300.1050706@redhat.com>
References: <CAGk6hheh0PcOFszcsq4EGV6SqY3NCWYC3A-XaV8B3b6bCTnROg@mail.gmail.com>	<5328642D.100@redhat.com>	<CAGk6hhcVCuymoQtXcLnu3wjtfW6yec+QNdszj9BQM3W9mOdq7g@mail.gmail.com>	<53287E18.4080900@jboss.com>	<CAGk6hheSozAbreWMyeEA4P5zx+t1y4stfbBxyn6Hr4_Wcc_LeA@mail.gmail.com>	<A5C3337F-B8F8-4919-AFAC-63F90BFDAC2C@redhat.com>
	<532A5300.1050706@redhat.com>
Message-ID: <532ACE83.2090008@jboss.com>

I am just tagging a JBoss Negotiation release then I will switch to 
getting this backported.

Once backported it may be easier if we just delete the commit from 
Kabir's branch when he rebases.

 From this point forward can we please push less to WildFly 9? ;-)  I 
already lost time as I started to work on this for 8 and was then 
diverted by other engineers to push it to 9, I am now going to spend 
time pulling it back to 8!

Regards,
Darran Lofthouse.


On 20/03/14 02:31, Brian Stansberry wrote:
> It's very similar to the existing commit for WF9/EAP6.3 [1], so if we
> want the feature in 8.0.1 we should just merge the open PR to bump the
> core schema versions[2] and then backport that commit.
>
> [1]
> https://github.com/kabir/wildfly/commit/3f22fcfa81975bf9951003889c4d4af1d2dbd319
>
> [2] https://github.com/wildfly/wildfly/pull/5913
>
> On 3/19/14, 8:32 PM, Jason T. Greene wrote:
>> Since this change looks minor, and it comes from a community member I am
>> inclined to allow into 8.0.1.
>>
>> How bad is the conflict for the other change you are referring to Darran?
>>
>> On Mar 19, 2014, at 5:43 PM, Marek ?upnik <marek.zupnik at gmail.com
>> <mailto:marek.zupnik at gmail.com>> wrote:
>>
>>> Hi,
>>>
>>> Darran, I understand your point of view, but stable version of 9 will
>>> be not released tomorrow. Lack of pkcs12 support in 8 is a major
>>> issue, not to mention that in AS 7 I was able to use this format for
>>> https private key. I think it will be useful to fix it yet in 8, even
>>> thought the code with a fix will be thrown away in 9.
>>>
>>> I made a pull request with a fix
>>> (https://github.com/wildfly/wildfly/pull/6062). It is up to you what
>>> you do with it.
>>>
>>> Thank you for your answers and clarifications.
>>>
>>> Kind Regards,
>>> Marek Zupnik
>>>
>>>
>>> 2014-03-18 18:10 GMT+01:00 Darran Lofthouse
>>> <darran.lofthouse at jboss.com <mailto:darran.lofthouse at jboss.com>>:
>>>
>>>      I will have another look if I get a chance to get something into 8 but
>>>      in reality a related change in this area (that completely
>>>      conflicts with
>>>      your changes) was pushed to 9 as the consensus was we did not want the
>>>      configuration model in this area changing before WildFLy 9.
>>>
>>>      On 18/03/14 16:30, Marek ?upnik wrote:
>>>      > Hi,
>>>      >
>>>      > Thank You Brian for your comments. I'll try to apply them to my
>>>      code. I
>>>      > ask if I will have further questions about it.
>>>      >
>>>      > @Darran, I have a question for you. I wasn't looking into
>>>      development
>>>      > branch so I haven't known about the changes. Is it possible that
>>>      pkcs12
>>>      > support will be merged in Wildfly 8? If not, could my change be
>>>      merged
>>>      > earlier? Otherwise, I'm forced to maintain my version of Wildfly
>>>      untill
>>>      > no 9 will be released.
>>>      >
>>>      > Kind Regards,
>>>      > Marek Zupnik
>>>      >
>>>      >
>>>      > 2014-03-18 16:20 GMT+01:00 Brian Stansberry
>>>      <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>
>>>      > <mailto:brian.stansberry at redhat.com
>>>      <mailto:brian.stansberry at redhat.com>>>:
>>>      >
>>>      >     Hi Marek,
>>>      >
>>>      >     Welcome!
>>>      >
>>>      >     I'm going to make a few comments on github re: some minor
>>>      details of
>>>      >     your commit. But please keep an eye on this list for your
>>>      more general
>>>      >     question about whether this is how we want to go about this.
>>>      I believe
>>>      >     Darran Lofthouse was planning some work in this area so he
>>>      may have some
>>>      >     input.
>>>      >
>>>      >     Cheers,
>>>      >
>>>      >     --
>>>      >     Brian Stansberry
>>>      >     Senior Principal Software Engineer
>>>      >     JBoss by Red Hat
>>>      >
>>>      >     On 3/18/14, 8:59 AM, Marek ?upnik wrote:
>>>      >      > Hi,
>>>      >      >
>>>      >      > I'm Marek Zupnik. It's my first message for this list but for
>>>      >     some time
>>>      >      > I've been keeping my eyes on what's happening in wildfly
>>>      development.
>>>      >      >
>>>      >      > I'm writing regarding to the issue about lack of support
>>>      for PKCS12
>>>      >      > keystores in security realms
>>>      >      > (https://issues.jboss.org/browse/WFLY-2229). I wanted to
>>>      migrate my
>>>      >      > system to Wildfly but in my case it is a blocking issue.
>>>      I have
>>>      >     to use
>>>      >      > keystore in PKCS12 format in which I'm storing, among
>>>      others, https
>>>      >      > private key.
>>>      >      >
>>>      >      > I forked Wildfly on github and made a simple fix for this
>>>      issue which
>>>      >      > consists in additional parameter "keystore-type" for keystore
>>>      >      > configuration. Based on this parameter I'm able to create
>>>      appropriate
>>>      >      > keystore type.
>>>      >      >
>>>      >      > Config sample:
>>>      >      > <keystore path="keystore.p12"
>>>      relative-to="jboss.server.config.dir"
>>>      >      > keystore-password="xxx" keystore-type="PKCS12"
>>>      alias="https"/>
>>>      >      >
>>>      >      > The changes are in my fork on github (keystore_type branch):
>>>      >      > https://github.com/mzupnik/wildfly/tree/keystore_type
>>>      >      >
>>>      >      > Before I will try to do push request, could you answer me
>>>      if it is
>>>      >      > acceptable solution according to your architecture
>>>      concept? If not,
>>>      >      > could you give me some tips how to resolve it in other way? I
>>>      >     care about
>>>      >      > this fix before 9. release.
>>>      >      >
>>>      >      > Kind Regards,
>>>      >      > Marek Zupnik
>>>      >      >
>>>      >      >
>>>      >      > _______________________________________________
>>>      >      > wildfly-dev mailing list
>>>      >      > wildfly-dev at lists.jboss.org
>>>      <mailto:wildfly-dev at lists.jboss.org>
>>>      <mailto:wildfly-dev at lists.jboss.org
>>>      <mailto:wildfly-dev at lists.jboss.org>>
>>>      >      > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>      >      >
>>>      >
>>>      >
>>>      >     _______________________________________________
>>>      >     wildfly-dev mailing list
>>>      > wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>      <mailto:wildfly-dev at lists.jboss.org
>>>      <mailto:wildfly-dev at lists.jboss.org>>
>>>      > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>      >
>>>      >
>>>      >
>>>      >
>>>      > _______________________________________________
>>>      > wildfly-dev mailing list
>>>      > wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>      > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>      >
>>>      _______________________________________________
>>>      wildfly-dev mailing list
>>>      wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>      https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>

From darran.lofthouse at jboss.com  Thu Mar 20 13:54:50 2014
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Thu, 20 Mar 2014 17:54:50 +0000
Subject: [wildfly-dev] Support for PKCS12 keystores in Security Realms
In-Reply-To: <532ACE83.2090008@jboss.com>
References: <CAGk6hheh0PcOFszcsq4EGV6SqY3NCWYC3A-XaV8B3b6bCTnROg@mail.gmail.com>	<5328642D.100@redhat.com>	<CAGk6hhcVCuymoQtXcLnu3wjtfW6yec+QNdszj9BQM3W9mOdq7g@mail.gmail.com>	<53287E18.4080900@jboss.com>	<CAGk6hheSozAbreWMyeEA4P5zx+t1y4stfbBxyn6Hr4_Wcc_LeA@mail.gmail.com>	<A5C3337F-B8F8-4919-AFAC-63F90BFDAC2C@redhat.com>	<532A5300.1050706@redhat.com>
	<532ACE83.2090008@jboss.com>
Message-ID: <532B2B6A.70000@jboss.com>

I have updated the pull request for the schema version bump, once that 
one is in I will get pull requests in for backporting the upstream 
changes and enabling support for alternative file based keystores such 
as PKCS#12

Regards,
Darran Lofthouse.


On 20/03/14 11:18, Darran Lofthouse wrote:
> I am just tagging a JBoss Negotiation release then I will switch to
> getting this backported.
>
> Once backported it may be easier if we just delete the commit from
> Kabir's branch when he rebases.
>
>   From this point forward can we please push less to WildFly 9? ;-)  I
> already lost time as I started to work on this for 8 and was then
> diverted by other engineers to push it to 9, I am now going to spend
> time pulling it back to 8!
>
> Regards,
> Darran Lofthouse.
>
>
> On 20/03/14 02:31, Brian Stansberry wrote:
>> It's very similar to the existing commit for WF9/EAP6.3 [1], so if we
>> want the feature in 8.0.1 we should just merge the open PR to bump the
>> core schema versions[2] and then backport that commit.
>>
>> [1]
>> https://github.com/kabir/wildfly/commit/3f22fcfa81975bf9951003889c4d4af1d2dbd319
>>
>> [2] https://github.com/wildfly/wildfly/pull/5913
>>
>> On 3/19/14, 8:32 PM, Jason T. Greene wrote:
>>> Since this change looks minor, and it comes from a community member I am
>>> inclined to allow into 8.0.1.
>>>
>>> How bad is the conflict for the other change you are referring to Darran?
>>>
>>> On Mar 19, 2014, at 5:43 PM, Marek ?upnik <marek.zupnik at gmail.com
>>> <mailto:marek.zupnik at gmail.com>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Darran, I understand your point of view, but stable version of 9 will
>>>> be not released tomorrow. Lack of pkcs12 support in 8 is a major
>>>> issue, not to mention that in AS 7 I was able to use this format for
>>>> https private key. I think it will be useful to fix it yet in 8, even
>>>> thought the code with a fix will be thrown away in 9.
>>>>
>>>> I made a pull request with a fix
>>>> (https://github.com/wildfly/wildfly/pull/6062). It is up to you what
>>>> you do with it.
>>>>
>>>> Thank you for your answers and clarifications.
>>>>
>>>> Kind Regards,
>>>> Marek Zupnik
>>>>
>>>>
>>>> 2014-03-18 18:10 GMT+01:00 Darran Lofthouse
>>>> <darran.lofthouse at jboss.com <mailto:darran.lofthouse at jboss.com>>:
>>>>
>>>>       I will have another look if I get a chance to get something into 8 but
>>>>       in reality a related change in this area (that completely
>>>>       conflicts with
>>>>       your changes) was pushed to 9 as the consensus was we did not want the
>>>>       configuration model in this area changing before WildFLy 9.
>>>>
>>>>       On 18/03/14 16:30, Marek ?upnik wrote:
>>>>       > Hi,
>>>>       >
>>>>       > Thank You Brian for your comments. I'll try to apply them to my
>>>>       code. I
>>>>       > ask if I will have further questions about it.
>>>>       >
>>>>       > @Darran, I have a question for you. I wasn't looking into
>>>>       development
>>>>       > branch so I haven't known about the changes. Is it possible that
>>>>       pkcs12
>>>>       > support will be merged in Wildfly 8? If not, could my change be
>>>>       merged
>>>>       > earlier? Otherwise, I'm forced to maintain my version of Wildfly
>>>>       untill
>>>>       > no 9 will be released.
>>>>       >
>>>>       > Kind Regards,
>>>>       > Marek Zupnik
>>>>       >
>>>>       >
>>>>       > 2014-03-18 16:20 GMT+01:00 Brian Stansberry
>>>>       <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>
>>>>       > <mailto:brian.stansberry at redhat.com
>>>>       <mailto:brian.stansberry at redhat.com>>>:
>>>>       >
>>>>       >     Hi Marek,
>>>>       >
>>>>       >     Welcome!
>>>>       >
>>>>       >     I'm going to make a few comments on github re: some minor
>>>>       details of
>>>>       >     your commit. But please keep an eye on this list for your
>>>>       more general
>>>>       >     question about whether this is how we want to go about this.
>>>>       I believe
>>>>       >     Darran Lofthouse was planning some work in this area so he
>>>>       may have some
>>>>       >     input.
>>>>       >
>>>>       >     Cheers,
>>>>       >
>>>>       >     --
>>>>       >     Brian Stansberry
>>>>       >     Senior Principal Software Engineer
>>>>       >     JBoss by Red Hat
>>>>       >
>>>>       >     On 3/18/14, 8:59 AM, Marek ?upnik wrote:
>>>>       >      > Hi,
>>>>       >      >
>>>>       >      > I'm Marek Zupnik. It's my first message for this list but for
>>>>       >     some time
>>>>       >      > I've been keeping my eyes on what's happening in wildfly
>>>>       development.
>>>>       >      >
>>>>       >      > I'm writing regarding to the issue about lack of support
>>>>       for PKCS12
>>>>       >      > keystores in security realms
>>>>       >      > (https://issues.jboss.org/browse/WFLY-2229). I wanted to
>>>>       migrate my
>>>>       >      > system to Wildfly but in my case it is a blocking issue.
>>>>       I have
>>>>       >     to use
>>>>       >      > keystore in PKCS12 format in which I'm storing, among
>>>>       others, https
>>>>       >      > private key.
>>>>       >      >
>>>>       >      > I forked Wildfly on github and made a simple fix for this
>>>>       issue which
>>>>       >      > consists in additional parameter "keystore-type" for keystore
>>>>       >      > configuration. Based on this parameter I'm able to create
>>>>       appropriate
>>>>       >      > keystore type.
>>>>       >      >
>>>>       >      > Config sample:
>>>>       >      > <keystore path="keystore.p12"
>>>>       relative-to="jboss.server.config.dir"
>>>>       >      > keystore-password="xxx" keystore-type="PKCS12"
>>>>       alias="https"/>
>>>>       >      >
>>>>       >      > The changes are in my fork on github (keystore_type branch):
>>>>       >      > https://github.com/mzupnik/wildfly/tree/keystore_type
>>>>       >      >
>>>>       >      > Before I will try to do push request, could you answer me
>>>>       if it is
>>>>       >      > acceptable solution according to your architecture
>>>>       concept? If not,
>>>>       >      > could you give me some tips how to resolve it in other way? I
>>>>       >     care about
>>>>       >      > this fix before 9. release.
>>>>       >      >
>>>>       >      > Kind Regards,
>>>>       >      > Marek Zupnik
>>>>       >      >
>>>>       >      >
>>>>       >      > _______________________________________________
>>>>       >      > wildfly-dev mailing list
>>>>       >      > wildfly-dev at lists.jboss.org
>>>>       <mailto:wildfly-dev at lists.jboss.org>
>>>>       <mailto:wildfly-dev at lists.jboss.org
>>>>       <mailto:wildfly-dev at lists.jboss.org>>
>>>>       >      > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>       >      >
>>>>       >
>>>>       >
>>>>       >     _______________________________________________
>>>>       >     wildfly-dev mailing list
>>>>       > wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>>       <mailto:wildfly-dev at lists.jboss.org
>>>>       <mailto:wildfly-dev at lists.jboss.org>>
>>>>       > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>       >
>>>>       >
>>>>       >
>>>>       >
>>>>       > _______________________________________________
>>>>       > wildfly-dev mailing list
>>>>       > wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>>       > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>       >
>>>>       _______________________________________________
>>>>       wildfly-dev mailing list
>>>>       wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>>       https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>
> _______________________________________________
> 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 Mar 21 06:31:35 2014
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Fri, 21 Mar 2014 10:31:35 +0000
Subject: [wildfly-dev] Urgent Pull Request
Message-ID: <532C1507.5030208@jboss.com>

Hello all,

Could we please give some priority to getting this pull request in?

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

I have some follow up changes dependent on this one.

Thanks,

Regards,
Darran Lofthouse.

From arun.gupta at gmail.com  Fri Mar 21 14:27:05 2014
From: arun.gupta at gmail.com (Arun Gupta)
Date: Fri, 21 Mar 2014 19:27:05 +0100
Subject: [wildfly-dev] Java EE 7 tests failing on WildFly trunk
Message-ID: <CAGBoHQUNgbS0xEfSChsjm+P2-8Pg9aqQNucfYTwDF7kmjMMFFw@mail.gmail.com>

Java EE 7 CI job on WildFly trunk is failing:

https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20WildFly-cb/155/console

Here is the error message:

Started 45 of 56 services (22 services are lazy, passive or on-demand)
+ wildfly-8.0.1.Final-SNAPSHOT/bin/jboss-cli.sh --connect
'--commands=/subsystem=messaging/hornetq-server=default:write-attribute(name=journal-type,value=NIO),:reload(admin-only=false)'
Error: Could not find or load main class EE
Process leaked file descriptors. See
http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build
for more information
Build step 'Execute shell' marked build as failure

Arun

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


From david.lloyd at redhat.com  Fri Mar 21 14:45:30 2014
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Fri, 21 Mar 2014 13:45:30 -0500
Subject: [wildfly-dev] Java EE 7 tests failing on WildFly trunk
In-Reply-To: <CAGBoHQUNgbS0xEfSChsjm+P2-8Pg9aqQNucfYTwDF7kmjMMFFw@mail.gmail.com>
References: <CAGBoHQUNgbS0xEfSChsjm+P2-8Pg9aqQNucfYTwDF7kmjMMFFw@mail.gmail.com>
Message-ID: <532C88CA.7050304@redhat.com>

On 03/21/2014 01:27 PM, Arun Gupta wrote:
> Java EE 7 CI job on WildFly trunk is failing:
>
> https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20WildFly-cb/155/console
>
> Here is the error message:
>
> Started 45 of 56 services (22 services are lazy, passive or on-demand)
> + wildfly-8.0.1.Final-SNAPSHOT/bin/jboss-cli.sh --connect
> '--commands=/subsystem=messaging/hornetq-server=default:write-attribute(name=journal-type,value=NIO),:reload(admin-only=false)'
> Error: Could not find or load main class EE
> Process leaked file descriptors. See
> http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build
> for more information
> Build step 'Execute shell' marked build as failure

Looks like a possible regression in standalone.sh due to there being a 
space in the startup path.

As a workaround you could change your workspace name from "Java EE 7 
Samples on WildFly-cb" to e.g. "java-ee-7-samples-on-wildfly-cb" or 
similar (with no spaces).


-- 
- DML

From arun.gupta at gmail.com  Fri Mar 21 15:05:09 2014
From: arun.gupta at gmail.com (Arun Gupta)
Date: Fri, 21 Mar 2014 20:05:09 +0100
Subject: [wildfly-dev] Java EE 7 tests failing on WildFly trunk
In-Reply-To: <532C88CA.7050304@redhat.com>
References: <CAGBoHQUNgbS0xEfSChsjm+P2-8Pg9aqQNucfYTwDF7kmjMMFFw@mail.gmail.com>
	<532C88CA.7050304@redhat.com>
Message-ID: <CAGBoHQVeggdYHN5m=Gru2Z0gH+usJ5o9M6O04dgRAgA7HYjYgg@mail.gmail.com>

Triggered a new build at:

https://arungupta.ci.cloudbees.com/job/javaee7-samples-on-wildfly-cb/156/

Also filed https://issues.jboss.org/browse/WFLY-3151 for tracking.

Arun

On Fri, Mar 21, 2014 at 7:45 PM, David M. Lloyd <david.lloyd at redhat.com> wrote:
> On 03/21/2014 01:27 PM, Arun Gupta wrote:
>> Java EE 7 CI job on WildFly trunk is failing:
>>
>> https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20WildFly-cb/155/console
>>
>> Here is the error message:
>>
>> Started 45 of 56 services (22 services are lazy, passive or on-demand)
>>  [0m+ wildfly-8.0.1.Final-SNAPSHOT/bin/jboss-cli.sh --connect
>> '--commands=/subsystem=messaging/hornetq-server=default:write-attribute(name=journal-type,value=NIO),:reload(admin-only=false)'
>> Error: Could not find or load main class EE
>> Process leaked file descriptors. See
>> http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build
>> for more information
>> Build step 'Execute shell' marked build as failure
>
> Looks like a possible regression in standalone.sh due to there being a
> space in the startup path.
>
> As a workaround you could change your workspace name from "Java EE 7
> Samples on WildFly-cb" to e.g. "java-ee-7-samples-on-wildfly-cb" or
> similar (with no spaces).
>
>
> --
> - DML
> _______________________________________________
> 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 darran.lofthouse at jboss.com  Mon Mar 24 07:58:20 2014
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Mon, 24 Mar 2014 11:58:20 +0000
Subject: [wildfly-dev] Support for PKCS12 keystores in Security Realms
In-Reply-To: <532B2B6A.70000@jboss.com>
References: <CAGk6hheh0PcOFszcsq4EGV6SqY3NCWYC3A-XaV8B3b6bCTnROg@mail.gmail.com>	<5328642D.100@redhat.com>	<CAGk6hhcVCuymoQtXcLnu3wjtfW6yec+QNdszj9BQM3W9mOdq7g@mail.gmail.com>	<53287E18.4080900@jboss.com>	<CAGk6hheSozAbreWMyeEA4P5zx+t1y4stfbBxyn6Hr4_Wcc_LeA@mail.gmail.com>	<A5C3337F-B8F8-4919-AFAC-63F90BFDAC2C@redhat.com>	<532A5300.1050706@redhat.com>
	<532ACE83.2090008@jboss.com> <532B2B6A.70000@jboss.com>
Message-ID: <53301DDC.8000909@jboss.com>

Most of the changes are now in for this, just some final updates to make 
this compatible with alternative file based stores.

On 20/03/14 17:54, Darran Lofthouse wrote:
> I have updated the pull request for the schema version bump, once that
> one is in I will get pull requests in for backporting the upstream
> changes and enabling support for alternative file based keystores such
> as PKCS#12
>
> Regards,
> Darran Lofthouse.
>
>
> On 20/03/14 11:18, Darran Lofthouse wrote:
>> I am just tagging a JBoss Negotiation release then I will switch to
>> getting this backported.
>>
>> Once backported it may be easier if we just delete the commit from
>> Kabir's branch when he rebases.
>>
>>   From this point forward can we please push less to WildFly 9? ;-)  I
>> already lost time as I started to work on this for 8 and was then
>> diverted by other engineers to push it to 9, I am now going to spend
>> time pulling it back to 8!
>>
>> Regards,
>> Darran Lofthouse.
>>
>>
>> On 20/03/14 02:31, Brian Stansberry wrote:
>>> It's very similar to the existing commit for WF9/EAP6.3 [1], so if we
>>> want the feature in 8.0.1 we should just merge the open PR to bump the
>>> core schema versions[2] and then backport that commit.
>>>
>>> [1]
>>> https://github.com/kabir/wildfly/commit/3f22fcfa81975bf9951003889c4d4af1d2dbd319
>>>
>>>
>>> [2] https://github.com/wildfly/wildfly/pull/5913
>>>
>>> On 3/19/14, 8:32 PM, Jason T. Greene wrote:
>>>> Since this change looks minor, and it comes from a community member
>>>> I am
>>>> inclined to allow into 8.0.1.
>>>>
>>>> How bad is the conflict for the other change you are referring to
>>>> Darran?
>>>>
>>>> On Mar 19, 2014, at 5:43 PM, Marek ?upnik <marek.zupnik at gmail.com
>>>> <mailto:marek.zupnik at gmail.com>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Darran, I understand your point of view, but stable version of 9 will
>>>>> be not released tomorrow. Lack of pkcs12 support in 8 is a major
>>>>> issue, not to mention that in AS 7 I was able to use this format for
>>>>> https private key. I think it will be useful to fix it yet in 8, even
>>>>> thought the code with a fix will be thrown away in 9.
>>>>>
>>>>> I made a pull request with a fix
>>>>> (https://github.com/wildfly/wildfly/pull/6062). It is up to you what
>>>>> you do with it.
>>>>>
>>>>> Thank you for your answers and clarifications.
>>>>>
>>>>> Kind Regards,
>>>>> Marek Zupnik
>>>>>
>>>>>
>>>>> 2014-03-18 18:10 GMT+01:00 Darran Lofthouse
>>>>> <darran.lofthouse at jboss.com <mailto:darran.lofthouse at jboss.com>>:
>>>>>
>>>>>       I will have another look if I get a chance to get something
>>>>> into 8 but
>>>>>       in reality a related change in this area (that completely
>>>>>       conflicts with
>>>>>       your changes) was pushed to 9 as the consensus was we did not
>>>>> want the
>>>>>       configuration model in this area changing before WildFLy 9.
>>>>>
>>>>>       On 18/03/14 16:30, Marek ?upnik wrote:
>>>>>       > Hi,
>>>>>       >
>>>>>       > Thank You Brian for your comments. I'll try to apply them
>>>>> to my
>>>>>       code. I
>>>>>       > ask if I will have further questions about it.
>>>>>       >
>>>>>       > @Darran, I have a question for you. I wasn't looking into
>>>>>       development
>>>>>       > branch so I haven't known about the changes. Is it possible
>>>>> that
>>>>>       pkcs12
>>>>>       > support will be merged in Wildfly 8? If not, could my
>>>>> change be
>>>>>       merged
>>>>>       > earlier? Otherwise, I'm forced to maintain my version of
>>>>> Wildfly
>>>>>       untill
>>>>>       > no 9 will be released.
>>>>>       >
>>>>>       > Kind Regards,
>>>>>       > Marek Zupnik
>>>>>       >
>>>>>       >
>>>>>       > 2014-03-18 16:20 GMT+01:00 Brian Stansberry
>>>>>       <brian.stansberry at redhat.com
>>>>> <mailto:brian.stansberry at redhat.com>
>>>>>       > <mailto:brian.stansberry at redhat.com
>>>>>       <mailto:brian.stansberry at redhat.com>>>:
>>>>>       >
>>>>>       >     Hi Marek,
>>>>>       >
>>>>>       >     Welcome!
>>>>>       >
>>>>>       >     I'm going to make a few comments on github re: some minor
>>>>>       details of
>>>>>       >     your commit. But please keep an eye on this list for your
>>>>>       more general
>>>>>       >     question about whether this is how we want to go about
>>>>> this.
>>>>>       I believe
>>>>>       >     Darran Lofthouse was planning some work in this area so he
>>>>>       may have some
>>>>>       >     input.
>>>>>       >
>>>>>       >     Cheers,
>>>>>       >
>>>>>       >     --
>>>>>       >     Brian Stansberry
>>>>>       >     Senior Principal Software Engineer
>>>>>       >     JBoss by Red Hat
>>>>>       >
>>>>>       >     On 3/18/14, 8:59 AM, Marek ?upnik wrote:
>>>>>       >      > Hi,
>>>>>       >      >
>>>>>       >      > I'm Marek Zupnik. It's my first message for this
>>>>> list but for
>>>>>       >     some time
>>>>>       >      > I've been keeping my eyes on what's happening in
>>>>> wildfly
>>>>>       development.
>>>>>       >      >
>>>>>       >      > I'm writing regarding to the issue about lack of
>>>>> support
>>>>>       for PKCS12
>>>>>       >      > keystores in security realms
>>>>>       >      > (https://issues.jboss.org/browse/WFLY-2229). I
>>>>> wanted to
>>>>>       migrate my
>>>>>       >      > system to Wildfly but in my case it is a blocking
>>>>> issue.
>>>>>       I have
>>>>>       >     to use
>>>>>       >      > keystore in PKCS12 format in which I'm storing, among
>>>>>       others, https
>>>>>       >      > private key.
>>>>>       >      >
>>>>>       >      > I forked Wildfly on github and made a simple fix for
>>>>> this
>>>>>       issue which
>>>>>       >      > consists in additional parameter "keystore-type" for
>>>>> keystore
>>>>>       >      > configuration. Based on this parameter I'm able to
>>>>> create
>>>>>       appropriate
>>>>>       >      > keystore type.
>>>>>       >      >
>>>>>       >      > Config sample:
>>>>>       >      > <keystore path="keystore.p12"
>>>>>       relative-to="jboss.server.config.dir"
>>>>>       >      > keystore-password="xxx" keystore-type="PKCS12"
>>>>>       alias="https"/>
>>>>>       >      >
>>>>>       >      > The changes are in my fork on github (keystore_type
>>>>> branch):
>>>>>       >      > https://github.com/mzupnik/wildfly/tree/keystore_type
>>>>>       >      >
>>>>>       >      > Before I will try to do push request, could you
>>>>> answer me
>>>>>       if it is
>>>>>       >      > acceptable solution according to your architecture
>>>>>       concept? If not,
>>>>>       >      > could you give me some tips how to resolve it in
>>>>> other way? I
>>>>>       >     care about
>>>>>       >      > this fix before 9. release.
>>>>>       >      >
>>>>>       >      > Kind Regards,
>>>>>       >      > Marek Zupnik
>>>>>       >      >
>>>>>       >      >
>>>>>       >      > _______________________________________________
>>>>>       >      > wildfly-dev mailing list
>>>>>       >      > wildfly-dev at lists.jboss.org
>>>>>       <mailto:wildfly-dev at lists.jboss.org>
>>>>>       <mailto:wildfly-dev at lists.jboss.org
>>>>>       <mailto:wildfly-dev at lists.jboss.org>>
>>>>>       >      > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>       >      >
>>>>>       >
>>>>>       >
>>>>>       >     _______________________________________________
>>>>>       >     wildfly-dev mailing list
>>>>>       > wildfly-dev at lists.jboss.org
>>>>> <mailto:wildfly-dev at lists.jboss.org>
>>>>>       <mailto:wildfly-dev at lists.jboss.org
>>>>>       <mailto:wildfly-dev at lists.jboss.org>>
>>>>>       > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>       >
>>>>>       >
>>>>>       >
>>>>>       >
>>>>>       > _______________________________________________
>>>>>       > wildfly-dev mailing list
>>>>>       > wildfly-dev at lists.jboss.org
>>>>> <mailto:wildfly-dev at lists.jboss.org>
>>>>>       > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>       >
>>>>>       _______________________________________________
>>>>>       wildfly-dev mailing list
>>>>>       wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>>>       https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>

From emartins at redhat.com  Mon Mar 24 10:04:56 2014
From: emartins at redhat.com (Eduardo Martins)
Date: Mon, 24 Mar 2014 14:04:56 +0000
Subject: [wildfly-dev] EE Subsystem Configuration Documentation
In-Reply-To: <532B2B6A.70000@jboss.com>
References: <CAGk6hheh0PcOFszcsq4EGV6SqY3NCWYC3A-XaV8B3b6bCTnROg@mail.gmail.com>	<5328642D.100@redhat.com>	<CAGk6hhcVCuymoQtXcLnu3wjtfW6yec+QNdszj9BQM3W9mOdq7g@mail.gmail.com>	<53287E18.4080900@jboss.com>	<CAGk6hheSozAbreWMyeEA4P5zx+t1y4stfbBxyn6Hr4_Wcc_LeA@mail.gmail.com>	<A5C3337F-B8F8-4919-AFAC-63F90BFDAC2C@redhat.com>	<532A5300.1050706@redhat.com>
	<532ACE83.2090008@jboss.com> <532B2B6A.70000@jboss.com>
Message-ID: <126DF8C9-3D88-4B3D-A3DE-64CFBF88E7A8@redhat.com>

Added a page documenting the EE Subsystem Configuration, which allows an admin to:

* customise the deployment of Java EE applications
* configure EE Concurrency Utilities instances
* define the default bindings, such as java:comp/DefaultDatasource

The page URL is https://docs.jboss.org/author/display/WFLY8/EE+Subsystem+Configuration

Also updated the JNDI Reference in WildFly's Developer Guide, which URL is https://docs.jboss.org/author/display/WFLY8/JNDI+Reference

Feedback is welcome.

?E

From marek.zupnik at gmail.com  Mon Mar 24 11:02:41 2014
From: marek.zupnik at gmail.com (=?ISO-8859-2?Q?Marek_=AFupnik?=)
Date: Mon, 24 Mar 2014 16:02:41 +0100
Subject: [wildfly-dev] Support for PKCS12 keystores in Security Realms
In-Reply-To: <53301DDC.8000909@jboss.com>
References: <CAGk6hheh0PcOFszcsq4EGV6SqY3NCWYC3A-XaV8B3b6bCTnROg@mail.gmail.com>
	<5328642D.100@redhat.com>
	<CAGk6hhcVCuymoQtXcLnu3wjtfW6yec+QNdszj9BQM3W9mOdq7g@mail.gmail.com>
	<53287E18.4080900@jboss.com>
	<CAGk6hheSozAbreWMyeEA4P5zx+t1y4stfbBxyn6Hr4_Wcc_LeA@mail.gmail.com>
	<A5C3337F-B8F8-4919-AFAC-63F90BFDAC2C@redhat.com>
	<532A5300.1050706@redhat.com> <532ACE83.2090008@jboss.com>
	<532B2B6A.70000@jboss.com> <53301DDC.8000909@jboss.com>
Message-ID: <CAGk6hhecQpi3j-eop9SvfN4A7vKHV-zCdKDnh9TvNExzr87buQ@mail.gmail.com>

It's a great news. Thank you for your help.

Kind regards,
Marek Zupnik


2014-03-24 12:58 GMT+01:00 Darran Lofthouse <darran.lofthouse at jboss.com>:

> Most of the changes are now in for this, just some final updates to make
> this compatible with alternative file based stores.
>
> On 20/03/14 17:54, Darran Lofthouse wrote:
> > I have updated the pull request for the schema version bump, once that
> > one is in I will get pull requests in for backporting the upstream
> > changes and enabling support for alternative file based keystores such
> > as PKCS#12
> >
> > Regards,
> > Darran Lofthouse.
> >
> >
> > On 20/03/14 11:18, Darran Lofthouse wrote:
> >> I am just tagging a JBoss Negotiation release then I will switch to
> >> getting this backported.
> >>
> >> Once backported it may be easier if we just delete the commit from
> >> Kabir's branch when he rebases.
> >>
> >>   From this point forward can we please push less to WildFly 9? ;-)  I
> >> already lost time as I started to work on this for 8 and was then
> >> diverted by other engineers to push it to 9, I am now going to spend
> >> time pulling it back to 8!
> >>
> >> Regards,
> >> Darran Lofthouse.
> >>
> >>
> >> On 20/03/14 02:31, Brian Stansberry wrote:
> >>> It's very similar to the existing commit for WF9/EAP6.3 [1], so if we
> >>> want the feature in 8.0.1 we should just merge the open PR to bump the
> >>> core schema versions[2] and then backport that commit.
> >>>
> >>> [1]
> >>>
> https://github.com/kabir/wildfly/commit/3f22fcfa81975bf9951003889c4d4af1d2dbd319
> >>>
> >>>
> >>> [2] https://github.com/wildfly/wildfly/pull/5913
> >>>
> >>> On 3/19/14, 8:32 PM, Jason T. Greene wrote:
> >>>> Since this change looks minor, and it comes from a community member
> >>>> I am
> >>>> inclined to allow into 8.0.1.
> >>>>
> >>>> How bad is the conflict for the other change you are referring to
> >>>> Darran?
> >>>>
> >>>> On Mar 19, 2014, at 5:43 PM, Marek ?upnik <marek.zupnik at gmail.com
> >>>> <mailto:marek.zupnik at gmail.com>> wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> Darran, I understand your point of view, but stable version of 9 will
> >>>>> be not released tomorrow. Lack of pkcs12 support in 8 is a major
> >>>>> issue, not to mention that in AS 7 I was able to use this format for
> >>>>> https private key. I think it will be useful to fix it yet in 8, even
> >>>>> thought the code with a fix will be thrown away in 9.
> >>>>>
> >>>>> I made a pull request with a fix
> >>>>> (https://github.com/wildfly/wildfly/pull/6062). It is up to you what
> >>>>> you do with it.
> >>>>>
> >>>>> Thank you for your answers and clarifications.
> >>>>>
> >>>>> Kind Regards,
> >>>>> Marek Zupnik
> >>>>>
> >>>>>
> >>>>> 2014-03-18 18:10 GMT+01:00 Darran Lofthouse
> >>>>> <darran.lofthouse at jboss.com <mailto:darran.lofthouse at jboss.com>>:
> >>>>>
> >>>>>       I will have another look if I get a chance to get something
> >>>>> into 8 but
> >>>>>       in reality a related change in this area (that completely
> >>>>>       conflicts with
> >>>>>       your changes) was pushed to 9 as the consensus was we did not
> >>>>> want the
> >>>>>       configuration model in this area changing before WildFLy 9.
> >>>>>
> >>>>>       On 18/03/14 16:30, Marek ?upnik wrote:
> >>>>>       > Hi,
> >>>>>       >
> >>>>>       > Thank You Brian for your comments. I'll try to apply them
> >>>>> to my
> >>>>>       code. I
> >>>>>       > ask if I will have further questions about it.
> >>>>>       >
> >>>>>       > @Darran, I have a question for you. I wasn't looking into
> >>>>>       development
> >>>>>       > branch so I haven't known about the changes. Is it possible
> >>>>> that
> >>>>>       pkcs12
> >>>>>       > support will be merged in Wildfly 8? If not, could my
> >>>>> change be
> >>>>>       merged
> >>>>>       > earlier? Otherwise, I'm forced to maintain my version of
> >>>>> Wildfly
> >>>>>       untill
> >>>>>       > no 9 will be released.
> >>>>>       >
> >>>>>       > Kind Regards,
> >>>>>       > Marek Zupnik
> >>>>>       >
> >>>>>       >
> >>>>>       > 2014-03-18 16:20 GMT+01:00 Brian Stansberry
> >>>>>       <brian.stansberry at redhat.com
> >>>>> <mailto:brian.stansberry at redhat.com>
> >>>>>       > <mailto:brian.stansberry at redhat.com
> >>>>>       <mailto:brian.stansberry at redhat.com>>>:
> >>>>>       >
> >>>>>       >     Hi Marek,
> >>>>>       >
> >>>>>       >     Welcome!
> >>>>>       >
> >>>>>       >     I'm going to make a few comments on github re: some minor
> >>>>>       details of
> >>>>>       >     your commit. But please keep an eye on this list for your
> >>>>>       more general
> >>>>>       >     question about whether this is how we want to go about
> >>>>> this.
> >>>>>       I believe
> >>>>>       >     Darran Lofthouse was planning some work in this area so
> he
> >>>>>       may have some
> >>>>>       >     input.
> >>>>>       >
> >>>>>       >     Cheers,
> >>>>>       >
> >>>>>       >     --
> >>>>>       >     Brian Stansberry
> >>>>>       >     Senior Principal Software Engineer
> >>>>>       >     JBoss by Red Hat
> >>>>>       >
> >>>>>       >     On 3/18/14, 8:59 AM, Marek ?upnik wrote:
> >>>>>       >      > Hi,
> >>>>>       >      >
> >>>>>       >      > I'm Marek Zupnik. It's my first message for this
> >>>>> list but for
> >>>>>       >     some time
> >>>>>       >      > I've been keeping my eyes on what's happening in
> >>>>> wildfly
> >>>>>       development.
> >>>>>       >      >
> >>>>>       >      > I'm writing regarding to the issue about lack of
> >>>>> support
> >>>>>       for PKCS12
> >>>>>       >      > keystores in security realms
> >>>>>       >      > (https://issues.jboss.org/browse/WFLY-2229). I
> >>>>> wanted to
> >>>>>       migrate my
> >>>>>       >      > system to Wildfly but in my case it is a blocking
> >>>>> issue.
> >>>>>       I have
> >>>>>       >     to use
> >>>>>       >      > keystore in PKCS12 format in which I'm storing, among
> >>>>>       others, https
> >>>>>       >      > private key.
> >>>>>       >      >
> >>>>>       >      > I forked Wildfly on github and made a simple fix for
> >>>>> this
> >>>>>       issue which
> >>>>>       >      > consists in additional parameter "keystore-type" for
> >>>>> keystore
> >>>>>       >      > configuration. Based on this parameter I'm able to
> >>>>> create
> >>>>>       appropriate
> >>>>>       >      > keystore type.
> >>>>>       >      >
> >>>>>       >      > Config sample:
> >>>>>       >      > <keystore path="keystore.p12"
> >>>>>       relative-to="jboss.server.config.dir"
> >>>>>       >      > keystore-password="xxx" keystore-type="PKCS12"
> >>>>>       alias="https"/>
> >>>>>       >      >
> >>>>>       >      > The changes are in my fork on github (keystore_type
> >>>>> branch):
> >>>>>       >      > https://github.com/mzupnik/wildfly/tree/keystore_type
> >>>>>       >      >
> >>>>>       >      > Before I will try to do push request, could you
> >>>>> answer me
> >>>>>       if it is
> >>>>>       >      > acceptable solution according to your architecture
> >>>>>       concept? If not,
> >>>>>       >      > could you give me some tips how to resolve it in
> >>>>> other way? I
> >>>>>       >     care about
> >>>>>       >      > this fix before 9. release.
> >>>>>       >      >
> >>>>>       >      > Kind Regards,
> >>>>>       >      > Marek Zupnik
> >>>>>       >      >
> >>>>>       >      >
> >>>>>       >      > _______________________________________________
> >>>>>       >      > wildfly-dev mailing list
> >>>>>       >      > wildfly-dev at lists.jboss.org
> >>>>>       <mailto:wildfly-dev at lists.jboss.org>
> >>>>>       <mailto:wildfly-dev at lists.jboss.org
> >>>>>       <mailto:wildfly-dev at lists.jboss.org>>
> >>>>>       >      > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>>>>       >      >
> >>>>>       >
> >>>>>       >
> >>>>>       >     _______________________________________________
> >>>>>       >     wildfly-dev mailing list
> >>>>>       > wildfly-dev at lists.jboss.org
> >>>>> <mailto:wildfly-dev at lists.jboss.org>
> >>>>>       <mailto:wildfly-dev at lists.jboss.org
> >>>>>       <mailto:wildfly-dev at lists.jboss.org>>
> >>>>>       > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>>>>       >
> >>>>>       >
> >>>>>       >
> >>>>>       >
> >>>>>       > _______________________________________________
> >>>>>       > wildfly-dev mailing list
> >>>>>       > wildfly-dev at lists.jboss.org
> >>>>> <mailto:wildfly-dev at lists.jboss.org>
> >>>>>       > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>>>>       >
> >>>>>       _______________________________________________
> >>>>>       wildfly-dev mailing list
> >>>>>       wildfly-dev at lists.jboss.org <mailto:
> wildfly-dev at lists.jboss.org>
> >>>>>       https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> wildfly-dev mailing list
> >>>>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
> >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> wildfly-dev mailing list
> >>>> wildfly-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>>>
> >>>
> >>>
> >> _______________________________________________
> >> 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/20140324/6c0a62ef/attachment-0001.html 

From manderse at redhat.com  Tue Mar 25 07:21:34 2014
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Tue, 25 Mar 2014 12:21:34 +0100
Subject: [wildfly-dev] Admin Console / Homepage / Sidebar links
In-Reply-To: <33C8DC1E-BD57-491B-9ABF-0F1EF1915230@redhat.com>
References: <77B44DAE-08C0-4663-ADF5-C0F067D82D98@redhat.com>
	<CAGBoHQU1PnYua8SCYtG6Fp5euoVc58T+=hLzkEm+RrExdOofUg@mail.gmail.com>
	<9C1FBE2B-859F-48B6-9FEF-FFA201380C15@redhat.com>
	<CAGBoHQXHOe61wnN3TK5Ljcm8J1mMfR87hVLmo0vYu1_gBCYhZA@mail.gmail.com>
	<33C8DC1E-BD57-491B-9ABF-0F1EF1915230@redhat.com>
Message-ID: <2D1B07F8-04B2-4C17-BDD6-8BC692661B05@redhat.com>

On 4 Mar 2014, at 17:03, Harald Pehl wrote:

> Am 04.03.2014 um 16:58 schrieb Arun Gupta <arun.gupta at gmail.com>:
>
>> How is that google analytics data collected ? And where can I see 
>> that data ?
>
> You should have access to the GA site: 
> https://www.google.com/analytics/web/?#report/visitors-overview/a35829315w63735551p65393289/

Could you grant me (google id is max.andersen at gmail.com) to see this too 
?

Thanks,
Max
>>
>> Does it give us a measure of our active users ? Not just download
>> data, but developers who are using it actively.
>
> There are tons of reports. For example there's a real time view 
> showing the users who are running the console right now.
>
> .: Harald
>
>
>>
>> Arun
>>
>> On Tue, Mar 4, 2014 at 6:30 AM, Heiko Braun <hbraun at redhat.com> 
>> wrote:
>>>
>>>
>>> WF has google analytics enabled. We get much more info then that.
>>>
>>> On 04 Mar 2014, at 15:11, Arun Gupta <arun.gupta at gmail.com> wrote:
>>>
>>> This will send a geo ping
>>>
>>>
>>
>>
>>
>> -- 
>> http://blog.arungupta.me
>> http://twitter.com/arungupta
>
> ---
> 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


/max
http://about.me/maxandersen


From manderse at redhat.com  Tue Mar 25 07:22:57 2014
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Tue, 25 Mar 2014 12:22:57 +0100
Subject: [wildfly-dev] Admin Console / Homepage / Sidebar links
In-Reply-To: <CAMquZP6BPjjZtq=m-D0BYrbYyfmkkdRU9eMGr8i6D7GT+vswgQ@mail.gmail.com>
References: <77B44DAE-08C0-4663-ADF5-C0F067D82D98@redhat.com>
	<CAGBoHQU1PnYua8SCYtG6Fp5euoVc58T+=hLzkEm+RrExdOofUg@mail.gmail.com>
	<CAMquZP6BPjjZtq=m-D0BYrbYyfmkkdRU9eMGr8i6D7GT+vswgQ@mail.gmail.com>
Message-ID: <8DF0BE3F-FC43-40ED-8B8E-5640ACCA330A@redhat.com>

On 4 Mar 2014, at 15:19, Toma? Cerar wrote:

> On Tue, Mar 4, 2014 at 3:11 PM, Arun Gupta <arun.gupta at gmail.com> 
> wrote:
>
>> Is there a way to add a "call home" feature using a script in this
>> panel as well ?
>>
>> This will send a geo ping from where ever the admin console is
>> launched which can then be plotted in a map mashup to show "active
>> users" ?
>>
>
>
> There is noting that devs hate more than extra tracking. It will 
> backfire
> at us...

GA can be disabled if you don't want tracking.

And even thought JBT is opt-in (you get asked at startup) we still have 
~40.000
daily starts registered.

So devs seem to love giving feedback when they don't have to do 
anything.

/max
http://about.me/maxandersen

From ochong at gmail.com  Wed Mar 26 08:12:00 2014
From: ochong at gmail.com (Oliver Chong)
Date: Wed, 26 Mar 2014 08:12:00 -0400
Subject: [wildfly-dev] Undertow 1.0.2 in WildFly 8.0.1?
Message-ID: <CAKNC9q3XrzsBY4hhKm74FWstGeDAVE3C=pGye60zxYU=QiHJJA@mail.gmail.com>

We were seeing issues with Undertow 1.0.0 bundled in WildFly 8.0.0 properly
handling a client certificate proxied from apache httpd over AJP
(mod_proxy_ajp).  The application would seemingly randomly not be able to
retrieve the cert from the request and so respond with a 403.

I've since tried Undertow 1.0.2 and everything seems to be working
correctly now.  I noticed that in the Undertow change log there were
changes to AJP parsing and handling of certificates when Apache doesn't
forward the session ID.

We prefer to not have to swap components from those provided in an official
WildFly release.  Will WildFly 8.0.1 include Undertow 1.0.2?

Thanks,
Oliver
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140326/e4d9c77d/attachment.html 

From tomaz.cerar at gmail.com  Wed Mar 26 08:44:01 2014
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Wed, 26 Mar 2014 13:44:01 +0100
Subject: [wildfly-dev] Undertow 1.0.2 in WildFly 8.0.1?
In-Reply-To: <CAKNC9q3XrzsBY4hhKm74FWstGeDAVE3C=pGye60zxYU=QiHJJA@mail.gmail.com>
References: <CAKNC9q3XrzsBY4hhKm74FWstGeDAVE3C=pGye60zxYU=QiHJJA@mail.gmail.com>
Message-ID: <CAMquZP5W+Vwb73EX_1W27iA1HO6s-GOXqhnRtS5u5=0uEwHgUQ@mail.gmail.com>

Hi Oliver,

Undertow 1.0.2 is already part of wildfly codebase which will become 8.0.1.

We will probably ship 8.0.1 with 1.0.3 which was released yesterday as it
addresses few more problems.

btw, you can always grab nightly build from
https://community.jboss.org/thread/224262

--
tomaz



On Wed, Mar 26, 2014 at 1:12 PM, Oliver Chong <ochong at gmail.com> wrote:

> We were seeing issues with Undertow 1.0.0 bundled in WildFly 8.0.0
> properly handling a client certificate proxied from apache httpd over AJP
> (mod_proxy_ajp).  The application would seemingly randomly not be able to
> retrieve the cert from the request and so respond with a 403.
>
> I?ve since tried Undertow 1.0.2 and everything seems to be working
> correctly now.  I noticed that in the Undertow change log there were
> changes to AJP parsing and handling of certificates when Apache doesn?t
> forward the session ID.
>
> We prefer to not have to swap components from those provided in an
> official WildFly release.  Will WildFly 8.0.1 include Undertow 1.0.2?
>
> Thanks,
> Oliver
>
> _______________________________________________
> 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/20140326/e26697e1/attachment.html 

From ochong at gmail.com  Wed Mar 26 09:05:38 2014
From: ochong at gmail.com (Oliver Chong)
Date: Wed, 26 Mar 2014 09:05:38 -0400
Subject: [wildfly-dev] Undertow 1.0.2 in WildFly 8.0.1?
In-Reply-To: <CAMquZP5W+Vwb73EX_1W27iA1HO6s-GOXqhnRtS5u5=0uEwHgUQ@mail.gmail.com>
References: <CAKNC9q3XrzsBY4hhKm74FWstGeDAVE3C=pGye60zxYU=QiHJJA@mail.gmail.com>
	<CAMquZP5W+Vwb73EX_1W27iA1HO6s-GOXqhnRtS5u5=0uEwHgUQ@mail.gmail.com>
Message-ID: <CAKNC9q1SUHCK-FZe6gmYa-rsbJvUnoKmwCtcAcYhuFQCcKwH-A@mail.gmail.com>

Great! Thank you Tomaz.  I must have overlooked the nightly build location.

- Oliver

On Wed, Mar 26, 2014 at 8:44 AM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
> Hi Oliver,
>
> Undertow 1.0.2 is already part of wildfly codebase which will become 8.0.1.
>
> We will probably ship 8.0.1 with 1.0.3 which was released yesterday as it
> addresses few more problems.
>
> btw, you can always grab nightly build from
> https://community.jboss.org/thread/224262
>
> --
> tomaz
>
>
>
> On Wed, Mar 26, 2014 at 1:12 PM, Oliver Chong <ochong at gmail.com> wrote:
>>
>> We were seeing issues with Undertow 1.0.0 bundled in WildFly 8.0.0
>> properly handling a client certificate proxied from apache httpd over AJP
>> (mod_proxy_ajp).  The application would seemingly randomly not be able to
>> retrieve the cert from the request and so respond with a 403.
>>
>> I?ve since tried Undertow 1.0.2 and everything seems to be working
>> correctly now.  I noticed that in the Undertow change log there were changes
>> to AJP parsing and handling of certificates when Apache doesn?t forward the
>> session ID.
>>
>> We prefer to not have to swap components from those provided in an
>> official WildFly release.  Will WildFly 8.0.1 include Undertow 1.0.2?
>>
>> Thanks,
>> Oliver
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>


From hostetlerm at gmail.com  Wed Mar 26 11:16:59 2014
From: hostetlerm at gmail.com (Mike Hostetler)
Date: Wed, 26 Mar 2014 10:16:59 -0500
Subject: [wildfly-dev] ConstraintDeclarationException on deployment
Message-ID: <CAKskYa0HMbRhCno0otwsvehvQHn5589Rg3OGhohHYX229t_NOg@mail.gmail.com>

I'm probably one of the many that is moving away from Glassfish to WildFly.
I have done some trivial changes but now Weld is giving validation failures
like the following on some of our EJB3 beans:

javax.validation.ConstraintDeclarationException: HV000151: A method
overriding another method must not alter the parameter constraint
configuration

The worse thing is that only see one at a time: so I fix one, do the
build-redeploy dance, and then see the next one. Most of the problems is
that in the overriding class we use javax.validation.constraints.NotNull
annotation on the parameter, which is what Weld doesn't seem to like.
Obviously these worked in Glassfish.

My first thought is: how can I shut off Weld validation? If that is not
possible (which I'm willing to accept), then how can I see these validation
errors all at once instead of one at a time during deployment?

Thanks
-- 
Mike Hostetler
http://mike.hostetlerhome.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140326/c102de8b/attachment.html 

From emmanuel at hibernate.org  Wed Mar 26 11:40:32 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 26 Mar 2014 16:40:32 +0100
Subject: [wildfly-dev] ConstraintDeclarationException on deployment
In-Reply-To: <CAKskYa0HMbRhCno0otwsvehvQHn5589Rg3OGhohHYX229t_NOg@mail.gmail.com>
References: <CAKskYa0HMbRhCno0otwsvehvQHn5589Rg3OGhohHYX229t_NOg@mail.gmail.com>
Message-ID: <20140326154032.GJ42990@hibernate.org>

Does your offending method actually override another method?
Because that would definitely be an error on your part.
Glassfish uses Hibernate Validator for the validation engine so I don't
think your code is at fault here. Unless they have a broken integration
and nothing is validated.

But it could be due to a bug on how Weld does subclassing for proxies and
copy constraint annotations but I thought we had that base covered
already.

The best would be to open an issue with a reproducible minimal test
case. From there we could either fix the offending bug and if there is
none see how we could report several errors in one go.

Emmanuel

On Wed 2014-03-26 10:16, Mike Hostetler wrote:
> I'm probably one of the many that is moving away from Glassfish to WildFly.
> I have done some trivial changes but now Weld is giving validation failures
> like the following on some of our EJB3 beans:
> 
> javax.validation.ConstraintDeclarationException: HV000151: A method
> overriding another method must not alter the parameter constraint
> configuration
> 
> The worse thing is that only see one at a time: so I fix one, do the
> build-redeploy dance, and then see the next one. Most of the problems is
> that in the overriding class we use javax.validation.constraints.NotNull
> annotation on the parameter, which is what Weld doesn't seem to like.
> Obviously these worked in Glassfish.
> 
> My first thought is: how can I shut off Weld validation? If that is not
> possible (which I'm willing to accept), then how can I see these validation
> errors all at once instead of one at a time during deployment?
> 
> Thanks
> -- 
> Mike Hostetler
> http://mike.hostetlerhome.com/

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


From hostetlerm at gmail.com  Wed Mar 26 16:02:42 2014
From: hostetlerm at gmail.com (Mike Hostetler)
Date: Wed, 26 Mar 2014 15:02:42 -0500
Subject: [wildfly-dev] Shut off connection pooling?
Message-ID: <CAKskYa0WxbeBGzHcxdyOd3=JwH6zqabu-VLpwrMbdo81B181KQ@mail.gmail.com>

My next migration question --

how do I shut off jdbc connection pooling? We have our own Datasource jar
that takes of that for us, including handling our own unique (read:
"crazy") requirements. That datasource jar is already successfully deployed
in my WildFly container.

Thanks,

-- 
Mike Hostetler
http://mike.hostetlerhome.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140326/93db07a7/attachment.html 

From hardy at hibernate.org  Wed Mar 26 16:04:44 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 26 Mar 2014 21:04:44 +0100
Subject: [wildfly-dev] ConstraintDeclarationException on deployment
In-Reply-To: <20140326154032.GJ42990@hibernate.org>
References: <CAKskYa0HMbRhCno0otwsvehvQHn5589Rg3OGhohHYX229t_NOg@mail.gmail.com>
	<20140326154032.GJ42990@hibernate.org>
Message-ID: <27722012-9628-4189-A162-7FA0DF866F93@hibernate.org>

Hi Mike,

a couple of more remarks on top of Emmanuel?s.

First of all, as Emmanuel is saying method and constructor validation should behave the same
on Glassfish and Wildfly. The Bean Validation specification (part of EE 7) says that method and 
constructor validation occurs per default as soon as Bean Validation constraint annotations are 
used on methods or constructors. You find the relevant specification section here - 
http://beanvalidation.org/1.1/spec/#integration-general-executable

To answer your question on how to disable validation. You can add a validation.xml file disabling 
executable validation:

<?xml version="1.0" encoding="UTF-8"?>
<validation-config xmlns="http://jboss.org/xml/ns/javax/validation/configuration"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://jboss.org/xml/ns/javax/validation/configuration validation-configuration-1.1.xsd"
        version="1.1">

    <executable-validation enabled="false"/>

</validation-config>

Last but not least, open an issue with test case, so that we can check whether there is a bug or not.

?Hardy



On 26 Jan 2014, at 16:40, Emmanuel Bernard <emmanuel at hibernate.org> wrote:

> Does your offending method actually override another method?
> Because that would definitely be an error on your part.
> Glassfish uses Hibernate Validator for the validation engine so I don't
> think your code is at fault here. Unless they have a broken integration
> and nothing is validated.
> 
> But it could be due to a bug on how Weld does subclassing for proxies and
> copy constraint annotations but I thought we had that base covered
> already.
> 
> The best would be to open an issue with a reproducible minimal test
> case. From there we could either fix the offending bug and if there is
> none see how we could report several errors in one go.
> 
> Emmanuel
> 
> On Wed 2014-03-26 10:16, Mike Hostetler wrote:
>> I'm probably one of the many that is moving away from Glassfish to WildFly.
>> I have done some trivial changes but now Weld is giving validation failures
>> like the following on some of our EJB3 beans:
>> 
>> javax.validation.ConstraintDeclarationException: HV000151: A method
>> overriding another method must not alter the parameter constraint
>> configuration
>> 
>> The worse thing is that only see one at a time: so I fix one, do the
>> build-redeploy dance, and then see the next one. Most of the problems is
>> that in the overriding class we use javax.validation.constraints.NotNull
>> annotation on the parameter, which is what Weld doesn't seem to like.
>> Obviously these worked in Glassfish.
>> 
>> My first thought is: how can I shut off Weld validation? If that is not
>> possible (which I'm willing to accept), then how can I see these validation
>> errors all at once instead of one at a time during deployment?
>> 
>> Thanks
>> -- 
>> Mike Hostetler
>> http://mike.hostetlerhome.com/
> 
>> _______________________________________________
>> 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 hostetlerm at gmail.com  Wed Mar 26 16:09:47 2014
From: hostetlerm at gmail.com (Mike Hostetler)
Date: Wed, 26 Mar 2014 15:09:47 -0500
Subject: [wildfly-dev] ConstraintDeclarationException on deployment
In-Reply-To: <27722012-9628-4189-A162-7FA0DF866F93@hibernate.org>
References: <CAKskYa0HMbRhCno0otwsvehvQHn5589Rg3OGhohHYX229t_NOg@mail.gmail.com>
	<20140326154032.GJ42990@hibernate.org>
	<27722012-9628-4189-A162-7FA0DF866F93@hibernate.org>
Message-ID: <CAKskYa16-LKPUycVWcc8ysWMvmYGq8uyDEYTMY6JPv2HvOZUyA@mail.gmail.com>

Thanks Hardy,

When I get through my hurdles (I just sent another one) I will make an
example for bug-checking.

Actually, after I did 2 or 3, the constraint errors went away so it wasn't
so bad. But it still may be an issue.

Thanks for getting back to me.


On Wed, Mar 26, 2014 at 3:04 PM, Hardy Ferentschik <hardy at hibernate.org>wrote:

> Hi Mike,
>
> a couple of more remarks on top of Emmanuel's.
>
> First of all, as Emmanuel is saying method and constructor validation
> should behave the same
> on Glassfish and Wildfly. The Bean Validation specification (part of EE 7)
> says that method and
> constructor validation occurs per default as soon as Bean Validation
> constraint annotations are
> used on methods or constructors. You find the relevant specification
> section here -
> http://beanvalidation.org/1.1/spec/#integration-general-executable
>
> To answer your question on how to disable validation. You can add a
> validation.xml file disabling
> executable validation:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <validation-config xmlns="
> http://jboss.org/xml/ns/javax/validation/configuration"
>         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>         xsi:schemaLocation="
> http://jboss.org/xml/ns/javax/validation/configurationvalidation-configuration-1.1.xsd"
>         version="1.1">
>
>     <executable-validation enabled="false"/>
>
> </validation-config>
>
> Last but not least, open an issue with test case, so that we can check
> whether there is a bug or not.
>
> --Hardy
>
>
>
> On 26 Jan 2014, at 16:40, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>
> > Does your offending method actually override another method?
> > Because that would definitely be an error on your part.
> > Glassfish uses Hibernate Validator for the validation engine so I don't
> > think your code is at fault here. Unless they have a broken integration
> > and nothing is validated.
> >
> > But it could be due to a bug on how Weld does subclassing for proxies and
> > copy constraint annotations but I thought we had that base covered
> > already.
> >
> > The best would be to open an issue with a reproducible minimal test
> > case. From there we could either fix the offending bug and if there is
> > none see how we could report several errors in one go.
> >
> > Emmanuel
> >
> > On Wed 2014-03-26 10:16, Mike Hostetler wrote:
> >> I'm probably one of the many that is moving away from Glassfish to
> WildFly.
> >> I have done some trivial changes but now Weld is giving validation
> failures
> >> like the following on some of our EJB3 beans:
> >>
> >> javax.validation.ConstraintDeclarationException: HV000151: A method
> >> overriding another method must not alter the parameter constraint
> >> configuration
> >>
> >> The worse thing is that only see one at a time: so I fix one, do the
> >> build-redeploy dance, and then see the next one. Most of the problems is
> >> that in the overriding class we use javax.validation.constraints.NotNull
> >> annotation on the parameter, which is what Weld doesn't seem to like.
> >> Obviously these worked in Glassfish.
> >>
> >> My first thought is: how can I shut off Weld validation? If that is not
> >> possible (which I'm willing to accept), then how can I see these
> validation
> >> errors all at once instead of one at a time during deployment?
> >>
> >> Thanks
> >> --
> >> Mike Hostetler
> >> http://mike.hostetlerhome.com/
> >
> >> _______________________________________________
> >> 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
>
>


-- 
Mike Hostetler
http://mike.hostetlerhome.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140326/27c04e4a/attachment.html 

From filippespolti at gmail.com  Thu Mar 27 08:47:22 2014
From: filippespolti at gmail.com (Filippe Costa Spolti)
Date: Thu, 27 Mar 2014 09:47:22 -0300
Subject: [wildfly-dev] AS 7 to WildFly
Message-ID: <53341DDA.3000307@gmail.com>

Hi Guys,

Anyone have some material about this?

-- 
Regards,
______________________________________
Filippe Costa Spolti
Linux User n?515639 - http://counter.li.org/
filippespolti at gmail.com
"Be yourself"
<http://www.linkedin.com/pub/filippe-costa-spolti/67/985/575>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140327/679d6a4a/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: linkedin.png
Type: image/png
Size: 957 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140327/679d6a4a/attachment.png 

From pbielicki at gmail.com  Fri Mar 28 11:26:16 2014
From: pbielicki at gmail.com (PB)
Date: Fri, 28 Mar 2014 16:26:16 +0100
Subject: [wildfly-dev] WF 8.0 HTTP Upgrade help needed
Message-ID: <CAMvdueASMd1kUBSOC7J_dMoiAtC0ovTdQGywATpC3kNoheDDJA@mail.gmail.com>

Hi,

I'm testing the HTTP Upgrade feature of WF 8.0 and I'm facing some banal
problem. Basically my ReadListener is NEVER called.
Here's the code:

@WebServlet(urlPatterns = "/upgrade")
public class UpgradeServlet extends HttpServlet {
  @Override
  protected void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
    if ("upgrade".equalsIgnoreCase(req.getHeader("Connection"))) {
      req.upgrade(EchoHandler.class);
    }
  }
}

public class EchoHandler implements HttpUpgradeHandler {
  @Override
  public void init(WebConnection wc) {
    try {
      ServletInputStream in = wc.getInputStream();
      ServletOutputStream out = wc.getOutputStream();

      BlockingQueue<String> queue = new LinkedBlockingQueue<String>();
      in.setReadListener(new EchoReadListener(queue, in));
      out.setWriteListener(new EchoWriteListener(queue, out));
    } catch (IOException e) {
      throw new IllegalStateException(e);
    }
  }

public class EchoReadListener implements ReadListener {
  @Override
  public void onDataAvailable() throws IOException {
    while (in.isReady()) {
      int length = in.read(buffer);
      String input = new String(buffer, 0, length);
      if (false == queue.offer(input)) {
        System.err.println("'" + input + "' input was ignored");
      }
    }
  }

I'm connecting to WF using telnet and sending the upgrade request:
GET /example-webapp/upgrade HTTP/1.1
Host: localhost
Connection: upgrade
Upgrade: echo

and I'm getting correct response:

HTTP/1.1 101 Switching Protocols
Connection: Upgrade
X-Powered-By: Undertow 1
Server: Wildfly 8
Content-Length: 0

which means that from now on the protocol between my telnet client and WF
is pure TCP.
So, I start typing some text, hit Enter and.... nothing happens.
onDataAvailable() is NEVER called. More so, this makes WF totally
irresponsive - my whole webapp is dead.

I believe, I'm doing something wrong - any ideas what exactly? There is
also a slight chance that Upgrade feature in WF is f****d :)
Anyway, WF should not block even in case my upgraded protocol is not
working correctly?

Many thanks,
Przemyslaw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140328/154384a7/attachment.html 

From hbraun at redhat.com  Fri Mar 28 12:14:51 2014
From: hbraun at redhat.com (Heiko Braun)
Date: Fri, 28 Mar 2014 17:14:51 +0100
Subject: [wildfly-dev] WF 8.0 HTTP Upgrade help needed
In-Reply-To: <CAMvdueASMd1kUBSOC7J_dMoiAtC0ovTdQGywATpC3kNoheDDJA@mail.gmail.com>
References: <CAMvdueASMd1kUBSOC7J_dMoiAtC0ovTdQGywATpC3kNoheDDJA@mail.gmail.com>
Message-ID: <9890BDFE-346B-4BE9-9ABF-50D4AF9535AF@redhat.com>

At a first glance, I'd say your while{} block never returns. Is ServletInputStream.isFinished() what you've been looking for, instead of isReady()

On 28 Mar 2014, at 16:26, PB <pbielicki at gmail.com> wrote:

> while (in.isReady()) {

--

http://about.me/hbraun







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

From pbielicki at gmail.com  Fri Mar 28 16:05:04 2014
From: pbielicki at gmail.com (PB)
Date: Fri, 28 Mar 2014 21:05:04 +0100
Subject: [wildfly-dev] WF 8.0 HTTP Upgrade help needed
In-Reply-To: <9890BDFE-346B-4BE9-9ABF-50D4AF9535AF@redhat.com>
References: <CAMvdueASMd1kUBSOC7J_dMoiAtC0ovTdQGywATpC3kNoheDDJA@mail.gmail.com>
	<9890BDFE-346B-4BE9-9ABF-50D4AF9535AF@redhat.com>
Message-ID: <CAMvdueBqtHrAZp7E3at25pM5v48NydBZWg7rDEEnZAUf7CX_ZQ@mail.gmail.com>

Hi,

I dare to say that my code is correct ;) The problem is that it is NEVER
called - this condition (even if it's wrong, however it's not) is never
checked. When I remove this line:

out.setWriteListener(new EchoWriteListener(queue, out));

it seems to work. However, I have no writer, so it should be rather called
SwallowListener... It's not my goal.

Maybe I should initialize WriteListener from the ReadListener after the
first read? Or maybe, when I want to send back the response I should do
this directly from the read listener? e.g.
https://java.net/projects/tyrus/sources/source-code-repository/content/trunk/containers/servlet/src/main/java/org/glassfish/tyrus/servlet/TyrusHttpUpgradeHandler.java

Thanks,
Przemyslaw


On Fri, Mar 28, 2014 at 5:14 PM, Heiko Braun <hbraun at redhat.com> wrote:

> At a first glance, I'd say your while{} block never returns. Is
> ServletInputStream.isFinished() what you've been looking for, instead of
> isReady()
>
> On 28 Mar 2014, at 16:26, PB <pbielicki at gmail.com> wrote:
>
> while (in.isReady()) {
>
>
> --
>
> http://about.me/hbraun
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140328/af0541c8/attachment-0001.html 

From dador92 at gmail.com  Fri Mar 28 16:31:01 2014
From: dador92 at gmail.com (Jim McGuinness)
Date: Fri, 28 Mar 2014 15:31:01 -0500
Subject: [wildfly-dev] WF 8.0 HTTP Upgrade help needed
In-Reply-To: <CAMvdueBqtHrAZp7E3at25pM5v48NydBZWg7rDEEnZAUf7CX_ZQ@mail.gmail.com>
References: <CAMvdueASMd1kUBSOC7J_dMoiAtC0ovTdQGywATpC3kNoheDDJA@mail.gmail.com>
	<9890BDFE-346B-4BE9-9ABF-50D4AF9535AF@redhat.com>
	<CAMvdueBqtHrAZp7E3at25pM5v48NydBZWg7rDEEnZAUf7CX_ZQ@mail.gmail.com>
Message-ID: <CALbcAPV4k5CAZeshaqyH298KpVXJWz+JNnF9NwE9_cGousPYOA@mail.gmail.com>

So here's what I'm getting (my source code is attached) ...


__Telnet__

dador-iMac:~ dador$ telnet 10.0.1.14 8080

Trying 10.0.1.14...

Connected to 10.0.1.14.

Escape character is '^]'.

GET /wildfly-debug/upgrade HTTP/1.1

Connection: upgrade


HTTP/1.1 101 Switching Protocols

Connection: Upgrade

X-Powered-By: Undertow 1

Server: Wildfly 8

Content-Length: 0

Date: Fri, 28 Mar 2014 20:22:36 GMT


the quick brown fox blah, blah, blah

^]

telnet> quit

Connection closed.

dador-iMac:~ dador$


__console___

15:22:36,825 INFO  [stdout] (default task-15) servlet doGet() received
'upgrade'

15:22:46,488 INFO  [stdout] (default I/O-3) listener onDataAvailable()
called

15:22:46,488 INFO  [stdout] (default I/O-3) listener read 'the quick brown
fox blah, blah, blah'; successfully offered to queue

15:22:46,489 INFO  [stdout] (default I/O-3) listener read ''; successfully
offered to queue

15:22:56,824 INFO  [stdout] (default I/O-3) listener onDataAvailable()
called

15:22:56,824 INFO  [stdout] (default I/O-3) listener onAllDataRead() called

15:22:56,824 INFO  [stdout] (default I/O-3) here is data queued ...

15:22:56,825 INFO  [stdout] (default I/O-3) the quick brown fox blah, blah,
blah

15:22:56,825 INFO  [stdout] (default I/O-3)

15:22:56,825 INFO  [stdout] (default I/O-3)

15:22:56,825 INFO  [stdout] (default I/O-3) now do something


So the queue is getting the data as it's being piped in (the blanks in the
queued data are telnet line feeds). But I have to send a signal to the
servlet that all of the data has been sent (I simply close the telnet
connection). Then the listener's onAllDataRead() method gets called.

So maybe this is a configuration issue. By the way, it made a difference
for me in the telnet session when I specified the Connection as "upgrade"
versus "Upgrade".

Just a suggestion, but you may also want to take a look at the non-blocking
I/O if you input stream is a long one.

Good luck,

--Jim.


On Fri, Mar 28, 2014 at 3:05 PM, PB <pbielicki at gmail.com> wrote:

> Hi,
>
> I dare to say that my code is correct ;) The problem is that it is NEVER
> called - this condition (even if it's wrong, however it's not) is never
> checked. When I remove this line:
>
> out.setWriteListener(new EchoWriteListener(queue, out));
>
> it seems to work. However, I have no writer, so it should be rather called
> SwallowListener... It's not my goal.
>
> Maybe I should initialize WriteListener from the ReadListener after the
> first read? Or maybe, when I want to send back the response I should do
> this directly from the read listener? e.g.
> https://java.net/projects/tyrus/sources/source-code-repository/content/trunk/containers/servlet/src/main/java/org/glassfish/tyrus/servlet/TyrusHttpUpgradeHandler.java
>
> Thanks,
> Przemyslaw
>
>
> On Fri, Mar 28, 2014 at 5:14 PM, Heiko Braun <hbraun at redhat.com> wrote:
>
>> At a first glance, I'd say your while{} block never returns. Is
>> ServletInputStream.isFinished() what you've been looking for, instead of
>> isReady()
>>
>> On 28 Mar 2014, at 16:26, PB <pbielicki at gmail.com> wrote:
>>
>> while (in.isReady()) {
>>
>>
>>   --
>>
>> http://about.me/hbraun
>>
>>
>>
>>
>>
>>
>>
>>
>
> _______________________________________________
> 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/20140328/1258eef2/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EchoHandler.java
Type: application/octet-stream
Size: 703 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140328/1258eef2/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EchoReadListener.java
Type: application/octet-stream
Size: 1270 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140328/1258eef2/attachment-0001.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: UpgradeServlet.java
Type: application/octet-stream
Size: 903 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140328/1258eef2/attachment-0002.obj 

From pxntium at gmail.com  Mon Mar 31 05:37:16 2014
From: pxntium at gmail.com (=?ISO-8859-1?Q?Francisco_Mart=EDnez?=)
Date: Mon, 31 Mar 2014 11:37:16 +0200
Subject: [wildfly-dev] Undertow 1.0.2 in WildFly 8.0.1?
In-Reply-To: <CAKNC9q1SUHCK-FZe6gmYa-rsbJvUnoKmwCtcAcYhuFQCcKwH-A@mail.gmail.com>
References: <CAKNC9q3XrzsBY4hhKm74FWstGeDAVE3C=pGye60zxYU=QiHJJA@mail.gmail.com>
	<CAMquZP5W+Vwb73EX_1W27iA1HO6s-GOXqhnRtS5u5=0uEwHgUQ@mail.gmail.com>
	<CAKNC9q1SUHCK-FZe6gmYa-rsbJvUnoKmwCtcAcYhuFQCcKwH-A@mail.gmail.com>
Message-ID: <CAE9-Q_vBsmRT6vfxpG=4OvZA8r+_YOQcrJPNR_PNVBbs_Rw0fg@mail.gmail.com>

Hi all,
it's great!
Someone knows when the 8.0.1 final version will be released?

Thanks in advance

Regards
Fran



2014-03-26 14:05 GMT+01:00 Oliver Chong <ochong at gmail.com>:

> Great! Thank you Tomaz.  I must have overlooked the nightly build location.
>
> - Oliver
>
> On Wed, Mar 26, 2014 at 8:44 AM, Toma? Cerar <tomaz.cerar at gmail.com>
> wrote:
> > Hi Oliver,
> >
> > Undertow 1.0.2 is already part of wildfly codebase which will become
> 8.0.1.
> >
> > We will probably ship 8.0.1 with 1.0.3 which was released yesterday as it
> > addresses few more problems.
> >
> > btw, you can always grab nightly build from
> > https://community.jboss.org/thread/224262
> >
> > --
> > tomaz
> >
> >
> >
> > On Wed, Mar 26, 2014 at 1:12 PM, Oliver Chong <ochong at gmail.com> wrote:
> >>
> >> We were seeing issues with Undertow 1.0.0 bundled in WildFly 8.0.0
> >> properly handling a client certificate proxied from apache httpd over
> AJP
> >> (mod_proxy_ajp).  The application would seemingly randomly not be able
> to
> >> retrieve the cert from the request and so respond with a 403.
> >>
> >> I?ve since tried Undertow 1.0.2 and everything seems to be working
> >> correctly now.  I noticed that in the Undertow change log there were
> changes
> >> to AJP parsing and handling of certificates when Apache doesn?t forward
> the
> >> session ID.
> >>
> >> We prefer to not have to swap components from those provided in an
> >> official WildFly release.  Will WildFly 8.0.1 include Undertow 1.0.2?
> >>
> >> Thanks,
> >> Oliver
> >>
> >>
> >> _______________________________________________
> >> 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/20140331/4b8ffd05/attachment.html 

From tomaz.cerar at gmail.com  Mon Mar 31 05:42:03 2014
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Mon, 31 Mar 2014 11:42:03 +0200
Subject: [wildfly-dev] Undertow 1.0.2 in WildFly 8.0.1?
In-Reply-To: <CAE9-Q_vBsmRT6vfxpG=4OvZA8r+_YOQcrJPNR_PNVBbs_Rw0fg@mail.gmail.com>
References: <CAKNC9q3XrzsBY4hhKm74FWstGeDAVE3C=pGye60zxYU=QiHJJA@mail.gmail.com>
	<CAMquZP5W+Vwb73EX_1W27iA1HO6s-GOXqhnRtS5u5=0uEwHgUQ@mail.gmail.com>
	<CAKNC9q1SUHCK-FZe6gmYa-rsbJvUnoKmwCtcAcYhuFQCcKwH-A@mail.gmail.com>
	<CAE9-Q_vBsmRT6vfxpG=4OvZA8r+_YOQcrJPNR_PNVBbs_Rw0fg@mail.gmail.com>
Message-ID: <CAMquZP5kUtFzsT_-n+is36A=uXn8B2aKiuQuihzZWiUP0ZNUAA@mail.gmail.com>

When all blockers are resolved:
https://issues.jboss.org/issues/?jql=project%20%3D%20WFLY%20AND%20fixVersion%20%3D%20%228.0.1.Final%22%20AND%20resolution%20%3D%20Unresolved%20AND%20priority%20%3D%20Blocker%20ORDER%20BY%20key%20DESC


On Mon, Mar 31, 2014 at 11:37 AM, Francisco Mart?nez <pxntium at gmail.com>wrote:

> Hi all,
> it's great!
> Someone knows when the 8.0.1 final version will be released?
>
> Thanks in advance
>
> Regards
> Fran
>
>
>
> 2014-03-26 14:05 GMT+01:00 Oliver Chong <ochong at gmail.com>:
>
> Great! Thank you Tomaz.  I must have overlooked the nightly build location.
>>
>> - Oliver
>>
>> On Wed, Mar 26, 2014 at 8:44 AM, Toma? Cerar <tomaz.cerar at gmail.com>
>> wrote:
>> > Hi Oliver,
>> >
>> > Undertow 1.0.2 is already part of wildfly codebase which will become
>> 8.0.1.
>> >
>> > We will probably ship 8.0.1 with 1.0.3 which was released yesterday as
>> it
>> > addresses few more problems.
>> >
>> > btw, you can always grab nightly build from
>> > https://community.jboss.org/thread/224262
>> >
>> > --
>> > tomaz
>> >
>> >
>> >
>> > On Wed, Mar 26, 2014 at 1:12 PM, Oliver Chong <ochong at gmail.com> wrote:
>> >>
>> >> We were seeing issues with Undertow 1.0.0 bundled in WildFly 8.0.0
>> >> properly handling a client certificate proxied from apache httpd over
>> AJP
>> >> (mod_proxy_ajp).  The application would seemingly randomly not be able
>> to
>> >> retrieve the cert from the request and so respond with a 403.
>> >>
>> >> I?ve since tried Undertow 1.0.2 and everything seems to be working
>> >> correctly now.  I noticed that in the Undertow change log there were
>> changes
>> >> to AJP parsing and handling of certificates when Apache doesn?t
>> forward the
>> >> session ID.
>> >>
>> >> We prefer to not have to swap components from those provided in an
>> >> official WildFly release.  Will WildFly 8.0.1 include Undertow 1.0.2?
>> >>
>> >> Thanks,
>> >> Oliver
>> >>
>> >>
>> >> _______________________________________________
>> >> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140331/fe3079cf/attachment-0001.html