From stuart.w.douglas at gmail.com Mon Sep 1 01:24:49 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Mon, 01 Sep 2014 15:24:49 +1000 Subject: [wildfly-dev] Wildfly provisioning tools and packaging format In-Reply-To: <53B583C5.2010405@redhat.com> References: <53B583C5.2010405@redhat.com> Message-ID: <54040321.5060206@gmail.com> Just so everyone is aware these build/provisioning tools now live at https://github.com/wildfly/wildfly-build-tools with JIRA at https://issues.jboss.org/browse/WFBUILD Stuart Stuart Douglas wrote: > Hi all, > > So now that the core split has happened, I want to start work on the new > tooling for creating Wildfly feature packs. > > At the moment the build is using a simple maven plugin that I created, > that will take an existing server (e.g. the core server), layer some > extra modules over the top of it, build the config files, and perform > any other build tasks that are required. It can also turn a 'thin' > server into a traditional fat server. > > This is going to change to having two separate tools, the build tool and > the provisioning tool. The build tool will be used to create Wildfly > feature packs. A feature pack is kinda similar to what is already > produced, but with some major differences: > > - It does not contain the contents of any feature packs it was built on. > For example at the moment the results of web-build also contains the > server core. The web-build feature pack will only contain modules > provided by the web-build pack. > > - It is not a server, in that it cannot just be unzipped and ran, the > provisioning tool must be used first to create a runnable server from a > set of feature packs. > > Once the build tool has created the feature packs, it is then up to the > provisioning tool to use them to assemble a working server. The > provision tool will be written as a library, with multiple front ends. > At the very least we will provide a standalone version and a maven plugin. > > The provisioning tool takes a server descriptor, and uses that to > download all the relevant feature packs and assemble them into a server. > This process will give the user a lot of flexibility over how the server > is configured, including: > > - The ability to specify only the subsystems they are after, and a cut > down subsystem with just these subsystems and their dependents will be > installed. > - The ability to override versions, e.g. to provision a server with an > updated version of Resteasy. > - The ability to install deployments into the server by specifying the > deployments GAV. > - The ability to customise the default config (not sure how this will > work yet. A yuck solution would be xslt, but no one likes that. A nicer > solution could be some kind of CLI script that is run on first boot). > > This provisioning tool will also be used to build our server for our > traditional distribution and test suite. Basically as part of the build > process the maven plugin will be run to provision a server from the > constituent feature packs. > > The feature pack layout will look like below: > > ------ > > versions.properties > wildfly-pack.xml > modules/ > com/acme/mymodule > module.xml > ... > repository (optional) > com/acme/myartifact/my-artifact.jar > ... > configuration > standalone.xml > standalone-full.xml > domain.xml > ... > content > bin/README.txt > bin/LICENSE.txt > ... > ------ > The contents of these files and directories is as follows: > > versions.properties - properties file with the format G:A(:C)=V, e.g. > org.jboss.resteasy:resteasy-jaxrs=3.0.0.Final > wildfly-pack.xml - This contains all additional pack metadata: > pack name: The name of the feature pack, must not contain spaces > pack description: Self explanatory > packaging version: This is inferred from the schema > required tool version: The minimum version of the provisioning tool > that is required to handle this pack > permissions: A section to set unix file permissions > version overrides: A section that allows for specific overrides of > versions in the base system > dependencies: Information on the feature packs this pack depends on > > modules: > Similar to the modules dir we have today, with some exceptions: > - only artifact references are used, and these artifacts just refer to > group and artifact, without the version number. See the modules.xml > files in the current build for an example. > > repository: > Contains maven artifacts in the maven repository layout. This allows > for the creation of 'offline' feature packs, where the pack > does not need access to an external maven repository. This is not > required, and in most cases will not be used. > I am not 100% sure if we actually want this. > > configuration: > contains configuration template files, e.g. standalone.xml template > > content: > anything in this directory will be copied directly into the server > > Comments? It is expected that work will be started on this tooling very > shortly to replace the current build plugin. I am going to create a > wildfly-build-tools repository to hold these new plugins. > > Stuart > > > _______________________________________________ > 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 Tue Sep 2 00:18:55 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Tue, 02 Sep 2014 14:18:55 +1000 Subject: [wildfly-dev] Console and feature packs Message-ID: <5405452F.9040402@gmail.com> Hi everyone, Now that we have the initial feature pack and provisioning stuff working I have been thinking a bit about what we should do with the console. I think it makes the most sense to just have the console as a separate feature pack, as this gives us the maximum amount of flexibility. In particular this will make it easy to provision Wildfly-core and Wildfly-web instances with or without the console as required. Assuming we go down this route this gives us a few options as to where this should live: - Wildfly Core repo - This would not be part of a standard core build, but would just build another feature pack with only the console (like this: https://github.com/stuartwdouglas/wildfly-core/compare/console-feature-pack). - Its own repo - We could create a new repo just for this, but it seems like overkill. - The console project - This would mean that the feature pack would then be versioned using the same scheme as the console, every time the console was released the feature pack should be ready immediately. - Somewhere else - The full WF distro, or the upcoming wildfly-web repo for instance. For what it is worth I think that it would make the most sense for this to live in the console project, as this gives us the maximum flexibility. Stuart From hbraun at redhat.com Tue Sep 2 04:08:02 2014 From: hbraun at redhat.com (Heiko Braun) Date: Tue, 2 Sep 2014 10:08:02 +0200 Subject: [wildfly-dev] Console and feature packs In-Reply-To: <5405452F.9040402@gmail.com> References: <5405452F.9040402@gmail.com> Message-ID: On 02 Sep 2014, at 06:18, Stuart Douglas wrote: > - The console project - This would mean that the feature pack would then be versioned using the same scheme as the console, every time the console was released the feature pack should be ready immediately. > > > For what it is worth I think that it would make the most sense for this to live in the console project, as this gives us the maximum flexibility. +1 I fully agree. Can you point to some docs how create and provide a feature pack? We can then take care to delivery it part of the next release. Heiko -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140902/21bf8f18/attachment.html From stuart.w.douglas at gmail.com Tue Sep 2 06:17:23 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Tue, 02 Sep 2014 20:17:23 +1000 Subject: [wildfly-dev] Console and feature packs In-Reply-To: References: <5405452F.9040402@gmail.com> Message-ID: <54059933.9050407@gmail.com> I will try and update the docs this week (at the moment they refer to the old build plugin). There is actually not that much too it, this commit https://github.com/stuartwdouglas/wildfly-core/commit/782f1e384dd6256e64fe7939a0d13209d3ef8f5b adds a module to build a console feature pack to wildfly-core, you basically just need to do the same thing in the console project (note that there is a minor bug at the moment where the content directory is required, even if there is no additional content, hence the .gitkeep file). If you then want to install that feature pack into a server you just add it to the server-provisioning.xml file for the relevant build. Stuart Heiko Braun wrote: > > On 02 Sep 2014, at 06:18, Stuart Douglas > wrote: > >> - The console project - This would mean that the feature pack would >> then be versioned using the same scheme as the console, every time the >> console was released the feature pack should be ready immediately. >> >> >> For what it is worth I think that it would make the most sense for >> this to live in the console project, as this gives us the maximum >> flexibility. > > > +1 > > I fully agree. > > Can you point to some docs how create and provide a feature pack? We can > then take care to delivery it part of the next release. > > Heiko From ssilvert at redhat.com Tue Sep 2 13:30:25 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Tue, 02 Sep 2014 13:30:25 -0400 Subject: [wildfly-dev] No more metadata main? In-Reply-To: <5400E4D3.7060603@gmail.com> References: <5400B5B6.9070908@redhat.com> <5400B613.5090603@redhat.com> <5400E4D3.7060603@gmail.com> Message-ID: <5405FEB1.5070900@redhat.com> Stuart, This is what I'm thinking for the main module. Does this look correct? What feature pack should it live in? On 8/29/2014 4:38 PM, Stuart Douglas wrote: > No objections here. > > Stuart > > Stan Silvert wrote: >> BTW, I don't mean put the resources back. I just mean should we have an >> aggregation module? >> >> On 8/29/2014 1:17 PM, Stan Silvert wrote: >>> The org.jboss.metadata main module has gone away in WildFly 9. This >>> used to include all the jboss metadata resources but has now been >>> broken up. >>> >>> However, this breaks the Keycloak subsystem and any other module that >>> used to reference it as a dependency. Should we restore this module >>> for backward compatibility? >>> >>> Stan >>> _______________________________________________ >>> 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 stuart.w.douglas at gmail.com Tue Sep 2 16:52:08 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Wed, 03 Sep 2014 06:52:08 +1000 Subject: [wildfly-dev] No more metadata main? In-Reply-To: <5405FEB1.5070900@redhat.com> References: <5400B5B6.9070908@redhat.com> <5400B613.5090603@redhat.com> <5400E4D3.7060603@gmail.com> <5405FEB1.5070900@redhat.com> Message-ID: <54062DF8.9090002@gmail.com> It looks ok, and should be part of the main feature pack. Stuart Stan Silvert wrote: > Stuart, > > This is what I'm thinking for the main module. Does this look correct? > What feature pack should it live in? > > > > > > > > > > > > > On 8/29/2014 4:38 PM, Stuart Douglas wrote: >> No objections here. >> >> Stuart >> >> Stan Silvert wrote: >>> BTW, I don't mean put the resources back. I just mean should we have an >>> aggregation module? >>> >>> On 8/29/2014 1:17 PM, Stan Silvert wrote: >>>> The org.jboss.metadata main module has gone away in WildFly 9. This >>>> used to include all the jboss metadata resources but has now been >>>> broken up. >>>> >>>> However, this breaks the Keycloak subsystem and any other module that >>>> used to reference it as a dependency. Should we restore this module >>>> for backward compatibility? >>>> >>>> Stan >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > From brian.stansberry at redhat.com Wed Sep 3 12:16:21 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 03 Sep 2014 11:16:21 -0500 Subject: [wildfly-dev] Resolve your JIRAs Message-ID: <54073ED5.4080106@redhat.com> Please resolve your JIRAs in "Pull Request Sent" state once the pull request is merged. Use Workflow -> Pull Request Closed to move the issue to Resolved state. -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From sdouglas at redhat.com Thu Sep 4 00:16:47 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Thu, 04 Sep 2014 14:16:47 +1000 Subject: [wildfly-dev] Customizing a provisioned server Message-ID: <5407E7AF.6060701@redhat.com> Hi everyone, Work on the provisioning tool is now well underway, so I would like to revisit something I mentioned in my original email, which is allowing the provisioning tool to customize a provisioned server. I think there are a few options here, some more palatable than others. In no particular order: 1) Customize the XML directly Using this approach we would just directly customize the XML configuration files. This would basically require the use of XSLT (yuck), or require us to basically invent our own version of XSLT (even more yuck). Even though this approach will work, and will be fairly easy to implement, I think it would really suck from an end-user point of view, and I think we should discount it. 2) Allow the user to provide CLI commands to customise the server This is by far my favorite approach. The provisioning file would just contain a list of CLI commands, and would execute them in order. I think this is by far the most intuitive, and the CLI is well documented. 3) Allow the user to provide DMR operations to customize the server Similar to 2, but allow the user to provide DMR or JSON operations to customize the server. I think this is not nearly as nice as 2, as users are much more likely to be familiar with the CLI rather than DMR. I think 2 is by far the best approach, however it does open up the question of how and when to execute the operations. I think the easiest way to do this would be to just start the server in admin only mode on a custom port (so it will not interfere with any existing running Wildfly instances), and just execute the CLI commands in admin only mode. Does this all sound reasonable? Stuart From stuart.w.douglas at gmail.com Thu Sep 4 00:25:53 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Thu, 04 Sep 2014 14:25:53 +1000 Subject: [wildfly-dev] Customizing a provisioned server In-Reply-To: <5407E7AF.6060701@redhat.com> References: <5407E7AF.6060701@redhat.com> Message-ID: <5407E9D1.70404@gmail.com> Something I forgot to mention is that these customizations will need to be specified per config file, so you may specify different customizations for standalone.xml, standalone-full.xml and domain.xml for example. Unfortunately this will involve stopping and starting the admin only server multiple times, but I can't really see any way around that. Stuart Douglas wrote: > Hi everyone, > > Work on the provisioning tool is now well underway, so I would like to > revisit something I mentioned in my original email, which is allowing > the provisioning tool to customize a provisioned server. > > I think there are a few options here, some more palatable than others. > In no particular order: > > 1) Customize the XML directly > > Using this approach we would just directly customize the XML > configuration files. This would basically require the use of XSLT > (yuck), or require us to basically invent our own version of XSLT (even > more yuck). Even though this approach will work, and will be fairly easy > to implement, I think it would really suck from an end-user point of > view, and I think we should discount it. > > 2) Allow the user to provide CLI commands to customise the server > > This is by far my favorite approach. The provisioning file would just > contain a list of CLI commands, and would execute them in order. I think > this is by far the most intuitive, and the CLI is well documented. > > 3) Allow the user to provide DMR operations to customize the server > > Similar to 2, but allow the user to provide DMR or JSON operations to > customize the server. I think this is not nearly as nice as 2, as users > are much more likely to be familiar with the CLI rather than DMR. > > > I think 2 is by far the best approach, however it does open up the > question of how and when to execute the operations. I think the easiest > way to do this would be to just start the server in admin only mode on a > custom port (so it will not interfere with any existing running Wildfly > instances), and just execute the CLI commands in admin only mode. > > Does this all sound reasonable? > > Stuart > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From jason.greene at redhat.com Thu Sep 4 00:28:17 2014 From: jason.greene at redhat.com (Jason Greene) Date: Wed, 3 Sep 2014 23:28:17 -0500 Subject: [wildfly-dev] Customizing a provisioned server In-Reply-To: <5407E7AF.6060701@redhat.com> References: <5407E7AF.6060701@redhat.com> Message-ID: On Sep 3, 2014, at 11:16 PM, Stuart Douglas wrote: > Hi everyone, > > Work on the provisioning tool is now well underway, so I would like to > revisit something I mentioned in my original email, which is allowing > the provisioning tool to customize a provisioned server. > > I think there are a few options here, some more palatable than others. > In no particular order: > > 1) Customize the XML directly > > Using this approach we would just directly customize the XML > configuration files. This would basically require the use of XSLT > (yuck), or require us to basically invent our own version of XSLT (even > more yuck). Even though this approach will work, and will be fairly easy > to implement, I think it would really suck from an end-user point of > view, and I think we should discount it. > > 2) Allow the user to provide CLI commands to customise the server > > This is by far my favorite approach. The provisioning file would just > contain a list of CLI commands, and would execute them in order. I think > this is by far the most intuitive, and the CLI is well documented. > > 3) Allow the user to provide DMR operations to customize the server > > Similar to 2, but allow the user to provide DMR or JSON operations to > customize the server. I think this is not nearly as nice as 2, as users > are much more likely to be familiar with the CLI rather than DMR. > > > I think 2 is by far the best approach, however it does open up the > question of how and when to execute the operations. I think the easiest > way to do this would be to just start the server in admin only mode on a > custom port (so it will not interfere with any existing running Wildfly > instances), and just execute the CLI commands in admin only mode. My big concern is how we deal with overlapping configuration. If we figure that out something like 2 or 3 aren?t that much different to me. 2 is just an abbreviated syntax for the operation element. Note that we have a feature request for ?offline CLI? which amounts to really an embedded management mode with no ports. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From hbraun at redhat.com Thu Sep 4 03:05:52 2014 From: hbraun at redhat.com (Heiko Braun) Date: Thu, 4 Sep 2014 09:05:52 +0200 Subject: [wildfly-dev] Customizing a provisioned server In-Reply-To: <5407E7AF.6060701@redhat.com> References: <5407E7AF.6060701@redhat.com> Message-ID: 2) builds on 3), right? On 04 Sep 2014, at 06:16, Stuart Douglas wrote: > 2) Allow the user to provide CLI commands to customise the server > > This is by far my favorite approach. The provisioning file would just > contain a list of CLI commands, and would execute them in order. I think > this is by far the most intuitive, and the CLI is well documented. > > 3) Allow the user to provide DMR operations to customize the server > > Similar to 2, but allow the user to provide DMR or JSON operations to > customize the server. I think this is not nearly as nice as 2, as users > are much more likely to be familiar with the CLI rather than DMR. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140904/d90e1071/attachment.html From theute at redhat.com Thu Sep 4 06:15:23 2014 From: theute at redhat.com (Thomas Heute) Date: Thu, 04 Sep 2014 12:15:23 +0200 Subject: [wildfly-dev] Customizing a provisioned server In-Reply-To: <5407E7AF.6060701@redhat.com> References: <5407E7AF.6060701@redhat.com> Message-ID: <54083BBB.1000806@redhat.com> I would need to provision Wildfly remotely with something like JON or Fabric8 for instance, the CLI would not work for that if I understand correctly. REST-ish API would work better I think (I guess option 3 covers that), Fabric8 preference would likely be option 1 though (note that in this usecase the end-user doesn't really touch the XML files, he's using a tool) BTW: I completely missed the discussion about provisioning tool until this email so please forgive my ignorance. If there is a document or email thread that would help me catch up I would love to have a look. Thomas On 09/04/2014 06:16 AM, Stuart Douglas wrote: > Hi everyone, > > Work on the provisioning tool is now well underway, so I would like to > revisit something I mentioned in my original email, which is allowing > the provisioning tool to customize a provisioned server. > > I think there are a few options here, some more palatable than others. > In no particular order: > > 1) Customize the XML directly > > Using this approach we would just directly customize the XML > configuration files. This would basically require the use of XSLT > (yuck), or require us to basically invent our own version of XSLT (even > more yuck). Even though this approach will work, and will be fairly easy > to implement, I think it would really suck from an end-user point of > view, and I think we should discount it. > > 2) Allow the user to provide CLI commands to customise the server > > This is by far my favorite approach. The provisioning file would just > contain a list of CLI commands, and would execute them in order. I think > this is by far the most intuitive, and the CLI is well documented. > > 3) Allow the user to provide DMR operations to customize the server > > Similar to 2, but allow the user to provide DMR or JSON operations to > customize the server. I think this is not nearly as nice as 2, as users > are much more likely to be familiar with the CLI rather than DMR. > > > I think 2 is by far the best approach, however it does open up the > question of how and when to execute the operations. I think the easiest > way to do this would be to just start the server in admin only mode on a > custom port (so it will not interfere with any existing running Wildfly > instances), and just execute the CLI commands in admin only mode. > > Does this all sound reasonable? > > Stuart > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From eduardo.santanadasilva at gmail.com Thu Sep 4 06:26:26 2014 From: eduardo.santanadasilva at gmail.com (=?UTF-8?Q?Eduardo_Sant=C2=B4Ana_da_Silva?=) Date: Thu, 4 Sep 2014 07:26:26 -0300 Subject: [wildfly-dev] Customizing a provisioned server In-Reply-To: <54083BBB.1000806@redhat.com> References: <5407E7AF.6060701@redhat.com> <54083BBB.1000806@redhat.com> Message-ID: Thomas, Here is some threads about the provisioning discussion: http://lists.jboss.org/pipermail/wildfly-dev/2014-June/002330.html http://lists.jboss.org/pipermail/wildfly-dev/2014-July/002523.html http://lists.jboss.org/pipermail/wildfly-dev/2014-August/002831.html http://lists.jboss.org/pipermail/wildfly-dev/2014-September/002912.html http://lists.jboss.org/pipermail/wildfly-dev/2014-September/002919.html 2014-09-04 7:15 GMT-03:00 Thomas Heute : > > I would need to provision Wildfly remotely with something like JON or > Fabric8 for instance, the CLI would not work for that if I understand > correctly. > > REST-ish API would work better I think (I guess option 3 covers that), > Fabric8 preference would likely be option 1 though (note that in this > usecase the end-user doesn't really touch the XML files, he's using a tool) > > BTW: I completely missed the discussion about provisioning tool until > this email so please forgive my ignorance. If there is a document or > email thread that would help me catch up I would love to have a look. > > Thomas > > > On 09/04/2014 06:16 AM, Stuart Douglas wrote: > > Hi everyone, > > > > Work on the provisioning tool is now well underway, so I would like to > > revisit something I mentioned in my original email, which is allowing > > the provisioning tool to customize a provisioned server. > > > > I think there are a few options here, some more palatable than others. > > In no particular order: > > > > 1) Customize the XML directly > > > > Using this approach we would just directly customize the XML > > configuration files. This would basically require the use of XSLT > > (yuck), or require us to basically invent our own version of XSLT (even > > more yuck). Even though this approach will work, and will be fairly easy > > to implement, I think it would really suck from an end-user point of > > view, and I think we should discount it. > > > > 2) Allow the user to provide CLI commands to customise the server > > > > This is by far my favorite approach. The provisioning file would just > > contain a list of CLI commands, and would execute them in order. I think > > this is by far the most intuitive, and the CLI is well documented. > > > > 3) Allow the user to provide DMR operations to customize the server > > > > Similar to 2, but allow the user to provide DMR or JSON operations to > > customize the server. I think this is not nearly as nice as 2, as users > > are much more likely to be familiar with the CLI rather than DMR. > > > > > > I think 2 is by far the best approach, however it does open up the > > question of how and when to execute the operations. I think the easiest > > way to do this would be to just start the server in admin only mode on a > > custom port (so it will not interfere with any existing running Wildfly > > instances), and just execute the CLI commands in admin only mode. > > > > Does this all sound reasonable? > > > > Stuart > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- __________________________ Eduardo Sant'Ana da Silva - Dr. Pesquisador / Consultor de TI -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140904/c9c2d3d3/attachment.html From tomaz.cerar at gmail.com Thu Sep 4 08:18:14 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Thu, 4 Sep 2014 14:18:14 +0200 Subject: [wildfly-dev] Customizing a provisioned server In-Reply-To: <5407E7AF.6060701@redhat.com> References: <5407E7AF.6060701@redhat.com> Message-ID: Best would be to go with 3) as it works directly with mgmt interface without need for CLI interpreter. This way commands an be executed ether localy or remotely via REST api. CLI enhancements are not all that useful for customizations, beyond few shortcuts with high-level commands. Tomaz On Thu, Sep 4, 2014 at 6:16 AM, Stuart Douglas wrote: > Hi everyone, > > Work on the provisioning tool is now well underway, so I would like to > revisit something I mentioned in my original email, which is allowing > the provisioning tool to customize a provisioned server. > > I think there are a few options here, some more palatable than others. > In no particular order: > > 1) Customize the XML directly > > Using this approach we would just directly customize the XML > configuration files. This would basically require the use of XSLT > (yuck), or require us to basically invent our own version of XSLT (even > more yuck). Even though this approach will work, and will be fairly easy > to implement, I think it would really suck from an end-user point of > view, and I think we should discount it. > > 2) Allow the user to provide CLI commands to customise the server > > This is by far my favorite approach. The provisioning file would just > contain a list of CLI commands, and would execute them in order. I think > this is by far the most intuitive, and the CLI is well documented. > > 3) Allow the user to provide DMR operations to customize the server > > Similar to 2, but allow the user to provide DMR or JSON operations to > customize the server. I think this is not nearly as nice as 2, as users > are much more likely to be familiar with the CLI rather than DMR. > > > I think 2 is by far the best approach, however it does open up the > question of how and when to execute the operations. I think the easiest > way to do this would be to just start the server in admin only mode on a > custom port (so it will not interfere with any existing running Wildfly > instances), and just execute the CLI commands in admin only mode. > > Does this all sound reasonable? > > Stuart > > _______________________________________________ > 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/20140904/2a58e110/attachment-0001.html From emartins at redhat.com Thu Sep 4 09:06:30 2014 From: emartins at redhat.com (Eduardo Martins) Date: Thu, 4 Sep 2014 14:06:30 +0100 Subject: [wildfly-dev] Customizing a provisioned server In-Reply-To: <5407E7AF.6060701@redhat.com> References: <5407E7AF.6060701@redhat.com> Message-ID: <081AA551-F145-4430-9A31-7F12987DC7D7@redhat.com> Perhaps we should start with extending the capabilities of the (standalone) server provisioner api, that we now use to build the server, to stop a server, upgrade it offline, and start it again. The offline upgrade would for now first delete files that were added in the previous version of the server provision, supporting excludes/includes filters to don?t mess with user/server data, and then provision ?everything? again, skipping files that were kept in the output dir. Tools would have access to the previous version of the server provision and start editing from that. ?E On 04 Sep 2014, at 05:16, Stuart Douglas wrote: > Hi everyone, > > Work on the provisioning tool is now well underway, so I would like to > revisit something I mentioned in my original email, which is allowing > the provisioning tool to customize a provisioned server. > > I think there are a few options here, some more palatable than others. > In no particular order: > > 1) Customize the XML directly > > Using this approach we would just directly customize the XML > configuration files. This would basically require the use of XSLT > (yuck), or require us to basically invent our own version of XSLT (even > more yuck). Even though this approach will work, and will be fairly easy > to implement, I think it would really suck from an end-user point of > view, and I think we should discount it. > > 2) Allow the user to provide CLI commands to customise the server > > This is by far my favorite approach. The provisioning file would just > contain a list of CLI commands, and would execute them in order. I think > this is by far the most intuitive, and the CLI is well documented. > > 3) Allow the user to provide DMR operations to customize the server > > Similar to 2, but allow the user to provide DMR or JSON operations to > customize the server. I think this is not nearly as nice as 2, as users > are much more likely to be familiar with the CLI rather than DMR. > > > I think 2 is by far the best approach, however it does open up the > question of how and when to execute the operations. I think the easiest > way to do this would be to just start the server in admin only mode on a > custom port (so it will not interfere with any existing running Wildfly > instances), and just execute the CLI commands in admin only mode. > > Does this all sound reasonable? > > Stuart > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From emartins at redhat.com Thu Sep 4 09:46:01 2014 From: emartins at redhat.com (Eduardo Martins) Date: Thu, 4 Sep 2014 14:46:01 +0100 Subject: [wildfly-dev] Customizing a provisioned server In-Reply-To: <081AA551-F145-4430-9A31-7F12987DC7D7@redhat.com> References: <5407E7AF.6060701@redhat.com> <081AA551-F145-4430-9A31-7F12987DC7D7@redhat.com> Message-ID: <5BDBE5AC-BB75-42FA-B018-1829C8CED92C@redhat.com> We would still need a few mngt ops, to fetch and upgrade the server provisioning. The upgrade op perhaps would just trigger a backup, store the new server provisioning and setup something that would indicate the need for upgrade, and restart the server. Then on startup, it would notice the upgrade and do it, only after that completes the real server would be started. Wdyt? ?E On 04 Sep 2014, at 14:06, Eduardo Martins wrote: > Perhaps we should start with extending the capabilities of the (standalone) server provisioner api, that we now use to build the server, to stop a server, upgrade it offline, and start it again. > > The offline upgrade would for now first delete files that were added in the previous version of the server provision, supporting excludes/includes filters to don?t mess with user/server data, and then provision ?everything? again, skipping files that were kept in the output dir. Tools would have access to the previous version of the server provision and start editing from that. > > ?E > > On 04 Sep 2014, at 05:16, Stuart Douglas wrote: > >> Hi everyone, >> >> Work on the provisioning tool is now well underway, so I would like to >> revisit something I mentioned in my original email, which is allowing >> the provisioning tool to customize a provisioned server. >> >> I think there are a few options here, some more palatable than others. >> In no particular order: >> >> 1) Customize the XML directly >> >> Using this approach we would just directly customize the XML >> configuration files. This would basically require the use of XSLT >> (yuck), or require us to basically invent our own version of XSLT (even >> more yuck). Even though this approach will work, and will be fairly easy >> to implement, I think it would really suck from an end-user point of >> view, and I think we should discount it. >> >> 2) Allow the user to provide CLI commands to customise the server >> >> This is by far my favorite approach. The provisioning file would just >> contain a list of CLI commands, and would execute them in order. I think >> this is by far the most intuitive, and the CLI is well documented. >> >> 3) Allow the user to provide DMR operations to customize the server >> >> Similar to 2, but allow the user to provide DMR or JSON operations to >> customize the server. I think this is not nearly as nice as 2, as users >> are much more likely to be familiar with the CLI rather than DMR. >> >> >> I think 2 is by far the best approach, however it does open up the >> question of how and when to execute the operations. I think the easiest >> way to do this would be to just start the server in admin only mode on a >> custom port (so it will not interfere with any existing running Wildfly >> instances), and just execute the CLI commands in admin only mode. >> >> Does this all sound reasonable? >> >> Stuart >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From jperkins at redhat.com Thu Sep 4 11:51:11 2014 From: jperkins at redhat.com (James R. Perkins) Date: Thu, 04 Sep 2014 08:51:11 -0700 Subject: [wildfly-dev] Customizing a provisioned server In-Reply-To: <081AA551-F145-4430-9A31-7F12987DC7D7@redhat.com> References: <081AA551-F145-4430-9A31-7F12987DC7D7@redhat.com> Message-ID: <1409845871.572.0@localhost> If I understand it correctly the provisioning tool is used to create a server. What server will be running that would need to be stopped and then restarted? This doesn't sound like a provisioning thing to me. Is it also meant to do patching? -- James R. Perkins JBoss by Red Hat On Thu, Sep 4, 2014 at 6:06 AM, Eduardo Martins wrote: > Perhaps we should start with extending the capabilities of the > (standalone) server provisioner api, that we now use to build the > server, to stop a server, upgrade it offline, and start it again. > > The offline upgrade would for now first delete files that were added > in the previous version of the server provision, supporting > excludes/includes filters to don?t mess with user/server data, and > then provision ?everything? again, skipping files that were kept > in the output dir. Tools would have access to the previous version of > the server provision and start editing from that. > > ?E > > On 04 Sep 2014, at 05:16, Stuart Douglas wrote: > >> Hi everyone, >> >> Work on the provisioning tool is now well underway, so I would like >> to >> revisit something I mentioned in my original email, which is >> allowing >> the provisioning tool to customize a provisioned server. >> >> I think there are a few options here, some more palatable than >> others. >> In no particular order: >> >> 1) Customize the XML directly >> >> Using this approach we would just directly customize the XML >> configuration files. This would basically require the use of XSLT >> (yuck), or require us to basically invent our own version of XSLT >> (even >> more yuck). Even though this approach will work, and will be fairly >> easy >> to implement, I think it would really suck from an end-user point of >> view, and I think we should discount it. >> >> 2) Allow the user to provide CLI commands to customise the server >> >> This is by far my favorite approach. The provisioning file would >> just >> contain a list of CLI commands, and would execute them in order. I >> think >> this is by far the most intuitive, and the CLI is well documented. >> >> 3) Allow the user to provide DMR operations to customize the server >> >> Similar to 2, but allow the user to provide DMR or JSON operations >> to >> customize the server. I think this is not nearly as nice as 2, as >> users >> are much more likely to be familiar with the CLI rather than DMR. >> >> >> I think 2 is by far the best approach, however it does open up the >> question of how and when to execute the operations. I think the >> easiest >> way to do this would be to just start the server in admin only mode >> on a >> custom port (so it will not interfere with any existing running >> Wildfly >> instances), and just execute the CLI commands in admin only mode. >> >> Does this all sound reasonable? >> >> Stuart >> >> _______________________________________________ >> 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/20140904/9f876a1a/attachment.html From emartins at redhat.com Thu Sep 4 12:06:41 2014 From: emartins at redhat.com (Eduardo Martins) Date: Thu, 4 Sep 2014 17:06:41 +0100 Subject: [wildfly-dev] Customizing a provisioned server In-Reply-To: <1409845871.572.0@localhost> References: <081AA551-F145-4430-9A31-7F12987DC7D7@redhat.com> <1409845871.572.0@localhost> Message-ID: <31CCCAFF-7017-44B0-83B6-F96296CCFDB6@redhat.com> The provisioning tool assembles a server from a set of feature packs, it will also be able to customize the assembled and possibly running server, for instance add feature pack, add modules, etc. ?E On 04 Sep 2014, at 16:51, James R. Perkins wrote: > If I understand it correctly the provisioning tool is used to create a server. What server will be running that would need to be stopped and then restarted? This doesn't sound like a provisioning thing to me. Is it also meant to do patching? > > -- > James R. Perkins > JBoss by Red Hat > > On Thu, Sep 4, 2014 at 6:06 AM, Eduardo Martins wrote: >> Perhaps we should start with extending the capabilities of the (standalone) server provisioner api, that we now use to build the server, to stop a server, upgrade it offline, and start it again. >> >> The offline upgrade would for now first delete files that were added in the previous version of the server provision, supporting excludes/includes filters to don?t mess with user/server data, and then provision ?everything? again, skipping files that were kept in the output dir. Tools would have access to the previous version of the server provision and start editing from that. >> >> ?E >> >> On 04 Sep 2014, at 05:16, Stuart Douglas wrote: >> >> Hi everyone, >> >> Work on the provisioning tool is now well underway, so I would like to >> revisit something I mentioned in my original email, which is allowing >> the provisioning tool to customize a provisioned server. >> >> I think there are a few options here, some more palatable than others. >> In no particular order: >> >> 1) Customize the XML directly >> >> Using this approach we would just directly customize the XML >> configuration files. This would basically require the use of XSLT >> (yuck), or require us to basically invent our own version of XSLT (even >> more yuck). Even though this approach will work, and will be fairly easy >> to implement, I think it would really suck from an end-user point of >> view, and I think we should discount it. >> >> 2) Allow the user to provide CLI commands to customise the server >> >> This is by far my favorite approach. The provisioning file would just >> contain a list of CLI commands, and would execute them in order. I think >> this is by far the most intuitive, and the CLI is well documented. >> >> 3) Allow the user to provide DMR operations to customize the server >> >> Similar to 2, but allow the user to provide DMR or JSON operations to >> customize the server. I think this is not nearly as nice as 2, as users >> are much more likely to be familiar with the CLI rather than DMR. >> >> >> I think 2 is by far the best approach, however it does open up the >> question of how and when to execute the operations. I think the easiest >> way to do this would be to just start the server in admin only mode on a >> custom port (so it will not interfere with any existing running Wildfly >> instances), and just execute the CLI commands in admin only mode. >> >> Does this all sound reasonable? >> >> Stuart >> >> _______________________________________________ >> 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/20140904/2d97d709/attachment.html From jperkins at redhat.com Thu Sep 4 12:34:43 2014 From: jperkins at redhat.com (James R. Perkins) Date: Thu, 04 Sep 2014 09:34:43 -0700 Subject: [wildfly-dev] Customizing a provisioned server In-Reply-To: <31CCCAFF-7017-44B0-83B6-F96296CCFDB6@redhat.com> References: <31CCCAFF-7017-44B0-83B6-F96296CCFDB6@redhat.com> Message-ID: <1409848483.572.1@localhost> Ah okay so we may add feature packs to an already "provisioned" server. I don't think it's a good idea for the provisioning to tool to stop and start a server. If you stop shutdown a server, apply the new feature packs and start a new process. The new process may inherit the parent processes I/O which could be problematic. -- James R. Perkins JBoss by Red Hat On Thu, Sep 4, 2014 at 9:06 AM, Eduardo Martins wrote: > The provisioning tool assembles a server from a set of feature packs, > it will also be able to customize the assembled and possibly running > server, for instance add feature pack, add modules, etc. > > ?E > > On 04 Sep 2014, at 16:51, James R. Perkins > wrote: > >> If I understand it correctly the provisioning tool is used to create >> a server. What server will be running that would need to be stopped >> and then restarted? This doesn't sound like a provisioning thing to >> me. Is it also meant to do patching? >> >> -- >> James R. Perkins >> JBoss by Red Hat >> >> On Thu, Sep 4, 2014 at 6:06 AM, Eduardo Martins >> wrote: >>> Perhaps we should start with extending the capabilities of the >>> (standalone) server provisioner api, that we now use to build the >>> server, to stop a server, upgrade it offline, and start it again. >>> >>> The offline upgrade would for now first delete files that were >>> added in the previous version of the server provision, supporting >>> excludes/includes filters to don?t mess with user/server data, >>> and then provision ?everything? again, skipping files that were >>> kept in the output dir. Tools would have access to the previous >>> version of the server provision and start editing from that. >>> >>> ?E >>> >>> On 04 Sep 2014, at 05:16, Stuart Douglas >>> wrote: >>> >>>> Hi everyone, >>>> >>>> Work on the provisioning tool is now well underway, so I would >>>> like to >>>> revisit something I mentioned in my original email, which is >>>> allowing >>>> the provisioning tool to customize a provisioned server. >>>> >>>> I think there are a few options here, some more palatable than >>>> others. >>>> In no particular order: >>>> >>>> 1) Customize the XML directly >>>> >>>> Using this approach we would just directly customize the XML >>>> configuration files. This would basically require the use of XSLT >>>> (yuck), or require us to basically invent our own version of XSLT >>>> (even >>>> more yuck). Even though this approach will work, and will be >>>> fairly easy >>>> to implement, I think it would really suck from an end-user point >>>> of >>>> view, and I think we should discount it. >>>> >>>> 2) Allow the user to provide CLI commands to customise the server >>>> >>>> This is by far my favorite approach. The provisioning file would >>>> just >>>> contain a list of CLI commands, and would execute them in order. >>>> I think >>>> this is by far the most intuitive, and the CLI is well documented. >>>> >>>> 3) Allow the user to provide DMR operations to customize the >>>> server >>>> >>>> Similar to 2, but allow the user to provide DMR or JSON >>>> operations to >>>> customize the server. I think this is not nearly as nice as 2, as >>>> users >>>> are much more likely to be familiar with the CLI rather than DMR. >>>> >>>> >>>> I think 2 is by far the best approach, however it does open up the >>>> question of how and when to execute the operations. I think the >>>> easiest >>>> way to do this would be to just start the server in admin only >>>> mode on a >>>> custom port (so it will not interfere with any existing running >>>> Wildfly >>>> instances), and just execute the CLI commands in admin only mode. >>>> >>>> Does this all sound reasonable? >>>> >>>> Stuart >>>> >>>> _______________________________________________ >>>> 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/20140904/e85079c9/attachment-0001.html From brian.stansberry at redhat.com Thu Sep 4 17:06:49 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 04 Sep 2014 16:06:49 -0500 Subject: [wildfly-dev] Customizing a provisioned server In-Reply-To: References: <5407E7AF.6060701@redhat.com> Message-ID: <5408D469.7080508@redhat.com> Not necessarily. Everything in the end speaks the underlying management API. But that doesn't mean the syntax needs to be the raw dmr or json equivalent. This is primarily about UX and parsing. If we supported CLI syntax there's no requirement to also parse basic DMR. The CLI itself doesn't. If we support CLI syntax though it seems logical to use the CLI libs themselves to do it. Otherwise we are maintaining two code bases for the same thing. (I doubt the CLI parsing code can easily be extracted out for reuse, although I may be wrong.) On 9/4/14, 2:05 AM, Heiko Braun wrote: > > 2) builds on 3), right? > > On 04 Sep 2014, at 06:16, Stuart Douglas > wrote: > >> 2) Allow the user to provide CLI commands to customise the server >> >> This is by far my favorite approach. The provisioning file would just >> contain a list of CLI commands, and would execute them in order. I think >> this is by far the most intuitive, and the CLI is well documented. >> >> 3) Allow the user to provide DMR operations to customize the server >> >> Similar to 2, but allow the user to provide DMR or JSON operations to >> customize the server. I think this is not nearly as nice as 2, as users >> are much more likely to be familiar with the CLI rather than DMR. > > > > _______________________________________________ > 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 stuart.w.douglas at gmail.com Thu Sep 4 17:14:36 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Fri, 05 Sep 2014 07:14:36 +1000 Subject: [wildfly-dev] Customizing a provisioned server In-Reply-To: <5408D469.7080508@redhat.com> References: <5407E7AF.6060701@redhat.com> <5408D469.7080508@redhat.com> Message-ID: <5408D63C.2000604@gmail.com> I thought that it was already possible to use the CLI in library mode? The tool will have access to a full server at the point it needs to do this (as the server has already been provisioned), so it could potentially just load the CLI lib from the provisioned server and use that. Stuart Brian Stansberry wrote: > Not necessarily. Everything in the end speaks the underlying management > API. But that doesn't mean the syntax needs to be the raw dmr or json > equivalent. > > This is primarily about UX and parsing. If we supported CLI syntax > there's no requirement to also parse basic DMR. The CLI itself doesn't. > > If we support CLI syntax though it seems logical to use the CLI libs > themselves to do it. Otherwise we are maintaining two code bases for the > same thing. (I doubt the CLI parsing code can easily be extracted out > for reuse, although I may be wrong.) > > On 9/4/14, 2:05 AM, Heiko Braun wrote: >> 2) builds on 3), right? >> >> On 04 Sep 2014, at 06:16, Stuart Douglas> > wrote: >> >>> 2) Allow the user to provide CLI commands to customise the server >>> >>> This is by far my favorite approach. The provisioning file would just >>> contain a list of CLI commands, and would execute them in order. I think >>> this is by far the most intuitive, and the CLI is well documented. >>> >>> 3) Allow the user to provide DMR operations to customize the server >>> >>> Similar to 2, but allow the user to provide DMR or JSON operations to >>> customize the server. I think this is not nearly as nice as 2, as users >>> are much more likely to be familiar with the CLI rather than DMR. >> >> >> _______________________________________________ >> 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 Thu Sep 4 17:15:51 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Fri, 05 Sep 2014 07:15:51 +1000 Subject: [wildfly-dev] Customizing a provisioned server In-Reply-To: <54083BBB.1000806@redhat.com> References: <5407E7AF.6060701@redhat.com> <54083BBB.1000806@redhat.com> Message-ID: <5408D687.4010304@gmail.com> Thomas Heute wrote: > I would need to provision Wildfly remotely with something like JON or > Fabric8 for instance, the CLI would not work for that if I understand > correctly. > This is more about how to customize a server after it has been provisioned. So for example you can have a file that basically says 'I want a WF instance with these features, these deployments, and then perform these mgmt ops to configure it' Stuart > REST-ish API would work better I think (I guess option 3 covers that), > Fabric8 preference would likely be option 1 though (note that in this > usecase the end-user doesn't really touch the XML files, he's using a tool) > > BTW: I completely missed the discussion about provisioning tool until > this email so please forgive my ignorance. If there is a document or > email thread that would help me catch up I would love to have a look. > > Thomas > > > On 09/04/2014 06:16 AM, Stuart Douglas wrote: >> Hi everyone, >> >> Work on the provisioning tool is now well underway, so I would like to >> revisit something I mentioned in my original email, which is allowing >> the provisioning tool to customize a provisioned server. >> >> I think there are a few options here, some more palatable than others. >> In no particular order: >> >> 1) Customize the XML directly >> >> Using this approach we would just directly customize the XML >> configuration files. This would basically require the use of XSLT >> (yuck), or require us to basically invent our own version of XSLT (even >> more yuck). Even though this approach will work, and will be fairly easy >> to implement, I think it would really suck from an end-user point of >> view, and I think we should discount it. >> >> 2) Allow the user to provide CLI commands to customise the server >> >> This is by far my favorite approach. The provisioning file would just >> contain a list of CLI commands, and would execute them in order. I think >> this is by far the most intuitive, and the CLI is well documented. >> >> 3) Allow the user to provide DMR operations to customize the server >> >> Similar to 2, but allow the user to provide DMR or JSON operations to >> customize the server. I think this is not nearly as nice as 2, as users >> are much more likely to be familiar with the CLI rather than DMR. >> >> >> I think 2 is by far the best approach, however it does open up the >> question of how and when to execute the operations. I think the easiest >> way to do this would be to just start the server in admin only mode on a >> custom port (so it will not interfere with any existing running Wildfly >> instances), and just execute the CLI commands in admin only mode. >> >> Does this all sound reasonable? >> >> Stuart >> >> _______________________________________________ >> 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 stuart.w.douglas at gmail.com Thu Sep 4 17:17:12 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Fri, 05 Sep 2014 07:17:12 +1000 Subject: [wildfly-dev] Customizing a provisioned server In-Reply-To: References: <5407E7AF.6060701@redhat.com> Message-ID: <5408D6D8.4050305@gmail.com> The problem with 3 is that for the most part users do not use DMR directly, they use the CLI, and all our documentation reflects this. If we use DMR directly for this it just one more thing that we require our users to learn. Stuart Toma? Cerar wrote: > Best would be to go with 3) > > as it works directly with mgmt interface without need for CLI interpreter. > This way commands an be executed ether localy or remotely via REST api. > > CLI enhancements are not all that useful for customizations, beyond few > shortcuts with high-level commands. > > Tomaz > > > On Thu, Sep 4, 2014 at 6:16 AM, Stuart Douglas > wrote: > > Hi everyone, > > Work on the provisioning tool is now well underway, so I would like to > revisit something I mentioned in my original email, which is allowing > the provisioning tool to customize a provisioned server. > > I think there are a few options here, some more palatable than others. > In no particular order: > > 1) Customize the XML directly > > Using this approach we would just directly customize the XML > configuration files. This would basically require the use of XSLT > (yuck), or require us to basically invent our own version of XSLT (even > more yuck). Even though this approach will work, and will be fairly easy > to implement, I think it would really suck from an end-user point of > view, and I think we should discount it. > > 2) Allow the user to provide CLI commands to customise the server > > This is by far my favorite approach. The provisioning file would just > contain a list of CLI commands, and would execute them in order. I think > this is by far the most intuitive, and the CLI is well documented. > > 3) Allow the user to provide DMR operations to customize the server > > Similar to 2, but allow the user to provide DMR or JSON operations to > customize the server. I think this is not nearly as nice as 2, as users > are much more likely to be familiar with the CLI rather than DMR. > > > I think 2 is by far the best approach, however it does open up the > question of how and when to execute the operations. I think the easiest > way to do this would be to just start the server in admin only mode on a > custom port (so it will not interfere with any existing running Wildfly > instances), and just execute the CLI commands in admin only mode. > > Does this all sound reasonable? > > Stuart > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From brian.stansberry at redhat.com Thu Sep 4 17:18:02 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 04 Sep 2014 16:18:02 -0500 Subject: [wildfly-dev] Customizing a provisioned server In-Reply-To: <5407E7AF.6060701@redhat.com> References: <5407E7AF.6060701@redhat.com> Message-ID: <5408D70A.7060908@redhat.com> On 9/3/14, 11:16 PM, Stuart Douglas wrote: > Hi everyone, > > Work on the provisioning tool is now well underway, so I would like to > revisit something I mentioned in my original email, which is allowing > the provisioning tool to customize a provisioned server. > > I think there are a few options here, some more palatable than others. > In no particular order: > > 1) Customize the XML directly > > Using this approach we would just directly customize the XML > configuration files. This would basically require the use of XSLT > (yuck), or require us to basically invent our own version of XSLT (even > more yuck). Even though this approach will work, and will be fairly easy > to implement, I think it would really suck from an end-user point of > view, and I think we should discount it. > I can't see this as workable at all for generic customization. I could see it for a setup where a user provides a list of capabilities, and we produce a tailored xml that provides those capabilities. The xml is still some standard config, just mildly customizable by listing capabilities. Implemented perhaps using something like the templating thing we've used in the past. But if the idea is to support arbitrary config changes, no way xml is an option. > 2) Allow the user to provide CLI commands to customise the server > > This is by far my favorite approach. The provisioning file would just > contain a list of CLI commands, and would execute them in order. I think > this is by far the most intuitive, and the CLI is well documented. > > 3) Allow the user to provide DMR operations to customize the server > > Similar to 2, but allow the user to provide DMR or JSON operations to > customize the server. I think this is not nearly as nice as 2, as users > are much more likely to be familiar with the CLI rather than DMR. > > > I think 2 is by far the best approach, however it does open up the > question of how and when to execute the operations. I think the easiest > way to do this would be to just start the server in admin only mode on a > custom port (so it will not interfere with any existing running Wildfly > instances), and just execute the CLI commands in admin only mode. > If we are going to use the management API, we need to start an embedded process with no ports open. Otherwise people should just use one of our existing management tools. > Does this all sound reasonable? > > Stuart > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Thu Sep 4 17:23:36 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 04 Sep 2014 16:23:36 -0500 Subject: [wildfly-dev] Customizing a provisioned server In-Reply-To: <5408D63C.2000604@gmail.com> References: <5407E7AF.6060701@redhat.com> <5408D469.7080508@redhat.com> <5408D63C.2000604@gmail.com> Message-ID: <5408D858.8090604@redhat.com> Yes, the CLI can be used as a library. But it works via remote communication, which IMHO is not something we should be doing here. Running the server embedded in the tool with no ports open is fine though. I think if people want to configure the server remotely they should launch it and use one of the existing tools. On 9/4/14, 4:14 PM, Stuart Douglas wrote: > I thought that it was already possible to use the CLI in library mode? > > The tool will have access to a full server at the point it needs to do > this (as the server has already been provisioned), so it could > potentially just load the CLI lib from the provisioned server and use that. > > Stuart > > Brian Stansberry wrote: >> Not necessarily. Everything in the end speaks the underlying management >> API. But that doesn't mean the syntax needs to be the raw dmr or json >> equivalent. >> >> This is primarily about UX and parsing. If we supported CLI syntax >> there's no requirement to also parse basic DMR. The CLI itself doesn't. >> >> If we support CLI syntax though it seems logical to use the CLI libs >> themselves to do it. Otherwise we are maintaining two code bases for the >> same thing. (I doubt the CLI parsing code can easily be extracted out >> for reuse, although I may be wrong.) >> >> On 9/4/14, 2:05 AM, Heiko Braun wrote: >>> 2) builds on 3), right? >>> >>> On 04 Sep 2014, at 06:16, Stuart Douglas>> > wrote: >>> >>>> 2) Allow the user to provide CLI commands to customise the server >>>> >>>> This is by far my favorite approach. The provisioning file would just >>>> contain a list of CLI commands, and would execute them in order. I >>>> think >>>> this is by far the most intuitive, and the CLI is well documented. >>>> >>>> 3) Allow the user to provide DMR operations to customize the server >>>> >>>> Similar to 2, but allow the user to provide DMR or JSON operations to >>>> customize the server. I think this is not nearly as nice as 2, as users >>>> are much more likely to be familiar with the CLI rather than DMR. >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> >> -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Thu Sep 4 17:29:45 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 04 Sep 2014 16:29:45 -0500 Subject: [wildfly-dev] Customizing a provisioned server In-Reply-To: <5407E7AF.6060701@redhat.com> References: <5407E7AF.6060701@redhat.com> Message-ID: <5408D9C9.1070502@redhat.com> Are we going to do anything related to the "Provisioning" stuff on [1] here? That's an intermediate level of granularity than saying "I want xyz feature pack" (and perhaps tweaking the module set a bit) and doing a bunch of detailed config like "/subsystem=elytron/elytron-thingy=foo:write-attribute(name=bar,value=true). It's more for stuff like saying "I want jts, I want remote ejb, I want JSR-160" all of which are optional capabilities provided by various extensions. [1] https://developer.jboss.org/docs/DOC-52712 On 9/3/14, 11:16 PM, Stuart Douglas wrote: > Hi everyone, > > Work on the provisioning tool is now well underway, so I would like to > revisit something I mentioned in my original email, which is allowing > the provisioning tool to customize a provisioned server. > > I think there are a few options here, some more palatable than others. > In no particular order: > > 1) Customize the XML directly > > Using this approach we would just directly customize the XML > configuration files. This would basically require the use of XSLT > (yuck), or require us to basically invent our own version of XSLT (even > more yuck). Even though this approach will work, and will be fairly easy > to implement, I think it would really suck from an end-user point of > view, and I think we should discount it. > > 2) Allow the user to provide CLI commands to customise the server > > This is by far my favorite approach. The provisioning file would just > contain a list of CLI commands, and would execute them in order. I think > this is by far the most intuitive, and the CLI is well documented. > > 3) Allow the user to provide DMR operations to customize the server > > Similar to 2, but allow the user to provide DMR or JSON operations to > customize the server. I think this is not nearly as nice as 2, as users > are much more likely to be familiar with the CLI rather than DMR. > > > I think 2 is by far the best approach, however it does open up the > question of how and when to execute the operations. I think the easiest > way to do this would be to just start the server in admin only mode on a > custom port (so it will not interfere with any existing running Wildfly > instances), and just execute the CLI commands in admin only mode. > > Does this all sound reasonable? > > Stuart > > _______________________________________________ > 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 theute at redhat.com Fri Sep 5 01:52:44 2014 From: theute at redhat.com (Thomas Heute) Date: Fri, 05 Sep 2014 07:52:44 +0200 Subject: [wildfly-dev] Customizing a provisioned server In-Reply-To: <5408D687.4010304@gmail.com> References: <5407E7AF.6060701@redhat.com> <54083BBB.1000806@redhat.com> <5408D687.4010304@gmail.com> Message-ID: <54094FAC.7050202@redhat.com> On 09/04/2014 11:15 PM, Stuart Douglas wrote: > > > Thomas Heute wrote: >> I would need to provision Wildfly remotely with something like JON or >> Fabric8 for instance, the CLI would not work for that if I understand >> correctly. >> > > This is more about how to customize a server after it has been > provisioned. So for example you can have a file that basically says 'I > want a WF instance with these features, these deployments, and then > perform these mgmt ops to configure it' Sounds like what I want to do remotely :) Let's take an example, I would like to be able to "deploy and configure" keycloak on a group of servers (i can handle the "group" part). Deploying and installing keycloak today requires to: - Add a few modules - add 1 extension and 1 subsytem in standalone/domain.xml - add 1 security domain in standalone/domain.xml If Keycloak could be delivered as "feature pack" to do the 3 steps above I would still want the possibility to do this remotely on a set of servers. You could argue that you need to prepare a package beforehand "locally" and they deploy the fully customized WF but I don't think it would always be the preferred solution Does that make sense ? Thomas > > Stuart > >> REST-ish API would work better I think (I guess option 3 covers that), >> Fabric8 preference would likely be option 1 though (note that in this >> usecase the end-user doesn't really touch the XML files, he's using a >> tool) >> >> BTW: I completely missed the discussion about provisioning tool until >> this email so please forgive my ignorance. If there is a document or >> email thread that would help me catch up I would love to have a look. >> >> Thomas >> >> >> On 09/04/2014 06:16 AM, Stuart Douglas wrote: >>> Hi everyone, >>> >>> Work on the provisioning tool is now well underway, so I would like to >>> revisit something I mentioned in my original email, which is allowing >>> the provisioning tool to customize a provisioned server. >>> >>> I think there are a few options here, some more palatable than others. >>> In no particular order: >>> >>> 1) Customize the XML directly >>> >>> Using this approach we would just directly customize the XML >>> configuration files. This would basically require the use of XSLT >>> (yuck), or require us to basically invent our own version of XSLT (even >>> more yuck). Even though this approach will work, and will be fairly >>> easy >>> to implement, I think it would really suck from an end-user point of >>> view, and I think we should discount it. >>> >>> 2) Allow the user to provide CLI commands to customise the server >>> >>> This is by far my favorite approach. The provisioning file would just >>> contain a list of CLI commands, and would execute them in order. I >>> think >>> this is by far the most intuitive, and the CLI is well documented. >>> >>> 3) Allow the user to provide DMR operations to customize the server >>> >>> Similar to 2, but allow the user to provide DMR or JSON operations to >>> customize the server. I think this is not nearly as nice as 2, as users >>> are much more likely to be familiar with the CLI rather than DMR. >>> >>> >>> I think 2 is by far the best approach, however it does open up the >>> question of how and when to execute the operations. I think the easiest >>> way to do this would be to just start the server in admin only mode >>> on a >>> custom port (so it will not interfere with any existing running Wildfly >>> instances), and just execute the CLI commands in admin only mode. >>> >>> Does this all sound reasonable? >>> >>> Stuart >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev From rory.odonnell at oracle.com Fri Sep 5 04:16:11 2014 From: rory.odonnell at oracle.com (Rory O'Donnell Oracle, Dublin Ireland) Date: Fri, 05 Sep 2014 09:16:11 +0100 Subject: [wildfly-dev] Early Access builds for JDK 9 b28 and JDK 8u40 b04 are available on java.net Message-ID: <5409714B.1040409@oracle.com> Hi Guys, Early Access build for JDK 9 b28 is available on java.net, summary of changes are listed here Early Access build for JDK 8u40 b04 is available on java.net, summary of changes are listed here. 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/20140905/4ff16ea9/attachment.html From tomaz.cerar at gmail.com Fri Sep 5 04:59:13 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Fri, 5 Sep 2014 10:59:13 +0200 Subject: [wildfly-dev] Customizing a provisioned server In-Reply-To: <5408D6D8.4050305@gmail.com> References: <5407E7AF.6060701@redhat.com> <5408D6D8.4050305@gmail.com> Message-ID: On Thu, Sep 4, 2014 at 11:17 PM, Stuart Douglas wrote: > The problem with 3 is that for the most part users do not use DMR > directly, they use the CLI, and all our documentation reflects this. If we > use DMR directly for this it just one more thing that we require our users > to learn. 90%+ of what users do in CLI is direct DMR. Things that CLI adds that are not part of native DMR are handlers like: - ls (instead of :read-resource), - reload (instead of :reload) - try,catch - batch* - if, else - clear, quit + some others but in general most of the commands people write are direct DMR. CLI only adds lots of usability features on top of them like tab completion. for example /subsystem=io/worker=new-worker:add() is 100% dmr operation. In any case if we go with WildFly embedded in CLI mode all this discussion is non issue. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140905/1579e893/attachment.html From kabir.khan at jboss.com Fri Sep 5 05:22:20 2014 From: kabir.khan at jboss.com (Kabir Khan) Date: Fri, 5 Sep 2014 10:22:20 +0100 Subject: [wildfly-dev] Customizing a provisioned server In-Reply-To: References: <5407E7AF.6060701@redhat.com> <5408D6D8.4050305@gmail.com> Message-ID: <721DBB09-04FF-45DF-BAEA-4024C59805F1@jboss.com> On 5 Sep 2014, at 09:59, Toma? Cerar wrote: > > On Thu, Sep 4, 2014 at 11:17 PM, Stuart Douglas wrote: > The problem with 3 is that for the most part users do not use DMR directly, they use the CLI, and all our documentation reflects this. If we use DMR directly for this it just one more thing that we require our users to learn. > > > 90%+ of what users do in CLI is direct DMR. > Things that CLI adds that are not part of native DMR are handlers like: > > - ls (instead of :read-resource), > - reload (instead of :reload) > - try,catch > - batch* > - if, else > - clear, quit > + some others > > but in general most of the commands people write are direct DMR. > CLI only adds lots of usability features on top of them like tab completion. > > for example > /subsystem=io/worker=new-worker:add() > is 100% dmr operation. Yes, but isn?t the issue that it is nicer for end users, who are used to the CLI to write this rather than either using the serialized forms of the the DMR representation, e.g. either (raw DMR) { "address" => [ ("subsystem" => "io"), ("worker" => "new-worker") ], "operation" => ?add? } or (JSON) { "address" : [ { "subsystem" : "io" }, { "worker" : "new-worker" } ], "operation" : "add" } is is a lot more usable to just be able to say /subsystem=io/worker=new-worker:add() > > In any case if we go with WildFly embedded in CLI mode all this discussion is non issue. > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From ehugonne at redhat.com Fri Sep 5 05:47:57 2014 From: ehugonne at redhat.com (Emmanuel Hugonnet) Date: Fri, 05 Sep 2014 11:47:57 +0200 Subject: [wildfly-dev] Customizing a provisioned server In-Reply-To: <721DBB09-04FF-45DF-BAEA-4024C59805F1@jboss.com> References: <5407E7AF.6060701@redhat.com> <5408D6D8.4050305@gmail.com> <721DBB09-04FF-45DF-BAEA-4024C59805F1@jboss.com> Message-ID: <540986CD.6010709@redhat.com> Can't the provisionning "build tool" convert the cli scripts in dmr in building the feature pack ? Thus dmr would be the lingua franca of the provisionning itself. That might mean more rebuilding during the feature pack creation / configuration from a user point of view. Emmanuel Le 05/09/2014 11:22, Kabir Khan a ?crit : > > On 5 Sep 2014, at 09:59, Toma? Cerar wrote: > >> >> On Thu, Sep 4, 2014 at 11:17 PM, Stuart Douglas wrote: >> The problem with 3 is that for the most part users do not use DMR directly, they use the CLI, and all our documentation reflects this. If we use DMR directly for this it just one more thing that we require our users to learn. >> >> >> 90%+ of what users do in CLI is direct DMR. >> Things that CLI adds that are not part of native DMR are handlers like: >> >> - ls (instead of :read-resource), >> - reload (instead of :reload) >> - try,catch >> - batch* >> - if, else >> - clear, quit >> + some others >> >> but in general most of the commands people write are direct DMR. >> CLI only adds lots of usability features on top of them like tab completion. >> >> for example >> /subsystem=io/worker=new-worker:add() >> is 100% dmr operation. > Yes, but isn?t the issue that it is nicer for end users, who are used to the CLI to write this rather than either using the serialized forms of the the DMR representation, e.g. either (raw DMR) > { > "address" => [ > ("subsystem" => "io"), > ("worker" => "new-worker") > ], > "operation" => ?add? > } > or (JSON) > { > "address" : [ > { > "subsystem" : "io" > }, > { > "worker" : "new-worker" > } > ], > "operation" : "add" > } > is is a lot more usable to just be able to say > /subsystem=io/worker=new-worker:add() > > >> >> In any case if we go with WildFly embedded in CLI mode all this discussion is non issue. >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140905/9bfb9b29/attachment.bin From tomaz.cerar at gmail.com Fri Sep 5 06:22:26 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Fri, 5 Sep 2014 12:22:26 +0200 Subject: [wildfly-dev] Customizing a provisioned server In-Reply-To: <721DBB09-04FF-45DF-BAEA-4024C59805F1@jboss.com> References: <5407E7AF.6060701@redhat.com> <5408D6D8.4050305@gmail.com> <721DBB09-04FF-45DF-BAEA-4024C59805F1@jboss.com> Message-ID: You are right. I was mixing the two. And when doing some client last time I was indeed using CLI api for that. Looking at the code, there is only one method we would really need to use CommandContext#buildRequest(String) https://github.com/wildfly/wildfly-core/blob/master/cli/src/main/java/org/jboss/as/cli/CommandContext.java#L278 Which translates CLI command to DMR one. So in any case, CLI is a way to go. how that is different question. On Fri, Sep 5, 2014 at 11:22 AM, Kabir Khan wrote: > > On 5 Sep 2014, at 09:59, Toma? Cerar wrote: > > > > > On Thu, Sep 4, 2014 at 11:17 PM, Stuart Douglas < > stuart.w.douglas at gmail.com> wrote: > > The problem with 3 is that for the most part users do not use DMR > directly, they use the CLI, and all our documentation reflects this. If we > use DMR directly for this it just one more thing that we require our users > to learn. > > > > > > 90%+ of what users do in CLI is direct DMR. > > Things that CLI adds that are not part of native DMR are handlers like: > > > > - ls (instead of :read-resource), > > - reload (instead of :reload) > > - try,catch > > - batch* > > - if, else > > - clear, quit > > + some others > > > > but in general most of the commands people write are direct DMR. > > CLI only adds lots of usability features on top of them like tab > completion. > > > > for example > > /subsystem=io/worker=new-worker:add() > > is 100% dmr operation. > Yes, but isn?t the issue that it is nicer for end users, who are used to > the CLI to write this rather than either using the serialized forms of the > the DMR representation, e.g. either (raw DMR) > { > "address" => [ > ("subsystem" => "io"), > ("worker" => "new-worker") > ], > "operation" => ?add? > } > or (JSON) > { > "address" : [ > { > "subsystem" : "io" > }, > { > "worker" : "new-worker" > } > ], > "operation" : "add" > } > is is a lot more usable to just be able to say > /subsystem=io/worker=new-worker:add() > > > > > > In any case if we go with WildFly embedded in CLI mode all this > discussion is non issue. > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140905/b55f6e19/attachment-0001.html From jason.greene at redhat.com Fri Sep 5 13:42:25 2014 From: jason.greene at redhat.com (Jason Greene) Date: Fri, 5 Sep 2014 12:42:25 -0500 Subject: [wildfly-dev] Customizing a provisioned server In-Reply-To: <540986CD.6010709@redhat.com> References: <5407E7AF.6060701@redhat.com> <5408D6D8.4050305@gmail.com> <721DBB09-04FF-45DF-BAEA-4024C59805F1@jboss.com> <540986CD.6010709@redhat.com> Message-ID: The nice thing about expressing this in DMR as that you could have one consistent data model vs nesting a bunch of different ones (DMR inside of CLI syntax inside of XML syntax). We could also just add path support into the management API, just parse the equivalent string. { ?install-feature-list? => [?io?, ?something-else"], ?tasks? => [ { ?address? => ?/subsystem=io/worker=new-worker1?, ?operation? => ?add? }, { ?address? => ?/subsystem=io/worker=new-worker2?, ?operation? => ?add? }, { ?address? => ?/subsystem=io/worker=new-worker3?, ?operation? => ?add? } ] } Note that the CLI doesn?t hide DMR, in particular with an add operation. So the difference will be pretty small imo. On Sep 5, 2014, at 4:47 AM, Emmanuel Hugonnet wrote: > Can't the provisionning "build tool" convert the cli scripts in dmr in building the feature pack ? > Thus dmr would be the lingua franca of the provisionning itself. > That might mean more rebuilding during the feature pack creation / configuration from a user point of view. > Emmanuel > > Le 05/09/2014 11:22, Kabir Khan a ?crit : >> >> On 5 Sep 2014, at 09:59, Toma? Cerar wrote: >> >>> >>> On Thu, Sep 4, 2014 at 11:17 PM, Stuart Douglas wrote: >>> The problem with 3 is that for the most part users do not use DMR directly, they use the CLI, and all our documentation reflects this. If we use DMR directly for this it just one more thing that we require our users to learn. >>> >>> >>> 90%+ of what users do in CLI is direct DMR. >>> Things that CLI adds that are not part of native DMR are handlers like: >>> >>> - ls (instead of :read-resource), >>> - reload (instead of :reload) >>> - try,catch >>> - batch* >>> - if, else >>> - clear, quit >>> + some others >>> >>> but in general most of the commands people write are direct DMR. >>> CLI only adds lots of usability features on top of them like tab completion. >>> >>> for example >>> /subsystem=io/worker=new-worker:add() >>> is 100% dmr operation. >> Yes, but isn?t the issue that it is nicer for end users, who are used to the CLI to write this rather than either using the serialized forms of the the DMR representation, e.g. either (raw DMR) >> { >> "address" => [ >> ("subsystem" => "io"), >> ("worker" => "new-worker") >> ], >> "operation" => ?add? >> } >> or (JSON) >> { >> "address" : [ >> { >> "subsystem" : "io" >> }, >> { >> "worker" : "new-worker" >> } >> ], >> "operation" : "add" >> } >> is is a lot more usable to just be able to say >> /subsystem=io/worker=new-worker:add() >> >> >>> >>> In any case if we go with WildFly embedded in CLI mode all this discussion is non issue. >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From brian.stansberry at redhat.com Fri Sep 5 14:28:35 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 05 Sep 2014 13:28:35 -0500 Subject: [wildfly-dev] Customizing a provisioned server In-Reply-To: References: <5407E7AF.6060701@redhat.com> <5408D6D8.4050305@gmail.com> <721DBB09-04FF-45DF-BAEA-4024C59805F1@jboss.com> <540986CD.6010709@redhat.com> Message-ID: <540A00D3.2050608@redhat.com> On 9/5/14, 12:42 PM, Jason Greene wrote: > The nice thing about expressing this in DMR as that you could have one consistent data model vs nesting a bunch of different ones (DMR inside of CLI syntax inside of XML syntax). We could also just add path support into the management API, just parse the equivalent string. > > { > ?install-feature-list? => [?io?, ?something-else"], > > ?tasks? => [ > { > ?address? => ?/subsystem=io/worker=new-worker1?, Regardless of this provisioning tool discussion, this is a good idea. We have a bug to fix where passing "address" => "" (instead of "address" => []) results in useless failure instead of a proper failure, and the fix for that would likely involve some highly central point where we validate the address param. That point could easily deal with this too. > ?operation? => ?add? > }, > { > ?address? => ?/subsystem=io/worker=new-worker2?, > ?operation? => ?add? > }, > { > ?address? => ?/subsystem=io/worker=new-worker3?, > ?operation? => ?add? > } > ] > } > > > Note that the CLI doesn?t hide DMR, in particular with an add operation. So the difference will be pretty small imo. > > > > On Sep 5, 2014, at 4:47 AM, Emmanuel Hugonnet wrote: > >> Can't the provisionning "build tool" convert the cli scripts in dmr in building the feature pack ? >> Thus dmr would be the lingua franca of the provisionning itself. >> That might mean more rebuilding during the feature pack creation / configuration from a user point of view. >> Emmanuel >> >> Le 05/09/2014 11:22, Kabir Khan a ?crit : >>> >>> On 5 Sep 2014, at 09:59, Toma? Cerar wrote: >>> >>>> >>>> On Thu, Sep 4, 2014 at 11:17 PM, Stuart Douglas wrote: >>>> The problem with 3 is that for the most part users do not use DMR directly, they use the CLI, and all our documentation reflects this. If we use DMR directly for this it just one more thing that we require our users to learn. >>>> >>>> >>>> 90%+ of what users do in CLI is direct DMR. >>>> Things that CLI adds that are not part of native DMR are handlers like: >>>> >>>> - ls (instead of :read-resource), >>>> - reload (instead of :reload) >>>> - try,catch >>>> - batch* >>>> - if, else >>>> - clear, quit >>>> + some others >>>> >>>> but in general most of the commands people write are direct DMR. >>>> CLI only adds lots of usability features on top of them like tab completion. >>>> >>>> for example >>>> /subsystem=io/worker=new-worker:add() >>>> is 100% dmr operation. >>> Yes, but isn?t the issue that it is nicer for end users, who are used to the CLI to write this rather than either using the serialized forms of the the DMR representation, e.g. either (raw DMR) >>> { >>> "address" => [ >>> ("subsystem" => "io"), >>> ("worker" => "new-worker") >>> ], >>> "operation" => ?add? >>> } >>> or (JSON) >>> { >>> "address" : [ >>> { >>> "subsystem" : "io" >>> }, >>> { >>> "worker" : "new-worker" >>> } >>> ], >>> "operation" : "add" >>> } >>> is is a lot more usable to just be able to say >>> /subsystem=io/worker=new-worker:add() >>> >>> >>>> >>>> In any case if we go with WildFly embedded in CLI mode all this discussion is non issue. >>>> >>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From hbraun at redhat.com Tue Sep 9 04:03:18 2014 From: hbraun at redhat.com (Heiko Braun) Date: Tue, 9 Sep 2014 10:03:18 +0200 Subject: [wildfly-dev] Undertow statistics Message-ID: I am looking for some undertow metrics, like HTTP request/error rates, etc. I was expecting them to be exposed alongside with the listeners, but cannot find any. Is this missing or am I looking at the wrong resources? /Heiko From stuart.w.douglas at gmail.com Tue Sep 9 05:51:43 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Tue, 09 Sep 2014 19:51:43 +1000 Subject: [wildfly-dev] Undertow statistics In-Reply-To: References: Message-ID: <540ECDAF.8080406@gmail.com> We don't have those metrics at the moment, although they are easy to add. Are there any more that are missing that I should add? Stuart Heiko Braun wrote: > I am looking for some undertow metrics, like HTTP request/error rates, etc. I was expecting them to be exposed alongside with the listeners, but cannot find any. Is this missing or am I looking at the wrong resources? > > /Heiko > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From benevides at redhat.com Tue Sep 9 10:01:33 2014 From: benevides at redhat.com (Rafael Benevides) Date: Tue, 09 Sep 2014 11:01:33 -0300 Subject: [wildfly-dev] New wildfly-javaee7-webapp Archetypes In-Reply-To: <53FCB846.2070705@redhat.com> References: <-8355667449386973450@unknownmsgid> <53FCB846.2070705@redhat.com> Message-ID: <540F083D.5080009@redhat.com> Hi all, Considering that there's no objection, I'll release 8.1.0.Final Archetypes until the end of the week and promote it to Maven Central. Please, let me know if you have any issues. Thanks Em 8/26/14, 13:39, Rafael Benevides escreveu: > Hi all, > > I added the *wildfly-javaee7-webapp-*-archetype* to > https://github.com/wildfly/wildfly-archetypes and also performed a > release of them as 8.1.0.CR1 to > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3775/ > > This will give us a chance to test it before I can promote this staged > repository. > > Note that these Archetypes are kept synchronized with its original > quickstarts from https://github.com/wildfly/quickstart through QSTools > ( http://jboss-developer.github.io/maven-qstools-plugin/ ) > > Once that everybody is ok, I can do a *.Final* release and ask it to > be synched with Maven Central > > Every feedback is welcome! > > Thanks > > Em 8/26/14, 11:20, Pete Muir escreveu: >> Thanks Tomaz. >> >> I did the rename (https://github.com/wildfly/wildfly-archetypes). I added the archetypes-push team, and put Rafael in it, so he can manage these archetypes. >> >> Pete >> >> On 26 Aug 2014, at 14:05, Toma? Cerar wrote: >> >>> Go for it. >>> >>> Sent from my PhoneFrom: Pete Muir >>> Sent: ?26/?08/?2014 12:05 >>> To: WildFly Dev >>> Cc: Rafael Benevides >>> Subject: [wildfly-dev] Rename wildfly/archetypes -> >>> wildfly/wildfly-archetypes and add archetypes for creating applications >>> As per subject, we would like to rename the repo to follow the normal >>> naming process. We would also like to add and release a couple of >>> archetypes for creating web-app projects for WildFly. >>> >>> Any objections? >>> _______________________________________________ >>> 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/20140909/079fdc5e/attachment.html From tomaz.cerar at gmail.com Tue Sep 9 10:13:09 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Tue, 9 Sep 2014 16:13:09 +0200 Subject: [wildfly-dev] New wildfly-javaee7-webapp Archetypes In-Reply-To: <540F083D.5080009@redhat.com> References: <-8355667449386973450@unknownmsgid> <53FCB846.2070705@redhat.com> <540F083D.5080009@redhat.com> Message-ID: Please use more recent jboss-parent if noting else. As version 8 your are using doesn't allow / compile to java7 which is kinda annoying if you are trying to show off ee7 features... Current latest is 16. also update url's in pom to point to wildfly.org. beyond that I am fine with doing release. -- tomaz On Tue, Sep 9, 2014 at 4:01 PM, Rafael Benevides wrote: > Hi all, > > Considering that there's no objection, I'll release 8.1.0.Final Archetypes > until the end of the week and promote it to Maven Central. > > Please, let me know if you have any issues. > > Thanks > > Em 8/26/14, 13:39, Rafael Benevides escreveu: > > Hi all, > > I added the *wildfly-javaee7-webapp-*-archetype* to > https://github.com/wildfly/wildfly-archetypes and also performed a > release of them as 8.1.0.CR1 to > > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3775/ > > This will give us a chance to test it before I can promote this staged > repository. > > Note that these Archetypes are kept synchronized with its original > quickstarts from https://github.com/wildfly/quickstart through QSTools ( > http://jboss-developer.github.io/maven-qstools-plugin/ ) > > Once that everybody is ok, I can do a *.Final* release and ask it to be > synched with Maven Central > > Every feedback is welcome! > > Thanks > > Em 8/26/14, 11:20, Pete Muir escreveu: > > Thanks Tomaz. > > I did the rename (https://github.com/wildfly/wildfly-archetypes). I added the archetypes-push team, and put Rafael in it, so he can manage these archetypes. > > Pete > > On 26 Aug 2014, at 14:05, Toma? Cerar wrote: > > > Go for it. > > Sent from my PhoneFrom: Pete Muir > Sent: ?26/?08/?2014 12:05 > To: WildFly Dev > Cc: Rafael Benevides > Subject: [wildfly-dev] Rename wildfly/archetypes -> > wildfly/wildfly-archetypes and add archetypes for creating applications > As per subject, we would like to rename the repo to follow the normal > naming process. We would also like to add and release a couple of > archetypes for creating web-app projects for WildFly. > > Any objections? > _______________________________________________ > wildfly-dev mailing listwildfly-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140909/4ea8afad/attachment-0001.html From benevides at redhat.com Tue Sep 9 10:29:50 2014 From: benevides at redhat.com (Rafael Benevides) Date: Tue, 09 Sep 2014 11:29:50 -0300 Subject: [wildfly-dev] New wildfly-javaee7-webapp Archetypes In-Reply-To: References: <-8355667449386973450@unknownmsgid> <53FCB846.2070705@redhat.com> <540F083D.5080009@redhat.com> Message-ID: <540F0EDE.2080207@redhat.com> Thanks Toma?! ;) I fixed it https://github.com/wildfly/wildfly-archetypes/compare/6f81d40b0e7cf0c452...f0d73d3db5328a0eb454e Em 9/9/14, 11:13, Toma? Cerar escreveu: > Please use more recent jboss-parent if noting else. > As version 8 your are using doesn't allow / compile to java7 > which is kinda annoying if you are trying to show off ee7 features... > Current latest is 16. > > also update url's in pom to point to wildfly.org . > > beyond that I am fine with doing release. > > -- > tomaz > > On Tue, Sep 9, 2014 at 4:01 PM, Rafael Benevides > wrote: > > Hi all, > > Considering that there's no objection, I'll release 8.1.0.Final > Archetypes until the end of the week and promote it to Maven Central. > > Please, let me know if you have any issues. > > Thanks > > Em 8/26/14, 13:39, Rafael Benevides escreveu: >> Hi all, >> >> I added the *wildfly-javaee7-webapp-*-archetype* to >> https://github.com/wildfly/wildfly-archetypes and also performed >> a release of them as 8.1.0.CR1 to >> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3775/ >> >> This will give us a chance to test it before I can promote this >> staged repository. >> >> Note that these Archetypes are kept synchronized with its >> original quickstarts from https://github.com/wildfly/quickstart >> through QSTools ( >> http://jboss-developer.github.io/maven-qstools-plugin/ ) >> >> Once that everybody is ok, I can do a *.Final* release and ask it >> to be synched with Maven Central >> >> Every feedback is welcome! >> >> Thanks >> >> Em 8/26/14, 11:20, Pete Muir escreveu: >>> Thanks Tomaz. >>> >>> I did the rename (https://github.com/wildfly/wildfly-archetypes). I added the archetypes-push team, and put Rafael in it, so he can manage these archetypes. >>> >>> Pete >>> >>> On 26 Aug 2014, at 14:05, Toma? Cerar wrote: >>> >>>> Go for it. >>>> >>>> Sent from my PhoneFrom: Pete Muir >>>> Sent: ?26/?08/?2014 12:05 >>>> To: WildFly Dev >>>> Cc: Rafael Benevides >>>> Subject: [wildfly-dev] Rename wildfly/archetypes -> >>>> wildfly/wildfly-archetypes and add archetypes for creating applications >>>> As per subject, we would like to rename the repo to follow the normal >>>> naming process. We would also like to add and release a couple of >>>> archetypes for creating web-app projects for WildFly. >>>> >>>> Any objections? >>>> _______________________________________________ >>>> 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/20140909/9dd61aa0/attachment.html From hbraun at redhat.com Tue Sep 9 12:16:17 2014 From: hbraun at redhat.com (Heiko Braun) Date: Tue, 9 Sep 2014 18:16:17 +0200 Subject: [wildfly-dev] Undertow statistics In-Reply-To: <540ECDAF.8080406@gmail.com> References: <540ECDAF.8080406@gmail.com> Message-ID: It should be equivalent to the previous web subsystem I think. On 09 Sep 2014, at 11:51, Stuart Douglas wrote: > We don't have those metrics at the moment, although they are easy to add. Are there any more that are missing that I should add? > > Stuart > > Heiko Braun wrote: >> I am looking for some undertow metrics, like HTTP request/error rates, etc. I was expecting them to be exposed alongside with the listeners, but cannot find any. Is this missing or am I looking at the wrong resources? >> >> /Heiko >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev From arun.gupta at gmail.com Tue Sep 9 14:40:42 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Tue, 9 Sep 2014 21:40:42 +0300 Subject: [wildfly-dev] Undertow statistics In-Reply-To: References: <540ECDAF.8080406@gmail.com> Message-ID: +1, I think that'll be very useful. Arun On Tue, Sep 9, 2014 at 7:16 PM, Heiko Braun wrote: > It should be equivalent to the previous web subsystem I think. > > On 09 Sep 2014, at 11:51, Stuart Douglas wrote: > >> We don't have those metrics at the moment, although they are easy to add. Are there any more that are missing that I should add? >> >> Stuart >> >> Heiko Braun wrote: >>> I am looking for some undertow metrics, like HTTP request/error rates, etc. I was expecting them to be exposed alongside with the listeners, but cannot find any. Is this missing or am I looking at the wrong resources? >>> >>> /Heiko >>> _______________________________________________ >>> 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 -- http://blog.arungupta.me http://twitter.com/arungupta From pxntium at gmail.com Tue Sep 9 15:27:36 2014 From: pxntium at gmail.com (=?UTF-8?Q?Francisco_Mart=C3=ADnez?=) Date: Tue, 9 Sep 2014 21:27:36 +0200 Subject: [wildfly-dev] Undertow statistics In-Reply-To: References: <540ECDAF.8080406@gmail.com> Message-ID: +1 Yes! It's very useful! Regards Fran 2014-09-09 20:40 GMT+02:00 Arun Gupta : > +1, I think that'll be very useful. > > Arun > > On Tue, Sep 9, 2014 at 7:16 PM, Heiko Braun wrote: > > It should be equivalent to the previous web subsystem I think. > > > > On 09 Sep 2014, at 11:51, Stuart Douglas > wrote: > > > >> We don't have those metrics at the moment, although they are easy to > add. Are there any more that are missing that I should add? > >> > >> Stuart > >> > >> Heiko Braun wrote: > >>> I am looking for some undertow metrics, like HTTP request/error rates, > etc. I was expecting them to be exposed alongside with the listeners, but > cannot find any. Is this missing or am I looking at the wrong resources? > >>> > >>> /Heiko > >>> _______________________________________________ > >>> 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 > > > > -- > http://blog.arungupta.me > http://twitter.com/arungupta > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140909/c4e22f05/attachment.html From jason.greene at redhat.com Tue Sep 9 15:54:10 2014 From: jason.greene at redhat.com (Jason Greene) Date: Tue, 9 Sep 2014 14:54:10 -0500 Subject: [wildfly-dev] Undertow statistics In-Reply-To: References: <540ECDAF.8080406@gmail.com> Message-ID: <9E78DF21-37D8-40B2-84C5-F49A2209A9BB@redhat.com> We could do this efficiently if we tracked it using a counter value local to the I/O thread, and summed them when querying the stat. On Sep 9, 2014, at 2:27 PM, Francisco Mart?nez wrote: > +1 > Yes! It's very useful! > Regards > Fran > > > > 2014-09-09 20:40 GMT+02:00 Arun Gupta : > +1, I think that'll be very useful. > > Arun > > On Tue, Sep 9, 2014 at 7:16 PM, Heiko Braun wrote: > > It should be equivalent to the previous web subsystem I think. > > > > On 09 Sep 2014, at 11:51, Stuart Douglas wrote: > > > >> We don't have those metrics at the moment, although they are easy to add. Are there any more that are missing that I should add? > >> > >> Stuart > >> > >> Heiko Braun wrote: > >>> I am looking for some undertow metrics, like HTTP request/error rates, etc. I was expecting them to be exposed alongside with the listeners, but cannot find any. Is this missing or am I looking at the wrong resources? > >>> > >>> /Heiko > >>> _______________________________________________ > >>> 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 > > > > -- > http://blog.arungupta.me > http://twitter.com/arungupta > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From jason.greene at redhat.com Tue Sep 9 15:54:56 2014 From: jason.greene at redhat.com (Jason Greene) Date: Tue, 9 Sep 2014 14:54:56 -0500 Subject: [wildfly-dev] Undertow statistics In-Reply-To: <9E78DF21-37D8-40B2-84C5-F49A2209A9BB@redhat.com> References: <540ECDAF.8080406@gmail.com> <9E78DF21-37D8-40B2-84C5-F49A2209A9BB@redhat.com> Message-ID: Are there any volunteers that want their name on the Undertow codebase? It?s a pretty easy enhancement. On Sep 9, 2014, at 2:54 PM, Jason Greene wrote: > We could do this efficiently if we tracked it using a counter value local to the I/O thread, and summed them when querying the stat. > > On Sep 9, 2014, at 2:27 PM, Francisco Mart?nez wrote: > >> +1 >> Yes! It's very useful! >> Regards >> Fran >> >> >> >> 2014-09-09 20:40 GMT+02:00 Arun Gupta : >> +1, I think that'll be very useful. >> >> Arun >> >> On Tue, Sep 9, 2014 at 7:16 PM, Heiko Braun wrote: >>> It should be equivalent to the previous web subsystem I think. >>> >>> On 09 Sep 2014, at 11:51, Stuart Douglas wrote: >>> >>>> We don't have those metrics at the moment, although they are easy to add. Are there any more that are missing that I should add? >>>> >>>> Stuart >>>> >>>> Heiko Braun wrote: >>>>> I am looking for some undertow metrics, like HTTP request/error rates, etc. I was expecting them to be exposed alongside with the listeners, but cannot find any. Is this missing or am I looking at the wrong resources? >>>>> >>>>> /Heiko >>>>> _______________________________________________ >>>>> 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 >> >> >> >> -- >> http://blog.arungupta.me >> http://twitter.com/arungupta >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> _______________________________________________ >> 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 > -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From marek.zupnik at gmail.com Tue Sep 9 16:15:30 2014 From: marek.zupnik at gmail.com (=?UTF-8?Q?Marek_=C5=BBupnik?=) Date: Tue, 9 Sep 2014 22:15:30 +0200 Subject: [wildfly-dev] Undertow statistics In-Reply-To: References: <540ECDAF.8080406@gmail.com> <9E78DF21-37D8-40B2-84C5-F49A2209A9BB@redhat.com> Message-ID: Hi all, I was just thinking about taking a task for volunteers in order to familiarize myself with Undertow code. I'm sure I have enough programming experience to do it. Do you have some requirements for this task? Or any hints? Regards, Marek Zupnik 2014-09-09 21:54 GMT+02:00 Jason Greene : > Are there any volunteers that want their name on the Undertow codebase? > It?s a pretty easy enhancement. > > On Sep 9, 2014, at 2:54 PM, Jason Greene wrote: > > > We could do this efficiently if we tracked it using a counter value > local to the I/O thread, and summed them when querying the stat. > > > > On Sep 9, 2014, at 2:27 PM, Francisco Mart?nez > wrote: > > > >> +1 > >> Yes! It's very useful! > >> Regards > >> Fran > >> > >> > >> > >> 2014-09-09 20:40 GMT+02:00 Arun Gupta : > >> +1, I think that'll be very useful. > >> > >> Arun > >> > >> On Tue, Sep 9, 2014 at 7:16 PM, Heiko Braun wrote: > >>> It should be equivalent to the previous web subsystem I think. > >>> > >>> On 09 Sep 2014, at 11:51, Stuart Douglas > wrote: > >>> > >>>> We don't have those metrics at the moment, although they are easy to > add. Are there any more that are missing that I should add? > >>>> > >>>> Stuart > >>>> > >>>> Heiko Braun wrote: > >>>>> I am looking for some undertow metrics, like HTTP request/error > rates, etc. I was expecting them to be exposed alongside with the > listeners, but cannot find any. Is this missing or am I looking at the > wrong resources? > >>>>> > >>>>> /Heiko > >>>>> _______________________________________________ > >>>>> 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 > >> > >> > >> > >> -- > >> http://blog.arungupta.me > >> http://twitter.com/arungupta > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >> > >> _______________________________________________ > >> 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 > > > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140909/e5420a28/attachment.html From stuart.w.douglas at gmail.com Tue Sep 9 20:53:47 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Wed, 10 Sep 2014 10:53:47 +1000 Subject: [wildfly-dev] Undertow statistics In-Reply-To: References: <540ECDAF.8080406@gmail.com> <9E78DF21-37D8-40B2-84C5-F49A2209A9BB@redhat.com> Message-ID: <540FA11B.7080402@gmail.com> I have created this JIRA to track it: https://issues.jboss.org/browse/WFLY-3835 Most of these will also require some Undertow level changes as well. A good place to start would probably be the session manager statistics. I would create another interface (SessionManagerStatistics maybe) that exposes these statistics, and then modify the InMemorySessionManger to expose them. Stuart Marek ?upnik wrote: > Hi all, > > I was just thinking about taking a task for volunteers in order to > familiarize myself with Undertow code. I'm sure I have enough > programming experience to do it. > > Do you have some requirements for this task? Or any hints? > > Regards, > Marek Zupnik > > 2014-09-09 21:54 GMT+02:00 Jason Greene >: > > Are there any volunteers that want their name on the Undertow > codebase? It?s a pretty easy enhancement. > > On Sep 9, 2014, at 2:54 PM, Jason Greene > wrote: > > > We could do this efficiently if we tracked it using a counter > value local to the I/O thread, and summed them when querying the stat. > > > > On Sep 9, 2014, at 2:27 PM, Francisco Mart?nez > wrote: > > > >> +1 > >> Yes! It's very useful! > >> Regards > >> Fran > >> > >> > >> > >> 2014-09-09 20:40 GMT+02:00 Arun Gupta >: > >> +1, I think that'll be very useful. > >> > >> Arun > >> > >> On Tue, Sep 9, 2014 at 7:16 PM, Heiko Braun > wrote: > >>> It should be equivalent to the previous web subsystem I think. > >>> > >>> On 09 Sep 2014, at 11:51, Stuart Douglas > > wrote: > >>> > >>>> We don't have those metrics at the moment, although they are > easy to add. Are there any more that are missing that I should add? > >>>> > >>>> Stuart > >>>> > >>>> Heiko Braun wrote: > >>>>> I am looking for some undertow metrics, like HTTP > request/error rates, etc. I was expecting them to be exposed > alongside with the listeners, but cannot find any. Is this missing > or am I looking at the wrong resources? > >>>>> > >>>>> /Heiko > >>>>> _______________________________________________ > >>>>> 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 > >> > >> > >> > >> -- > >> http://blog.arungupta.me > >> http://twitter.com/arungupta > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >> > >> _______________________________________________ > >> 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 > > > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From marek.zupnik at gmail.com Wed Sep 10 01:46:35 2014 From: marek.zupnik at gmail.com (=?UTF-8?Q?Marek_=C5=BBupnik?=) Date: Wed, 10 Sep 2014 07:46:35 +0200 Subject: [wildfly-dev] Undertow statistics In-Reply-To: <540FA11B.7080402@gmail.com> References: <540ECDAF.8080406@gmail.com> <9E78DF21-37D8-40B2-84C5-F49A2209A9BB@redhat.com> <540FA11B.7080402@gmail.com> Message-ID: Thank you, I got it. I'm starting the work. I'll ask if I have any questions. Should I be assigned to this issue (I have a JIRA account)? What is the due date for it? Regards, Marek Zupnik 2014-09-10 2:53 GMT+02:00 Stuart Douglas : > I have created this JIRA to track it: > > https://issues.jboss.org/browse/WFLY-3835 > > Most of these will also require some Undertow level changes as well. > > A good place to start would probably be the session manager statistics. I > would create another interface (SessionManagerStatistics maybe) that > exposes these statistics, and then modify the InMemorySessionManger to > expose them. > > Stuart > > > Marek ?upnik wrote: > >> Hi all, >> >> I was just thinking about taking a task for volunteers in order to >> familiarize myself with Undertow code. I'm sure I have enough >> programming experience to do it. >> >> Do you have some requirements for this task? Or any hints? >> >> Regards, >> Marek Zupnik >> >> 2014-09-09 21:54 GMT+02:00 Jason Greene > >: >> >> Are there any volunteers that want their name on the Undertow >> codebase? It?s a pretty easy enhancement. >> >> On Sep 9, 2014, at 2:54 PM, Jason Greene > > wrote: >> >> > We could do this efficiently if we tracked it using a counter >> value local to the I/O thread, and summed them when querying the stat. >> > >> > On Sep 9, 2014, at 2:27 PM, Francisco Mart?nez > > wrote: >> > >> >> +1 >> >> Yes! It's very useful! >> >> Regards >> >> Fran >> >> >> >> >> >> >> >> 2014-09-09 20:40 GMT+02:00 Arun Gupta > >: >> >> +1, I think that'll be very useful. >> >> >> >> Arun >> >> >> >> On Tue, Sep 9, 2014 at 7:16 PM, Heiko Braun > > wrote: >> >>> It should be equivalent to the previous web subsystem I think. >> >>> >> >>> On 09 Sep 2014, at 11:51, Stuart Douglas >> > >> wrote: >> >>> >> >>>> We don't have those metrics at the moment, although they are >> easy to add. Are there any more that are missing that I should add? >> >>>> >> >>>> Stuart >> >>>> >> >>>> Heiko Braun wrote: >> >>>>> I am looking for some undertow metrics, like HTTP >> request/error rates, etc. I was expecting them to be exposed >> alongside with the listeners, but cannot find any. Is this missing >> or am I looking at the wrong resources? >> >>>>> >> >>>>> /Heiko >> >>>>> _______________________________________________ >> >>>>> wildfly-dev mailing list >> >>>>> wildfly-dev at lists.jboss.org > 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 >> >> >> >> >> >> >> >> -- >> >> http://blog.arungupta.me >> >> http://twitter.com/arungupta >> >> _______________________________________________ >> >> wildfly-dev mailing list >> >> wildfly-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> >> _______________________________________________ >> >> 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 >> > >> >> -- >> Jason T. Greene >> WildFly Lead / JBoss EAP Platform Architect >> JBoss, a division of Red Hat >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140910/897243e2/attachment-0001.html From benevides at redhat.com Wed Sep 10 10:52:15 2014 From: benevides at redhat.com (Rafael Benevides) Date: Wed, 10 Sep 2014 11:52:15 -0300 Subject: [wildfly-dev] New wildfly-javaee7-webapp Archetypes In-Reply-To: <540F0EDE.2080207@redhat.com> References: <-8355667449386973450@unknownmsgid> <53FCB846.2070705@redhat.com> <540F083D.5080009@redhat.com> <540F0EDE.2080207@redhat.com> Message-ID: <5410659F.3080707@redhat.com> After promoting the staged Archetype I realized that Quickstarts archetypes ( org.wildfly.archetype ) uses a different groupId than Subsystem archetypes ( org.wildfly.archetypes - plural ) as you can see here: https://repository.jboss.org/nexus/content/groups/public/org/wildfly/ Since they are used for different purposes, I don't think that it's an issue, but I'd like to hear if we should make them the same for Wildfly 9. Thanks. Em 9/9/14, 11:29, Rafael Benevides escreveu: > Thanks Toma?! ;) > > I fixed it > https://github.com/wildfly/wildfly-archetypes/compare/6f81d40b0e7cf0c452...f0d73d3db5328a0eb454e > > > Em 9/9/14, 11:13, Toma? Cerar escreveu: >> Please use more recent jboss-parent if noting else. >> As version 8 your are using doesn't allow / compile to java7 >> which is kinda annoying if you are trying to show off ee7 features... >> Current latest is 16. >> >> also update url's in pom to point to wildfly.org . >> >> beyond that I am fine with doing release. >> >> -- >> tomaz >> >> On Tue, Sep 9, 2014 at 4:01 PM, Rafael Benevides >> > wrote: >> >> Hi all, >> >> Considering that there's no objection, I'll release 8.1.0.Final >> Archetypes until the end of the week and promote it to Maven Central. >> >> Please, let me know if you have any issues. >> >> Thanks >> >> Em 8/26/14, 13:39, Rafael Benevides escreveu: >>> Hi all, >>> >>> I added the *wildfly-javaee7-webapp-*-archetype* to >>> https://github.com/wildfly/wildfly-archetypes and also performed >>> a release of them as 8.1.0.CR1 to >>> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3775/ >>> >>> This will give us a chance to test it before I can promote this >>> staged repository. >>> >>> Note that these Archetypes are kept synchronized with its >>> original quickstarts from https://github.com/wildfly/quickstart >>> through QSTools ( >>> http://jboss-developer.github.io/maven-qstools-plugin/ ) >>> >>> Once that everybody is ok, I can do a *.Final* release and ask >>> it to be synched with Maven Central >>> >>> Every feedback is welcome! >>> >>> Thanks >>> >>> Em 8/26/14, 11:20, Pete Muir escreveu: >>>> Thanks Tomaz. >>>> >>>> I did the rename (https://github.com/wildfly/wildfly-archetypes). I added the archetypes-push team, and put Rafael in it, so he can manage these archetypes. >>>> >>>> Pete >>>> >>>> On 26 Aug 2014, at 14:05, Toma? Cerar wrote: >>>> >>>>> Go for it. >>>>> >>>>> Sent from my PhoneFrom: Pete Muir >>>>> Sent: ?26/?08/?2014 12:05 >>>>> To: WildFly Dev >>>>> Cc: Rafael Benevides >>>>> Subject: [wildfly-dev] Rename wildfly/archetypes -> >>>>> wildfly/wildfly-archetypes and add archetypes for creating applications >>>>> As per subject, we would like to rename the repo to follow the normal >>>>> naming process. We would also like to add and release a couple of >>>>> archetypes for creating web-app projects for WildFly. >>>>> >>>>> Any objections? >>>>> _______________________________________________ >>>>> 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/20140910/8ed2b708/attachment.html From sgilda at redhat.com Wed Sep 10 10:58:41 2014 From: sgilda at redhat.com (Sande Gilda) Date: Wed, 10 Sep 2014 10:58:41 -0400 Subject: [wildfly-dev] New wildfly-javaee7-webapp Archetypes In-Reply-To: <5410659F.3080707@redhat.com> References: <-8355667449386973450@unknownmsgid> <53FCB846.2070705@redhat.com> <540F083D.5080009@redhat.com> <540F0EDE.2080207@redhat.com> <5410659F.3080707@redhat.com> Message-ID: <54106721.1070208@redhat.com> I'm a big believer in consistency to avoid confusion. :-) On 09/10/2014 10:52 AM, Rafael Benevides wrote: > After promoting the staged Archetype I realized that Quickstarts > archetypes ( org.wildfly.archetype ) uses a different groupId than > Subsystem archetypes ( org.wildfly.archetypes - plural ) as you can > see here: > https://repository.jboss.org/nexus/content/groups/public/org/wildfly/ > > Since they are used for different purposes, I don't think that it's an > issue, but I'd like to hear if we should make them the same for Wildfly 9. > > Thanks. > > Em 9/9/14, 11:29, Rafael Benevides escreveu: >> Thanks Toma?! ;) >> >> I fixed it >> https://github.com/wildfly/wildfly-archetypes/compare/6f81d40b0e7cf0c452...f0d73d3db5328a0eb454e >> >> >> Em 9/9/14, 11:13, Toma? Cerar escreveu: >>> Please use more recent jboss-parent if noting else. >>> As version 8 your are using doesn't allow / compile to java7 >>> which is kinda annoying if you are trying to show off ee7 features... >>> Current latest is 16. >>> >>> also update url's in pom to point to wildfly.org . >>> >>> beyond that I am fine with doing release. >>> >>> -- >>> tomaz >>> >>> On Tue, Sep 9, 2014 at 4:01 PM, Rafael Benevides >>> > wrote: >>> >>> Hi all, >>> >>> Considering that there's no objection, I'll release 8.1.0.Final >>> Archetypes until the end of the week and promote it to Maven >>> Central. >>> >>> Please, let me know if you have any issues. >>> >>> Thanks >>> >>> Em 8/26/14, 13:39, Rafael Benevides escreveu: >>>> Hi all, >>>> >>>> I added the *wildfly-javaee7-webapp-*-archetype* to >>>> https://github.com/wildfly/wildfly-archetypes and also >>>> performed a release of them as 8.1.0.CR1 to >>>> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3775/ >>>> >>>> This will give us a chance to test it before I can promote this >>>> staged repository. >>>> >>>> Note that these Archetypes are kept synchronized with its >>>> original quickstarts from https://github.com/wildfly/quickstart >>>> through QSTools ( >>>> http://jboss-developer.github.io/maven-qstools-plugin/ ) >>>> >>>> Once that everybody is ok, I can do a *.Final* release and ask >>>> it to be synched with Maven Central >>>> >>>> Every feedback is welcome! >>>> >>>> Thanks >>>> >>>> Em 8/26/14, 11:20, Pete Muir escreveu: >>>>> Thanks Tomaz. >>>>> >>>>> I did the rename (https://github.com/wildfly/wildfly-archetypes). I added the archetypes-push team, and put Rafael in it, so he can manage these archetypes. >>>>> >>>>> Pete >>>>> >>>>> On 26 Aug 2014, at 14:05, Toma? Cerar wrote: >>>>> >>>>>> Go for it. >>>>>> >>>>>> Sent from my PhoneFrom: Pete Muir >>>>>> Sent: ?26/?08/?2014 12:05 >>>>>> To: WildFly Dev >>>>>> Cc: Rafael Benevides >>>>>> Subject: [wildfly-dev] Rename wildfly/archetypes -> >>>>>> wildfly/wildfly-archetypes and add archetypes for creating applications >>>>>> As per subject, we would like to rename the repo to follow the normal >>>>>> naming process. We would also like to add and release a couple of >>>>>> archetypes for creating web-app projects for WildFly. >>>>>> >>>>>> Any objections? >>>>>> _______________________________________________ >>>>>> 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/20140910/2ec6e517/attachment.html From benevides at redhat.com Wed Sep 10 11:01:22 2014 From: benevides at redhat.com (Rafael Benevides) Date: Wed, 10 Sep 2014 12:01:22 -0300 Subject: [wildfly-dev] New wildfly-javaee7-webapp Archetypes In-Reply-To: <54106721.1070208@redhat.com> References: <-8355667449386973450@unknownmsgid> <53FCB846.2070705@redhat.com> <540F083D.5080009@redhat.com> <540F0EDE.2080207@redhat.com> <5410659F.3080707@redhat.com> <54106721.1070208@redhat.com> Message-ID: <541067C2.90903@redhat.com> +1 :) but this could mean leave this as it is forever (two kinds of archetypes with two groupIds) or change it on next release (same groupId for both) Both could avoid confusion from different perspectives :p Em 9/10/14, 11:58, Sande Gilda escreveu: > I'm a big believer in consistency to avoid confusion. :-) > > On 09/10/2014 10:52 AM, Rafael Benevides wrote: >> After promoting the staged Archetype I realized that Quickstarts >> archetypes ( org.wildfly.archetype ) uses a different groupId than >> Subsystem archetypes ( org.wildfly.archetypes - plural ) as you can >> see here: >> https://repository.jboss.org/nexus/content/groups/public/org/wildfly/ >> >> Since they are used for different purposes, I don't think that it's >> an issue, but I'd like to hear if we should make them the same for >> Wildfly 9. >> >> Thanks. >> >> Em 9/9/14, 11:29, Rafael Benevides escreveu: >>> Thanks Toma?! ;) >>> >>> I fixed it >>> https://github.com/wildfly/wildfly-archetypes/compare/6f81d40b0e7cf0c452...f0d73d3db5328a0eb454e >>> >>> >>> Em 9/9/14, 11:13, Toma? Cerar escreveu: >>>> Please use more recent jboss-parent if noting else. >>>> As version 8 your are using doesn't allow / compile to java7 >>>> which is kinda annoying if you are trying to show off ee7 features... >>>> Current latest is 16. >>>> >>>> also update url's in pom to point to wildfly.org . >>>> >>>> beyond that I am fine with doing release. >>>> >>>> -- >>>> tomaz >>>> >>>> On Tue, Sep 9, 2014 at 4:01 PM, Rafael Benevides >>>> > wrote: >>>> >>>> Hi all, >>>> >>>> Considering that there's no objection, I'll release 8.1.0.Final >>>> Archetypes until the end of the week and promote it to Maven >>>> Central. >>>> >>>> Please, let me know if you have any issues. >>>> >>>> Thanks >>>> >>>> Em 8/26/14, 13:39, Rafael Benevides escreveu: >>>>> Hi all, >>>>> >>>>> I added the *wildfly-javaee7-webapp-*-archetype* to >>>>> https://github.com/wildfly/wildfly-archetypes and also >>>>> performed a release of them as 8.1.0.CR1 to >>>>> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3775/ >>>>> >>>>> This will give us a chance to test it before I can promote >>>>> this staged repository. >>>>> >>>>> Note that these Archetypes are kept synchronized with its >>>>> original quickstarts from >>>>> https://github.com/wildfly/quickstart through QSTools ( >>>>> http://jboss-developer.github.io/maven-qstools-plugin/ ) >>>>> >>>>> Once that everybody is ok, I can do a *.Final* release and ask >>>>> it to be synched with Maven Central >>>>> >>>>> Every feedback is welcome! >>>>> >>>>> Thanks >>>>> >>>>> Em 8/26/14, 11:20, Pete Muir escreveu: >>>>>> Thanks Tomaz. >>>>>> >>>>>> I did the rename (https://github.com/wildfly/wildfly-archetypes). I added the archetypes-push team, and put Rafael in it, so he can manage these archetypes. >>>>>> >>>>>> Pete >>>>>> >>>>>> On 26 Aug 2014, at 14:05, Toma? Cerar wrote: >>>>>> >>>>>>> Go for it. >>>>>>> >>>>>>> Sent from my PhoneFrom: Pete Muir >>>>>>> Sent: ?26/?08/?2014 12:05 >>>>>>> To: WildFly Dev >>>>>>> Cc: Rafael Benevides >>>>>>> Subject: [wildfly-dev] Rename wildfly/archetypes -> >>>>>>> wildfly/wildfly-archetypes and add archetypes for creating applications >>>>>>> As per subject, we would like to rename the repo to follow the normal >>>>>>> naming process. We would also like to add and release a couple of >>>>>>> archetypes for creating web-app projects for WildFly. >>>>>>> >>>>>>> Any objections? >>>>>>> _______________________________________________ >>>>>>> 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/20140910/e9ada549/attachment-0001.html From tomaz.cerar at gmail.com Wed Sep 10 11:24:15 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Wed, 10 Sep 2014 17:24:15 +0200 Subject: [wildfly-dev] Undertow statistics In-Reply-To: <540FA11B.7080402@gmail.com> References: <540ECDAF.8080406@gmail.com> <9E78DF21-37D8-40B2-84C5-F49A2209A9BB@redhat.com> <540FA11B.7080402@gmail.com> Message-ID: For what it is worth we already have: https://issues.jboss.org/browse/WFLY-918 and https://issues.jboss.org/browse/WFLY-3274 I linked them to issue you created On Wed, Sep 10, 2014 at 2:53 AM, Stuart Douglas wrote: > I have created this JIRA to track it: > > https://issues.jboss.org/browse/WFLY-3835 > > Most of these will also require some Undertow level changes as well. > > A good place to start would probably be the session manager statistics. > I would create another interface (SessionManagerStatistics maybe) that > exposes these statistics, and then modify the InMemorySessionManger to > expose them. > > Stuart > > > Marek ?upnik wrote: > > Hi all, > > > > I was just thinking about taking a task for volunteers in order to > > familiarize myself with Undertow code. I'm sure I have enough > > programming experience to do it. > > > > Do you have some requirements for this task? Or any hints? > > > > Regards, > > Marek Zupnik > > > > 2014-09-09 21:54 GMT+02:00 Jason Greene > >: > > > > Are there any volunteers that want their name on the Undertow > > codebase? It?s a pretty easy enhancement. > > > > On Sep 9, 2014, at 2:54 PM, Jason Greene > > wrote: > > > > > We could do this efficiently if we tracked it using a counter > > value local to the I/O thread, and summed them when querying the > stat. > > > > > > On Sep 9, 2014, at 2:27 PM, Francisco Mart?nez > > wrote: > > > > > >> +1 > > >> Yes! It's very useful! > > >> Regards > > >> Fran > > >> > > >> > > >> > > >> 2014-09-09 20:40 GMT+02:00 Arun Gupta > >: > > >> +1, I think that'll be very useful. > > >> > > >> Arun > > >> > > >> On Tue, Sep 9, 2014 at 7:16 PM, Heiko Braun > > wrote: > > >>> It should be equivalent to the previous web subsystem I think. > > >>> > > >>> On 09 Sep 2014, at 11:51, Stuart Douglas > > > > wrote: > > >>> > > >>>> We don't have those metrics at the moment, although they are > > easy to add. Are there any more that are missing that I should add? > > >>>> > > >>>> Stuart > > >>>> > > >>>> Heiko Braun wrote: > > >>>>> I am looking for some undertow metrics, like HTTP > > request/error rates, etc. I was expecting them to be exposed > > alongside with the listeners, but cannot find any. Is this missing > > or am I looking at the wrong resources? > > >>>>> > > >>>>> /Heiko > > >>>>> _______________________________________________ > > >>>>> wildfly-dev mailing list > > >>>>> wildfly-dev at lists.jboss.org 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 > > >> > > >> > > >> > > >> -- > > >> http://blog.arungupta.me > > >> http://twitter.com/arungupta > > >> _______________________________________________ > > >> wildfly-dev mailing list > > >> wildfly-dev at lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > >> > > >> _______________________________________________ > > >> 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 > > > > > > > -- > > Jason T. Greene > > WildFly Lead / JBoss EAP Platform Architect > > JBoss, a division of Red Hat > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140910/78ec1d7f/attachment.html From tomaz.cerar at gmail.com Wed Sep 10 11:25:27 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Wed, 10 Sep 2014 17:25:27 +0200 Subject: [wildfly-dev] Undertow statistics In-Reply-To: References: <540ECDAF.8080406@gmail.com> <9E78DF21-37D8-40B2-84C5-F49A2209A9BB@redhat.com> <540FA11B.7080402@gmail.com> Message-ID: On Wed, Sep 10, 2014 at 7:46 AM, Marek ?upnik wrote: > Thank you, I got it. I'm starting the work. I'll ask if I have any > questions. > > Should I be assigned to this issue (I have a JIRA account)? What is the > due date for it? > Sure, assign it to yourself if you can (some users cannot be assigned) Due date is more related to what release you want this in, more than anything else. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140910/2f50b2cb/attachment.html From tomaz.cerar at gmail.com Wed Sep 10 11:35:22 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Wed, 10 Sep 2014 17:35:22 +0200 Subject: [wildfly-dev] New wildfly-javaee7-webapp Archetypes In-Reply-To: <541067C2.90903@redhat.com> References: <-8355667449386973450@unknownmsgid> <53FCB846.2070705@redhat.com> <540F083D.5080009@redhat.com> <540F0EDE.2080207@redhat.com> <5410659F.3080707@redhat.com> <54106721.1070208@redhat.com> <541067C2.90903@redhat.com> Message-ID: They should be kept consistent. both should use same groupId. On Wed, Sep 10, 2014 at 5:01 PM, Rafael Benevides wrote: > +1 :) > > but this could mean leave this as it is forever (two kinds of archetypes > with two groupIds) or change it on next release (same groupId for both) > > Both could avoid confusion from different perspectives :p > > Em 9/10/14, 11:58, Sande Gilda escreveu: > > I'm a big believer in consistency to avoid confusion. :-) > > On 09/10/2014 10:52 AM, Rafael Benevides wrote: > > After promoting the staged Archetype I realized that Quickstarts > archetypes ( org.wildfly.archetype ) uses a different groupId than > Subsystem archetypes ( org.wildfly.archetypes - plural ) as you can see > here: > https://repository.jboss.org/nexus/content/groups/public/org/wildfly/ > > Since they are used for different purposes, I don't think that it's an > issue, but I'd like to hear if we should make them the same for Wildfly 9. > > Thanks. > > Em 9/9/14, 11:29, Rafael Benevides escreveu: > > Thanks Toma?! ;) > > I fixed it > > https://github.com/wildfly/wildfly-archetypes/compare/6f81d40b0e7cf0c452...f0d73d3db5328a0eb454e > > > Em 9/9/14, 11:13, Toma? Cerar escreveu: > > Please use more recent jboss-parent if noting else. > As version 8 your are using doesn't allow / compile to java7 > which is kinda annoying if you are trying to show off ee7 features... > Current latest is 16. > > also update url's in pom to point to wildfly.org. > > beyond that I am fine with doing release. > > -- > tomaz > > On Tue, Sep 9, 2014 at 4:01 PM, Rafael Benevides > wrote: > >> Hi all, >> >> Considering that there's no objection, I'll release 8.1.0.Final >> Archetypes until the end of the week and promote it to Maven Central. >> >> Please, let me know if you have any issues. >> >> Thanks >> >> Em 8/26/14, 13:39, Rafael Benevides escreveu: >> >> Hi all, >> >> I added the *wildfly-javaee7-webapp-*-archetype* to >> https://github.com/wildfly/wildfly-archetypes and also performed a >> release of them as 8.1.0.CR1 to >> >> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3775/ >> >> This will give us a chance to test it before I can promote this staged >> repository. >> >> Note that these Archetypes are kept synchronized with its original >> quickstarts from https://github.com/wildfly/quickstart through QSTools ( >> http://jboss-developer.github.io/maven-qstools-plugin/ ) >> >> Once that everybody is ok, I can do a *.Final* release and ask it to be >> synched with Maven Central >> >> Every feedback is welcome! >> >> Thanks >> >> Em 8/26/14, 11:20, Pete Muir escreveu: >> >> Thanks Tomaz. >> >> I did the rename (https://github.com/wildfly/wildfly-archetypes). I added the archetypes-push team, and put Rafael in it, so he can manage these archetypes. >> >> Pete >> >> On 26 Aug 2014, at 14:05, Toma? Cerar wrote: >> >> >> Go for it. >> >> Sent from my PhoneFrom: Pete Muir >> Sent: ?26/?08/?2014 12:05 >> To: WildFly Dev >> Cc: Rafael Benevides >> Subject: [wildfly-dev] Rename wildfly/archetypes -> >> wildfly/wildfly-archetypes and add archetypes for creating applications >> As per subject, we would like to rename the repo to follow the normal >> naming process. We would also like to add and release a couple of >> archetypes for creating web-app projects for WildFly. >> >> Any objections? >> _______________________________________________ >> wildfly-dev mailing listwildfly-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> >> > > > > > _______________________________________________ > wildfly-dev mailing listwildfly-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140910/07237f06/attachment-0001.html From benevides at redhat.com Wed Sep 10 11:36:23 2014 From: benevides at redhat.com (Rafael Benevides) Date: Wed, 10 Sep 2014 12:36:23 -0300 Subject: [wildfly-dev] New wildfly-javaee7-webapp Archetypes In-Reply-To: References: <-8355667449386973450@unknownmsgid> <53FCB846.2070705@redhat.com> <540F083D.5080009@redhat.com> <540F0EDE.2080207@redhat.com> <5410659F.3080707@redhat.com> <54106721.1070208@redhat.com> <541067C2.90903@redhat.com> Message-ID: <54106FF7.9080201@redhat.com> Do you think that I should do a new release with org.wildfly.archetypes ? Em 9/10/14, 12:35, Toma? Cerar escreveu: > They should be kept consistent. > both should use same groupId. > > On Wed, Sep 10, 2014 at 5:01 PM, Rafael Benevides > > wrote: > > +1 :) > > but this could mean leave this as it is forever (two kinds of > archetypes with two groupIds) or change it on next release (same > groupId for both) > > Both could avoid confusion from different perspectives :p > > Em 9/10/14, 11:58, Sande Gilda escreveu: >> I'm a big believer in consistency to avoid confusion. :-) >> >> On 09/10/2014 10:52 AM, Rafael Benevides wrote: >>> After promoting the staged Archetype I realized that Quickstarts >>> archetypes ( org.wildfly.archetype ) uses a different groupId >>> than Subsystem archetypes ( org.wildfly.archetypes - plural ) >>> as you can see here: >>> https://repository.jboss.org/nexus/content/groups/public/org/wildfly/ >>> >>> Since they are used for different purposes, I don't think that >>> it's an issue, but I'd like to hear if we should make them the >>> same for Wildfly 9. >>> >>> Thanks. >>> >>> Em 9/9/14, 11:29, Rafael Benevides escreveu: >>>> Thanks Toma?! ;) >>>> >>>> I fixed it >>>> https://github.com/wildfly/wildfly-archetypes/compare/6f81d40b0e7cf0c452...f0d73d3db5328a0eb454e >>>> >>>> >>>> Em 9/9/14, 11:13, Toma? Cerar escreveu: >>>>> Please use more recent jboss-parent if noting else. >>>>> As version 8 your are using doesn't allow / compile to java7 >>>>> which is kinda annoying if you are trying to show off ee7 >>>>> features... >>>>> Current latest is 16. >>>>> >>>>> also update url's in pom to point to wildfly.org >>>>> . >>>>> >>>>> beyond that I am fine with doing release. >>>>> >>>>> -- >>>>> tomaz >>>>> >>>>> On Tue, Sep 9, 2014 at 4:01 PM, Rafael Benevides >>>>> > wrote: >>>>> >>>>> Hi all, >>>>> >>>>> Considering that there's no objection, I'll release >>>>> 8.1.0.Final Archetypes until the end of the week and >>>>> promote it to Maven Central. >>>>> >>>>> Please, let me know if you have any issues. >>>>> >>>>> Thanks >>>>> >>>>> Em 8/26/14, 13:39, Rafael Benevides escreveu: >>>>>> Hi all, >>>>>> >>>>>> I added the *wildfly-javaee7-webapp-*-archetype* to >>>>>> https://github.com/wildfly/wildfly-archetypes and also >>>>>> performed a release of them as 8.1.0.CR1 to >>>>>> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3775/ >>>>>> >>>>>> This will give us a chance to test it before I can >>>>>> promote this staged repository. >>>>>> >>>>>> Note that these Archetypes are kept synchronized with its >>>>>> original quickstarts from >>>>>> https://github.com/wildfly/quickstart through QSTools ( >>>>>> http://jboss-developer.github.io/maven-qstools-plugin/ ) >>>>>> >>>>>> Once that everybody is ok, I can do a *.Final* release >>>>>> and ask it to be synched with Maven Central >>>>>> >>>>>> Every feedback is welcome! >>>>>> >>>>>> Thanks >>>>>> >>>>>> Em 8/26/14, 11:20, Pete Muir escreveu: >>>>>>> Thanks Tomaz. >>>>>>> >>>>>>> I did the rename (https://github.com/wildfly/wildfly-archetypes). I added the archetypes-push team, and put Rafael in it, so he can manage these archetypes. >>>>>>> >>>>>>> Pete >>>>>>> >>>>>>> On 26 Aug 2014, at 14:05, Toma? Cerar wrote: >>>>>>> >>>>>>>> Go for it. >>>>>>>> >>>>>>>> Sent from my PhoneFrom: Pete Muir >>>>>>>> Sent: ?26/?08/?2014 12:05 >>>>>>>> To: WildFly Dev >>>>>>>> Cc: Rafael Benevides >>>>>>>> Subject: [wildfly-dev] Rename wildfly/archetypes -> >>>>>>>> wildfly/wildfly-archetypes and add archetypes for creating applications >>>>>>>> As per subject, we would like to rename the repo to follow the normal >>>>>>>> naming process. We would also like to add and release a couple of >>>>>>>> archetypes for creating web-app projects for WildFly. >>>>>>>> >>>>>>>> Any objections? >>>>>>>> _______________________________________________ >>>>>>>> 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/20140910/e6966f19/attachment.html From marek.zupnik at gmail.com Wed Sep 10 12:37:36 2014 From: marek.zupnik at gmail.com (=?UTF-8?Q?Marek_=C5=BBupnik?=) Date: Wed, 10 Sep 2014 18:37:36 +0200 Subject: [wildfly-dev] Undertow statistics In-Reply-To: References: <540ECDAF.8080406@gmail.com> <9E78DF21-37D8-40B2-84C5-F49A2209A9BB@redhat.com> <540FA11B.7080402@gmail.com> Message-ID: Thanks, I'm starting the work. I'll try to do it as soon as possible. I'll ask in case of any question. Regards, Marek Zupnik 2014-09-10 17:25 GMT+02:00 Toma? Cerar : > > On Wed, Sep 10, 2014 at 7:46 AM, Marek ?upnik > wrote: > >> Thank you, I got it. I'm starting the work. I'll ask if I have any >> questions. >> >> Should I be assigned to this issue (I have a JIRA account)? What is the >> due date for it? >> > > > Sure, assign it to yourself if you can (some users cannot be assigned) > Due date is more related to what release you want this in, more than > anything else. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140910/6292499b/attachment.html From ssilvert at redhat.com Wed Sep 10 14:47:23 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Wed, 10 Sep 2014 14:47:23 -0400 Subject: [wildfly-dev] Creating a Keycloak Feature Pack Message-ID: <54109CBB.6070408@redhat.com> Perhaps it's a little early to start implementing a Keycloak FP, but I'm starting to look at it and identify potential issues. So I thought I should list the issues here and find out which ones are already addressed and which need some time to work out. *Task:* Implement a feature pack that adds the Keycloak Auth Server to either/both of the _WildFly Web build_ and the _WildFly Full build_. Note that this is completely separate from the effort to use Keycloak to secure the web console. That only involves Keycloak adapter integration destined to ride on top of Elytron. Here, we are talking about using a feature pack to add and configure the Keycloak Auth Server. *Issue #1: Module duplication.* Keycloak needs to install the bouncycastle module. This module already exists in the full build but not the web build. So you have the same module specified for the Keycloak FP and the Full WildFly FP. I assume this is already handled? Will the FP mechanism have a problem with duplication of modules when I try to add a module to full that already exists? *Issue #2: Adding a subsystem:* It looks like the current mechanism for creating configuration files is inappropriate for the Keycloak FP. The way this is done right now is that a config file is generated via the combination of a template file and a list of subsystem snippets. So you would have, for example: template-keycloak.xml + subsystems-keycloak.xml = standalone-keycloak.xml But that's not what we really want. We don't want a separate standalone-keycloak.xml. We really just want to add the keycloak subssytem to every generated config file, whatever they may be. *Issue #3: Adding a deployment:* The Keycloak auth server is deployed as a WAR. We can use the copy-artifacts mechanism to simply copy the WAR into the deployments directory. But that doesn't work for a domain where you want to have the WAR pre-loaded into the content repository. Furthermore, it's probably not the best way to integrate this for standalone either. What would be a better option? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140910/3204da1f/attachment-0001.html From brian.stansberry at redhat.com Wed Sep 10 17:24:02 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 10 Sep 2014 16:24:02 -0500 Subject: [wildfly-dev] Creating a Keycloak Feature Pack In-Reply-To: <54109CBB.6070408@redhat.com> References: <54109CBB.6070408@redhat.com> Message-ID: <5410C172.3000406@redhat.com> On 9/10/14, 1:47 PM, Stan Silvert wrote: > > *Issue #3: Adding a deployment:* The Keycloak auth server is deployed > as a WAR. We can use the copy-artifacts mechanism to simply copy the > WAR into the deployments directory. But that doesn't work for a domain > where you want to have the WAR pre-loaded into the content repository. > Furthermore, it's probably not the best way to integrate this for > standalone either. > > What would be a better option? > See the "A Mixed Approach" section at https://developer.jboss.org/docs/DOC-25627 The two comments at the bottom of that page are also relevant to that part of the wiki. Cheers, -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From stuart.w.douglas at gmail.com Wed Sep 10 17:30:15 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Thu, 11 Sep 2014 07:30:15 +1000 Subject: [wildfly-dev] Creating a Keycloak Feature Pack In-Reply-To: <54109CBB.6070408@redhat.com> References: <54109CBB.6070408@redhat.com> Message-ID: <5410C2E7.5060900@gmail.com> Stan Silvert wrote: > Perhaps it's a little early to start implementing a Keycloak FP, but I'm > starting to look at it and identify potential issues. So I thought I > should list the issues here and find out which ones are already > addressed and which need some time to work out. > > *Task:* Implement a feature pack that adds the Keycloak Auth Server to > either/both of the _WildFly Web build_ and the _WildFly Full build_. > > Note that this is completely separate from the effort to use Keycloak to > secure the web console. That only involves Keycloak adapter integration > destined to ride on top of Elytron. > > Here, we are talking about using a feature pack to add and configure the > Keycloak Auth Server. > > *Issue #1: Module duplication.* Keycloak needs to install the > bouncycastle module. This module already exists in the full build but > not the web build. So you have the same module specified for the > Keycloak FP and the Full WildFly FP. > > I assume this is already handled? Will the FP mechanism have a problem > with duplication of modules when I try to add a module to full that > already exists? This should work fine. Eventually we may have a solution where you can specify a dependency on just some modules in the full build, although that is not implemented yet. > > *Issue #2: Adding a subsystem:* It looks like the current mechanism for > creating configuration files is inappropriate for the Keycloak FP. The > way this is done right now is that a config file is generated via the > combination of a template file and a list of subsystem snippets. So you > would have, for example: > > template-keycloak.xml + subsystems-keycloak.xml = standalone-keycloak.xml > > But that's not what we really want. We don't want a separate > standalone-keycloak.xml. We really just want to add the keycloak > subssytem to every generated config file, whatever they may be. We should be able to add a feature to enable this. Stuart > > *Issue #3: Adding a deployment:* The Keycloak auth server is deployed as > a WAR. We can use the copy-artifacts mechanism to simply copy the WAR > into the deployments directory. But that doesn't work for a domain where > you want to have the WAR pre-loaded into the content repository. > Furthermore, it's probably not the best way to integrate this for > standalone either. > > What would be a better option? > > _______________________________________________ > 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 Thu Sep 11 02:09:47 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Thu, 11 Sep 2014 16:09:47 +1000 Subject: [wildfly-dev] Customizing a provisioned server In-Reply-To: <54094FAC.7050202@redhat.com> References: <5407E7AF.6060701@redhat.com> <54083BBB.1000806@redhat.com> <5408D687.4010304@gmail.com> <54094FAC.7050202@redhat.com> Message-ID: <54113CAB.4030605@gmail.com> I have started a document at https://developer.jboss.org/wiki/WildflyProvisioning to contain all the info regarding provisioning. At the moment it is fairly basic, it just contains all the use cases that we have considered. I will expand on it to include more detail over the next few days. Stuart Thomas Heute wrote: > > On 09/04/2014 11:15 PM, Stuart Douglas wrote: >> >> >> Thomas Heute wrote: >>> I would need to provision Wildfly remotely with something like JON or >>> Fabric8 for instance, the CLI would not work for that if I understand >>> correctly. >>> >> >> This is more about how to customize a server after it has been >> provisioned. So for example you can have a file that basically says 'I >> want a WF instance with these features, these deployments, and then >> perform these mgmt ops to configure it' > > > Sounds like what I want to do remotely :) > Let's take an example, I would like to be able to "deploy and configure" > keycloak on a group of servers (i can handle the "group" part). > Deploying and installing keycloak today requires to: > - Add a few modules > - add 1 extension and 1 subsytem in standalone/domain.xml > - add 1 security domain in standalone/domain.xml > > If Keycloak could be delivered as "feature pack" to do the 3 steps above > I would still want the possibility to do this remotely on a set of servers. > > You could argue that you need to prepare a package beforehand "locally" > and they deploy the fully customized WF but I don't think it would > always be the preferred solution > > Does that make sense ? > > Thomas > >> >> Stuart >> >>> REST-ish API would work better I think (I guess option 3 covers that), >>> Fabric8 preference would likely be option 1 though (note that in this >>> usecase the end-user doesn't really touch the XML files, he's using a >>> tool) >>> >>> BTW: I completely missed the discussion about provisioning tool until >>> this email so please forgive my ignorance. If there is a document or >>> email thread that would help me catch up I would love to have a look. >>> >>> Thomas >>> >>> >>> On 09/04/2014 06:16 AM, Stuart Douglas wrote: >>>> Hi everyone, >>>> >>>> Work on the provisioning tool is now well underway, so I would like to >>>> revisit something I mentioned in my original email, which is allowing >>>> the provisioning tool to customize a provisioned server. >>>> >>>> I think there are a few options here, some more palatable than others. >>>> In no particular order: >>>> >>>> 1) Customize the XML directly >>>> >>>> Using this approach we would just directly customize the XML >>>> configuration files. This would basically require the use of XSLT >>>> (yuck), or require us to basically invent our own version of XSLT (even >>>> more yuck). Even though this approach will work, and will be fairly >>>> easy >>>> to implement, I think it would really suck from an end-user point of >>>> view, and I think we should discount it. >>>> >>>> 2) Allow the user to provide CLI commands to customise the server >>>> >>>> This is by far my favorite approach. The provisioning file would just >>>> contain a list of CLI commands, and would execute them in order. I >>>> think >>>> this is by far the most intuitive, and the CLI is well documented. >>>> >>>> 3) Allow the user to provide DMR operations to customize the server >>>> >>>> Similar to 2, but allow the user to provide DMR or JSON operations to >>>> customize the server. I think this is not nearly as nice as 2, as users >>>> are much more likely to be familiar with the CLI rather than DMR. >>>> >>>> >>>> I think 2 is by far the best approach, however it does open up the >>>> question of how and when to execute the operations. I think the easiest >>>> way to do this would be to just start the server in admin only mode >>>> on a >>>> custom port (so it will not interfere with any existing running Wildfly >>>> instances), and just execute the CLI commands in admin only mode. >>>> >>>> Does this all sound reasonable? >>>> >>>> Stuart >>>> >>>> _______________________________________________ >>>> 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 rstryker at redhat.com Thu Sep 11 02:51:39 2014 From: rstryker at redhat.com (Rob Stryker) Date: Thu, 11 Sep 2014 14:51:39 +0800 Subject: [wildfly-dev] Fwd: Question on wildfly schema In-Reply-To: <5410B524.50001@redhat.com> References: <5410B524.50001@redhat.com> Message-ID: <5411467B.6020903@redhat.com> Hey All: All the wildfly schema are added online here: http://www.jboss.org/schema/jbossas/ A user is indicating some of the schema cause bugs in our tools: https://issues.jboss.org/browse/WFLY-3189 They have made a PR to make changes to some of the schema in our tools. However, we typically clone the online folder for our schema and distribute them with our tools, so it'd be very good to know if these changes can also be made to the online versions so that we don't end up forking the schema. So if any of you can either direct me to who would know the answer, or, review the changes to the schema yourself to see if they make sense, that'd be really helpful. Ideally I'd prefer these changes to be made to the online schema so that our jbt-distributed schema match the onlines. PR: https://github.com/jbosstools/jbosstools-server/pull/268/files - Rob Stryker From rory.odonnell at oracle.com Thu Sep 11 10:33:44 2014 From: rory.odonnell at oracle.com (Rory O'Donnell Oracle, Dublin Ireland) Date: Thu, 11 Sep 2014 15:33:44 +0100 Subject: [wildfly-dev] Analysis of wildfly-8.1.0 dependency on JDK-Internal APIs Message-ID: <5411B2C8.80800@oracle.com> Hi Tomaz, As part of the preparations for JDK 9, Oracle?s engineers have been analyzing open source projects like yours to understand usage. One area of concern involves identifying compatibility problems, such as reliance on JDK-internal APIs. Our engineers have already prepared guidance on migrating some of the more common usage patterns of JDK-internal APIs to supported public interfaces. The list is on the OpenJDK wiki [0], along with instructions on how to run the jdeps analysis tool yourself . As part of the ongoing development of JDK 9, I would like to encourage migration from JDK-internal APIs towards the supported Java APIs. I have prepared a report for your project wildfly-8.1.0 release based on the jdeps output. The report is attached to this e-mail. For anything where your migration path is unclear, I would appreciate comments on the JDK-internal API usage patterns in the attached jdeps report, (if any) - in particular comments elaborating on the rationale for them - either to me or on this list. Finding suitable replacements for unsupported interfaces is not always straightforward, which is why I am reaching out to you early in the JDK 9 development cycle so you can give feedback about new APIs that may be needed to facilitate this exercise. Thank you in advance for any efforts and feedback helping us make JDK 9 better. Rgds,Rory [0] https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool -- 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/20140911/bb370a93/attachment-0001.html From benevides at redhat.com Thu Sep 11 10:58:21 2014 From: benevides at redhat.com (Rafael Benevides) Date: Thu, 11 Sep 2014 11:58:21 -0300 Subject: [wildfly-dev] New wildfly-javaee7-webapp Archetypes In-Reply-To: <54106FF7.9080201@redhat.com> References: <-8355667449386973450@unknownmsgid> <53FCB846.2070705@redhat.com> <540F083D.5080009@redhat.com> <540F0EDE.2080207@redhat.com> <5410659F.3080707@redhat.com> <54106721.1070208@redhat.com> <541067C2.90903@redhat.com> <54106FF7.9080201@redhat.com> Message-ID: <5411B88D.7050509@redhat.com> Well, I don't think it will be possible for this release because it was synched with Maven Central: http://search.maven.org/#search%7Cga%7C1%7Corg.wildfly.archetype It will be made for Wildfly 9.0 Archetypes. Given that there's only one release of org.wildfly.archetypes:wildfly-subsystem ( http://search.maven.org/#search%7Cga%7C1%7Ca%3A%22wildfly-subsystem%22 ) . It will be renamed to org.wildfly.archetype (in singular) as it have been using in EAP and WFK Archetypes Em 9/10/14, 12:36, Rafael Benevides escreveu: > Do you think that I should do a new release with org.wildfly.archetypes ? > > Em 9/10/14, 12:35, Toma? Cerar escreveu: >> They should be kept consistent. >> both should use same groupId. >> >> On Wed, Sep 10, 2014 at 5:01 PM, Rafael Benevides >> > wrote: >> >> +1 :) >> >> but this could mean leave this as it is forever (two kinds of >> archetypes with two groupIds) or change it on next release (same >> groupId for both) >> >> Both could avoid confusion from different perspectives :p >> >> Em 9/10/14, 11:58, Sande Gilda escreveu: >>> I'm a big believer in consistency to avoid confusion. :-) >>> >>> On 09/10/2014 10:52 AM, Rafael Benevides wrote: >>>> After promoting the staged Archetype I realized that >>>> Quickstarts archetypes ( org.wildfly.archetype ) uses a >>>> different groupId than Subsystem archetypes ( >>>> org.wildfly.archetypes - plural ) as you can see here: >>>> https://repository.jboss.org/nexus/content/groups/public/org/wildfly/ >>>> >>>> Since they are used for different purposes, I don't think that >>>> it's an issue, but I'd like to hear if we should make them the >>>> same for Wildfly 9. >>>> >>>> Thanks. >>>> >>>> Em 9/9/14, 11:29, Rafael Benevides escreveu: >>>>> Thanks Toma?! ;) >>>>> >>>>> I fixed it >>>>> https://github.com/wildfly/wildfly-archetypes/compare/6f81d40b0e7cf0c452...f0d73d3db5328a0eb454e >>>>> >>>>> >>>>> Em 9/9/14, 11:13, Toma? Cerar escreveu: >>>>>> Please use more recent jboss-parent if noting else. >>>>>> As version 8 your are using doesn't allow / compile to java7 >>>>>> which is kinda annoying if you are trying to show off ee7 >>>>>> features... >>>>>> Current latest is 16. >>>>>> >>>>>> also update url's in pom to point to wildfly.org >>>>>> . >>>>>> >>>>>> beyond that I am fine with doing release. >>>>>> >>>>>> -- >>>>>> tomaz >>>>>> >>>>>> On Tue, Sep 9, 2014 at 4:01 PM, Rafael Benevides >>>>>> > wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> Considering that there's no objection, I'll release >>>>>> 8.1.0.Final Archetypes until the end of the week and >>>>>> promote it to Maven Central. >>>>>> >>>>>> Please, let me know if you have any issues. >>>>>> >>>>>> Thanks >>>>>> >>>>>> Em 8/26/14, 13:39, Rafael Benevides escreveu: >>>>>>> Hi all, >>>>>>> >>>>>>> I added the *wildfly-javaee7-webapp-*-archetype* to >>>>>>> https://github.com/wildfly/wildfly-archetypes and also >>>>>>> performed a release of them as 8.1.0.CR1 to >>>>>>> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3775/ >>>>>>> >>>>>>> This will give us a chance to test it before I can >>>>>>> promote this staged repository. >>>>>>> >>>>>>> Note that these Archetypes are kept synchronized with >>>>>>> its original quickstarts from >>>>>>> https://github.com/wildfly/quickstart through QSTools ( >>>>>>> http://jboss-developer.github.io/maven-qstools-plugin/ ) >>>>>>> >>>>>>> Once that everybody is ok, I can do a *.Final* release >>>>>>> and ask it to be synched with Maven Central >>>>>>> >>>>>>> Every feedback is welcome! >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Em 8/26/14, 11:20, Pete Muir escreveu: >>>>>>>> Thanks Tomaz. >>>>>>>> >>>>>>>> I did the rename (https://github.com/wildfly/wildfly-archetypes). I added the archetypes-push team, and put Rafael in it, so he can manage these archetypes. >>>>>>>> >>>>>>>> Pete >>>>>>>> >>>>>>>> On 26 Aug 2014, at 14:05, Toma? Cerar wrote: >>>>>>>> >>>>>>>>> Go for it. >>>>>>>>> >>>>>>>>> Sent from my PhoneFrom: Pete Muir >>>>>>>>> Sent: ?26/?08/?2014 12:05 >>>>>>>>> To: WildFly Dev >>>>>>>>> Cc: Rafael Benevides >>>>>>>>> Subject: [wildfly-dev] Rename wildfly/archetypes -> >>>>>>>>> wildfly/wildfly-archetypes and add archetypes for creating applications >>>>>>>>> As per subject, we would like to rename the repo to follow the normal >>>>>>>>> naming process. We would also like to add and release a couple of >>>>>>>>> archetypes for creating web-app projects for WildFly. >>>>>>>>> >>>>>>>>> Any objections? >>>>>>>>> _______________________________________________ >>>>>>>>> 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/20140911/842c325a/attachment.html From tomaz.cerar at gmail.com Thu Sep 11 11:00:22 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Thu, 11 Sep 2014 17:00:22 +0200 Subject: [wildfly-dev] Analysis of wildfly-8.1.0 dependency on JDK-Internal APIs In-Reply-To: <5411B2C8.80800@oracle.com> References: <5411B2C8.80800@oracle.com> Message-ID: Hi Rory, Thank you for the report!, I have forwarded it to the team to analyze it. -- tomaz On Thu, Sep 11, 2014 at 4:33 PM, Rory O'Donnell Oracle, Dublin Ireland < rory.odonnell at oracle.com> wrote: > Hi Tomaz, > > As part of the preparations for JDK 9, Oracle?s engineers have been > analyzing open source projects like yours to understand usage. > One area of concern involves identifying compatibility problems, such as > reliance on JDK-internal APIs. > > Our engineers have already prepared guidance on migrating some of the more > common usage patterns of JDK-internal APIs to supported public interfaces. > The list is on the OpenJDK wiki [0], along with instructions on how to run > the jdeps analysis tool yourself . > > As part of the ongoing development of JDK 9, I would like to encourage > migration from JDK-internal APIs towards the supported Java APIs. I have > prepared a report for your project wildfly-8.1.0 release based on the > jdeps output. > > The report is attached to this e-mail. > > For anything where your migration path is unclear, I would appreciate > comments on the JDK-internal API usage patterns in the attached jdeps > report, (if any) - in particular comments elaborating on the rationale for > them - either to me or on this list. > > Finding suitable replacements for unsupported interfaces is not always > straightforward, which is why I am reaching out to you early in the JDK 9 > development cycle so you can give feedback about new APIs that may be > needed to facilitate this exercise. > > Thank you in advance for any efforts and feedback helping us make JDK 9 > better. > > Rgds,Rory > > [0] https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+ > Analysis+Tool > > -- > 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/20140911/903c4f30/attachment.html From tomaz.cerar at gmail.com Thu Sep 11 11:02:21 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Thu, 11 Sep 2014 17:02:21 +0200 Subject: [wildfly-dev] New wildfly-javaee7-webapp Archetypes In-Reply-To: <5411B88D.7050509@redhat.com> References: <-8355667449386973450@unknownmsgid> <53FCB846.2070705@redhat.com> <540F083D.5080009@redhat.com> <540F0EDE.2080207@redhat.com> <5410659F.3080707@redhat.com> <54106721.1070208@redhat.com> <541067C2.90903@redhat.com> <54106FF7.9080201@redhat.com> <5411B88D.7050509@redhat.com> Message-ID: On Thu, Sep 11, 2014 at 4:58 PM, Rafael Benevides wrote: > Given that there's only one release of > org.wildfly.archetypes:wildfly-subsystem ( > http://search.maven.org/#search%7Cga%7C1%7Ca%3A%22wildfly-subsystem%22 ) > . It will be renamed to org.wildfly.archetype (in singular) as it have been > using in EAP and WFK Archetypes > Sure, that is fine. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140911/e6c1bd9f/attachment-0001.html From ssilvert at redhat.com Thu Sep 11 13:20:02 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Thu, 11 Sep 2014 13:20:02 -0400 Subject: [wildfly-dev] Creating a Keycloak Feature Pack In-Reply-To: <5410C172.3000406@redhat.com> References: <54109CBB.6070408@redhat.com> <5410C172.3000406@redhat.com> Message-ID: <5411D9C2.1040601@redhat.com> On 9/10/2014 5:24 PM, Brian Stansberry wrote: > On 9/10/14, 1:47 PM, Stan Silvert wrote: > >> *Issue #3: Adding a deployment:* The Keycloak auth server is deployed >> as a WAR. We can use the copy-artifacts mechanism to simply copy the >> WAR into the deployments directory. But that doesn't work for a domain >> where you want to have the WAR pre-loaded into the content repository. >> Furthermore, it's probably not the best way to integrate this for >> standalone either. >> >> What would be a better option? >> > See the "A Mixed Approach" section at > https://developer.jboss.org/docs/DOC-25627 > > The two comments at the bottom of that page are also relevant to that > part of the wiki. > > Cheers, > Awesome. That actually solves several potential problems. Thanks Brian. From ssilvert at redhat.com Thu Sep 11 13:27:05 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Thu, 11 Sep 2014 13:27:05 -0400 Subject: [wildfly-dev] Creating a Keycloak Feature Pack In-Reply-To: <5410C2E7.5060900@gmail.com> References: <54109CBB.6070408@redhat.com> <5410C2E7.5060900@gmail.com> Message-ID: <5411DB69.7000804@redhat.com> On 9/10/2014 5:30 PM, Stuart Douglas wrote: > > > Stan Silvert wrote: > >> >> *Issue #2: Adding a subsystem:* It looks like the current mechanism for >> creating configuration files is inappropriate for the Keycloak FP. The >> way this is done right now is that a config file is generated via the >> combination of a template file and a list of subsystem snippets. So you >> would have, for example: >> >> template-keycloak.xml + subsystems-keycloak.xml = >> standalone-keycloak.xml >> >> But that's not what we really want. We don't want a separate >> standalone-keycloak.xml. We really just want to add the keycloak >> subssytem to every generated config file, whatever they may be. > > We should be able to add a feature to enable this. > > Stuart Thanks Stuart. Is this covered in your "Wildfly Provisioning" plans? Should I open a Jira? From brian.stansberry at redhat.com Thu Sep 11 14:31:09 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 11 Sep 2014 13:31:09 -0500 Subject: [wildfly-dev] System deployments? WAS: Creating a Keycloak Feature Pack In-Reply-To: <5411D9C2.1040601@redhat.com> References: <54109CBB.6070408@redhat.com> <5410C172.3000406@redhat.com> <5411D9C2.1040601@redhat.com> Message-ID: <5411EA6D.4040603@redhat.com> On 9/11/14, 12:20 PM, Stan Silvert wrote: > On 9/10/2014 5:24 PM, Brian Stansberry wrote: >> On 9/10/14, 1:47 PM, Stan Silvert wrote: >> >>> *Issue #3: Adding a deployment:* The Keycloak auth server is deployed >>> as a WAR. We can use the copy-artifacts mechanism to simply copy the >>> WAR into the deployments directory. But that doesn't work for a domain >>> where you want to have the WAR pre-loaded into the content repository. >>> Furthermore, it's probably not the best way to integrate this for >>> standalone either. >>> >>> What would be a better option? >>> >> See the "A Mixed Approach" section at >> https://developer.jboss.org/docs/DOC-25627 >> >> The two comments at the bottom of that page are also relevant to that >> part of the wiki. >> >> Cheers, >> > Awesome. That actually solves several potential problems. Thanks Brian. > You're welcome. The drawback I mentioned there is these deployments appear in the resource tree alongside the regular user deployments. That's not ideal, because things can happen like the user undeploying or removing the deployment, plus it just mixes things that are somewhat separate. We've briefly discussed in the past the idea of having a "system-deployment" tree that looks just like the "deployment" tree except the registration of the handlers for the "add", "remove" "deploy" "undeploy" ops would have a flag added that marks them as private, so they don't show up in the public API. They can still be invoked internally by subsystem though. The change to that "fibo" example in the wiki would be minimal. This would impact the console's "Runtime" tab, as it's another tree of runtime data to present. Also, these deployments wouldn't appear in the Content Repository tab, which in general is good, although there may be some subtle UX effects. It would also change the location in the tree at which these things appear from EAP 6.x to EAP 7.x, but I don't think that's a big deal. What do folks think about pursuing this? Mazz, your opinion would be useful. Cheers, -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From ssilvert at redhat.com Thu Sep 11 14:53:39 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Thu, 11 Sep 2014 14:53:39 -0400 Subject: [wildfly-dev] System deployments? WAS: Creating a Keycloak Feature Pack In-Reply-To: <5411EA6D.4040603@redhat.com> References: <54109CBB.6070408@redhat.com> <5410C172.3000406@redhat.com> <5411D9C2.1040601@redhat.com> <5411EA6D.4040603@redhat.com> Message-ID: <5411EFB3.3000406@redhat.com> On 9/11/2014 2:31 PM, Brian Stansberry wrote: > On 9/11/14, 12:20 PM, Stan Silvert wrote: >> On 9/10/2014 5:24 PM, Brian Stansberry wrote: >>> On 9/10/14, 1:47 PM, Stan Silvert wrote: >>> >>>> *Issue #3: Adding a deployment:* The Keycloak auth server is deployed >>>> as a WAR. We can use the copy-artifacts mechanism to simply copy the >>>> WAR into the deployments directory. But that doesn't work for a domain >>>> where you want to have the WAR pre-loaded into the content repository. >>>> Furthermore, it's probably not the best way to integrate this for >>>> standalone either. >>>> >>>> What would be a better option? >>>> >>> See the "A Mixed Approach" section at >>> https://developer.jboss.org/docs/DOC-25627 >>> >>> The two comments at the bottom of that page are also relevant to that >>> part of the wiki. >>> >>> Cheers, >>> >> Awesome. That actually solves several potential problems. Thanks Brian. >> > You're welcome. > > The drawback I mentioned there is these deployments appear in the > resource tree alongside the regular user deployments. That's not ideal, > because things can happen like the user undeploying or removing the > deployment, plus it just mixes things that are somewhat separate. That's OK for now. Still a big improvement over copying to the /deployments directory. > > We've briefly discussed in the past the idea of having a > "system-deployment" tree that looks just like the "deployment" tree > except the registration of the handlers for the "add", "remove" "deploy" > "undeploy" ops would have a flag added that marks them as private, so > they don't show up in the public API. They can still be invoked > internally by subsystem though. +1 This might be especially important for Keycloak. You would want to limit the damage an attacker could do if he gained access to DMR but not to Keycloak itself. You don't want the attacker to be able to deploy his own auth server in place of the real one. Same goes for the Keycloak datasource and the Keycloak subsystem. > > The change to that "fibo" example in the wiki would be minimal. > > This would impact the console's "Runtime" tab, as it's another tree of > runtime data to present. Also, these deployments wouldn't appear in the > Content Repository tab, which in general is good, although there may be > some subtle UX effects. > > It would also change the location in the tree at which these things > appear from EAP 6.x to EAP 7.x, but I don't think that's a big deal. > > What do folks think about pursuing this? Mazz, your opinion would be useful. > > Cheers, > From tomaz.cerar at gmail.com Thu Sep 11 17:57:26 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Thu, 11 Sep 2014 23:57:26 +0200 Subject: [wildfly-dev] Fwd: Question on wildfly schema In-Reply-To: <5411467B.6020903@redhat.com> References: <5410B524.50001@redhat.com> <5411467B.6020903@redhat.com> Message-ID: Rob, Is there any special reason why you guys don't use schemas that are part of wildfly/EAP distro in docs/schema? -- tomaz On Thu, Sep 11, 2014 at 8:51 AM, Rob Stryker wrote: > > Hey All: > > All the wildfly schema are added online here: > http://www.jboss.org/schema/jbossas/ > > A user is indicating some of the schema cause bugs in our tools: > https://issues.jboss.org/browse/WFLY-3189 > > They have made a PR to make changes to some of the schema in our tools. > However, we typically clone the online folder for our schema and > distribute them with our tools, so it'd be very good to know if these > changes can also be made to the online versions so that we don't end up > forking the schema. > > So if any of you can either direct me to who would know the answer, or, > review > the changes to the schema yourself to see if they make sense, that'd be > really helpful. > > Ideally I'd prefer these changes to be made to the online schema so that > our > jbt-distributed schema match the onlines. > > PR: https://github.com/jbosstools/jbosstools-server/pull/268/files > > - Rob Stryker > > > > _______________________________________________ > 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/20140911/710fceb0/attachment.html From hbraun at redhat.com Fri Sep 12 02:39:44 2014 From: hbraun at redhat.com (Heiko Braun) Date: Fri, 12 Sep 2014 08:39:44 +0200 Subject: [wildfly-dev] System deployments? WAS: Creating a Keycloak Feature Pack In-Reply-To: <5411EA6D.4040603@redhat.com> References: <54109CBB.6070408@redhat.com> <5410C172.3000406@redhat.com> <5411D9C2.1040601@redhat.com> <5411EA6D.4040603@redhat.com> Message-ID: <271A9284-F785-470E-9C7A-3A7C0FC8DB30@redhat.com> +1 on system deployments. On 11 Sep 2014, at 20:31, Brian Stansberry wrote: > What do folks think about pursuing this? Mazz, your opinion would be useful. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140912/595d39ca/attachment.html From rory.odonnell at oracle.com Fri Sep 12 03:47:42 2014 From: rory.odonnell at oracle.com (Rory O'Donnell Oracle, Dublin Ireland) Date: Fri, 12 Sep 2014 08:47:42 +0100 Subject: [wildfly-dev] Early Access builds for JDK 9 b29 and JDK 8u40 b05 are available on java.net Message-ID: <5412A51E.1040703@oracle.com> Hi Guys, Early Access build for JDK 9 b29 is available on java.net, summary of changes are listed here Early Access build for JDK 8u40 b05 is available on java.net, summary of changes are listed here. 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/20140912/4124e44d/attachment.html From myfear at web.de Fri Sep 12 11:31:29 2014 From: myfear at web.de (Markus Eisele) Date: Fri, 12 Sep 2014 17:31:29 +0200 Subject: [wildfly-dev] Fwd: Camel 2.14-SNAPSHOT / JMX / JAXB / Classloading In-Reply-To: References: Message-ID: Hi all, I've been playing around with latest Camel 2.14 which introduces a new metrics-component. The information get exposed via JMX/XML. They use JAXB and bootstrapping Camel in a war on latest WildFly 8.1 (I used this a base: https://github.com/myfear/CamelEE7). If you use JConsole or hawtio+jolokia to access the relevant mbeans you get the following exception: NoClassDefFoundError: Could not initialize class com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl Root cause is this: public static JAXBContext createJaxbContext() throws JAXBException { // must use classloader from CamelContext to have JAXB working return JAXBContext.newInstance(Constants.JAXB_CONTEXT_PACKAGES, CamelContext.class.getClassLoader()); } (https://github.com/apache/camel/blob/master/camel-core/src/main/java/org/apache/camel/model/ModelHelper.java#L95) Full stack: https://gist.github.com/myfear/7d95388bb22e313e5f4b Google lead me to some results about AS7 .. nothing worked so far. I tried: 1) MANIFEST.MF (expot services com.sun.xml.bind) 2) jboss-deployment-structure.xml 3) packaging JAXB 2.2.6 in the war WildFly is the only server with those issues. It works on plain servlet containers like Tomcat and jetty. Any hints highly appreciated Thanks, Markus From Andrew.Schmidt at impactmobile.com Fri Sep 12 11:59:46 2014 From: Andrew.Schmidt at impactmobile.com (Andrew Schmidt) Date: Fri, 12 Sep 2014 15:59:46 +0000 Subject: [wildfly-dev] performance issue with wildfly and hibernate validator Message-ID: I've been investigating performance issues with wildfly and hibernate validator. The changes made for this https://issues.jboss.org/browse/AS7-1306 imply the follow from the jpa spec: The results of calling the PersistenceProviderResolverHolder.getPersistenceProviderResolver and the PersistenceProviderResolver.getPersistenceProviders methods must not be cached. however, the spec says later on: Note that the PersistenceProviderResolver.getPersistenceProviders() method can potentially be called many times. It is therefore recommended that the implementation of this method make use of caching. My interpretation is that wildfly should be caching the providers and it's the responsibility of the callers to not cache the results. So the issue AS7-1306 shouldn't have been implemented. The performance penalty of wildfly not caching the implementation of that method in regards to hibernate is that HibernatePersistenceProvider uses a cache for classes/methods/fields and that cache is blown away on every call to getPersistenceProviders and that happens on every validation of every member of every class. From jason.greene at redhat.com Fri Sep 12 12:30:39 2014 From: jason.greene at redhat.com (Jason Greene) Date: Fri, 12 Sep 2014 11:30:39 -0500 Subject: [wildfly-dev] performance issue with wildfly and hibernate validator In-Reply-To: References: Message-ID: <28773E35-093E-4979-905C-541D2A6BE9F4@redhat.com> On Sep 12, 2014, at 10:59 AM, Andrew Schmidt wrote: > I've been investigating performance issues with wildfly and hibernate validator. > The changes made for this https://issues.jboss.org/browse/AS7-1306 imply the > follow from the jpa spec: > > The results of calling the PersistenceProviderResolverHolder.getPersistenceProviderResolver > and the PersistenceProviderResolver.getPersistenceProviders methods must not be cached. > > however, the spec says later on: > > Note that the PersistenceProviderResolver.getPersistenceProviders() method > can potentially be called many times. It is therefore recommended that the > implementation of this method make use of caching. > > My interpretation is that wildfly should be caching the providers and it's the > responsibility of the callers to not cache the results. So the issue AS7-1306 shouldn't > have been implemented. > > The performance penalty of wildfly not caching the implementation of that method in regards to > hibernate is that HibernatePersistenceProvider uses a cache for classes/methods/fields > and that cache is blown away on every call to getPersistenceProviders and that > happens on every validation of every member of every class. I agree with your interpretation. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From smarlow at redhat.com Fri Sep 12 14:15:21 2014 From: smarlow at redhat.com (Scott Marlow) Date: Fri, 12 Sep 2014 14:15:21 -0400 Subject: [wildfly-dev] performance issue with wildfly and hibernate validator In-Reply-To: References: Message-ID: <54133839.7050901@redhat.com> Have you looked on the JPA spec mailing lists for clarification about whether the getPersistenceProviders result can be cached or not? I'll take a look to see if I can find anything. On 09/12/2014 11:59 AM, Andrew Schmidt wrote: > I've been investigating performance issues with wildfly and hibernate validator. > The changes made for this https://issues.jboss.org/browse/AS7-1306 imply the > follow from the jpa spec: > > The results of calling the PersistenceProviderResolverHolder.getPersistenceProviderResolver > and the PersistenceProviderResolver.getPersistenceProviders methods must not be cached. > > however, the spec says later on: > > Note that the PersistenceProviderResolver.getPersistenceProviders() method > can potentially be called many times. It is therefore recommended that the > implementation of this method make use of caching. > > My interpretation is that wildfly should be caching the providers and it's the > responsibility of the callers to not cache the results. So the issue AS7-1306 shouldn't > have been implemented. Good point that the JPA.next specification should pick one (allow caching or not). > > The performance penalty of wildfly not caching the implementation of that method in regards to > hibernate is that HibernatePersistenceProvider uses a cache for classes/methods/fields > and that cache is blown away on every call to getPersistenceProviders and that > happens on every validation of every member of every class. The Hibernate implementation of these classes also do the same thing: https://github.com/hibernate/hibernate-jpa-api/blob/master/src/main/java/javax/persistence/spi/PersistenceProviderResolverHolder.java#L173 The Hibernate PersistenceProviderResolverHolder does have a comment that caching should be introduced, whatever that means. > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From jason.greene at redhat.com Fri Sep 12 14:19:58 2014 From: jason.greene at redhat.com (Jason Greene) Date: Fri, 12 Sep 2014 13:19:58 -0500 Subject: [wildfly-dev] performance issue with wildfly and hibernate validator In-Reply-To: <54133839.7050901@redhat.com> References: <54133839.7050901@redhat.com> Message-ID: <93BAC64B-DD67-45BB-929B-FD9CCDE04C70@redhat.com> On Sep 12, 2014, at 1:15 PM, Scott Marlow wrote: > Have you looked on the JPA spec mailing lists for clarification about > whether the getPersistenceProviders result can be cached or not? I'll > take a look to see if I can find anything. > > On 09/12/2014 11:59 AM, Andrew Schmidt wrote: >> I've been investigating performance issues with wildfly and hibernate validator. >> The changes made for this https://issues.jboss.org/browse/AS7-1306 imply the >> follow from the jpa spec: >> >> The results of calling the PersistenceProviderResolverHolder.getPersistenceProviderResolver >> and the PersistenceProviderResolver.getPersistenceProviders methods must not be cached. >> >> however, the spec says later on: >> >> Note that the PersistenceProviderResolver.getPersistenceProviders() method >> can potentially be called many times. It is therefore recommended that the >> implementation of this method make use of caching. >> >> My interpretation is that wildfly should be caching the providers and it's the >> responsibility of the callers to not cache the results. So the issue AS7-1306 shouldn't >> have been implemented. > > Good point that the JPA.next specification should pick one (allow > caching or not). I think the spec is consistent, but could be improved to avoid confusion. It says that callers of PersistenceProviderResolver should not cache the result, but PersistenceProviderResolver can internally cache itself. This makes sense because the container should be able to decide when to change the provider, and if the caller caches this wouldn?t take effect. > >> >> The performance penalty of wildfly not caching the implementation of that method in regards to >> hibernate is that HibernatePersistenceProvider uses a cache for classes/methods/fields >> and that cache is blown away on every call to getPersistenceProviders and that >> happens on every validation of every member of every class. > > The Hibernate implementation of these classes also do the same thing: > > https://github.com/hibernate/hibernate-jpa-api/blob/master/src/main/java/javax/persistence/spi/PersistenceProviderResolverHolder.java#L173 > > The Hibernate PersistenceProviderResolverHolder does have a comment that > caching should be introduced, whatever that means. > >> >> _______________________________________________ >> 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 hardy at hibernate.org Fri Sep 12 14:40:54 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Fri, 12 Sep 2014 20:40:54 +0200 Subject: [wildfly-dev] performance issue with wildfly and hibernate validator In-Reply-To: <28773E35-093E-4979-905C-541D2A6BE9F4@redhat.com> References: <28773E35-093E-4979-905C-541D2A6BE9F4@redhat.com> Message-ID: <20140912184054.GA1934@Sarmakand-2.local> > > ... > > The performance penalty of wildfly not caching the implementation of that method in regards to > > hibernate is that HibernatePersistenceProvider uses a cache for classes/methods/fields > > and that cache is blown away on every call to getPersistenceProviders and that > > happens on every validation of every member of every class. > > > I agree with your interpretation. +1 For what it's worth Bean Validation caches its discovered Bean Validation Providers as well in javax.validation.Validation. --Hardy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 496 bytes Desc: not available Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140912/f3c4477e/attachment.bin From smarlow at redhat.com Fri Sep 12 15:43:33 2014 From: smarlow at redhat.com (Scott Marlow) Date: Fri, 12 Sep 2014 15:43:33 -0400 Subject: [wildfly-dev] performance issue with wildfly and hibernate validator In-Reply-To: <93BAC64B-DD67-45BB-929B-FD9CCDE04C70@redhat.com> References: <54133839.7050901@redhat.com> <93BAC64B-DD67-45BB-929B-FD9CCDE04C70@redhat.com> Message-ID: <54134CE5.1050501@redhat.com> My concern about caching the PersistenceProvider classes is that leaks in persistence providers versions that are already released (or not released but will not be fixed), will be more harmful. If the WildFly PersistenceProviderResolver implementation was the only implementor doing this, it would be safer to start caching by default (Hibernate + EclipseLink PersistenceProviderResolver impls do the same). We should default to not cache the PersistenceProvider instances for stability but allow for caching to be enabled, so that we *could* share the same PersistenceProvider instance across deployments as Andrew is asking for. Question is how to determine which PersistenceProvider class instances can be shared by multiple deployments without leaking memory. Do we need a system property setting or something in our configuration? If we use a boolean, it doesn't matter but if we have a list of PersistenceProvider class names, that can't be stored in the WildFly standalone.xml. One reason to make this a system property controlled setting is that we could later remove it if we determine that its hopeless (just don't ever cache) or there are no leaks (we could always cache). We also need more than to have no leaks in future persistence provider releases, we also need there to be no leaks in earlier releases that can also be used with WildFly. If anyone wants to contribute a classloader leak detector test to the WildFly testsuite (perhaps using the Eclipse MAT API), that would be helpful in ensuring that we don't cause a leak and can detect them in the future. Thoughts? Scott [1] https://eclipse.googlesource.com/eclipselink/javax.persistence/+/2.0.5.v201211290903/src/javax/persistence/spi/PersistenceProviderResolverHolder.java On 09/12/2014 02:19 PM, Jason Greene wrote: > > On Sep 12, 2014, at 1:15 PM, Scott Marlow wrote: > >> Have you looked on the JPA spec mailing lists for clarification about >> whether the getPersistenceProviders result can be cached or not? I'll >> take a look to see if I can find anything. >> >> On 09/12/2014 11:59 AM, Andrew Schmidt wrote: >>> I've been investigating performance issues with wildfly and hibernate validator. >>> The changes made for this https://issues.jboss.org/browse/AS7-1306 imply the >>> follow from the jpa spec: >>> >>> The results of calling the PersistenceProviderResolverHolder.getPersistenceProviderResolver >>> and the PersistenceProviderResolver.getPersistenceProviders methods must not be cached. >>> >>> however, the spec says later on: >>> >>> Note that the PersistenceProviderResolver.getPersistenceProviders() method >>> can potentially be called many times. It is therefore recommended that the >>> implementation of this method make use of caching. >>> >>> My interpretation is that wildfly should be caching the providers and it's the >>> responsibility of the callers to not cache the results. So the issue AS7-1306 shouldn't >>> have been implemented. >> >> Good point that the JPA.next specification should pick one (allow >> caching or not). > > I think the spec is consistent, but could be improved to avoid confusion. It says that callers of PersistenceProviderResolver should not cache the result, but PersistenceProviderResolver can internally cache itself. This makes sense because the container should be able to decide when to change the provider, and if the caller caches this wouldn?t take effect. > > >> >>> >>> The performance penalty of wildfly not caching the implementation of that method in regards to >>> hibernate is that HibernatePersistenceProvider uses a cache for classes/methods/fields >>> and that cache is blown away on every call to getPersistenceProviders and that >>> happens on every validation of every member of every class. >> >> The Hibernate implementation of these classes also do the same thing: >> >> https://github.com/hibernate/hibernate-jpa-api/blob/master/src/main/java/javax/persistence/spi/PersistenceProviderResolverHolder.java#L173 >> >> The Hibernate PersistenceProviderResolverHolder does have a comment that >> caching should be introduced, whatever that means. >> >>> >>> _______________________________________________ >>> 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 smarlow at redhat.com Fri Sep 12 16:10:11 2014 From: smarlow at redhat.com (Scott Marlow) Date: Fri, 12 Sep 2014 16:10:11 -0400 Subject: [wildfly-dev] performance issue with wildfly and hibernate validator In-Reply-To: <54134CE5.1050501@redhat.com> References: <54133839.7050901@redhat.com> <93BAC64B-DD67-45BB-929B-FD9CCDE04C70@redhat.com> <54134CE5.1050501@redhat.com> Message-ID: <54135323.7090001@redhat.com> Cross post link to hibernate-dev ml is http://lists.jboss.org/pipermail/hibernate-dev/2014-September/011777.html On 09/12/2014 03:43 PM, Scott Marlow wrote: > My concern about caching the PersistenceProvider classes is that leaks > in persistence providers versions that are already released (or not > released but will not be fixed), will be more harmful. > > If the WildFly PersistenceProviderResolver implementation was the only > implementor doing this, it would be safer to start caching by default > (Hibernate + EclipseLink PersistenceProviderResolver impls do the same). > > We should default to not cache the PersistenceProvider instances for > stability but allow for caching to be enabled, so that we *could* share > the same PersistenceProvider instance across deployments as Andrew is > asking for. > > Question is how to determine which PersistenceProvider class instances > can be shared by multiple deployments without leaking memory. Do we > need a system property setting or something in our configuration? If we > use a boolean, it doesn't matter but if we have a list of > PersistenceProvider class names, that can't be stored in the WildFly > standalone.xml. One reason to make this a system property controlled > setting is that we could later remove it if we determine that its > hopeless (just don't ever cache) or there are no leaks (we could always > cache). > > We also need more than to have no leaks in future persistence provider > releases, we also need there to be no leaks in earlier releases that can > also be used with WildFly. > > If anyone wants to contribute a classloader leak detector test to the > WildFly testsuite (perhaps using the Eclipse MAT API), that would be > helpful in ensuring that we don't cause a leak and can detect them in > the future. > > Thoughts? > > Scott > > [1] > https://eclipse.googlesource.com/eclipselink/javax.persistence/+/2.0.5.v201211290903/src/javax/persistence/spi/PersistenceProviderResolverHolder.java > > > On 09/12/2014 02:19 PM, Jason Greene wrote: >> >> On Sep 12, 2014, at 1:15 PM, Scott Marlow wrote: >> >>> Have you looked on the JPA spec mailing lists for clarification about >>> whether the getPersistenceProviders result can be cached or not? I'll >>> take a look to see if I can find anything. >>> >>> On 09/12/2014 11:59 AM, Andrew Schmidt wrote: >>>> I've been investigating performance issues with wildfly and hibernate validator. >>>> The changes made for this https://issues.jboss.org/browse/AS7-1306 imply the >>>> follow from the jpa spec: >>>> >>>> The results of calling the PersistenceProviderResolverHolder.getPersistenceProviderResolver >>>> and the PersistenceProviderResolver.getPersistenceProviders methods must not be cached. >>>> >>>> however, the spec says later on: >>>> >>>> Note that the PersistenceProviderResolver.getPersistenceProviders() method >>>> can potentially be called many times. It is therefore recommended that the >>>> implementation of this method make use of caching. >>>> >>>> My interpretation is that wildfly should be caching the providers and it's the >>>> responsibility of the callers to not cache the results. So the issue AS7-1306 shouldn't >>>> have been implemented. >>> >>> Good point that the JPA.next specification should pick one (allow >>> caching or not). >> >> I think the spec is consistent, but could be improved to avoid confusion. It says that callers of PersistenceProviderResolver should not cache the result, but PersistenceProviderResolver can internally cache itself. This makes sense because the container should be able to decide when to change the provider, and if the caller caches this wouldn?t take effect. >> >> >>> >>>> >>>> The performance penalty of wildfly not caching the implementation of that method in regards to >>>> hibernate is that HibernatePersistenceProvider uses a cache for classes/methods/fields >>>> and that cache is blown away on every call to getPersistenceProviders and that >>>> happens on every validation of every member of every class. >>> >>> The Hibernate implementation of these classes also do the same thing: >>> >>> https://github.com/hibernate/hibernate-jpa-api/blob/master/src/main/java/javax/persistence/spi/PersistenceProviderResolverHolder.java#L173 >>> >>> The Hibernate PersistenceProviderResolverHolder does have a comment that >>> caching should be introduced, whatever that means. >>> >>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> -- >> Jason T. Greene >> WildFly Lead / JBoss EAP Platform Architect >> JBoss, a division of Red Hat >> > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From jason.greene at redhat.com Fri Sep 12 16:19:03 2014 From: jason.greene at redhat.com (Jason Greene) Date: Fri, 12 Sep 2014 15:19:03 -0500 Subject: [wildfly-dev] performance issue with wildfly and hibernate validator In-Reply-To: <54134CE5.1050501@redhat.com> References: <54133839.7050901@redhat.com> <93BAC64B-DD67-45BB-929B-FD9CCDE04C70@redhat.com> <54134CE5.1050501@redhat.com> Message-ID: If you look at Andrew?s complaint though, he?s really talking about multiple calls in the *same* deployment. On Sep 12, 2014, at 2:43 PM, Scott Marlow wrote: > My concern about caching the PersistenceProvider classes is that leaks in persistence providers versions that are already released (or not released but will not be fixed), will be more harmful. > > If the WildFly PersistenceProviderResolver implementation was the only implementor doing this, it would be safer to start caching by default (Hibernate + EclipseLink PersistenceProviderResolver impls do the same). > > We should default to not cache the PersistenceProvider instances for stability but allow for caching to be enabled, so that we *could* share the same PersistenceProvider instance across deployments as Andrew is asking for. > > Question is how to determine which PersistenceProvider class instances can be shared by multiple deployments without leaking memory. Do we need a system property setting or something in our configuration? If we use a boolean, it doesn't matter but if we have a list of PersistenceProvider class names, that can't be stored in the WildFly standalone.xml. One reason to make this a system property controlled setting is that we could later remove it if we determine that its hopeless (just don't ever cache) or there are no leaks (we could always cache). > > We also need more than to have no leaks in future persistence provider releases, we also need there to be no leaks in earlier releases that can also be used with WildFly. > > If anyone wants to contribute a classloader leak detector test to the WildFly testsuite (perhaps using the Eclipse MAT API), that would be helpful in ensuring that we don't cause a leak and can detect them in the future. > > Thoughts? > > Scott > > [1] https://eclipse.googlesource.com/eclipselink/javax.persistence/+/2.0.5.v201211290903/src/javax/persistence/spi/PersistenceProviderResolverHolder.java > > > On 09/12/2014 02:19 PM, Jason Greene wrote: >> >> On Sep 12, 2014, at 1:15 PM, Scott Marlow wrote: >> >>> Have you looked on the JPA spec mailing lists for clarification about >>> whether the getPersistenceProviders result can be cached or not? I'll >>> take a look to see if I can find anything. >>> >>> On 09/12/2014 11:59 AM, Andrew Schmidt wrote: >>>> I've been investigating performance issues with wildfly and hibernate validator. >>>> The changes made for this https://issues.jboss.org/browse/AS7-1306 imply the >>>> follow from the jpa spec: >>>> >>>> The results of calling the PersistenceProviderResolverHolder.getPersistenceProviderResolver >>>> and the PersistenceProviderResolver.getPersistenceProviders methods must not be cached. >>>> >>>> however, the spec says later on: >>>> >>>> Note that the PersistenceProviderResolver.getPersistenceProviders() method >>>> can potentially be called many times. It is therefore recommended that the >>>> implementation of this method make use of caching. >>>> >>>> My interpretation is that wildfly should be caching the providers and it's the >>>> responsibility of the callers to not cache the results. So the issue AS7-1306 shouldn't >>>> have been implemented. >>> >>> Good point that the JPA.next specification should pick one (allow >>> caching or not). >> >> I think the spec is consistent, but could be improved to avoid confusion. It says that callers of PersistenceProviderResolver should not cache the result, but PersistenceProviderResolver can internally cache itself. This makes sense because the container should be able to decide when to change the provider, and if the caller caches this wouldn?t take effect. >> >> >>> >>>> >>>> The performance penalty of wildfly not caching the implementation of that method in regards to >>>> hibernate is that HibernatePersistenceProvider uses a cache for classes/methods/fields >>>> and that cache is blown away on every call to getPersistenceProviders and that >>>> happens on every validation of every member of every class. >>> >>> The Hibernate implementation of these classes also do the same thing: >>> >>> https://github.com/hibernate/hibernate-jpa-api/blob/master/src/main/java/javax/persistence/spi/PersistenceProviderResolverHolder.java#L173 >>> >>> The Hibernate PersistenceProviderResolverHolder does have a comment that >>> caching should be introduced, whatever that means. >>> >>>> >>>> _______________________________________________ >>>> 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 >> > -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From smarlow at redhat.com Fri Sep 12 16:37:22 2014 From: smarlow at redhat.com (Scott Marlow) Date: Fri, 12 Sep 2014 16:37:22 -0400 Subject: [wildfly-dev] performance issue with wildfly and hibernate validator In-Reply-To: References: <54133839.7050901@redhat.com> <93BAC64B-DD67-45BB-929B-FD9CCDE04C70@redhat.com> <54134CE5.1050501@redhat.com> Message-ID: <54135982.9010501@redhat.com> On 09/12/2014 04:19 PM, Jason Greene wrote: > If you look at Andrew?s complaint though, he?s really talking about multiple calls in the *same* deployment. Ahh, caching the list at the *same* deployment level, is safe. We can definitely do that. > > On Sep 12, 2014, at 2:43 PM, Scott Marlow wrote: > >> My concern about caching the PersistenceProvider classes is that leaks in persistence providers versions that are already released (or not released but will not be fixed), will be more harmful. >> >> If the WildFly PersistenceProviderResolver implementation was the only implementor doing this, it would be safer to start caching by default (Hibernate + EclipseLink PersistenceProviderResolver impls do the same). >> >> We should default to not cache the PersistenceProvider instances for stability but allow for caching to be enabled, so that we *could* share the same PersistenceProvider instance across deployments as Andrew is asking for. >> >> Question is how to determine which PersistenceProvider class instances can be shared by multiple deployments without leaking memory. Do we need a system property setting or something in our configuration? If we use a boolean, it doesn't matter but if we have a list of PersistenceProvider class names, that can't be stored in the WildFly standalone.xml. One reason to make this a system property controlled setting is that we could later remove it if we determine that its hopeless (just don't ever cache) or there are no leaks (we could always cache). >> >> We also need more than to have no leaks in future persistence provider releases, we also need there to be no leaks in earlier releases that can also be used with WildFly. >> >> If anyone wants to contribute a classloader leak detector test to the WildFly testsuite (perhaps using the Eclipse MAT API), that would be helpful in ensuring that we don't cause a leak and can detect them in the future. >> >> Thoughts? >> >> Scott >> >> [1] https://eclipse.googlesource.com/eclipselink/javax.persistence/+/2.0.5.v201211290903/src/javax/persistence/spi/PersistenceProviderResolverHolder.java >> >> >> On 09/12/2014 02:19 PM, Jason Greene wrote: >>> >>> On Sep 12, 2014, at 1:15 PM, Scott Marlow wrote: >>> >>>> Have you looked on the JPA spec mailing lists for clarification about >>>> whether the getPersistenceProviders result can be cached or not? I'll >>>> take a look to see if I can find anything. >>>> >>>> On 09/12/2014 11:59 AM, Andrew Schmidt wrote: >>>>> I've been investigating performance issues with wildfly and hibernate validator. >>>>> The changes made for this https://issues.jboss.org/browse/AS7-1306 imply the >>>>> follow from the jpa spec: >>>>> >>>>> The results of calling the PersistenceProviderResolverHolder.getPersistenceProviderResolver >>>>> and the PersistenceProviderResolver.getPersistenceProviders methods must not be cached. >>>>> >>>>> however, the spec says later on: >>>>> >>>>> Note that the PersistenceProviderResolver.getPersistenceProviders() method >>>>> can potentially be called many times. It is therefore recommended that the >>>>> implementation of this method make use of caching. >>>>> >>>>> My interpretation is that wildfly should be caching the providers and it's the >>>>> responsibility of the callers to not cache the results. So the issue AS7-1306 shouldn't >>>>> have been implemented. >>>> >>>> Good point that the JPA.next specification should pick one (allow >>>> caching or not). >>> >>> I think the spec is consistent, but could be improved to avoid confusion. It says that callers of PersistenceProviderResolver should not cache the result, but PersistenceProviderResolver can internally cache itself. This makes sense because the container should be able to decide when to change the provider, and if the caller caches this wouldn?t take effect. >>> >>> >>>> >>>>> >>>>> The performance penalty of wildfly not caching the implementation of that method in regards to >>>>> hibernate is that HibernatePersistenceProvider uses a cache for classes/methods/fields >>>>> and that cache is blown away on every call to getPersistenceProviders and that >>>>> happens on every validation of every member of every class. >>>> >>>> The Hibernate implementation of these classes also do the same thing: >>>> >>>> https://github.com/hibernate/hibernate-jpa-api/blob/master/src/main/java/javax/persistence/spi/PersistenceProviderResolverHolder.java#L173 >>>> >>>> The Hibernate PersistenceProviderResolverHolder does have a comment that >>>> caching should be introduced, whatever that means. >>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > From smarlow at redhat.com Fri Sep 12 16:47:41 2014 From: smarlow at redhat.com (Scott Marlow) Date: Fri, 12 Sep 2014 16:47:41 -0400 Subject: [wildfly-dev] performance issue with wildfly and hibernate validator In-Reply-To: <54135982.9010501@redhat.com> References: <54133839.7050901@redhat.com> <93BAC64B-DD67-45BB-929B-FD9CCDE04C70@redhat.com> <54134CE5.1050501@redhat.com> <54135982.9010501@redhat.com> Message-ID: <54135BED.6070405@redhat.com> WFLY-3853 is the jira for this change. On 09/12/2014 04:37 PM, Scott Marlow wrote: > On 09/12/2014 04:19 PM, Jason Greene wrote: >> If you look at Andrew?s complaint though, he?s really talking about multiple calls in the *same* deployment. > > Ahh, caching the list at the *same* deployment level, is safe. We can > definitely do that. > >> >> On Sep 12, 2014, at 2:43 PM, Scott Marlow wrote: >> >>> My concern about caching the PersistenceProvider classes is that leaks in persistence providers versions that are already released (or not released but will not be fixed), will be more harmful. >>> >>> If the WildFly PersistenceProviderResolver implementation was the only implementor doing this, it would be safer to start caching by default (Hibernate + EclipseLink PersistenceProviderResolver impls do the same). >>> >>> We should default to not cache the PersistenceProvider instances for stability but allow for caching to be enabled, so that we *could* share the same PersistenceProvider instance across deployments as Andrew is asking for. >>> >>> Question is how to determine which PersistenceProvider class instances can be shared by multiple deployments without leaking memory. Do we need a system property setting or something in our configuration? If we use a boolean, it doesn't matter but if we have a list of PersistenceProvider class names, that can't be stored in the WildFly standalone.xml. One reason to make this a system property controlled setting is that we could later remove it if we determine that its hopeless (just don't ever cache) or there are no leaks (we could always cache). >>> >>> We also need more than to have no leaks in future persistence provider releases, we also need there to be no leaks in earlier releases that can also be used with WildFly. >>> >>> If anyone wants to contribute a classloader leak detector test to the WildFly testsuite (perhaps using the Eclipse MAT API), that would be helpful in ensuring that we don't cause a leak and can detect them in the future. >>> >>> Thoughts? >>> >>> Scott >>> >>> [1] https://eclipse.googlesource.com/eclipselink/javax.persistence/+/2.0.5.v201211290903/src/javax/persistence/spi/PersistenceProviderResolverHolder.java >>> >>> >>> On 09/12/2014 02:19 PM, Jason Greene wrote: >>>> >>>> On Sep 12, 2014, at 1:15 PM, Scott Marlow wrote: >>>> >>>>> Have you looked on the JPA spec mailing lists for clarification about >>>>> whether the getPersistenceProviders result can be cached or not? I'll >>>>> take a look to see if I can find anything. >>>>> >>>>> On 09/12/2014 11:59 AM, Andrew Schmidt wrote: >>>>>> I've been investigating performance issues with wildfly and hibernate validator. >>>>>> The changes made for this https://issues.jboss.org/browse/AS7-1306 imply the >>>>>> follow from the jpa spec: >>>>>> >>>>>> The results of calling the PersistenceProviderResolverHolder.getPersistenceProviderResolver >>>>>> and the PersistenceProviderResolver.getPersistenceProviders methods must not be cached. >>>>>> >>>>>> however, the spec says later on: >>>>>> >>>>>> Note that the PersistenceProviderResolver.getPersistenceProviders() method >>>>>> can potentially be called many times. It is therefore recommended that the >>>>>> implementation of this method make use of caching. >>>>>> >>>>>> My interpretation is that wildfly should be caching the providers and it's the >>>>>> responsibility of the callers to not cache the results. So the issue AS7-1306 shouldn't >>>>>> have been implemented. >>>>> >>>>> Good point that the JPA.next specification should pick one (allow >>>>> caching or not). >>>> >>>> I think the spec is consistent, but could be improved to avoid confusion. It says that callers of PersistenceProviderResolver should not cache the result, but PersistenceProviderResolver can internally cache itself. This makes sense because the container should be able to decide when to change the provider, and if the caller caches this wouldn?t take effect. >>>> >>>> >>>>> >>>>>> >>>>>> The performance penalty of wildfly not caching the implementation of that method in regards to >>>>>> hibernate is that HibernatePersistenceProvider uses a cache for classes/methods/fields >>>>>> and that cache is blown away on every call to getPersistenceProviders and that >>>>>> happens on every validation of every member of every class. >>>>> >>>>> The Hibernate implementation of these classes also do the same thing: >>>>> >>>>> https://github.com/hibernate/hibernate-jpa-api/blob/master/src/main/java/javax/persistence/spi/PersistenceProviderResolverHolder.java#L173 >>>>> >>>>> The Hibernate PersistenceProviderResolverHolder does have a comment that >>>>> caching should be introduced, whatever that means. >>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>> >> >> -- >> Jason T. Greene >> WildFly Lead / JBoss EAP Platform Architect >> JBoss, a division of Red Hat >> > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From emmanuel at hibernate.org Sat Sep 13 04:27:46 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Sat, 13 Sep 2014 10:27:46 +0200 Subject: [wildfly-dev] performance issue with wildfly and hibernate validator In-Reply-To: <54135982.9010501@redhat.com> References: <54133839.7050901@redhat.com> <93BAC64B-DD67-45BB-929B-FD9CCDE04C70@redhat.com> <54134CE5.1050501@redhat.com> <54135982.9010501@redhat.com> Message-ID: <122EF8CA-79CB-4838-9B40-A6E2D1430562@hibernate.org> Sorry I am late in the game. I am the author of the persistence provider discovery mechanism. I confirm that it should not be cached by callers but that implementors should. I envision that the app server would know when a new persistence provider appears and disappears from its runtime in an efficient way. That also solves some of the modularity and visibility issues. Caching per deployment is bringing us 90% of the way and might be good enough. Once the app server can cache cross deployments safely we can go there too. Emmanuel > On 12 sept. 2014, at 22:37, Scott Marlow wrote: > >> On 09/12/2014 04:19 PM, Jason Greene wrote: >> If you look at Andrew?s complaint though, he?s really talking about multiple calls in the *same* deployment. > > Ahh, caching the list at the *same* deployment level, is safe. We can > definitely do that. > >> >>> On Sep 12, 2014, at 2:43 PM, Scott Marlow wrote: >>> >>> My concern about caching the PersistenceProvider classes is that leaks in persistence providers versions that are already released (or not released but will not be fixed), will be more harmful. >>> >>> If the WildFly PersistenceProviderResolver implementation was the only implementor doing this, it would be safer to start caching by default (Hibernate + EclipseLink PersistenceProviderResolver impls do the same). >>> >>> We should default to not cache the PersistenceProvider instances for stability but allow for caching to be enabled, so that we *could* share the same PersistenceProvider instance across deployments as Andrew is asking for. >>> >>> Question is how to determine which PersistenceProvider class instances can be shared by multiple deployments without leaking memory. Do we need a system property setting or something in our configuration? If we use a boolean, it doesn't matter but if we have a list of PersistenceProvider class names, that can't be stored in the WildFly standalone.xml. One reason to make this a system property controlled setting is that we could later remove it if we determine that its hopeless (just don't ever cache) or there are no leaks (we could always cache). >>> >>> We also need more than to have no leaks in future persistence provider releases, we also need there to be no leaks in earlier releases that can also be used with WildFly. >>> >>> If anyone wants to contribute a classloader leak detector test to the WildFly testsuite (perhaps using the Eclipse MAT API), that would be helpful in ensuring that we don't cause a leak and can detect them in the future. >>> >>> Thoughts? >>> >>> Scott >>> >>> [1] https://eclipse.googlesource.com/eclipselink/javax.persistence/+/2.0.5.v201211290903/src/javax/persistence/spi/PersistenceProviderResolverHolder.java >>> >>> >>>> On 09/12/2014 02:19 PM, Jason Greene wrote: >>>> >>>>> On Sep 12, 2014, at 1:15 PM, Scott Marlow wrote: >>>>> >>>>> Have you looked on the JPA spec mailing lists for clarification about >>>>> whether the getPersistenceProviders result can be cached or not? I'll >>>>> take a look to see if I can find anything. >>>>> >>>>>> On 09/12/2014 11:59 AM, Andrew Schmidt wrote: >>>>>> I've been investigating performance issues with wildfly and hibernate validator. >>>>>> The changes made for this https://issues.jboss.org/browse/AS7-1306 imply the >>>>>> follow from the jpa spec: >>>>>> >>>>>> The results of calling the PersistenceProviderResolverHolder.getPersistenceProviderResolver >>>>>> and the PersistenceProviderResolver.getPersistenceProviders methods must not be cached. >>>>>> >>>>>> however, the spec says later on: >>>>>> >>>>>> Note that the PersistenceProviderResolver.getPersistenceProviders() method >>>>>> can potentially be called many times. It is therefore recommended that the >>>>>> implementation of this method make use of caching. >>>>>> >>>>>> My interpretation is that wildfly should be caching the providers and it's the >>>>>> responsibility of the callers to not cache the results. So the issue AS7-1306 shouldn't >>>>>> have been implemented. >>>>> >>>>> Good point that the JPA.next specification should pick one (allow >>>>> caching or not). >>>> >>>> I think the spec is consistent, but could be improved to avoid confusion. It says that callers of PersistenceProviderResolver should not cache the result, but PersistenceProviderResolver can internally cache itself. This makes sense because the container should be able to decide when to change the provider, and if the caller caches this wouldn?t take effect. >>>> >>>> >>>>> >>>>>> >>>>>> The performance penalty of wildfly not caching the implementation of that method in regards to >>>>>> hibernate is that HibernatePersistenceProvider uses a cache for classes/methods/fields >>>>>> and that cache is blown away on every call to getPersistenceProviders and that >>>>>> happens on every validation of every member of every class. >>>>> >>>>> The Hibernate implementation of these classes also do the same thing: >>>>> >>>>> https://github.com/hibernate/hibernate-jpa-api/blob/master/src/main/java/javax/persistence/spi/PersistenceProviderResolverHolder.java#L173 >>>>> >>>>> The Hibernate PersistenceProviderResolverHolder does have a comment that >>>>> caching should be introduced, whatever that means. >>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >> >> -- >> Jason T. Greene >> WildFly Lead / JBoss EAP Platform Architect >> JBoss, a division of Red Hat > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From kabir.khan at jboss.com Mon Sep 15 04:42:07 2014 From: kabir.khan at jboss.com (Kabir Khan) Date: Mon, 15 Sep 2014 09:42:07 +0100 Subject: [wildfly-dev] Analysis of wildfly-8.1.0 dependency on JDK-Internal APIs In-Reply-To: <5411B2C8.80800@oracle.com> References: <5411B2C8.80800@oracle.com> Message-ID: <35020E7B-017E-4F30-A6B6-D11D3077CF37@jboss.com> Wow, now that is proactive! :-) On 11 Sep 2014, at 15:33, Rory O'Donnell Oracle, Dublin Ireland wrote: > Hi Tomaz, > > As part of the preparations for JDK 9, Oracle?s engineers have been analyzing open source projects like yours to understand usage. > One area of concern involves identifying compatibility problems, such as reliance on JDK-internal APIs. > > Our engineers have already prepared guidance on migrating some of the more common usage patterns of JDK-internal APIs to supported public interfaces. The list is on the OpenJDK wiki [0], along with instructions on how to run the jdeps analysis tool yourself . > > As part of the ongoing development of JDK 9, I would like to encourage migration from JDK-internal APIs towards the supported Java APIs. I have prepared a report for your project wildfly-8.1.0 release based on the jdeps output. > > The report is attached to this e-mail. > > For anything where your migration path is unclear, I would appreciate comments on the JDK-internal API usage patterns in the attached jdeps report, (if any) - in particular comments elaborating on the rationale for them - either to me or on this list. > > Finding suitable replacements for unsupported interfaces is not always straightforward, which is why I am reaching out to you early in the JDK 9 development cycle so you can give feedback about new APIs that may be needed to facilitate this exercise. > > Thank you in advance for any efforts and feedback helping us make JDK 9 better. > > Rgds,Rory > > [0] https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From jason.greene at redhat.com Mon Sep 15 11:40:13 2014 From: jason.greene at redhat.com (Jason Greene) Date: Mon, 15 Sep 2014 10:40:13 -0500 Subject: [wildfly-dev] Analysis of wildfly-8.1.0 dependency on JDK-Internal APIs In-Reply-To: <5411B2C8.80800@oracle.com> References: <5411B2C8.80800@oracle.com> Message-ID: Hello, Thanks for collecting feedback on this. Here is my initial response: org.w3c.* - These are false alarms. We bundle xalan, xerces, and woodstox for our JAXP providers so that we get consistent behavior on all JVM vendors and versions. The first two introduce the APIs that the report is complaining about. This is misreported as a JDK internal dep, because the JDK implementation of JAXP happens to be a fork of them, and so introduces those APIs as well. org.relax.* - This is a similar issue. We bundle the sun JAXB impl of a fixed version in order to provide consistent results on all JVMs, the classes it is complaining about are actually introduced by a sub JAXB dep (rngom). com.sun.misc.Unsafe - This class is critical to implementing high-performance concurrent data structures and algorithms (hence it?s usage by java.util.concurrent). Our general pattern is to attempt to use it if possible, and fallback to slower, less resilient, yet portable mechanisms. In practice all JVMs now include this class, since all providers prefer to reuse the java.util.concurrent code. If the day comes that java.util.concurrent no longer requires this (or an equivalent class), our primary need for it would be eliminated. sun.reflect.ReflectionFactory - Serialization/Marshalling frameworks need to be able to instantiate classes which do not have public constructors (just like Java Serialization requires). Without this hook, or alternatively usage of unsafe, this is not possible. sun.misc.Cleaner - This is useful in cases where you want to free the memory associated with a direct buffer immediately, preventing degenerate cases of massive native memory consumption, or failures caused by inaccurate limit checking. The main issue is that the garbage collector does not have proper insight into native memory space. and thus may defer freeing what it thinks is a single small reference which in reality is a large block of memory. PhantomReference isn?t a workable alternative. That said, in general we prefer to avoid non-static usage of direct buffers. com.sun.org.apache.xerces.* - This looks like one of our third party deps, XOM, includes some code for Java 5 to workaround bugs and enable secure processing. This code will never actually be ran on WildFly since we require Java 7. sun.misc.Signal/SignalHandler - This dependency has been removed in later versions and uses an alternative strategy. sun.tools.jconsole.Utilities - We have a jconsole gui plugin that is using this. Aren?t all of these jconsole APIs considered unofficial? GSS SPI/API usage - I?d have to research this further as to why jacorb needs these. However, we are looking into switching to a downstream fork of the oracle orb used in the JDK, so this one is likely to vanish as well. -Jason -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From rory.odonnell at oracle.com Mon Sep 15 12:14:45 2014 From: rory.odonnell at oracle.com (Rory O'Donnell Oracle, Dublin Ireland) Date: Mon, 15 Sep 2014 17:14:45 +0100 Subject: [wildfly-dev] Analysis of wildfly-8.1.0 dependency on JDK-Internal APIs In-Reply-To: References: <5411B2C8.80800@oracle.com> Message-ID: <54171075.40106@oracle.com> Hi Jason, Thank you for the feedback, I will pass on the info and get back to you. Rgds,Rory On 15/09/2014 16:40, Jason Greene wrote: > Hello, > > Thanks for collecting feedback on this. Here is my initial response: > > org.w3c.* - These are false alarms. We bundle xalan, xerces, and woodstox for our JAXP providers so that we get consistent behavior on all JVM vendors and versions. The first two introduce the APIs that the report is complaining about. This is misreported as a JDK internal dep, because the JDK implementation of JAXP happens to be a fork of them, and so introduces those APIs as well. > > org.relax.* - This is a similar issue. We bundle the sun JAXB impl of a fixed version in order to provide consistent results on all JVMs, the classes it is complaining about are actually introduced by a sub JAXB dep (rngom). > > com.sun.misc.Unsafe - This class is critical to implementing high-performance concurrent data structures and algorithms (hence it?s usage by java.util.concurrent). Our general pattern is to attempt to use it if possible, and fallback to slower, less resilient, yet portable mechanisms. In practice all JVMs now include this class, since all providers prefer to reuse the java.util.concurrent code. If the day comes that java.util.concurrent no longer requires this (or an equivalent class), our primary need for it would be eliminated. > > sun.reflect.ReflectionFactory - Serialization/Marshalling frameworks need to be able to instantiate classes which do not have public constructors (just like Java Serialization requires). Without this hook, or alternatively usage of unsafe, this is not possible. > > sun.misc.Cleaner - This is useful in cases where you want to free the memory associated with a direct buffer immediately, preventing degenerate cases of massive native memory consumption, or failures caused by inaccurate limit checking. The main issue is that the garbage collector does not have proper insight into native memory space. and thus may defer freeing what it thinks is a single small reference which in reality is a large block of memory. PhantomReference isn?t a workable alternative. That said, in general we prefer to avoid non-static usage of direct buffers. > > com.sun.org.apache.xerces.* - This looks like one of our third party deps, XOM, includes some code for Java 5 to workaround bugs and enable secure processing. This code will never actually be ran on WildFly since we require Java 7. > > sun.misc.Signal/SignalHandler - This dependency has been removed in later versions and uses an alternative strategy. > > sun.tools.jconsole.Utilities - We have a jconsole gui plugin that is using this. Aren?t all of these jconsole APIs considered unofficial? > > GSS SPI/API usage - I?d have to research this further as to why jacorb needs these. However, we are looking into switching to a downstream fork of the oracle orb used in the JDK, so this one is likely to vanish as well. > > -Jason > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland From jason.greene at redhat.com Mon Sep 15 16:41:12 2014 From: jason.greene at redhat.com (Jason Greene) Date: Mon, 15 Sep 2014 15:41:12 -0500 Subject: [wildfly-dev] 9.0.0.Alpha1 Released Message-ID: Hello Everyone, I just pushed Alpha1, which was a bit delayed due to testsuite issues that cropped up at the last minute: wildfly.org/downloads/ The biggest changes are: - Built off our new feature provisioning tool which is layered on the now separate core distribution - New servlet distribution based on above (we are calling it web lite until we can come up with a better name): https://repository.jboss.org/nexus/content/groups/developer/org/wildfly/wildfly-web-dist/9.0.0.Alpha1/wildfly-web-dist-9.0.0.Alpha1.zip - Architecture now supports server suspend mode (graceful shutdown) + Although only Undertow + EJB3 use this so far, additional subsystems need to be updated - Notification support in the management APIs Overall 256 fixes and improvements were included in this release: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12313721&version=12324890 Enjoy! -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From anmiller at redhat.com Mon Sep 15 17:43:05 2014 From: anmiller at redhat.com (Andrig Miller) Date: Mon, 15 Sep 2014 17:43:05 -0400 (EDT) Subject: [wildfly-dev] 9.0.0.Alpha1 Released In-Reply-To: References: Message-ID: <1890853890.22960001.1410817385526.JavaMail.zimbra@redhat.com> Congratulations to everyone involved! Awesome job! Andy ----- Original Message ----- > Hello Everyone, > I just pushed Alpha1, which was a bit delayed due to testsuite issues that > cropped up at the last minute: > wildfly.org/downloads/ > The biggest changes are: > - Built off our new feature provisioning tool which is layered on the now > separate core distribution > - New servlet distribution based on above (we are calling it web lite until > we can come up with a better name): > https://repository.jboss.org/nexus/content/groups/developer/org/wildfly/wildfly-web-dist/9.0.0.Alpha1/wildfly-web-dist-9.0.0.Alpha1.zip > - Architecture now supports server suspend mode (graceful shutdown) > + Although only Undertow + EJB3 use this so far, additional subsystems need > to be updated > - Notification support in the management APIs > Overall 256 fixes and improvements were included in this release: > https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12313721&version=12324890 > Enjoy! > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140915/7ad9bcc1/attachment.html From bgeorges at redhat.com Mon Sep 15 19:43:24 2014 From: bgeorges at redhat.com (Bruno Georges) Date: Mon, 15 Sep 2014 19:43:24 -0400 (EDT) Subject: [wildfly-dev] 9.0.0.Alpha1 Released In-Reply-To: References: Message-ID: Awesome news! Excellent work everyone ! -- Bruno Sent from my iPhone > On 16 Sep, 2014, at 4:41, Jason Greene wrote: > > Hello Everyone, > > I just pushed Alpha1, which was a bit delayed due to testsuite issues that cropped up at the last minute: > > wildfly.org/downloads/ > > The biggest changes are: > > - Built off our new feature provisioning tool which is layered on the now separate core distribution > - New servlet distribution based on above (we are calling it web lite until we can come up with a better name): > https://repository.jboss.org/nexus/content/groups/developer/org/wildfly/wildfly-web-dist/9.0.0.Alpha1/wildfly-web-dist-9.0.0.Alpha1.zip > - Architecture now supports server suspend mode (graceful shutdown) > + Although only Undertow + EJB3 use this so far, additional subsystems need to be updated > - Notification support in the management APIs > > Overall 256 fixes and improvements were included in this release: > https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12313721&version=12324890 > > Enjoy! > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From jgreene at redhat.com Mon Sep 15 22:49:14 2014 From: jgreene at redhat.com (Jason T. Greene) Date: Mon, 15 Sep 2014 22:49:14 -0400 (EDT) Subject: [wildfly-dev] 8.2 is next Message-ID: Hi Everyone, We just got the TCK update with CDI 1.2 and Scott is the process of setting it up. As soon as that's done and we get good results I would like to cut the release. So the window for critical patches is pretty small. So if you have them and you are confident they will not introduce TCK regressions, feel free to propose. The branch already has many fixes and, of course, CDI 1.2. Finally only "Final" component updates will be accepted. Our goal is to release as quickly as possible and move on to 9 beta. Thanks! -Jason From rsvoboda at redhat.com Tue Sep 16 07:34:07 2014 From: rsvoboda at redhat.com (Rostislav Svoboda) Date: Tue, 16 Sep 2014 07:34:07 -0400 (EDT) Subject: [wildfly-dev] Analysis of wildfly-8.1.0 dependency on JDK-Internal APIs In-Reply-To: References: <5411B2C8.80800@oracle.com> Message-ID: <958971336.23758981.1410867247161.JavaMail.zimbra@redhat.com> We have jdeps analysis for EAP 6.2.0 GA available since 2013-12-20, see https://bugzilla.redhat.com/show_bug.cgi?id=1045395. I have just added report for EAP 6.4.0 DR1. Could you please check these reports too ? There are items which weren't mentioned in this response - e.g. sun.nio. Thank you. Rostislav ----- Original Message ----- > Hello, > > Thanks for collecting feedback on this. Here is my initial response: > > org.w3c.* - These are false alarms. We bundle xalan, xerces, and woodstox for > our JAXP providers so that we get consistent behavior on all JVM vendors and > versions. The first two introduce the APIs that the report is complaining > about. This is misreported as a JDK internal dep, because the JDK > implementation of JAXP happens to be a fork of them, and so introduces those > APIs as well. > > org.relax.* - This is a similar issue. We bundle the sun JAXB impl of a fixed > version in order to provide consistent results on all JVMs, the classes it > is complaining about are actually introduced by a sub JAXB dep (rngom). > > com.sun.misc.Unsafe - This class is critical to implementing high-performance > concurrent data structures and algorithms (hence it?s usage by > java.util.concurrent). Our general pattern is to attempt to use it if > possible, and fallback to slower, less resilient, yet portable mechanisms. > In practice all JVMs now include this class, since all providers prefer to > reuse the java.util.concurrent code. If the day comes that > java.util.concurrent no longer requires this (or an equivalent class), our > primary need for it would be eliminated. > > sun.reflect.ReflectionFactory - Serialization/Marshalling frameworks need to > be able to instantiate classes which do not have public constructors (just > like Java Serialization requires). Without this hook, or alternatively usage > of unsafe, this is not possible. > > sun.misc.Cleaner - This is useful in cases where you want to free the memory > associated with a direct buffer immediately, preventing degenerate cases of > massive native memory consumption, or failures caused by inaccurate limit > checking. The main issue is that the garbage collector does not have proper > insight into native memory space. and thus may defer freeing what it thinks > is a single small reference which in reality is a large block of memory. > PhantomReference isn?t a workable alternative. That said, in general we > prefer to avoid non-static usage of direct buffers. > > com.sun.org.apache.xerces.* - This looks like one of our third party deps, > XOM, includes some code for Java 5 to workaround bugs and enable secure > processing. This code will never actually be ran on WildFly since we require > Java 7. > > sun.misc.Signal/SignalHandler - This dependency has been removed in later > versions and uses an alternative strategy. > > sun.tools.jconsole.Utilities - We have a jconsole gui plugin that is using > this. Aren?t all of these jconsole APIs considered unofficial? > > GSS SPI/API usage - I?d have to research this further as to why jacorb needs > these. However, we are looking into switching to a downstream fork of the > oracle orb used in the JDK, so this one is likely to vanish as well. > > -Jason > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From rsearls at redhat.com Tue Sep 16 11:08:06 2014 From: rsearls at redhat.com (Rebecca Searls) Date: Tue, 16 Sep 2014 11:08:06 -0400 (EDT) Subject: [wildfly-dev] Analysis of wildfly-8.1.0 dependency on JDK-Internal APIs In-Reply-To: <5411B2C8.80800@oracle.com> References: <5411B2C8.80800@oracle.com> Message-ID: <1528451551.5168825.1410880086124.JavaMail.zimbra@redhat.com> Has Oracle run the tool on apache's CXF project? ----- Original Message ----- > From: "Rory O'Donnell Oracle, Dublin Ireland" > To: "Toma? Cerar" > Cc: "Norman Maurer" , "Balchandra Vaidya" , > wildfly-dev at lists.jboss.org, "Dalibor Topic" > Sent: Thursday, September 11, 2014 10:33:44 AM > Subject: [wildfly-dev] Analysis of wildfly-8.1.0 dependency on JDK-Internal APIs > > Hi Tomaz, > > As part of the preparations for JDK 9, Oracle?s engineers have been > analyzing open source projects like yours to understand usage. > One area of concern involves identifying compatibility problems, such as > reliance on JDK-internal APIs. > > Our engineers have already prepared guidance on migrating some of the > more common usage patterns of JDK-internal APIs to supported public > interfaces. The list is on the OpenJDK wiki [0], along with instructions > on how to run the jdeps analysis tool yourself . > > As part of the ongoing development of JDK 9, I would like to encourage > migration from JDK-internal APIs towards the supported Java APIs. I have > prepared a report for your project wildfly-8.1.0 release based on the > jdeps output. > > The report is attached to this e-mail. > > For anything where your migration path is unclear, I would appreciate > comments on the JDK-internal API usage patterns in the attached jdeps > report, (if any) - in particular comments elaborating on the rationale > for them - either to me or on this list. > > Finding suitable replacements for unsupported interfaces is not always > straightforward, which is why I am reaching out to you early in the JDK > 9 development cycle so you can give feedback about new APIs that may be > needed to facilitate this exercise. > > Thank you in advance for any efforts and feedback helping us make JDK 9 > better. > > Rgds,Rory > > [0] > https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From rory.odonnell at oracle.com Tue Sep 16 12:08:20 2014 From: rory.odonnell at oracle.com (Rory O'Donnell Oracle, Dublin Ireland) Date: Tue, 16 Sep 2014 17:08:20 +0100 Subject: [wildfly-dev] Analysis of wildfly-8.1.0 dependency on JDK-Internal APIs In-Reply-To: <1528451551.5168825.1410880086124.JavaMail.zimbra@redhat.com> References: <5411B2C8.80800@oracle.com> <1528451551.5168825.1410880086124.JavaMail.zimbra@redhat.com> Message-ID: <54186074.9070602@oracle.com> Hi Rebecca, Not yet, we have a long list of FOSS Projects which we are targeting and I can't say when we will get to it. In the mean time the tool is available here: https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool Feel free to run it yourself and post results. Rgds,Rory On 16/09/2014 16:08, Rebecca Searls wrote: > Has Oracle run the tool on apache's CXF project? > > ----- Original Message ----- >> From: "Rory O'Donnell Oracle, Dublin Ireland" >> To: "Toma? Cerar" >> Cc: "Norman Maurer" , "Balchandra Vaidya" , >> wildfly-dev at lists.jboss.org, "Dalibor Topic" >> Sent: Thursday, September 11, 2014 10:33:44 AM >> Subject: [wildfly-dev] Analysis of wildfly-8.1.0 dependency on JDK-Internal APIs >> >> Hi Tomaz, >> >> As part of the preparations for JDK 9, Oracle?s engineers have been >> analyzing open source projects like yours to understand usage. >> One area of concern involves identifying compatibility problems, such as >> reliance on JDK-internal APIs. >> >> Our engineers have already prepared guidance on migrating some of the >> more common usage patterns of JDK-internal APIs to supported public >> interfaces. The list is on the OpenJDK wiki [0], along with instructions >> on how to run the jdeps analysis tool yourself . >> >> As part of the ongoing development of JDK 9, I would like to encourage >> migration from JDK-internal APIs towards the supported Java APIs. I have >> prepared a report for your project wildfly-8.1.0 release based on the >> jdeps output. >> >> The report is attached to this e-mail. >> >> For anything where your migration path is unclear, I would appreciate >> comments on the JDK-internal API usage patterns in the attached jdeps >> report, (if any) - in particular comments elaborating on the rationale >> for them - either to me or on this list. >> >> Finding suitable replacements for unsupported interfaces is not always >> straightforward, which is why I am reaching out to you early in the JDK >> 9 development cycle so you can give feedback about new APIs that may be >> needed to facilitate this exercise. >> >> Thank you in advance for any efforts and feedback helping us make JDK 9 >> better. >> >> Rgds,Rory >> >> [0] >> https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool >> >> -- >> Rgds,Rory O'Donnell >> Quality Engineering Manager >> Oracle EMEA , Dublin, Ireland >> >> >> >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland From jason.greene at redhat.com Tue Sep 16 12:18:12 2014 From: jason.greene at redhat.com (Jason Greene) Date: Tue, 16 Sep 2014 11:18:12 -0500 Subject: [wildfly-dev] Analysis of wildfly-8.1.0 dependency on JDK-Internal APIs In-Reply-To: <958971336.23758981.1410867247161.JavaMail.zimbra@redhat.com> References: <5411B2C8.80800@oracle.com> <958971336.23758981.1410867247161.JavaMail.zimbra@redhat.com> Message-ID: <5562DB28-65B3-4450-846F-8347364D6D58@redhat.com> Ah yes I forgot to address sun.nio, which is used in the codemodel project contained in both WildFly and EAP. This project generates source code and is a dependency of the JAXB RI, which we bundle (see earlier response for why). Looking at the project, the sun.nio classes are only directly used when the MS1252 encoder is used, and according to the comments in the source was done to workaround a bug on JDK 1.4.2. This workaround appears to have been removed in the latest trunk of the repo, but AFAICT there is not a release available with this fix: https://java.net/projects/codemodel/sources/svn/revision/333 On Sep 16, 2014, at 6:34 AM, Rostislav Svoboda wrote: > We have jdeps analysis for EAP 6.2.0 GA available since 2013-12-20, see https://bugzilla.redhat.com/show_bug.cgi?id=1045395. I have just added report for EAP 6.4.0 DR1. > > Could you please check these reports too ? There are items which weren't mentioned in this response - e.g. sun.nio. > > Thank you. > Rostislav > > ----- Original Message ----- >> Hello, >> >> Thanks for collecting feedback on this. Here is my initial response: >> >> org.w3c.* - These are false alarms. We bundle xalan, xerces, and woodstox for >> our JAXP providers so that we get consistent behavior on all JVM vendors and >> versions. The first two introduce the APIs that the report is complaining >> about. This is misreported as a JDK internal dep, because the JDK >> implementation of JAXP happens to be a fork of them, and so introduces those >> APIs as well. >> >> org.relax.* - This is a similar issue. We bundle the sun JAXB impl of a fixed >> version in order to provide consistent results on all JVMs, the classes it >> is complaining about are actually introduced by a sub JAXB dep (rngom). >> >> com.sun.misc.Unsafe - This class is critical to implementing high-performance >> concurrent data structures and algorithms (hence it?s usage by >> java.util.concurrent). Our general pattern is to attempt to use it if >> possible, and fallback to slower, less resilient, yet portable mechanisms. >> In practice all JVMs now include this class, since all providers prefer to >> reuse the java.util.concurrent code. If the day comes that >> java.util.concurrent no longer requires this (or an equivalent class), our >> primary need for it would be eliminated. >> >> sun.reflect.ReflectionFactory - Serialization/Marshalling frameworks need to >> be able to instantiate classes which do not have public constructors (just >> like Java Serialization requires). Without this hook, or alternatively usage >> of unsafe, this is not possible. >> >> sun.misc.Cleaner - This is useful in cases where you want to free the memory >> associated with a direct buffer immediately, preventing degenerate cases of >> massive native memory consumption, or failures caused by inaccurate limit >> checking. The main issue is that the garbage collector does not have proper >> insight into native memory space. and thus may defer freeing what it thinks >> is a single small reference which in reality is a large block of memory. >> PhantomReference isn?t a workable alternative. That said, in general we >> prefer to avoid non-static usage of direct buffers. >> >> com.sun.org.apache.xerces.* - This looks like one of our third party deps, >> XOM, includes some code for Java 5 to workaround bugs and enable secure >> processing. This code will never actually be ran on WildFly since we require >> Java 7. >> >> sun.misc.Signal/SignalHandler - This dependency has been removed in later >> versions and uses an alternative strategy. >> >> sun.tools.jconsole.Utilities - We have a jconsole gui plugin that is using >> this. Aren?t all of these jconsole APIs considered unofficial? >> >> GSS SPI/API usage - I?d have to research this further as to why jacorb needs >> these. However, we are looking into switching to a downstream fork of the >> oracle orb used in the JDK, so this one is likely to vanish as well. >> >> -Jason >> >> -- >> Jason T. Greene >> WildFly Lead / JBoss EAP Platform Architect >> JBoss, a division of Red Hat >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From rsearls at redhat.com Tue Sep 16 13:59:06 2014 From: rsearls at redhat.com (Rebecca Searls) Date: Tue, 16 Sep 2014 13:59:06 -0400 (EDT) Subject: [wildfly-dev] Analysis of wildfly-8.1.0 dependency on JDK-Internal APIs In-Reply-To: <54186074.9070602@oracle.com> References: <5411B2C8.80800@oracle.com> <1528451551.5168825.1410880086124.JavaMail.zimbra@redhat.com> <54186074.9070602@oracle.com> Message-ID: <391694563.5303626.1410890346256.JavaMail.zimbra@redhat.com> I ran jdeps on apache CXF ( http://git-wip-us.apache.org/repos/asf/cxf.git, branch 3.0.x-fixes) and got the following results. --- digraph "ehcache-2.8.1.jar" { // Path: ./services/sts/sts-war/target/SecurityTokenService/WEB-INF/lib/ehcache-2.8.1.jar "net.sf.ehcache.pool.sizeof.UnsafeSizeOf" -> "sun.misc.Unsafe (JDK internal API (rt.jar))"; } --- digraph "woodstox-core-asl-4.3.0.jar" { // Path: ./services/sts/sts-war/target/SecurityTokenService/WEB-INF/lib/woodstox-core-asl-4.3.0.jar "com.ctc.wstx.msv.GenericMsvValidator" -> "org.relaxng.datatype.Datatype (JDK internal API (tools .jar))"; } ----- Original Message ----- > From: "Rory O'Donnell Oracle, Dublin Ireland" > To: "Rebecca Searls" > Cc: "Toma? Cerar" , "Norman Maurer" , "Balchandra Vaidya" > , wildfly-dev at lists.jboss.org, "Dalibor Topic" > Sent: Tuesday, September 16, 2014 12:08:20 PM > Subject: Re: [wildfly-dev] Analysis of wildfly-8.1.0 dependency on JDK-Internal APIs > > Hi Rebecca, > > Not yet, we have a long list of FOSS Projects which we are targeting and I > can't say when we will get to it. In the mean time the tool is available > here: > > https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool > > Feel free to run it yourself and post results. > > Rgds,Rory > > > On 16/09/2014 16:08, Rebecca Searls wrote: > > Has Oracle run the tool on apache's CXF project? > > > > ----- Original Message ----- > >> From: "Rory O'Donnell Oracle, Dublin Ireland" > >> To: "Toma? Cerar" > >> Cc: "Norman Maurer" , "Balchandra Vaidya" > >> , > >> wildfly-dev at lists.jboss.org, "Dalibor Topic" > >> Sent: Thursday, September 11, 2014 10:33:44 AM > >> Subject: [wildfly-dev] Analysis of wildfly-8.1.0 dependency on > >> JDK-Internal APIs > >> > >> Hi Tomaz, > >> > >> As part of the preparations for JDK 9, Oracle?s engineers have been > >> analyzing open source projects like yours to understand usage. > >> One area of concern involves identifying compatibility problems, such as > >> reliance on JDK-internal APIs. > >> > >> Our engineers have already prepared guidance on migrating some of the > >> more common usage patterns of JDK-internal APIs to supported public > >> interfaces. The list is on the OpenJDK wiki [0], along with instructions > >> on how to run the jdeps analysis tool yourself . > >> > >> As part of the ongoing development of JDK 9, I would like to encourage > >> migration from JDK-internal APIs towards the supported Java APIs. I have > >> prepared a report for your project wildfly-8.1.0 release based on the > >> jdeps output. > >> > >> The report is attached to this e-mail. > >> > >> For anything where your migration path is unclear, I would appreciate > >> comments on the JDK-internal API usage patterns in the attached jdeps > >> report, (if any) - in particular comments elaborating on the rationale > >> for them - either to me or on this list. > >> > >> Finding suitable replacements for unsupported interfaces is not always > >> straightforward, which is why I am reaching out to you early in the JDK > >> 9 development cycle so you can give feedback about new APIs that may be > >> needed to facilitate this exercise. > >> > >> Thank you in advance for any efforts and feedback helping us make JDK 9 > >> better. > >> > >> Rgds,Rory > >> > >> [0] > >> https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool > >> > >> -- > >> Rgds,Rory O'Donnell > >> Quality Engineering Manager > >> Oracle EMEA , Dublin, Ireland > >> > >> > >> > >> > >> > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > > > > > From ssilvert at redhat.com Tue Sep 16 14:43:58 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Tue, 16 Sep 2014 14:43:58 -0400 Subject: [wildfly-dev] Creating a Keycloak Feature Pack In-Reply-To: <5410C172.3000406@redhat.com> References: <54109CBB.6070408@redhat.com> <5410C172.3000406@redhat.com> Message-ID: <541884EE.1030007@redhat.com> On 9/10/2014 5:24 PM, Brian Stansberry wrote: > On 9/10/14, 1:47 PM, Stan Silvert wrote: > >> *Issue #3: Adding a deployment:* The Keycloak auth server is deployed >> as a WAR. We can use the copy-artifacts mechanism to simply copy the >> WAR into the deployments directory. But that doesn't work for a domain >> where you want to have the WAR pre-loaded into the content repository. >> Furthermore, it's probably not the best way to integrate this for >> standalone either. >> >> What would be a better option? >> > See the "A Mixed Approach" section at > https://developer.jboss.org/docs/DOC-25627 When I do this in a domain, the deployment does not live in the content repository and can not be assigned directly to server groups. Instead, it is just deployed to any server that has the Keycloak subsystem. That might be a good thing. The deployment is still "assigned" to the server group via the profile containing the keycloak subsystem. Do any of you guys see a problem with this? > > The two comments at the bottom of that page are also relevant to that > part of the wiki. > > Cheers, > From brian.stansberry at redhat.com Tue Sep 16 15:07:37 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 16 Sep 2014 14:07:37 -0500 Subject: [wildfly-dev] Creating a Keycloak Feature Pack In-Reply-To: <541884EE.1030007@redhat.com> References: <54109CBB.6070408@redhat.com> <5410C172.3000406@redhat.com> <541884EE.1030007@redhat.com> Message-ID: <54188A79.2040808@redhat.com> On 9/16/14, 1:43 PM, Stan Silvert wrote: > On 9/10/2014 5:24 PM, Brian Stansberry wrote: >> On 9/10/14, 1:47 PM, Stan Silvert wrote: >> >>> *Issue #3: Adding a deployment:* The Keycloak auth server is deployed >>> as a WAR. We can use the copy-artifacts mechanism to simply copy the >>> WAR into the deployments directory. But that doesn't work for a domain >>> where you want to have the WAR pre-loaded into the content repository. >>> Furthermore, it's probably not the best way to integrate this for >>> standalone either. >>> >>> What would be a better option? >>> >> See the "A Mixed Approach" section at >> https://developer.jboss.org/docs/DOC-25627 > When I do this in a domain, the deployment does not live in the content > repository and can not be assigned directly to server groups. Instead, > it is just deployed to any server that has the Keycloak subsystem. > > That might be a good thing. The deployment is still "assigned" to the > server group via the profile containing the keycloak subsystem. > > Do any of you guys see a problem with this? > That's the goal. The "deployment" is not like end user deployments; it's an aspect of the subsystem. And subsystems are mapped to server groups via profiles. >> >> The two comments at the bottom of that page are also relevant to that >> part of the wiki. >> >> Cheers, >> > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From sdouglas at redhat.com Tue Sep 16 17:55:51 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Wed, 17 Sep 2014 07:55:51 +1000 Subject: [wildfly-dev] Creating config files for provisioned servers Message-ID: <5418B1E7.3020808@redhat.com> Hi All, so I have been giving a bit of thought to how our configuration files are generated, and how it can work with feature packs. At the moment feature packs just package files with a subsystem list inside, and later feature packs configs override configs from their dependents. I think we should move to an approach where feature packs build on the config provided by other feature packs. So the web feature pack config will basically express 'add these additional subsystems to standalone.xml'. Additional config files can also be created based of existing config, so for example standalone-full.xml would be represented as 'like standalone.xml, but with these additional subsystems'. Domain mode would work in a similar manner, but with profiles instead of config files (so everything I am saying here about standalone.xml will also apply to domain mode). There are quite a few advantages to this approach: - As most (all?) configs will use standalone.xml as a base, it makes it simple to keep multiple config files in place - It is easy for a feature pack to add a subsystem to all configurations (e.g. installing the KeyCloak feature pack could add KeyCloak to all configs). - It is easy to create a new configuration that is the same as existing configs, but with an additional subsystem. Does this sound reasonable? Stuart From rstryker at redhat.com Wed Sep 17 05:21:09 2014 From: rstryker at redhat.com (Rob Stryker) Date: Wed, 17 Sep 2014 17:21:09 +0800 Subject: [wildfly-dev] Fwd: Question on wildfly schema In-Reply-To: <5411467B.6020903@redhat.com> References: <5410B524.50001@redhat.com> <5411467B.6020903@redhat.com> Message-ID: <54195285.2090306@redhat.com> Hi all: After looking at the user's patch to jbosstools, I made accompanying PRs to the wildfly and metadata repos. https://github.com/wildfly/wildfly/pull/6720 https://github.com/jboss/metadata/pull/72 The wildfly PR seems to have passed all tests, so I'm wondering who can actually review the changes and see if they make sense. I admit, some of the changes are a bit suspect, so I'd really appreciate if someone can take a look at them. Any questions should probably be made on the jira https://issues.jboss.org/browse/WFLY-3189 to ensure wider visibility to the patch contributor. I realize you all have things you're working on, but, the tools team would appreciate it if this could be prioritized for us. Our schedule is tight for any further changes, and we don't want to accept changes to the schema unless we verify the same changes will also be in your repositories as well. On 09/11/2014 02:51 PM, Rob Stryker wrote: > Hey All: > > All the wildfly schema are added online here: > http://www.jboss.org/schema/jbossas/ > > A user is indicating some of the schema cause bugs in our tools: > https://issues.jboss.org/browse/WFLY-3189 > > They have made a PR to make changes to some of the schema in our tools. > However, we typically clone the online folder for our schema and > distribute them with our tools, so it'd be very good to know if these > changes can also be made to the online versions so that we don't end up > forking the schema. > > So if any of you can either direct me to who would know the answer, or, review > the changes to the schema yourself to see if they make sense, that'd be really helpful. > > Ideally I'd prefer these changes to be made to the online schema so that our > jbt-distributed schema match the onlines. > > PR: https://github.com/jbosstools/jbosstools-server/pull/268/files > > - Rob Stryker > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From kabir.khan at jboss.com Wed Sep 17 05:32:34 2014 From: kabir.khan at jboss.com (Kabir Khan) Date: Wed, 17 Sep 2014 10:32:34 +0100 Subject: [wildfly-dev] Creating config files for provisioned servers In-Reply-To: <5418B1E7.3020808@redhat.com> References: <5418B1E7.3020808@redhat.com> Message-ID: What about the next iteration where, say you have the EE feature pack and you add the clustering feature. Say, the clustering feature will add jgroups and infinispan subsystems, which is in line with what you say. However, with clustering enabled, IIRC that enables some extra things in e.g. the EJB subsystem. On 16 Sep 2014, at 22:55, Stuart Douglas wrote: > Hi All, > > so I have been giving a bit of thought to how our configuration files > are generated, and how it can work with feature packs. At the moment > feature packs just package files with a subsystem list inside, and later > feature packs configs override configs from their dependents. > > I think we should move to an approach where feature packs build on the > config provided by other feature packs. So the web feature pack config > will basically express 'add these additional subsystems to > standalone.xml'. Additional config files can also be created based of > existing config, so for example standalone-full.xml would be represented > as 'like standalone.xml, but with these additional subsystems'. > > Domain mode would work in a similar manner, but with profiles instead of > config files (so everything I am saying here about standalone.xml will > also apply to domain mode). > > There are quite a few advantages to this approach: > > - As most (all?) configs will use standalone.xml as a base, it makes it > simple to keep multiple config files in place > - It is easy for a feature pack to add a subsystem to all configurations > (e.g. installing the KeyCloak feature pack could add KeyCloak to all > configs). > - It is easy to create a new configuration that is the same as existing > configs, but with an additional subsystem. > > Does this sound reasonable? > > Stuart > > _______________________________________________ > 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 Sep 17 05:51:25 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Wed, 17 Sep 2014 19:51:25 +1000 Subject: [wildfly-dev] Creating config files for provisioned servers In-Reply-To: References: <5418B1E7.3020808@redhat.com> Message-ID: <5419599D.1020700@gmail.com> This would still be done via supplements, in a similar way to how it is done at the moment. I think when you define a new file such as standalone-ha.xml you will also be able to supply supplement names to modify the config. Stuart Kabir Khan wrote: > What about the next iteration where, say you have the EE feature pack and you add the clustering feature. > Say, the clustering feature will add jgroups and infinispan subsystems, which is in line with what you say. > However, with clustering enabled, IIRC that enables some extra things in e.g. the EJB subsystem. > On 16 Sep 2014, at 22:55, Stuart Douglas wrote: > >> Hi All, >> >> so I have been giving a bit of thought to how our configuration files >> are generated, and how it can work with feature packs. At the moment >> feature packs just package files with a subsystem list inside, and later >> feature packs configs override configs from their dependents. >> >> I think we should move to an approach where feature packs build on the >> config provided by other feature packs. So the web feature pack config >> will basically express 'add these additional subsystems to >> standalone.xml'. Additional config files can also be created based of >> existing config, so for example standalone-full.xml would be represented >> as 'like standalone.xml, but with these additional subsystems'. >> >> Domain mode would work in a similar manner, but with profiles instead of >> config files (so everything I am saying here about standalone.xml will >> also apply to domain mode). >> >> There are quite a few advantages to this approach: >> >> - As most (all?) configs will use standalone.xml as a base, it makes it >> simple to keep multiple config files in place >> - It is easy for a feature pack to add a subsystem to all configurations >> (e.g. installing the KeyCloak feature pack could add KeyCloak to all >> configs). >> - It is easy to create a new configuration that is the same as existing >> configs, but with an additional subsystem. >> >> Does this sound reasonable? >> >> Stuart >> >> _______________________________________________ >> 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 ssilvert at redhat.com Wed Sep 17 09:29:27 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Wed, 17 Sep 2014 09:29:27 -0400 Subject: [wildfly-dev] Creating config files for provisioned servers In-Reply-To: <5419599D.1020700@gmail.com> References: <5418B1E7.3020808@redhat.com> <5419599D.1020700@gmail.com> Message-ID: <54198CB7.7010600@redhat.com> I think it sounds good. Kabir's question was my only concern. I believe that I'll not need to create a new config file with different supplements, but I'll need to specify different supplements based on which config file I'm modifying. In other words, if I'm adding the keycloak subsystem to standalone.xml, I want one supplement. If I'm adding keycloak subsystem to domain.xml, I want a different supplement. On 9/17/2014 5:51 AM, Stuart Douglas wrote: > This would still be done via supplements, in a similar way to how it is > done at the moment. I think when you define a new file such as > standalone-ha.xml you will also be able to supply supplement names to > modify the config. > > Stuart > > Kabir Khan wrote: >> What about the next iteration where, say you have the EE feature pack and you add the clustering feature. >> Say, the clustering feature will add jgroups and infinispan subsystems, which is in line with what you say. >> However, with clustering enabled, IIRC that enables some extra things in e.g. the EJB subsystem. >> On 16 Sep 2014, at 22:55, Stuart Douglas wrote: >> >>> Hi All, >>> >>> so I have been giving a bit of thought to how our configuration files >>> are generated, and how it can work with feature packs. At the moment >>> feature packs just package files with a subsystem list inside, and later >>> feature packs configs override configs from their dependents. >>> >>> I think we should move to an approach where feature packs build on the >>> config provided by other feature packs. So the web feature pack config >>> will basically express 'add these additional subsystems to >>> standalone.xml'. Additional config files can also be created based of >>> existing config, so for example standalone-full.xml would be represented >>> as 'like standalone.xml, but with these additional subsystems'. >>> >>> Domain mode would work in a similar manner, but with profiles instead of >>> config files (so everything I am saying here about standalone.xml will >>> also apply to domain mode). >>> >>> There are quite a few advantages to this approach: >>> >>> - As most (all?) configs will use standalone.xml as a base, it makes it >>> simple to keep multiple config files in place >>> - It is easy for a feature pack to add a subsystem to all configurations >>> (e.g. installing the KeyCloak feature pack could add KeyCloak to all >>> configs). >>> - It is easy to create a new configuration that is the same as existing >>> configs, but with an additional subsystem. >>> >>> Does this sound reasonable? >>> >>> Stuart >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From darran.lofthouse at jboss.com Wed Sep 17 10:52:29 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 17 Sep 2014 15:52:29 +0100 Subject: [wildfly-dev] Creating config files for provisioned servers In-Reply-To: <5418B1E7.3020808@redhat.com> References: <5418B1E7.3020808@redhat.com> Message-ID: <5419A02D.9090305@jboss.com> This is where I have been saying before why not build all the configs using management ops / the CLI? - Much easier to define config that tweaks the config that came before. - Execute using the CLI and you even get some logic support. - Would be compatible if in the future we release distributions that don't use XML config persistence. Regards, Darran Lofthouse. On 16/09/14 22:55, Stuart Douglas wrote: > Hi All, > > so I have been giving a bit of thought to how our configuration files > are generated, and how it can work with feature packs. At the moment > feature packs just package files with a subsystem list inside, and later > feature packs configs override configs from their dependents. > > I think we should move to an approach where feature packs build on the > config provided by other feature packs. So the web feature pack config > will basically express 'add these additional subsystems to > standalone.xml'. Additional config files can also be created based of > existing config, so for example standalone-full.xml would be represented > as 'like standalone.xml, but with these additional subsystems'. > > Domain mode would work in a similar manner, but with profiles instead of > config files (so everything I am saying here about standalone.xml will > also apply to domain mode). > > There are quite a few advantages to this approach: > > - As most (all?) configs will use standalone.xml as a base, it makes it > simple to keep multiple config files in place > - It is easy for a feature pack to add a subsystem to all configurations > (e.g. installing the KeyCloak feature pack could add KeyCloak to all > configs). > - It is easy to create a new configuration that is the same as existing > configs, but with an additional subsystem. > > Does this sound reasonable? > > Stuart > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From jperkins at redhat.com Wed Sep 17 11:42:11 2014 From: jperkins at redhat.com (James R. Perkins) Date: Wed, 17 Sep 2014 08:42:11 -0700 Subject: [wildfly-dev] Creating config files for provisioned servers In-Reply-To: <5419A02D.9090305@jboss.com> References: <5418B1E7.3020808@redhat.com> <5419A02D.9090305@jboss.com> Message-ID: <5419ABD3.9040205@redhat.com> If we ever wanted to move away from XML configuration files using DMR, or JSON, could be a good first step. On 09/17/2014 07:52 AM, Darran Lofthouse wrote: > This is where I have been saying before why not build all the configs > using management ops / the CLI? > > - Much easier to define config that tweaks the config that came before. > - Execute using the CLI and you even get some logic support. > - Would be compatible if in the future we release distributions that > don't use XML config persistence. > > Regards, > Darran Lofthouse. > > > On 16/09/14 22:55, Stuart Douglas wrote: >> Hi All, >> >> so I have been giving a bit of thought to how our configuration files >> are generated, and how it can work with feature packs. At the moment >> feature packs just package files with a subsystem list inside, and later >> feature packs configs override configs from their dependents. >> >> I think we should move to an approach where feature packs build on the >> config provided by other feature packs. So the web feature pack config >> will basically express 'add these additional subsystems to >> standalone.xml'. Additional config files can also be created based of >> existing config, so for example standalone-full.xml would be represented >> as 'like standalone.xml, but with these additional subsystems'. >> >> Domain mode would work in a similar manner, but with profiles instead of >> config files (so everything I am saying here about standalone.xml will >> also apply to domain mode). >> >> There are quite a few advantages to this approach: >> >> - As most (all?) configs will use standalone.xml as a base, it makes it >> simple to keep multiple config files in place >> - It is easy for a feature pack to add a subsystem to all configurations >> (e.g. installing the KeyCloak feature pack could add KeyCloak to all >> configs). >> - It is easy to create a new configuration that is the same as existing >> configs, but with an additional subsystem. >> >> Does this sound reasonable? >> >> Stuart >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- James R. Perkins JBoss by Red Hat From brian.stansberry at redhat.com Wed Sep 17 11:52:25 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 17 Sep 2014 10:52:25 -0500 Subject: [wildfly-dev] Creating config files for provisioned servers In-Reply-To: <5419ABD3.9040205@redhat.com> References: <5418B1E7.3020808@redhat.com> <5419A02D.9090305@jboss.com> <5419ABD3.9040205@redhat.com> Message-ID: <5419AE39.9090009@redhat.com> Alexey is working on this as a persistence alternative. https://developer.jboss.org/docs/DOC-52773 Darran, I've come around to wanting to do things as you say, but haven't had cycles to resurrect my server-embedded in CLI thing. This is somewhat orthogonal to Stuart's question though, which AIUI is more about what configs a feature-pack should be updating. How it updates them is of course related though. On 9/17/14, 10:42 AM, James R. Perkins wrote: > If we ever wanted to move away from XML configuration files using DMR, > or JSON, could be a good first step. > > On 09/17/2014 07:52 AM, Darran Lofthouse wrote: >> This is where I have been saying before why not build all the configs >> using management ops / the CLI? >> >> - Much easier to define config that tweaks the config that came before. >> - Execute using the CLI and you even get some logic support. >> - Would be compatible if in the future we release distributions that >> don't use XML config persistence. >> >> Regards, >> Darran Lofthouse. >> >> >> On 16/09/14 22:55, Stuart Douglas wrote: >>> Hi All, >>> >>> so I have been giving a bit of thought to how our configuration files >>> are generated, and how it can work with feature packs. At the moment >>> feature packs just package files with a subsystem list inside, and later >>> feature packs configs override configs from their dependents. >>> >>> I think we should move to an approach where feature packs build on the >>> config provided by other feature packs. So the web feature pack config >>> will basically express 'add these additional subsystems to >>> standalone.xml'. Additional config files can also be created based of >>> existing config, so for example standalone-full.xml would be represented >>> as 'like standalone.xml, but with these additional subsystems'. >>> >>> Domain mode would work in a similar manner, but with profiles instead of >>> config files (so everything I am saying here about standalone.xml will >>> also apply to domain mode). >>> >>> There are quite a few advantages to this approach: >>> >>> - As most (all?) configs will use standalone.xml as a base, it makes it >>> simple to keep multiple config files in place >>> - It is easy for a feature pack to add a subsystem to all configurations >>> (e.g. installing the KeyCloak feature pack could add KeyCloak to all >>> configs). >>> - It is easy to create a new configuration that is the same as existing >>> configs, but with an additional subsystem. >>> >>> Does this sound reasonable? >>> >>> Stuart >>> >>> _______________________________________________ >>> 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 rsearls at redhat.com Wed Sep 17 12:44:48 2014 From: rsearls at redhat.com (Rebecca Searls) Date: Wed, 17 Sep 2014 12:44:48 -0400 (EDT) Subject: [wildfly-dev] Analysis of wildfly-8.1.0 dependency on JDK-Internal APIs In-Reply-To: <54196368.4050603@oracle.com> References: <5411B2C8.80800@oracle.com> <1528451551.5168825.1410880086124.JavaMail.zimbra@redhat.com> <54186074.9070602@oracle.com> <391694563.5303626.1410890346256.JavaMail.zimbra@redhat.com> <54196368.4050603@oracle.com> Message-ID: <1773999125.5880249.1410972288877.JavaMail.zimbra@redhat.com> I filed https://issues.apache.org/jira/browse/CXF-6008 requesting the CXF team responding to this information. ----- Original Message ----- > From: "Balchandra Vaidya" > To: "Rebecca Searls" , "rory odonnell" > Cc: "Toma? Cerar" , "Norman Maurer" , > wildfly-dev at lists.jboss.org, "Dalibor Topic" > Sent: Wednesday, September 17, 2014 6:33:12 AM > Subject: Re: [wildfly-dev] Analysis of wildfly-8.1.0 dependency on JDK-Internal APIs > > > Hi Rebecca, > > Thank you for the report. Both sun.misc.Unsafe and > org.relaxng.datatype.Datatype > are JDK-internal APIs that have no supported replacements. If you are > unable to > migrate away, please provide us with an explanation. > > Thank you for your efforts and feedback helping us make JDK 9 better. > > > Regards, > Balchandra > > > On 16/09/2014 18:59, Rebecca Searls wrote: > > I ran jdeps on apache CXF ( http://git-wip-us.apache.org/repos/asf/cxf.git, > > branch 3.0.x-fixes) > > and got the following results. > > > > --- > > digraph "ehcache-2.8.1.jar" { > > // Path: > > ./services/sts/sts-war/target/SecurityTokenService/WEB-INF/lib/ehcache-2.8.1.jar > > "net.sf.ehcache.pool.sizeof.UnsafeSizeOf" -> "sun.misc.Unsafe > > (JDK internal API (rt.jar))"; > > } > > > > --- > > digraph "woodstox-core-asl-4.3.0.jar" { > > // Path: > > ./services/sts/sts-war/target/SecurityTokenService/WEB-INF/lib/woodstox-core-asl-4.3.0.jar > > "com.ctc.wstx.msv.GenericMsvValidator" -> > > "org.relaxng.datatype.Datatype (JDK internal API (tools > > .jar))"; > > } > > > > > > > > ----- Original Message ----- > >> From: "Rory O'Donnell Oracle, Dublin Ireland" > >> To: "Rebecca Searls" > >> Cc: "Toma? Cerar" , "Norman Maurer" > >> , "Balchandra Vaidya" > >> , wildfly-dev at lists.jboss.org, "Dalibor > >> Topic" > >> Sent: Tuesday, September 16, 2014 12:08:20 PM > >> Subject: Re: [wildfly-dev] Analysis of wildfly-8.1.0 dependency on > >> JDK-Internal APIs > >> > >> Hi Rebecca, > >> > >> Not yet, we have a long list of FOSS Projects which we are targeting and I > >> can't say when we will get to it. In the mean time the tool is available > >> here: > >> > >> https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool > >> > >> Feel free to run it yourself and post results. > >> > >> Rgds,Rory > >> > >> > >> On 16/09/2014 16:08, Rebecca Searls wrote: > >>> Has Oracle run the tool on apache's CXF project? > >>> > >>> ----- Original Message ----- > >>>> From: "Rory O'Donnell Oracle, Dublin Ireland" > >>>> To: "Toma? Cerar" > >>>> Cc: "Norman Maurer" , "Balchandra Vaidya" > >>>> , > >>>> wildfly-dev at lists.jboss.org, "Dalibor Topic" > >>>> Sent: Thursday, September 11, 2014 10:33:44 AM > >>>> Subject: [wildfly-dev] Analysis of wildfly-8.1.0 dependency on > >>>> JDK-Internal APIs > >>>> > >>>> Hi Tomaz, > >>>> > >>>> As part of the preparations for JDK 9, Oracle?s engineers have been > >>>> analyzing open source projects like yours to understand usage. > >>>> One area of concern involves identifying compatibility problems, such as > >>>> reliance on JDK-internal APIs. > >>>> > >>>> Our engineers have already prepared guidance on migrating some of the > >>>> more common usage patterns of JDK-internal APIs to supported public > >>>> interfaces. The list is on the OpenJDK wiki [0], along with instructions > >>>> on how to run the jdeps analysis tool yourself . > >>>> > >>>> As part of the ongoing development of JDK 9, I would like to encourage > >>>> migration from JDK-internal APIs towards the supported Java APIs. I have > >>>> prepared a report for your project wildfly-8.1.0 release based on the > >>>> jdeps output. > >>>> > >>>> The report is attached to this e-mail. > >>>> > >>>> For anything where your migration path is unclear, I would appreciate > >>>> comments on the JDK-internal API usage patterns in the attached jdeps > >>>> report, (if any) - in particular comments elaborating on the rationale > >>>> for them - either to me or on this list. > >>>> > >>>> Finding suitable replacements for unsupported interfaces is not always > >>>> straightforward, which is why I am reaching out to you early in the JDK > >>>> 9 development cycle so you can give feedback about new APIs that may be > >>>> needed to facilitate this exercise. > >>>> > >>>> Thank you in advance for any efforts and feedback helping us make JDK 9 > >>>> better. > >>>> > >>>> Rgds,Rory > >>>> > >>>> [0] > >>>> https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool > >>>> > >>>> -- > >>>> Rgds,Rory O'Donnell > >>>> Quality Engineering Manager > >>>> Oracle EMEA , Dublin, Ireland > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> wildfly-dev mailing list > >>>> wildfly-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >> -- > >> Rgds,Rory O'Donnell > >> Quality Engineering Manager > >> Oracle EMEA , Dublin, Ireland > >> > >> > >> > >> > >> > > From hbraun at redhat.com Fri Sep 19 04:12:16 2014 From: hbraun at redhat.com (Heiko Braun) Date: Fri, 19 Sep 2014 10:12:16 +0200 Subject: [wildfly-dev] Cassandra Subsystem In-Reply-To: <53FCA973.5050203@redhat.com> References: <78CCAB36-F425-4633-8336-5053914CCFFA@redhat.com> <53FC874F.9000804@redhat.com> <43D71725-DCDF-44BA-9A33-DFBE19EA8BCE@redhat.com> <53FCA973.5050203@redhat.com> Message-ID: <3EC6E3DE-159A-40F8-B8CE-4B8267339041@redhat.com> David, I've been thinking more about your proposal to treat the cassandra daemon as a subprocess. Currently the cassandra dependencies are installed along side the module. How would I pass the classpath to the subprocess? Is there a way to get to the CP, similar to the way an URLClassLoader exposes it? Or how could it be achieved with JBoss modules? /Heiko On 26 Aug 2014, at 17:36, David M. Lloyd wrote: > Yeah, you could have a service that controls the cassandra daemon as a > service and uses whatever its default network API is for communications. > This should be safe and reliable as of JDK 7. > > Just a suggestion in case embedding becomes an untenable proposition. > > On 8/26/14, 8:23 AM, Heiko Braun wrote: >> >> >> Not sure I can follow. Do you refer to the System.exit() calls? >> >> On 26 Aug 2014, at 15:10, David M. Lloyd > > wrote: >> >>> One possible option might be to run it as a subprocess. >> > > > -- > - DML > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From david.lloyd at redhat.com Fri Sep 19 08:52:25 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 19 Sep 2014 07:52:25 -0500 Subject: [wildfly-dev] Cassandra Subsystem In-Reply-To: <3EC6E3DE-159A-40F8-B8CE-4B8267339041@redhat.com> References: <78CCAB36-F425-4633-8336-5053914CCFFA@redhat.com> <53FC874F.9000804@redhat.com> <43D71725-DCDF-44BA-9A33-DFBE19EA8BCE@redhat.com> <53FCA973.5050203@redhat.com> <3EC6E3DE-159A-40F8-B8CE-4B8267339041@redhat.com> Message-ID: <541C2709.20808@redhat.com> Well, I have a bias of course, but it seems to me like you could just add Cassandra and its dependencies as modules and then launch it like this: String javaHome = System.getProperty("java.home"); ProcessBuilder pb = new ProcssBuilder( javaHome + File.pathSeparator + "bin" + File.pathSeparator + "java", ...jvm args..., "-jar", "jboss-modules.jar", "-mp", "modules", "org.whatever.cassandra", ...cassandra args...); ...set up I/O redirection here... Process p = pb.start(); On 09/19/2014 03:12 AM, Heiko Braun wrote: > > > David, > > I've been thinking more about your proposal to treat the cassandra daemon as a subprocess. Currently the cassandra dependencies are installed along side the module. How would I pass the classpath to the subprocess? Is there a way to get to the CP, similar to the way an URLClassLoader exposes it? Or how could it be achieved with JBoss modules? > > /Heiko > > On 26 Aug 2014, at 17:36, David M. Lloyd wrote: > >> Yeah, you could have a service that controls the cassandra daemon as a >> service and uses whatever its default network API is for communications. >> This should be safe and reliable as of JDK 7. >> >> Just a suggestion in case embedding becomes an untenable proposition. >> >> On 8/26/14, 8:23 AM, Heiko Braun wrote: >>> >>> >>> Not sure I can follow. Do you refer to the System.exit() calls? >>> >>> On 26 Aug 2014, at 15:10, David M. Lloyd >> > wrote: >>> >>>> One possible option might be to run it as a subprocess. >>> >> >> >> -- >> - DML >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- - DML From hbraun at redhat.com Fri Sep 19 08:57:21 2014 From: hbraun at redhat.com (Heiko Braun) Date: Fri, 19 Sep 2014 14:57:21 +0200 Subject: [wildfly-dev] Cassandra Subsystem In-Reply-To: <541C2709.20808@redhat.com> References: <78CCAB36-F425-4633-8336-5053914CCFFA@redhat.com> <53FC874F.9000804@redhat.com> <43D71725-DCDF-44BA-9A33-DFBE19EA8BCE@redhat.com> <53FCA973.5050203@redhat.com> <3EC6E3DE-159A-40F8-B8CE-4B8267339041@redhat.com> <541C2709.20808@redhat.com> Message-ID: <993FFA8A-9D0F-4711-A2F5-2FE6220DACCC@redhat.com> It's not my preferred solution, but something to explore. At the same time I talking to the apache folks if we can get rid of the System.exit() call in C*. Which they seem to consider a good thing too. But thanks for the pointers, I'll have a look. Bootstrapping modules like we do it for WF didn't come to my mind. Regards, Heiko On 19 Sep 2014, at 14:52, David M. Lloyd wrote: > Well, I have a bias of course, but it seems to me like you could just > add Cassandra and its dependencies as modules and then launch it like this: > > String javaHome = System.getProperty("java.home"); > ProcessBuilder pb = new ProcssBuilder( > javaHome + File.pathSeparator + "bin" + File.pathSeparator + "java", > ...jvm args..., > "-jar", > "jboss-modules.jar", > "-mp", > "modules", > "org.whatever.cassandra", > ...cassandra args...); > ...set up I/O redirection here... > Process p = pb.start(); > > On 09/19/2014 03:12 AM, Heiko Braun wrote: >> >> >> David, >> >> I've been thinking more about your proposal to treat the cassandra daemon as a subprocess. Currently the cassandra dependencies are installed along side the module. How would I pass the classpath to the subprocess? Is there a way to get to the CP, similar to the way an URLClassLoader exposes it? Or how could it be achieved with JBoss modules? >> >> /Heiko >> >> On 26 Aug 2014, at 17:36, David M. Lloyd wrote: >> >>> Yeah, you could have a service that controls the cassandra daemon as a >>> service and uses whatever its default network API is for communications. >>> This should be safe and reliable as of JDK 7. >>> >>> Just a suggestion in case embedding becomes an untenable proposition. >>> >>> On 8/26/14, 8:23 AM, Heiko Braun wrote: >>>> >>>> >>>> Not sure I can follow. Do you refer to the System.exit() calls? >>>> >>>> On 26 Aug 2014, at 15:10, David M. Lloyd >>> > wrote: >>>> >>>>> One possible option might be to run it as a subprocess. >>>> >>> >>> >>> -- >>> - DML >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > -- > - DML > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From smarlow at redhat.com Fri Sep 19 10:00:28 2014 From: smarlow at redhat.com (Scott Marlow) Date: Fri, 19 Sep 2014 10:00:28 -0400 Subject: [wildfly-dev] Cassandra Subsystem In-Reply-To: <993FFA8A-9D0F-4711-A2F5-2FE6220DACCC@redhat.com> References: <78CCAB36-F425-4633-8336-5053914CCFFA@redhat.com> <53FC874F.9000804@redhat.com> <43D71725-DCDF-44BA-9A33-DFBE19EA8BCE@redhat.com> <53FCA973.5050203@redhat.com> <3EC6E3DE-159A-40F8-B8CE-4B8267339041@redhat.com> <541C2709.20808@redhat.com> <993FFA8A-9D0F-4711-A2F5-2FE6220DACCC@redhat.com> Message-ID: <541C36FC.1020006@redhat.com> Even if System.exit() isn't called, the process can still terminate for other reasons. How do you want to handle a Cassandra process termination? Perhaps log the error and retry starting it a certain number of times (with maybe a time threshold on how many times to restart)? Do we have logic like this elsewhere? IMO, we should also read the Cassandra process output so that it doesn't stay in memory. On 09/19/2014 08:57 AM, Heiko Braun wrote: > It's not my preferred solution, but something to explore. At the same time I talking to the apache folks if we can get rid of the System.exit() call in C*. Which they seem to consider a good thing too. > > But thanks for the pointers, I'll have a look. Bootstrapping modules like we do it for WF didn't come to my mind. > > Regards, Heiko > > On 19 Sep 2014, at 14:52, David M. Lloyd wrote: > >> Well, I have a bias of course, but it seems to me like you could just >> add Cassandra and its dependencies as modules and then launch it like this: >> >> String javaHome = System.getProperty("java.home"); >> ProcessBuilder pb = new ProcssBuilder( >> javaHome + File.pathSeparator + "bin" + File.pathSeparator + "java", >> ...jvm args..., >> "-jar", >> "jboss-modules.jar", >> "-mp", >> "modules", >> "org.whatever.cassandra", >> ...cassandra args...); >> ...set up I/O redirection here... >> Process p = pb.start(); >> >> On 09/19/2014 03:12 AM, Heiko Braun wrote: >>> >>> >>> David, >>> >>> I've been thinking more about your proposal to treat the cassandra daemon as a subprocess. Currently the cassandra dependencies are installed along side the module. How would I pass the classpath to the subprocess? Is there a way to get to the CP, similar to the way an URLClassLoader exposes it? Or how could it be achieved with JBoss modules? >>> >>> /Heiko >>> >>> On 26 Aug 2014, at 17:36, David M. Lloyd wrote: >>> >>>> Yeah, you could have a service that controls the cassandra daemon as a >>>> service and uses whatever its default network API is for communications. >>>> This should be safe and reliable as of JDK 7. >>>> >>>> Just a suggestion in case embedding becomes an untenable proposition. >>>> >>>> On 8/26/14, 8:23 AM, Heiko Braun wrote: >>>>> >>>>> >>>>> Not sure I can follow. Do you refer to the System.exit() calls? >>>>> >>>>> On 26 Aug 2014, at 15:10, David M. Lloyd >>>> > wrote: >>>>> >>>>>> One possible option might be to run it as a subprocess. >>>>> >>>> >>>> >>>> -- >>>> - DML >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> >> -- >> - DML >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From david.lloyd at redhat.com Fri Sep 19 10:45:11 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 19 Sep 2014 09:45:11 -0500 Subject: [wildfly-dev] Cassandra Subsystem In-Reply-To: <541C36FC.1020006@redhat.com> References: <78CCAB36-F425-4633-8336-5053914CCFFA@redhat.com> <53FC874F.9000804@redhat.com> <43D71725-DCDF-44BA-9A33-DFBE19EA8BCE@redhat.com> <53FCA973.5050203@redhat.com> <3EC6E3DE-159A-40F8-B8CE-4B8267339041@redhat.com> <541C2709.20808@redhat.com> <993FFA8A-9D0F-4711-A2F5-2FE6220DACCC@redhat.com> <541C36FC.1020006@redhat.com> Message-ID: <541C4177.2020103@redhat.com> Indeed, when you define a service to control the process, the lifecycle of the process should not be tied to the service. Instead, the service represents the desire to have the process running. A dedicated reaper thread with a small (32k? maybe less on 32-bit?) stack should be established to waitFor() and re-create the process (with a short/configurable delay to avoid overloading the system). If you want to capture stdout and stderr, one small-stack thread each should be created for each to capture the process output and feed it to the logging layer. Alternatively, they can be combined by ProcessBuilder so you only need one thread (though the output might be intermixed). Pooled threads generally are not a good fit for this application. Daemon threads should not be used, as that might provide more opportunity for the JVM to exit before the child process has been shut down. In JDK 9, there will likely be options to force child processes to terminate when the parent terminates, but we do not yet have this capability available unfortunately, so we must live with this limit of what we can do to avoid misadventure. The input stream to the process must be managed so the process never hangs waiting for input. This could be as simple as closing the stream immediately on start. The reaper thread should be cleanly managed to ensure deterministic shutdown of the process on service stop(). This can be done through the application of a (volatile) stop flag and thread interruption, combined with async service stop, which the reaper thread would invoke upon exit. Because you need an async service stop context to stop the thread, you could use a field of this type as the stop flag; if null, then no stop is requested. Maybe a ProcessManagementService would be a good addition to MSC... On 09/19/2014 09:00 AM, Scott Marlow wrote: > Even if System.exit() isn't called, the process can still terminate for > other reasons. How do you want to handle a Cassandra process > termination? Perhaps log the error and retry starting it a certain > number of times (with maybe a time threshold on how many times to > restart)? Do we have logic like this elsewhere? > > IMO, we should also read the Cassandra process output so that it doesn't > stay in memory. > > On 09/19/2014 08:57 AM, Heiko Braun wrote: >> It's not my preferred solution, but something to explore. At the same >> time I talking to the apache folks if we can get rid of the >> System.exit() call in C*. Which they seem to consider a good thing too. >> >> But thanks for the pointers, I'll have a look. Bootstrapping modules >> like we do it for WF didn't come to my mind. >> >> Regards, Heiko >> >> On 19 Sep 2014, at 14:52, David M. Lloyd wrote: >> >>> Well, I have a bias of course, but it seems to me like you could just >>> add Cassandra and its dependencies as modules and then launch it like >>> this: >>> >>> String javaHome = System.getProperty("java.home"); >>> ProcessBuilder pb = new ProcssBuilder( >>> javaHome + File.pathSeparator + "bin" + File.pathSeparator + "java", >>> ...jvm args..., >>> "-jar", >>> "jboss-modules.jar", >>> "-mp", >>> "modules", >>> "org.whatever.cassandra", >>> ...cassandra args...); >>> ...set up I/O redirection here... >>> Process p = pb.start(); >>> >>> On 09/19/2014 03:12 AM, Heiko Braun wrote: >>>> >>>> >>>> David, >>>> >>>> I've been thinking more about your proposal to treat the cassandra >>>> daemon as a subprocess. Currently the cassandra dependencies are >>>> installed along side the module. How would I pass the classpath to >>>> the subprocess? Is there a way to get to the CP, similar to the way >>>> an URLClassLoader exposes it? Or how could it be achieved with JBoss >>>> modules? >>>> >>>> /Heiko >>>> >>>> On 26 Aug 2014, at 17:36, David M. Lloyd >>>> wrote: >>>> >>>>> Yeah, you could have a service that controls the cassandra daemon as a >>>>> service and uses whatever its default network API is for >>>>> communications. >>>>> This should be safe and reliable as of JDK 7. >>>>> >>>>> Just a suggestion in case embedding becomes an untenable proposition. >>>>> >>>>> On 8/26/14, 8:23 AM, Heiko Braun wrote: >>>>>> >>>>>> >>>>>> Not sure I can follow. Do you refer to the System.exit() calls? >>>>>> >>>>>> On 26 Aug 2014, at 15:10, David M. Lloyd >>>>> > wrote: >>>>>> >>>>>>> One possible option might be to run it as a subprocess. >>>>>> >>>>> >>>>> >>>>> -- >>>>> - DML >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>> >>> -- >>> - DML >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > -- - DML From jperkins at redhat.com Fri Sep 19 17:24:03 2014 From: jperkins at redhat.com (James R. Perkins) Date: Fri, 19 Sep 2014 14:24:03 -0700 Subject: [wildfly-dev] Cassandra Subsystem In-Reply-To: <541C2709.20808@redhat.com> References: <78CCAB36-F425-4633-8336-5053914CCFFA@redhat.com> <53FC874F.9000804@redhat.com> <43D71725-DCDF-44BA-9A33-DFBE19EA8BCE@redhat.com> <53FCA973.5050203@redhat.com> <3EC6E3DE-159A-40F8-B8CE-4B8267339041@redhat.com> <541C2709.20808@redhat.com> Message-ID: <541C9EF3.1080600@redhat.com> With Java 7 you can inherit the I/O too so you don't have to consume it. pb.inheritIO(); On 09/19/2014 05:52 AM, David M. Lloyd wrote: > Well, I have a bias of course, but it seems to me like you could just > add Cassandra and its dependencies as modules and then launch it like this: > > String javaHome = System.getProperty("java.home"); > ProcessBuilder pb = new ProcssBuilder( > javaHome + File.pathSeparator + "bin" + File.pathSeparator + "java", > ...jvm args..., > "-jar", > "jboss-modules.jar", > "-mp", > "modules", > "org.whatever.cassandra", > ...cassandra args...); > ...set up I/O redirection here... > Process p = pb.start(); > > On 09/19/2014 03:12 AM, Heiko Braun wrote: >> >> David, >> >> I've been thinking more about your proposal to treat the cassandra daemon as a subprocess. Currently the cassandra dependencies are installed along side the module. How would I pass the classpath to the subprocess? Is there a way to get to the CP, similar to the way an URLClassLoader exposes it? Or how could it be achieved with JBoss modules? >> >> /Heiko >> >> On 26 Aug 2014, at 17:36, David M. Lloyd wrote: >> >>> Yeah, you could have a service that controls the cassandra daemon as a >>> service and uses whatever its default network API is for communications. >>> This should be safe and reliable as of JDK 7. >>> >>> Just a suggestion in case embedding becomes an untenable proposition. >>> >>> On 8/26/14, 8:23 AM, Heiko Braun wrote: >>>> >>>> Not sure I can follow. Do you refer to the System.exit() calls? >>>> >>>> On 26 Aug 2014, at 15:10, David M. Lloyd >>> > wrote: >>>> >>>>> One possible option might be to run it as a subprocess. >>> >>> -- >>> - DML >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev -- James R. Perkins JBoss by Red Hat From rory.odonnell at oracle.com Mon Sep 22 03:34:29 2014 From: rory.odonnell at oracle.com (Rory O'Donnell Oracle, Dublin Ireland) Date: Mon, 22 Sep 2014 08:34:29 +0100 Subject: [wildfly-dev] Early Access builds for JDK 9 b31 and JDK 8u40 b06 are available on java.net Message-ID: <541FD105.4000709@oracle.com> Hi Guys, Early Access build for JDK 9 b31 is available on java.net, summary of changes are listed here Early Access build for JDK 8u40 b06 is available on java.net, summary of changes are listed here. 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/20140922/79db252b/attachment.html From tsegismo at redhat.com Mon Sep 22 10:29:18 2014 From: tsegismo at redhat.com (Thomas Segismont) Date: Mon, 22 Sep 2014 16:29:18 +0200 Subject: [wildfly-dev] JAR scanning Message-ID: <5420323E.4030209@redhat.com> Hi everyone, In RHQ I need a way to list my domain classes at runtime (when preparing the CLI environment for execution, but that's another story). In the past, for the same issue with another project, I did something like looking for the persistence.xml file in the classpath and then scan the JAR where it is found. I wonder if there's something I could re-use from our EAP6.3-alpha base. Any idea? Thanks, Thomas From jason.greene at redhat.com Mon Sep 22 10:53:34 2014 From: jason.greene at redhat.com (Jason Greene) Date: Mon, 22 Sep 2014 09:53:34 -0500 Subject: [wildfly-dev] JAR scanning In-Reply-To: <5420323E.4030209@redhat.com> References: <5420323E.4030209@redhat.com> Message-ID: <8C394B52-5DA8-4DC8-8D95-31E37580CA6C@redhat.com> You can do a similar technique. Load a file in your deployment via getResource on a clasloader. Then you will get a VFS uri. If you convert it to a URL and call openContent on it you will get a VFS VirtualFile, and then using that you can browse anything int he deployment. On Sep 22, 2014, at 9:29 AM, Thomas Segismont wrote: > Hi everyone, > > In RHQ I need a way to list my domain classes at runtime (when preparing > the CLI environment for execution, but that's another story). > > In the past, for the same issue with another project, I did something > like looking for the persistence.xml file in the classpath and then scan > the JAR where it is found. > > I wonder if there's something I could re-use from our EAP6.3-alpha base. > Any idea? > > Thanks, > Thomas > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From brian.stansberry at redhat.com Mon Sep 22 10:55:36 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 22 Sep 2014 09:55:36 -0500 Subject: [wildfly-dev] Automatically resolving expressions in the CLI In-Reply-To: <53C6C299.3000102@redhat.com> References: <924955857.34071548.1403779269224.JavaMail.zimbra@redhat.com> <53AD83A4.10004@redhat.com> <53AD8D3D.1020301@redhat.com> <9465014.839.1404711377103.JavaMail.joe@dhcp-17-61.nay.redhat.com> <53BADC94.8060705@redhat.com> <17231034.1110.1404819425495.JavaMail.joe@dhcp-17-61.nay.redhat.com> <53BBF1BB.5040704@redhat.com> <53BC028D.7050904@redhat.com> <18410210.421.1405482037565.JavaMail.joe@dhcp-17-61.nay.redhat.com> <53C6C299.3000102@redhat.com> Message-ID: <54203868.30106@redhat.com> On 7/16/14, 1:21 PM, Brian Stansberry wrote: > On 7/15/14, 10:40 PM, Edward Wertz wrote: >> I've got a better broad solution to this now, but I'm having some trouble figuring out how to create limitations on the functionality. >> >> I added a 'resolve-expressions' parameter to ':read-attribute', which can enable the handler to simply call ModelNode.resolve() on the return value and replace all the expressions with their runtime values from that server. > > I assume you're referring to server-side handler, > org.jboss.as.controller.operations.global.ReadAttributeHandler? > > You can't resolve expressions by calling ModelNode.resolve(), as that > doesn't account for all the resolution sources available in a WildFly > process, e.g. the security vault. An OperationStepHandler would do it > via OperationContext.resolveExpressions(). > FYI, folks, Joe has done great work on this and has also been very patient! See [1] which I hope to merge in the next day or so. I was a bit off base in my last comment above. I don't actually want to bring the security vault into the resolution process. The really nice article on the vault by mentallurg at [2] outlines the theory of the vault nicely. The whole point is the expression can be publicly available, e.g. in the config file which might get passed around. But to learn a secret you must have access to the vault itself, and that is a carefully protected file. Allowing a remote management client to read the vault via this feature defeats the whole point. We don't let the existing :resolve-expression op do this. I don't think our security schemes are such that we can say that just because a user is an authorized WildFly admin (even an RBAC SuperUser) that they are privileged in the user organization to read their vault. This isn't a difficult issue to deal with though; a simple added commit on Joe's work takes care of it. [1] https://github.com/wildfly/wildfly-core/pull/192 [2] https://developer.jboss.org/docs/DOC-48166 -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From eduardo.santanadasilva at gmail.com Mon Sep 22 11:05:21 2014 From: eduardo.santanadasilva at gmail.com (Eduardo Sant'Ana da Silva) Date: Mon, 22 Sep 2014 12:05:21 -0300 Subject: [wildfly-dev] JAR scanning In-Reply-To: <8C394B52-5DA8-4DC8-8D95-31E37580CA6C@redhat.com> References: <5420323E.4030209@redhat.com> <8C394B52-5DA8-4DC8-8D95-31E37580CA6C@redhat.com> Message-ID: <4B80ADD4-B9DD-4B3A-9F53-4FB913525F38@gmail.com> URI uri = getURI("/test.rar"); final VirtualFile virtualFile = VFS.getChild(uri); final Indexer indexer = new Indexer(); final List classChildren = virtualFile.getChildren(new SuffixMatchFilter(".class", VisitorAttributes.RECURSE_LEAVES_ONLY)); for (VirtualFile classFile : classChildren) { InputStream inputStream = null; try { inputStream = classFile.openStream(); indexer.index(inputStream); } finally { VFSUtils.safeClose(inputStream); } } On Sep 22, 2014, at 11:53 AM, Jason Greene wrote: > You can do a similar technique. Load a file in your deployment via getResource on a clasloader. Then you will get a VFS uri. If you convert it to a URL and call openContent on it you will get a VFS VirtualFile, and then using that you can browse anything int he deployment. > > > On Sep 22, 2014, at 9:29 AM, Thomas Segismont wrote: > >> Hi everyone, >> >> In RHQ I need a way to list my domain classes at runtime (when preparing >> the CLI environment for execution, but that's another story). >> >> In the past, for the same issue with another project, I did something >> like looking for the persistence.xml file in the classpath and then scan >> the JAR where it is found. >> >> I wonder if there's something I could re-use from our EAP6.3-alpha base. >> Any idea? >> >> Thanks, >> Thomas >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140922/43b7e359/attachment.html From jason.greene at redhat.com Mon Sep 22 11:23:57 2014 From: jason.greene at redhat.com (Jason Greene) Date: Mon, 22 Sep 2014 10:23:57 -0500 Subject: [wildfly-dev] JAR scanning In-Reply-To: <4B80ADD4-B9DD-4B3A-9F53-4FB913525F38@gmail.com> References: <5420323E.4030209@redhat.com> <8C394B52-5DA8-4DC8-8D95-31E37580CA6C@redhat.com> <4B80ADD4-B9DD-4B3A-9F53-4FB913525F38@gmail.com> Message-ID: <350AB73E-2591-4CAD-A758-1087BFF98A73@redhat.com> Yeah something like that. Although I just want to stress the importance of using the ClassLoader for the deployment, as due to a historical oversight the path is different between windows and unix. On Sep 22, 2014, at 10:05 AM, Eduardo Sant'Ana da Silva wrote: > > URI uri = getURI("/test.rar"); > final VirtualFile virtualFile = VFS.getChild(uri); > final Indexer indexer = new Indexer(); > final List classChildren = virtualFile.getChildren(new SuffixMatchFilter(".class", > VisitorAttributes.RECURSE_LEAVES_ONLY)); > for (VirtualFile classFile : classChildren) { > InputStream inputStream = null; > try { > inputStream = classFile.openStream(); > indexer.index(inputStream); > } finally { > VFSUtils.safeClose(inputStream); > } > } > > > On Sep 22, 2014, at 11:53 AM, Jason Greene wrote: > >> You can do a similar technique. Load a file in your deployment via getResource on a clasloader. Then you will get a VFS uri. If you convert it to a URL and call openContent on it you will get a VFS VirtualFile, and then using that you can browse anything int he deployment. >> >> >> On Sep 22, 2014, at 9:29 AM, Thomas Segismont wrote: >> >>> Hi everyone, >>> >>> In RHQ I need a way to list my domain classes at runtime (when preparing >>> the CLI environment for execution, but that's another story). >>> >>> In the past, for the same issue with another project, I did something >>> like looking for the persistence.xml file in the classpath and then scan >>> the JAR where it is found. >>> >>> I wonder if there's something I could re-use from our EAP6.3-alpha base. >>> Any idea? >>> >>> Thanks, >>> Thomas >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> -- >> Jason T. Greene >> WildFly Lead / JBoss EAP Platform Architect >> JBoss, a division of Red Hat >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From tomaz.cerar at gmail.com Mon Sep 22 11:29:07 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Mon, 22 Sep 2014 17:29:07 +0200 Subject: [wildfly-dev] Changes to WildFly pull request testing Message-ID: Hi guys, As most of you already noticed we started testing wildfly-core pull requests on both Linux and Windows build agents few weeks back. Since than we ironed out few remaining problems, added few more windows agents and started working on enabling testing this kind of testing also for WildFly pull requests. As of today also all pull requests (or retests) for WildFly will be tested on both platforms. How does all this work? We now have 3 separate CI jobs for each repository acting as part of build chain - one for linux build - one for windows build - one aggregate job Build is first started for given feature branch (pull request number) on aggregate job which than uses chain build to start linux & windows job simultaneously while the aggregate jobs is waiting in queue for both jobs to complete. When both jobs complete successfully then also aggregate job will start and immediately complete with success status which will be posted as result to pull request. If any of the jobs fail then aggregate will fail with message like "Snapshot dependency failed: WildFly :: Pull Request :: Windows" in case that windows job had test failures. On pull requests you open you will now see 3 different messages posted, each one prefixed with a platform where job is running. This way you can know that job/tests only failed/passed on linux or windows. Guys among you that have rights to manually start pull request jobs on brones directly I have just few advices, if you want to test only on one platform, then open build for platform you want to test and find the proper feature branch (PR number) and run it. If you want to test both platforms do that via agregate job. For easier overview pull request jobs have been moved to a sub project for both WildFly and WildFly core project in teamcity. As many of you have asked about what kind of OS/HW config do build agents have: - Linux agents have 4gb ram and 2 vCPUs and are running CentOS 6.5 x64 - Windows agents have 4gb ram and 2-4 vCPUs and are running Windows Server 2012R2 x64 In following weeks there will be few more windows agents added to the build pool, how many will be decided based on how much currrent are utilized. If you see any problems let me know. cheers, tomaz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140922/88504037/attachment.html From tsegismo at redhat.com Tue Sep 23 03:32:02 2014 From: tsegismo at redhat.com (Thomas Segismont) Date: Tue, 23 Sep 2014 09:32:02 +0200 Subject: [wildfly-dev] JAR scanning In-Reply-To: <350AB73E-2591-4CAD-A758-1087BFF98A73@redhat.com> References: <5420323E.4030209@redhat.com> <8C394B52-5DA8-4DC8-8D95-31E37580CA6C@redhat.com> <4B80ADD4-B9DD-4B3A-9F53-4FB913525F38@gmail.com> <350AB73E-2591-4CAD-A758-1087BFF98A73@redhat.com> Message-ID: <542121F2.8080800@redhat.com> Hi, Le 22/09/2014 17:23, Jason Greene a ?crit : > Yeah something like that. Although I just want to stress the importance of using the ClassLoader for the deployment, as due to a historical oversight the path is different between windows and unix. Understood. For the record: getClass().getClassLoader().getResources("META-INF/persistence.xml"); Then: VirtualFile virtualFile = (VirtualFile) url.openConnection().getContent(); // up to the archive root virtualFile = virtualFile.getParent().getParent(); My index is correctly built and now I'm trying to find how I can read org.jboss.jandex.ClassInfo#flags to determine if the class is public. Thank you both for indications and the code snippet! Regards, Thomas From tsegismo at redhat.com Tue Sep 23 04:02:45 2014 From: tsegismo at redhat.com (Thomas Segismont) Date: Tue, 23 Sep 2014 10:02:45 +0200 Subject: [wildfly-dev] JAR scanning In-Reply-To: <542121F2.8080800@redhat.com> References: <5420323E.4030209@redhat.com> <8C394B52-5DA8-4DC8-8D95-31E37580CA6C@redhat.com> <4B80ADD4-B9DD-4B3A-9F53-4FB913525F38@gmail.com> <350AB73E-2591-4CAD-A758-1087BFF98A73@redhat.com> <542121F2.8080800@redhat.com> Message-ID: <54212925.7040603@redhat.com> Le 23/09/2014 09:32, Thomas Segismont a ?crit : > My index is correctly built and now I'm trying to find how I can read > org.jboss.jandex.ClassInfo#flags to determine if the class is public. The RHQ CLI requires javassist, so I have this available: javassist.bytecode.AccessFlag#isPublic Thank you both again. Cheers, Thomas From emartins at redhat.com Tue Sep 23 05:43:08 2014 From: emartins at redhat.com (Eduardo Martins) Date: Tue, 23 Sep 2014 10:43:08 +0100 Subject: [wildfly-dev] JBoss EAP and WildFly JNDI federation Message-ID: <1C756E82-DF56-4AEC-9346-74EF92C9ED20@redhat.com> FYI, I just published a blog post wrt JBoss EAP JNDI federation at http://blog-emmartins.rhcloud.com/2014/09/jboss-eap-jndi-federation Same applies to WildFly with some minor modifications. ?E From tomaz.cerar at gmail.com Tue Sep 23 05:47:47 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Tue, 23 Sep 2014 11:47:47 +0200 Subject: [wildfly-dev] JAR scanning In-Reply-To: <542121F2.8080800@redhat.com> References: <5420323E.4030209@redhat.com> <8C394B52-5DA8-4DC8-8D95-31E37580CA6C@redhat.com> <4B80ADD4-B9DD-4B3A-9F53-4FB913525F38@gmail.com> <350AB73E-2591-4CAD-A758-1087BFF98A73@redhat.com> <542121F2.8080800@redhat.com> Message-ID: Just for record if that is not sure. If this is deployment properly deployed in WildFly jandex index for it is automatically build for it during deploy time. If your code is in Extension(subsystem) it can register DeploymentUnitProcessor which can access this indexes during deployment. Otherwise if your code is run time only then what you are doing is the right way. -- tomaz On Tue, Sep 23, 2014 at 9:32 AM, Thomas Segismont wrote: > Hi, > > > Le 22/09/2014 17:23, Jason Greene a ?crit : > > Yeah something like that. Although I just want to stress the importance > of using the ClassLoader for the deployment, as due to a historical > oversight the path is different between windows and unix. > > Understood. For the record: > getClass().getClassLoader().getResources("META-INF/persistence.xml"); > > > Then: > > VirtualFile virtualFile = (VirtualFile) url.openConnection().getContent(); > // up to the archive root > virtualFile = virtualFile.getParent().getParent(); > > > My index is correctly built and now I'm trying to find how I can read > org.jboss.jandex.ClassInfo#flags to determine if the class is public. > > > Thank you both for indications and the code snippet! > > Regards, > Thomas > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140923/06d8daa8/attachment.html From tsegismo at redhat.com Tue Sep 23 06:06:03 2014 From: tsegismo at redhat.com (Thomas Segismont) Date: Tue, 23 Sep 2014 12:06:03 +0200 Subject: [wildfly-dev] JAR scanning In-Reply-To: References: <5420323E.4030209@redhat.com> <8C394B52-5DA8-4DC8-8D95-31E37580CA6C@redhat.com> <4B80ADD4-B9DD-4B3A-9F53-4FB913525F38@gmail.com> <350AB73E-2591-4CAD-A758-1087BFF98A73@redhat.com> <542121F2.8080800@redhat.com> Message-ID: <5421460B.6020703@redhat.com> Our CLI Alert Sender is not part of the RHQ extension. It's a plugin loaded by the RHQ EAR (so to speak). So yes, runtime only. Thanks, Thomas Le 23/09/2014 11:47, Toma? Cerar a ?crit : > Just for record if that is not sure. > If this is deployment properly deployed in WildFly jandex index for it > is automatically build for it during deploy time. > If your code is in Extension(subsystem) it can register > DeploymentUnitProcessor which can access this indexes during deployment. > > Otherwise if your code is run time only then what you are doing is the > right way. > > -- > tomaz > > On Tue, Sep 23, 2014 at 9:32 AM, Thomas Segismont > wrote: > > Hi, > > > Le 22/09/2014 17:23, Jason Greene a ?crit : > > Yeah something like that. Although I just want to stress the importance of using the ClassLoader for the deployment, as due to a historical oversight the path is different between windows and unix. > > Understood. For the record: > getClass().getClassLoader().getResources("META-INF/persistence.xml"); > > > Then: > > VirtualFile virtualFile = (VirtualFile) > url.openConnection().getContent(); > // up to the archive root > virtualFile = virtualFile.getParent().getParent(); > > > My index is correctly built and now I'm trying to find how I can read > org.jboss.jandex.ClassInfo#flags to determine if the class is public. > > > Thank you both for indications and the code snippet! > > Regards, > Thomas > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > From dandread at redhat.com Tue Sep 23 08:44:31 2014 From: dandread at redhat.com (Dimitris Andreadis) Date: Tue, 23 Sep 2014 14:44:31 +0200 Subject: [wildfly-dev] JBoss EAP and WildFly JNDI federation In-Reply-To: <1C756E82-DF56-4AEC-9346-74EF92C9ED20@redhat.com> References: <1C756E82-DF56-4AEC-9346-74EF92C9ED20@redhat.com> Message-ID: <54216B2F.20900@redhat.com> Nice blog Eduardo! /Dimitris On 23/09/2014 11:43, Eduardo Martins wrote: > FYI, I just published a blog post wrt JBoss EAP JNDI federation at > > http://blog-emmartins.rhcloud.com/2014/09/jboss-eap-jndi-federation > > Same applies to WildFly with some minor modifications. > > ?E > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From fjuma at redhat.com Tue Sep 23 09:36:42 2014 From: fjuma at redhat.com (Farah Juma) Date: Tue, 23 Sep 2014 09:36:42 -0400 (EDT) Subject: [wildfly-dev] WildFly 9.0.0.Alpha1 on OpenShift In-Reply-To: <1562513415.31825175.1411420759146.JavaMail.zimbra@redhat.com> Message-ID: <146225124.32022643.1411479402475.JavaMail.zimbra@redhat.com> The OpenShift WildFly cartridge has now been updated to provide support for WildFly 9.0.0.Alpha1 in addition to the existing support for 8.1.0.Final. For details on how to get started with Alpha1, check out the documentation here: https://github.com/openshift-cartridges/openshift-wildfly-cartridge/tree/wildfly-9 Enjoy! From arun.gupta at gmail.com Tue Sep 23 11:08:11 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Tue, 23 Sep 2014 08:08:11 -0700 Subject: [wildfly-dev] JBoss EAP and WildFly JNDI federation In-Reply-To: <1C756E82-DF56-4AEC-9346-74EF92C9ED20@redhat.com> References: <1C756E82-DF56-4AEC-9346-74EF92C9ED20@redhat.com> Message-ID: Great post Eduardo, promoted via @WildFlyAS and my twitter handle. Arun On Tue, Sep 23, 2014 at 2:43 AM, Eduardo Martins wrote: > FYI, I just published a blog post wrt JBoss EAP JNDI federation at > > http://blog-emmartins.rhcloud.com/2014/09/jboss-eap-jndi-federation > > Same applies to WildFly with some minor modifications. > > ?E > _______________________________________________ > 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 arun.gupta at gmail.com Tue Sep 23 15:43:23 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Tue, 23 Sep 2014 12:43:23 -0700 Subject: [wildfly-dev] WildFly 9.0.0.Alpha1 on OpenShift In-Reply-To: <146225124.32022643.1411479402475.JavaMail.zimbra@redhat.com> References: <1562513415.31825175.1411420759146.JavaMail.zimbra@redhat.com> <146225124.32022643.1411479402475.JavaMail.zimbra@redhat.com> Message-ID: Farah, Thanks a a lot for sharing this! My first WildFly 9 instance on OpenShift is now running at: http://wildfly9-milestogo.rhcloud.com :) And promoted using twitter. Thanks Arun On Tue, Sep 23, 2014 at 6:36 AM, Farah Juma wrote: > The OpenShift WildFly cartridge has now been updated to provide support for WildFly 9.0.0.Alpha1 in addition to the existing support for 8.1.0.Final. For details on how to get started with Alpha1, check out the documentation here: > > https://github.com/openshift-cartridges/openshift-wildfly-cartridge/tree/wildfly-9 > > Enjoy! > > _______________________________________________ > 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 Sep 23 16:24:35 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Tue, 23 Sep 2014 22:24:35 +0200 Subject: [wildfly-dev] [undertow-dev] single-sign-on and reauthenticate=false In-Reply-To: <2112134791.2490800.1411486140396.JavaMail.zimbra@redpill-linpro.com> References: <1952992066.2490670.1411485708619.JavaMail.zimbra@redpill-linpro.com> <2112134791.2490800.1411486140396.JavaMail.zimbra@redpill-linpro.com> Message-ID: This is discussion that is more appropriate for wildfly-dev mailing list. (cced now) On Tue, Sep 23, 2014 at 5:29 PM, Mattias Nilsson Grip < mattias.nilsson.grip at redpill-linpro.com> wrote: > Hi, > > I see in a commit message from February "Drop superfluous re-authenticate > attribute of ." > > Looks like re-authenticate=true is still the default behaviour? In > previous JBoss versions it was possible to use re-authenticate=false to do > single-sign-on for two web applications in different security domains > without the need to reauthenticate. What is the proper way to do that now? > Should we configure an identity provider? > > Regards, > Mattias > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140923/5e1e4992/attachment.html From brian.stansberry at redhat.com Wed Sep 24 08:59:20 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 24 Sep 2014 07:59:20 -0500 Subject: [wildfly-dev] profile cloning tool In-Reply-To: References: <53F1EBCC.8010505@redhat.com> <53F21601.50103@redhat.com> <53F21BF9.4070705@redhat.com> <53F21FA4.6040801@redhat.com> <53FC80E2.7050905@redhat.com> <53FC9A8F.6090100@redhat.com> <541852D1.7000808@redhat.com> <5418560D.7030403@redhat.com> <54199E53.4080704@redhat.com> <5419A693.4040103@redhat.com> <541ADF76.2070400@redhat.com> <541AE1BB.80608@redhat.com> <542043EC.4040100@redhat.com> <54205042.5020105@redhat.com> <5421298C.1000409@redhat.com> <54216365.1010008@redhat.com> <54216542.6060908@redhat.com> <5421C718.5080703@redhat.com> Message-ID: <5422C028.50509@redhat.com> Following is a discussion that started being about low level details on how to implement a particular feature and has instead morphed into a broader design discussion. So it seemed better to have it on the dev list. Dev list readers, sorry for the jump into the middle of something with no background. Heiko, The only connection to you is about the record/replay format, yes. Not just the format in a general sense though, but also architecturally where/how the conversion to that format is done. Which depends on what the format is and how it's used. The fundamental format is the native DMR format. If the only use cases the console has involve storing stuff for its own use, without user involvement, then you guys could stick with that. Once end users start dealing with recording and replay, we already have a format, in the form of CLI scripts, and a replay device, the CLI. These scripts are very commonly used. So for sure we are going to get requests to record stuff in CLI script form, at least from CLI users. If the console use cases also involve recording in the CLI format, then I think we should aim for a common code base for converting to/from that format. Maintain all the quoting and escaping stuff in one place. Deal with quirks there. For example, the CLI uses the 'batch' commands to encapsulate steps into a composite op. CLI users don't have to deal with the complex nesting involved in a raw DMR composite op. If that code is all maintained in one place, then the question is how does the console use it? Compile it in? Ask the server to do conversion for it? My mention of a generic op was about the latter. On 9/24/14, 2:15 AM, Heiko Braun wrote: > > > Apologies, I didn't really follow this thread. But one question comes to my mind: > > We always had requests for record/replay functionality. This ultimately boils down to the question what format the recorded operation should use. It seems to be related to questions Brian raised. Isn't that central data format part of both the profile cloning and the record/replay features? Do these two share anything else? > > > My 2 cents. > > On 23 Sep 2014, at 21:16, Brian Stansberry wrote: > >> I see. That's not the WFLY-1106 task though. WFLY-1106 is meant to be a live clone. Sorry if that wasn't clear. >> >> I've added Alexey and Heiko Braun in cc. >> >> I'm not comfortable with having the server directly create CLI scripts. Particularly writing a file. I think that belongs on the client side. >> >> Brainstorming a bit now... >> >> I also don't like returning CLI syntax as the response for anything but a single totally generic op. Not for something custom purpose like cloning. Over time we'd end up with a bunch of those kind of custom things, each added for some special purpose. >> >> I can, however, see a totally generic op being useful. We have, for example, console RFEs for outputing CLI scripts to correspond to what the console has done. Having a generic op the console could invoke to get back the necessary string *might* make sense. >> >> A facility like that could then be used by the CLI itself as part of a client-side solution to this kind of thing. >> >> Possibly whether to perform the live update could be a param to the clone op. Either way the return value of the op is the list of needed operations; the param simply controls whether the server applies them. >> >> If the live update isn't performed, the client can instead turn around and ask the server to translate the return value into CLI syntax. >> >> It would make more sense for the CLI to do that translation itself though. But the DMR->CLI logic it uses could be reused by the server for the generic op I mentioned. >> >> On 9/23/14, 7:19 AM, Tom Fonteyne wrote: >>> all customer are asking how to turn a profile into a CLI script. None >>> that I know are actually interested in a "live" clone. >>> >>> I started with a standalone client: >>> https://github.com/tfonteyn/profilecloner >>> >>> >>> On 23/09/14 13:11, Emanuel Muckenhuber wrote: >>>> Hi, >>>> >>>> i am not so sure whether writing those operations to a file and >>>> converting them to the CLI format makes much sense as part of the mgmt >>>> API in general. We don't have this concept anywhere in the mgmt API at >>>> the moment and only the CLI really understands (implements) the way >>>> commands are parsed on the client side. >>>> >>>> In particular i am concerned about having those workarounds for >>>> generating CLI scripts as part of the mgmt API contracts. This really >>>> should be a client side thing (if required), but i don't really know >>>> what the failures you were running into are. >>>> >>>> The ProfileCloneLiveHandler looks correct and having nested classes >>>> there seems to be totally fine. Speaking of composite operations, we >>>> should make sure to also test a composite operations cloning a profile >>>> and reading it as a 2nd step. I suspect this will cause some problems >>>> with the ordering of some handlers. >>>> >>>> I hope this helps and thanks, >>>> Emanuel >>>> >>>> On 23/09/14 10:04, Tom Fonteyne wrote: >>>>> >>>>> On 22/09/14 17:37, Brian Stansberry wrote: >>>>>> On 9/22/14, 10:44 AM, Tom Fonteyne wrote: >>>>>>> well... if it was not for some bugs in wildfly ... it would all work >>>>>>> now :) >>>>>>> >>>>>>> 1. PathAddress.pathAddress(node.require(OP_ADDR)).toCLIStyleString() >>>>>>> -> toCLIStyleString does not quote the value part >>>>>>> --> temp workaround, but I'll log a JIRA and do a pull-request >>>>>>> >>>>>> >>>>>> OK, but how is this relevant to this work? >>>>> writing the profile to a CLI file. For example without quoting: >>>>> >>>>> /profile=default/subsystem=undertow/server=default-server/host=default-host/location=/:add(handler="welcome-content") >>>>> >>>>> >>>>> => breaks as the value "/" is seen as an address separator. >>>>> Its no big deal as I just build the string myself for now. >>>>> >>>>> https://github.com/tfonteyn/wildfly-core/tree/WFLY-1106 >>>>> >>>>> modified: >>>>> controller/src/main/java/org/jboss/as/controller/descriptions/ModelDescriptionConstants.java >>>>> >>>>> >>>>> modified: >>>>> controller/src/main/java/org/jboss/as/controller/logging/ControllerLogger.java >>>>> >>>>> >>>>> modified: >>>>> host-controller/src/main/java/org/jboss/as/domain/controller/operations/ProfileCloneHandler.java >>>>> >>>>> >>>>> modified: >>>>> host-controller/src/main/java/org/jboss/as/domain/controller/resources/ProfileResourceDefinition.java >>>>> >>>>> >>>>> modified: >>>>> host-controller/src/main/resources/org/jboss/as/domain/controller/resources/LocalDescriptions.properties >>>>> >>>>> >>>>> >>>>> ProfileCloneHandler.java >>>>> >>>>> Look at private ProfileCloneLiveHandler class. >>>>> >>>>> Note I used a single java file with two internal classes - I wasn't sure >>>>> if there is a "contained" policy or if I should simply use 3 classes. >>>>> >>>>> All feedback is obviously very welcome. >>>>> >>>>> cheers >>>>> Tom >>>>> >>>>> >>>>>> >>>>>>> 2. The describe information for the transaction subsystem used as-is >>>>>>> does do the "add" but will in fact install broken xml >>>>>>> -> will investigate, then log JIRA >>>>>>> >>>>>>> 3. The datasource describe can be added, but fails to marchal its >>>>>>> config >>>>>>> to xml due to issues with the "driver-name" child >>>>>>> -> will investigate, then log JIRA >>>>>>> >>>>>>> 4. JGroups subsystem is problematic due to it's use of the >>>>>>> "add-protocol" command.In CLI you would do: >>>>>>> >>>>>>> /profile="test"/subsystem="jgroups"/stack="udp":add() >>>>>>> /profile="test"/subsystem="jgroups"/stack="udp":add-protocol(type="PING") >>>>>>> >>>>>>> >>>>>>> >>>>>>> but the ProfileAddHandler sees this as the same address (which it >>>>>>> is) and tells me "Duplicate resource" >>>>>>> In my humble opinion we should change that to: >>>>>>> /profile="test"/subsystem="jgroups"/stack="udp"/protocol=PING:add() >>>>>>> >>>>>>> Keep add-protocol for backwards compatibility, but let >>>>>>> "describe" use >>>>>>> a normal "add" >>>>>>> -> will log JIRA >>>>>>> >>>>>>> Other then that (ahum) cloning to a new profile works. >>>>>> >>>>>> Do you have a link to what you're doing? Having all these issues with >>>>>> "describe" sounds a bit odd. You wouldn't be able to boot a managed >>>>>> domain server if describe doesn't work. >>>>>> >>>>>>> Cloning to a file fully works. >>>>>>> >>>>>>> Kind regards >>>>>>> Tom >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 18/09/14 14:44, Emanuel Muckenhuber wrote: >>>>>>>> >>>>>>>> On 18/09/14 15:34, Tom Fonteyne wrote: >>>>>>>>> ok - part one is done and functioning well >>>>>>>>> I can now write the profile to a file as CLI commands >>>>>>>>> >>>>>>>>> second part is the live cloning option still todo. >>>>>>>>> >>>>>>>>> But I have a small issue left. The cloning to the file works >>>>>>>>> fine, and >>>>>>>>> yet despite setting >>>>>>>>> >>>>>>>>> context.getResult().set(SUCCESS); >>>>>>>> >>>>>>>> The outcome of the operation will be a success if the operation >>>>>>>> completes. The context.getResult() is the response i.e. a simple >>>>>>>> value >>>>>>>> for metrics or a more complex structure for the read-resource >>>>>>>> operation. >>>>>>>> >>>>>>>>> context.stepCompleted(); >>>>>>>>> >>>>>>>>> the operation says: >>>>>>>>> >>>>>>>>> [domain at localhost:9990 /] >>>>>>>>> /profile=full-ha:clone(file=/tmp/q2,profile-name=qq) >>>>>>>>> { >>>>>>>>> "outcome" => "failed", >>>>>>>>> "result" => "success", >>>>>>>>> "failure-description" => "WFLYCTL0159: Operation handler >>>>>>>>> failed to >>>>>>>>> complete", >>>>>>>>> "rolled-back" => true >>>>>>>>> } >>>>>>>>> >>>>>>>>> I presume that I need some sort of commit ? I did look at some other >>>>>>>>> handlers of course but I seem to miss it. >>>>>>>>> >>>>>>>> >>>>>>>> This just means there is a context.stepCompleted(); call missing for >>>>>>>> one of the stepHandlers and therefore the operation gets rolled back. >>>>>>>> This is easy to miss in particular for nested handlers. >>>>>>>> >>>>>>>> Emanuel >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> On 17/09/14 16:19, Emanuel Muckenhuber wrote: >>>>>>>>>> >>>>>>>>>> On 17/09/14 16:44, Tom Fonteyne wrote: >>>>>>>>>>> >>>>>>>>>>> I started on doing this but could use some doc's for those steps. >>>>>>>>>>> >>>>>>>>>>> I have so far: >>>>>>>>>>> - added "clone" with attributes >>>>>>>>>>> - registered the ProfileCloneHandler >>>>>>>>>>> - ProfileCloneHandler sets up the describe opp. >>>>>>>>>>> - must now execute it.... >>>>>>>>>>> >>>>>>>>>>> public void execute(OperationContext context, ModelNode operation) >>>>>>>>>>> throws OperationFailedException { >>>>>>>>>>> >>>>>>>>>>> ModelNode profileDescription = new ModelNode(); >>>>>>>>>>> ModelNode describeProfile = new ModelNode(); >>>>>>>>>>> describeProfile.get(OP).set(ModelDescriptionConstants.DESCRIBE); >>>>>>>>>>> describeProfile.get(OP_ADDR).set(address.toModelNode()); >>>>>>>>>>> >>>>>>>>>>> // is this correct ? will it execute the describe (and block while >>>>>>>>>>> doing >>>>>>>>>>> so) >>>>>>>>>>> context.addStep(profileDescription, describeProfile, >>>>>>>>>>> ProfileDescribeHandler.INSTANCE, OperationContext.Stage.MODEL); >>>>>>>>>>> >>>>>>>>>>> // I presume I can now take profileDescription and create file >>>>>>>>>>> and/or >>>>>>>>>>> new profile... >>>>>>>>>>> doBla(); >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> You would need to add another nested step to have access to the >>>>>>>>>> result >>>>>>>>>> of the describe operations. The context.addStep() is not >>>>>>>>>> blocking and >>>>>>>>>> just adds it to a queue of handlers which are executed after the >>>>>>>>>> current one finishes. >>>>>>>>>> >>>>>>>>>> In this step you should be able to get the resolved operations >>>>>>>>>> using >>>>>>>>>> profileDescription.get("result").asList() and would then need to >>>>>>>>>> get >>>>>>>>>> the operation handlers from the mgmt resource registration and add >>>>>>>>>> those as another step. So there are going to be a lot of nested >>>>>>>>>> steps ;) >>>>>>>>>> >>>>>>>>>>> // is this the last step before leaving execute, or should this be >>>>>>>>>>> done >>>>>>>>>>> to actually kick of the describe .. and should doBla() be done >>>>>>>>>>> *after* >>>>>>>>>>> this ? >>>>>>>>>>> >>>>>>>>>>> context.stepCompleted(); >>>>>>>>>>> >>>>>>>>>>> any good doc on StepHandler and related would be gladly >>>>>>>>>>> welcomed :) >>>>>>>>>>> >>>>>>>>>>> Kind regards >>>>>>>>>>> Tom >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 16/09/14 16:23, Brian Stansberry wrote: >>>>>>>>>>>> This time really bringing him into the loop. >>>>>>>>>>>> >>>>>>>>>>>> On 9/16/14, 10:10 AM, Brian Stansberry wrote: >>>>>>>>>>>>> Bringing Emanuel Muckenhuber into the loop. >>>>>>>>>>>>> >>>>>>>>>>>>> On 8/26/14, 9:32 AM, Brian Stansberry wrote: >>>>>>>>>>>>>> On 8/26/14, 7:43 AM, Tom Fonteyne wrote: >>>>>>>>>>>>>>> Hi Brian, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I've been digging into the relevant source (what else does >>>>>>>>>>>>>>> one do >>>>>>>>>>>>>>> on a >>>>>>>>>>>>>>> bank holiday Monday in the UK in the bleeping torrential >>>>>>>>>>>>>>> rain...) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I looked at: >>>>>>>>>>>>>>> org.jboss.as.domain.controller.resources.ProfileResourceDefinition >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> to add the "clone" command >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yep. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> (I do need to look at commands that take >>>>>>>>>>>>>>> arguments as well) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> org.jboss.as.controller.operations.global.WriteAttributeHandler >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I don't think this is relevant. You'd add a step that >>>>>>>>>>>>>> invokes the >>>>>>>>>>>>>> ProfileDescribeHandler and then take the output (a list of >>>>>>>>>>>>>> ops) and >>>>>>>>>>>>>> change the address of each op to the new profile name, and >>>>>>>>>>>>>> then add >>>>>>>>>>>>>> each >>>>>>>>>>>>>> of those steps. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> org.jboss.as.domain.controller.operations.ProfileDescribeHandler >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> on how to do this stephandler >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I wanted to start getting the command "working" but without >>>>>>>>>>>>>>> doing >>>>>>>>>>>>>>> anything >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Idiot questions: >>>>>>>>>>>>>>> - is the above the right way of tackling this ? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yes. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I presume the correct place to add a handler is in >>>>>>>>>>>>>>> "org.jboss.as.domain.controller.operations" >>>>>>>>>>>>>>> but that would mean clone is only on profile level (and >>>>>>>>>>>>>>> not for >>>>>>>>>>>>>>> example on datasource level) >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think that's fine to start. If you get a clone of an entire >>>>>>>>>>>>>> profile >>>>>>>>>>>>>> clone working, you'll learn a lot, we'll have something useful, >>>>>>>>>>>>>> and it >>>>>>>>>>>>>> should be straightforward enough to further advance that >>>>>>>>>>>>>> work to >>>>>>>>>>>>>> make it >>>>>>>>>>>>>> more generally useful. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> -> hopefully I'm wrong, but would a clone need to be >>>>>>>>>>>>>>> added to >>>>>>>>>>>>>>> every >>>>>>>>>>>>>>> single level ?? >>>>>>>>>>>>>> >>>>>>>>>>>>>> What I want to do later is add a 'copy' op to the root >>>>>>>>>>>>>> resource, >>>>>>>>>>>>>> which >>>>>>>>>>>>>> will take a source and target address. It can use the existing >>>>>>>>>>>>>> subsystem >>>>>>>>>>>>>> level describe ops to get anything related to subsystems. That >>>>>>>>>>>>>> would >>>>>>>>>>>>>> get >>>>>>>>>>>>>> more data than is needed if, say, cloning only a single >>>>>>>>>>>>>> datasource >>>>>>>>>>>>>> was >>>>>>>>>>>>>> the goal, but that's ok. I don't want to add any further >>>>>>>>>>>>>> requirement to >>>>>>>>>>>>>> subsystem authors to support this, so we'll rely on the >>>>>>>>>>>>>> existing >>>>>>>>>>>>>> 'describe' op. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> ... as a global operation would be out as "describe" >>>>>>>>>>>>>>> does >>>>>>>>>>>>>>> not >>>>>>>>>>>>>>> exist other then on profile (and sub-profile) >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yes, a 'describe'-like function for resources outside >>>>>>>>>>>>>> subsystems >>>>>>>>>>>>>> is a >>>>>>>>>>>>>> prerequisite for doing more than the profile clone op. But we >>>>>>>>>>>>>> can do >>>>>>>>>>>>>> that within core, without adding any requirement on subsystem >>>>>>>>>>>>>> authors. I >>>>>>>>>>>>>> don't know exactly when we'll be able to provide that for you, >>>>>>>>>>>>>> which is >>>>>>>>>>>>>> one reason I think starting with just the full profile clone >>>>>>>>>>>>>> makes >>>>>>>>>>>>>> sense. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> - how do I make wildfly use my newly build wild-fly core ? >>>>>>>>>>>>>>> I tried updating the pom to the new core version, but it >>>>>>>>>>>>>>> seems to >>>>>>>>>>>>>>> refuse to use the local copy >>>>>>>>>>>>>>> Note; I'm *not* good at maven :/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> You need the following in your command to maven: >>>>>>>>>>>>>> >>>>>>>>>>>>>> -Dversion.org.wildfly.core=1.0.0.Alpha6-SNAPSHOT >>>>>>>>>>>>>> -Dskip-enforce=true >>>>>>>>>>>>>> >>>>>>>>>>>>>> e.g. >>>>>>>>>>>>>> >>>>>>>>>>>>>> ./build.sh -Dversion.org.wildfly.core=1.0.0.Alpha6-SNAPSHOT >>>>>>>>>>>>>> -Dskip-enforce=true >>>>>>>>>>>>>> >>>>>>>>>>>>>> The first one is a general thing you can do to change a version >>>>>>>>>>>>>> from >>>>>>>>>>>>>> what's defined in the pom. If you look in the root pom.xml, >>>>>>>>>>>>>> there's a >>>>>>>>>>>>>> long properties section where the version of everything is >>>>>>>>>>>>>> defined. So >>>>>>>>>>>>>> that -D just overrides one of those property values. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The -Dskip-enforce=true turns of a validation thing that bans >>>>>>>>>>>>>> transitive >>>>>>>>>>>>>> dependencies. That validation just causes trouble when you are >>>>>>>>>>>>>> working >>>>>>>>>>>>>> with snapshots. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> - do I make any sense ? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yes. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> - is there any dev doc I can read on this subject ? >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> This doc is really about adding subsystems, but it's the only >>>>>>>>>>>>>> docs >>>>>>>>>>>>>> about >>>>>>>>>>>>>> writing handlers, etc: >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://docs.jboss.org/author/display/WFLY9/Extending+WildFly >>>>>>>>>>>>>> >>>>>>>>>>>>>> The biggest thing is to really understand the OperationContext >>>>>>>>>>>>>> interface, which is extensively javadoced. >>>>>>>>>>>>>> >>>>>>>>>>>>>> In particular, you need to understand the addStep methods, >>>>>>>>>>>>>> since >>>>>>>>>>>>>> the >>>>>>>>>>>>>> essence of what you are doing is adding steps and passing data >>>>>>>>>>>>>> back and >>>>>>>>>>>>>> forth between their handlers. A trick to understand is the >>>>>>>>>>>>>> variant(s) >>>>>>>>>>>>>> of addStep that let you pass in a 'response' ModelNode. For >>>>>>>>>>>>>> example, >>>>>>>>>>>>>> you >>>>>>>>>>>>>> could >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1) create a ModelNode. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2) add a step that will trigger use of ProfileDescribeHandler, >>>>>>>>>>>>>> passing >>>>>>>>>>>>>> in the ModelNode from 1) as the response. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 3) Add a step that will take the 'describe' results from 2, >>>>>>>>>>>>>> munge the >>>>>>>>>>>>>> addresses, and then add steps to execute all those ops. This 3) >>>>>>>>>>>>>> step >>>>>>>>>>>>>> will have a ref to the ModelNode from 1), allowing it to see >>>>>>>>>>>>>> the >>>>>>>>>>>>>> result >>>>>>>>>>>>>> of the work done by 2). >>>>>>>>>>>>>> >>>>>>>>>>>>>>> - I will be out on holiday next week, so take your take >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Enjoy! >>>>>>>>>>>>>> >>>>>>>>>>>>>>> cheers >>>>>>>>>>>>>>> Tom >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 18/08/14 16:45, Brian Stansberry wrote: >>>>>>>>>>>>>>>> On 8/18/14, 10:30 AM, Tom Fonteyne wrote: >>>>>>>>>>>>>>>>>> Do you have any interest in looking into that? >>>>>>>>>>>>>>>>> sure - if I can I will :) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> But you'll need to send me details on where to hook up in >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> code/modules >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Great. Just a warning -- this will be a fairly complex task. >>>>>>>>>>>>>>>> But >>>>>>>>>>>>>>>> hopefully not crazily so. :) And hopefully interesting. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Seems JIRA works, so long as you don't need to log in. >>>>>>>>>>>>>>>> There are two JIRAs: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> https://issues.jboss.org/browse/WFLY-1106 >>>>>>>>>>>>>>>> https://issues.jboss.org/browse/WFLY-1706 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The second is really more of a duplicate of the former and >>>>>>>>>>>>>>>> I'll >>>>>>>>>>>>>>>> probably close it as such. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This would be part of WildFly Core (I'll move the issues to >>>>>>>>>>>>>>>> WFCORE at >>>>>>>>>>>>>>>> some point.) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> What's needed is an implementation of the >>>>>>>>>>>>>>>> OperationStepHandler >>>>>>>>>>>>>>>> interface in the WildFly Core controller module. We can chat >>>>>>>>>>>>>>>> off-list >>>>>>>>>>>>>>>> about details. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Doing this for profiles (or children of standalone server >>>>>>>>>>>>>>>> subsystems) >>>>>>>>>>>>>>>> should be fairly straightforward, because the "describe" >>>>>>>>>>>>>>>> operation >>>>>>>>>>>>>>>> that I mentioned exists. Moving to other resources outside >>>>>>>>>>>>>>>> of a >>>>>>>>>>>>>>>> profile/subsystem will require some work from my team, to >>>>>>>>>>>>>>>> provide >>>>>>>>>>>>>>>> some >>>>>>>>>>>>>>>> sort of analogue to the "describe" operation. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> To show you what I mean about the describe operation, here I >>>>>>>>>>>>>>>> run it >>>>>>>>>>>>>>>> from the CLI against a standalone server's datasource >>>>>>>>>>>>>>>> subsystem. >>>>>>>>>>>>>>>> The >>>>>>>>>>>>>>>> result is a list, where each element in the list is the >>>>>>>>>>>>>>>> equivalent of >>>>>>>>>>>>>>>> a low level operation. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> [standalone at localhost:9990 /] /subsystem=datasources:describe >>>>>>>>>>>>>>>> { >>>>>>>>>>>>>>>> "outcome" => "success", >>>>>>>>>>>>>>>> "result" => [ >>>>>>>>>>>>>>>> { >>>>>>>>>>>>>>>> "operation" => "add", >>>>>>>>>>>>>>>> "address" => [("subsystem" => "datasources")] >>>>>>>>>>>>>>>> }, >>>>>>>>>>>>>>>> { >>>>>>>>>>>>>>>> "deployment-name" => undefined, >>>>>>>>>>>>>>>> "driver-name" => "h2", >>>>>>>>>>>>>>>> "driver-module-name" => "com.h2database.h2", >>>>>>>>>>>>>>>> "module-slot" => undefined, >>>>>>>>>>>>>>>> "driver-class-name" => undefined, >>>>>>>>>>>>>>>> "driver-datasource-class-name" => undefined, >>>>>>>>>>>>>>>> "driver-xa-datasource-class-name" => >>>>>>>>>>>>>>>> "org.h2.jdbcx.JdbcDataSource", >>>>>>>>>>>>>>>> "xa-datasource-class" => undefined, >>>>>>>>>>>>>>>> "driver-major-version" => undefined, >>>>>>>>>>>>>>>> "driver-minor-version" => undefined, >>>>>>>>>>>>>>>> "jdbc-compliant" => undefined, >>>>>>>>>>>>>>>> "operation" => "add", >>>>>>>>>>>>>>>> "address" => [ >>>>>>>>>>>>>>>> ("subsystem" => "datasources"), >>>>>>>>>>>>>>>> ("jdbc-driver" => "h2") >>>>>>>>>>>>>>>> ] >>>>>>>>>>>>>>>> }, >>>>>>>>>>>>>>>> { >>>>>>>>>>>>>>>> "connection-url" => >>>>>>>>>>>>>>>> "jdbc:h2:mem:test;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE", >>>>>>>>>>>>>>>> "driver-class" => undefined, >>>>>>>>>>>>>>>> "datasource-class" => undefined, >>>>>>>>>>>>>>>> "jndi-name" => >>>>>>>>>>>>>>>> "java:jboss/datasources/ExampleDS", >>>>>>>>>>>>>>>> "driver-name" => "h2", >>>>>>>>>>>>>>>> "new-connection-sql" => undefined, >>>>>>>>>>>>>>>> "url-delimiter" => undefined, >>>>>>>>>>>>>>>> "url-selector-strategy-class-name" => undefined, >>>>>>>>>>>>>>>> "use-java-context" => true, >>>>>>>>>>>>>>>> "jta" => undefined, >>>>>>>>>>>>>>>> "max-pool-size" => undefined, >>>>>>>>>>>>>>>> "min-pool-size" => undefined, >>>>>>>>>>>>>>>> "initial-pool-size" => undefined, >>>>>>>>>>>>>>>> "pool-prefill" => undefined, >>>>>>>>>>>>>>>> "pool-use-strict-min" => undefined, >>>>>>>>>>>>>>>> "capacity-incrementer-class" => undefined, >>>>>>>>>>>>>>>> "capacity-decrementer-class" => undefined, >>>>>>>>>>>>>>>> "user-name" => "sa", >>>>>>>>>>>>>>>> "password" => "sa", >>>>>>>>>>>>>>>> "security-domain" => undefined, >>>>>>>>>>>>>>>> "reauth-plugin-class-name" => undefined, >>>>>>>>>>>>>>>> "flush-strategy" => undefined, >>>>>>>>>>>>>>>> "allow-multiple-users" => undefined, >>>>>>>>>>>>>>>> "connection-listener-class" => undefined, >>>>>>>>>>>>>>>> "connection-properties" => undefined, >>>>>>>>>>>>>>>> "prepared-statements-cache-size" => undefined, >>>>>>>>>>>>>>>> "share-prepared-statements" => undefined, >>>>>>>>>>>>>>>> "track-statements" => undefined, >>>>>>>>>>>>>>>> "allocation-retry" => undefined, >>>>>>>>>>>>>>>> "allocation-retry-wait-millis" => undefined, >>>>>>>>>>>>>>>> "blocking-timeout-wait-millis" => undefined, >>>>>>>>>>>>>>>> "idle-timeout-minutes" => undefined, >>>>>>>>>>>>>>>> "query-timeout" => undefined, >>>>>>>>>>>>>>>> "use-try-lock" => undefined, >>>>>>>>>>>>>>>> "set-tx-query-timeout" => undefined, >>>>>>>>>>>>>>>> "transaction-isolation" => undefined, >>>>>>>>>>>>>>>> "check-valid-connection-sql" => undefined, >>>>>>>>>>>>>>>> "exception-sorter-class-name" => undefined, >>>>>>>>>>>>>>>> "stale-connection-checker-class-name" => undefined, >>>>>>>>>>>>>>>> "valid-connection-checker-class-name" => undefined, >>>>>>>>>>>>>>>> "background-validation-millis" => undefined, >>>>>>>>>>>>>>>> "background-validation" => undefined, >>>>>>>>>>>>>>>> "use-fast-fail" => undefined, >>>>>>>>>>>>>>>> "validate-on-match" => undefined, >>>>>>>>>>>>>>>> "spy" => undefined, >>>>>>>>>>>>>>>> "use-ccm" => undefined, >>>>>>>>>>>>>>>> "enabled" => true, >>>>>>>>>>>>>>>> "connectable" => undefined, >>>>>>>>>>>>>>>> "statistics-enabled" => undefined, >>>>>>>>>>>>>>>> "tracking" => undefined, >>>>>>>>>>>>>>>> "reauth-plugin-properties" => undefined, >>>>>>>>>>>>>>>> "exception-sorter-properties" => undefined, >>>>>>>>>>>>>>>> "stale-connection-checker-properties" => undefined, >>>>>>>>>>>>>>>> "valid-connection-checker-properties" => undefined, >>>>>>>>>>>>>>>> "connection-listener-property" => undefined, >>>>>>>>>>>>>>>> "capacity-incrementer-properties" => undefined, >>>>>>>>>>>>>>>> "capacity-decrementer-properties" => undefined, >>>>>>>>>>>>>>>> "operation" => "add", >>>>>>>>>>>>>>>> "address" => [ >>>>>>>>>>>>>>>> ("subsystem" => "datasources"), >>>>>>>>>>>>>>>> ("data-source" => "ExampleDS") >>>>>>>>>>>>>>>> ] >>>>>>>>>>>>>>>> }, >>>>>>>>>>>>>>>> { >>>>>>>>>>>>>>>> "connection-url" => >>>>>>>>>>>>>>>> "jdbc:h2:mem:test;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE", >>>>>>>>>>>>>>>> "driver-class" => undefined, >>>>>>>>>>>>>>>> "datasource-class" => undefined, >>>>>>>>>>>>>>>> "jndi-name" => >>>>>>>>>>>>>>>> "java:jboss/datasources/ExampleDS", >>>>>>>>>>>>>>>> "driver-name" => "h2", >>>>>>>>>>>>>>>> "new-connection-sql" => undefined, >>>>>>>>>>>>>>>> "url-delimiter" => undefined, >>>>>>>>>>>>>>>> "url-selector-strategy-class-name" => undefined, >>>>>>>>>>>>>>>> "use-java-context" => true, >>>>>>>>>>>>>>>> "jta" => undefined, >>>>>>>>>>>>>>>> "max-pool-size" => undefined, >>>>>>>>>>>>>>>> "min-pool-size" => undefined, >>>>>>>>>>>>>>>> "initial-pool-size" => undefined, >>>>>>>>>>>>>>>> "pool-prefill" => undefined, >>>>>>>>>>>>>>>> "pool-use-strict-min" => undefined, >>>>>>>>>>>>>>>> "capacity-incrementer-class" => undefined, >>>>>>>>>>>>>>>> "capacity-decrementer-class" => undefined, >>>>>>>>>>>>>>>> "user-name" => "sa", >>>>>>>>>>>>>>>> "password" => "sa", >>>>>>>>>>>>>>>> "security-domain" => undefined, >>>>>>>>>>>>>>>> "reauth-plugin-class-name" => undefined, >>>>>>>>>>>>>>>> "flush-strategy" => undefined, >>>>>>>>>>>>>>>> "allow-multiple-users" => undefined, >>>>>>>>>>>>>>>> "connection-listener-class" => undefined, >>>>>>>>>>>>>>>> "connection-properties" => undefined, >>>>>>>>>>>>>>>> "prepared-statements-cache-size" => undefined, >>>>>>>>>>>>>>>> "share-prepared-statements" => undefined, >>>>>>>>>>>>>>>> "track-statements" => undefined, >>>>>>>>>>>>>>>> "allocation-retry" => undefined, >>>>>>>>>>>>>>>> "allocation-retry-wait-millis" => undefined, >>>>>>>>>>>>>>>> "blocking-timeout-wait-millis" => undefined, >>>>>>>>>>>>>>>> "idle-timeout-minutes" => undefined, >>>>>>>>>>>>>>>> "query-timeout" => undefined, >>>>>>>>>>>>>>>> "use-try-lock" => undefined, >>>>>>>>>>>>>>>> "set-tx-query-timeout" => undefined, >>>>>>>>>>>>>>>> "transaction-isolation" => undefined, >>>>>>>>>>>>>>>> "check-valid-connection-sql" => undefined, >>>>>>>>>>>>>>>> "exception-sorter-class-name" => undefined, >>>>>>>>>>>>>>>> "stale-connection-checker-class-name" => undefined, >>>>>>>>>>>>>>>> "valid-connection-checker-class-name" => undefined, >>>>>>>>>>>>>>>> "background-validation-millis" => undefined, >>>>>>>>>>>>>>>> "background-validation" => undefined, >>>>>>>>>>>>>>>> "use-fast-fail" => undefined, >>>>>>>>>>>>>>>> "validate-on-match" => undefined, >>>>>>>>>>>>>>>> "spy" => undefined, >>>>>>>>>>>>>>>> "use-ccm" => undefined, >>>>>>>>>>>>>>>> "enabled" => true, >>>>>>>>>>>>>>>> "connectable" => undefined, >>>>>>>>>>>>>>>> "statistics-enabled" => undefined, >>>>>>>>>>>>>>>> "tracking" => undefined, >>>>>>>>>>>>>>>> "reauth-plugin-properties" => undefined, >>>>>>>>>>>>>>>> "exception-sorter-properties" => undefined, >>>>>>>>>>>>>>>> "stale-connection-checker-properties" => undefined, >>>>>>>>>>>>>>>> "valid-connection-checker-properties" => undefined, >>>>>>>>>>>>>>>> "connection-listener-property" => undefined, >>>>>>>>>>>>>>>> "capacity-incrementer-properties" => undefined, >>>>>>>>>>>>>>>> "capacity-decrementer-properties" => undefined, >>>>>>>>>>>>>>>> "operation" => "add", >>>>>>>>>>>>>>>> "address" => [ >>>>>>>>>>>>>>>> ("subsystem" => "datasources"), >>>>>>>>>>>>>>>> ("data-source" => "ExampleDS") >>>>>>>>>>>>>>>> ] >>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>> ] >>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 18/08/14 16:04, Brian Stansberry wrote: >>>>>>>>>>>>>>>>>> Cool. That can be quite helpful. It's nice to see folks >>>>>>>>>>>>>>>>>> writing >>>>>>>>>>>>>>>>>> tooling based on the management API. :) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> There's a JIRA out there for doing this on the server side >>>>>>>>>>>>>>>>>> instead of >>>>>>>>>>>>>>>>>> the client side. So a user invokes an op and the server >>>>>>>>>>>>>>>>>> handles it. >>>>>>>>>>>>>>>>>> For sure that will be done for EAP 7. Do you have any >>>>>>>>>>>>>>>>>> interest in >>>>>>>>>>>>>>>>>> looking into that? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The jboss.org site is down for maintenance, or I'd send >>>>>>>>>>>>>>>>>> you the >>>>>>>>>>>>>>>>>> link >>>>>>>>>>>>>>>>>> to the JIRA. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The server-side can utilize an internal operation called >>>>>>>>>>>>>>>>>> "describe" to >>>>>>>>>>>>>>>>>> get the exact ops needed to create a profile. From there >>>>>>>>>>>>>>>>>> it's >>>>>>>>>>>>>>>>>> just a >>>>>>>>>>>>>>>>>> matter of changing the addresses to point to the target. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 8/18/14, 7:04 AM, Tom Fonteyne wrote: >>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I decided to stick my head into DMR code and as a result >>>>>>>>>>>>>>>>>>> ended up >>>>>>>>>>>>>>>>>>> writing a Profile Clone tool >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> It connects to a running domain controller, reads the >>>>>>>>>>>>>>>>>>> desired >>>>>>>>>>>>>>>>>>> origin >>>>>>>>>>>>>>>>>>> profile and spits out a file with CLI commands. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I't not limited to profiles, it can basically read any >>>>>>>>>>>>>>>>>>> root >>>>>>>>>>>>>>>>>>> element >>>>>>>>>>>>>>>>>>> (not >>>>>>>>>>>>>>>>>>> all make sense of course) so you can also for example >>>>>>>>>>>>>>>>>>> clone >>>>>>>>>>>>>>>>>>> socket-binding-group >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I've tested it with full-ha with added datasources and >>>>>>>>>>>>>>>>>>> security >>>>>>>>>>>>>>>>>>> domains. >>>>>>>>>>>>>>>>>>> Will it handle any profile ? Well, it should... but if you >>>>>>>>>>>>>>>>>>> have >>>>>>>>>>>>>>>>>>> one >>>>>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>>> breaks then please let me know. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> There is a caveat with hornetq conection factories though: >>>>>>>>>>>>>>>>>>> double >>>>>>>>>>>>>>>>>>> check >>>>>>>>>>>>>>>>>>> if the right connector is set. >>>>>>>>>>>>>>>>>>> Correct manually in the output if needed ! >>>>>>>>>>>>>>>>>>> Check the entries: >>>>>>>>>>>>>>>>>>> /profile=.*/subsystem=messaging/hornetq-server=.*/connection-factory=.* >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> and see/correct the connector attribute: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> connector={\"in-vm\" => undefined} >>>>>>>>>>>>>>>>>>> or >>>>>>>>>>>>>>>>>>> connector={\"netty\" => undefined} >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The reason is that the Cloner class does not set undefined >>>>>>>>>>>>>>>>>>> values >>>>>>>>>>>>>>>>>>> which >>>>>>>>>>>>>>>>>>> is logical, >>>>>>>>>>>>>>>>>>> but the hornetq connector must be defined with an >>>>>>>>>>>>>>>>>>> "undefined" >>>>>>>>>>>>>>>>>>> which is >>>>>>>>>>>>>>>>>>> not logical... >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Get the binary from here: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> http://zen.usersys.redhat.com/downloads/eap/apps/profilecloner.jar >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> http://zen.usersys.redhat.com/downloads/eap/apps/profilecloner.sh >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The sh file is bare-bones and expect JBOSS_HOME to be >>>>>>>>>>>>>>>>>>> set. Or >>>>>>>>>>>>>>>>>>> without >>>>>>>>>>>>>>>>>>> the sh: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> java -cp >>>>>>>>>>>>>>>>>>> $JBOSS_HOME/bin/client/jboss-cli-client.jar:profilecloner.jar >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> org.jboss.tfonteyne.profilecloner.Main >>>>>>>>>>>>>>>>>>> --controller= --username= >>>>>>>>>>>>>>>>>>> --password= >>>>>>>>>>>>>>>>>>> --port= --file= >>>>>>>>>>>>>>>>>>> rootelement from to [rootelement from to] .... >>>>>>>>>>>>>>>>>>> where "rootelement from to" is for example: >>>>>>>>>>>>>>>>>>> socket-binding-group full-ha-sockets >>>>>>>>>>>>>>>>>>> full-ha-sockets-copy >>>>>>>>>>>>>>>>>>> profile full-ha full-ha-copy >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> example: >>>>>>>>>>>>>>>>>>> java -cp >>>>>>>>>>>>>>>>>>> $JBOSS_HOME/bin/client/jboss-cli-client.jar:profilecloner.jar >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> org.jboss.tfonteyne.profilecloner.Main >>>>>>>>>>>>>>>>>>> --controller=localhost >>>>>>>>>>>>>>>>>>> --user=admin --password=secret --file=output.cli profile >>>>>>>>>>>>>>>>>>> full-ha >>>>>>>>>>>>>>>>>>> mycopy >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The sources are here: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> https://github.com/tfonteyn/profilecloner >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Is the code any good ? Can engineering use it to stick it >>>>>>>>>>>>>>>>>>> into the >>>>>>>>>>>>>>>>>>> product ? >>>>>>>>>>>>>>>>>>> I dunno... it works but was build with trial and error. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> PLEASE send me feedback ! >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Kind regards >>>>>>>>>>>>>>>>>>> Tom >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>> >> >> >> -- >> Brian Stansberry >> Senior Principal Software Engineer >> JBoss by Red Hat > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From arun.gupta at gmail.com Wed Sep 24 20:39:15 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Wed, 24 Sep 2014 17:39:15 -0700 Subject: [wildfly-dev] Fwd: Running an Arquillian test with WildFly on OpenShift In-Reply-To: References: Message-ID: Forwarding to a broader alias in case somebody can help. ---------- Forwarded message ---------- From: Arun Gupta Date: Wed, Sep 24, 2014 at 4:50 PM Subject: Running an Arquillian test with WildFly on OpenShift To: Farah Juma , Brian Stansberry , Aslak Knutsen , Grant Shipley Trying to run a trivial Arquillian test from my local machine against a WildFly instance hosted on OpenShift. Tried using javaee7-milestogo.rhcloud.com 127.7.102.129 ${env.OPENSHIFT_WILDFLY_IP} in arquillian.xml but keep getting: JBAS012144: Could not connect to http-remoting://javaee7-milestogo.rhcloud.com:9990. The connection timed out 127.7.102.129:8080 is timing out as well. Hostname to IP address mapping is giving: 107.21.74.39. Tried that and didn't work. Here is my arquillian.xml: 107.21.74.39 9990 I can run the test fine against a local WildFly instance. Any suggestions ? Arun -- http://blog.arungupta.me http://twitter.com/arungupta -- http://blog.arungupta.me http://twitter.com/arungupta From slaskawi at redhat.com Thu Sep 25 03:46:36 2014 From: slaskawi at redhat.com (=?UTF-8?B?U2ViYXN0aWFuIMWBYXNrYXdpZWM=?=) Date: Thu, 25 Sep 2014 09:46:36 +0200 Subject: [wildfly-dev] Fwd: Running an Arquillian test with WildFly on OpenShift In-Reply-To: References: Message-ID: <5423C85C.9010306@redhat.com> Hi Arun! I think I've seen somewhere that this port is not exposed to the outside world. I'm sorry, but I can't find exact link right now... However it should be easy to verify it by running: /"telnet javaee7-milestogo.rhcloud.com 9990/" According to this thread: https://www.openshift.com/forums/openshift/jboss-as7-management-in-openshift you should be able to forward ports to your local machine using " /rhc port-forward app/" After that you could use localhost:9990 The other way to solve it is to set up SSH port tunneling like that: /"ssh -L 9990:localhost:9990 @javaee7-milestogo.rhcloud.com"// /After that try using localhost:9990 Please let us know if any of those 2 solutions worked for you :) Best regards Sebastian On 09/25/2014 02:39 AM, Arun Gupta wrote: > Forwarding to a broader alias in case somebody can help. > > > ---------- Forwarded message ---------- > From: Arun Gupta > Date: Wed, Sep 24, 2014 at 4:50 PM > Subject: Running an Arquillian test with WildFly on OpenShift > To: Farah Juma , Brian Stansberry > , Aslak Knutsen , Grant > Shipley > > > Trying to run a trivial Arquillian test from my local machine against > a WildFly instance hosted on OpenShift. Tried using > > javaee7-milestogo.rhcloud.com > 127.7.102.129 > ${env.OPENSHIFT_WILDFLY_IP} > > in arquillian.xml but keep getting: > > JBAS012144: Could not connect to > http-remoting://javaee7-milestogo.rhcloud.com:9990. The connection > timed out > > 127.7.102.129:8080 is timing out as well. > > Hostname to IP address mapping is giving: 107.21.74.39. Tried that and > didn't work. > > Here is my arquillian.xml: > > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://jboss.org/schema/arquillian > http://jboss.org/schema/arquillian/arquillian_1_0.xsd"> > > > > > > 107.21.74.39 > 9990 > > > > > I can run the test fine against a local WildFly instance. > > Any suggestions ? > > Arun > > -- > http://blog.arungupta.me > http://twitter.com/arungupta > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140925/0d87196a/attachment.html From mpallas at gmail.com Thu Sep 25 04:01:36 2014 From: mpallas at gmail.com (Nick Mpallas) Date: Thu, 25 Sep 2014 10:01:36 +0200 Subject: [wildfly-dev] Fwd: Running an Arquillian test with WildFly on OpenShift In-Reply-To: <5423C85C.9010306@redhat.com> References: <5423C85C.9010306@redhat.com> Message-ID: Hi Arun, I think in openshift you need to enable port forwarding in order to have access to the server. By default that isn't enabled. There is this command : rhc port-forward -a Read more about it in the following link: https://www.openshift.com/blogs/getting-started-with-port-forwarding-on-openshift regards \n\b On Thu, Sep 25, 2014 at 9:46 AM, Sebastian ?askawiec wrote: > Hi Arun! > > I think I've seen somewhere that this port is not exposed to the outside > world. I'm sorry, but I can't find exact link right now... > > However it should be easy to verify it by running: > *"telnet javaee7-milestogo.rhcloud.com > 9990*" > > According to this thread: > https://www.openshift.com/forums/openshift/jboss-as7-management-in-openshift > you should be able to forward ports to your local machine using " *rhc > port-forward app*" > After that you could use localhost:9990 > > The other way to solve it is to set up SSH port tunneling like that: > *"ssh -L 9990:localhost:9990 @javaee7-milestogo.rhcloud.com > "* > After that try using localhost:9990 > > Please let us know if any of those 2 solutions worked for you :) > > Best regards > Sebastian > > > > On 09/25/2014 02:39 AM, Arun Gupta wrote: > > Forwarding to a broader alias in case somebody can help. > > > ---------- Forwarded message ---------- > From: Arun Gupta > Date: Wed, Sep 24, 2014 at 4:50 PM > Subject: Running an Arquillian test with WildFly on OpenShift > To: Farah Juma , Brian Stansberry , Aslak Knutsen , Grant > Shipley > > > Trying to run a trivial Arquillian test from my local machine against > a WildFly instance hosted on OpenShift. Tried using > javaee7-milestogo.rhcloud.com > 127.7.102.129 > ${env.OPENSHIFT_WILDFLY_IP} > > in arquillian.xml but keep getting: > > JBAS012144: Could not connect to > http-remoting://javaee7-milestogo.rhcloud.com:9990. The connection > timed out > 127.7.102.129:8080 is timing out as well. > > Hostname to IP address mapping is giving: 107.21.74.39. Tried that and > didn't work. > > Here is my arquillian.xml: > > > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://jboss.org/schema/arquillian > http://jboss.org/schema/arquillian/arquillian_1_0.xsd" > > > > > > > 107.21.74.39 > 9990 > > > > > I can run the test fine against a local WildFly instance. > > Any suggestions ? > > Arun > > --http://blog.arungupta.mehttp://twitter.com/arungupta > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- \n\m "camel is a horse made up in a laboratory" -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140925/00d85d29/attachment.html From arun.gupta at gmail.com Thu Sep 25 08:55:32 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Thu, 25 Sep 2014 05:55:32 -0700 Subject: [wildfly-dev] Fwd: Running an Arquillian test with WildFly on OpenShift In-Reply-To: <5423C85C.9010306@redhat.com> References: <5423C85C.9010306@redhat.com> Message-ID: On Thu, Sep 25, 2014 at 12:46 AM, Sebastian ?askawiec wrote: > Hi Arun! > > I think I've seen somewhere that this port is not exposed to the outside > world. I'm sorry, but I can't find exact link right now... > > However it should be easy to verify it by running: > "telnet javaee7-milestogo.rhcloud.com 9990" > > According to this thread: > https://www.openshift.com/forums/openshift/jboss-as7-management-in-openshift > you should be able to forward ports to your local machine using " rhc > port-forward app" > After that you could use localhost:9990 Already tried port forwarding and getting: Caused by: java.lang.RuntimeException: java.net.ConnectException: JBAS012174: Could not connect to http-remoting://127.0.0.1:9990. The connection failed I can telnet to localhost 9990 after forwarding the port. > > The other way to solve it is to set up SSH port tunneling like that: > "ssh -L 9990:localhost:9990 @javaee7-milestogo.rhcloud.com" > After that try using localhost:9990 > This opens up an ssh shell instead. Is this the right command ? Arun > Please let us know if any of those 2 solutions worked for you :) > > Best regards > Sebastian > > > > On 09/25/2014 02:39 AM, Arun Gupta wrote: > > Forwarding to a broader alias in case somebody can help. > > > ---------- Forwarded message ---------- > From: Arun Gupta > Date: Wed, Sep 24, 2014 at 4:50 PM > Subject: Running an Arquillian test with WildFly on OpenShift > To: Farah Juma , Brian Stansberry > , Aslak Knutsen , Grant > Shipley > > > Trying to run a trivial Arquillian test from my local machine against > a WildFly instance hosted on OpenShift. Tried using > > javaee7-milestogo.rhcloud.com > 127.7.102.129 > ${env.OPENSHIFT_WILDFLY_IP} > > in arquillian.xml but keep getting: > > JBAS012144: Could not connect to > http-remoting://javaee7-milestogo.rhcloud.com:9990. The connection > timed out > > 127.7.102.129:8080 is timing out as well. > > Hostname to IP address mapping is giving: 107.21.74.39. Tried that and > didn't work. > > Here is my arquillian.xml: > > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://jboss.org/schema/arquillian > http://jboss.org/schema/arquillian/arquillian_1_0.xsd"> > > > > > > 107.21.74.39 > 9990 > > > > > I can run the test fine against a local WildFly instance. > > Any suggestions ? > > Arun > > -- > http://blog.arungupta.me > http://twitter.com/arungupta > > > -- http://blog.arungupta.me http://twitter.com/arungupta From arun.gupta at gmail.com Thu Sep 25 09:08:10 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Thu, 25 Sep 2014 06:08:10 -0700 Subject: [wildfly-dev] Fwd: Running an Arquillian test with WildFly on OpenShift In-Reply-To: References: <5423C85C.9010306@redhat.com> Message-ID: Sebastian, After leaving the SSH tunnel open, here is the error that I'm getting: Caused by: java.io.EOFException: XNIO000812: Connection closed unexpectedly at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:296) at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:279) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) Seems like HTTP upgrade is failing over ssh tunnel. Is this usecase been tested ? Arun On Thu, Sep 25, 2014 at 5:55 AM, Arun Gupta wrote: > On Thu, Sep 25, 2014 at 12:46 AM, Sebastian ?askawiec > wrote: >> Hi Arun! >> >> I think I've seen somewhere that this port is not exposed to the outside >> world. I'm sorry, but I can't find exact link right now... >> >> However it should be easy to verify it by running: >> "telnet javaee7-milestogo.rhcloud.com 9990" >> >> According to this thread: >> https://www.openshift.com/forums/openshift/jboss-as7-management-in-openshift >> you should be able to forward ports to your local machine using " rhc >> port-forward app" >> After that you could use localhost:9990 > Already tried port forwarding and getting: > > Caused by: java.lang.RuntimeException: java.net.ConnectException: > JBAS012174: Could not connect to http-remoting://127.0.0.1:9990. The > connection failed > > I can telnet to localhost 9990 after forwarding the port. > >> >> The other way to solve it is to set up SSH port tunneling like that: >> "ssh -L 9990:localhost:9990 @javaee7-milestogo.rhcloud.com" >> After that try using localhost:9990 >> > > This opens up an ssh shell instead. Is this the right command ? > > Arun > >> Please let us know if any of those 2 solutions worked for you :) >> >> Best regards >> Sebastian >> >> >> >> On 09/25/2014 02:39 AM, Arun Gupta wrote: >> >> Forwarding to a broader alias in case somebody can help. >> >> >> ---------- Forwarded message ---------- >> From: Arun Gupta >> Date: Wed, Sep 24, 2014 at 4:50 PM >> Subject: Running an Arquillian test with WildFly on OpenShift >> To: Farah Juma , Brian Stansberry >> , Aslak Knutsen , Grant >> Shipley >> >> >> Trying to run a trivial Arquillian test from my local machine against >> a WildFly instance hosted on OpenShift. Tried using >> >> javaee7-milestogo.rhcloud.com >> 127.7.102.129 >> ${env.OPENSHIFT_WILDFLY_IP} >> >> in arquillian.xml but keep getting: >> >> JBAS012144: Could not connect to >> http-remoting://javaee7-milestogo.rhcloud.com:9990. The connection >> timed out >> >> 127.7.102.129:8080 is timing out as well. >> >> Hostname to IP address mapping is giving: 107.21.74.39. Tried that and >> didn't work. >> >> Here is my arquillian.xml: >> >> >> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >> xsi:schemaLocation="http://jboss.org/schema/arquillian >> http://jboss.org/schema/arquillian/arquillian_1_0.xsd"> >> >> >> >> >> >> 107.21.74.39 >> 9990 >> >> >> >> >> I can run the test fine against a local WildFly instance. >> >> Any suggestions ? >> >> Arun >> >> -- >> http://blog.arungupta.me >> http://twitter.com/arungupta >> >> >> > > > > -- > http://blog.arungupta.me > http://twitter.com/arungupta -- http://blog.arungupta.me http://twitter.com/arungupta From hbraun at redhat.com Thu Sep 25 10:29:53 2014 From: hbraun at redhat.com (Heiko Braun) Date: Thu, 25 Sep 2014 16:29:53 +0200 Subject: [wildfly-dev] Subsystem exposing a port? Message-ID: Can someone give me a brief overview how a subsystem would expose a port? How are services actually wired to the protocol multiplexing ? Can you point me to some examples? Regards, Heiko From tomaz.cerar at gmail.com Thu Sep 25 10:49:51 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Thu, 25 Sep 2014 16:49:51 +0200 Subject: [wildfly-dev] Subsystem exposing a port? In-Reply-To: References: Message-ID: You are talking about two things now. One is exposing new port which can be done via SocketBinding infrastructure we have. for example see ListenerAdd in undertow subsystem. Completely different thing is protocol multiplexing aka utilizing http upgrade. In this case port is one already exposed by undertow (8080 by default) See RemotingHttpUpgradeService for example how http-remoting works. Before you go with this solution make sure also protocol client support this. -- tomaz On Thu, Sep 25, 2014 at 4:29 PM, Heiko Braun wrote: > Can someone give me a brief overview how a subsystem would expose a port? > How are services actually wired to the protocol multiplexing ? Can you > point me to some examples? > > Regards, Heiko > _______________________________________________ > 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/20140925/f4f76ecd/attachment.html From fjuma at redhat.com Thu Sep 25 12:58:56 2014 From: fjuma at redhat.com (Farah Juma) Date: Thu, 25 Sep 2014 12:58:56 -0400 (EDT) Subject: [wildfly-dev] Fwd: Running an Arquillian test with WildFly on OpenShift In-Reply-To: References: <5423C85C.9010306@redhat.com> Message-ID: <841918436.32791203.1411664336187.JavaMail.zimbra@redhat.com> > From: "Arun Gupta" > To: "Sebastian ?askawiec" > Cc: "WildFly Dev" > Sent: Thursday, September 25, 2014 8:55:32 AM > Subject: Re: [wildfly-dev] Fwd: Running an Arquillian test with WildFly on OpenShift > > On Thu, Sep 25, 2014 at 12:46 AM, Sebastian ?askawiec > wrote: > > Hi Arun! > > > > I think I've seen somewhere that this port is not exposed to the outside > > world. I'm sorry, but I can't find exact link right now... > > > > However it should be easy to verify it by running: > > "telnet javaee7-milestogo.rhcloud.com 9990" > > > > According to this thread: > > https://www.openshift.com/forums/openshift/jboss-as7-management-in-openshift > > you should be able to forward ports to your local machine using " rhc > > port-forward app" > > After that you could use localhost:9990 > Already tried port forwarding and getting: > > Caused by: java.lang.RuntimeException: java.net.ConnectException: > JBAS012174: Could not connect to http-remoting://127.0.0.1:9990. The > connection failed Could this be an authentication issue? Does it work with port forwarding if you include the username and password for the user that's created by the cartridge in your arquillian.xml file? Farah > I can telnet to localhost 9990 after forwarding the port. > > > > > The other way to solve it is to set up SSH port tunneling like that: > > "ssh -L 9990:localhost:9990 @javaee7-milestogo.rhcloud.com" > > After that try using localhost:9990 > > > > This opens up an ssh shell instead. Is this the right command ? > > Arun > > > Please let us know if any of those 2 solutions worked for you :) > > > > Best regards > > Sebastian > > > > > > > > On 09/25/2014 02:39 AM, Arun Gupta wrote: > > > > Forwarding to a broader alias in case somebody can help. > > > > > > ---------- Forwarded message ---------- > > From: Arun Gupta > > Date: Wed, Sep 24, 2014 at 4:50 PM > > Subject: Running an Arquillian test with WildFly on OpenShift > > To: Farah Juma , Brian Stansberry > > , Aslak Knutsen , Grant > > Shipley > > > > > > Trying to run a trivial Arquillian test from my local machine against > > a WildFly instance hosted on OpenShift. Tried using > > > > javaee7-milestogo.rhcloud.com > > 127.7.102.129 > > ${env.OPENSHIFT_WILDFLY_IP} > > > > in arquillian.xml but keep getting: > > > > JBAS012144: Could not connect to > > http-remoting://javaee7-milestogo.rhcloud.com:9990. The connection > > timed out > > > > 127.7.102.129:8080 is timing out as well. > > > > Hostname to IP address mapping is giving: 107.21.74.39. Tried that and > > didn't work. > > > > Here is my arquillian.xml: > > > > > > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > > xsi:schemaLocation="http://jboss.org/schema/arquillian > > http://jboss.org/schema/arquillian/arquillian_1_0.xsd"> > > > > > > > > > > > > 107.21.74.39 > > 9990 > > > > > > > > > > I can run the test fine against a local WildFly instance. > > > > Any suggestions ? > > > > Arun > > > > -- > > http://blog.arungupta.me > > http://twitter.com/arungupta > > > > > > > > > > -- > http://blog.arungupta.me > http://twitter.com/arungupta > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From arun.gupta at gmail.com Thu Sep 25 13:04:36 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Thu, 25 Sep 2014 10:04:36 -0700 Subject: [wildfly-dev] Fwd: Running an Arquillian test with WildFly on OpenShift In-Reply-To: <841918436.32791203.1411664336187.JavaMail.zimbra@redhat.com> References: <5423C85C.9010306@redhat.com> <841918436.32791203.1411664336187.JavaMail.zimbra@redhat.com> Message-ID: Could be ... But seems like its not able to connect to the right host/port. How do I specify username/password in arquillian.xml ? Arun On Thu, Sep 25, 2014 at 9:58 AM, Farah Juma wrote: > >> From: "Arun Gupta" >> To: "Sebastian ?askawiec" >> Cc: "WildFly Dev" >> Sent: Thursday, September 25, 2014 8:55:32 AM >> Subject: Re: [wildfly-dev] Fwd: Running an Arquillian test with WildFly on OpenShift >> >> On Thu, Sep 25, 2014 at 12:46 AM, Sebastian ?askawiec >> wrote: >> > Hi Arun! >> > >> > I think I've seen somewhere that this port is not exposed to the outside >> > world. I'm sorry, but I can't find exact link right now... >> > >> > However it should be easy to verify it by running: >> > "telnet javaee7-milestogo.rhcloud.com 9990" >> > >> > According to this thread: >> > https://www.openshift.com/forums/openshift/jboss-as7-management-in-openshift >> > you should be able to forward ports to your local machine using " rhc >> > port-forward app" >> > After that you could use localhost:9990 >> Already tried port forwarding and getting: >> >> Caused by: java.lang.RuntimeException: java.net.ConnectException: >> JBAS012174: Could not connect to http-remoting://127.0.0.1:9990. The >> connection failed > > Could this be an authentication issue? Does it work with port forwarding if you include the username and password for the user that's created by the cartridge in your arquillian.xml file? > > > Farah > > >> I can telnet to localhost 9990 after forwarding the port. >> >> > >> > The other way to solve it is to set up SSH port tunneling like that: >> > "ssh -L 9990:localhost:9990 @javaee7-milestogo.rhcloud.com" >> > After that try using localhost:9990 >> > >> >> This opens up an ssh shell instead. Is this the right command ? >> >> Arun >> >> > Please let us know if any of those 2 solutions worked for you :) >> > >> > Best regards >> > Sebastian >> > >> > >> > >> > On 09/25/2014 02:39 AM, Arun Gupta wrote: >> > >> > Forwarding to a broader alias in case somebody can help. >> > >> > >> > ---------- Forwarded message ---------- >> > From: Arun Gupta >> > Date: Wed, Sep 24, 2014 at 4:50 PM >> > Subject: Running an Arquillian test with WildFly on OpenShift >> > To: Farah Juma , Brian Stansberry >> > , Aslak Knutsen , Grant >> > Shipley >> > >> > >> > Trying to run a trivial Arquillian test from my local machine against >> > a WildFly instance hosted on OpenShift. Tried using >> > >> > javaee7-milestogo.rhcloud.com >> > 127.7.102.129 >> > ${env.OPENSHIFT_WILDFLY_IP} >> > >> > in arquillian.xml but keep getting: >> > >> > JBAS012144: Could not connect to >> > http-remoting://javaee7-milestogo.rhcloud.com:9990. The connection >> > timed out >> > >> > 127.7.102.129:8080 is timing out as well. >> > >> > Hostname to IP address mapping is giving: 107.21.74.39. Tried that and >> > didn't work. >> > >> > Here is my arquillian.xml: >> > >> > >> > > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >> > xsi:schemaLocation="http://jboss.org/schema/arquillian >> > http://jboss.org/schema/arquillian/arquillian_1_0.xsd"> >> > >> > >> > >> > >> > >> > 107.21.74.39 >> > 9990 >> > >> > >> > >> > >> > I can run the test fine against a local WildFly instance. >> > >> > Any suggestions ? >> > >> > Arun >> > >> > -- >> > http://blog.arungupta.me >> > http://twitter.com/arungupta >> > >> > >> > >> >> >> >> -- >> http://blog.arungupta.me >> http://twitter.com/arungupta >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev -- http://blog.arungupta.me http://twitter.com/arungupta From fjuma at redhat.com Thu Sep 25 13:10:31 2014 From: fjuma at redhat.com (Farah Juma) Date: Thu, 25 Sep 2014 13:10:31 -0400 (EDT) Subject: [wildfly-dev] Fwd: Running an Arquillian test with WildFly on OpenShift In-Reply-To: References: <5423C85C.9010306@redhat.com> <841918436.32791203.1411664336187.JavaMail.zimbra@redhat.com> Message-ID: <1342041985.32793728.1411665031104.JavaMail.zimbra@redhat.com> They can be specified as follows: someUser somePassword The username/password for the user created by the cartridge can be found via the $OPENSHIFT_WILDFLY_USERNAME and $OPENSHIFT_WILDFLY_PASSWORD environment variables. Farah ----- Original Message ----- > From: "Arun Gupta" > To: "Farah Juma" > Cc: "WildFly Dev" > Sent: Thursday, September 25, 2014 1:04:36 PM > Subject: Re: [wildfly-dev] Fwd: Running an Arquillian test with WildFly on OpenShift > > Could be ... > > But seems like its not able to connect to the right host/port. How do > I specify username/password in arquillian.xml ? > > Arun > > On Thu, Sep 25, 2014 at 9:58 AM, Farah Juma wrote: > > > >> From: "Arun Gupta" > >> To: "Sebastian ?askawiec" > >> Cc: "WildFly Dev" > >> Sent: Thursday, September 25, 2014 8:55:32 AM > >> Subject: Re: [wildfly-dev] Fwd: Running an Arquillian test with WildFly on > >> OpenShift > >> > >> On Thu, Sep 25, 2014 at 12:46 AM, Sebastian ?askawiec > >> wrote: > >> > Hi Arun! > >> > > >> > I think I've seen somewhere that this port is not exposed to the outside > >> > world. I'm sorry, but I can't find exact link right now... > >> > > >> > However it should be easy to verify it by running: > >> > "telnet javaee7-milestogo.rhcloud.com 9990" > >> > > >> > According to this thread: > >> > https://www.openshift.com/forums/openshift/jboss-as7-management-in-openshift > >> > you should be able to forward ports to your local machine using " rhc > >> > port-forward app" > >> > After that you could use localhost:9990 > >> Already tried port forwarding and getting: > >> > >> Caused by: java.lang.RuntimeException: java.net.ConnectException: > >> JBAS012174: Could not connect to http-remoting://127.0.0.1:9990. The > >> connection failed > > > > Could this be an authentication issue? Does it work with port forwarding if > > you include the username and password for the user that's created by the > > cartridge in your arquillian.xml file? > > > > > > Farah > > > > > >> I can telnet to localhost 9990 after forwarding the port. > >> > >> > > >> > The other way to solve it is to set up SSH port tunneling like that: > >> > "ssh -L 9990:localhost:9990 @javaee7-milestogo.rhcloud.com" > >> > After that try using localhost:9990 > >> > > >> > >> This opens up an ssh shell instead. Is this the right command ? > >> > >> Arun > >> > >> > Please let us know if any of those 2 solutions worked for you :) > >> > > >> > Best regards > >> > Sebastian > >> > > >> > > >> > > >> > On 09/25/2014 02:39 AM, Arun Gupta wrote: > >> > > >> > Forwarding to a broader alias in case somebody can help. > >> > > >> > > >> > ---------- Forwarded message ---------- > >> > From: Arun Gupta > >> > Date: Wed, Sep 24, 2014 at 4:50 PM > >> > Subject: Running an Arquillian test with WildFly on OpenShift > >> > To: Farah Juma , Brian Stansberry > >> > , Aslak Knutsen , Grant > >> > Shipley > >> > > >> > > >> > Trying to run a trivial Arquillian test from my local machine against > >> > a WildFly instance hosted on OpenShift. Tried using > >> > > >> > javaee7-milestogo.rhcloud.com > >> > 127.7.102.129 > >> > ${env.OPENSHIFT_WILDFLY_IP} > >> > > >> > in arquillian.xml but keep getting: > >> > > >> > JBAS012144: Could not connect to > >> > http-remoting://javaee7-milestogo.rhcloud.com:9990. The connection > >> > timed out > >> > > >> > 127.7.102.129:8080 is timing out as well. > >> > > >> > Hostname to IP address mapping is giving: 107.21.74.39. Tried that and > >> > didn't work. > >> > > >> > Here is my arquillian.xml: > >> > > >> > > >> > >> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > >> > xsi:schemaLocation="http://jboss.org/schema/arquillian > >> > http://jboss.org/schema/arquillian/arquillian_1_0.xsd"> > >> > > >> > > >> > > >> > > >> > > >> > 107.21.74.39 > >> > 9990 > >> > > >> > > >> > > >> > > >> > I can run the test fine against a local WildFly instance. > >> > > >> > Any suggestions ? > >> > > >> > Arun > >> > > >> > -- > >> > http://blog.arungupta.me > >> > http://twitter.com/arungupta > >> > > >> > > >> > > >> > >> > >> > >> -- > >> http://blog.arungupta.me > >> http://twitter.com/arungupta > >> > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > -- > http://blog.arungupta.me > http://twitter.com/arungupta > From arun.gupta at gmail.com Thu Sep 25 13:24:09 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Thu, 25 Sep 2014 10:24:09 -0700 Subject: [wildfly-dev] Fwd: Running an Arquillian test with WildFly on OpenShift In-Reply-To: <1342041985.32793728.1411665031104.JavaMail.zimbra@redhat.com> References: <5423C85C.9010306@redhat.com> <841918436.32791203.1411664336187.JavaMail.zimbra@redhat.com> <1342041985.32793728.1411665031104.JavaMail.zimbra@redhat.com> Message-ID: I'd like to run the tests from my machine against the remote WildFly instance first and so would need the value for these variables. How do I retrieve these values for a previously created WildFly application on OpenShift ? Arun On Thu, Sep 25, 2014 at 10:10 AM, Farah Juma wrote: > They can be specified as follows: > > someUser > somePassword > > The username/password for the user created by the cartridge can be found via the $OPENSHIFT_WILDFLY_USERNAME and $OPENSHIFT_WILDFLY_PASSWORD environment variables. > > Farah > > > ----- Original Message ----- >> From: "Arun Gupta" >> To: "Farah Juma" >> Cc: "WildFly Dev" >> Sent: Thursday, September 25, 2014 1:04:36 PM >> Subject: Re: [wildfly-dev] Fwd: Running an Arquillian test with WildFly on OpenShift >> >> Could be ... >> >> But seems like its not able to connect to the right host/port. How do >> I specify username/password in arquillian.xml ? >> >> Arun >> >> On Thu, Sep 25, 2014 at 9:58 AM, Farah Juma wrote: >> > >> >> From: "Arun Gupta" >> >> To: "Sebastian ?askawiec" >> >> Cc: "WildFly Dev" >> >> Sent: Thursday, September 25, 2014 8:55:32 AM >> >> Subject: Re: [wildfly-dev] Fwd: Running an Arquillian test with WildFly on >> >> OpenShift >> >> >> >> On Thu, Sep 25, 2014 at 12:46 AM, Sebastian ?askawiec >> >> wrote: >> >> > Hi Arun! >> >> > >> >> > I think I've seen somewhere that this port is not exposed to the outside >> >> > world. I'm sorry, but I can't find exact link right now... >> >> > >> >> > However it should be easy to verify it by running: >> >> > "telnet javaee7-milestogo.rhcloud.com 9990" >> >> > >> >> > According to this thread: >> >> > https://www.openshift.com/forums/openshift/jboss-as7-management-in-openshift >> >> > you should be able to forward ports to your local machine using " rhc >> >> > port-forward app" >> >> > After that you could use localhost:9990 >> >> Already tried port forwarding and getting: >> >> >> >> Caused by: java.lang.RuntimeException: java.net.ConnectException: >> >> JBAS012174: Could not connect to http-remoting://127.0.0.1:9990. The >> >> connection failed >> > >> > Could this be an authentication issue? Does it work with port forwarding if >> > you include the username and password for the user that's created by the >> > cartridge in your arquillian.xml file? >> > >> > >> > Farah >> > >> > >> >> I can telnet to localhost 9990 after forwarding the port. >> >> >> >> > >> >> > The other way to solve it is to set up SSH port tunneling like that: >> >> > "ssh -L 9990:localhost:9990 @javaee7-milestogo.rhcloud.com" >> >> > After that try using localhost:9990 >> >> > >> >> >> >> This opens up an ssh shell instead. Is this the right command ? >> >> >> >> Arun >> >> >> >> > Please let us know if any of those 2 solutions worked for you :) >> >> > >> >> > Best regards >> >> > Sebastian >> >> > >> >> > >> >> > >> >> > On 09/25/2014 02:39 AM, Arun Gupta wrote: >> >> > >> >> > Forwarding to a broader alias in case somebody can help. >> >> > >> >> > >> >> > ---------- Forwarded message ---------- >> >> > From: Arun Gupta >> >> > Date: Wed, Sep 24, 2014 at 4:50 PM >> >> > Subject: Running an Arquillian test with WildFly on OpenShift >> >> > To: Farah Juma , Brian Stansberry >> >> > , Aslak Knutsen , Grant >> >> > Shipley >> >> > >> >> > >> >> > Trying to run a trivial Arquillian test from my local machine against >> >> > a WildFly instance hosted on OpenShift. Tried using >> >> > >> >> > javaee7-milestogo.rhcloud.com >> >> > 127.7.102.129 >> >> > ${env.OPENSHIFT_WILDFLY_IP} >> >> > >> >> > in arquillian.xml but keep getting: >> >> > >> >> > JBAS012144: Could not connect to >> >> > http-remoting://javaee7-milestogo.rhcloud.com:9990. The connection >> >> > timed out >> >> > >> >> > 127.7.102.129:8080 is timing out as well. >> >> > >> >> > Hostname to IP address mapping is giving: 107.21.74.39. Tried that and >> >> > didn't work. >> >> > >> >> > Here is my arquillian.xml: >> >> > >> >> > >> >> > > >> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >> >> > xsi:schemaLocation="http://jboss.org/schema/arquillian >> >> > http://jboss.org/schema/arquillian/arquillian_1_0.xsd"> >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > 107.21.74.39 >> >> > 9990 >> >> > >> >> > >> >> > >> >> > >> >> > I can run the test fine against a local WildFly instance. >> >> > >> >> > Any suggestions ? >> >> > >> >> > Arun >> >> > >> >> > -- >> >> > http://blog.arungupta.me >> >> > http://twitter.com/arungupta >> >> > >> >> > >> >> > >> >> >> >> >> >> >> >> -- >> >> http://blog.arungupta.me >> >> http://twitter.com/arungupta >> >> >> >> _______________________________________________ >> >> wildfly-dev mailing list >> >> wildfly-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> >> -- >> http://blog.arungupta.me >> http://twitter.com/arungupta >> -- http://blog.arungupta.me http://twitter.com/arungupta From fjuma at redhat.com Thu Sep 25 13:34:52 2014 From: fjuma at redhat.com (Farah Juma) Date: Thu, 25 Sep 2014 13:34:52 -0400 (EDT) Subject: [wildfly-dev] Fwd: Running an Arquillian test with WildFly on OpenShift In-Reply-To: References: <5423C85C.9010306@redhat.com> <841918436.32791203.1411664336187.JavaMail.zimbra@redhat.com> <1342041985.32793728.1411665031104.JavaMail.zimbra@redhat.com> Message-ID: <2014035546.32798828.1411666492636.JavaMail.zimbra@redhat.com> The values can be retrieved by using the "rhc ssh" command to ssh into your instance and then: echo $OPENSHIFT_WILDFLY_USERNAME echo $OPENSHIFT_WILDFLY_PASSWORD Farah ----- Original Message ----- > From: "Arun Gupta" > To: "Farah Juma" > Cc: "WildFly Dev" > Sent: Thursday, September 25, 2014 1:24:09 PM > Subject: Re: [wildfly-dev] Fwd: Running an Arquillian test with WildFly on OpenShift > > I'd like to run the tests from my machine against the remote WildFly > instance first and so would need the value for these variables. > > How do I retrieve these values for a previously created WildFly > application on OpenShift ? > > Arun > > On Thu, Sep 25, 2014 at 10:10 AM, Farah Juma wrote: > > They can be specified as follows: > > > > someUser > > somePassword > > > > The username/password for the user created by the cartridge can be found > > via the $OPENSHIFT_WILDFLY_USERNAME and $OPENSHIFT_WILDFLY_PASSWORD > > environment variables. > > > > Farah > > > > > > ----- Original Message ----- > >> From: "Arun Gupta" > >> To: "Farah Juma" > >> Cc: "WildFly Dev" > >> Sent: Thursday, September 25, 2014 1:04:36 PM > >> Subject: Re: [wildfly-dev] Fwd: Running an Arquillian test with WildFly on > >> OpenShift > >> > >> Could be ... > >> > >> But seems like its not able to connect to the right host/port. How do > >> I specify username/password in arquillian.xml ? > >> > >> Arun > >> > >> On Thu, Sep 25, 2014 at 9:58 AM, Farah Juma wrote: > >> > > >> >> From: "Arun Gupta" > >> >> To: "Sebastian ?askawiec" > >> >> Cc: "WildFly Dev" > >> >> Sent: Thursday, September 25, 2014 8:55:32 AM > >> >> Subject: Re: [wildfly-dev] Fwd: Running an Arquillian test with WildFly > >> >> on > >> >> OpenShift > >> >> > >> >> On Thu, Sep 25, 2014 at 12:46 AM, Sebastian ?askawiec > >> >> wrote: > >> >> > Hi Arun! > >> >> > > >> >> > I think I've seen somewhere that this port is not exposed to the > >> >> > outside > >> >> > world. I'm sorry, but I can't find exact link right now... > >> >> > > >> >> > However it should be easy to verify it by running: > >> >> > "telnet javaee7-milestogo.rhcloud.com 9990" > >> >> > > >> >> > According to this thread: > >> >> > https://www.openshift.com/forums/openshift/jboss-as7-management-in-openshift > >> >> > you should be able to forward ports to your local machine using " rhc > >> >> > port-forward app" > >> >> > After that you could use localhost:9990 > >> >> Already tried port forwarding and getting: > >> >> > >> >> Caused by: java.lang.RuntimeException: java.net.ConnectException: > >> >> JBAS012174: Could not connect to http-remoting://127.0.0.1:9990. The > >> >> connection failed > >> > > >> > Could this be an authentication issue? Does it work with port forwarding > >> > if > >> > you include the username and password for the user that's created by the > >> > cartridge in your arquillian.xml file? > >> > > >> > > >> > Farah > >> > > >> > > >> >> I can telnet to localhost 9990 after forwarding the port. > >> >> > >> >> > > >> >> > The other way to solve it is to set up SSH port tunneling like that: > >> >> > "ssh -L 9990:localhost:9990 @javaee7-milestogo.rhcloud.com" > >> >> > After that try using localhost:9990 > >> >> > > >> >> > >> >> This opens up an ssh shell instead. Is this the right command ? > >> >> > >> >> Arun > >> >> > >> >> > Please let us know if any of those 2 solutions worked for you :) > >> >> > > >> >> > Best regards > >> >> > Sebastian > >> >> > > >> >> > > >> >> > > >> >> > On 09/25/2014 02:39 AM, Arun Gupta wrote: > >> >> > > >> >> > Forwarding to a broader alias in case somebody can help. > >> >> > > >> >> > > >> >> > ---------- Forwarded message ---------- > >> >> > From: Arun Gupta > >> >> > Date: Wed, Sep 24, 2014 at 4:50 PM > >> >> > Subject: Running an Arquillian test with WildFly on OpenShift > >> >> > To: Farah Juma , Brian Stansberry > >> >> > , Aslak Knutsen , Grant > >> >> > Shipley > >> >> > > >> >> > > >> >> > Trying to run a trivial Arquillian test from my local machine against > >> >> > a WildFly instance hosted on OpenShift. Tried using > >> >> > > >> >> > javaee7-milestogo.rhcloud.com > >> >> > 127.7.102.129 > >> >> > ${env.OPENSHIFT_WILDFLY_IP} > >> >> > > >> >> > in arquillian.xml but keep getting: > >> >> > > >> >> > JBAS012144: Could not connect to > >> >> > http-remoting://javaee7-milestogo.rhcloud.com:9990. The connection > >> >> > timed out > >> >> > > >> >> > 127.7.102.129:8080 is timing out as well. > >> >> > > >> >> > Hostname to IP address mapping is giving: 107.21.74.39. Tried that > >> >> > and > >> >> > didn't work. > >> >> > > >> >> > Here is my arquillian.xml: > >> >> > > >> >> > > >> >> > >> >> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > >> >> > xsi:schemaLocation="http://jboss.org/schema/arquillian > >> >> > http://jboss.org/schema/arquillian/arquillian_1_0.xsd"> > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > 107.21.74.39 > >> >> > 9990 > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > I can run the test fine against a local WildFly instance. > >> >> > > >> >> > Any suggestions ? > >> >> > > >> >> > Arun > >> >> > > >> >> > -- > >> >> > http://blog.arungupta.me > >> >> > http://twitter.com/arungupta > >> >> > > >> >> > > >> >> > > >> >> > >> >> > >> >> > >> >> -- > >> >> http://blog.arungupta.me > >> >> http://twitter.com/arungupta > >> >> > >> >> _______________________________________________ > >> >> wildfly-dev mailing list > >> >> wildfly-dev at lists.jboss.org > >> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >> > >> > >> > >> -- > >> http://blog.arungupta.me > >> http://twitter.com/arungupta > >> > > > > -- > http://blog.arungupta.me > http://twitter.com/arungupta > From hbraun at redhat.com Fri Sep 26 02:38:39 2014 From: hbraun at redhat.com (Heiko Braun) Date: Fri, 26 Sep 2014 08:38:39 +0200 Subject: [wildfly-dev] Subsystem exposing a port? In-Reply-To: References: Message-ID: Yes, my explanation was misleading. Since we try to reduce the overall number of ports used, I did assume that any subsystem that needs remote communication needs to go down the HTTP upgrade route. Isn't that the case? What's the policy behind this? On 25 Sep 2014, at 16:49, Toma? Cerar wrote: > You are talking about two things now. > > One is exposing new port which can be done via SocketBinding infrastructure we have. > for example see ListenerAdd in undertow subsystem. > > Completely different thing is protocol multiplexing aka utilizing http upgrade. > In this case port is one already exposed by undertow (8080 by default) > See RemotingHttpUpgradeService for example how http-remoting works. > Before you go with this solution make sure also protocol client support this. > > -- > tomaz > > > On Thu, Sep 25, 2014 at 4:29 PM, Heiko Braun wrote: > Can someone give me a brief overview how a subsystem would expose a port? How are services actually wired to the protocol multiplexing ? Can you point me to some examples? > > Regards, Heiko > _______________________________________________ > 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/20140926/31d54be5/attachment.html From hbraun at redhat.com Fri Sep 26 03:06:28 2014 From: hbraun at redhat.com (Heiko Braun) Date: Fri, 26 Sep 2014 09:06:28 +0200 Subject: [wildfly-dev] Subsystem exposing a port? In-Reply-To: References: Message-ID: <6437B621-4ADF-40C8-A0CF-E8D91CB81A9E@redhat.com> so for the simple case the idea is to declare a service dependency on the socket-binding: serviceBuilder..addDependency(SocketBinding.JBOSS_BINDING_NAME.append(bindingRef), SocketBinding.class, service.getBinding()) and on the opposite side (service impl) use an injectable field: InjectedValue binding = new InjectedValue<>(); On 26 Sep 2014, at 08:38, Heiko Braun wrote: > > Yes, my explanation was misleading. Since we try to reduce the overall number of ports used, I did assume that any subsystem that needs remote communication needs to go down the HTTP upgrade route. Isn't that the case? What's the policy behind this? > > On 25 Sep 2014, at 16:49, Toma? Cerar wrote: > >> You are talking about two things now. >> >> One is exposing new port which can be done via SocketBinding infrastructure we have. >> for example see ListenerAdd in undertow subsystem. >> >> Completely different thing is protocol multiplexing aka utilizing http upgrade. >> In this case port is one already exposed by undertow (8080 by default) >> See RemotingHttpUpgradeService for example how http-remoting works. >> Before you go with this solution make sure also protocol client support this. >> >> -- >> tomaz >> >> >> On Thu, Sep 25, 2014 at 4:29 PM, Heiko Braun wrote: >> Can someone give me a brief overview how a subsystem would expose a port? How are services actually wired to the protocol multiplexing ? Can you point me to some examples? >> >> Regards, Heiko >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From david.lloyd at redhat.com Fri Sep 26 09:21:42 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 26 Sep 2014 08:21:42 -0500 Subject: [wildfly-dev] Security manager and RuntimePermission Message-ID: <54256866.9010304@redhat.com> There are several people (myself included) who have been using RuntimePermission as an easy way to define simple permissions for various purposes. However, by spec [1] the possible values of RuntimePermission are limited to a specific set defined by the JDK itself. Therefore our extensive usage of this permission in WildFly [2] and elsewhere needs to be revisited, and replaced with more specifically applicable permission types. I've created WFLY-3902 [3] to cover the main portion of this work, however, non-core project members should also perform this same examination to fix this issue in their projects. [1] http://docs.oracle.com/javase/7/docs/api/index.html?java/lang/RuntimePermission.html [2] http://fpaste.org/136720/37116141/raw/ [3] https://issues.jboss.org/browse/WFLY-3902 -- - DML From darran.lofthouse at jboss.com Fri Sep 26 09:27:44 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Fri, 26 Sep 2014 14:27:44 +0100 Subject: [wildfly-dev] Security manager and RuntimePermission In-Reply-To: <54256866.9010304@redhat.com> References: <54256866.9010304@redhat.com> Message-ID: <542569D0.1050500@jboss.com> At the same time I think we also need a better review of how PrivilegedActions are actually used - we kind of have an approach of using one every time we do something that could perform a security manager check but really there are cases where the action should be higher up the call stack. Secondly we also need additional checking that parameters passed to a privileged action are correctly sanitised. Regards, Darran Lofthouse. On 26/09/14 14:21, David M. Lloyd wrote: > There are several people (myself included) who have been using > RuntimePermission as an easy way to define simple permissions for > various purposes. However, by spec [1] the possible values of > RuntimePermission are limited to a specific set defined by the JDK itself. > > Therefore our extensive usage of this permission in WildFly [2] and > elsewhere needs to be revisited, and replaced with more specifically > applicable permission types. I've created WFLY-3902 [3] to cover the > main portion of this work, however, non-core project members should also > perform this same examination to fix this issue in their projects. > > [1] > http://docs.oracle.com/javase/7/docs/api/index.html?java/lang/RuntimePermission.html > [2] http://fpaste.org/136720/37116141/raw/ > [3] https://issues.jboss.org/browse/WFLY-3902 > From david.lloyd at redhat.com Fri Sep 26 11:53:19 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 26 Sep 2014 10:53:19 -0500 Subject: [wildfly-dev] About the security manager lifecycle Message-ID: <54258BEF.40802@redhat.com> At present in WildFly upstream, the security manager is only installed when the security manager subsystem installation commences, leading to PRs like this one [1] being rejected. However, feedback from various quarters indicates that this relatively late installation may not be acceptable for a couple different reasons. The current EAP version supports using the -secmgr flag to the start scripts to tell the bootstrap to install the security manager via jboss-modules' discovery process, which happens at the very beginning of process start. I'm thinking maybe we should bring this functionality forward, resurrect #175, and modify the security manager subsystem to attach to the currently installed security manager. This is also more friendly to embedded processes; we should support (for example) permission specification in deployments even if we don't directly control the security manager. This also allows the security manager subsystem to run even if no security manager is installed, so validation of permissions.xml (for example) will still take place. Thoughts? [1] https://github.com/wildfly/wildfly-core/pull/175 -- - DML From tomaz.cerar at gmail.com Mon Sep 29 07:25:37 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Mon, 29 Sep 2014 13:25:37 +0200 Subject: [wildfly-dev] Subsystem exposing a port? In-Reply-To: <6437B621-4ADF-40C8-A0CF-E8D91CB81A9E@redhat.com> References: <6437B621-4ADF-40C8-A0CF-E8D91CB81A9E@redhat.com> Message-ID: yes On Fri, Sep 26, 2014 at 9:06 AM, Heiko Braun wrote: > so for the simple case the idea is to declare a service dependency on the > socket-binding: > > serviceBuilder..addDependency(SocketBinding.JBOSS_BINDING_NAME.append(bindingRef), > SocketBinding.class, service.getBinding()) > > and on the opposite side (service impl) use an injectable field: > > InjectedValue binding = new InjectedValue<>(); > > > On 26 Sep 2014, at 08:38, Heiko Braun wrote: > > > > > Yes, my explanation was misleading. Since we try to reduce the overall > number of ports used, I did assume that any subsystem that needs remote > communication needs to go down the HTTP upgrade route. Isn't that the case? > What's the policy behind this? > > > > On 25 Sep 2014, at 16:49, Toma? Cerar wrote: > > > >> You are talking about two things now. > >> > >> One is exposing new port which can be done via SocketBinding > infrastructure we have. > >> for example see ListenerAdd in undertow subsystem. > >> > >> Completely different thing is protocol multiplexing aka utilizing http > upgrade. > >> In this case port is one already exposed by undertow (8080 by default) > >> See RemotingHttpUpgradeService for example how http-remoting works. > >> Before you go with this solution make sure also protocol client support > this. > >> > >> -- > >> tomaz > >> > >> > >> On Thu, Sep 25, 2014 at 4:29 PM, Heiko Braun wrote: > >> Can someone give me a brief overview how a subsystem would expose a > port? How are services actually wired to the protocol multiplexing ? Can > you point me to some examples? > >> > >> Regards, Heiko > >> _______________________________________________ > >> 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/20140929/360e1cfc/attachment-0001.html From hrupp at redhat.com Mon Sep 29 07:36:51 2014 From: hrupp at redhat.com (Heiko W.Rupp) Date: Mon, 29 Sep 2014 13:36:51 +0200 Subject: [wildfly-dev] Deliver 3rd party subsystem to customers? Message-ID: <43C4D1A3-7256-4436-A093-A5B321C1DC06@redhat.com> Hey, suppose I am writing a subsystem for WildFly, that I can or want not add to the generic WildFly codebase (e.g. because it is not open source or because WildFly team would consider it too special for general consumption). Is there a way to package that up in a .zip or any other format (in the good 'ol days we used .shar files :-) to deliver such a subsystem with its module but also the xsl to modify standalone.xml (or similar)? If not (yet), would it make sense for WildFly to reconsider allowing to provide e.g. * ext.xml * subsystem.xml * ports.xml that will get merged / added to standalone.xml when the module is loaded for the very first time (like when the module.jar is also indexed for the first time). Thanks Heiko From ssilvert at redhat.com Mon Sep 29 08:32:19 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Mon, 29 Sep 2014 08:32:19 -0400 Subject: [wildfly-dev] Adding jar to WAR from DeploymentProcessor Message-ID: <54295153.4020402@redhat.com> The Keycloak auth server allows third-parties to add providers using the ServiceLoader. To do this, you need to open Keycloak's auth-server.war and drop your jar into the WEB-INF/lib directory. I'd like to eliminate opening the WAR and have a DeploymentProcessor look in a particular directory and add the jar at deployment time. What is the cleanest way to do that? Bonus points if you tell me that I can treat the service provider jar as a deployment and let the user upload it via CLI. :-) Thanks, Stan From tomaz.cerar at gmail.com Mon Sep 29 09:00:04 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Mon, 29 Sep 2014 15:00:04 +0200 Subject: [wildfly-dev] Adding jar to WAR from DeploymentProcessor In-Reply-To: <54295153.4020402@redhat.com> References: <54295153.4020402@redhat.com> Message-ID: On Mon, Sep 29, 2014 at 2:32 PM, Stan Silvert wrote: > I'd like to eliminate opening the WAR and have a DeploymentProcessor > look in a particular directory and add the jar at deployment time. What > is the cleanest way to do that? > Simple let user create new module that has that jar in it and than in your war dependencies processor add that module to deployment as dependency > Bonus points if you tell me that I can treat the service provider jar as > a deployment and let the user upload it via CLI. :-) > you can add module as global dependency, but that is ugly. But what you could do is have deployment processor that would handle exactly deployments and register keycloak plugins based on that. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140929/0b85534f/attachment.html From ssilvert at redhat.com Mon Sep 29 09:10:25 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Mon, 29 Sep 2014 09:10:25 -0400 Subject: [wildfly-dev] Adding jar to WAR from DeploymentProcessor In-Reply-To: References: <54295153.4020402@redhat.com> Message-ID: <54295A41.1010303@redhat.com> On 9/29/2014 9:00 AM, Toma? Cerar wrote: > > On Mon, Sep 29, 2014 at 2:32 PM, Stan Silvert > wrote: > > I'd like to eliminate opening the WAR and have a DeploymentProcessor > look in a particular directory and add the jar at deployment time. > What > is the cleanest way to do that? > > > Simple let user create new module that has that jar in it and than in > your war > dependencies processor add that module to deployment as dependency I tried that and it doesn't work very well. The service jar will need to depend on classes in WEB-INF/lib. So the dependencies get hard to declare in module.xml. A user might not even know how to do it. So it really needs to "look" like it's sitting in WEB-INF/lib. I see the code in WebStructureDeploymentProcessor that adds ResourceRoots to Attachments.RESOURCE_ROOTS. I'm wondering if that is the way to accomplish this. https://github.com/wildfly/wildfly/blob/master/undertow/src/main/java/org/wildfly/extension/undertow/deployment/WarStructureDeploymentProcessor.java#L121 > > Bonus points if you tell me that I can treat the service provider > jar as > a deployment and let the user upload it via CLI. :-) > > you can add module as global dependency, but that is ugly. Yea, I don't want to do that. > > But what you could do is have deployment processor that would handle > exactly > deployments and register keycloak plugins based on that. I don't understand what you mean by "exactly deployments". > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140929/3084ecde/attachment.html From hbraun at redhat.com Mon Sep 29 12:30:47 2014 From: hbraun at redhat.com (Heiko Braun) Date: Mon, 29 Sep 2014 18:30:47 +0200 Subject: [wildfly-dev] Deliver 3rd party subsystem to customers? In-Reply-To: <43C4D1A3-7256-4436-A093-A5B321C1DC06@redhat.com> References: <43C4D1A3-7256-4436-A093-A5B321C1DC06@redhat.com> Message-ID: <054697E9-9395-466F-9BD1-EFBD58EB0ED0@redhat.com> I think the recently added feature packs work that way. Stuart wrote about that last week: http://lists.jboss.org/pipermail/wildfly-dev/2014-September/002919.html > Am 29.09.2014 um 13:36 schrieb "Heiko W.Rupp" : > > Hey, > > suppose I am writing a subsystem for WildFly, that I can or want not add to the generic WildFly codebase (e.g. because it is not open source or because WildFly team would consider it too special for general consumption). > > Is there a way to package that up in a .zip or any other format (in the good 'ol days we used .shar files :-) > to deliver such a subsystem with its module but also the xsl to modify standalone.xml (or similar)? > > If not (yet), would it make sense for WildFly to reconsider allowing to provide e.g. > * ext.xml > * subsystem.xml > * ports.xml > > that will get merged / added to standalone.xml when the module is loaded for the very first time > (like when the module.jar is also indexed for the first time). > > Thanks > Heiko > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From brian.stansberry at redhat.com Mon Sep 29 12:42:35 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 29 Sep 2014 11:42:35 -0500 Subject: [wildfly-dev] Deliver 3rd party subsystem to customers? In-Reply-To: <054697E9-9395-466F-9BD1-EFBD58EB0ED0@redhat.com> References: <43C4D1A3-7256-4436-A093-A5B321C1DC06@redhat.com> <054697E9-9395-466F-9BD1-EFBD58EB0ED0@redhat.com> Message-ID: <54298BFB.2040309@redhat.com> Agreed. I see feature-packs as the best solution to this kind of thing. CLI archives are another possibility, with the archive bundling the module and then the script executes to install it and make needed mods, but my instinct is the feature-pack stuff will end up being a better approach. On 9/29/14, 11:30 AM, Heiko Braun wrote: > I think the recently added feature packs work that way. Stuart wrote about that last week: http://lists.jboss.org/pipermail/wildfly-dev/2014-September/002919.html > > > > > > >> Am 29.09.2014 um 13:36 schrieb "Heiko W.Rupp" : >> >> Hey, >> >> suppose I am writing a subsystem for WildFly, that I can or want not add to the generic WildFly codebase (e.g. because it is not open source or because WildFly team would consider it too special for general consumption). >> >> Is there a way to package that up in a .zip or any other format (in the good 'ol days we used .shar files :-) >> to deliver such a subsystem with its module but also the xsl to modify standalone.xml (or similar)? >> >> If not (yet), would it make sense for WildFly to reconsider allowing to provide e.g. >> * ext.xml >> * subsystem.xml >> * ports.xml >> >> that will get merged / added to standalone.xml when the module is loaded for the very first time >> (like when the module.jar is also indexed for the first time). >> >> Thanks >> Heiko >> >> >> _______________________________________________ >> 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 jason.greene at redhat.com Mon Sep 29 12:56:34 2014 From: jason.greene at redhat.com (Jason Greene) Date: Mon, 29 Sep 2014 11:56:34 -0500 Subject: [wildfly-dev] Deliver 3rd party subsystem to customers? In-Reply-To: <54298BFB.2040309@redhat.com> References: <43C4D1A3-7256-4436-A093-A5B321C1DC06@redhat.com> <054697E9-9395-466F-9BD1-EFBD58EB0ED0@redhat.com> <54298BFB.2040309@redhat.com> Message-ID: <130544E0-64E1-4A18-B552-F0405146CF8D@redhat.com> Yeah this is a key goal of features. You can do something like "feature install org.blah.feature?, and it fetches it from maven and installs it. On Sep 29, 2014, at 11:42 AM, Brian Stansberry wrote: > Agreed. I see feature-packs as the best solution to this kind of thing. > > CLI archives are another possibility, with the archive bundling the > module and then the script executes to install it and make needed mods, > but my instinct is the feature-pack stuff will end up being a better > approach. > > On 9/29/14, 11:30 AM, Heiko Braun wrote: >> I think the recently added feature packs work that way. Stuart wrote about that last week: http://lists.jboss.org/pipermail/wildfly-dev/2014-September/002919.html >> >> >> >> >> >> >>> Am 29.09.2014 um 13:36 schrieb "Heiko W.Rupp" : >>> >>> Hey, >>> >>> suppose I am writing a subsystem for WildFly, that I can or want not add to the generic WildFly codebase (e.g. because it is not open source or because WildFly team would consider it too special for general consumption). >>> >>> Is there a way to package that up in a .zip or any other format (in the good 'ol days we used .shar files :-) >>> to deliver such a subsystem with its module but also the xsl to modify standalone.xml (or similar)? >>> >>> If not (yet), would it make sense for WildFly to reconsider allowing to provide e.g. >>> * ext.xml >>> * subsystem.xml >>> * ports.xml >>> >>> that will get merged / added to standalone.xml when the module is loaded for the very first time >>> (like when the module.jar is also indexed for the first time). >>> >>> Thanks >>> Heiko >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From stuart.w.douglas at gmail.com Mon Sep 29 17:52:29 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Tue, 30 Sep 2014 07:52:29 +1000 Subject: [wildfly-dev] Adding jar to WAR from DeploymentProcessor In-Reply-To: <54295153.4020402@redhat.com> References: <54295153.4020402@redhat.com> Message-ID: <5429D49D.8010305@gmail.com> Stan Silvert wrote: > The Keycloak auth server allows third-parties to add providers using the > ServiceLoader. To do this, you need to open Keycloak's auth-server.war > and drop your jar into the WEB-INF/lib directory. > > I'd like to eliminate opening the WAR and have a DeploymentProcessor > look in a particular directory and add the jar at deployment time. What > is the cleanest way to do that? > Deployment overlay. Add the jar as an overlay in WEB-INF/lib. > Bonus points if you tell me that I can treat the service provider jar as > a deployment and let the user upload it via CLI. :-) It can be uploaded via the CLI, but it is not a deployment as such. Stuart > > Thanks, > > Stan From rory.odonnell at oracle.com Tue Sep 30 05:48:13 2014 From: rory.odonnell at oracle.com (Rory O'Donnell Oracle, Dublin Ireland) Date: Tue, 30 Sep 2014 10:48:13 +0100 Subject: [wildfly-dev] Early Access builds for JDK 9 b32 and JDK 8u40 b07 are available on java.net Message-ID: <542A7C5D.7050305@oracle.com> Hi Guys, Early Access build for JDK 9 b32 is available on java.net, summary of changes are listed here Early Access build for JDK 8u40 b07 is available on java.net, summary of changes are listed here. 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/20140930/3ccfbaf4/attachment.html From hrupp at redhat.com Tue Sep 30 08:51:48 2014 From: hrupp at redhat.com (Heiko W.Rupp) Date: Tue, 30 Sep 2014 14:51:48 +0200 Subject: [wildfly-dev] Customizing a provisioned server In-Reply-To: <54094FAC.7050202@redhat.com> References: <5407E7AF.6060701@redhat.com> <54083BBB.1000806@redhat.com> <5408D687.4010304@gmail.com> <54094FAC.7050202@redhat.com> Message-ID: <623F21C5-9035-408A-B7D6-6BD166B5C87A@redhat.com> Am 05.09.2014 um 07:52 schrieb Thomas Heute : > Sounds like what I want to do remotely :) > Let's take an example, I would like to be able to "deploy and configure" > keycloak on a group of servers (i can handle the "group" part). > Deploying and installing keycloak today requires to: > - Add a few modules > - add 1 extension and 1 subsytem in standalone/domain.xml > - add 1 security domain in standalone/domain.xml > > If Keycloak could be delivered as "feature pack" to do the 3 steps above > I would still want the possibility to do this remotely on a set of servers. > > You could argue that you need to prepare a package beforehand "locally" > and they deploy the fully customized WF but I don't think it would > always be the preferred solution I think we need both (and on a more recent thread there was even the option to download the feature pack from maven). Remote install to update existing servers in the data center from a central console. And also an easy way for standalone install. java -jar keycloak-fp --wildfly=/path/to/wildfly The current situation with "manually" editing standalone.xml is a very bad user experience. One could supply a cli-script, but still putting the module in the right place into the filesystem and then starting the cli to run :add(extension) and :add(subsystem) is much more error-prone.